KeyHelp Community

Hallo,

Die neuen Backups mit restic sind top. Ich hatte Restic schon vorher manuell im Einsatz, um ein Shared Webhosting auf einen anderen Server zu backuppen und es ist in KeyHelp wirklich äußerst komfortabel umgesetzt.
Mir ist auch bereits eine Wiederherstellung einer Systemdatei gelungen. Und es war eine sehr gute Usererfahrung. Fantastisch!

Leider sind die letzten manuell ausgeführten Backups nicht fertig geworden und hängen im Zustand "Startet in Kürze".
Ich habe einen Screenshot angehängt, der dies verdeutlicht.

Woran kann das liegen, welche logs soll ich hier noch heraussuchen, um der Ursache auf den Grund zu gehen?

Wenn ich das Repository quasi neu anlegen möchte ist die Vorgehensweise glaube ich folgende:
Das Repository in keyhelp löschen (nur Datenbankeinträge) und dann den Ordner /backup/repository-***/ löschen (Dateien).
Damit hätte ich kein Problem, aber es wäre interessant herauszufinden woran es liegen könnte.

Der Server ist inkl. Backups mit ca. 50% belegt und sollte auch ein komplettes Backups komprimiert speichern können.

Grüße,

versuch einmal das Folgende:

1.)
Führe die folgenden Befehle aus. Hierbei wird erstmal ein Backup von 2 Dateien erstellt, die wir in Schritt 2 austauschen werden:
2.)
Anschließend tauschen wir nun 2 Dateien aus. Je nach zum Einsatz kommenden Betriebssystem bitte nur die entsprechenden Befehle ausführen:

Für Debian 10, Ubuntu 18, Ubuntu 20 Für Debian 9
3)
Jetzt sollten künftige Jobs ohne sich aufzuhängen laufen.
Nun müssen wir aber gegebenenfalls noch die Altlasten der vorherigen Jobs beiseite schaffen:

3.1 Hängenden Restic-Prozess terminieren)
Du gehst in die Prozessverwaltung im KeyHelp (Systemstatus -> Prozessverwaltung). Und suchst dort (STRG+F) alle Prozesse in denen das Wort "restic" vorkommt und terminierst diese über den Butten rechts daneben (i.d.R. sind es 3 Stück, wenn du keine mehr finden kannst -> Schritt erledigt).

3.2 Die Liste der letzen Operationen bereinigen)
Hier gehst du in die KeyHelp Datenbank in der Tabelle "backup_operations" und sortierst diese nach ID in absteigender Reihenfolge.
Anschließend siehst du oben die zuletzt eingereihten Operationen.
Hier löscht du erstmal die beiden letzten Backup Jobs (diese haben in Spalte "type" den Wert "backup" und in Spalte "state" den Wert "pending").
Als nächstes kannst du auch noch den Wiederherstellungsprozess löschen, dieser hat in Spalte "type" den Wert "restore" und unter "state" den Wert "processing".

3.3 Repository Lock entfernen)
Hierzu gehst du in der KeyHelp Datenbank in die Tabelle "backup_repositories". Hier suchst du die Zeile des entsprechenden Repositories und sollte in der Spalte "is_locked" der Wert 1 stehen, machst du daraus eine 0.

---

Anschließend sollte alles wieder normal funktionieren und künftig nicht mehr hängen bleiben.
Du kannst jetzt erneut Backup-Prozesse bzw. Wiederherstellungen starten.

---

Vielen lieben Dank für deine Worte zum Backup-System .

Alexander wrote: ↑Fri 27. Aug 2021, 14:39 Anschließend sollte alles wieder normal funktionieren und künftig nicht mehr hängen bleiben.

Vielen Dank für die ausführliche Anleitung.

Ich habe alle Schritte ausführt. Es hat geklappt, aber mit einem kleinen Stolperstein.

Beim Befolgen der Schritte gab es interessanter Weise keine Restic Prozesse in der Übersicht (/index.php?page=admin_process_manager&sid=)
Ich habe nach den Änderungen den Server komplett neu gestartet.

Damit alles frisch angelegt wird, habe ich folgende Schritte gemacht:
- Das Repository über Keyhelp gelöscht und die Dateien vom Server entfernt (wie in meinem ersten Post).
- Dann ein neues Repository erstellt.
- Ein komplettes lokales Backup manuell gestartet. (Ich sehe auch an diesem Punkt noch keine Prozesse mit Namen "Restic" in ps -aux | less oder mit Strg+R im Prozessmanager von KeyHelp. )

Es war 20 Minuten ein "Startet in Kürze" und es wurden noch keine Dateien in den neuen Backupordner hinzugefügt.
Dann plötzlich "Wird bearbeitet (92,90 %)"
Dann mit Fehler beendet.
Meldung siehe im Screenshot.

Kann ich nun davon ausgehen, dass das Backup fehlgeschlagen ist, oder ist nur diese Datei nicht lesbar gewesen?
"GeoLite2-Country.tar-qfFMB4.tmp" ist für mich nicht wichtig, aber es könnte zu einem Abbruch an dieser Stelle geführt haben. Es sind jedenfalls Dateien im Data Verzeichnis vorhanden und bei Wiederherstellen gibt es schon die gewohnte Auswahl von Verzeichnissen, Emails und Datenbanken.

Ich würde die temporären Verzeichnisse der User grundsätzlich nicht mitsichern. Das ist doch eh unnötig.

tab-kh wrote: ↑Fri 27. Aug 2021, 22:58 Ich würde die temporären Verzeichnisse der User grundsätzlich nicht mitsichern. Das ist doch eh unnötig.

Ja, guter Tipp.
Es sind doch einige Nutzer, daher habe ich keine Anpassung gemacht.

Gibt es eine empfohlene Liste an Ordnern, die man am besten auslässt?
z.B. diese:

/home/users/USER1/tmp
/home/users/USER2/tmp
/home/users/USER3/tmp
/mnt
/proc
/tmp
/backup-keyhelp
/backup
/srv
/lost+found
/media

Weitere Backups mit dieser exclude Liste sind dann fehlerfrei gelaufen.

Hier nochmal die Bestätigung von mir, dass die oben erwähnte Anleitung tatsächlich den gewünschten Erfolg bringen und empfehlenswert sind.
Dies scheint bei Installationen von KeyHelp vor der Einführung des neuen Backupsystems ein Thema zu sein.

Das exclude der erwähnten Pfade.. insbesondere von tmp ist auch die Lösung für die erwähnte Fehlermeldung. Das Backup war trotzdem so wie es scheint komplett und wurde nicht abgebrochen.

Kleine Info:

Die Tmp-Verzeichnisse sind mit dem kommenden Update im Vollbackup standardmäßig exkludiert. Damit muss man dann i.d.R. keine Anpassungen mehr selbst vornehmen.

Die anderen Pfade, die du in deiner Liste hast musst du auch nicht unbedingt mit angeben, da diese im Vollbackup ohnehin nicht gesichert werden.