Restic 0.16.3 und Repository Version

[rf-leo]

Hallo Zusammen,

da ich in jüngerer Vergangenheit wiederholt kleine temporäre Auffälligkeiten bei dem Speichern eines Backups hatte, habe ich mich dessen mal tiefergehend angenommen.
Erwähnen muss ich noch, dass Keyhelp auf eine VPS-Instanz läuft und die Backups beim selben Betreiber auf einen 's3-Object-Storage' geschrieben werden.

angefangen hat es mit einer Meldung in Keyhelp:

Code: Select all

Failed to create backup: Fatal: unable to open repository at rclone:rclone-storage:/wetter-vps.keyhelp/rep-02/: error talking HTTP to rclone: Get "http://localhost/file-14253643478655775433": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Über ein mount des betroffenen Repository mit 's3fs' habe ich anschließend die Struktur & Integrität geprüft ...

Code: Select all

restic -r /mnt/obsbu/rep-02 check --read-data

... mit dem Ergebnis ...

Code: Select all

using temporary cache in /tmp/restic-check-cache-2730902778
enter password for repository:
repository daf1ae2e opened (version 1)
created new cache in /tmp/restic-check-cache-2730902778
create exclusive lock for repository
load indexes
[0:02] 100.00%  1 / 1 index files loaded
check all packs
check snapshots, trees and blobs
[0:03] 100.00%  7 / 7 snapshots
read all data
[11:50] 100.00%  763 / 763 packs
no errors were found

... also alles in Ordnung.
Ein manuelles anstoßen des entsprechenden Backups lief dann auch wieder ohne Probleme durch. - Also mal wieder eine temporäre Auffälligkeit.

Worauf ich aber nun aufmerksam geworden bin, ist die Repository-Version. In der letzten zitierten Meldung wird 'version 1' ausgegeben.
In der offiziellen Restic-Doku wird aber auch von einer 'Version 2' gesprochen mit gewissen Änderungen.
Quelle: https://restic.readthedocs.io/en/stable ... -version-2

Jetzt mein eigentliches Anliegen:
Gibt es Gründe oder gar Notwendigkeiten die 'Version 1' beizubehalten? (Es gäbe eine upgrade-Möglichkeit für das Repro zu V2.)
Könnte eine modernisierte 'Version 2' evtl. meine Auffälligkeiten beheben?
Gibt es hierzu Erfahrungen aus der Community?

Feedback ist gerne willkommen!

Gruß
Rainer

[Tobi]

Ich meine auch das in KeyHelp integrierte restic verwendet aktuell bereits Version 2.
Leider gibt es keine Upgrade-Möglichkeit.
Du musst das alte Archiv löschen und komplett neu anlegen.

Dann profitierst du auch von der Komprimierung und dein neues Archiv hat dann auch Version 2.

[rf-leo]

Hallo Tobi,

vielen Dank für deine Ausführung.

Die von mir erwähnte upgrade-Möglichkeit bezieht sich auf die Restic-Doku, in welcher hiervon berichtet wird.
Quelle: https://restic.readthedocs.io/en/stable ... at-version

... versucht habe ich es noch nicht.

Gruß
Rainer

[Tobi]

Ah O.K.
Dann scheint das sogar möglich.

Ich hatte mich nur an Alex Aussage zu diesem Thema erinnert. (Letzte Abschnitt)
Beitrag damals: viewtopic.php?p=42187#p42187


Vielleicht hat er noch eine detaillierte Meinung. Aber bis Montag ist Alex im Wochenende.

[rf-leo]

... danke für den Link.

Darin gibt es ja indirekt schon die Antwort auf die verwendete Version und auf eine meiner Fragen.
Ein schneller Test hat es dann auch bestätigt, alle neuen Repros laufen in der Version 2 mit Komprimierung.

Darauf hin habe ich entsprechend der verlinkten Doku weitere Tests gemacht und kann nun betätigen, dass ein upgrade vorhandener Backups zu Version 2 ohne Probleme möglich ist und bei mir sauber mit einen kleineren Backup durchgelaufen ist.

Für alle Interessierten: Somit gibt es zwei Möglichkeiten in den Genuss der V2 zu kommen. Entweder neu anlegen oder die Upgrade-Möglichkeit.

Die bei mir aufgetretenen Auffälligkeiten werde ich weiter im Auge behalten ...

Thema kann als erledigt betrachtet werden - Dankeschön!
Und, lassen wir dem Alex sein wohlverdientes Wochenende!

Gruß
Rainer

[Alexander]

Als Ergänzung zu Tobis aussagen.

Leider gibt es keine Upgrade-Möglichkeit.

Das ist so zu verstehen, dass es im KeyHelp keine Updatemöglichkeit für alte Repositories geben wird. Manuell kann man das natürlich gern so, wie von rf-leo auch getan, selbst durchführen.

[rf-leo]

... jup, hätte ich vlt. erwähnen sollen, dass ich das Upgrade über die CLI laufen lassen habe.

Letzte Nacht hatte ich wieder Auffälligkeiten der Art wie in der ersten zitierten Meldung "... unable to open repository ...", auch gleich mehrere.
Ein Blick ins Log und in die protokollierten Zeiten lässt mich vermuten, dass nun über das Öffnen des Repos und die Dekomprimierung es länger braucht und es in einen timeout endet.

Nun gibt es in Restic die Möglichkeit über das Flag '-o' Optionen anzugeben, u.a. dieses:

Code: Select all

-o rclone.timeout specifies timeout for waiting on repository opening, the default value is 1m

... im Log wurde die Default-Minute bei mir überschritten.
Quelle: https://restic.readthedocs.io/en/stable ... via-rclone

Jetzt möchte ich Versuche mit der genannten Option tätigen. Nur leider fehlt mir der Ansatz, wo ich dieses hinzufügen soll oder kann.
Hier möchte ich nun gerne eure Hilfe erbitten.

Gruß
Rainer

[Alexander]

Diese Option kannst du aktuell nicht hinterlegen.
Ist mir aktuell aber auch noch nie (bewusst) untergekommen, dass es am Öffnen des Repos wegen timeout gescheitert ist. hmm

[rf-leo]

Da ich weiterhin temporäre Auffälligkeiten habe, möchte ich mich weiter auf die Fehlersuche begeben. Eine weitere These meinseits ist das Netzwerk ...
Nur leider komme ich mit den bisher zur Verfügung stehenden Logs nicht weiter. Meine manuellen Versuche laufen ohne Fehler durch. Nur des Nachts und unter dem Aspekt das der Restic-Backup-Befehl aus KeyHelp heraus gestartet wird, treten dann und wann mal die Auffälligkeiten auf.

In Restic gibt es eine Möglichkeit umfangreiche Debug-Logs schreiben zu können.
Quelle: https://restic.readthedocs.io/en/stable ... ating.html
... wie z.B. von mir bei den manuellen Versuchen:

Code: Select all

DEBUG_LOG=/var/log/restic-debug.log restic -r /mnt/obsbu/rep-02 ... 

@Alexander
Könntest du dir vorstellen einen "Schalter" einzubauen, der auf bewusstes Einschalten eines gewählten Pepository hin dann eine "restic-debug.log" schreibt?
Oder eine andere Möglichkeit an solch eine Debug-Log zu kommen?

Gruß
Rainer

[Tobi]

Frage 1: Laufen mehrere Backups gleichzeitig?
Frage 2: Laufen die alle im selben Speicherplatz zusammen?
Frage 3: Laufen alle Backups unter demselben User auf dem Speicherserver?
Frage 4: Welcher Verbindungstyp?
Frage 5: Wieviele gleichzeitige Verbindungen pro Backup?
Frage 6: Wo liegt der Backupspeicher, welcher Art?

[rf-leo]

zu Frage 1: nein, die Backups wurden zeitlich bewusst entkoppelt und überschneiden sich auch nicht.
zu Frage 2: ja, sie laufen alle auf den selben Speicherplatz.
zu Frage 3: die Auffälligkeiten treten unter allen Usern auf.
zu Frage 4: Speicher-Typ: Benutzerdefiniert - type = s3; provider = Ceph
zu Frage 5: Anzahl Verbindungen kann ich nicht benennen; bei der Backup-Konfiguration kein CPU-Kern-Limit, Multithreading ist aktiviert.
zu Frage 6: wie im ersten Beitrag erwähnt: "... Keyhelp auf eine VPS-Instanz läuft und die Backups beim selben Betreiber auf einen 's3-Object-Storage' geschrieben werden."

Gruß
Rainer

[Tobi]

Kannst du testweise auf einen alternativen Speicher ausweichen und prüfen ob die Probleme auch weiterhin bestehen?

[rf-leo]

... ich werde weitere Versuche unternehmen, evtl. auch mit alternativen Speicher und später dann mal berichten.

Gruß
Rainer