Ref: https://learn.cantrill.io/courses/1820301/lectures/41301423
Backing up data in RDS
Diagram: https://github.com/acantril/aws-dev-associate/blob/main/16_SQL_DATABASES/00_LearningAids/RDS_Backups.png
- 🔧 RDS data can be backed up to S3 via EBS snapshots
- Options:
- Manual Snapshots
- Automated Backups
- Data stored in S3 buckets that are AWS-managed
- ❗ Buckets can be seen from RDS console UI, but not from S3 console UI
- S3 benefits: data replication across multiple AZs of the region (better resiliency)
- RDS snapshots/backups use EBS snapshots under the hood
- ❗ Snapshots can NOT be seen from EBS console UI, only from RDS console UI
- I/O pause in RDS instance while taking snapshot/backup from it
- PROD: usually Multi-AZ enabled and standby instance can be used → no read performance issues neither on primary instance nor on app
- ‼️ Read performance is unaffected, but Write performance is paused while making a backup from a replica!
- Data replication is synchronous, and must be registered in the standby replica too for it to be committed!
- 💡 Rs are generally much higher in volume than Ws, so in general DB performance is unaffected by backups in Multi-AZ mode
- DEV/TEST: if Single-AZ, performance pause (because it's the only instance)
- Incremental snapshots/backups architecture
- 💡 Same as with EBS snapshots of EC2 instances
- First snapshot/backup is full (whole instance data)
- Size equivalent to consumed data
- 💡 Might take a while, especially with large DBs
- Following snapshots/backups are incremental
- Contain only changes since the last snapshot/backup
- 💡 Usually much quicker than first snapshot/backup, unless many data changes
- ❗ Resilient to deleting a specific snapshot/backup in the chain, still functional!
RDS Manual Snapshots
- 🔧 Run explicitly (manually), or via a script or custom application
- Do NOT expire
- Live on past RDS instance lifecycle (i.e. after deleting the instance)
- ‼️ Must be cleaned up/deleted by the customer! Billed for storage until deleted!
- Customer decides frequency
- Can be taken on an hourly, daily, weekly, etc basis
- ❗ Taking more frequent snapshots reduces RPO
- When deleting an RDS instance, you will be prompted to create a final snapshot to keep data
RDS Automated Backups
- 🔧 Essentially they're automated snapshots
- Happen daily on a backup window defined on the instance
- Use a window that fits the business, or AWS can pick a backup window at random
- ❗ If Single-AZ, schedule them in periods of little/no usage of app (because of I/O pause)
- They EXPIRE
- Cleaned automatically by AWS
- Retention period can be 0-35 days
- 0 days ↔ automatic backups are disabled
- Any data older than retention period is removed
- ‼️ These backups still expire even if you keep them after deleting the RDS instance!!
- Circumvent this by creating a final manual snapshot when deleting the instance
- In addition, transaction logs also uploaded to S3 every 5 minutes
- Combination of Backup + transaction logs means that instance can be restored to any point in time (during retention period) with 5-minutes granularity
- 💡 Can reach a 5-minutes RPO
- ❗ Instances can be restored to any point in time with a 1-second granularity as long as the transaction logs up to that point have been uploaded.
- 💡 e.g. Transaction logs uploaded for 12:46 and 12:51. You can restore to 12:48:35, but you can't restore to 12:54:02 (because the logs for 12:56 haven't been uploaded yet)
- …but transaction logs increase the time for an automated backup to be restored!
- DB needs to be restored from the snapshot and transaction logs need to be applied to bring the DB to the desired point-in-time
- 💡 RTO for automated snapshots generally longer than manual snapshots
- Cross-Region Replication (CRR) via S3: RDS can replicate backups to another region
- Both backups & transaction logs
- Charges apply for cross-region data copy & storage in the destination region
- ❗NOT the default. Must be explicitly enabled
