KeyHelp Community

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
eher ein restic Problem welches sich aber nicht über die GUI lösen lässt.


Server-Betriebssystem + Version
Debian 10.13 (64-bit)


Eingesetzte Server-Virtualisierung-Technologie
keine


KeyHelp-Version + Build-Nummer
24.1 (Build 3285)


Problembeschreibung / Fehlermeldungen
Seit einer Woche kann restic kein Backup mehr erstellen. Außer der Meldung "Startet in Kürze" passiert nichts. Im Gegenteil, jeden Tag wird eine neue Backup-Instanz gestartet mit "Startet in Kürze". Aber nix startet.
Sicherungsziel ist eine Hetzner Storage Box welche bisher problemlos funktioniert hatte. Speicherplatz ist dort auch verfügbar (gerade geprüft). Sämtliche Einstellungen, Passwörter etc. sind unverändert. restic hat einfach von heute auf morgen aufgehört zu arbeiten.

Gibt es separate restic-Logfiles?
Wo finde ich diese?

Erwartetes Ergebnis
Durchlaufendes restic-Backup

Tatsächliches Ergebnis
Außer der Meldung "Startet in Kürze" passiert nichts.

Schritte zur Reproduktion
keine Ahnung

Zusätzliche Informationen
Backup-Software: Restic 0.16.4
Backup-Datenübertragung: Rclone 1.66.0

Kann ich mal auf dem Server nachschauen? (-> PM mit Zugangsdaten)
Hat mit dem Backup an sich wahrscheinlich gar nichts zu tun.

Ich habe den aktuellen Job, der mit Status "Startet in Kürze" markiert ist einmal gelöscht um zu sehen, was passiert wenn ich einen neuen Job starte.

Im Log fand sich dann (update.log):

[25-Jun-2024 11:30:22] INFO | Backup: Pending operation "backup" found for repository #6
[25-Jun-2024 11:30:22] INFO | Backup: Repository is locked, this operation is performed after it has finished its current operation.
[25-Jun-2024 11:30:22] INFO | Backup: Check for outdated operations

Also habe ich dann über Problembehandlung für dieses Repository einmal "Repository entsperren" laufen lassen.

Anschließend startete der Backup-Job, der zuvor noch "Startet in Kürze" hatte automatisch.

-> Erledigt

Dankeschön Alex.

Warum wurde denn dieser „locked“ Status nicht angezeigt?
In der Vergangenheit konnte man sowas doch in der GUI sehen?

Hast du das Repo an anderer Stelle (anderer Kunde, anderer/alter Server, etc.) auch eingebunden, oder einen manuellen Zugriff versucht?

Der Log Eintrag lässt darauf schließen, das von anderer Stelle das Repo auf locked gesetzt wurde.

... Oder du hast die Jobs, bei denen die Fehlermeldung dabei stand, dass das Repo gelockt ist, bereits gelöscht (z.B. über Problembehandlung -> Abgebrochene Operationen löschen)

Tatsächlich beides, anderer Server und gelöschte Aktion.
In der Vergangenheit war der lock jedoch angezeigt worden.

Kann man den das Entsperren auch einfach „auf Verdacht“ durchführen, oder kann da was kaputt gehen?

Tatsächlich beides, anderer Server und gelöschte Aktion.
In der Vergangenheit war der lock jedoch angezeigt worden.

Es wird auch irgendwo gestanden haben (an dem Code, der für das Anzeigen der beiden Meldungen verantwortlich ist, hat sich nichts geändert), aber wurde dann wahrscheinlich durch oben genannten Punkt ' Abgebrochene Operationen löschen' o.Ä. gelöscht.

Kann man den das Entsperren auch einfach „auf Verdacht“ durchführen, oder kann da was kaputt gehen?

Wenn in ein Repo von gleichzeitig von mehreren Stellen beschrieben werden soll (z.B. zwei Server sichern in das selbe repo), dann wäre es ungünstig (dafür ist das Lock ja in erster Linie da). Wenn das nicht der Fall ist, dann ist es unproblematisch.

Wenn ich das richtig raus höre ist demnach die empfohlene Variante: Ein Repository pro Server.
Da werde ich mal umstellen müssen.

Alexander wrote: ↑Tue 25. Jun 2024, 16:06 Wenn in ein Repo von gleichzeitig von mehreren Stellen beschrieben werden soll (z.B. zwei Server sichern in das selbe repo)

Helft mir mal bitte weiter...Warum sollte man überhaupt von zwei verschiedenen Servern ins selbe Repo sichern?
Mir fällt da auf Anhieb kein Szenario ein, wo das Sinn macht...

Transfer von Server alt nach neu.

Wobei dieser spezielle Server sich eigentlich nur eine Storagebox und kein Repro mit nem anderen Server geteilt hat.

Also beide haben dieselben Zugangsdaten, lagern ihre Repros aber in unterschiedlichen Unterordnern.