Wondering how to perform aws elasticache redis backup and restore? Our AWS Support team is here to lend a hand with your queries and issues.

AWS elasticache redis backup and restore

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 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 select 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 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.

Today, let us see the steps followed by support techs to perform aws elasticache redis backup and restore

Backup constraints

Consider the following constraints when planning or making backups:

• At this time, backup and restore are support only for clusters running on Redis.
• For Redis clusters, backup and restore aren’t support on cache.t1.micro nodes. All other cache node types are support.
• For Redis clusters, backup and restore are support for all node types.
• During any contiguous 24-hour period, you can create no more than 20 manual backups per node in the cluster.
• Redis only supports taking backups on the cluster level. Redis doesn’t support taking backups at the shard level.
• During the backup process, you can’t run any other API or CLI operations on the cluster.
• If using clusters 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.

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.

And 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 aws elasticache redis backup and restore.

• Set the reserved-memory-percent parameter – To mitigate excessive paging, we recommend that you set the reserved-memory-percent parameter. This parameter prevents Redis from consuming all of the node’s available memory, and can help reduce the amount of paging.
• 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 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.