Backup- und Restore-Strategien für produktive Redis-Instanzen

1. Warum Persistence kein Backup ersetzt

Eine verbreitete Fehleinschätzung ist, RDB-Snapshots oder AOF-Persistence bereits als vollständige Backup-Strategie zu betrachten. Beide Mechanismen schützen vor demselben Szenario: einem Prozess-Neustart, bei dem der Speicherinhalt sonst komplett verloren ginge. Keiner der beiden schützt jedoch vor einem defekten Datenträger, einem versehentlich gelöschten Server, einer korrumpierten Festplatte oder einem menschlichen Fehler wie einem falsch ausgeführten FLUSHALL, das genauso zuverlässig persistiert wird wie jede andere Operation.

Eine echte Backup-Strategie unterscheidet sich von reiner Persistence in drei entscheidenden Punkten: Sie hält mehrere Zeitpunkte vor, nicht nur den aktuellsten Zustand, sie liegt physisch getrennt von der produktiven Instanz, und sie wird regelmäßig auf Wiederherstellbarkeit getestet. Ein RDB-Snapshot, der auf derselben Festplatte wie die laufende Redis-Instanz liegt, ist bei einem Hardware-Defekt ebenso verloren wie der Datenbestand selbst.

Dieser Artikel behandelt die praktische Umsetzung einer robusten Backup-Strategie: konsistentes Kopieren von RDB- und AOF-Dateien, Automatisierung mit Retention-Policy, regelmäßige Restore-Tests und eine Off-Site-Komponente. Die technischen Grundlagen zu RDB und AOF selbst werden in den vorangegangenen Artikeln dieser Reihe behandelt.

2. RDB-Dateien konsistent kopieren

Eine RDB-Datei einfach während des laufenden Betriebs mit cp zu kopieren, klingt zunächst simpel, birgt aber ein Konsistenzrisiko: Wenn genau in diesem Moment ein automatischer BGSAVE die Datei überschreibt, kann die Kopie einen inkonsistenten Zwischenstand erwischen. Zwar schreibt Redis intern über eine temporäre Datei und benennt erst atomar um, was das Risiko einer halb geschriebenen Datei praktisch ausschließt, dennoch sollte ein Backup-Prozess nicht auf zufälliges Timing angewiesen sein.

Die robustere Methode ist, vor dem Kopieren explizit einen frischen, garantiert vollständigen Snapshot zu erzwingen: redis-cli BGSAVE aufrufen, auf den Abschluss warten, indem rdb_bgsave_in_progress per Polling abgefragt wird, und erst danach die Datei kopieren. Das garantiert, dass das Backup exakt den Zustand zum Zeitpunkt des Backup-Laufs enthält, statt eines älteren, möglicherweise Stunden zurückliegenden Snapshots aus einem automatischen save-Punkt.

#!/usr/bin/env bash
# rdb_backup.sh - Force a fresh, consistent RDB snapshot and copy it out
set -euo pipefail

RDB_DIR="/var/lib/redis"
RDB_FILE="dump.rdb"
BACKUP_DIR="/var/backups/redis"
TIMESTAMP="$(date +%Y%m%d-%H%M%S)"

mkdir -p "$BACKUP_DIR"

# Trigger a fresh snapshot and wait for it to finish
redis-cli BGSAVE
while [[ "$(redis-cli INFO persistence | grep rdb_bgsave_in_progress | cut -d: -f2 | tr -d '\r')" == "1" ]]; do
  sleep 1
done

STATUS="$(redis-cli INFO persistence | grep rdb_last_bgsave_status | cut -d: -f2 | tr -d '\r')"
if [[ "$STATUS" != "ok" ]]; then
  echo "[ERROR] BGSAVE failed, aborting backup" >&2
  exit 1
fi

# Copy the now-guaranteed-consistent file
cp "${RDB_DIR}/${RDB_FILE}" "${BACKUP_DIR}/dump-${TIMESTAMP}.rdb"
gzip "${BACKUP_DIR}/dump-${TIMESTAMP}.rdb"
echo "[OK] Backup written: ${BACKUP_DIR}/dump-${TIMESTAMP}.rdb.gz"

3. AOF-Verzeichnisse sichern: die Besonderheiten

Bei aktivierter AOF-Persistence besteht der zu sichernde Datenbestand nicht mehr aus einer einzelnen Datei, sondern aus dem kompletten appendonlydir-Verzeichnis mit Manifest-, Basis- und Inkrement-Dateien. Ein Backup, das nur einzelne Dateien aus diesem Verzeichnis kopiert, statt des gesamten Verzeichnisbaums inklusive Manifest, führt beim Restore zu einem inkonsistenten Zustand, weil das Manifest die exakte Zuordnung zwischen Basis- und Inkrement-Dateien beschreibt.

Analog zum RDB-Backup empfiehlt sich vor dem Kopieren ein expliziter BGREWRITEAOF, um eine frische, kompakte Basis-Datei zu erzwingen, statt eine potenziell große Inkrement-Datei mitzusichern. Wichtig ist, während des Kopierens des kompletten Verzeichnisses keine Datei zu verpassen, falls Redis zwischen dem Start und dem Ende des Kopiervorgangs neue Inkrement-Dateien anlegt, etwa durch einen parallel laufenden Rewrite. Ein atomarer Snapshot des Dateisystems, etwa über LVM oder ZFS, umgeht dieses Problem vollständig.

#!/usr/bin/env bash
# aof_backup.sh - Backup the complete AOF directory consistently
set -euo pipefail

AOF_DIR="/var/lib/redis/appendonlydir"
BACKUP_DIR="/var/backups/redis"
TIMESTAMP="$(date +%Y%m%d-%H%M%S)"

mkdir -p "$BACKUP_DIR"

# Force a fresh, compact base file before copying
redis-cli BGREWRITEAOF
while [[ "$(redis-cli INFO persistence | grep aof_rewrite_in_progress | cut -d: -f2 | tr -d '\r')" == "1" ]]; do
  sleep 1
done

# Copy the entire directory (manifest + base + increment files together)
tar -czf "${BACKUP_DIR}/aof-${TIMESTAMP}.tar.gz" -C "$(dirname "$AOF_DIR")" "$(basename "$AOF_DIR")"
echo "[OK] AOF backup written: ${BACKUP_DIR}/aof-${TIMESTAMP}.tar.gz"

4. Backup-Jobs automatisieren: Cron, Systemd-Timer, Retention

Manuelle Backups sind für den produktiven Betrieb wertlos, weil sie unweigerlich vergessen werden. Die Automatisierung über Cron oder, in modernen Linux-Distributionen bevorzugt, über Systemd-Timer stellt sicher, dass Backups zuverlässig zu festen Zeitpunkten laufen, unabhängig von menschlicher Erinnerung. Ein Systemd-Timer bietet gegenüber Cron den Vorteil integrierter Logging-Möglichkeiten über journalctl und die Option Persistent=true, die verpasste Läufe nach einem Server-Neustart automatisch nachholt.

Genauso wichtig wie die Ausführung ist eine klare Retention-Policy: Ohne automatisches Löschen alter Backups läuft die Backup-Partition irgendwann voll, mit potenziell fatalen Folgen, falls dadurch auch neue Backups fehlschlagen. Eine bewährte Staffelung hält tägliche Backups für zwei Wochen, wöchentliche Backups für drei Monate und monatliche Backups für ein Jahr, wodurch sowohl kurzfristige Fehler als auch länger zurückliegende Datenzustände wiederherstellbar bleiben, ohne unbegrenzt Speicherplatz zu verbrauchen.

# /etc/systemd/system/redis-backup.service
[Unit]
Description=Redis RDB backup job
After=redis.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/rdb_backup.sh
User=redis

# /etc/systemd/system/redis-backup.timer
[Unit]
Description=Run Redis backup daily at 02:30

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

# Retention cleanup: keep 14 daily, 12 weekly, 12 monthly backups
find /var/backups/redis -name "dump-*.rdb.gz" -mtime +14 -delete

5. Backups auf Konsistenz prüfen

Ein Backup, das lediglich erfolgreich kopiert wurde, ist noch kein verifiziertes Backup. Nach dem Kopieren sollte jede RDB-Datei mit redis-check-rdb auf strukturelle Konsistenz geprüft werden, bevor sie als gültig markiert wird. Das Werkzeug liest die Datei komplett ein, validiert die interne Struktur gegen das RDB-Format und prüft optional die CRC64-Checksumme am Dateiende, sofern rdbchecksum beim Schreiben aktiv war.

Diese Prüfung deckt Probleme auf, die beim reinen Kopieren nicht auffallen würden, etwa eine durch einen fehlerhaften Datenträger korrumpierte Kopie oder ein abgebrochener Kopiervorgang über ein instabiles Netzwerk. Backups, die diese Prüfung nicht bestehen, sollten sofort einen Alarm auslösen, statt stillschweigend als vermeintlich valide Sicherung im Bestand zu verbleiben, bis Monate später ein tatsächlicher Restore-Versuch das Problem erst offenbart.

6. Restores regelmäßig testen, nicht nur planen

Der wohl häufigste Fehler in Backup-Strategien ist, ausschließlich das Backup selbst zu testen, niemals aber den vollständigen Restore-Prozess. Ein Backup, dessen Wiederherstellung im Ernstfall zum ersten Mal ausprobiert wird, ist ein unkalkuliertes Risiko: Fehlende Berechtigungen, falsch dokumentierte Pfade oder ein vergessener Konfigurationsschritt fallen sonst genau dann auf, wenn keine Zeit mehr für Fehlerbehebung bleibt.

Ein regelmäßiger, automatisierter Restore-Test, etwa monatlich auf einer isolierten Test-Instanz, deckt genau diese Lücken auf, bevor sie im Ernstfall zum Problem werden. Der Test sollte den kompletten Prozess durchlaufen: Backup-Datei aus dem Archiv holen, auf einer frischen Redis-Instanz einspielen, Datenintegrität stichprobenartig prüfen und die benötigte Zeit protokollieren. Diese gemessene Recovery-Zeit ist der einzige belastbare Wert für ein realistisches Recovery Time Objective.

#!/usr/bin/env bash
# restore_test.sh - Automated monthly restore drill on an isolated instance
set -euo pipefail

LATEST_BACKUP=$(ls -t /var/backups/redis/dump-*.rdb.gz | head -1)
TEST_DIR="/tmp/redis-restore-test"
START_TIME=$(date +%s)

mkdir -p "$TEST_DIR"
gunzip -c "$LATEST_BACKUP" > "${TEST_DIR}/dump.rdb"

# Validate structure before starting a server against it
redis-check-rdb "${TEST_DIR}/dump.rdb"

# Start an isolated instance on a non-default port for verification
redis-server --port 6390 --dir "$TEST_DIR" --daemonize yes
sleep 2

KEY_COUNT=$(redis-cli -p 6390 DBSIZE)
redis-cli -p 6390 SHUTDOWN NOSAVE

ELAPSED=$(( $(date +%s) - START_TIME ))
echo "[OK] Restore drill complete: ${KEY_COUNT} keys loaded in ${ELAPSED}s"

7. Off-Site-Aufbewahrung: 3-2-1-Regel für Redis

Die klassische 3-2-1-Backup-Regel gilt unverändert für Redis-Datenbestände: mindestens drei Kopien der Daten, auf mindestens zwei unterschiedlichen Speichermedien, davon mindestens eine Kopie physisch an einem anderen Standort. Die produktive RDB- oder AOF-Datei zählt als erste Kopie, ein lokales Backup auf einem separaten Datenträger als zweite, und eine Kopie in einem anderen Rechenzentrum oder Cloud-Storage-Bucket als dritte, off-site gelagerte Kopie.

Diese dritte Kopie schützt vor Szenarien, die eine rein lokale Backup-Strategie nicht abdeckt: ein Brand oder eine Überflutung im Rechenzentrum, ein kompletter Anbieterausfall oder ein kompromittierter Root-Zugang, der sowohl produktive Daten als auch lokale Backups gleichzeitig löscht. Für die Übertragung eignen sich verschlüsselte Uploads zu Object-Storage-Diensten, wobei die Backup-Datei bereits vor der Übertragung lokal verschlüsselt werden sollte, statt sich allein auf Transport-Verschlüsselung zu verlassen.

#!/usr/bin/env bash
# offsite_sync.sh - Encrypt and upload backups off-site
set -euo pipefail

BACKUP_FILE="$1"
ENCRYPTED="${BACKUP_FILE}.enc"

# Encrypt locally before leaving the host (do not rely on transport TLS alone)
openssl enc -aes-256-cbc -pbkdf2 -salt \
  -in "$BACKUP_FILE" -out "$ENCRYPTED" \
  -pass file:/etc/redis/backup.key

# Upload to off-site object storage (example: S3-compatible endpoint)
aws s3 cp "$ENCRYPTED" "s3://redis-backups-offsite/$(basename "$ENCRYPTED")" \
  --storage-class STANDARD_IA

rm -f "$ENCRYPTED"
echo "[OK] Off-site copy uploaded and local encrypted artifact removed"

8. Der eigentliche Restore-Prozess Schritt für Schritt

Ein Restore beginnt immer mit dem Stoppen der Ziel-Redis-Instanz, damit keine widersprüchlichen Schreiboperationen während des Wiederherstellens auftreten. Anschließend wird die gesicherte RDB-Datei, oder im Fall von AOF das komplette appendonlydir-Verzeichnis, an die in redis.conf konfigurierte Position kopiert, wobei bestehende, möglicherweise beschädigte Dateien vorher gesichert statt einfach überschrieben werden sollten, für den Fall, dass der Restore selbst fehlschlägt.

Nach dem Kopieren wird die Redis-Instanz gestartet und die Logs auf Fehler beim Laden geprüft, insbesondere auf Checksummen-Fehler oder Formatprobleme. Ein abschließender Vergleich der Schlüsselanzahl über DBSIZE gegen einen bekannten Referenzwert sowie stichprobenartige Prüfungen einzelner kritischer Keys geben zusätzliche Sicherheit, dass der Restore tatsächlich vollständig und korrekt war, bevor die Instanz wieder für produktiven Traffic freigegeben wird.

9. Typische Fehler in Backup-Strategien

Der häufigste Fehler ist, Backups zwar zu erstellen, aber niemals einen Restore zu testen. Damit bleibt völlig unklar, ob der Backup-Prozess tatsächlich funktioniert, bis genau in dem Moment, in dem es darauf ankommt. Ein zweiter verbreiteter Fehler ist, Backups auf demselben physischen Server oder derselben Storage-Instanz wie die produktiven Daten zu lagern, wodurch ein einzelner Hardware-Ausfall sowohl Produktivdaten als auch deren Sicherung gleichzeitig vernichtet.

Ein dritter Fehler betrifft fehlende Alarmierung bei fehlgeschlagenen Backup-Jobs: Ein Cron-Job, der seit Wochen fehlschlägt, ohne dass jemand benachrichtigt wird, ist funktional gleichwertig mit gar keinem Backup, mit dem einzigen Unterschied, dass ein trügerisches Gefühl der Sicherheit besteht. Jeder Backup-Job sollte seinen Exit-Code und seine Log-Ausgabe an ein Monitoring-System melden, das bei Fehlschlägen aktiv alarmiert, statt sich auf gelegentliches manuelles Prüfen zu verlassen.

10. Zusammenfassung

Eine robuste Backup-Strategie für Redis unterscheidet sich fundamental von reiner RDB- oder AOF-Persistence: Sie erzwingt frische, konsistente Snapshots vor jeder Kopie, automatisiert die Ausführung mit klarer Retention-Policy, prüft jede Sicherung mit redis-check-rdb auf strukturelle Integrität und testet den kompletten Restore-Prozess regelmäßig auf einer isolierten Instanz. Ohne diese Elemente bleibt ein Backup eine unbewiesene Annahme statt einer belastbaren Absicherung.

Die 3-2-1-Regel mit mindestens einer verschlüsselten Off-Site-Kopie schützt zusätzlich vor Szenarien, die eine rein lokale Sicherung nicht abdeckt, von Hardware-Defekten bis zu kompromittierten Zugängen. Wer diese Elemente konsequent kombiniert, verwandelt Backups von einer theoretischen Checkbox in einen tatsächlich funktionierenden Sicherheitsmechanismus für den Ernstfall.

11. FAQ: Backup- und Restore-Strategien für Redis