Redis Enterprise

Redis Enterprise Technology

Backup and Disaster Recovery

In addition to data persistence functionality, Redis Enterprise provides out-of-the-box support for backup and restore services.


Redis Enterprise allows you to backup a snapshot of your database (across all shards) to any major public cloud storage solutions (AWS S3, Azure Blob Storage or Google Cloud Storage) as well as any FTP or Swift services.  Before executing the snapshot, Redis Enterprise confirms that there are no outstanding requests in the cluster, thus ensuring consistency. The following figure illustrates the backup process:



The restore process is useful in the following cases:

  • If you have lost all in-memory copy(ies) of your data as well as your data persistence files (Note: The likelihood of this scenario is very low if you have deployed Redis Enterprise in a multi-AZ manner with replication and data persistence enabled)
  • When you need to regress your dataset

Note: In this second case, you can return to a previous point in time seamlessly by creating a second database, importing data and switching endpoints once the data loading is complete. This ensures that you can continue to access your data even while the backup is being loaded.

Cluster Recovery

Cluster Recovery is an independent tool that launches Redis Enterprise cluster from scratch in cases where the cluster reaches an irrecoverable state—when a majority of the cluster nodes are down, for instance. If you use Redis Enterprise as a fully managed service in the cloud (Hosted or VPC), the cluster recovery process is executed automatically and governed by our DevOps team. If you deploy Redis Enterprise cluster, you should control the recovery process yourself. An irrecoverable cluster state is rare, especially if the cluster is deployed in a multi-AZ manner. That said, in order to avoid downtime in these situations we recommend that you use Active-Passive or Active-Active geo-distribution deployment.  

The cluster recovery process is based on the information written in the cluster Common Cluster Storage (CCS) file—which is constantly being backed up during the operation of the cluster—and includes the following steps:

1. Rebuild the cluster, nodes and storage



2. Transfer backup files to local/persistent storage



3. Load the backup files to RAM



4. Create replicas and start opening the cluster



Next Section  ►  Active-Passive Geo Distribution