Restic: Baum e5457a72: Datei "XX": Metadatengröße (8770356) und Summe der Blobgrößen (8770808) stimmen nicht überein
Hallo,
Gerade auf Restic 0.9 aktualisiert und festgestellt, dass Restic jetzt Fehler für mein vorhandenes Repo meldet (das war mit 0.8.3 in Ordnung und wurde nach dem Upgrade nicht geändert):
error for tree e5457a72:
tree e5457a72: file "mail.err": metadata size (1085858) and sum of blob sizes (1085966) do not match
tree e5457a72: file "mail.info": metadata size (8770356) and sum of blob sizes (8770808) do not match
tree e5457a72: file "mail.log": metadata size (8770356) and sum of blob sizes (8770808) do not match
tree e5457a72: file "mail.warn": metadata size (1091226) and sum of blob sizes (1091334) do not match
Wahrscheinlich wurden Dateien geändert, während das Backup ausgeführt wurde.
Ausgabe von restic version
restic 0.9.0 compiled with go1.10.2 on linux/amd64
Wie bist du genau restic gelaufen?
restic check
Welches Backend / Server / Service haben Sie zum Speichern des Repositorys verwendet?
lokales Verzeichnis und Rest-Server
Erwartetes Verhalten
Ich verstehe, dass restic nichts tun kann, um sicherzustellen, dass die Sicherung konsistent ist (zum Beispiel, dass einige abhängige Dateien mit dem Inhalt übereinstimmen).
Aber ich bin mir ziemlich sicher, dass restic sicherstellen sollte, dass sein eigenes Repository in einem solchen Fall konsistent ist (Repository-Metadaten sollten mit Repository-Daten übereinstimmen). Wenn etwas an die Datei angehängt wurde, nachdem stat aufgerufen wurde, aber bevor die gesamte Datei gelesen wurde, sollte restic wahrscheinlich nur bis zur erwarteten Dateigröße lesen oder nur Metadaten mit der Anzahl der tatsächlich gelesenen Bytes aktualisieren.
PS. Wahrscheinlich ist dieses Problem auf 0.9 behoben und dies tritt bei neuen Snapshots nicht auf.
Aber leider kann restic rebuild-index Problem nicht beheben.
dionorgua
Alle 5 Kommentare
Ich wollte genau das gleiche Thema eröffnen wie Sie @dionorgua , Sie haben mich um 11 Minuten verprügelt. : +1:
Haben Sie die gleichen Fehler in meinem Repo (siehe unten) und teilen Sie das Gefühl, dass dies keine Fehler sein sollten, und Restic sollte es anmutig behandeln. Eine Sicherungssoftware kann nichts gegen Dateien tun, die sich darunter ändern, außer der Warnung, dass dies während des Sicherungsvorgangs geschehen ist. Aber später, wenn check wird, sollten dies keine Fehler sein oder sogar erneut gemeldet werden?
Die Ergebnisse der Überprüfung von Version 0.9.0 werden auf einem Repo ausgeführt, auf dem Version 0.8.3 keinen Fehler meldet.
check snapshots, trees and blobs
error for tree c1c7286d:
tree c1c7286d: file "panacea.dat": metadata size (5975885) and sum of blob sizes (5975910) do not match
error for tree 5908dec5:
tree 5908dec5: file "panacea.dat": metadata size (5425341) and sum of blob sizes (5425366) do not match
Fatal: repository contains errors
zcalusic
am 22. Mai 2018
Ich stimme zu, dies sollte entweder eine Warnung sein oder überhaupt nicht angezeigt werden. Es gibt nichts, was Benutzer tun können (oder müssen).
Es ist ein Fehler im alten Archivierungscode, der die falsche Größe in das Repo geschrieben hat, als die Datei angehängt wurde, während Restic sie las. Der neue Archivierer macht das nicht und alle anderen Funktionen funktionieren einwandfrei (sie verwenden nur die richtige Größe, die Summe der Dateiblöcke).
fd0
am 22. Mai 2018
Wie geht man mit diesem Problem um? Dies führt dazu, dass meine wöchentlichen automatischen Überprüfungen bei mehreren meiner Backup-Repos fehlschlagen.
Hier ist die Ausgabe meines "Restic Checks" - ich mache das über das Restic Docker Image.
...
Digest: sha256:9c851e0ba8a9c20ef853ee507af14c4d87c33661c25136262e97506a1cdc7a57
Status: Image is up to date for restic/restic:latest
ID Date Host Tags Directory
----------------------------------------------------------------------
8eb0175e 2018-02-28 21:01:38 internal-cluster /fisheye
a7848682 2018-03-31 09:28:09 internal-cluster /fisheye
8ad27273 2018-04-30 09:28:09 internal-cluster /fisheye
97d2e914 2018-05-31 09:28:12 internal-cluster /fisheye
96ba1cc7 2018-06-30 09:28:13 internal-cluster /fisheye
23ef9a4b 2018-07-08 09:28:11 internal-cluster /fisheye
76f8e70a 2018-07-09 09:28:12 internal-cluster /fisheye
74d46da4 2018-07-10 09:28:14 internal-cluster /fisheye
a893de2c 2018-07-11 09:28:12 internal-cluster /fisheye
7dbeb6c0 2018-07-12 09:28:13 internal-cluster /fisheye
8df2f318 2018-07-13 09:28:11 internal-cluster /fisheye
e7321bf1 2018-07-14 09:28:13 internal-cluster /fisheye
----------------------------------------------------------------------
12 snapshots
+ restic check
+ sudo -E docker run --rm -e AWS_ACCESS_KEY_ID=**** -e AWS_SECRET_ACCESS_KEY=**** -e RESTIC_PASSWORD=**** -v /mnt/efs/fisheye:/fisheye:ro -h internal-cluster --user root restic/restic -r s3:s3.amazonaws.com/redacted/restic/fisheye check
using temporary cache in /tmp/restic-check-cache-069761908
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
error for tree d93db471:
tree d93db471: file "atlassian-fisheye-2018-07-13.log": metadata size (52139444) and sum of blob sizes (52165018) do not match
error for tree 8d1b1f5f:
tree 8d1b1f5f: file "atlassian-fisheye-2018-04-30.log": metadata size (53418588) and sum of blob sizes (53426968) do not match
Fatal: repository contains errors
deweysasser
am 15. Juli 2018
Das ist eine gute Frage! Alle meine Repos bis auf eines sind jetzt fehlerhaft ... ich denke darüber nach, die Check-Phase insgesamt zu deaktivieren, aber andererseits war und wird es ein guter Weg sein, mögliche zukünftige Regressionen zu erkennen. Schwer zu sagen, was der beste Weg für die Zukunft ist ...
@ fd0 , das ist ein ziemlich schwerwiegender Fehler. Problemumgehung , um Repos wieder stumm zu machen?
zcalusic
am 15. Juli 2018
Entschuldigung, ich habe den Check-in # 1887 deaktiviert. Sie können das Commit auswählen, wenn Sie möchten.
fd0
am 15. Juli 2018
Verwandte Themen
reallinfo
·
4Kommentare
TheLastProject
·
3Kommentare
rakor
·
5Kommentare
ikarlo
·
4Kommentare
christian-vent
·
3Kommentare
Hilfreichster Kommentar
Ich stimme zu, dies sollte entweder eine Warnung sein oder überhaupt nicht angezeigt werden. Es gibt nichts, was Benutzer tun können (oder müssen).
Es ist ein Fehler im alten Archivierungscode, der die falsche Größe in das Repo geschrieben hat, als die Datei angehängt wurde, während Restic sie las. Der neue Archivierer macht das nicht und alle anderen Funktionen funktionieren einwandfrei (sie verwenden nur die richtige Größe, die Summe der Dateiblöcke).