Backup-Probleme nach Update auf Version 24.0

[Grauer]

---------------------------------------------------------------------------


Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum)
Ja, der Fehler trat nach dem Update auf Version 24.0 auf

Server-Betriebssystem + Version
(z.B. Ubuntu 20.04)
Debian 12

Eingesetzte Server-Virtualisierung-Technologie
(z.B. keine, OpenVZ, KVM, XEN, etc.)
keine

KeyHelp-Version + Build-Nummer
(z.B. 22.0 - Build 2366)
24.0 - Build 3218

Problembeschreibung / Fehlermeldungen
Fehler beim Backup

Code: Select all

Die folgenden Meldungen wurden protokolliert:

    Failed to prune repository: unable to create lock in backend: repository is already locked by PID 4080108 on XserverDomainX by root (UID 0, GID 0)
    lock was created at 2024-02-07 17:07:20 (5h59m51.188421901s ago)
    storage ID ef626bf1
    the `unlock` command can be used to remove stale locks

Der Lock (17:07:20:) war das letzte Backup welches vor den Update auf KeyHelp 24.0 gemacht wurde.

Erwartetes Ergebnis
Aufheben des Locks damit das Backup wieder funktioniert

Tatsächliches Ergebnis
siehe Fehlermeldung oben

Schritte zur Reproduktion
-

Zusätzliche Informationen
(z.B. kürzlich durchgeführte Änderungen am Server, Auszüge aus Protokolldateien (/var/log/*, /var/log/keyhelp/php-error.log, etc.))
KeyHelp Update von Version 23.2.1 auf 24.0

[Florian]

Hallo,

hast du den Repo Lock über die Problembehandlung schonmal entfernt und neu probiert?

[Grauer]

Hallo Florian,

Die Einstellung kannte ich noch nicht, habe sie aber jetzt gefunden und probiert.
Der Lock ist aufgehoben, aber das Backup bleibt jetzt bei

Integritätsprüfung / Statistiken aktualisieren
Wird bearbeitet (33,00 %)

stehen.

[Grauer]

Danke nochmals für den Hinweis mit dem Repo Lock über die Problembehandlung. Nachdem das Backup zuerst bei 33% stehen geblieben ist, wurde es dann doch ohne Fehlermeldung abgeschlossen. Das nächste Backup ging dann ohne irgendwelche Beanstandungen oder Verzögerungen.

[Grauer]

Leider ist das Problem doch nicht ganz behoben. Wenn ich über die Problembehandlung das Repository entsperre geht es zwar, aber nach ein paar backups ist es wieder gesperrt.

[Grauer]

So, ich habe das Repository nun nochmals entsperrt und, man weiß ja nie, den Server mal neu gestartet. Ich werde das Backup (betrifft ja komischerweise nur eines) im Auge behalten und das Ergebnis nachher berichten.

[Grauer]

Der Fehler kommt immer wieder. Ich kann das Repository entsperren und dann geht es ein paar mal und dann ist es wieder gesperrt.
Betroffen davon ist ein Repository von dreien, die anderen Beiden laufen ohne Probleme.

[Tobi]

Am Besten das korrupte Repository löschen und neu anlegen.

[Grauer]

Du hast recht. Der Gedanke ist mir auch schon gekommen und so werde ich es jetzt auch machen (das betreffende Repository ging nämlich wieder in den Lock Status)

[Grauer]

Ich glaub ich spinne. Ich habe ein neues Repository angelegt und nun nach einigen Backups genau das gleiche Problem. Wieder geht das Theater mit dem Lock los.

[Fezzi]

Ich bin mir nicht sicher ob das hier mit rein passt... aber auch ich habe seit dem Update ein noch nie dagewesenes Problemchen...
Die Repository Bereinigung bricht ab

Repository bereinigen Abgebrochen

Mein OS ist Ubuntu 20.04 LTS / KVM Virtualisierung

Die Backups laufen zwar durch, aber es findet kein Unlock statt:

Die folgenden Meldungen wurden protokolliert:

Failed to prune repository: unable to create lock in backend: repository is already locked by PID 135486 on server.phuket-hosting.com by root (UID 0, GID 0)
lock was created at 2024-02-08 21:00:31 (23h59m48.8215014s ago)
storage ID f97311bd
the `unlock` command can be used to remove stale locks

Ich konnte es manuell mit der Problembehandlung loesen... werde das mal die Tage beobachten ob es wieder vorkommt...

[Fezzi]

War bei mir wohl eine Eintagsfliege...

Gestern Nacht wurde das Repository bereinigen wieder einwandfrei durchgefuehrt...

[Grauer]

Ich hatte so eine schöne Aufschlüsselung geschrieben, aber irgendwie ist die im Nirvana verschwunden. Nun also nochmal.

Vor dem Update auf v.24 hatte ich 3 Backups und alle liefen.
+ Vollständig (1x täglich)
+ Benutzerkonten (1x täglich)
+ Datenbanken (1x stündlich)

Nach dem Update fing das Problem an dass das Datenbank-Backup Probleme machte. Nach mehreren Versuchen über die Problembehandlung (es funktionierte im Anschluss ein paar mal, ging dann aber wieder in den Lock), habe ich, wie auch Tobi vorgeschlagen hat, das Repository gelöscht und ein neues erstellt.
Leider trat bei den neuen Datenbank-Backup nach einigen Sicherungen derselbe Fehler auf.

Seit heute hat sich das Problem ausgeweitet und als ich heute Früh geschaut habe war auch das Benutzerkonten-Backup mit der selben Meldung "Failed to prune repository: unable to create lock in backend: repository is already locked by PID ..." abgebrochen.
Ich habe dieses nun auch entsperrt und werde es die nächsten Tage beobachten ob sich der Fehler auch beim täglichen Benutzerkonten-Backup wiederholt (wie es ja leider beim Datenbank-Backup immer noch der Fall ist).

[blickgerecht]

Bei uns gibt es die Probleme auch seit dem Update! Alle Backups mit dem gleichen Problem, wie beschrieben.

[blickgerecht]

Ich ergänze noch:

Die Fehlermeldung lautet nun nicht mehr, dass der Lock nicht mehr aufgehoben werden, konnte, sondern bei allen Backups in etwa so:

Code: Select all

Failed to prune repository: rclone: 2024/02/11 10:16:03 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request put error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
rclone: 2024/02/11 10:16:03 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request rcat error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
Save(<data/3743cc97e4>) returned error, retrying after 2.860775763s: server response unexpected: 500 Internal Server Error (500)
rclone: 2024/02/11 10:16:06 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request put error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
rclone: 2024/02/11 10:16:06 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request rcat error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
Save(<data/3743cc97e4>) returned error, retrying after 12.728744307s: server response unexpected: 500 Internal Server Error (500)
rclone: 2024/02/11 10:16:19 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request put error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
rclone: 2024/02/11 10:16:19 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request rcat error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
Save(<data/3743cc97e4>) returned error, retrying after 17.783238119s: server response unexpected: 500 Internal Server Error (500)
rclone: 2024/02/11 10:16:37 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request put error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
rclone: 2024/02/11 10:16:37 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request rcat error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
Save(<data/3743cc97e4>) returned error, retrying after 22.32864162s: server response unexpected: 500 Internal Server Error (500)
rclone: 2024/02/11 10:16:59 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request put error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
rclone: 2024/02/11 10:16:59 ERROR : data/37/3743cc97e4016a26f984beb73ee8c88e9a7891a9a811fc541cb154ff178af9d3: Post request rcat error: SetModTime: write tcp #Keyhelp-Server-IP#:47392->#Backup-Ziel-IP#:21: write: broken pipe
Fatal: server response unexpected: 500 Internal Server Error (500)

Das passiert aber erst beim Bereinigen des Repository. Das Backup selbst scheint durchzulaufen.