Databases·9 min read·

Redis Persistence: RDB vs AOF on a Small VPS

Choose RDB, AOF, or both on a small VPS by weighing restart durability against High-Speed SSD writes, fork cost, and how much data you can afford to lose.

NB

Netbay Infrastructure Team

Netbay Engineering

On this page

Redis keeps the working set in RAM. Persistence is the extra work that lets a restart, a crash, or a planned reboot bring those keys back. On a small VPS the tradeoff is sharp: more durability means more disk writes, more fork cost, and more chance that a snapshot stalls the instance. Pick RDB, AOF, or both with a number in mind: how many minutes of writes you can lose. Then set the config to that number instead of copying a cloud tutorial that assumed a dedicated Redis host.

If Redis is a pure cache in front of Postgres, you can often turn persistence off and rebuild from the database. If Redis holds sessions, rate-limit counters, or a queue the application cannot rebuild, you need a snapshot you can restore. The rest of this post assumes the second case on a single VPS with High-Speed SSD and a modest RAM allocation.

RDB is a point-in-time snapshot

RDB writes a compact binary dump. Redis forks a child, the child walks the dataset, and dump.rdb lands in the data directory. The parent keeps serving clients. The cost is the fork: on a 2 GB dataset the copy-on-write pages add RAM pressure, and a small VPS that is already near maxmemory can hit the OOM killer during the snapshot. save rules in redis.conf control how often that fork happens.

bash
# /etc/redis/redis.conf
dir /var/lib/redis
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes

Those three save lines mean: snapshot if at least one key changed in 15 minutes, or ten keys in five minutes, or ten thousand keys in one minute. For a cache that can lose a few minutes, save 300 100 is enough and cheaper. For sessions you care about, keep a 60-second rule or add AOF. stop-writes-on-bgsave-error is the safety brake: if the child cannot write the dump, Redis refuses new writes instead of running on a lie.

Trigger a snapshot by hand when you are about to reboot or copy a backup.

bash
redis-cli BGSAVE
redis-cli LASTSAVE
ls -lh /var/lib/redis/dump.rdb

LASTSAVE moving forward is the check that the dump finished. Copying dump.rdb while BGSAVE is still running is how you restore a truncated file. Wait, then copy.

AOF is a write-ahead log

AOF appends every write to an append-only file. On restart Redis replays the log. You choose how often fsync runs: every write, every second, or never (the OS decides). everysec is the usual production setting. always is durable and slow. no is fast and can lose more than a second on a crash.

bash
appendonly yes
appendfilename appendonly.aof
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

The log grows without bound until a rewrite. Redis forks again, writes a compact AOF, and swaps it in. On a small VPS that rewrite is the same fork tax as RDB. Keep auto-aof-rewrite-min-size high enough that you are not rewriting every few minutes, and leave enough free RAM for the child. If the dataset is 1 GB, do not run Redis at 1.8 GB of a 2 GB plan and expect AOF rewrite to succeed.

Both together, or neither

Redis can write RDB and AOF at once. On restart it prefers AOF because it is more complete. That pair is the right default when Redis is the session store and you already pay for High-Speed SSD. A cache that is rebuilt from MySQL should set save to empty and appendonly no so a restart is a cold cache, not a fork storm.

bash
# cache-only: lose the dataset on restart, keep RAM for keys
save ""
appendonly no
maxmemory 512mb
maxmemory-policy allkeys-lru

On Intel Xeon Platinum VPS nodes the CPU is rarely the limit for persistence. RAM headroom and disk write latency are. Watch used_memory, rdb_last_bgsave_status, and aof_last_rewrite_time_sec after you enable AOF. If the rewrite regularly takes tens of seconds, lower write volume or raise the plan so the child can finish.

A practical split for a 2 GB VPS that holds sessions plus a small cache: AOF everysec, one RDB save every five minutes, maxmemory well under the plan size, and a nightly copy of dump.rdb off the box. That is durable enough for logins and still small enough that a rewrite does not freeze the instance.

RDB vs AOF vs cache-only RDB compact snapshot lose minutes fork per save AOF everysec replay writes lose about 1 s rewrite forks too No persist rebuild from SQL lose all keys best for cache sessions: AOF + RDB cache: save empty leave RAM headroom for the BGSAVE child High-Speed SSD helps; fork still needs free memory

Takeaway

Match persistence to rebuild cost. Cache-only Redis should not snapshot. Session Redis should use AOF everysec and a periodic RDB you can copy off-box. You can size a Lucknow VPS on Netbay, enable High-Speed SSD, and test a restart in under a minute — netbayhosts.in.

Keep reading

Follow along on a real VPS

Deploy Linux in under 60 seconds

These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.

Deploy an instance