ElastiCache Backup and Restore (Redis)
Amazon ElastiCache clusters running Redis can back up their data. The backup can be used 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. ElastiCache lets you manage backups using the AWS Management Console, the AWS Command Line Interface (AWS 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 which writes all changes to the
cache's reserved memory while the cache is being backed up.
This child process could, depending on the number of writes to the cache during the backup process,
reserved memory, causing the backup to fail.
If there is insufficient memory available, a forkless, cooperative background process is employed. The forkless method can impact 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.
This section provides an overview of working with backup and restore.
- Performance Impact of Backups
- Scheduling Automatic Backups
- Taking Manual Backups
- Taking a Final Backup
- Describing Backups
- Copying a Backup
- Exporting a Backup
- Restoring From a Backup with Cluster Resizing
- Seeding a New Cluster with an Externally Created Backup (Redis)
- Tagging Backups
- Deleting a Backup
- Redis Append Only Files (AOF)
The following constraints should be considered when planning or making backups:
At this time, backup and restore are supported only for clusters running on Redis.
Backup and restore are not supported on
cache.t2.*nodes for Redis (cluster mode disabled) clusters. All other cache node types are supported.
For Redis (cluster mode enabled) clusters, backup and restore are supported for all node types.
During any contiguous 24-hour period, you can create no more than 20 manual backups per cluster.
Redis (cluster mode enabled) only supports taking backups on the cluster level (for the API or CLI, the replication group level), not at the shard level (for the API or CLI, the node group level).
During the backup process you cannot perform any additional API or CLI operations on the cluster.
ElastiCache allows you to 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 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
Redis backups, in versions 2.8.22 and later, choose between two backup methods. If there is insufficient memory to support a forked backup, ElastiCache use a forkless method that employs cooperative background processing. If there is sufficient memory to support a forked save process, the same process as in prior Redis versions is employed.
If the write load is high during a forkless backup, writes to the cache are delayed to ensure that you don't accumulate too many changes and thus prevent a successful backup.
Backups when running Redis versions prior to 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 ten seconds to spawn the child process, and 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.
The following are guidelines for improving backing up performance.
Set the reserved-memory parameter—To mitigate excessive paging, we recommend that you set the reserved-memory parameter. This parameter prevents Redis from consuming all of the node's available memory, and can help reduce the amount of paging. You might also see performance improvements by simply using a larger node. For more information about the reserved-memory parameter and node memory sizes, see Redis Specific Parameters.
Create backups from a read replica—If you are running Redis in a node group with more than one node, you can take a backup from the primary node or one of the read replicas. Because of the system resources required during a BGSAVE, we recommend that you create backups from one of the read replicas, rather than the primary. While the backup is being created from the replica, the primary node remains unaffected by BGSAVE resource requirements, and can continue serving requests without slowing down.
If you delete a replication group and request a final backup, ElastiCache will always take the backup from the primary node. This ensures that you capture the very latest Redis data, before the replication group is deleted.