This chapter covers Amazon RDS automated backups and manual snapshots, two critical features for database reliability and disaster recovery. On the SOA-C02 exam, approximately 8-12% of questions touch on RDS backup and recovery, making it a high-yield topic. You will be tested on the differences between automated backups and manual snapshots, retention periods, point-in-time recovery, cross-region snapshot copy, and how these features interact with RDS Multi-AZ and read replicas. Mastery of this topic is essential for the Reliability domain.
Jump to a section
Imagine a library with thousands of books. The head librarian (AWS) has a system: every day at a fixed time, a cart comes by and photographs every single page of every book (automated snapshot). These photographs are stored in a fireproof vault in a separate building (S3). The librarian keeps a log of which photographs correspond to which book and date. If a book is damaged or lost, she can retrieve the most recent photographs and reprint the entire book, but only back to the oldest photograph in the vault (retention period). However, the librarian also has a special service: she can take a single photograph of a specific book at any moment (manual snapshot). That photograph is also stored in the vault but never expires. If she wants to restore a book from a manual snapshot, she can do so at any time, regardless of the automated schedule. The vault has a limited capacity, and older automated photographs are shredded after the retention period expires. The librarian can also copy a manual snapshot to another library (cross-region snapshot copy) for disaster recovery. This system allows the library to recover from any disaster, but only within the window of the automated retention period or as far back as manual snapshots exist.
What Are RDS Automated Backups and Snapshots?
Amazon RDS provides two distinct mechanisms for backing up your database instances: automated backups and manual snapshots. Both create storage volume snapshots of your DB instance, but they differ in lifecycle, retention, and purpose.
Automated backups are enabled by default when you create an RDS DB instance. They consist of two components: a daily automated snapshot (taken during your preferred backup window) and transaction logs captured continuously throughout the day. Together, they enable point-in-time recovery (PITR) to any second within the retention period. The retention period can be set from 0 (disabled) to 35 days. If you set retention to 0, automated backups are disabled entirely, and you lose the ability to perform PITR.
Manual snapshots are user-initiated snapshots that you create explicitly. They persist until you manually delete them, regardless of the automated backup retention period. Manual snapshots are ideal for long-term retention, pre-migration backups, or creating a baseline before major changes.
How Automated Backups Work Internally
When automated backups are enabled, RDS performs the following:
Daily Snapshot: Once per day, during your 30-minute backup window (configurable), RDS takes a full snapshot of your DB instance's storage volume. This snapshot is stored in Amazon S3, but you do not see it in the S3 console; it is managed by RDS. The first snapshot is a full copy of all data. Subsequent daily snapshots are incremental — only changed blocks are stored.
Transaction Logs: RDS continuously captures transaction logs (for MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, and Aurora) from the database engine. These logs are uploaded to S3 every few minutes. For MySQL, these are binary logs (binlogs); for PostgreSQL, WAL files. The logs allow you to restore to any point in time within the retention window, down to the second.
Point-in-Time Recovery (PITR): When you initiate a PITR restore, RDS selects the daily snapshot taken before the target time, then applies the relevant transaction logs to bring the database to the exact requested second. This process can take from minutes to hours, depending on the database size and the amount of log data to replay.
Retention Period Deletion: When the retention period expires, RDS automatically deletes the daily snapshots and purges the associated transaction logs. After deletion, you cannot restore to points in time older than the retention window.
Key Components, Values, Defaults, and Timers
Backup Retention Period: Default is 7 days. Can be set between 0 (disabled) and 35 days. Changing the retention period affects existing backups: increasing it retains older snapshots; decreasing it may delete snapshots beyond the new period.
Backup Window: A 30-minute window chosen by RDS if you don't specify one. You can set a custom window (e.g., 03:00-03:30 UTC). During this window, I/O may be briefly suspended for snapshot consistency, though for Multi-AZ instances, the snapshot is taken from the standby to avoid impact.
Snapshot Storage: Automated snapshots are stored in S3, but you are not charged for snapshot storage up to the size of your DB instance. Beyond that, you pay per GB-month. Manual snapshots incur storage charges at standard S3 rates.
Transaction Log Retention: Logs are retained for the same duration as the backup retention period. For PITR to work, logs must be present; if automated backups are disabled, no logs are captured.
Cross-Region Snapshot Copy: Manual snapshots can be copied to another AWS region. Automated snapshots cannot be copied directly; you must first create a manual snapshot from the automated one, then copy it.
Configuration and Verification Commands
You can manage backups via the AWS Management Console, AWS CLI, or SDK. Key CLI commands:
Modify backup retention:
aws rds modify-db-instance --db-instance-identifier mydb --backup-retention-period 14Create a manual snapshot:
aws rds create-db-snapshot --db-instance-identifier mydb --db-snapshot-identifier mydb-manual-20250321Restore to a point in time:
aws rds restore-db-instance-to-point-in-time --source-db-instance-identifier mydb --target-db-instance-identifier mydb-restored --restore-time 2025-03-21T14:30:00ZList snapshots:
aws rds describe-db-snapshots --db-instance-identifier mydbCopy a snapshot to another region:
aws rds copy-db-snapshot --source-db-snapshot-identifier arn:aws:rds:us-east-1:123456789012:snapshot:mydb-manual --target-db-snapshot-identifier mydb-manual-copy --source-region us-east-1 --region eu-west-1Interactions with Related Technologies
Multi-AZ: For Multi-AZ deployments, automated snapshots are taken from the standby replica, eliminating I/O suspension on the primary. Manual snapshots are also taken from the standby if available. PITR works the same.
Read Replicas: Read replicas can be promoted to standalone instances, but they do not have automated backups enabled by default. You must enable them after promotion. Manual snapshots of read replicas are allowed.
Encryption: If your DB instance is encrypted with AWS KMS, all snapshots (automated and manual) are automatically encrypted with the same KMS key. When copying an encrypted snapshot, you must specify the same or a different KMS key.
Aurora: Aurora uses a different backup mechanism (continuous backup to S3 with 1-day retention by default, up to 35 days). Aurora snapshots are also managed differently; the concept of transaction logs is replaced by Aurora's cluster volume.
Enable Automated Backups
Automated backups are enabled by default when you create a DB instance with a retention period of 1-35 days. To verify, check the 'Backup retention period' in the RDS console or describe the instance. If disabled (retention=0), you cannot perform PITR. You can enable or modify retention at any time; RDS will start capturing daily snapshots and transaction logs after the change. Note that changing from 0 to a positive value does not create a snapshot immediately — the first snapshot occurs during the next backup window.
Daily Snapshot Creation
During the backup window, RDS initiates a snapshot of the DB instance's storage volume. For Single-AZ, I/O is briefly suspended (typically a few seconds) to ensure consistency. For Multi-AZ, the snapshot is taken from the standby, so no I/O impact. The snapshot is stored in S3 and is incremental. The first snapshot is full; subsequent snapshots store only changed blocks. You cannot access these snapshots directly; they are managed by RDS.
Transaction Log Capture
RDS continuously uploads transaction logs from the DB engine to S3 every few minutes (typically every 5 minutes). For MySQL, binary logs are used; for PostgreSQL, WAL files. These logs are retained for the same period as the backup retention. They enable PITR to any second within the window. If you delete or truncate logs manually (e.g., using PURGE BINARY LOGS), PITR may fail for times after the deletion.
Point-in-Time Restore
To restore to a specific time, RDS selects the most recent daily snapshot taken before the target time, then replays the transaction logs up to the exact second. The restore creates a new DB instance with a new endpoint. You can restore to any time within the retention period, down to second granularity. The restore time depends on database size and log volume; large databases may take hours.
Manual Snapshot Creation
You can create a manual snapshot at any time using the console, CLI, or API. The snapshot is a full, consistent snapshot of the DB instance. It persists until you delete it, regardless of the backup retention period. Manual snapshots incur storage costs. They are useful for long-term retention, pre-upgrade backups, or creating a baseline.
Cross-Region Snapshot Copy
You can copy manual snapshots to another AWS region for disaster recovery. The copy is asynchronous and can take time. You must specify the source region and target region. Encrypted snapshots require a KMS key in the target region. Automated snapshots cannot be copied directly; you must first create a manual snapshot from the automated one, then copy it.
Enterprise Scenario 1: Financial Services Compliance
A financial services company must retain database backups for 7 years to comply with regulatory requirements. RDS automated backups only support up to 35 days, so they use manual snapshots. They have a Lambda function that runs weekly to create a manual snapshot of their production MySQL RDS instance and tags it with the date and retention policy. The snapshots are stored in the same region, and after 7 years, another Lambda deletes them based on tags. They also copy the snapshot to a separate AWS account in the same region for additional security. Common issues: forgetting to delete old snapshots leads to escalating costs; they use lifecycle policies and cost alerts to manage this.
Enterprise Scenario 2: E-commerce Platform Disaster Recovery
An e-commerce platform uses RDS for PostgreSQL with Multi-AZ and automated backups set to 35 days. They need to be able to recover from a regional failure. They create a manual snapshot every day and copy it to another region using cross-region snapshot copy. In the disaster recovery region, they restore the latest snapshot into a standby instance that is kept stopped to save costs. They use AWS Backup to centralize backup policies across RDS and other services. When testing disaster recovery, they discovered that cross-region copy can take up to several hours for large databases (2 TB+). They now schedule copies to start immediately after the manual snapshot is created.
Scenario 3: Development/Test Environment Refresh
A development team needs to refresh their test environment with production data weekly. They take a manual snapshot of the production RDS instance, then restore it into a new test instance. They use the same KMS key for encryption. They automate this with a CloudFormation template that creates the test instance from the latest snapshot. A common mistake is restoring from an automated snapshot instead of a manual one — automated snapshots are deleted after retention expires, so the restore may fail if the snapshot is gone. They now always use manual snapshots for this purpose.
What SOA-C02 Tests on This Topic
The exam objectives under Domain 2: Reliability, Objective 2.2 (Backup and Restore) specifically test your ability to implement and manage RDS backups. Key areas:
Differences between automated backups and manual snapshots (lifecycle, retention, deletion)
Point-in-time recovery (PITR) capabilities and limitations
Cross-region snapshot copy requirements and restrictions
Impact of disabling automated backups (loss of PITR, no transaction logs)
Interaction with Multi-AZ (snapshot taken from standby, no I/O suspension)
Encryption considerations for snapshots
Common Wrong Answers and Why Candidates Choose Them
"Automated backups allow PITR beyond the retention period if you have manual snapshots." This is false. Manual snapshots are point-in-time images, not continuous; you cannot restore to a specific second within them. PITR only works within the automated backup retention window.
"You can copy an automated snapshot directly to another region." False. Only manual snapshots can be copied. You must first create a manual snapshot from the automated one, then copy.
"Disabling automated backups deletes existing manual snapshots." False. Manual snapshots persist until manually deleted.
"Restoring from a snapshot creates an instance with the same endpoint." False. Restore always creates a new instance with a new endpoint.
Specific Numbers and Terms on the Exam
Retention period: 0-35 days. Default is 7 days.
Backup window: 30 minutes. Customizable.
Transaction log upload interval: every 5 minutes (approximately).
Cross-region snapshot copy: only for manual snapshots.
Snapshot storage: free up to DB instance size; additional storage charged at S3 rates.
Edge Cases and Exceptions
RDS on VMware: Not covered on SOA-C02.
Aurora: Different backup mechanism; exam may ask you to differentiate.
SQL Server with Multi-AZ: Automated backups are taken from the primary, not standby, for SQL Server Mirroring (not Always On).
Read Replicas: Automated backups are not enabled by default; you must enable them after promotion.
How to Eliminate Wrong Answers
If a question asks about restoring to a specific time, check if automated backups are enabled and the retention window. If the answer mentions restoring from a manual snapshot to a specific second, it is wrong because manual snapshots are point-in-time, not continuous. If the answer says "copy automated snapshot to another region," it is wrong because only manual snapshots can be copied. If the answer says "restore to the same instance," it is wrong because restore creates a new instance.
Automated backups are enabled by default with a 7-day retention; can be set from 0 (disabled) to 35 days.
Point-in-time recovery (PITR) restores to any second within the retention window using daily snapshots + transaction logs.
Manual snapshots persist until deleted and are ideal for long-term retention.
Only manual snapshots can be copied across regions; automated snapshots must be converted first.
Restoring a snapshot always creates a new DB instance with a new endpoint.
For Multi-AZ, snapshots are taken from the standby to avoid I/O impact.
Transaction logs are captured every ~5 minutes and retained for the same period as automated backups.
These come up on the exam all the time. Here's how to tell them apart.
Automated Backups
Enabled by default with retention 1-35 days.
Automatically deleted after retention period expires.
Supports point-in-time recovery (PITR) to any second within retention.
Cannot be copied directly across regions.
No additional storage cost up to DB instance size.
Manual Snapshots
Created manually by user.
Persist until manually deleted.
Only restores to the exact time the snapshot was taken.
Can be copied to other regions and accounts.
Incur standard S3 storage costs.
Mistake
Automated backups and manual snapshots are stored in the same S3 bucket and can be accessed via S3 console.
Correct
Both are stored in S3, but they are managed by RDS and are not visible in the S3 console. You can only interact with them through the RDS console, CLI, or API.
Mistake
You can restore a manual snapshot to the same DB instance, overwriting its data.
Correct
Restoring from any snapshot always creates a new DB instance with a new endpoint. You cannot "restore over" an existing instance. You must rename or delete the old instance and then rename the new one if needed.
Mistake
Disabling automated backups (retention=0) deletes all existing automated snapshots immediately.
Correct
Setting retention to 0 disables future backups and deletes existing automated snapshots, but the deletion happens within a few hours, not instantly. Manual snapshots are unaffected.
Mistake
Point-in-time recovery can restore to any point in time within the retention period, even if you have no transaction logs.
Correct
PITR requires transaction logs. If logs are purged or corrupted, you can only restore to the time of the last daily snapshot, not to arbitrary seconds.
Mistake
Cross-region snapshot copy is available for both automated and manual snapshots.
Correct
Only manual snapshots can be copied across regions. Automated snapshots must first be converted to manual snapshots (by creating a manual snapshot from the automated one) before copying.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you cannot directly restore an automated backup to a different region. Automated backups are region-specific. To move a backup across regions, you must first create a manual snapshot from the automated backup, then copy that manual snapshot to the target region, and finally restore from the copied snapshot.
Setting retention to 0 disables automated backups. Existing automated snapshots and transaction logs are deleted, typically within a few hours. You will lose the ability to perform point-in-time recovery. Manual snapshots are unaffected.
No, manual snapshots are static point-in-time images. They do not include transaction logs, so you can only restore to the exact time the snapshot was taken. For PITR, you must rely on automated backups.
First, ensure the snapshot is a manual snapshot (create one from automated if needed). Then use the copy-db-snapshot command, specifying the source region and a KMS key in the target region. The target KMS key can be the same as the source if using a multi-region key, or a different one.
No, restoring a snapshot creates a new, independent DB instance with a new endpoint. The original instance remains unchanged. You can later delete the original if desired.
Aurora uses a different mechanism: continuous backup to S3 with automatic point-in-time recovery for up to 35 days. Aurora snapshots are also stored in S3 but are separate. The exam focuses on RDS (non-Aurora) for this objective, but be aware of the difference.
Yes, you can set a custom backup window (e.g., 02:00-02:30 UTC) when creating or modifying a DB instance. RDS will start the daily snapshot during that window. The window must be at least 30 minutes.
You've just covered RDS Automated Backups and Snapshots — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?