Zum Inhalt

Backup-Meldung von healthchecks.io

Ziel

Nach einer Meldung von healthchecks.io weißt du, warum das nächtliche Backup auf werner fehlgeschlagen oder ausgeblieben ist, und es gibt wieder einen erfolgreichen Lauf.

Voraussetzungen

Diese Anleitung brauchst du nur, wenn healthchecks.io eine E-Mail an it-admin@garage-lab.de geschickt hat.

Schritte

1. Art der Meldung bestimmen

Lies die E-Mail von healthchecks.io:

  • Der Lauf ist fehlgeschlagen: Die Mail meldet den Check als down nach einem Fehlersignal und enthält im Text die Fehlermeldungen aus system-backup, etwa hedgedoc backup failed oder Restic backup failed. Weiter mit Schritt 2.
  • Der Lauf ist ausgeblieben: Die Mail meldet den Check als down, weil zur erwarteten Zeit kein Signal kam, ohne Fehlermeldungen im Text. Weiter mit Schritt 3.

2. Logs des letzten Laufs lesen

Auf deinem Rechner, im Ordner syslet/werner:

Bash
1
cue cmd -t unit=system-backup.service logs

Erwartet: die Ausgabe des letzten Laufs, jede Zeile mit Zeit und [INFO], [WARN] oder [ERROR]; am Ende Backup finished with … error(s): und die Liste der Fehler. Mit Ctrl+C beendest du die Ausgabe.

Häufige Ursachen, je nach der ersten [ERROR]-Zeile:

Fehler Ursache Weiter
<app> backup failed Der Container der Datenbank lief nicht oder der Dump schlug fehl Container-Status und Logs ansehen für <app>-postgres
Restic backup failed, davor connection refused oder timeout werner erreicht den rest-server auf containerhost nicht WireGuard-Tunnel prüfen, dann ob der Container resticserver auf containerhost läuft
Restic backup failed, davor repository is already locked Ein früherer Lauf ist abgebrochen und hat eine Sperre hinterlassen Schritt 4
Failed to enable Nextcloud maintenance mode Die Nextcloud lief nicht Container-Status und Logs ansehen für nextcloud-aio-nextcloud

Behebe die Ursache und mach mit Schritt 5 weiter.

3. Timer prüfen

Im Ordner syslet/werner:

Bash
1
cue cmd -t unit=system-backup.timer status

Erwartet: Active: active (waiting) und in der Zeile Trigger: der Zeitpunkt des nächsten Laufs in der kommenden Nacht.

  • Steht dort inactive oder disabled, läuft der Timer nicht; schalte ihn wieder ein mit ssh werner.garage-lab.de systemctl enable --now system-backup.timer.
  • Ist werner in der Nacht neu gestartet oder war aus, holt systemd den Lauf nach dem Start nach; zeigt cue cmd -t unit=system-backup.service status einen Lauf nach dem Neustart mit status=0/SUCCESS, ist nichts weiter zu tun.
  • Läuft der Lauf noch (Active: activating (start)), hängt er vermutlich; sieh in die Logs wie in Schritt 2.

4. Alte Sperre im Repository entfernen

Nur bei repository is already locked, und nur, wenn kein Backup läuft:

Bash
1
2
ssh werner.garage-lab.de systemctl is-active system-backup.service
ssh werner.garage-lab.de podman exec restic restic unlock

Erwartet: zuerst inactive, dann successfully removed 1 locks.

5. Backup von Hand starten

Bash
1
ssh werner.garage-lab.de systemctl start system-backup.service

Der Befehl kehrt erst zurück, wenn der Lauf fertig ist; das kann mehrere Minuten dauern. Erwartet: keine Ausgabe. Endet der Lauf mit Fehlern, meldet systemctl Job for system-backup.service failed; dann zurück zu Schritt 2.

Prüfen

  • cue cmd -t unit=system-backup.service status zeigt status=0/SUCCESS mit der Zeit des Laufs aus Schritt 5.
  • ssh werner.garage-lab.de podman exec restic restic snapshots --latest 1 zeigt einen Snapshot von eben.
  • healthchecks.io meldet den Check wieder als up; meist kommt dazu eine E-Mail.

Wenn etwas schiefgeht