How to Backup and Restore a Redis RDB Snapshot

An RDB file is a point-in-time snapshot of every key. It is small, portable, and enough to rebuild a session store or a cache you actually care about. It is also easy to copy while Redis is still writing it, and easy to restore on top of a live AOF so the server ignores the dump. This post is the boring pipeline: BGSAVE, wait, copy dump.rdb off the box, restore on a stopped instance, then start.

If Redis is a pure cache, you may not need this. Rebuild from Postgres. If Redis holds sessions or a queue, you need a copy that is not on the same disk as the live data.

Take a consistent dump, then copy it

LASTSAVE is the timestamp of the last successful snapshot. BGSAVE asks for a new one without blocking the client thread. SAVE blocks everyone and is the wrong tool on a production port.

redis-cli LASTSAVE
redis-cli BGSAVE
# wait until LASTSAVE changes
while [ "$(redis-cli LASTSAVE)" = "$old" ]; do sleep 1; done
ls -lh /var/lib/redis/dump.rdb
cp -a /var/lib/redis/dump.rdb /var/backups/redis/dump.$(date +%F-%H%M).rdb

A slightly more honest script records LASTSAVE first, requests BGSAVE, and refuses to copy until the timestamp moves and the file size is non-zero. Copying mid-write is how you restore a truncated dump that Redis then refuses to load.

#!/usr/bin/env bash
set -euo pipefail
DIR=/var/backups/redis
mkdir -p $DIR
old=$(redis-cli LASTSAVE)
redis-cli BGSAVE
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30; do
  now=$(redis-cli LASTSAVE)
  if [ "$now" != "$old" ]; then
    break
  fi
  sleep 1
done
if [ "$(redis-cli LASTSAVE)" = "$old" ]; then
  echo "BGSAVE did not finish" >&2
  exit 1
fi
stamp=$(date +%F-%H%M)
cp -a /var/lib/redis/dump.rdb $DIR/dump.$stamp.rdb
chmod 600 $DIR/dump.$stamp.rdb

Push that file off the VPS. scp, sftp, or restic to another host is the off-site copy. A dump that lives only in /var/backups on the same High-Speed SSD dies with the node. Lucknow DC01 L3/L4 filtering does not replicate your RDB. Schedule the script from cron after the nightly quiet period, and keep 7 to 14 days.

INFO persistence shows rdb_last_bgsave_status and rdb_last_save_time. Grep those in the morning. An err status means the child failed, often because the disk filled or the fork could not allocate.

Restore on a stopped instance

Restore is not a COPY into a running server. A running Redis with AOF enabled will prefer the AOF on start and ignore a dump you just dropped in. Stop the service, decide which persistence files should exist, install the RDB, then start.

sudo systemctl stop redis-server
sudo mkdir -p /var/lib/redis
sudo rm -f /var/lib/redis/appendonly.aof
sudo rm -f /var/lib/redis/dump.rdb
sudo cp /var/backups/redis/dump.2026-08-02-0200.rdb /var/lib/redis/dump.rdb
sudo chown redis:redis /var/lib/redis/dump.rdb
sudo chmod 660 /var/lib/redis/dump.rdb
# appendonly no in redis.conf for this start, or leave AOF off until loaded
sudo systemctl start redis-server
redis-cli INFO keyspace
redis-cli DBSIZE

If you need AOF after the restore, start once with appendonly no so the RDB loads, then CONFIG SET appendonly yes and BGREWRITEAOF, or set appendonly yes and restart after you have confirmed DBSIZE. Mixing a stale AOF with a newer dump is the failure mode that looks like a successful start and an empty or old dataset.

Test this on a second VPS, not on production first. Restore drills are the only proof the file is valid. redis-check-rdb /path/to/dump.rdb is a quick integrity check before you copy.

redis-check-rdb /var/backups/redis/dump.2026-08-02-0200.rdb

A bad file exits non-zero. A good file prints a summary. Do not skip the check on a dump that arrived over the network.

What an RDB does not give you

RDB is not point-in-time for the last few seconds unless you BGSAVE constantly. AOF everysec is the tighter window; you can keep AOF on live and still copy RDB for off-site. RDB is not encrypted. chmod 600 and a private transfer are the minimum. RDB is not a replica. If you need a hot copy, run a replica; if you need a file you can put in object storage, RDB is the file.

On a Netbay plan, restore onto a fresh Ubuntu 24.04 instance, bind 127.0.0.1, set requirepass, then point a staging app at it. When DBSIZE matches, you have a backup. When it does not, you have a file you never tested. Write the expected DBSIZE next to the dump name in the backup log so the drill has a number. A dump that restores 12 keys when production had 12,000 is a truncated copy, not a mystery, and it almost always traces back to copying during BGSAVE or restoring beside a leftover AOF.

Takeaway

BGSAVE, wait for LASTSAVE, copy dump.rdb off the VPS, restore only while Redis is stopped and the old AOF is gone. Practice the restore on a fresh Netbay instance in Lucknow — netbayhosts.in.