When This Error Hits
You’ve just moved your dump.rdb file to a new server and hit start. Instead of your data loading, the service immediately crashes. You check the logs and see a frustrating message about RDB versions. This usually happens when you try to migrate data from a newer Redis instance (like Redis 7.0) to an older one (like Redis 5.0).
Can't handle RDB format version 10 (or higher); Short read or OOM loading DB
The problem is simple: your new server doesn't speak the same language as your old backup file.
Why This Happens
Redis RDB files use a specific versioning system. While Redis is great at forward-compatibility—meaning a new version can always read an old file—it does not support backward-compatibility. Older versions of Redis simply don't understand the new compression logic or data structures found in newer RDB formats.
- RDB Version 9: Used by Redis 5.0 and 6.0.
- RDB Version 10: Introduced with Redis 6.2.
- RDB Version 11: Introduced with Redis 7.0.
If you try to load an RDB Version 11 file into a Redis 6.0 engine, the process fails instantly. The engine sees a version number higher than its own limit and stops to prevent data corruption.
The Best Fix: Upgrade the Target Redis
Upgrading your target server is the most reliable solution. If your source is running 7.0, your target should be 7.0 or higher. For Docker users, this is a quick fix in your docker-compose.yml file.
# Upgrade from 6.0 to 7.2
docker pull redis:7.2
docker stop my-redis-container
docker run --name my-redis-container -v /path/to/dump.rdb:/data/dump.rdb -d redis:7.2
On Linux servers, avoid the outdated packages in default repositories. Use the official Redis repo to get the latest stable build instead:
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt-get update
sudo apt-get install redis
Workaround: Migration "Over the Wire"
Sometimes you’re stuck with an old OS that won't support the latest Redis. In this case, you cannot use the dump.rdb file directly. You must move the data while both instances are running. By doing this, Redis translates the data into a compatible format during the transfer.
Method 1: Using redis-cli --pipe
This method bypasses RDB versioning by serializing keys into a format both versions understand. It works well for small to medium datasets.
# Run this on your source server to push a specific key
redis-cli --raw SERIALIZE mykey | redis-cli -h target-host -x RESTORE mykey 0
Method 2: Using Redis-Shake
For databases larger than 1GB, use a dedicated tool like redis-shake. It acts as a bridge, syncing data from the source to the target in real-time.
- Download the
redis-shakebinary. - Edit the
syncconfiguration to point to your source and target IPs. - Start the tool. It will stream all keys without ever touching an RDB file on the target disk.
The AOF Alternative
If you need to move data between versions frequently, switch to Append Only File (AOF). Unlike the binary RDB format, AOF is a text-based log of commands. An AOF file generated by Redis 7.0 is much more likely to be readable by Redis 6.0 because the basic SET and HSET commands haven't changed.
- Enable AOF on the source:
CONFIG SET appendonly yes. - Transfer the resulting
appendonly.aofto your target server. - Ensure
appendonly yesis set in the target'sredis.conf. - Restart the target service.
Verifying the Migration
After the migration, don't just assume it worked. Check your keyspace and logs to ensure everything is stable.
# Confirm the service is responsive
redis-cli ping
# Compare key counts with the source
redis-cli info keyspace
# Check for the magic words in the logs
tail -n 50 /var/log/redis/redis-server.log
# Look for: "DB loaded from disk: 1.234 seconds"
If you see that loading message and no format errors, your data is safe and ready to use.