Back Up and Restore Redis Data on a Linux VPS

To back up Redis data you trigger a snapshot with BGSAVE (or stream one with redis-cli --rdb) and copy the resulting file off the server. To restore it, you stop Redis, put the file back in the data directory with the right ownership, and start the service again.

This guide covers both persistence formats Redis uses, the safe way to copy a snapshot while the server is running, and how to roll back when something goes wrong.

Before you start

You need:

• A Linux VPS with Redis installed and running. If you have not set it up yet, see How to install and secure Redis on a Linux VPS.
• Root or sudo access, plus the Redis password if you enabled requirepass.
• Enough free disk space for a second copy of the dataset. Check with df -h.
• A place to store the backup that is not the same disk — another VPS, object storage, or your local machine.

Confirm the service is up and find the data directory:

sudo systemctl status redis-server
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
redis-cli CONFIG GET appendonly

On Debian and Ubuntu the directory is usually /var/lib/redis and the file is dump.rdb. On AlmaLinux and Rocky it is often /var/lib/redis as well, but always trust the output of CONFIG GET dir over any guide, including this one.

Understand RDB and AOF

Redis has two persistence formats and you should know which one your server uses before you copy anything.

• RDB — a point-in-time snapshot written to dump.rdb. Compact, fast to load, and the default on most installs.
• AOF — an append-only log of every write. On Redis 7 and later the files live in an appendonlydir directory with a manifest file, not a single appendonly.aof.

Run redis-cli CONFIG GET appendonly. If it returns no, you only need dump.rdb. If it returns yes, back up the whole AOF directory as well as the RDB file.

Take a Redis backup with BGSAVE

BGSAVE forks the server and writes a snapshot in the background, so your clients keep working.

redis-cli BGSAVE

It returns Background saving started. Watch the log until it finishes:

redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_bgsave_status|rdb_last_save_time'

When rdb_bgsave_in_progress:0 and rdb_last_bgsave_status:ok, the file is complete. You can also check the timestamp with redis-cli LASTSAVE.

If you want the snapshot streamed straight to another host without touching the server's disk, use:

redis-cli --rdb /home/deploy/redis-$(date +%F).rdb

This performs a full sync over the network and writes the file locally. It is the cleanest option for a remote backup.

Copy the snapshot files safely

Copying a live dump.rdb while Redis is writing it can give you a truncated file. Always copy the file produced by a finished BGSAVE, and verify the copy.

DIR=$(redis-cli CONFIG GET dir | tail -n1)
sudo cp "$DIR/dump.rdb" /home/deploy/redis-$(date +%F).rdb
sudo chown deploy:deploy /home/deploy/redis-*.rdb
ls -lh /home/deploy/redis-*.rdb

If AOF is enabled, copy the whole directory:

sudo cp -a "$DIR/appendonlydir" /home/deploy/appendonlydir-$(date +%F)

Then move the copy off the server. With rsync over SSH:

rsync -avz /home/deploy/redis-$(date +%F).rdb deploy@203.0.113.10:/backups/redis/

For a full server-level routine that includes these files, see Back up your Linux VPS with rsync, restic and cron.

Restore Redis from an RDB file

Restoring replaces the current dataset, so stop Redis first and keep the old file until you have confirmed the restore worked.

sudo systemctl stop redis-server
DIR=$(redis-cli CONFIG GET dir 2>/dev/null | tail -n1)
sudo cp "$DIR/dump.rdb" "$DIR/dump.rdb.bak-$(date +%F)"
sudo cp /home/deploy/redis-2026-01-01.rdb "$DIR/dump.rdb"
sudo chown redis:redis "$DIR/dump.rdb"
sudo chmod 660 "$DIR/dump.rdb"
sudo systemctl start redis-server

The chown matters. If the file is owned by root, Redis fails to start or silently loads nothing. Check the service log with sudo journalctl -u redis-server -n 50 if it does not come up.

Restore Redis from AOF

If AOF is enabled, Redis loads the AOF in preference to the RDB. Replace the directory contents, not just one file.

sudo systemctl stop redis-server
DIR=$(redis-cli CONFIG GET dir 2>/dev/null | tail -n1)
sudo mv "$DIR/appendonlydir" "$DIR/appendonlydir.bak-$(date +%F)"
sudo cp -a /home/deploy/appendonlydir-2026-01-01 "$DIR/appendonlydir"
sudo chown -R redis:redis "$DIR/appendonlydir"
sudo systemctl start redis-server

Redis 7 stores a manifest plus base and incremental files in that directory. Copy the whole folder as a unit — mixing files from different backups will fail to load. If the format changes in a future release, check the Redis documentation for the current layout.

Check it works

Confirm the server is up and the data is really there:

redis-cli PING
redis-cli DBSIZE
redis-cli INFO persistence | grep -E 'loading|rdb_last_bgsave_status|aof_last_bgrewrite_status'

PING should return PONG. DBSIZE should match what you expect from the backup. Spot-check a few known keys with redis-cli GET keyname or redis-cli HGETALL hashname.

If you restored on a different server, point one application instance at it and watch the logs before switching production traffic over.

Troubleshooting

• Redis starts but the dataset is empty. The file is in the wrong directory or has the wrong owner. Re-check CONFIG GET dir, then sudo chown redis:redis on the file and restart.
• Short read or OOM loading DB in the log. The RDB file is truncated, usually from copying it during a write. Restore from an older, complete backup and take future snapshots only after rdb_bgsave_in_progress:0.
• Bad file format reading the append only file. The AOF directory was mixed between backups or copied partially. Restore the whole appendonlydir folder again, or fall back to the RDB file.
• MISCONF Redis is configured to save RDB snapshots. Redis cannot write to disk, often because the disk is full or permissions changed. Free space with df -h and fix ownership in the data directory.
• Restore takes a long time and the service looks hung. Large datasets load synchronously at startup. Watch redis-cli INFO persistence for loading:1 and give it time before assuming failure.

Next steps

• Install Redis and secure it with a password if you are still setting up the server.
• Configure Redis remote access with bind and protected-mode when the backup target is another host.
• Optimizing Redis for high-read, low-latency applications to tune persistence without hurting throughput.
• Back up your Linux VPS with rsync, restic and cron to automate the copy step.