verify state failed

[S3v|\|]

Hallo

Ich sichere meine PVE-VMs im Rechenzentrum auf einen lokalen PBS, der ebenfalls eine VM ist über einen ipsec Tunnel. Der Datastore liegt auf einer QNAP-NAS.
Ich weiß dass diese Konfig nicht ideal ist, aber nun ist sie halt so.

Ich hab ein paar Sicherungen, die leider nicht erfolgreich sind (weil der Tunnel abbricht, weil die QNAP-NAS mal wieder rummzickt oder warum auch immer)
Hierfür bekomme ich hinterher eine E-Mail, dass die Sicherung einen Fehler hatte. Dann muss ich meistens in den PBS reinschauen und diese fehlgeschlagene Sicherung löschen. Die erkenn ich meistens daran, dass sie keinen Kommentar hat und dass bei "Size" keine Zahl steht sondern ein Kreisel läuft. Diese fehlgeschlagenen Sicherungen sind aber nicht mein Problem.

Ich hab mehrere Sicherungen, bei denen der "Verify State" "failed" ist.
Meine Frage: heißt das, dass diese Sicherung defekt ist und ich sie löschen sollte oder kann es auch heißen, dass nur die Überprüfung Probleme hatte und man die Sicherung noch "retten" kann?

 

[dcsapak]

Meine Frage: heißt das, dass diese Sicherung defekt ist und ich sie löschen sollte oder kann es auch heißen, dass nur die Überprüfung Probleme hatte und man die Sicherung noch "retten" kann?

das kommt drauf an, wie sieht denn der task log vom verify task aus?

 

[TErxleben]

Egal ob Baremetal oder PBS-VM. Sieh zu, dass der PBS über Storages auf lokalen Medien verfügt.
Über Netzwerk Daten entgegen zu nehmen und gleichzeitig darüber auf einen Netzwerkspeicher zu schieben, halte ich für sehr gewagt, sofern du kein dediziertes Speichernetzwerk einsetzt.

 

[Falk R.]

Ich hab mehrere Sicherungen, bei denen der "Verify State" "failed" ist.
Meine Frage: heißt das, dass diese Sicherung defekt ist und ich sie löschen sollte oder kann es auch heißen, dass nur die Überprüfung Probleme hatte und man die Sicherung noch "retten" kann?

Beantworte erst mal die Frage von Dominik.
Ja die backups sind defekt, aber retten kann man eventuell die Daten. Wenn die defekten Chunks noch auf der Quellseite (PVE) vorhanden sind und die noch einmal gesichert werden können, ist es eventuell möglich die alten Restorepunkte zu retten.
Aber das ist nur ein eventuell, falls vorhanden.

 

[TErxleben]

Beantworte erst mal die Frage von Dominik.
Ja die backups sind defekt, aber retten kann man eventuell die Daten. Wenn die defekten Chunks noch auf der Quellseite (PVE) vorhanden sind und die noch einmal gesichert werden können, ist es eventuell möglich die alten Restorepunkte zu retten.
Aber das ist nur ein eventuell, falls vorhanden.

Warum an Sicherungen puzzlen, wenn die Hütte nicht brennt?
Die gleiche Zeit sollte man lieber investieren um zu verstehen, warum die Probleme überhaupt entstehen und bestenfalls beseitigen.

 

[Johannes S]

Ich sehe jetzt nicht den Widerspruch, der OP sollte doch beides tun: Einerseits, um überhaupt wieder Backups zu haben (finde ich nicht sooo unwichtig) und zum anderen um solche Fehler zu vermeiden. Aber ohne Taskslogs kann man da halt schlecht was raten

 

[TErxleben]

Der OP hat seine Situation doch geschildert. Da sind so viele Fußfehler drin, dass es sinnlos ist ein log zu analysieren. Nebenbei hat er nur sporadische Fehler.

 

[S3v|\|]

Sorry - hat etwas gedauert. Bei mir hat es das Log irgendwie nicht mehr angezeigt - also musste ich einen neuen Verify anstossen. Der läuft zwar noch aber es sind schon ein paar Fehler aufgetauch:

2026-07-18T15:30:47+02:00: SKIPPED: verify SMB-PBS2:vm/101/2026-06-17T20:00:05Z (recently verified)
2026-07-18T15:30:47+02:00: percentage done: 12.40% (2/20 groups, 24/50 snapshots in group #3)
2026-07-18T15:30:47+02:00: verify SMB-PBS2:vm/101/2026-06-16T20:00:01Z
2026-07-18T15:30:47+02:00:   check qemu-server.conf.blob
2026-07-18T15:30:47+02:00:   check drive-tpmstate0-backup.img.fidx
2026-07-18T15:30:47+02:00:   verified 0.01/4.00 MiB in 0.13 seconds, speed 0.05/31.97 MiB/s (0 errors)
2026-07-18T15:30:47+02:00:   check drive-scsi0.img.fidx
2026-07-18T15:51:31+02:00:   verified 9152.88/20852.00 MiB in 1243.23 seconds, speed 7.36/16.77 MiB/s (0 errors)
2026-07-18T15:51:31+02:00:   check drive-efidisk0.img.fidx
2026-07-18T15:51:31+02:00:   verified 0.03/0.52 MiB in 0.15 seconds, speed 0.17/3.37 MiB/s (0 errors)
2026-07-18T15:51:31+02:00: percentage done: 12.50% (2/20 groups, 25/50 snapshots in group #3)
2026-07-18T15:51:31+02:00: verify SMB-PBS2:vm/101/2026-06-15T20:00:04Z
2026-07-18T15:51:31+02:00:   check qemu-server.conf.blob
2026-07-18T15:51:31+02:00:   check drive-tpmstate0-backup.img.fidx
2026-07-18T15:51:32+02:00:   verified 0.00/0.00 MiB in 0.00 seconds, speed 0.00/0.00 MiB/s (0 errors)
2026-07-18T15:51:32+02:00:   check drive-scsi0.img.fidx
2026-07-18T17:28:47+02:00:   verified 8334.80/18396.00 MiB in 5834.91 seconds, speed 1.43/3.15 MiB/s (1 errors)
2026-07-18T17:28:47+02:00: verify SMB-PBS2:vm/101/2026-06-15T20:00:04Z/drive-scsi0.img.fidx failed: chunks could not be verified
2026-07-18T17:28:47+02:00:   check drive-efidisk0.img.fidx
2026-07-18T17:28:47+02:00:   verified 0.00/0.00 MiB in 0.00 seconds, speed 0.00/0.00 MiB/s (0 errors)
2026-07-18T17:28:47+02:00: percentage done: 12.60% (2/20 groups, 26/50 snapshots in group #3)
2026-07-18T17:28:48+02:00: verify SMB-PBS2:vm/101/2026-06-14T20:00:02Z
2026-07-18T17:28:48+02:00:   check qemu-server.conf.blob
2026-07-18T17:28:48+02:00:   check drive-tpmstate0-backup.img.fidx
2026-07-18T17:28:48+02:00:   verified 0.00/0.00 MiB in 0.00 seconds, speed 0.00/0.00 MiB/s (0 errors)
2026-07-18T17:28:48+02:00:   check drive-scsi0.img.fidx
2026-07-18T17:36:33+02:00: chunk 2f038c639f2c913bea541b2f2a80345b66be3f1760fc157e406eddce88228c53 was marked as corrupt
2026-07-18T18:16:50+02:00:   verified 1480.69/4340.00 MiB in 2881.82 seconds, speed 0.51/1.51 MiB/s (1 errors)
2026-07-18T18:16:50+02:00: verify SMB-PBS2:vm/101/2026-06-14T20:00:02Z/drive-scsi0.img.fidx failed: chunks could not be verified
2026-07-18T18:16:50+02:00:   check drive-efidisk0.img.fidx
2026-07-18T18:16:50+02:00:   verified 0.00/0.00 MiB in 0.00 seconds, speed 0.00/0.00 MiB/s (0 errors)
2026-07-18T18:16:51+02:00: percentage done: 12.70% (2/20 groups, 27/50 snapshots in group #3)
2026-07-18T18:16:51+02:00: SKIPPED: verify SMB-PBS2:vm/101/2026-06-11T20:00:00Z (recently verified)
2026-07-18T18:16:51+02:00: percentage done: 12.80% (2/20 groups, 28/50 snapshots in group #3)

Gibt es eine Möglichkeit an die älteren logs ranzukommen?

 

[TErxleben]

2026-07-18T18:16:50+02:00: verify SMB-PBS2:vm/101/2026-06-14T20:00:02Z/drive-scsi0.img.fidx failed: chunks could not be verified

Wie bereits vermutet, steht in deinem Log nur WAS nicht passt und nichts darüber WARUM es es so ist.
Da helfen auch keine älteren, vollständige Logs.

P.S.:
Lösche auf deinem PBS die Sicherungen, die nicht verifiziert werden konnten und warte auf die nächsten Fehler. Vielleicht gibt es keine neuen Fehler. Vielleicht aber doch.
Im übrigen findest du im Dashboard des PBS die alten Logs von gelaufenen Verifizierungen.

 

[Bu66as]

Der Datastore hängt ja direkt auf nem SMB/CIFS-Share von der QNAP (SMB-PBS2), oder? Das ist mMn die Ursache. Der PBS-Chunkstore verträgt sich mit CIFS ziemlich schlecht, fsync und Locking sind da unzuverlässig, und wenn dann noch der IPsec-Tunnel mittendrin wegbricht, landen unvollständige Chunks im Store und fliegen beim Verify als corrupt raus. Passt auch zu deinen sporadischen Fehlern.

Robuster wärs, der PBS-VM eine eigene virtuelle Disk zu geben (raw/qcow auf der QNAP oder per iSCSI) und da ein ext4/xfs drauf, den Datastore dann lokal in der VM statt als CIFS-Mount. Ein Block-Device mit echtem fsync ist viel zuverlässiger als CIFS direkt als Backend.

Die betroffenen VMs einfach nochmal frisch sichern. Die als .bad markierten Chunks werden dabei neu hochgeladen, und alte Snapshots die denselben Chunk teilen verifizieren danach wieder sauber. Vorher einmal GC laufen lassen.

 

[S3v|\|]

Update: Hardware wurde bei Serverschmiede bestellt. Sobald die da ist kommen die Platten direkt rein und der alte virtuelle darf seine Aufgabe abgeben. Allerdings möchte ich noch die älteren Sicherungen auf den neuen übernehmen.
Kann ich dies mit Pull vom alten auf den neuen rüberkopieren? Ist das so möglich oder hab ich da einen Denkfehler?
Ist folgender Ablauf richtig?:
- die Sicherung auf dem alten deaktiviern
- die Sicherung auf dem neuen aktivieren (Push vom PVE aus)
- auf neuem Server den alten als Remote anlegen
- in dem Datastore und in den gleichen Namespace, auf den die Sicherungen zukünftig laufen sollen, einen "Pull Sync Job" anlegen und einmalig manuell laufen lassen (wird wohl ein paar Tage laufen)
- auf die übertragenen Sicherungen ein "Verify" laufen lassen
- den Pull Job löschen und den alten in Rente schicken

 

[Johannes S]

<snip>
- in dem Datastore und in den gleichen Namespace, auf den die Sicherungen zukünftig laufen sollen, einen "Pull Sync Job" anlegen und einmalig manuell laufen lassen (wird wohl ein paar Tage laufen)

Das sollte so funktionieren, aber warum ein paar Tage? Im lokalen Netzwerk sollte das eigentlich deutlich flotter gehen.

- auf die übertragenen Sicherungen ein "Verify" laufen lassen
- den Pull Job löschen und den alten in Rente schicken

Zusätzlich würde ich noch folgendes nach den verify machen:
- Die VMs erneut backuppen (dabei sollten envtl. kaputte Chunks neu angelegt werden)
- Erneut den pull-sync vom alten PBS machen, dabei den erweiteren Einstellungen 'resync-corrupt' aktivieren, dann werden (soweit möglich) kaputte Chunks noch mal angefordert.
- Verify wiederholen

Mit etwas Glück ist dann alles heile