RDB-Snapshots verstehen und richtig konfigurieren

1. Was RDB-Snapshots sind und wofür sie gedacht sind

Ein RDB-Snapshot ist eine point-in-time-Momentaufnahme des gesamten Redis-Datenbestands, gespeichert als einzelne, kompakte Binärdatei. Anders als ein Log, das jede einzelne Schreiboperation protokolliert, hält RDB nur den Endzustand aller Keys zu einem bestimmten Zeitpunkt fest. Das macht RDB-Dateien klein, schnell zu laden und ideal für Backups, weil eine einzelne Datei den kompletten Datensatz repräsentiert, ohne dass ein Replay von Operationen nötig ist.

Der Kernvorteil von RDB-Snapshots liegt in der Geschwindigkeit beim Neustart: Redis liest eine RDB-Datei linear ein und rekonstruiert den Speicher, was bei großen Datenmengen deutlich schneller geht als das Abspielen eines Append-Only-Logs. Der Kernnachteil ist ebenso offensichtlich: Zwischen zwei Snapshots liegen Daten, die bei einem Absturz verloren gehen. Wer RDB-Snapshots als alleinige Persistenzstrategie einsetzt, akzeptiert implizit ein Zeitfenster für möglichen Datenverlust, das über die save-Konfiguration gesteuert wird.

In der Praxis eignen sich RDB-Snapshots hervorragend für Caching-Layer mit gelegentlicher Persistenzanforderung, für Read-Replicas, die ohnehin aus einem Snapshot bootstrappen, und für Backup-Szenarien, in denen ein konsistenter Vollzustand wichtiger ist als Verlustfreiheit auf Sekundenebene. Für Anwendungsfälle mit strikten Durability-Anforderungen kombiniert man RDB meist mit AOF, dazu mehr in einem separaten Artikel dieser Reihe.

2. Save-Punkte konfigurieren: die save-Direktive im Detail

Die save-Direktive in redis.conf definiert, unter welchen Bedingungen Redis automatisch einen RDB-Snapshot auslöst. Jede save-Zeile folgt dem Muster save <Sekunden> <Änderungen> und bedeutet: Wenn seit dem letzten Snapshot mindestens die angegebene Anzahl Sekunden vergangen ist UND mindestens die angegebene Anzahl an Schreiboperationen stattgefunden hat, wird ein neuer Snapshot ausgelöst. Mehrere save-Zeilen werden ODER-verknüpft: Sobald eine der Bedingungen zutrifft, startet der Snapshot.

Die Standardkonfiguration vieler Redis-Distributionen sieht drei save-Punkte vor: save 900 1, save 300 10 und save 60 10000. Das bedeutet in Worten: Ein Snapshot nach 900 Sekunden, wenn mindestens eine Änderung stattfand, ein Snapshot nach 300 Sekunden bei mindestens 10 Änderungen, und ein Snapshot nach 60 Sekunden bei mindestens 10.000 Änderungen. Diese Staffelung sorgt dafür, dass bei hoher Schreiblast häufiger gesichert wird, während bei geringer Last nicht unnötig oft ein Fork ausgelöst wird.

Wer RDB-Snapshots komplett deaktivieren will, etwa weil ausschließlich AOF genutzt wird, setzt save "" als leeren String. Das entfernt alle konfigurierten save-Punkte, ohne dass BGSAVE manuell weiterhin möglich bleibt: BGSAVE per redis-cli funktioniert weiterhin, nur die automatische Auslösung entfällt. Für produktive Setups empfiehlt sich, die save-Punkte an das tatsächliche Schreibvolumen anzupassen, statt blind die Standardwerte zu übernehmen.

# redis.conf - RDB save points configuration

# Save after 900 sec (15 min) if at least 1 key changed
save 900 1
# Save after 300 sec (5 min) if at least 10 keys changed
save 300 10
# Save after 60 sec if at least 10000 keys changed
save 60 10000

# Disable RDB entirely (AOF-only setups)
# save ""

# Filename and directory for the RDB file
dbfilename dump.rdb
dir /var/lib/redis

# Stop accepting writes if the last BGSAVE failed
# (protects against silent data loss, disable with caution)
stop-writes-on-bgsave-error yes

3. BGSAVE: Fork und Copy-on-Write im Detail

Der Mechanismus hinter automatischen RDB-Snapshots heißt BGSAVE und basiert auf dem POSIX-Systemaufruf fork(). Wenn ein Snapshot ausgelöst wird, dupliziert Redis den laufenden Prozess: Der Elternprozess bedient weiterhin Client-Anfragen, während der Kindprozess den kompletten Speicherinhalt in eine temporäre RDB-Datei schreibt und diese anschließend atomar per rename() an die Zieldatei verschiebt. Aus Sicht der Clients ist ein RDB-Snapshot damit praktisch nicht-blockierend, weil der Elternprozess Anfragen ununterbrochen weiterverarbeitet.

Der entscheidende Effizienzgewinn kommt von Copy-on-Write, kurz COW, einem Betriebssystem-Feature, das der Linux-Kernel für geforkte Prozesse bereitstellt. Beim Fork werden die Speicherseiten des Elternprozesses nicht physisch kopiert, sondern beide Prozesse teilen sich zunächst dieselben Seiten im virtuellen Speicher. Erst wenn der Elternprozess eine Seite verändert, etwa durch ein neues SET-Kommando, kopiert der Kernel genau diese eine Speicherseite, üblicherweise 4 KB groß, bevor der Schreibzugriff erfolgt. Der Kindprozess sieht dadurch weiterhin den unveränderten Zustand zum Zeitpunkt des Forks, exakt die Konsistenzgarantie, die ein Snapshot braucht.

Die Kosten dieses Mechanismus hängen direkt von der Schreibrate während des BGSAVE ab: Je mehr Keys sich ändern, während der Kindprozess noch schreibt, desto mehr Speicherseiten werden dupliziert, und desto mehr zusätzlicher RAM wird kurzzeitig belegt. Bei einem Datensatz mit hoher Schreiblast und großem Working Set kann der zusätzliche Speicherbedarf während eines BGSAVE durchaus 20 bis 50 Prozent des ursprünglichen Datenbestands erreichen. Das ist der Hauptgrund, warum Redis-Instanzen niemals bis an die physische Speichergrenze konfiguriert werden sollten.

# Trigger a manual RDB snapshot
redis-cli BGSAVE
# Background saving started

# Check whether a BGSAVE is currently running
redis-cli INFO persistence | grep rdb_bgsave_in_progress
# rdb_bgsave_in_progress:1   -> snapshot running
# rdb_bgsave_in_progress:0   -> idle

# Check outcome and timing of the last BGSAVE
redis-cli INFO persistence | grep -E "rdb_last_bgsave_status|rdb_last_bgsave_time_sec|rdb_last_cow_size"
# rdb_last_bgsave_status:ok
# rdb_last_bgsave_time_sec:3
# rdb_last_cow_size:41943040   -> ~40 MB copy-on-write overhead

4. SAVE vs. BGSAVE: der entscheidende Unterschied

Neben BGSAVE kennt Redis auch den synchronen Befehl SAVE, der den RDB-Snapshot direkt im Hauptprozess erzeugt, ohne zu forken. Während SAVE läuft, blockiert Redis vollständig: Kein Client-Kommando wird bearbeitet, bis der Snapshot abgeschlossen ist. Bei kleinen Datenmengen mag das im Millisekundenbereich liegen, bei mehreren Gigabyte Daten kann SAVE jedoch Sekunden bis Minuten dauern, in denen die gesamte Instanz für Clients unerreichbar wirkt.

In produktiven Umgebungen sollte SAVE praktisch nie manuell aufgerufen werden. Der einzige legitime Anwendungsfall ist ein kontrollierter Shutdown, bei dem Redis ohnehin keine Anfragen mehr bedienen soll und maximale Konsistenz ohne Fork-Overhead gewünscht ist. Der Befehl SHUTDOWN ruft standardmäßig intern ein SAVE auf, sofern save-Punkte konfiguriert sind, bevor der Prozess beendet wird, damit kein Datenstand verloren geht.

5. Das RDB-Dateiformat: Aufbau und Versionierung

Eine RDB-Datei ist binär, aber ihr Aufbau ist gut dokumentiert und folgt einer klaren Struktur. Sie beginnt mit einem Magic String REDIS, gefolgt von einer vierstelligen Versionsnummer des RDB-Formats, zum Beispiel 0011 für Version 11. Diese Versionsnummer ist unabhängig von der Redis-Server-Version und erhöht sich nur, wenn sich das binäre Format selbst ändert, etwa bei neuen Datentypen. Danach folgen beliebig viele Opcodes, die Metadaten wie die ausgewählte Datenbank-Nummer, Expire-Zeiten und schließlich die eigentlichen Key-Value-Paare kodieren.

Jeder Key wird zusammen mit einem Typ-Byte gespeichert, das angibt, ob es sich um einen String, eine Liste, ein Set, eine Sorted Set oder eine Hash-Struktur handelt, gefolgt von einer typspezifischen Serialisierung des Werts. Redis nutzt dabei kompakte Kodierungen wie Ziplist oder Listpack für kleine Collections, um Speicherplatz zu sparen, und wechselt erst bei Überschreiten konfigurierbarer Schwellenwerte auf die vollwertige Datenstruktur. Am Ende der Datei steht ein End-of-File-Opcode, gefolgt von einer 8-Byte CRC64-Checksumme über den gesamten vorangegangenen Inhalt.

Diese Checksumme ist der zentrale Integritätsschutz von RDB-Dateien: Beim Laden prüft Redis, ob die berechnete Checksumme mit der gespeicherten übereinstimmt, und verweigert bei einer Abweichung den Start, sofern rdbchecksum aktiviert ist. Die Kompatibilität zwischen RDB-Versionen ist grundsätzlich abwärtsgerichtet: Ein neuerer Redis-Server kann ältere RDB-Dateiformate lesen, ein älterer Server kann jedoch keine RDB-Datei laden, die mit neueren Datentypen oder Opcodes geschrieben wurde. Bei Downgrades einer Redis-Version ist das ein häufig übersehener Stolperstein.

# Inspect the raw header bytes of an RDB file
xxd dump.rdb | head -3
# 00000000: 5245 4449 5330 3031 31fa 0972 6564 6973  REDIS0011..redis
# 00000010: 2d76 6572 0736 2e32 2e37 fa0a 7265 6469  -ver.6.2.7..redi
# 00000020: 732d 6269 7473 c040 fa05 6374 696d 65c2  s-bits.@..ctime.

# Byte breakdown:
#   "REDIS"      magic string (5 bytes)
#   "0011"       RDB format version (4 bytes, ASCII)
#   0xFA         opcode: auxiliary field (metadata) follows
#   "redis-ver"  metadata key
#   "6.2.7"      metadata value (server version at write time)

# Verify the trailing CRC64 checksum manually (Redis does this on load)
tail -c 8 dump.rdb | xxd

6. Kompression, Checksummen und weitere RDB-Parameter

Redis komprimiert String-Werte innerhalb einer RDB-Datei standardmäßig mit dem LZF-Algorithmus, gesteuert über die Direktive rdbcompression yes. LZF ist bewusst auf niedrige CPU-Kosten statt maximale Kompressionsrate optimiert, weil der BGSAVE-Prozess ohnehin bereits durch Copy-on-Write belastet wird und zusätzliche CPU-Last die Fork-Dauer verlängern würde. Für Datensätze mit vielen kurzen Strings, etwa Session-IDs oder Zähler, lohnt sich Kompression selten, weil der Overhead pro Wert größer sein kann als die Ersparnis, weshalb Redis bei sehr kurzen Werten automatisch auf Kompression verzichtet.

Die Direktive rdbchecksum yes aktiviert die CRC64-Prüfsumme am Dateiende. Wird sie deaktiviert, spart Redis geringfügig CPU-Zeit beim Schreiben und Lesen, verliert aber jede Möglichkeit, eine stille Korruption der Datei zu erkennen, etwa durch einen fehlerhaften Datenträger oder ein abgebrochenes Kopieren. Für produktive Systeme sollte rdbchecksum praktisch immer aktiv bleiben, der Performance-Unterschied ist im Normalbetrieb kaum messbar.

Weitere relevante Parameter sind sanitize-dump-payload, das beim Laden von RDB-Dateien oder RESTORE-Kommandos zusätzliche Validierung gegen manipulierte oder korrupte Payloads durchführt, sowie rdb-key-save-delay, ein primär für Tests gedachter Parameter, der künstlich Verzögerung zwischen dem Schreiben einzelner Keys einfügt, um COW-Verhalten unter Last zu simulieren. Im produktiven Betrieb bleibt dieser Parameter unverändert bei 0.

# redis.conf - RDB compression, checksums, and validation

# LZF compression for string values inside the RDB file
rdbcompression yes

# CRC64 checksum at the end of the RDB file (integrity check)
rdbchecksum yes

# Extra validation when loading RDB payloads (RESTORE, replication)
sanitize-dump-payload yes

# Keep the previous RDB file if BGSAVE fails (Redis 7+)
rdb-del-sync-files no

7. Performance-Auswirkungen: Fork-Zeit und Latenz-Spitzen

Die Dauer des fork()-Aufrufs selbst, nicht die anschließende Schreibarbeit des Kindprozesses, ist die kritischste Latenz-Größe bei RDB-Snapshots. Der Fork ist zwar durch Copy-on-Write theoretisch billig, weil keine Speicherseiten physisch kopiert werden, doch der Kernel muss trotzdem die komplette Seitentabelle des Prozesses duplizieren. Bei Instanzen mit sehr großem Heap, etwa 50 GB und mehr, kann allein dieser Schritt mehrere hundert Millisekunden dauern, während derer der Elternprozess vollständig blockiert ist, weil fork() selbst ein synchroner Systemaufruf ist.

Diese Fork-Latenz zeigt sich in der INFO-Ausgabe als latest_fork_usec und sollte regelmäßig überwacht werden. Werte im niedrigen einstelligen Millisekundenbereich sind bei kleinen Instanzen normal, während Werte über 100 Millisekunden bei großen Instanzen ein Hinweis darauf sind, dass BGSAVE-Aufrufe spürbare Latenz-Spitzen im Anwendungsbetrieb verursachen. Die Overcommit-Einstellung des Betriebssystems spielt hier ebenfalls eine Rolle: Mit vm.overcommit_memory=1 im Kernel reserviert Linux beim Fork keinen zusätzlichen Speicher im Voraus, was Fork-Fehler bei knappem Speicher verhindert und häufig empfohlen wird.

Auf rotierenden Festplatten oder überlasteten Netzwerkspeichern kann zusätzlich die eigentliche Schreibphase des Kindprozesses zum Engpass werden, weil parallele I/O-Last von Anwendungslogs oder anderen Prozessen die Snapshot-Dauer verlängert und damit auch das Zeitfenster für Copy-on-Write-Overhead vergrößert. Auf SSD- oder NVMe-gestützten Systemen ist dieser Effekt in der Regel vernachlässigbar. Für latenzkritische Setups empfiehlt sich, BGSAVE-Zeitpunkte gezielt in Phasen niedriger Schreiblast zu legen, statt sich ausschließlich auf die automatischen save-Punkte zu verlassen.

8. RDB-Dateien im Betrieb: Speicherort, Naming, Signale

Die Parameter dir und dbfilename in redis.conf bestimmen, wo eine RDB-Datei abgelegt wird, standardmäßig als dump.rdb im Arbeitsverzeichnis des Prozesses. In produktiven Setups sollte dir immer explizit auf einen dedizierten, überwachten Datenträger zeigen, niemals auf ein temporäres oder ephemeres Dateisystem, weil sonst Snapshots bei einem Container-Neustart verloren gehen. Redis schreibt zunächst in eine temporäre Datei im selben Verzeichnis und benennt sie erst nach erfolgreichem Abschluss atomar in die Zieldatei um, wodurch eine unvollständige RDB-Datei nach einem Absturz während des Schreibens praktisch ausgeschlossen ist.

Redis reagiert außerdem auf das Signal SIGHUP nicht mit einem RDB-Snapshot, wohl aber löst ein reguläres SHUTDOWN-Kommando standardmäßig einen finalen SAVE aus, sofern mindestens ein save-Punkt konfiguriert ist. Bei SHUTDOWN NOSAVE wird dieser Schritt bewusst übersprungen, etwa wenn ein Neustart ohnehin folgt und der letzte automatische Snapshot als ausreichend betrachtet wird. Für Systemd-verwaltete Redis-Instanzen ist es wichtig, den TimeoutStopSec-Wert großzügig genug zu setzen, damit ein finaler Snapshot bei großen Datenmengen nicht durch ein hartes SIGKILL unterbrochen wird.

#!/usr/bin/env bash
# check_rdb_health.sh - Monitor RDB snapshot status and age
set -euo pipefail

STATUS=$(redis-cli INFO persistence | grep rdb_last_bgsave_status | cut -d: -f2 | tr -d '\r')
LAST_SAVE_EPOCH=$(redis-cli LASTSAVE)
NOW_EPOCH=$(date +%s)
AGE_MIN=$(( (NOW_EPOCH - LAST_SAVE_EPOCH) / 60 ))

if [[ "$STATUS" != "ok" ]]; then
  echo "[ALERT] Last BGSAVE failed: $STATUS" >&2
  exit 1
fi

if (( AGE_MIN > 30 )); then
  echo "[WARN] Last RDB snapshot is $AGE_MIN minutes old" >&2
  exit 1
fi

echo "[OK] RDB snapshot healthy, age: ${AGE_MIN} min"

9. Typische Fehler und Stolperfallen bei RDB-Snapshots

Der häufigste Fehler bei RDB-Snapshots ist, sich allein auf sie zu verlassen und dabei das Zeitfenster zwischen zwei save-Punkten zu unterschätzen. Bei save 900 1 als einzigem save-Punkt können im schlimmsten Fall bis zu 15 Minuten an Schreiboperationen bei einem harten Absturz verloren gehen. Für Session-Speicher oder Caches mag das tolerierbar sein, für Bestelldaten oder Finanztransaktionen ist es fahrlässig, ohne zusätzliche AOF-Absicherung oder Anwendungsseiten-Persistenz zu arbeiten.

Ein zweiter verbreiteter Fehler ist stop-writes-on-bgsave-error unbedacht auf no zu setzen, um vermeintlich Verfügbarkeit zu erhöhen. Standardmäßig blockiert Redis Schreiboperationen, wenn der letzte BGSAVE fehlgeschlagen ist, etwa weil die Festplatte voll war, damit der Betreiber das Problem bemerkt, bevor unbemerkt Daten ohne jede Persistenzgarantie akkumulieren. Wer diese Sicherung deaktiviert, verliert genau dieses Frühwarnsystem und riskiert stillen, unbemerkten Datenverlust über einen langen Zeitraum.

Ein dritter Fehler betrifft Speicher-Overcommit: Wird vm.overcommit_memory nicht auf 1 gesetzt, kann der fork()-Systemaufruf bei knappem freiem Speicher fehlschlagen, selbst wenn durch Copy-on-Write praktisch kein zusätzlicher Speicher sofort gebraucht wird. Das Ergebnis ist ein fehlgeschlagener BGSAVE just in dem Moment, in dem ein Backup am dringendsten gebraucht wird, meist unter hoher Last. Das Redis-Log warnt explizit vor dieser Fehlkonfiguration beim Start, diese Warnung sollte niemals ignoriert werden.

10. Zusammenfassung

RDB-Snapshots sind das effizienteste Werkzeug in Redis, um einen kompletten Datenbestand als kompakte, schnell ladbare Binärdatei festzuhalten. Die save-Direktive steuert, wie aggressiv automatisch gesichert wird, während BGSAVE durch fork() und Copy-on-Write dafür sorgt, dass ein Snapshot den laufenden Betrieb praktisch nicht blockiert. Das RDB-Dateiformat mit Magic String, Opcodes und CRC64-Checksumme ist stabil dokumentiert, kompakt und aufwärtskompatibel, aber nicht garantiert abwärtskompatibel zwischen Redis-Versionen.

Wer RDB-Snapshots produktiv einsetzt, sollte save-Punkte an das reale Schreibvolumen anpassen, rdbchecksum und stop-writes-on-bgsave-error aktiviert lassen und die Fork-Latenz über latest_fork_usec regelmäßig überwachen. Für Anwendungsfälle mit strikten Verlust-Anforderungen reicht RDB allein selten aus, hier liefert die Kombination mit AOF-Persistence, dazu mehr im nächsten Artikel dieser Reihe, das fehlende Sicherheitsnetz zwischen zwei Snapshots.

11. FAQ: RDB-Snapshots verstehen und konfigurieren