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.