Valkey: Persistence & LXC Backups

[pshankinclarke]

Valkey persistence and Proxmox backups

This guide walks through setting up persistence in the Valkey LXC and how it works with Proxmox backups and restores.

Persistence in Valkey refers to retaining data across restarts by writing it to disk. Proxmox provides backup and restore for LXC containers, so once Valkey is persisting to disk, Proxmox can back it up and restore it as needed.

Valkey includes RDB defaults: 3600 1 300 100 60 10000, but depending on your use case, you might want to change this. Below are some common persistence profiles and an example of how they behave with Proxmox backups.

Persistence profiles

All example snippets can be placed in /etc/valkey/valkey.conf and then restart the service:

sudo systemctl restart valkey-server

RDB (default persistence)

This uses point-in-time snapshots (dump.rdb) to persist data. On a fresh Debian-based Valkey LXC, RDB is enabled with the following defaults ( retrievable via valkey-cli CONFIG GET save ):

save 3600 1 300 100 60 10000
appendonly no

AOF (Append Only File) persistence

Debian does not enable AOF by default. Once enabled, AOF logs each write operation by the server. On restart, Valkey replays the log to rebuild your dataset.

appendonly yes
save ""  # disable RDB snapshots

No persistence

This disables persistence completely so the instance behaves like a cache. All data is lost on restart.

save ""
appendonly no # already the default

RDB + AOF hybrid

If you want durability similar to what PostgreSQL offers, turn on RDB snapshots and AOF.

save 3600 1 300 100 60 10000 # RDB defaults
appendonly yes

In all cases, Debian's default paths for data files remain unchanged, so RDB and AOF files continue to live under /var/lib/valkey where Proxmox CT backups can find them.

Proxmox backup integration steps

1. Edit /etc/valkey/valkey.conf inside the container and set one of the profiles, then restart.

You should see files like this, depending on the profile:

/var/lib/valkey:
appendonlydir  dump.rdb

/var/lib/valkey/appendonlydir:
appendonly.aof.1.base.rdb
appendonly.aof.1.incr.aof
appendonly.aof.manifest

2. Write some data to Valkey:

PASS="$(cat ~/valkey.creds)"

valkey-cli -a $PASS SET foo bar
valkey-cli -a $PASS SET counter 42

3. On the host, run a backup of the container:

vzdump <CTID> --mode snapshot --storage <STORAGE> --compress zstd

This creates an archive at a templatized path:

/var/lib/vz/dump/vzdump-lxc-<CTID>-YYYY_MM_DD-HH_MM_SS.tar.zst

4. Restore into a new container:

pct restore <NEW_CTID> /var/lib/vz/dump/vzdump-lxc-<CTID>-YYYY_MM_DD-HH_MM_SS.tar.zst --storage <STORAGE>
pct start <NEW_CTID>
pct enter <NEW_CTID>

5. Verify the data:

PASS="$(cat ~/valkey.creds)"

valkey-cli -a $PASS GET foo
valkey-cli -a $PASS GET counter

If you get bar and 42, then your persistence and backup are successfully capturing and restoring your Valkey dataset!