Check a Redis RDB Dump Before You Restore It

You will check a Redis RDB dump for structural integrity without opening it in Redis or changing the dump. The command is redis-check-rdb, supplied here by redis-tools version 5:7.0.15-1ubuntu0.24.04.4. Allow about ten minutes if you already know where the dump is stored.

This is a read-only inspection. You need a shell, the redis-tools package, and a readable RDB file. The examples use a placeholder path because Redis deployments store dumps in different directories. Replace it with the actual file, and check the path before copying a command into a recovery procedure.

1. Check the installed command

Confirm which executable will run and ask it for its usage text:

$ command -v redis-check-rdb
/usr/bin/redis-check-rdb
$ redis-check-rdb --help
Usage: redis-check-rdb <rdb-file-name>

The installed utility has one positional argument: the RDB filename. The local manual page documents no configuration file, server connection, repair mode or option for changing the input. Do not add a Redis connection string or a guessed flag.

Checkpoint: if command -v finds nothing, install or repair the normal redis-tools package through your system's package-management process. Do not download a replacement binary into a backup directory just to make this check run.

2. Identify the exact dump

Inspect the candidate file before checking it:

$ RDB_FILE=/var/lib/redis/dump.rdb
$ ls -l -- "$RDB_FILE"
$ file -- "$RDB_FILE"

Use an exact path rather than a broad wildcard. A Redis host may contain several dumps, rotated copies, or an unrelated file with an .rdb suffix. Note the file size and modification time so you can tell which backup you actually examined.

Reading a system-owned dump may require elevated privileges, depending on its permissions. Try the command as your normal account first. If it reports that the file cannot be opened, use sudo for this one read:

$ sudo redis-check-rdb -- "$RDB_FILE"

sudo is not an ordinary prerequisite. It does not repair the RDB and it does not make a missing file appear. Check the path and permissions before escalating.

3. Run the integrity check

Pass the dump as the only argument:

$ redis-check-rdb -- "$RDB_FILE"
[offset 0] Checking RDB file /var/lib/redis/dump.rdb
[offset 27] AUX FIELD redis-ver = '7.0.15'
[offset 110] Checksum OK
[offset 110] \o/ RDB looks OK! \o/
[info] 1 keys read
[info] 0 expires
[info] 0 already expired

The offsets, auxiliary fields and key counts depend on the dump. A successful check normally ends with Checksum OK and RDB looks OK!. The output may show more auxiliary fields than this shortened example, including the Redis version that wrote the file.

That output is evidence that the file passed this utility's RDB integrity checks. It is not evidence that the backup contains every key you expected, that its expiry times suit the recovery plan, or that a service can restore it into the intended Redis version.

Checkpoint: record the command, the absolute path, the file metadata and the exit status. Capture output without changing the dump:

$ redis-check-rdb -- "$RDB_FILE" > rdb-check.txt 2>&1
$ status=$?
$ printf 'redis-check-rdb exit status: %s\n' "$status"
$ test "$status" -eq 0

The temporary report is new state in your current directory, not a change to Redis. Keep it with the incident or backup record if you need an audit trail. If you do not need it, remove only that known report after reviewing it, not a directory containing the original dump.

4. Treat a failed check as a stop signal

A missing argument, unreadable path, truncated file or invalid RDB can produce a non-zero status and an error diagnostic. Do not pipe a failed check into a restore command, and do not overwrite the original dump while experimenting. First preserve the evidence:

$ cp --preserve=all -- "$RDB_FILE" "$RDB_FILE.before-investigation"
$ redis-check-rdb -- "$RDB_FILE.before-investigation" > rdb-failed-check.txt 2>&1
$ printf 'exit status: %s\n' "$?"

The copy needs enough free space and the destination must be a deliberate new filename. If the copy fails, stop and fix the storage or permissions problem. Do not continue with a partial copy. Once the investigation is complete and you have confirmed the original is no longer needed, the extra copy can be removed explicitly. That deletion is irreversible, so it is not part of the recovery command.

Do not interpret a failed check as proof that every copy of the backup is bad. Compare the file's checksum or transfer history, then test another known-good copy. If the file came from a transfer, repeat the transfer from the source rather than editing bytes in place.

5. Keep the result in proportion

redis-check-rdb checks a dumped database file. It does not contact a running Redis server, validate application-level data, or compare the dump with a separate backup manifest. A clean result also does not prove that the file is recent. Check the timestamp and the backup job's logs separately.

Before a real recovery, use a disposable Redis instance or an approved maintenance environment and verify the restored key count, important key types and expiry behaviour. That restore test is a separate operation with its own service and data-loss risks. The check itself should remain the quiet, read-only gate before you get that far.