Can You Roll Back a Valkey Upgrade? RDB Versions 11, 80 and 81 Explained

You upgraded a Valkey 8.1 replica to 9.1, failed over, and now want to go back. The obvious fallback is to start the old 8.1 binary on the current dump.rdb. That file was rewritten by 9.1, so 8.1 logs Can't handle RDB format version 80 and exits. Valkey 9.0 moved its snapshot format to a new numbering: 7.2 to 8.x write RDB version 11, 9.0 and 9.1 write version 80, and the 9.2 release candidates write 81. Older binaries refuse newer files by default, and the setting that relaxes this works on a best-effort basis only. This post maps what each release writes and loads, how mixed-version replication behaves, and a rollback plan you can test before you need it.

Scope and review date: November 2026. This post covers self-managed Valkey 7.2, 8.0, 8.1, 9.0, and 9.1 (latest patches 7.2.15, 8.0.12, 8.1.11, 9.0.7, and 9.1.3), with notes on the 9.2.0-rc2 release candidate and on Redis CE 7.4 and later. Version numbers, defaults, and log strings were checked against the Valkey source code, valkey.conf, and release notes on 10 November 2026. The commands were not run in a lab, so rehearse them on staging.

Which RDB version does each Valkey release write?

Every RDB file starts with a 9-byte header: a magic string followed by the format version. The comment in src/rdb.h at 9.1.3 states the history directly: "RDB 11 is the last open-source Redis RDB version, used by Valkey 7.x and 8.x." Valkey 9.0 jumped to version 80 "to avoid collisions with non-OSS Redis RDB versions", and files above version 79 use the magic string VALKEY instead of REDIS.

The 9.2.0-rc1 and 9.2.0-rc2 tags set RDB_VERSION to 81, which adds a new hash type (type 23) and an opcode used by forkless full sync. Treat RDB 81 as release-candidate behaviour until 9.2.0 ships.

# The first 9 bytes are the magic string and the RDB version
head -c 9 /var/lib/valkey/dump.rdb; echo
# REDIS0011  written by Valkey 7.2 to 8.x, or Redis OSS 7.2 and earlier
# VALKEY080  written by Valkey 9.0 or 9.1
# VALKEY081  written by a Valkey 9.2 release candidate

Interpretation: the header decides which binaries can start reading the file. A 9.2 release candidate set to rdbcompression lz4 or zstd writes a compressed stream that starts with VCS, and the 9.2 valkey.conf marks both codecs "Supported by Valkey 9.2 and later". The default, rdbcompression yes, still means per-string LZF.

Why are RDB versions 12 to 79 treated as Redis formats?

After Redis changed its license, Redis CE kept numbering its own format from 12. Per src/rdb.h in the redis/redis repository, Redis 7.4 to 8.4 write RDB 12, 8.6 writes 13, 8.8 writes 14, and 8.10 writes 15. Those formats add types Valkey does not have, and some reuse numbers that Valkey assigned differently. Type 22 is a Valkey 9.0 hash with field TTLs, but a Redis 7.4 release-candidate hash with a different layout. Opcode 243 is a Valkey slot import record, but Redis key metadata.

Valkey 8.1 reserved versions 12 to 79 as "foreign" in PR #1604 and refuses them even in relaxed mode. Valkey 9.0.0-rc2 added PR #2543, which accepts a foreign version in relaxed mode but rejects any type or opcode from 22 to 243 in a file with the REDIS header.

What does rdb-version-check relaxed actually do?

The setting arrived in Valkey 8.1.0. It takes strict or relaxed, defaults to strict, and can be changed at runtime. The 9.1.3 valkey.conf describes it as "a best-effort basis" and says "loading is aborted if unknown information is encountered", adding that it "also applies to replication and the RESTORE command."

In 8.1, relaxed accepts a VALKEY header with a higher version and fails on the first unknown type ("Unknown RDB encoding type"). In 9.0 and 9.1, it also accepts foreign Redis versions, and an unknown type ends the load with "Unknown type or opcode when loading DB. Unrecoverable error, aborting now."

valkey-cli CONFIG GET rdb-version-check
valkey-cli CONFIG SET rdb-version-check relaxed

Interpretation: CONFIG SET is enough for a replica that is about to full sync or for RESTORE. A file loaded at startup is read before you can connect, so for that case the value has to be in the config file.

# valkey.conf on the Valkey 8.1 host you might roll back to
rdb-version-check relaxed

Without it, this is what the old binary logs when it meets a 9.x snapshot. The strings are from the 8.1.11 and 8.0.12 source.

grep -E "RDB format|signature|Fatal error loading" /var/log/valkey/valkey.log
# Valkey 8.1 with the default strict check:
#   # Can't handle RDB format version 80
#   # Fatal error loading the DB, check server logs. Exiting.
# Valkey 8.0 or 7.2 (no setting can change this):
#   # Wrong signature trying to load DB from file

Interpretation: the 8.0 and 7.2 loaders only recognise a REDIS header, so they stop before the version is even read. On 8.1, relaxed gets past the header, and success then depends on what the data contains.

What happens to replication in a mixed-version rolling upgrade?

The Valkey releases page says to "always upgrade replicas before upgrading primaries", and that across major versions "data replicated from primaries to replicas will always be sent in a backward compatible format." The first half is easy: a 9.x replica of an 8.x primary loads the RDB 11 full sync without any setting. The second half depends on the primary's release.

• A 9.0 primary always writes RDB 80 with the VALKEY header; the 9.0.7 replication code has no per-replica version choice. A 7.2 or 8.0 replica cannot full sync from it, and an 8.1 replica can only try with relaxed.
• A 9.1 or later primary includes PR #2735, which "allows latest Valkey to send snapshots as RDB 11 to replicas running Valkey 7.2 and 8.x". The primary uses the version the replica announces and streams the older format over the socket, so its own dump.rdb stays at version 80.
• The exception: per the same PR, "if any new features that the replica can't handle (such as hash-field expiration and atomic slot migration) are in use, the full sync is aborted". The primary logs "Can't store key ... in RDB version 11".

A partial resync after a failover sends no RDB at all, only commands. The risk then moves to the command stream: an 8.x replica cannot run HSETEX or HEXPIRE. With the default propagation-error-behavior ignore, it logs the error, skips the command, and quietly diverges from the primary.

# Which release is each node really running? redis_version is always 7.2.4
for h in cache-01 cache-02 cache-03; do
  echo "$h $(valkey-cli -h "$h" INFO server | grep '^valkey_version:' | tr -d '\r')"
done

Interpretation: every Valkey reports redis_version:7.2.4, as the migration guide notes, so only valkey_version shows the real release.

# On the 9.1 primary: does any data or traffic need a 9.x replica?
valkey-cli INFO keyspace
# example: db0:keys=18240,expires=3115,avg_ttl=412000,keys_with_volatile_items=0
valkey-cli INFO commandstats \
  | grep -E 'cmdstat_(hsetex|hgetex|hexpire|hpexpire|hexpireat|hpexpireat|hgetdel|msetex|delifeq):'

Interpretation: in 9.1, keys_with_volatile_items above 0 means hashes with field TTLs exist, and an RDB 11 full sync to an 8.x replica will abort. Any cmdstat_ line means a command added in 9.0 or 9.1 ran since the counters were last reset, and an 8.x replica could not apply it.

Which 9.0 and 9.1 patch releases break cross-version loads?

Three 2026 fixes matter when versions are mixed. The most serious is PR #4819, shipped in 9.1.3 and 9.2.0-rc2. For listpack entries whose encoded length is exactly 16383, 2097151, or 268435455 bytes, two widths of the trailing length field are valid. Per the PR, "Valkey wrote the wider form up to 9.0 and the narrower one in 9.1.0 through 9.1.2", and each side misreads the other. The PR notes these lengths are reachable in normal use: a 16378-byte string element produces an entry length of exactly 16383.

The practical rule: go from 8.x or 9.0 straight to 9.1.3 or later. If a node already ran 9.1.0 to 9.1.2, move it forward to 9.1.3, which reads both widths, rather than back to 9.0. For which patch each branch needs for security fixes as well, see our Valkey support windows and minimum safe patch post.

# Check an AOF directory with a patched tool (9.0.7, 9.1.3 or later)
valkey-check-aof /var/lib/valkey/appendonlydir/appendonly.aof.manifest

# The base file of a multi-part AOF is an RDB file when aof-use-rdb-preamble is yes
head -c 9 /var/lib/valkey/appendonlydir/appendonly.aof.*.base.rdb; echo

Interpretation: with aof-use-rdb-preamble yes (the default), a 9.x AOF base file starts with VALKEY080, so an AOF does not help an 8.x rollback either. An older valkey-check-aof that flags that file as invalid is the #4739 bug, not corruption.

Can you downgrade from Valkey 9 to Valkey 8?

There is no documented downgrade procedure, only three ways to move data back:

• Start the old binary on the new files. Only 8.1 with relaxed can try, as above.
• Replicate into an old-version node. Works from a 9.1 or later primary until 9.x-only data exists.
• DUMP and RESTORE, or MIGRATE. The payload footer carries RDB version 80, which 8.x refuses under strict.

# MIGRATE uses DUMP and RESTORE, so the payload says RDB 80
valkey-cli -h cache-new MIGRATE cache-old 6379 "" 0 5000 KEYS session:42
# (error) ERR Target instance replied with error: ERR DUMP payload version or checksum are wrong

Interpretation: setting rdb-version-check relaxed on an 8.1 target lets RESTORE accept version 80 payloads for the old types. Keys in 9.x-only encodings still fail. A copy that reads values with ordinary commands and writes them back avoids the format entirely, but you handle each type and TTL yourself.

Can Valkey load an RDB file from Redis 7.4 or later?

Officially, no. The Valkey migration guide says "Redis Community Edition (CE) version 7.4 and later produce data files that are not compatible with Valkey" and supports file migration only from Redis OSS 2.x to 7.2.x. Since 9.0, relaxed mode accepts the foreign header and loads the file if every type is one Valkey understands, but many Redis files still fail. Redis 7.4 and later write hashes with field TTLs as types 24 and 25. Redis 8.6 and later write every stream as type 26 and can write key metadata as opcode 243. All fall inside the refused 22 to 243 range, and the load ends with "Can't handle foreign type or opcode". Valkey 8.1 refuses these files outright.

# Test a Redis CE snapshot with the Valkey 9.1 checker before planning around it
head -c 9 redis-dump.rdb; echo     # REDIS0012 from Redis 7.4 to 8.4
valkey-check-rdb redis-dump.rdb

Interpretation: for a foreign file, the 9.1 checker prints "Foreign RDB version 12 detected" and, if it parses every key, "RDB looks OK, but loading requires config 'rdb-version-check relaxed'". We have not run this against Redis files, so treat a pass as a reason to try a staging load, not as proof. Replication from Redis CE 7.4 or later sends the same format, so a logical copy is the dependable route. Our Redis 8 vs Valkey 8 in production covers the feature differences you will meet on the way.

How do you upgrade Valkey with a rollback path you have tested?

The plan below targets a primary with replicas, managed by Sentinel or by hand, moving from 8.x to 9.1.3. It relies on PR #2735, so the new primary must be 9.1 or later. A 9.0 primary would cut the old replica off at its next full sync.

The FAILOVER command waits for the named replica to catch up, then swaps roles; with TIMEOUT and no FORCE, it rolls back the attempt if the replica is too slow. During step 6, run the commandstats check above daily.

# Optional, on the old-version rollback replica only: stop on a command it
# cannot apply instead of skipping it and drifting from the primary
propagation-error-behavior panic-on-replicas

Interpretation: with the default ignore, a rollback target that missed writes looks healthy until you promote it. A stopped replica is at least visibly unusable.

Frequently asked questions

Key takeaways

Plan a Valkey upgrade you can undo with JusDB

JusDB's Valkey migration team can review your versions, topology, and the 9.x features your applications plan to use, then write a replica-first upgrade runbook with a rollback replica and rehearse the failover and the rollback on staging.

Bring your INFO server and INFO replication output from each node, your persistence settings, and your maintenance windows. Your team approves every production change.

Related reading

• Valkey 9.1: database ACLs, Lua as a module, and I/O threading
• Redis 8 vs Valkey 8 in production
• Redis persistence: RDB vs AOF, which to choose
• Valkey documentation: Releases and versioning schema