Snapshot and restore - Amazon ElastiCache (Redis OSS)

Snapshot and restore

Amazon ElastiCache caches running Redis OSS can back up their data by creating a snapshot. You can use the backup to restore a cache or seed data to a new cache. The backup consists of the cache’s metadata, along with all of the data in the cache. 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 OSS cache and populating it with data from a backup. With ElastiCache, you can manage backups using the AWS Management Console, the AWS Command Line Interface (AWS CLI), and the ElastiCache API.

If you plan to delete a cache and it's important to preserve the data, you can take an extra precaution. To do this, create a manual backup first, verify that its status is available, and then delete the cache. Doing this makes sure that if the backup fails, you still have the cache data available. You can retry making a backup, following the best practices outlined preceding.

Backup constraints

Consider the following constraints when planning or making backups:

  • Backup and restore are supported only for caches running on Redis OSS or Serverless Memcached.

  • For Redis OSS (cluster mode disabled) clusters, backup and restore aren't supported on cache.t1.micro nodes. All other cache node types are supported.

  • For Redis OSS (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 24 manual backups per serverless cache. For Redis OSS self-designed clusters, you can create no more than 20 manual backups per node in the cluster.

  • Redis OSS (cluster mode enabled) only supports taking backups on the cluster level (for the API or CLI, the replication group level). Redis OSS (cluster mode enabled) doesn't support taking backups at the shard level (for the API or CLI, the node group level).

  • During the backup process, you can't run any other API or CLI operations on serverless cache. You can run API or CLI operations on a self-designed cluster during backup.

  • If using caches with data tiering, you cannot export a backup to Amazon S3.

  • You can restore a backup of a cluster using the r6gd node type only to clusters using the r6gd node type.

Performance impact of backups of self-designed clusters

Backups on serverless caches are transparent to the application with no performance impact. However, when creating backups for self-designing clusters, there can be some performance impact depending on the available reserved memory. Self-designed clusters are not available with ElastiCache and Memcached, but are available with ElastiCache and Redis OSS.

The following are guidelines for improving backup performance for self-designed clusters.

  • Set the reserved-memory-percent parameter – To mitigate excessive paging, we recommend that you set the reserved-memory-percent parameter. This parameter prevents Redis OSS 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 and reserved-memory-percent parameters, see Managing Reserved Memory.

     

  • Create backups from a read replica – If you are running Redis OSS 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 BGSAVE, we recommend that you create backups from one of the read replicas. While the backup is being created from the replica, the primary node remains unaffected by BGSAVE resource requirements. The primary node can continue serving requests without slowing down.

    To do this, see Creating a manual backup (Console) and in the Cluster Name field in the Create Backup window, choose a replica instead of the default primary node.

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 OSS data, before the replication group is deleted.