You've been asked to “download the Redis cache,” usually because someone needs to move data, investigate a production issue, or prepare a recovery copy. The request sounds simple until you ask what should leave the server. Redis may expose an RDB snapshot, an AOF persistence file, a managed-provider export, or no portable artifact at all.
Those options aren't interchangeable. A cache snapshot can be useful for recovery or debugging, but it may contain stale, sensitive, or structurally incompatible data. The right download path depends on whether Redis is self-hosted, managed, clustered, ephemeral, or carrying data that belongs in a primary database.
Table of Contents
- What a Redis Cache Download Really Means
- Triggering an RDB Snapshot on a Self-Hosted Redis
- RDB vs AOF for Cache State and Backups
- Restoring and Inspecting a Downloaded Dump
- Hosted Provider Export and Download Caveats
- Safe Practices for Cache Snapshot Downloads
- Choosing the Right Download Path and FAQ
What a Redis Cache Download Really Means
A Redis cache download is normally the transfer of a server-side persistence artifact, not a browser-style export of visible cache entries. On a self-hosted instance, that artifact may be dump.rdb or an append-only file. A managed service may create an RDB snapshot in provider-owned object storage. A logical export may instead copy selected keys through commands such as SCAN, DUMP, and RESTORE.
Redis has supported both snapshotting and append-only persistence for much of its history. The project was first publicly released on February 26, 2009, and reached Redis 8.0 by May 2025, reflecting more than 16 years of ongoing development documented in the Redis project history. That maturity doesn't make every persistence artifact portable. It makes understanding the artifact more important.
Identify the export shape first
Before running a command, establish which of these situations applies:
- Self-hosted Redis: You control the configured persistence directory and can copy the resulting file from the host.
- Managed Redis: The provider may create an export in a storage account or backup system. You might never receive direct filesystem access.
- Logical rebuild: You select keys and serialize them over the Redis protocol. This is useful for targeted migration, but it isn't the same as a complete server snapshot.
The distinction affects durability, integrity checks, authentication, storage, restore compatibility, and data coverage. A downloaded RDB contains a point-in-time representation of Redis data. It doesn't automatically preserve the surrounding cluster topology, application contracts, secrets management, or the database that originally generated the cached values.
If you're designing the cache rather than extracting it, review Redis caching strategies before choosing a persistence model. The cache's role determines whether a snapshot is a recovery aid, a migration input, or merely a debugging sample.
Triggering an RDB Snapshot on a Self-Hosted Redis
On a self-hosted server, start by finding the configured persistence directory and filename. Redis commonly uses a dir setting for the directory and dbfilename for the snapshot name, but configuration varies by package, container image, and deployment system.
You can inspect the live configuration with:
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
The resulting path tells you where Redis writes the RDB file. Don't assume the file lives in the directory from your installation guide, especially if systemd, Docker, Kubernetes, or a custom volume changes the runtime configuration.
Use BGSAVE, not SAVE, during normal traffic
For an online snapshot, issue:
redis-cli BGSAVE
BGSAVE asks Redis to create the snapshot in a background child process and returns control to the server. It still consumes CPU, memory, and disk I/O, so it isn't free. Large datasets and memory pressure can make snapshotting visible to application traffic.
Avoid SAVE on a production primary. SAVE performs a synchronous snapshot and blocks the Redis event loop while the file is written. That can turn a routine export into an outage.
Check progress with:
redis-cli INFO persistence
redis-cli LASTSAVE
Look for the background-save status and confirm that the latest save timestamp changes after the operation completes. Also inspect the Redis logs and filesystem metadata. A command returning successfully doesn't prove that the final file was copied completely or stored safely.
When the snapshot is ready, transfer it away from the Redis host:
scp /path/to/dump.rdb backup-host:/secure/location/
You can also use rsync or synchronize the file to controlled object storage. Keep the transfer authenticated and avoid placing the dump in a publicly readable location.
For a small selection of keys, a full RDB is excessive. redis-cli --scan can enumerate matching keys, while DUMP can serialize individual values for a targeted transfer. That route requires you to preserve key names, TTL behavior, and restore ordering yourself, so it's a selective migration tool rather than a whole-instance backup.
A disciplined benchmark matters before you export during a busy window. Redis benchmark guidance recommends controlled testing, including a client in the same region as the cache, realistic GET requests, and payload sizes that resemble production objects. Measure hit behavior and miss latency as well as raw throughput, because a fast cache command won't compensate for an expensive fallback path.
RDB vs AOF for Cache State and Backups
RDB and AOF solve different durability problems. RDB captures a point-in-time binary snapshot. AOF records write operations and can provide a tighter recovery point, but its files and replay behavior make it a heavier choice for a disposable cache.
For most cache state, RDB is the practical default. If the source database can regenerate values, losing warm cache entries is usually less damaging than spending recovery time replaying a long command history. AOF makes more sense when Redis contains data that can't be cheaply rebuilt, or when the team explicitly needs command-log-style recovery.
| Attribute | RDB | AOF |
|---|---|---|
| File format | Compact binary snapshot | Append-only command log, periodically rewritten |
| Typical size | Often smaller for equivalent state | Often larger because it represents writes and rewrite metadata |
| Restore speed | Usually faster because Redis loads a snapshot | Usually slower because Redis replays operations |
| Data loss window | Changes since the latest completed snapshot can be lost | Depends on the configured fsync policy |
| Best fit | Cache backup, cloning, point-in-time state | Replayable history and stronger persistence requirements |
An AOF download also isn't always a single simple text file on newer Redis deployments. AOF rewrite and storage behavior can involve multiple components, so copying only one apparent file may produce an incomplete artifact. Treat the configured AOF layout as a set, and validate it before moving it to another server.
Practical rule: If Redis is only a cache, start with RDB and prove that restoring the cache is useful. Don't adopt AOF merely because it sounds safer.
Neither format replaces the system of record. A valid snapshot can still contain expired business assumptions, obsolete feature flags, or values that the application should refresh immediately. Persistence protects bytes. It doesn't validate their meaning.
Restoring and Inspecting a Downloaded Dump
Restore a downloaded file into an isolated Redis instance first. Stop the target server, place the artifact in the directory configured for that instance, confirm the filename matches the active configuration, and start Redis again.
A basic sequence looks like this:
sudo systemctl stop redis
sudo cp dump.rdb /var/lib/redis/dump.rdb
sudo chown redis:redis /var/lib/redis/dump.rdb
sudo systemctl start redis
redis-cli PING
redis-cli INFO keyspace
The exact service name, directory, and ownership depend on your operating system. The important control is isolation. Don't overwrite a live production primary while experimenting with an unfamiliar dump.
Validate before loading
Check the file before you trust it. For an RDB artifact, use:
redis-check-rdb /path/to/dump.rdb
The checker can identify a truncated file or malformed structure. Version compatibility also matters. An RDB produced by a newer Redis release may not load on an older server, so matching the source and target Redis versions is safer than hoping the loader accepts the file.
For AOF, run the corresponding validation tool before startup:
redis-check-aof --fix /path/to/appendonly.aof
Use the repair option only when you understand the consequences. A truncated tail may represent incomplete writes, and repairing it changes the artifact. Preserve the original before modifying anything.
Inspect the restored state
After startup, test both connectivity and content:
redis-cli PING
redis-cli DBSIZE
redis-cli --scan | head
For sampled keys, DEBUG OBJECT can reveal internal encoding details, while MEMORY USAGE key-name helps identify oversized values. Don't inspect every key blindly. Sample hot prefixes, large objects, and entries with unusual TTL behavior.
A short local warm-up with redis-cli MONITOR can expose unexpected reads, missing key patterns, or application code that immediately rewrites stale values. Stop monitoring promptly because it produces a high-volume stream and can distort a busy test environment.
The restored instance should remain side by side with the live system until you've checked key presence, TTLs, application compatibility, and memory requirements. A dump that loads successfully has passed only the file-format test.
Hosted Provider Export and Download Caveats
Managed Redis changes the meaning of “download.” You generally can't access the provider's Redis filesystem or fetch a dump through the public Redis endpoint. Instead, the service creates an export through its control plane and places the artifact in a storage location governed by provider permissions.
Azure's documented export and import model uses RDB snapshots stored in Azure Blob Storage for movement to or from Azure Redis cache instances, as described in the Azure Redis FAQ. That means the workflow involves the storage account, role permissions, and possibly a time-limited SAS token. Export copies data. It doesn't remove keys from the running cache.
| Provider | Export format | Download path | Auth method |
|---|---|---|---|
| Azure Redis | RDB snapshot | Azure Blob Storage configured for the export | Azure identity permissions or scoped storage access |
| Redis Cloud | Provider backup artifact, depending on database and plan | Console or provider administration tooling | Redis Cloud account or administrative credentials |
| AWS ElastiCache | Provider snapshot workflow | AWS-managed snapshot handling and supported export path | IAM-controlled AWS access |
Provider capabilities change by product, tier, deployment mode, and region. Confirm the current service documentation and console behavior before writing automation that assumes a local dump.rdb exists.
Verify the object, not just the job status
A provider reporting “export complete” tells you that its job finished. It doesn't prove that your download is intact or that the artifact contains the keys you expected.
Use a controlled verification sequence:
- Download the object through the provider's authenticated storage path.
- Run
redis-check-rdbagainst the local file where supported. - Compare keyspace observations with the source instance's
INFO keyspace. - Restore into an isolated Redis server and test representative key patterns.
- Record the source Redis version, database number, cluster arrangement, and export timestamp.
Hosted exports can also expose a portability gap. An RDB may contain data from one shard or deployment shape, while the destination expects a different topology. Don't treat a provider snapshot as a universal migration format until you've tested the restore path your application will use.
Safe Practices for Cache Snapshot Downloads
A snapshot contains data, not just operational metadata. Cache entries may include customer details, authorization material, request payloads, or internal tokens. Store every download as a sensitive infrastructure artifact until inspection proves otherwise.
Protect the file through its entire lifecycle
Use encryption before the artifact leaves the controlled environment:
gpg --symmetric --cipher-algo AES256 dump.rdb
Teams that use age can apply the same principle with recipient-based encryption. Keep encryption keys separate from the storage bucket, and restrict both download and decryption permissions. Don't email a raw dump to a vendor or attach it to an issue tracker.
The storage design matters as much as the command:
- Keep an off-host copy: A snapshot on the Redis server won't help after disk loss or host compromise.
- Use controlled object storage: Apply least-privilege access, audit logs, and retention controls.
- Protect against deletion: Object-lock or equivalent retention controls can prevent a bad deployment from deleting the only usable artifact.
- Record provenance: Store the Redis version, persistence settings, logical database, source environment, and cluster arrangement with the file.
- Remove sensitive data before sharing: Prefer a key-by-key sanitized export when a third party needs only a narrow reproduction.
Automate snapshot creation, transfer, validation, and alerting. The Redis production caching guidance highlights operational failure modes such as stampedes, evictions, missing TTLs, oversized serialized values, and insufficient memory headroom. A snapshot process should therefore capture operational context, not only the binary file.
A backup that nobody has restored is an assumption, not a recovery plan.
Run restore drills on a regular schedule that fits your risk. During each drill, measure whether the artifact loads, whether the application can read it, whether TTLs behave as expected, and whether the destination has enough memory. If the cache is used for API responses or rate-limiting state, document how the application behaves when those keys are absent. For a related application pattern, see VAT API rate limiting and caching.
Choosing the Right Download Path and FAQ
The decision is straightforward once you define what the downloaded data must accomplish. Use a point-in-time RDB when you need a compact snapshot from a self-hosted instance. Use AOF when replayable write history and tighter persistence matter more than quick cache reconstruction. Use a managed-provider export only after confirming the exact artifact, storage destination, authentication model, and restore constraints.
| Goal | Use | Don't use |
|---|---|---|
| Clone current cache state | BGSAVE, then copy and validate the RDB |
Synchronous SAVE during heavy traffic |
| Recover durable Redis data | AOF, often alongside RDB | An untested cache snapshot as the primary record |
| Move selected keys | SCAN with DUMP and RESTORE |
A full dump when only a small namespace is needed |
| Export managed Redis | Provider API and authenticated storage export | Direct filesystem assumptions or public curl access |
| Prepare a test environment | Sanitized RDB or logical fixture export | Production secrets copied into developer systems |
Three mistakes recur. Teams trigger a background snapshot on an already overloaded primary, restore a file onto an incompatible Redis version, or mistake cached state for authoritative business data. The fix is procedural: create the artifact away from peak pressure, validate compatibility, and rebuild from the primary store when correctness matters more than warm-start speed.
For teams that need a controlled artifact for load or recovery experiments, a separate download for infrastructure testing can be safer than handing test systems a production cache. If your application stores validation results or API response state, keep the cache contract explicit in the service layer and document it alongside your Redis cache REST API integration.
Frequently asked questions
Is a SCAN-based dump a valid backup?
It can be a valid logical export, but it isn't equivalent to an RDB backup. You must handle key names, serialized values, expiration times, data types, permissions, and partial failures. Use it when selective portability matters, not when you need a faithful point-in-time server image.
How often should a cache be downloaded?
Snapshot frequency should follow the cost of rebuilding the cache and the operational risk of losing warm state. If the source database can regenerate everything, a less frequent snapshot may be adequate. If Redis holds difficult-to-recreate state, treat it more like a durable datastore and test a stronger persistence design.
What should you do when the file won't load?
Keep the original untouched, run the appropriate checker, compare source and target Redis versions, and restore into a clean isolated instance. If the file is truncated or incompatible, rebuild selected data from the primary store instead of forcing an uncertain artifact into production.
TaxID provides a REST API for validating VAT and company identification numbers, with Redis-backed caching for repeated lookups and structured JSON responses. If your billing or checkout system needs reliable validation behavior without building the VIES integration and cache controls yourself, visit TaxID and review the API documentation.