So sichern Sie einen Redis-Docker-Container (2026)
Sie wollen ein Redis-Backup, das sich wirklich wiederherstellen lässt? Dumpen Sie es mit `redis-cli SAVE # then capture the resulting dump.rdb` aus dem Container heraus, statt /data zu kopieren. ein SAVE/BGSAVE forkt einen zeitpunktgenauen RDB-Schnappschuss auf die Platte — gesichert wird also die fertige dump.rdb (plus AOF, falls aktiviert), nicht der flüchtige In-Memory-Zustand. Dockstash übergibt den Dump dann an restic für verschlüsselte, deduplizierte Off-Site-Snapshots.
Was Dockstash erkennt
| Erkannte Env-Keys | REDIS_PASSWORD, REDIS_ARGS |
|---|---|
| Standard-Port | 6379 |
| Live-Datenpfade (nie im Betrieb kopiert) | /data, /data/dump.rdb, /data/appendonly.aof |
| Beispiel-Images | redis:7-alpine, redis:7, redis:6, redis |
Redis mit Dockstash sichern, Schritt für Schritt
Dockstash-Konto anlegen und das Dashboard öffnen
Registrieren Sie sich kostenlos auf app.dockstash.com/register. Der einmalige Einrichtungsassistent fragt nach Ihrem Storage-VPS (der Maschine, die die verschlüsselten Backups aufnimmt) und generiert ein Verschlüsselungspasswort — speichern Sie es sofort in einem Passwort-Manager, es wird genau einmal angezeigt.
Das Docker-Projekt mit Redis hinzufügen
Auf dem Projects-Bildschirm erkennt Dockstash automatisch jeden Compose-Projektordner des Servers (standardmäßig unter /var/www). Wählen Sie das Projekt mit Ihrem Redis-Service. Noch wird nichts gesichert — Sie sagen Dockstash nur, wo das Projekt liegt.
Prüfen, dass Redis erkannt wurde
Öffnen Sie das Projekt und schauen Sie auf den Plan-Tab. Dockstash liest docker-compose.yml, erkennt das redis-Image und fügt eine Datenbank-Ebene mit der richtigen Save-und-Capture-Strategie hinzu — samt aufgelöstem Containernamen und den gefundenen Env-Keys (REDIS_PASSWORD, REDIS_ARGS). Dateien, Datenbanken und Proxy-Configs lassen sich vor dem Speichern ein- oder ausschalten.
Optional: den Snapshot von Hand gegenprüfen
Wenn Sie vor der Automatisierung einen Beweis wollen, lösen Sie dasselbe Save aus wie Dockstash: redis-cli BGSAVE im Container. Redis antwortet „Background saving started", forkt und schreibt eine zeitpunktgenaue dump.rdb nach /data. Diese fertige RDB-Datei — nie der laufende In-Memory-Zustand — wird gesichert.
docker exec <redis-container> redis-cli BGSAVESpeicherziel bestätigen
Backups liegen als verschlüsselte restic-Snapshots auf Ihrem eigenen Storage-VPS, übertragen per SSH. Haben Sie den Assistenten abgeschlossen, ist das bereits konfiguriert; Host, Benutzer, Port oder SSH-Key ändern Sie jederzeit unter Settings → Storage.
Backup-Zeitplan festlegen
Wählen Sie im Schedule-Tab des Projekts täglich, wöchentlich oder einen eigenen Cron-Ausdruck (inline validiert). Für Redis als Primärspeicher (Queues, Sessions) ist täglich die vernünftige Untergrenze, stündlich üblich. Ergänzen Sie einen wöchentlichen Prune-Zeitplan mit Ihrer Aufbewahrungsrichtlinie.
Das erste Backup jetzt ausführen
Klicken Sie auf Backup Now auf der Projektkarte. Dockstash löst ein Hintergrund-Save aus, wartet auf die fertige dump.rdb und sichert sie — zusammen mit appendonly.aof, wenn AOF-Persistenz aktiv ist — direkt in restic. Die Live-Ausgabe verfolgen Sie im Log-Panel.
Snapshot bestätigen
Nach dem Lauf zeigt die Projektkarte die neue letzte Backup-Zeit, die Snapshot-Anzahl und die Repository-Größe. Öffnen Sie den Snapshots-Bildschirm: Der Wiederherstellungspunkt erscheint in der Zeitleiste — Ihr Beweis, dass das Backup off-site angekommen ist.
Der Dump-Befehl
redis-cli SAVE # then capture the resulting dump.rdbDer Restore-Befehl
place dump.rdb in the data dir and start redis-serverein SAVE/BGSAVE forkt einen zeitpunktgenauen RDB-Schnappschuss auf die Platte — gesichert wird also die fertige dump.rdb (plus AOF, falls aktiviert), nicht der flüchtige In-Memory-Zustand.
Ein Redis-Backup wiederherstellen und beweisen, dass es funktioniert
Ein Redis-Backup wird erst real, wenn es wiederhergestellt wurde. Dockstash-Restores überschreiben Ihre Live-Instanz standardmäßig nie — Sie stellen zuerst an einen frischen Ort wieder her, prüfen die Daten und befördern sie bewusst.
Wiederherstellungspunkt wählen
Öffnen Sie Snapshots, wählen Sie das Projekt und durchstöbern Sie die Zeitleiste. Jede Zeile enthält eine vollständige zeitpunktgenaue dump.rdb (plus AOF, falls aktiviert) und die Projektdateien desselben Laufs.
An einen neuen Ort wiederherstellen
Klicken Sie auf Restore und behalten Sie den Standardmodus „Restore to new location". Tippen Sie den Projektnamen zur Bestätigung. RDB und Dateien landen im gewählten Zielpfad; die Live-Instanz bleibt unberührt.
Wiederhergestellte Daten prüfen
Legen Sie die wiederhergestellte dump.rdb ins Datenverzeichnis eines Redis-Testcontainers und starten Sie ihn — Redis lädt die RDB beim Start. redis-cli PING muss PONG liefern; prüfen Sie dann die Keys Ihrer App mit DBSIZE und ein paar GETs.
docker exec <redis-container> redis-cli PINGBei Erfolg befördern
Wenn die Daten stimmen, richten Sie Ihre App darauf aus (oder wiederholen den Restore mit „Overwrite existing" — ein expliziter Opt-in — und starten den Live-Container neu, damit er die wiederhergestellte RDB lädt). Besser: der wöchentliche Restore-Drill erbringt den Beweis automatisch.
Stolperfallen vermeiden
- Eine dump.rdb mitten im Rewrite zu kopieren liefert eine abgeschnittene Datei; erst SAVE (oder BGSAVE) auslösen, dann die fertige RDB sichern.
- Ist AOF-Persistenz aktiv, sichern Sie auch die appendonly.aof-Datei(en) — die RDB allein kann hinter den neuesten Schreibzugriffen zurückliegen.
- Ein Redis-Restore verlangt einen gestoppten oder neu gestarteten Server, um die RDB zu laden; ein Hot-Swap der dump.rdb in eine laufende Instanz ist unmöglich.
Häufige Redis-Backup-Probleme
- Symptom
- Die wiederhergestellte dump.rdb lädt nicht: „Short read or OOM loading DB" oder Fehler wegen abgeschnittener Datei.
- Ursache
- Die RDB wurde kopiert, während Redis sie noch neu schrieb — ein Zugriff mitten im Rewrite liefert eine unvollständige Datei.
- Lösung
- Immer SAVE oder BGSAVE auslösen und das Ende abwarten, bevor dump.rdb erfasst wird. Genau das tut Dockstash: Save auslösen, Abschluss abwarten, fertige Datei sichern.
- Symptom
- Ein Restore gelingt, aber die jüngsten Schreibzugriffe fehlen.
- Ursache
- AOF-Persistenz ist aktiv, und appendonly.aof enthielt neuere Schreibzugriffe als der RDB-Schnappschuss — die RDB allein hinkt hinterher.
- Lösung
- Beide Dateien sichern. Dockstash erfasst /data/dump.rdb und appendonly.aof im selben Lauf, damit der Wiederherstellungspunkt die frischesten Schreibzugriffe enthält.
- Symptom
- Die wiederhergestellte dump.rdb liegt in /data, aber der laufende Redis liefert weiter alte Daten.
- Ursache
- Redis liest die RDB nur beim Start — ein Hot-Swap in eine laufende Instanz ist unmöglich. Und mit aktiviertem appendonly lädt Redis beim Start die AOF und ignoriert die RDB komplett.
- Lösung
- Container stoppen, wiederhergestellte dump.rdb (und ggf. AOF) ins Datenverzeichnis legen, neu starten. Wurde nur eine RDB in ein AOF-Setup restauriert: für den ersten Start vorübergehend appendonly no setzen, danach wieder aktivieren.
- Symptom
- BGSAVE scheitert mit „Can't save in background: fork: Cannot allocate memory".
- Ursache
- Der für das Hintergrund-Save nötige Fork wurde von den Memory-Overcommit-Heuristiken des Kernels abgelehnt — auf einem Host mit großem Redis-Datensatz.
- Lösung
- vm.overcommit_memory=1 auf dem Docker-Host setzen (sysctl) — die Einstellung, die Redis selbst beim Start empfiehlt. Der Fork nutzt Copy-on-Write und braucht keine vollständige zweite Kopie des Datensatzes.
Mit Dockstash in einem Klick
Dockstash führt exakt den obigen Dump aus, übergibt ihn off-site an restic und drill-testet den Restore automatisch — kein Skript zu pflegen.
Zuletzt aktualisiert: July 2026
Häufig gestellte Fragen
Lohnt es sich überhaupt, Redis zu sichern?
Kommt auf die Nutzung an. Als reiner Cache füllt sich ein verlorener Redis von selbst wieder. Als Primärspeicher (Queues, Sessions, Sorted-Set-Daten): ja — RDB sichern, plus AOF, falls aktiviert.
SAVE oder BGSAVE — was nutzt Dockstash?
BGSAVE forkt und snapshottet im Hintergrund ohne zu blockieren; SAVE blockiert bis zum Ende. Dockstash bevorzugt das Hintergrund-Save und sichert dann die fertige dump.rdb.
Was ist mit AOF (Append-Only File)?
Ist appendonly aktiv, enthält die AOF die jüngsten Schreibzugriffe, die die RDB womöglich noch nicht widerspiegelt. Dockstash erfasst /data/dump.rdb und appendonly.aof, damit keine frischen Daten verloren gehen.
Kann ich dump.rdb kopieren, während Redis läuft?
Nur nach abgeschlossenem SAVE/BGSAVE. Wer während eines Rewrites kopiert, erwischt womöglich eine Teil-Datei. Dockstash löst das Save aus und wartet auf den Abschluss.
Wie oft sollte ich Redis sichern?
Richten Sie den Zeitplan am Inhalt aus. Für Queues und Sessions ist stündlich üblich; für träge Daten reicht täglich. Im Free-Tarif sind Backups manuell (Backup Now); Pro erlaubt Zeitpläne bis stündlich, Business jeden Cron-Ausdruck.
Wo liegen die Backups eigentlich?
Auf Ihrem eigenen Storage-VPS, als verschlüsselte restic-Snapshots per SSH übertragen. Dockstash hält Ihre Daten nie in einer Dritt-Cloud — Sie zeigen auf eine Maschine unter Ihrer Kontrolle, und das Repository ist mit einem Passwort verschlüsselt, das nur Sie besitzen.
Woher weiß ich, dass ein Redis-Backup wirklich wiederherstellt?
Planen Sie einen Restore-Drill. Dockstash stellt den neuesten Snapshot in einen isolierten Arbeitsbereich wieder her, vergleicht jede Datei byteweise mit der Quelle und verifiziert den erfassten Dump — dann stempelt es ein Bestanden/Fehlgeschlagen-Badge aufs Projekt. Ein wöchentlicher Drill heißt: immer frischer Beweis.