What happens when a database hosting a critical application is accidentally deleted, or when ransomware encrypts every file on a server? Without a copy stored safely elsewhere, that data is permanently gone. This is the exact problem that backup and restore practises solve for the SOA-C02 exam, and the reason cloud professionals are paid to plan for disaster before it strikes.
Jump to a section
Because you leave a spare set of car keys with a neighbour, your car isn't stranded when you lock your keys inside.
Now suppose your home contains a fireproof safe where you keep copies of your passport, a spare debit card, and a USB stick with digital photos. You update this safe every time you get a new passport or take important new photos. This safe is your backup—a separate copy kept intentionally apart from the originals. If your house floods and paper documents are ruined, you walk to the safe, open it, and retrieve the copies. That action—recovering from the safe—is your restore.
But there is a catch. If you keep the safe in the same room as your originals, a fire could destroy both. So you learn: the safe must be in a different location, ideally a bank vault. In cloud terms, that is a cross-region backup. Also, you must test that the USB stick actually works—otherwise you have a backup that fails when you need it. This routine is restore testing. Every step here maps to AWS Backup: the safe is a backup vault, the documents are EBS snapshots or RDS database backups, and the bank vault is a different AWS Region. Just as you would not trust a safe you never open, you must not trust a backup you never restore.
Backup and restore is the process of creating copies of data (backups) and then using those copies to return systems to a working state (restore). In AWS, the primary tool for this is AWS Backup, a fully managed service that lets you centrally configure backup policies and monitor backup activity across AWS services like Amazon EC2 (virtual servers), Amazon RDS (managed databases), and Amazon EFS (file storage).
Before AWS Backup existed, IT teams had to write custom scripts to schedule snapshots—point-in-time copies of a volume or database. A snapshot captures the entire state of a resource at a specific moment. For example, an Amazon EBS snapshot is a copy of a virtual hard drive attached to an EC2 instance. You can take a snapshot every hour, day, or week depending on your Recovery Point Objective (RPO)—the maximum acceptable amount of data loss measured in time. If your RPO is 15 minutes, you must take snapshots at least every 15 minutes.
The other key metric is Recovery Time Objective (RTO)—how quickly you need to be back online after a failure. If your RTO is one hour, your restore process must complete within that window. AWS Backup helps enforce both by letting you create backup plans: rules that define when to take backups, how long to keep them (retention period), and where to store them (in the same Region or a different Region for disaster recovery).
AWS Backup stores backups in a backup vault using AWS Backup Vault Lock, which prevents anyone (even administrators) from deleting backups before the retention period expires. This is a defence against ransomware because an attacker who gains access cannot delete your backups and then demand payment.
Manual snapshots are a different approach. You initiate them using the AWS Management Console, CLI (Command Line Interface), or SDK (Software Development Kit). While flexible, manual snapshots require you to remember to create them and manage their lifecycle yourself—no automated deletion, no central dashboard. They are useful for on-demand backups, like before a risky software update, but they are error-prone for long-term strategies.
Restore is the flip side. You take a backup and create a new resource from it. For an EBS snapshot, you create a new volume and attach it to an instance. For an RDS snapshot, you launch a new database instance. AWS Backup can restore to the same AWS account, a different account (useful for isolation), or a different Region (cross-region restore). The service also supports granular restores—for example, restoring a single file from an EFS backup rather than the entire file system.
Key terms you must know:
Backup plan: a policy that specifies frequency, retention window, and backup vault.
Backup vault: a logical container that stores your backups.
Recovery point: a specific backup (snapshot or backup) stored in a vault.
Retention period: how long a backup is kept before automatic deletion.
Cross-region backup: copying a backup to a different AWS Region for disaster recovery.
Cross-account backup: copying a backup to a different AWS account for organisational separation.
Automation is the heart of modern backup strategy. AWS Backup integrates with AWS Organizations, so you can enforce backup policies across hundreds of accounts. You can also trigger Lambda functions before or after a backup to run custom logic, like notifying a team via Amazon SNS (Simple Notification Service).
What this replaces is the old way: manual scripts running on a server, emails to check success, and spreadsheets tracking retention. AWS Backup makes backup as a service: you define the policy once, and the cloud handles the rest. For the SOA-C02 exam, you must understand the difference between automated (AWS Backup) and manual (console/CLI) approaches, when to use each, and how to test that a restore actually works.
Define your RPO and RTO requirements
Before any technical setup, decide how much data loss you can tolerate (RPO) and how quickly you need to restore (RTO). For example, an RPO of 1 hour means you need backups at least every 60 minutes. An RTO of 4 hours means your restore process (including spinning up resources and validating) must finish within that window.
Create a backup plan in AWS Backup
Open the AWS Backup console and create a backup plan. Choose a frequency (e.g., daily at 2 AM), a retention period (e.g., 30 days), and a backup vault. Optionally enable cross-region copy to another Region for disaster recovery.
Assign resources to the backup plan
Use resource assignment rules to apply the backup plan to specific resources (e.g., all RDS databases with a tag 'Environment=Production'). AWS Backup will automatically create backups according to the plan. You can also manually assign individual resources.
Enable backup vault lock
From the backup vault settings, enable AWS Backup Vault Lock. Choose 'compliance mode' if you want a hard lock that cannot be removed. This ensures no one—not even an administrator—can delete backups before the retention period expires.
Optionally take a manual snapshot for immediate need
If you need a backup right now before a major change (like a schema migration), use the console or CLI to take a manual EBS snapshot or RDS snapshot. This is separate from your automated plan. Be aware: manual snapshots do not have lifecycle rules, so you must delete them manually when no longer needed to avoid cost.
Monitor backup jobs and test restores
Use the AWS Backup dashboard to check that backups completed successfully. Set up Amazon CloudWatch alarms for failures. Schedule a monthly restore test where you restore a backup into a test environment, verify data integrity, and measure the time taken. This validates that your RTO is realistic and your backups are not corrupt.
Imagine you work for an e-commerce company called ShopFast that runs a customer database on Amazon RDS for MySQL and a fleet of web servers on Amazon EC2 with EBS volumes holding product images. One morning, a junior engineer runs a script that accidentally drops the 'customers' table. Without a backup, the company loses every customer record.
Because you planned ahead, you had already set up AWS Backup with a backup plan that takes a daily snapshot of the RDS database at 2:00 AM and retains it for 30 days. You also enabled cross-region backup to copy that snapshot to a different Region (say, us-west-2) in case the primary Region experiences an outage.
Step by step, what you do:
Open the AWS Backup console and navigate to the backup vault where the database backups are stored.
Find the most recent recovery point (the backup taken at 2:00 AM today).
Choose 'Restore' and specify that you want to restore to a new RDS instance. For a MySQL database, you can also choose to restore to a point in time (within the last 30 days) for more granular recovery—like restoring the table as it was at 1:45 PM yesterday.
The new RDS instance spins up. You give it a temporary name like 'customer-db-restored'.
You then use a SQL client to connect to the restored database and export the 'customers' table.
Finally, you import that table into the original production database (after confirming the original drops), and then delete the temporary restored instance to avoid extra costs.
Now consider the product images on EBS volumes. Those are not automatically backed up by AWS Backup for EC2 instances unless you specifically create backups for the volumes. Your plan includes a weekly snapshot of each EBS volume, kept for 90 days. If a volume fails, you simply create a new volume from the latest snapshot and attach it to the EC2 instance in minutes.
An IT professional also monitors backup jobs. AWS Backup provides a dashboard showing completion status, failed jobs, and restore tests. You set up Amazon CloudWatch alarms to alert if a backup job fails. You also schedule a monthly 'restore drill' where you restore a database and web server from backups into a test environment and verify that the application works. This is called restore testing—it proves your backups are valid and your RTO is achievable.
Finally, you enforce backup retention using AWS Backup Vault Lock. When you enable the lock in 'compliance mode', even root users cannot delete backups before the retention period ends. This protects against an attacker who gets into the AWS account and tries to delete all backups as part of a ransomware attack.
The SOA-C02 exam tests backup and restore practises heavily. Expect questions that ask you to choose between AWS Backup and manual snapshots for a given scenario, or to select the correct retention policy. The exam loves to test your understanding of: Recovery Point Objective (RPO) vs Recovery Time Objective (RTO), cross-region vs cross-account backups, and the difference between a snapshot and an AMI (Amazon Machine Image—a template for an EC2 instance that includes the OS and software).
Common question types:
Scenario-based: 'A company needs to restore a database to the state it was in 10 minutes ago. Which approach should they use?' The answer is point-in-time recovery (PITR) for RDS, which requires automated backups (daily full snapshot + transaction logs) and not just manual snapshots.
Definition matching: 'Which AWS service provides a central place to define backup policies across multiple AWS services?' Answer: AWS Backup.
Cost optimisation: 'What is the cheapest way to retain backups for 7 years for compliance?' Answer: Archive backups to Amazon S3 Glacier Deep Archive via AWS Backup, using lifecycle policies.
Exam traps:
Beware of questions that say 'manual snapshot' when they really want point-in-time recovery or automated backups. Manual snapshots do not support point-in-time restore.
They love testing that AWS Backup Vault Lock in compliance mode prevents deletion by any user, including root—which is different from governance mode where locks can be removed.
They might ask: 'Should you store backups in the same Availability Zone as the production resource?' No—that defeats the purpose because an AZ failure would destroy both. Always store in a different AZ (within the same Region) or cross-Region.
Another trap: 'Can you restore an EBS snapshot to a different size instance?' Yes, but you must first create a volume from the snapshot, then you can launch an instance of any size that the volume supports.
Key definitions to memorise:
Snapshot: point-in-time copy of an EBS volume or RDS database. Not automatically created unless you configure it.
AMI: an image of an EC2 instance that includes the operating system, applications, and data. You can create an AMI from an EBS snapshot.
Backup vault: stores recovery points. Can have an optional lock.
Backup plan: specifies when and how often to take backups, retention period, and vault.
Recovery Point Objective (RPO): maximum acceptable data loss in time.
Recovery Time Objective (RTO): maximum acceptable downtime.
A specific exam pattern: they give you a table of backup costs. You must calculate the total cost of monthly snapshots given a certain retention period. Remember that EBS snapshot costs are based on the size of the changed blocks (incremental) and not the whole volume. The first snapshot is full-size; subsequent snapshots only charge for data that changed.
Another common question: 'A company wants to automate backups of EC2 instances, RDS databases, and EFS file systems from a single console. Which service should they use?' The answer is AWS Backup—not an EC2 instance scheduler or a cron job on a management server.
Finally, know that AWS Backup integrates with AWS Organizations, so you can define a backup policy that applies to all accounts in your organisation. This is a governance feature that the exam may present as a way to enforce compliance without needing a separate backup tool per account.
AWS Backup is the central managed service to automate backup scheduling, retention, and cross-region copying across EC2, RDS, EFS, and other AWS services.
A manual snapshot is a point-in-time copy you create on demand; it lacks automation, built-in monitoring, and lifecycle management, making it suitable for occasional backups before risky changes.
Recovery Point Objective (RPO) defines the maximum acceptable data loss measured in time; it directly dictates how frequently you must take backups.
Recovery Time Objective (RTO) defines the maximum acceptable downtime; it drives how fast your restore process must be, including spinning up new resources and validating data.
AWS Backup Vault Lock in compliance mode prevents deletion of backups by any user (including root) until the retention period expires, offering ransomware protection.
Restoring an RDS snapshot always creates a new database instance; you cannot restore into an existing running database without replacing it.
Cross-region backup copies backups to a different AWS Region for disaster recovery, but incurs data transfer costs and takes time proportional to the snapshot size.
Always test your restores periodically in a non-production environment to ensure backups are valid and your RTO is achievable.
These come up on the exam all the time. Here's how to tell them apart.
AWS Backup (Managed)
Centralised backup plans with scheduling, retention, and cross-region copying
Supports AWS Backup Vault Lock to prevent deletion
Integrates with AWS Organizations for cross-account governance
Manual Snapshots
Created on demand via console, CLI, or SDK
No built-in lifecycle management—must manually delete
No central dashboard; you monitor each resource individually
EBS Snapshot (Volume Level)
Captures data on a single EBS volume at a point in time
Must attach to an EC2 instance to restore data
No OS or boot configuration included
AMI (Image Level)
Captures the entire EC2 instance including OS, software, and volume data
Can launch a new instance directly from the AMI
Includes launch permissions and block device mappings
Recovery Point Objective (RPO)
Maximum acceptable data loss measured in time (e.g., 1 hour)
Drives backup frequency (e.g., hourly snapshots)
Lower RPO = more frequent backups = higher cost
Recovery Time Objective (RTO)
Maximum acceptable downtime (e.g., 4 hours)
Drives restore speed and automation (e.g., pre-provisioned resources)
Lower RTO = faster restore process = higher infrastructure cost
Cross-Region Backup
Copies backup to a different AWS Region
Protects against an entire Region becoming unavailable
Incurs data transfer costs between Regions
Cross-Account Backup
Copies backup to a different AWS account
Protects against accidental deletion or account compromise
No cross-Region data transfer within the same Region
Mistake
If I take a manual snapshot of an EC2 instance using the console, that automatically backs up the instance’s entire state including memory and running applications.
Correct
An EBS snapshot only captures the data that has been written to the attached EBS volumes—it does not capture the instance's RAM, CPU state, or any in-memory data. To get a consistent snapshot, you should stop the instance or use the 'No Reboot' option, but that risks file system inconsistency if applications are writing at that moment.
People assume 'snapshot' means a full copy of everything running, like a sleep-mode image on a laptop. Cloud snapshots are volume-level, not instance-level.
Mistake
AWS Backup is exactly the same as taking manual snapshots, just with a nicer interface.
Correct
AWS Backup is a managed service that automates scheduling, retention, cross-region copies, and monitoring. Manual snapshots require you to manage all of that yourself. AWS Backup also integrates with AWS Backup Vault Lock and supports more services out of the box.
Beginners confuse 'managed' with 'manual' because they see both create snapshots. The difference is automation and governance, not just the output.
Mistake
If you delete a manual snapshot, you can still restore from it as long as there is another copy in a different Region.
Correct
Deleting a snapshot permanently removes all its data. Copying a snapshot to another Region creates a separate snapshot; if you delete the source, the copy still exists. But there is no 'undelete'. You must keep at least one copy to restore from.
People think cloud storage works like a recycle bin. AWS snapshots are not recoverable once deleted unless you have a separate copy in another Region/account.
Mistake
You can restore an RDS snapshot directly into the existing RDS instance without creating a new one.
Correct
Restoring an RDS snapshot always creates a new DB instance. You can then manually rename or point your application to the new instance. You cannot overwrite an existing running database with a snapshot restore.
Users expect an 'overwrite' option similar to a local file save. AWS intentionally prevents this to avoid accidental data loss during restore.
Mistake
Cross-region backup with AWS Backup happens instantly and does not cost anything extra.
Correct
Cross-region backup copies data between Regions, which incurs data transfer costs (per GB) and storage costs in the destination Region. The copy also takes time proportional to the snapshot size.
New users often underestimate cloud data transfer costs and assume that moving data within the same provider is free. Cross-region is a paid feature.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A manual snapshot is created on demand via the console or CLI—you control timing, deletion, and retention yourself. An AWS Backup managed backup is automated through a backup plan, which handles scheduling, retention, cross-region copying, and central monitoring. AWS Backup also supports vault lock and is easier to audit.
Not necessarily, but stopping the instance ensures a consistent file system state. If you take a snapshot while the instance is running ('hot snapshot'), the snapshot captures data that has already been written to disk, but any in-memory data or recent writes still in the OS cache may be lost. For database servers, stopping the instance (or using EBS multi-volume snapshots) is recommended.
You can create a new volume from the snapshot, attach it to an EC2 instance (like a temporary management instance), mount the volume, and copy the specific file you need. For Amazon EFS, AWS Backup supports granular file-level restore from the console directly.
PITR allows you to restore an RDS database to any second within the retention period (up to 35 days). It requires automated backups to be enabled, which take daily snapshots and transaction logs. You cannot do PITR from manual snapshots—those are fixed points in time.
Go to the EBS Snapshots section of the EC2 console (or the Snapshots section under RDS for database snapshots), select the snapshot, and choose 'Delete'. Manual snapshots are not deleted automatically—you must manage their lifecycle. AWS Backup automatically deletes snapshots based on the retention period you set in the backup plan.
Yes, you can share EBS snapshots with other AWS accounts by modifying the snapshot permissions. For RDS snapshots, you can share them manually or use AWS Backup cross-account backup features. Shared snapshots cannot be made public for security reasons.
You've just covered Backup and Restore Practices — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?