Check a Redis RDB Dump with redis-check-rdb

Before you restore a backup and find it is truncated, run redis-check-rdb against it first. It is a structural check that never opens the dump in Redis or changes a byte of it, 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, since 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, so do not add a Redis connection string or a guessed flag; there is nothing there for it to use.

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 later.

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 here. 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!, and the output may show more auxiliary fields than this shortened example, including the Redis version that wrote the file.

That output is evidence the file passed this utility's RDB integrity checks. It is not evidence 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.

$ 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 not, 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 all 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. Preserve the evidence first:

$ 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 rather than continuing with a partial one. Once the investigation is complete and the original is confirmed no longer needed, the extra copy can be removed explicitly; that deletion is irreversible, so it is deliberately not part of the recovery command.

Do not interpret a failed check as proof 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, and a clean result does not prove the file is recent either. 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.