DEV Community

Naoki
Naoki

Posted on

Introduction to AWS Backup Design | EBS Snapshots, RPO, and RTO

Introduction to AWS Backup Design | EBS Snapshots, RPO, and RTO

When designing backups on AWS, simply deciding to "create a snapshot every day" is not enough.

How much data loss can you tolerate in the event of a failure?
How quickly does the service need to be restored?

Defining these two requirements makes it easier to determine backup frequency and recovery methods.

What Is a Backup in AWS?

A backup is a copy of data that can be used to restore the original data if it is lost or becomes unavailable.

For example, you can create snapshots of EBS volumes attached to EC2 instances.

EC2
  ↓
Uses an EBS volume
  ↓
Create an EBS snapshot
  ↓
Restore when needed
Enter fullscreen mode Exit fullscreen mode

However, creating a backup is not the same as being able to restore the service.

You also need to attach the restored volume to an EC2 instance and verify that the application works correctly.

Difference Between Backups and Snapshots

A backup is a general term for storing data so that it can be restored later.

A snapshot is one method used to create a backup.

Term Meaning
Backup Storing data so that it can be restored
EBS Snapshot A point-in-time copy of an EBS volume
AWS Backup An AWS service for managing backup creation and retention

For example, when backing up an EBS volume, you can create an EBS snapshot.

You can also use AWS Backup to manage the scheduled creation of EBS snapshots.

In other words, AWS Backup and EBS snapshots are not mutually exclusive options.

Why Are Backups Necessary?

Data loss is not caused only by server failures.

  • Accidental file deletion
  • Data corruption caused by application bugs
  • Failed updates
  • Unauthorized operations
  • Preparation for Region-level failures

For example, if an application writes incorrect data to an EBS volume, a backup can help you restore the data to an earlier point in time.

RPO and RTO in Backup Design

When designing a backup strategy, start by defining the RPO and RTO.

Term What to Define
RPO How much data loss is acceptable
RTO How quickly the service must be restored

The AWS Well-Architected Framework also recommends defining RPO and RTO for each workload.

What Is RPO?

RPO stands for Recovery Point Objective.

It defines how far back in time you need to be able to restore data after a failure.

For example, if the requirement allows a maximum of 24 hours of data loss, the RPO is 24 hours.

What Is RTO?

RTO stands for Recovery Time Objective.

It defines how quickly the service must be restored after a failure occurs.

For example, if the application must be available again within four hours, the RTO is four hours.

Example of RPO and RTO

Suppose a backup is created every day at 2:00 a.m., and a failure occurs at 1:00 a.m. the following day.

If the latest usable backup is the one created at 2:00 a.m. the previous day, up to approximately 23 hours of updates may be lost.

2:00 a.m.
Backup created
  ↓
About 23 hours later
Failure occurs
  ↓
Restore data to the 2:00 a.m. state
Enter fullscreen mode Exit fullscreen mode

RTO, on the other hand, is not about which point in time you restore the data to.

It is about how long it takes until the application becomes available again after recovery.

What Is an EBS Snapshot?

An EBS snapshot is a point-in-time copy of an EBS volume.

You can create a new EBS volume from a snapshot.

Relationship Between EC2, EBS, and Snapshots

EC2 provides virtual servers for running applications and other workloads.

EBS provides storage that can be attached to EC2 instances.

EBS volumes are the resources that EBS snapshots back up.

EC2
  ↓ Attached and used by
EBS Volume
  ↓ Backed up as
EBS Snapshot
Enter fullscreen mode Exit fullscreen mode

Creating an EBS snapshot does not automatically back up all EC2 settings or data stored in external databases.

You need to identify everything required to restore the entire service.

EBS Snapshots Are Incremental

The first snapshot of an EBS volume contains the data blocks that need to be stored.

Subsequent snapshots are incremental by default.
Only blocks that have changed or been added since the previous snapshot need to be stored.

First snapshot
  ↓
Stores the required data blocks

Next snapshot
  ↓
Stores changed or added blocks
Enter fullscreen mode Exit fullscreen mode

Even though snapshots are stored incrementally, each snapshot can be used to restore the volume to its state at that point in time.

How Restoration from an EBS Snapshot Works

Select an EBS snapshot and create a new EBS volume from it.

Then attach the new volume to an EC2 instance and verify the data and application behavior.

EBS Snapshot
  ↓
Create a new EBS volume
  ↓
Attach it to EC2
  ↓
Verify the data and application
Enter fullscreen mode Exit fullscreen mode

Volumes created from snapshots may experience performance impact during the initial data reads.
The actual recovery time should be tested in advance.

EBS restore settings screen from the official AWS documentation

Image: Example restore screen from the official AWS documentation.
You specify the settings for the EBS volume created from the snapshot.
The screen may change over time.

Determine Snapshot Frequency Based on RPO

The frequency of snapshots should be determined based on the amount of data loss you can tolerate.

Taking a Snapshot Once a Day

For example, suppose a snapshot is created every day at 2:00 a.m.

Depending on when a failure occurs, you may lose almost an entire day of updates since the previous backup.

Daily backups can be considered for systems that can tolerate approximately one day of data loss.

Taking a Snapshot Every Hour

Creating backups every hour provides more recent recovery points than daily backups.

However, simply scheduling hourly backups does not guarantee that the RPO will be met.

You also need to monitor whether backups are completing successfully and identify the latest recoverable point.

Increasing backup frequency also affects storage usage and cost.

Consider the Snapshot Retention Period

In addition to backup frequency, you need to decide how long backups should be retained.

Problems are not always discovered immediately.
If an incorrect update is discovered several days later, keeping only the latest snapshot may not be enough.

How Many Generations Should Be Retained?

For example, if you create a backup every day and retain backups for seven days, you maintain recovery points covering approximately the previous week.

Create a backup every day
  ↓
Retain for 7 days
  ↓
Delete backups after the retention period
Enter fullscreen mode Exit fullscreen mode

The required retention period depends on how long it may take to discover a problem and on your organization's data retention requirements.

What Should You Do with Old Snapshots?

If snapshots are created manually without a retention policy, old snapshots may accumulate, making management and cost tracking more difficult.

AWS Backup and Amazon Data Lifecycle Manager allow you to configure creation schedules and retention periods.

Incremental snapshots share data blocks.
Deleting an old snapshot therefore does not necessarily reduce storage costs by the proportion you might expect.

What Is AWS Backup?

AWS Backup is a service for centrally managing backup plans for AWS resources.

A backup plan can define settings such as backup frequency, storage destination, and retention period.
After assigning resources to the plan, backups are performed according to the configured rules.

AWS Backup rule configuration screen from the official AWS documentation

Image: Example configuration screen from the official AWS documentation.
You can configure backup frequency and retention periods.
The screen may change over time.

Difference Between AWS Backup and EBS Snapshots

An EBS snapshot is a backup used to restore an EBS volume.

AWS Backup is a service for managing when backups are created, how long they are retained, and which resources are included.

When AWS Backup is used to back up EBS volumes, it also uses EBS snapshots.

Managing Multiple AWS Resources Together

AWS Backup can assign supported AWS resources other than EBS to backup plans.

For example, you can consider managing backup policies for EC2 EBS volumes and RDS through AWS Backup.

However, recovery procedures differ depending on the resource type.
The recovery procedure for EBS cannot be used to restore RDS.

Example of an AWS Backup Design

Consider a system where an application runs on EC2 and stores required data on EBS.

Requirement / Setting Example
RPO 24 hours
RTO 4 hours
Backup frequency Once a day
Retention period 7 days
Recovery testing Performed regularly

The design process looks like this:

Allow up to 24 hours of data loss
  ↓
Consider daily backups
  ↓
Retain backups for 7 days
  ↓
Verify backup success and recovery procedures
Enter fullscreen mode Exit fullscreen mode

In this example, simply configuring daily backups does not guarantee that the four-hour RTO can be achieved.

You need to test the creation of a new EBS volume, attachment to EC2, application startup, and application behavior to confirm that the entire recovery process can be completed within four hours.

If the database is stored separately in RDS, EBS snapshots alone cannot protect the database data.

You also need to design backup and recovery procedures for RDS.

Summary

A backup is a general term for storing data so that it can be restored later.
An EBS snapshot is one method for backing up EBS volumes.

When designing a backup strategy, start by defining the RPO and RTO.

Use the RPO to determine backup frequency, and consider how long it may take to discover a problem when deciding the retention period.

Finally, perform an actual recovery test and confirm how long it takes to restore the service.

Top comments (0)