Redis-Backup und -Restore (RDB, AOF, Replica und Cluster)

Richtet für ein installiertes Redis oder Valkey (Einzelinstanz, Master/Replica mit Sentinel oder Redis Cluster) eine Backup-Routine ein und beschreibt die Wiederherstellung aus dem Backup. Schritt für Schritt: RDB-Backups (save-Regel, BGSAVE, LASTSAVE, Kopie von dump.rdb) und AOF-Backups (BGREWRITEAOF, mehrteiliges appendonlydir ab 7.x), Backup von einer Replica, Backup aller Master in einem Cluster, Test-Restore auf einer temporären Instanz, In-Place-Restore ohne die AOF-Vorrang-Falle sowie ein geplantes Backup mit Aufbewahrung und Remote-Kopie per systemd-Timer / cron; am Ende steht ein Backup, das regelmäßig läuft und nachweislich wiederherstellbar ist. Replikation (Sentinel, Cluster) ersetzt kein Backup: Versehentlich gelöschte Daten werden auf alle Replicas übertragen. Installation und täglicher Betrieb sind in eigenen Redis-Anleitungen beschrieben.

Topologie: Einzelinstanz, Replica oder Redis-Cluster-Server (Redis 7.2 / 8.x, Valkey)

Vor dem Start

• … läuft, und in der Konfigurationsdatei … ist requirepass gesetzt (das Passwort wird aus dieser Datei gelesen). Die Installation muss mit den Pfaden aus der DBAtlas-Anleitung …Redis Cluster…Redis Sentinel… erfolgt sein; weichen sie ab, passe die Pfade an.
• … liegt auf einer anderen Disk als die Daten oder auf einer Netzwerkfreigabe; der freie Platz beträgt mindestens die Datengröße im Speicher (used_memory) mal Aufbewahrungsdauer. Zusätzlich braucht das Datenverzeichnis für BGSAVE genug freien Platz, um das neue RDB zu schreiben.
• BGSAVE/BGREWRITEAOF arbeiten mit einem Fork: Abhängig von der Schreibrate wird zusätzlicher Speicher benötigt (Copy-on-Write). vm.overcommit_memory = 1 muss gesetzt sein; sonst schlägt der Fork mit „Can't save in background: fork: Cannot allocate memory“ fehl.
• Die für das Backup verwendeten Befehle (CONFIG, BGSAVE, LASTSAVE, BGREWRITEAOF…, CLUSTER, SYNC…) sind nicht per rename-command deaktiviert, und der Benutzer, dem das Passwort gehört (default), darf sie ausführen.
• Du hast root- oder sudo-Rechte. Ist ein In-Place-Restore geplant, ist ein Wartungsfenster vereinbart und das Anwendungsteam informiert.

Phasen der Anleitung

• Aktuelle Persistenz-Einstellungen — Persistenz- und Rolleninformationen prüfen · RDB-save-Regel setzen · AOF zur Laufzeit aktivieren · Backup-Verzeichnis vorbereiten
• RDB-Backup — Prüfen, ob die Replica aktuell ist · Aktuelles RDB mit BGSAVE erstellen · dump.rdb in das Backup-Verzeichnis kopieren und prüfen · Cluster-Master auflisten · Von jedem Master ein RDB holen (--rdb)
• AOF-Backup — AOF verdichten (BGREWRITEAOF) · appendonlydir sichern · AOF-Dateien prüfen
• Test-Restore (temporäre Instanz) — RDB auf einer temporären Instanz öffnen · Mit der Quelle vergleichen und temporäre Instanz beenden · AOF-Backup auf einer temporären Instanz öffnen
• In-Place-Restore — Dienst stoppen und aktuelle Dateien beiseitelegen · RDB-Backup an seinen Platz legen · AOF vorübergehend deaktivieren · AOF-Backup an seinen Platz legen · Dienst starten und Daten prüfen · AOF zur Laufzeit wieder aktivieren …
• Geplantes Backup und Aufbewahrung — Backup-Skript schreiben · Skript ausführbar machen · SSH-Zugang zum Remote-Server vorbereiten · systemd-Service und -Timer anlegen · Geplantes Backup manuell auslösen und prüfen · cron-Job schreiben …
• Monitoring — Persistenz und Backup-Alter überwachen · Regelmäßige Restore-Übung