Beim Durchlauf von z.B.

restic forget --keep-last 7 --prune

kann es mitunter zu einer Fehlermeldung wie diese kommen:

repacking packs [8:38] 45.74% 1537 / 3163 packs repacked

Fatal: StreamPack: read blob <data/ba13113d> from 87c8e881: wrong data returned, hash is 16c7ec8e96fbbdc12bcb59353690dba2e700ad466d39992e8bb38ce8586348ce

Die Ursachen können verschieden sein, wie zum Beispiel:

• Übertragungsfehler
• Verschlüsselungs- bzw. Berechnungsfehler
• Ein fehlerhaftes Dateisystem am Backup-Ziel
• Fehlerhafte Hardware (CPU, RAM, Storage) sowohl an der Quelle als auch am Ziel
• Fehler in restic oder der Software beim Ziel

Als erste Maßnahme kann man mit

restic check

das Repository überprüfen. In diesem Praxis-Fall sah die Ausgabe (gekürzt) so aus:

...
pack efe51be19b470755e6d235e2b594d70c754a73ec7f879af119774bd560ab2736: not referenced in any index
...
902 additional files were found in the repo, which likely contain duplicate data.
This is non-critical, you can run `restic prune` to correct this.
check snapshots, trees and blobs
[0:02] 100.00% 7 / 7 snapshots
no errors were found

Zwar soweit keine Fehler, dafür jede Menge (ich nenne es Mal) “Reste”.

Interessant ist wenn man erneut “prune” laufen lässt, das ggf. sich die Datei-Anzahl erhöht und der genannte Fehler mitunter später auftritt. Hier waren es dann 950 Dateien und der Fehler kam bei 48.00%. Denkbar ist das der Fehler nach ausreichend vielen Durchläufen im weitesten Sinne verschwindet.

Möchte man es vorher lösen oder weiter eingrenzen hilft dieser Befehl:

restic find --show-pack-id --blob ba13113d

Den Blob (die Kennung am Ende) muss man natürlich anpassen. Die Ausgabe sieht wie folgt aus:

repository ff4f8a08 opened (version 2, compression level auto)
[0:01] 100.00% 35 / 35 index files loaded
Found blob ba13113dd19d456aea24b8298eff41f8a5c63d302484cd3810d657586382d61a
... in file /E/ISOs/SRV03/Setup/apps.iso
(tree 21bb2e488ba73f1c07fcd9786d2cebaa8dfb7d9656dd0ac622e81d1017da3b0f)
... in snapshot 42505ffd (2024-01-18 04:47:22)
Object belongs to pack 87c8e881bd56459425f67e53c6ecf130abf7ae8f8ac4d7d4060806be5d4a1887
... Pack 87c8e881: <Blob (data) ba13113d, offset 8501066, length 46070, uncompressed length 549050>

Hier sieht man genau welche Dateien und welche Snapshots es betrifft.

Um den Fehler an sich und die “Reste” los zu werden kann es helfen, den Index neu aufbauen zu lassen:

restic repair index

Anschließend prüft man nochmals mit

restic check

Es sollten keine “Reste” mehr vorhanden sein. Der oder die nächsten prune-Vorgänge sollten dann ebenfalls ohne Fehler durchlaufen.

Weitere Möglichkeiten den Fehler zu beheben sind:

• Den oder die betroffenen Snapshots löschen.
• Sofern vorhanden den betroffenen Blob aus einem Backup wiederherstellen.
• Das Repository komplett zu leeren oder vollständig neu zu erstellen.

Quellen

restic – Docs – Troubleshooting – Repair the index

restic – Forum – Blob returned invalid hash check error

restic – Forum – Help debugging a blob invalid hash

blog.pkh.me – Saving a restic backup the hard way

Feeding the Cloud – Removing a corrupted data pack in a Restic backup

Update 17.02.2024

Einen solchen Fehler hatte ich jetzt erneut, allerdings war der betroffene Blog in allen Snapshots. Die obigen Maßnahmen halfen erstmal nicht, dafür allerdings die Folgenden.

Den Index zu reparieren bringt mitunter nichts, hier wird er nur noch mal der Vollständigkeit halber erwähnt. Diesen Befehl kann man überspringen:

restic repair index (vormals restic rebuild-index --read-all-packs)

Hier gab es in diese Fall dann weitere Fehler (Ausgabe gekürzt):

...
repacking packs
[0:55] 24.76% 366 / 1478 packs repacked
Fatal: StreamPack: read blob <data/21609ffb> from 8749c84d: wrong data returned, hash is 0fb6570c335260c0c387af8707a849d0f41c33d1da33beb8003dca480b3e08c7

Erst ab hier wird es wieder spannend:

restic check --read-data

Achtung: Dieser Befehl lädt jedes Paket herunter und prüft es, daher je nach Größe des Repositoriy entsprechend Zeit mitbringen! Um den Speicherplatz braucht man sich indes offenbar keine Sorgen zu machen, da immer nur ein (paar) Paket(e)  heruntergeladen und geprüft werden (dies belegt ca. 522 MB auf der Disk), man braucht also nicht soviel Platz wie das Repository groß ist.

Die Ausgabe (gekürzt) wirft dann die fehlerhaften Packs/Blobs aus, aber auch was man tun kann:

...
The repository contains pack files with damaged blobs. These blobs must be removed to repair the repository. This can be done using the following commands:

RESTIC_FEATURES=repair-packs-v1
restic repair packs 405ce16584b398e5ab0152aabdc2dd81ff31b30bf9f1016837f787879c061565 d1410289a8e1c4ac951cbc91afd0eee236f8e2f07745814f188ca7044666ae15 
956454004c46a9c6c7f06ef24b5f47d765eadd8851f016b1361580aad60958f0 f6fae1965c0a96bdb81c7da8a1d16bd8fde139e5ce93add4850e7a0e4679771e 
8749c84d70106a7bae80a416b6a23550769d7ca2b18c2a35aef24cac648c489e c83cb1ae1822afdcaebe2cb7ddcdfe8b48a0637db761b278ca2b8d9e4b87d936 
994d76c1e7503681c6a4844b0763e9f4777cd5ddb366d3e4db3caad92e46615d fd927ec2e15d7e3bca298dfbcefcf49a207b1561fc89c3dd4f4143b749097a5e 
4daf54db4d7d7da7749231b17bed0a5d6b76c0258cb72e656e088863db18ffc4 eeee26c6c0037b8d0edb148d209a653d20c53249b49c97bd3fe1071e4c986142 
cfdce03b596656b24a4bf28cc6abc3d5c8300b9240335d17a6097dc1d8515fed
restic repair snapshots --forget

Corrupted blobs are either caused by hardware problems or bugs in restic.
Please open an issue at https://github.com/restic/restic/issues/new/choose for further troubleshooting!

Fatal: repository contains errors

Also zunächst die Umgebungsvariable wie angegeben gesetzt:

Windows: set RESTIC_FEATURES=repair-packs-v1
Linux: export RESTIC_FEATURES=repair-packs-v1

Anschließend mit

restic repair packs... <- wie es in der Ausgabe steht

weiter gemacht und schließlich noch

restic repair snapshots --forget

ausgeführt.

Das lief soweit alles durch. Anschließend noch mal

restic check

ausgeführt. Hier tauchen wieder “Reste” auf:

...
49 additional files were found in the repo, which likely contain duplicate data.
This is non-critical, you can run `restic prune` to correct this.
check snapshots, trees and blobs
[0:01] 100.00% 7 / 7 snapshots
no errors were found

Also noch mal

restic prune

ausgeführt und dann war alles sauber.

Nach dem nächsten Durchlauf des Backups wurde nochmal ein Check gefahren und der (hier übliche)

restic forget --keep-last 7 --prune

lief normal ohne Fehler durch.

Zur absoluten Sicherheit wurde dann noch eine Test-Wiederherstellung durchgeführt:

restic restore latest <Ziel>

Diese klappte ebenfalls und die wiederhergestellten Daten konnten gelesen werden.

Update 19.02.2024

Ein paar kleinere Korrekturen und Ergänzungen.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.