A Redis backup comes down to two files: the RDB snapshot and the append-only log. Every method on every platform builds on them. The commands are the easy half, since restores usually fail on sequencing, retention caps, and snapshots nobody can find.
How persistence powers every Redis backup
Redis persistence writes the in-memory dataset to durable storage so it survives a restart, a crash, or a lost node. There are two mechanisms:
RDB snapshots capture point-in-time state
RDB persistence writes a compact, point-in-time snapshot of the full dataset to a single binary file, dump.rdb. Redis produces it by forking a child process, so the parent keeps serving requests without touching the disk.
You set the cadence with save points: save 60 1000, for instance, tells Redis to write a snapshot once a minute whenever 1,000 or more keys have changed.
RDB files restart quickly on large datasets and travel well to remote storage. The tradeoff is data loss between snapshots. If Redis dies five minutes after the last save, those five minutes of writes are gone.
AOF logs every write, and when to combine both
AOF (append-only file) persistence logs every write command the server receives, then replays the log at startup to rebuild the dataset.
With the default appendfsync everysec policy, you lose at most one second of writes in a crash.
Since Redis 7.0, the AOF is split into a base file plus incremental files inside a dedicated directory.
Running both gives you durability comparable to a conventional database: RDB as the portable artifact, AOF to narrow the loss window between snapshots.
What you'll need before starting
Prerequisites:
- redis-cli and shell access to the server for self-managed instances, or the aws, gcloud, or az CLI with backup permissions for managed services
- An object storage bucket (S3, Cloud Storage, or Blob Storage) in the same region as the instance
- Enough free memory on the host for the BGSAVE fork, which can briefly double memory pressure on large datasets
- Your persistence mode confirmed with redis-cli CONFIG GET appendonly
Time required: 15–30 minutes for a first backup plus a test restore. Large datasets extend the snapshot and transfer time.
How to back up self-managed Redis, step by step
The RDB file is the backup artifact. Disks fail and cloud instances disappear, so offsite copies are crucial.
Step 1: Locate your data directory and persistence mode
Ask the running server where its files live and how it persists.
redis-cli CONFIG GET dir # data directory, often /var/lib/redis
redis-cli CONFIG GET dbfilename # snapshot filename, usually dump.rdb
redis-cli CONFIG GET appendonly # "yes" means AOF is on
Every later step depends on these three values, and guessing them is how restores end up pointed at the wrong file.
Pro tip: Run redis-cli INFO persistence too. It reports the last save time, which tells you how stale your current snapshot already is.
Step 2: Trigger a fresh snapshot with BGSAVE
Run redis-cli BGSAVE to fork a background save. The child process writes the dataset to a temporary file, then atomically renames it into place as dump.rdb, which is why copying the file while the server runs is safe.
redis-cli BGSAVE
redis-cli INFO persistence | grep -E "rdb_bgsave_in_progress|rdb_last_bgsave_status"
# rdb_bgsave_in_progress:0 and rdb_last_bgsave_status:ok mean the snapshot is ready
This gives you a current recovery point instead of whatever the last scheduled save left behind.
Pro tip: On a busy primary, point your backup job at a replica. The fork happens there, and the primary never feels it.
Step 3: Copy the AOF directory while rewrites are paused
Skip this step if appendonly returned no. Since Redis 7.0 the AOF lives as multiple files in one directory, and copying that directory during a background rewrite produces an invalid backup. Pause rewrites first.
redis-cli CONFIG SET auto-aof-rewrite-percentage 0
redis-cli INFO persistence | grep aof_rewrite_in_progress # wait for 0
cp -r /var/lib/redis/appendonlydir /backups/redis/aof-$(date +%F)
redis-cli CONFIG SET auto-aof-rewrite-percentage 100 # restore your previous value
Hard-link the files instead of copying, re-enable rewrites immediately, then copy the hard links at leisure. It shrinks the paused window to seconds.
Step 4: Verify the file and ship a copy off the host
Check the snapshot with redis-check-rdb, the integrity tool that ships with Redis, then move an encrypted copy somewhere the host cannot touch. Ship at least one snapshot per day off the physical machine, with S3 or equivalent as the destination.
redis-check-rdb /var/lib/redis/dump.rdb
aws s3 cp /var/lib/redis/dump.rdb \
s3://my-redis-backups/prod/dump-$(date +%F-%H%M).rdb --sse aws:kms
Cron this hourly, keep 48 hourly copies and 30 daily copies, and put the date in every filename. Verify the transferred file size matches the source after every upload.
How to back up managed Redis on AWS, Google Cloud, and Azure
Managed Redis services all converge on the same model. The platform produces a native RDB snapshot, you export it to object storage, and restores rebuild a new instance from that file.
Amazon ElastiCache, automatic snapshots and S3 export
ElastiCache writes automatic daily backups to S3-backed storage with a retention limit of up to 35 days, and setting the limit to 0 turns automatic backups off. Manual snapshots never expire and are the right move before a risky deployment.
# Schedule daily automatic backups with 7-day retention
aws elasticache modify-replication-group \
--replication-group-id my-redis \
--snapshot-retention-limit 7 \
--snapshot-window 03:00-04:00 \
--apply-immediately
# Take a manual snapshot before a risky change
aws elasticache create-snapshot \
--replication-group-id my-redis \
--snapshot-name pre-migration-2026-07-21
To hold a snapshot past 35 days or move it across accounts, export it to your own S3 bucket. Node-based clusters use copy-snapshot with a target bucket, and serverless caches use a dedicated export operation.
# Node-based cluster: export to your own S3 bucket
aws elasticache copy-snapshot \
--source-snapshot-name pre-migration-2026-07-21 \
--target-snapshot-name pre-migration-2026-07-21-export \
--target-bucket my-redis-backups
# Serverless cache: export a snapshot to S3
aws elasticache export-serverless-cache-snapshot \
--serverless-cache-snapshot-name automatic.my-redis-2026-07-20 \
--s3-bucket-name my-redis-backups
The bucket must sit in the same region as the snapshot, with ElastiCache granted read and write access. Clusters on data-tiering (r6gd) node types cannot export backups to S3 at all.
Google Memorystore, export RDB to Cloud Storage
Memorystore for Redis (BasIc/Standard) has no scheduled backup setting. Instead it exports the instance as an RDB file to a Cloud Storage bucket on demand, using the same mechanism as BGSAVE.
gcloud redis instances export \
gs://my-redis-backups/prod-cache-$(date +%F).rdb \
prod-cache --region=us-central1
Grant the account running the export (your user or service account) Storage write access to the bucket first, and expect temporarily slower performance during the export. Admin operations like scaling stay locked until it finishes. Wire the export into Cloud Scheduler for recurring backups.
Azure Cache for Redis, export on Premium and Enterprise tiers
Azure separates durability from backup. The persistence feature writes snapshots for automatic recovery after a failure, while the import/export feature produces the portable RDB files you keep as periodic backups.
Export requires a Premium, Enterprise, or Enterprise Flash cache and lands the RDB in a Blob Storage container.
az redis export \
--name my-cache \
--resource-group my-rg \
--prefix redis-backup-$(date +%F) \
--container "<blob-container-SAS-URL>" \
--file-format rdb
The Premium tier's persistence file also sits in Azure Storage, but you cannot import it into a different cache, so treat exports as the real backup artifact.
Redis Cloud, backups by plan tier
Redis Cloud gates backup on plan. Pro subscriptions back up on demand and on schedules from 24 hours down to every hour; paid Essentials plans back up on demand and every 24 hours; and Free plans have no console backup at all.
Destinations include S3, Cloud Storage, Blob Storage, and FTPS, and a clustered database produces one RDB file per shard.
How to restore Redis data, step by step
Restores fail more often from sequencing than from bad files. Two behaviors cause most of the damage: Redis rewriting the snapshot at shutdown and AOF taking precedence over RDB at startup.
Step 1: Stop Redis before touching the data directory
Stop the service before you move any files into place.
sudo systemctl stop redis
With save points configured, Redis writes a fresh snapshot as it exits. Copy your backup in first, and that shutdown save overwrites it with the current, wrong dataset.
Pro tip: Copy the existing dump.rdb aside before replacing it. If the restore goes sideways, you can still return to the pre-restore state.
Step 2: Disable AOF so Redis loads your snapshot
When both persistence modes are enabled, Redis rebuilds from the AOF and never reads your restored RDB; the AOF wins at startup as the more complete file.
redis-cli CONFIG GET appendonly # if "yes", disable it before restoring
Set appendonly no in redis.conf while the server is down. Skipping this check is the most common reason a restored instance comes up empty.
Pro tip: An empty DBSIZE after a restore almost always means AOF was still enabled. Check this before assuming the backup file is bad.
Step 3: Place the backup file and fix ownership
Copy the backup into the data directory you recorded earlier, rename it to match dbfilename, and hand ownership to the Redis user.
cp /backups/redis/dump-2026-07-20.rdb /var/lib/redis/dump.rdb
chown redis:redis /var/lib/redis/dump.rdb
Redis only loads a file whose name and location match its configuration, and it refuses files it cannot read. Both failure modes end in a silently empty instance.
Run redis-check-rdb on the file one more time before starting the server. Thirty seconds here beats a failed startup loop.
Step 4: Start Redis and verify the data
Start the service and count the keys.
sudo systemctl start redis
redis-cli DBSIZE
redis-cli GET some-known-key
A key count in the expected range plus a spot-check of known keys confirms the restore.
If this instance should run AOF, convert it back on the live server. CONFIG SET appendonly yes starts an initial AOF rewrite that builds a new base file from the restored dataset in memory.
redis-cli CONFIG SET appendonly yes
redis-cli INFO persistence | grep -E "aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status"
# wait for both progress fields to read 0 and the status to read ok
redis-cli CONFIG REWRITE
CONFIG REWRITE writes the setting back to redis.conf so it survives a restart. Skip it and the server comes back up with AOF off, running unprotected against the loss window you turned AOF on to close.
The dangerous sequence is restarting with appendonly yes in the config while the pre-restore appendonlydir is still on disk. AOF takes precedence at startup, so Redis rebuilds from the stale log and the dataset you restored disappears.
Move the old directory aside before you enable AOF, and restart only once the rewrite reports ok.
Time the full sequence and put the number in your runbook.
Managed restore behavior varies by provider
Where the data lands differs across the three services, and that decides whether your recovery plan needs an endpoint cutover or a maintenance window.
ElastiCache restores a backup into a new cache. The original keeps serving traffic while the replacement warms, so the switch is a DNS or endpoint change once the new cache is ready.
Memorystore for Redis imports the RDB into an existing instance and replaces its entire dataset. Memorystore for Redis Cluster has no import path into a running cluster, so a backup there seeds a new cluster.
Azure Cache for Redis imports the RDB into an existing cache, and that cache stays unavailable until the operation finishes. Size the window against the dataset before you start.
# ElastiCache: restore a snapshot into a new serverless cache
aws elasticache create-serverless-cache \
--serverless-cache-name my-redis-restored \
--engine redis \
--snapshot-arns-to-restore <snapshot-ARN>
# Memorystore: import an RDB into an instance (replaces all data)
gcloud redis instances import \
gs://my-redis-backups/prod-cache-2026-07-20.rdb \
prod-cache-restored --region=us-central1
Version direction is strict on Memorystore, since an instance cannot import an RDB from a newer Redis version than its own.
Common mistakes to avoid
Most Redis restore failures are about sequencing, defaults, and where the backup lived when someone needed it.
- Restarting Redis before copying the RDB out: the shutdown save overwrites dump.rdb with current state, destroying the recovery point. Stop the service first, always.
- Leaving AOF enabled during an RDB restore: Redis rebuilds from the AOF and ignores the snapshot you placed, so the instance comes up with the wrong data. Disable AOF, restore, rewrite, re-enable.
- Copying the AOF directory mid-rewrite: the base and incremental files land in an inconsistent state and the backup will not load. Pause rewrites or hard-link first.
- Keeping the only copy in the production account: credentials that can delete production can delete the backup beside it. In the PocketOS incident, an AI coding agent deleted a production database and its attached backups in nine seconds.
- Treating the 35-day ElastiCache cap as an archive: automatic snapshots expire on schedule, and compliance requests routinely reach further back. Export what you must keep to your own bucket.
- Backing up without ever restoring: an unverified backup is a hypothesis. Restore into a scratch instance monthly and time it.
Managing Redis backups at cloud scale
The commands above solve one instance. Operating fifty Redis nodes across accounts and clouds raises different questions such as, which snapshots exist, who can reach them, and what they cost.
Govern exported snapshots with the same rules as source data
Every export lands an RDB file in an S3 or Cloud Storage bucket, and those buckets rarely inherit the retention and protection rules the source data deserved.
Eon's Cloud Backup Posture Management (CBPM) classifies cloud resources automatically and applies backup policy without manual tagging, covering the EC2 instances and EBS volumes that host self-managed Redis along with the buckets where managed exports accumulate.
Eon protects the infrastructure around Redis, while the managed cache engines themselves stay on their native snapshot tooling.
Keep one copy outside the blast radius
Coverage is only half of it. The PocketOS deletion worked because production credentials could reach the backups, so the fix is a copy in a vault those identities cannot touch.
Eon stores backups in a logically air-gapped, immutable vault in a separate account, so a compromised credential or a misbehaving agent hits a wall before your last recovery point.
Recover a single file without rebuilding the host
When Redis runs on EC2, Compute Engine, or EKS, the persistence files ride inside the instance, and volume backups and native tooling make you restore the whole volume to retrieve one file.
Eon's Granular Restoration pulls an individual dump.rdb or AOF directory straight out of the snapshot, so seeding a replacement instance skips the volume rebuild.
On EKS, Eon backs up Kubernetes secrets and EBS-backed persistent volumes, which covers the standard self-hosted Redis pattern.
Cut the cost of snapshot sprawl
Hourly RDB exports multiplied across instances and regions become a real line item, and per-snapshot pricing punishes exactly the cadence good recovery points require.
Deduplication across the environment lowers that cost: NETGEAR cut its backup storage 35% after moving to Eon, and Innago cut its AWS backup spend 40% across an environment spanning EKS and EC2.
What a working Redis backup strategy looks like
A working Redis backup strategy fits in four commitments. Match persistence mode to your durability target, keep one verified copy outside the production account, restore on a schedule instead of on faith, and set retention by what the data is worth. The commands above get a single instance there in an afternoon.
Across a fleet spread over a dozen accounts, the bottleneck shifts from commands to inventory. Exports pile up in buckets nobody owns, and coverage gaps stay invisible until a restore is already needed.
Knowing which Redis hosts are covered and where every export lives is the part that takes real work.
Want that answer for your environment? Get a demo and see how Eon maps coverage across every account, flags unowned exports, and restores a single file without a volume rebuild.
Frequently asked questions
How often should I back up Redis?
You should back up Redis as often as your tolerance for data loss allows. Hourly RDB snapshots with daily offsite copies suit most production workloads, and enabling AOF alongside RDB narrows the loss window between snapshots to about one second of writes.
Is RDB or AOF better for backups?
RDB is better for backups, and AOF is better for durability. The RDB file is a compact, portable, point-in-time artifact you can copy and archive, while the AOF minimizes data loss between snapshots. Redis recommends running both for production data you care about.
Does ElastiCache back up Redis automatically?
Yes, ElastiCache backs up Redis automatically once you set a snapshot retention limit above zero. Automatic snapshots run daily in a window you choose and persist up to 35 days, while manual snapshots never expire and S3 exports let you keep history indefinitely.
Can you restore a single Redis key from a backup?
No, standard Redis backups restore at the instance level only. An RDB file loads as a complete dataset, and managed services rebuild an entire new instance from it, so recovering one key means restoring into a scratch instance and copying the key out manually.
Where should Redis backups be stored?
Redis backups should be stored in at least two places, one copy near the instance for fast restores and one encrypted copy in a separate account or region. Backups reachable by production credentials share production's blast radius, so isolation is the property to insist on.
Does Eon back up ElastiCache or Memorystore directly?
No, Eon does not back up the managed cache engines directly. Eon protects self-managed Redis through EC2, EBS, and EKS persistent volume backups with file-level restore, and it governs, classifies, and protects the S3 or Cloud Storage buckets where ElastiCache and Memorystore exports land. The managed engines themselves stay on native snapshot tooling.
