Backup-Probleme nach Update auf Version 24.0

[Henning]

Hallo zusammen,

auch ich habe Problem mit dem Backup. Anbei das Log, sowie Screenshots.

Wenn noch anderweitige Daten erforderlich sind, bitte melden.

Ich habe über die Problembehandlung das Repository entsperrt und werde berichten, ob es heute Nacht wieder normal durchgelaufen ist.

====
[10-Feb-2024 01:00:02] INFO | Create repository lock
[10-Feb-2024 01:00:04] INFO | Looking for pending operations for repository: odin.nieland.io (FTP(S)) / #1
[10-Feb-2024 01:00:04] INFO | Operation found: backup
[10-Feb-2024 01:00:04] INFO | Prepare backup...
[10-Feb-2024 01:03:05] INFO | Backup created
[10-Feb-2024 01:03:05] INFO | Cleanup
[10-Feb-2024 01:03:05] INFO | Operation found: prune
[10-Feb-2024 01:03:05] INFO | Remove old snapshots
[10-Feb-2024 01:03:10] ERROR | Failed to prune repository: unable to create lock in backend: repository is already locked by PID 2313212 on odin.nieland.io by root (UID 0, GID 0)
lock was created at 2024-02-09 01:04:04 (23h59m6.514296904s ago)
storage ID 9563b147
the `unlock` command can be used to remove stale locks
[10-Feb-2024 01:03:11] INFO | All finished, releasing lock.
====
[11-Feb-2024 01:00:01] INFO | Create repository lock
[11-Feb-2024 01:00:03] INFO | Looking for pending operations for repository: odin.nieland.io (FTP(S)) / #1
[11-Feb-2024 01:00:03] INFO | Operation found: backup
[11-Feb-2024 01:00:03] INFO | Prepare backup...
[11-Feb-2024 01:03:02] INFO | Backup created
[11-Feb-2024 01:03:02] INFO | Cleanup
[11-Feb-2024 01:03:02] INFO | Operation found: prune
[11-Feb-2024 01:03:02] INFO | Remove old snapshots
[11-Feb-2024 01:03:12] ERROR | Failed to prune repository: unable to create lock in backend: repository is already locked by PID 2313212 on odin.nieland.io by root (UID 0, GID 0)
lock was created at 2024-02-09 01:04:04 (47h59m3.652696162s ago)
storage ID 9563b147
the `unlock` command can be used to remove stale locks
[11-Feb-2024 01:03:13] INFO | All finished, releasing lock.
====

[Grauer]

Noch ein Update zum Thema.
Ich habe einen zweiten Server (einen kleinen vServer) wo ich zum ausprobieren verschiedener Dinge verwende. Auch den habe ich auf KeyHelp v24 upgedatet und siehe da, das Vollständige Backup (dort mache ich nur Vollständig 1x täglich) zeigt dort den selben Fehler: "Failed to prune repository: unable to create lock in backend: repository is already locked by PID ... "

[Henning]

Noch ein Update zum Thema.
Ich habe einen zweiten Server (einen kleinen vServer) wo ich zum ausprobieren verschiedener Dinge verwende. Auch den habe ich auf KeyHelp v24 upgedatet und siehe da, das Vollständige Backup (dort mache ich nur Vollständig 1x täglich) zeigt dort den selben Fehler: "Failed to prune repository: unable to create lock in backend: repository is already locked by PID ... "

Kann ich hier ebenfalls bestätigen. Auch auf Server 2 und 3 genau das gleiche Verhalten.

[Grauer]

Ich habe über die Problembehandlung das Repository entsperrt und werde berichten, ob es heute Nacht wieder normal durchgelaufen ist.

Du musst es länger beobachten. Bei mir war und ist es so dass es nach dem entsperren sauber durchläuft. Später aber kommt es wieder, nur kann ich kein System darin erkennen. Mal läuft es 3 mal durch, mal 5 oder gar noch öfters, aber manchmal auch nur einmal und dann kommt es wieder.

[mhagge]

Was für eine Methode wird denn für den Zugriff auf den Backup-Speicher genutzt? Im Screenshot oben scheint es FTPS zu sein.

Ich habe hier z. B.: mehr als ein dutzend geupdatete Server, wo überall das Backup problemlos durchläuft (genutzt wird allerdings durch die Bank weg SFTP - in nahezu allen Fällen mit Storage-Boxen von Hetzner oder Keydiscs von Keyhelp - in einem Fall auch auf einen anderen Server).

Das Update hat ja lt. Changelog auch eine neue Restic-Version mit sich gebracht - evtl. besteht da irgendwo ein Kompatibilitätsproblem mit dem Backup-Speicher. Vielleicht besteht die Möglichkeit, es mal mit einer anderen Methode oder einem anderen Ziel zu probieren.

[Tobi]

Fürn Start muss es kein Fullbackup sein.

Es würde reichen ein kleines Nutzerkonto lokal zu sichern.
Wenn das fehlerfrei funktioniert wird es wohl tatsächlich an dem verwendeten Protokoll liegen.

[Grauer]

Ja, alle Backups verwenden FTP(S). Der dedicated Server nutzt einen Backupspeicher des gleichen Anbieters und der vServer nutzt ebenfalls den vom Anbieter bereitgestellten Backupspeicher. Beide Anbieter, also der des dedicated Server sowie der des vServer sind jedoch verschieden.

Ich habe jetzt Testweise aber mal ein lokales Backup angelegt und werde es beobachten. Gebe dann Bescheid was dabei rausgekommen ist.

[blickgerecht]

Ich habe hier z. B.: mehr als ein dutzend geupdatete Server, wo überall das Backup problemlos durchläuft (genutzt wird allerdings durch die Bank weg SFTP - in nahezu allen Fällen mit Storage-Boxen von Hetzner oder Keydiscs von Keyhelp - in einem Fall auch auf einen anderen Server).

Meine Backups laufen auch zu einer Storagebox von Hetzner, allerdings hatte ich FTPS genutzt, statt SFTP.
Ich habe gerade testweise ein Repository von FTPS auf SFTP umgestellt – und es hat das erste mal seit dem Update geklappt.
Markus scheint da der Ursache auf der richtigen Spur zu sein.

Ich stelle mal alle Backups auf SFTP um und berichte wieder.

[Fezzi]

Was für eine Methode wird denn für den Zugriff auf den Backup-Speicher genutzt? Im Screenshot oben scheint es FTPS zu sein.

(....genutzt wird allerdings durch die Bank weg SFTP - in nahezu allen Fällen mit Storage-Boxen von Hetzner ......).

Das Update hat ja lt. Changelog auch eine neue Restic-Version mit sich gebracht - evtl. besteht da irgendwo ein Kompatibilitätsproblem mit dem Backup-Speicher. Vielleicht besteht die Möglichkeit, es mal mit einer anderen Methode oder einem anderen Ziel zu probieren.

Same here und ich hatte das Dingens jetzt einmal... Gestern Nacht lief alles normal... mal schauen ob es Morgen wieder kommt...

[tab-kh]

Also ich habe mit den Backups nach (und vor) der Umstellung nie Probleme gehabt mit meinen vier Keyhelp-Servern, die auch ein Backup (komplett, als Administrator) machen. 2x Strato Debian 11, 1x Strato Debian 12, 1x netcup Debian 12. Alle Backups laufen über Nacht um jeweils etwa eineStundeversetzt per SFTP zur selben Hetzner Storagebox. Bisher sind keine Probleme mit prune oder Locks aufgetreten. Sind da eventell das laufende Backup und das Keyhelp-Update einander in die Quere gekommen, so dass dadurch jetzt ein kompromittiertes/unvollständiges Repository entstanden ist?

[Grauer]

@tab-kh Da auch neu angelegte Repositories betroffen sind denke ich nicht dass es daran liegt das das Repository beim Update geschädigt wurde. Ich Tendiere mittlerweile auch dazu dass es eventuell am FTP(S) liegen könnte.
Das testweise Lokal gespeicherte Backup läuft bisweilen normal. Werde es aber im Auge behalten und versuchen ob alternativen zu FTP(S) möglich sind.

[Henning]

Bei mir lief es heute Nacht - nach dem gestrigen entsperren - normal mit FTP(S) durch. Mal schauen, was die Tage bringen.

[Alexander]

In der Vergangenheit gab es ab und an mal Probleme mit FTP und Restic/Rclone.
Damals war Rclone der "Schuldige" bzw. die von ihnen verwendete go FTP Bibliothek.


Dinge die Ihr einmal versuchen könnt:

1. Statt FTP eine Alternative versuchen, z.B: SFTP
2. Ein Downgrade von Restic und Rclone auf die in KeyHelp 23.2.1 aktiven Versionen

Code: Select all

# Checken der Version
rclone version
restic version

# Downgrade restic
# Download der entsprechenden Version hier: https://github.com/restic/restic/releases/v0.16.0
# restic_0.16.0_linux_amd64.bz2 oder restic_0.16.0_linux_arm64.bz2 je nach System
# Entpacken (mit "bunzip2") und dann das Binary hier überschreiben: /usr/local/bin/restic (+ chmod 0755)

# Um später wieder upzugraden reicht der Befehl
restic self-update


# Downgrade rclone
rclone selfupdate --version 1.64.0

# Um später wieder upzugraden reicht der Befehl
rclone selfupdate
# Ah, ich glaub da gab es einen Bug in 1.64.0, was das self-update außer Gefecht setzte. In dem Fall wäre das Upgrade wie folgt:
# Download der entsprechenden Version hier: https://rclone.org/downloads/
# linux_arm64 oder linux_amd64 je nach System
# Entpacken und dann das Binary hier überschreiben: /usr/local/bin/rclone (+ chmod 0755)

[Grauer]

@Alexander
Ich bin mir nun ziemlich sicher dass es, wie von dir Vermutet an FTP(S) liegt. Alle Backups die lokal gespeichert werden laufen ohne Probleme.
Gibt es Aussichten dass dieses Problem behoben wird. Ich weis nicht inwiefern KeyHelp da etwas machen kann oder ob es ein Update von Restic und Rclone benötigt.
Der von dir vorgeschlagene Workaround zum Downgrade ist zwar eine Behelfslösung, aber auch Dauer bringt es nichts wenn man mit der alten Version arbeitet und das Problem in den neuen Versionen weiterhin bestehen bleibt.

[Fezzi]

Warum stellst Du dann nicht einfach auf SFTP um? Das sollte doch mit eigentlich jedem Backup Ziel arbeiten.

Edit: bzw. aendere einfach Deine bestehenden Repositories auf SFTP und gut ist.