Fehlgeschlagene Backups beheben
Wenn ein Backup scheitert, sagt Dockstash es laut und zeigt genau wo: eine Alert-Mail mit dem Fehler, ein Status-Badge auf der Projektkarte und die volle restic-Ausgabe im Live-Log-Panel. Dieser Guide geht die häufigen Fehlerbilder durch — rote Läufe, Offline-Agenten, der Stille-Alarm — und ihre Fixes.
So geht's
Bei der Projektkarte anfangen
Der Projects-Bildschirm zeigt pro Projekt Status-Badge, letzte Backup-Zeit und Größe. Ein gescheiterter Lauf kommt zusätzlich als Alert-Mail mit Fehler und Direktlink — starten Sie bei einem von beiden. Die Detailansicht zeigt das letzte Fehlschlag-Detail direkt.
Die restic-Ausgabe des Laufs lesen
Öffnen Sie das Log-Panel des fehlgeschlagenen Laufs. Die letzten Zeilen benennen fast immer die Ursache: authentication failed (SSH-Key oder DB-Zugangsdaten), no space left on device (Storage-Box voll), connection refused (Storage-VPS unerreichbar) oder ein Dump-Befehlsfehler aus dem Container.
Veraltete restic-Locks heilen sich selbst
Ist ein Lauf abgestürzt oder der Server mitten im Backup neu gestartet, kann das Repository gesperrt bleiben. Kein Eingriff nötig: Der nächste Lauf erkennt den verwaisten Lock und führt automatisch restic unlock aus. Ein von einem wirklich laufenden Job gehaltener Lock wird nie gebrochen.
Agent-Projekte: zuerst den Agenten prüfen
Hört ein Fleet-Agent-Projekt auf zu sichern, schauen Sie auf den Fleet-Bildschirm. Offline heißt: Heartbeats blieben aus — auf dem VPS prüfen, ob beide Agent-Container laufen, die Dockstash-URL erreichbar ist und das Token nicht rotiert wurde, ohne den Container zu aktualisieren. Wiederholte 401er in den Logs bedeuten: Irgendwo heartbeatet noch ein alter Container mit widerrufenem Token.
docker compose -f docker-compose.agent.yml ps„Kein Backup lief"-Alerts verstehen
Eine Heartbeat-Alert heißt: Im Fenster landete kein erfolgreiches Backup — nichts schlug fehl, nichts lief. Übliche Verdächtige: Zeitplan deaktiviert, Tarif ohne Zeitpläne, Projekt nach Downgrade pausiert, zugewiesener Agent offline. Ursache beheben — der nächste grüne Lauf löscht den Alarm.
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
Verwandte Guides
Einen Fleet-Agenten verbinden
Betreiben Sie einen kleinen, nur ausgehend kommunizierenden Agenten auf jedem VPS und sichern Sie dessen Container aus einem Dashboard — Registrierung, Installation, Projektverzeichnisse und erste Zuweisung.
Alerts & Benachrichtigungen einrichten
Fehler-Mails, ein Dead-Man's-Switch-Heartbeat gegen stille Ausfälle, Webhook-Verteilung an Slack oder PagerDuty und ein unveränderlicher Audit-Trail.
MySQL
MySQL unter Docker sichern
MongoDB
MongoDB unter Docker sichern
Häufig gestellte Fragen
Ein Backup schlug einmal fehl und gelang beim Retry. Muss mich das kümmern?
Auf den Fehlergrund schauen. Jobs wiederholen mit gedeckeltem exponentiellem Backoff — transiente Netzwerk-Schluckaufe heilen sich selbst. Wiederkehrende Retries auf demselben Fehler — volllaufende Platte, wackliges SSH — verdienen einen echten Fix, bevor sie zum harten Ausfall werden.
Warum wartet mein zweiter Zeitplan, statt zu laufen?
Ein Job pro Repository, immer. Gleichzeitige restic-Operationen korrumpieren Repositories, kollidierende Zeitpläne auf demselben Repo werden also bewusst serialisiert. Verschiedene Repos laufen parallel.
Der Add-Project-Picker meines Agenten ist leer. Warum?
Der Picker liest den Snapshot, den der Agent beim letzten Heartbeat gepusht hat. Leer heißt: Der Agent hat noch nie berichtet, ein Projektverzeichnis ist im Agent-Container nicht wirklich gemountet, oder der Docker-Socket-Proxy ist unerreichbar — das Banner im Picker sagt, was es ist. Beheben, dann Refresh now klicken statt auf den nächsten Discovery-Zyklus zu warten.
Wie beweise ich, dass das Repository selbst gesund ist?
Einen Check-Job laufen lassen. restic check verifiziert die Repository-Struktur; mit einem Read-Data-Prozentsatz liest und prüft es auch echte Pack-Inhalte. Bestanden erfordert Exit-Code null — kein falsches Grün.
Wo sehe ich, warum ein Drill fehlschlug?
Das Drill-Ergebnis speichert eine Detailmeldung samt Abweichungszahl, sichtbar im Restore-drill-Tab und in der Alert-Mail. Byte-Abweichungen deuten auf Dateien, die sich während des Backups änderten; Zeilen-Abweichungen auf Dump-Konsistenz — in beiden Fällen gilt das Backup als unbewiesen, bis ein neuer Lauf besteht.