So sichern Sie einen Valkey-Docker-Container (2026)
Valkey sicher zu sichern heißt eine Regel befolgen: dumpen, nicht kopieren. `valkey-cli SAVE # then capture the resulting dump.rdb` erzeugt einen konsistenten, wiederherstellbaren Dump aus dem laufenden Container, den restic anschließend verschlüsselt off-site ablegt. 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. Alles, was /data im laufenden Betrieb kopiert, riskiert ein nicht wiederherstellbares Backup.
Was Dockstash erkennt
| Erkannte Env-Keys | VALKEY_PASSWORD, VALKEY_ARGS, REDIS_PASSWORD |
|---|---|
| Standard-Port | 6379 |
| Live-Datenpfade (nie im Betrieb kopiert) | /data, /data/dump.rdb, /data/appendonly.aof |
| Beispiel-Images | valkey/valkey:8, valkey/valkey:7, valkey/valkey |
Valkey 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 Valkey 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 Valkey-Service. Noch wird nichts gesichert — Sie sagen Dockstash nur, wo das Projekt liegt.
Prüfen, dass Valkey erkannt wurde
Öffnen Sie das Projekt und schauen Sie auf den Plan-Tab. Dockstash liest docker-compose.yml, erkennt das valkey/valkey-Image und fügt eine Datenbank-Ebene mit der richtigen Save-und-Capture-Strategie hinzu — samt aufgelöstem Containernamen und den gefundenen Env-Keys (VALKEY_PASSWORD, VALKEY_ARGS und das ältere REDIS_PASSWORD). 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: valkey-cli BGSAVE im Container. Valkey antwortet „Background saving started", forkt und schreibt eine zeitpunktgenaue dump.rdb nach /data — dieselbe von Redis geerbte RDB-Persistenz. Diese fertige Datei wird gesichert, nie der laufende In-Memory-Zustand.
docker exec <valkey-container> valkey-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 Valkey 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
valkey-cli SAVE # then capture the resulting dump.rdbDer Restore-Befehl
place dump.rdb in the data dir and start valkey-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 Valkey-Backup wiederherstellen und beweisen, dass es funktioniert
Ein Valkey-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 Valkey-Testcontainers und starten Sie ihn — Valkey lädt die RDB beim Start. valkey-cli PING muss PONG liefern; prüfen Sie dann die Keys Ihrer App mit DBSIZE und ein paar GETs.
docker exec <valkey-container> valkey-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
- Wie bei Redis: nie eine dump.rdb mitten im Rewrite greifen — erst SAVE/BGSAVE auslösen und die fertige Datei sichern.
- valkey-cli ist das Client-Binary; auf manchen Kompatibilitäts-Images ist redis-cli verlinkt — Dockstash erkennt das vorhandene.
- Aktivieren und erfassen Sie die AOF, wenn Sie die frischesten Schreibzugriffe brauchen; die RDB allein kann zurückliegen.
Häufige Valkey-Backup-Probleme
- Symptom
- Die wiederhergestellte dump.rdb lädt nicht: Fehler wegen abgeschnittener Datei oder Short-Read.
- Ursache
- Die RDB wurde kopiert, während Valkey sie noch neu schrieb — dieselbe Mid-Rewrite-Gefahr wie bei Redis, denn Valkey behält das identische RDB-Persistenzmodell.
- 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 manueller Test mit redis-cli funktioniert, aber valkey-cli meldet „not found" (oder umgekehrt).
- Ursache
- Das Client-Binary variiert je nach Image: Offizielle valkey/valkey-Images liefern valkey-cli, manche Kompatibilitäts-Images verlinken stattdessen redis-cli.
- Lösung
- Nutzen Sie das Binary, das das Image liefert — Protokoll und Befehle sind identisch. Dockstash erkennt automatisch den vorhandenen Client, Backups funktionieren so oder so.
- Symptom
- Die wiederhergestellte dump.rdb liegt in /data, aber der laufende Valkey liefert weiter alte Daten.
- Ursache
- Wie Redis liest Valkey die RDB nur beim Start — kein Hot-Swap in eine laufende Instanz. Und mit aktiviertem appendonly hat die AOF beim Start Vorrang, die RDB wird ignoriert.
- 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
- 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.
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
Wie unterscheidet sich das Valkey-Backup vom Redis-Backup?
Praktisch gar nicht. Valkey ist ein Redis-Fork und behält dasselbe RDB- und AOF-Persistenzmodell. Der einzige praktische Unterschied ist der Name des Client-Binarys (valkey-cli), den Dockstash automatisch erkennt.
Kann ich eine Redis-RDB in Valkey wiederherstellen?
Für aktuelle Versionen ja — das RDB-Format ist über den Fork-Punkt hinweg geteilt. Da die Projekte auseinanderdriften, bleiben Restores sicherheitshalber in derselben Engine.
Erkennt Dockstash Valkey automatisch?
Ja. Die valkey/valkey-Images und das valkey-cli-Binary werden erkannt, und sowohl VALKEY_PASSWORD als auch das ältere REDIS_PASSWORD werden aufgegriffen.
Sollte ich die AOF ebenfalls erfassen?
Wenn appendonly aktiv ist und Sie die letzten Sekunden an Schreibzugriffen nicht verlieren dürfen: ja. Dockstash sichert RDB- und AOF-Dateien.
Wie oft sollte ich Valkey 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 Valkey-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.