Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Backup and restore for ElastiCache for Redis

Amazon ElastiCache clusters running Redis can back up their data. You can use the backup to restore a cluster or seed a new cluster. The backup consists of the cluster's metadata, along with all of the data in the cluster. All backups are written to Amazon Simple Storage Service (Amazon S3), which provides durable storage. At any time, you can restore your data by creating a new Redis cluster and populating it with data from a backup. With ElastiCache, you can manage backups using the Amazon Web Services Management Console, the Amazon Command Line Interface (Amazon CLI), and the ElastiCache API.

Beginning with Redis version 2.8.22, the backup method is selected based upon available memory. If there is sufficient available memory, a child process is spawned that writes all changes to the cache's reserved memory while the cache is being backed up. Depending on the number of writes to the cache during the backup process, this child process can consume all reserved memory, causing the backup to fail.

If there is insufficient memory available, a forkless, cooperative background process is employed. The forkless method can affect both latency and throughput. For more information, see How synchronization and backup are implemented.

For more information about the performance impact of the backup process, see Performance impact of backups.

Following, you can find an overview of working with backup and restore.

Backup constraints

Consider the following constraints when planning or making backups:

Backup costs

Using ElastiCache, you can store one backup for each active Redis cluster free of charge. Storage space for additional backups is charged at a rate of $0.085/GB per month for all Amazon Regions. There are no data transfer fees for creating a backup, or for restoring data from a backup to a Redis cluster.

Performance impact of backups

The backup process depends upon which Redis version you're running. Beginning with Redis 2.8.22, the process is forkless.

Backups when running Redis 2.8.22 and later

In versions 2.8.22 and later, Redis backups choose between two methods. If there isn't enough memory to support a forked backup, ElastiCache use a forkless method that uses cooperative background processing. If there is enough memory to support a forked save process, the same process is used as in earlier Redis versions.

If the write load is high during a forkless backup, writes to the cache are delayed. This delay makes sure that you don't accumulate too many changes and thus prevent a successful backup.

Backups when running Redis versions before 2.8.22

Backups are created using Redis' native BGSAVE operation. The Redis process on the cache node spawns a child process to write all the data from the cache to a Redis .rdb file. It can take up to 10 seconds to spawn the child process. During this time, the parent process is unable to accept incoming application requests. After the child process is running independently, the parent process resumes normal operations. The child process exits when the backup operation is complete.

While the backup is being written, additional cache node memory is used for new writes. If this additional memory usage exceeds the node's available memory, processing can become slow due to excessive paging, or fail.

Improving backup performance

The following are guidelines for improving backup performance.

If you delete a replication group and request a final backup, ElastiCache always takes the backup from the primary node. This ensures that you capture the very latest Redis data, before the replication group is deleted.