[SOLVED] sync-job für Offsite-Backup: "can't verify chunk"

Oct 28, 2013
299
44
93
www.nadaka.de
Hallo zusammen,

wir sichern unsere ca. 60 VMs auf einen dedizierten PBS. Nun würden wir gerne einen weiteren PBS als Offsite Backup an den Start bringen, der einmal am Tag das jeweils jüngste Backup aller VMs zu sich holt. Sowohl die Einrichtung, als auch der initiale Sync haben prima geklappt. Doch nun schlägt bei einer einzigen VM die Verifizierung fehl:

Code:
2024-01-22T04:31:09+01:00: verify offsite:vm/103/2024-01-21T21:00:51Z
2024-01-22T04:31:09+01:00:   check qemu-server.conf.blob
2024-01-22T04:31:09+01:00:   check drive-scsi0.img.fidx
2024-01-22T04:31:28+01:00:   verified 13711.79/27400.00 MiB in 19.50 seconds, speed 703.31/1405.41 MiB/s (0 errors)
2024-01-22T04:31:28+01:00: percentage done: 25.00% (21/84 groups)
2024-01-22T04:31:28+01:00: verify group offsite:vm/103 (1 snapshots)
2024-01-22T04:31:28+01:00: verify offsite:vm/103/2024-01-21T23:30:02Z
2024-01-22T04:31:28+01:00:   check qemu-server.conf.blob
2024-01-22T04:31:28+01:00:   check drive-scsi2.img.fidx
2024-01-22T04:31:41+01:00:   verified 8793.94/19552.00 MiB in 13.01 seconds, speed 675.90/1502.76 MiB/s (0 errors)
2024-01-22T04:31:41+01:00:   check drive-scsi1.img.fidx
2024-01-22T04:35:19+01:00: can't verify chunk, load failed - store 'offsite', unable to load chunk '279c19b9eff0b0d81c1458eb4e6e911a0372523aa19098000394cec16554a621' - Data blob has wrong CRC checksum.
2024-01-22T04:35:19+01:00: corrupted chunk renamed to "/offsite/.chunks/279c/279c19b9eff0b0d81c1458eb4e6e911a0372523aa19098000394cec16554a621.0.bad"
2024-01-22T04:43:53+01:00:   verified 255514.53/1723288.00 MiB in 731.24 seconds, speed 349.43/2356.68 MiB/s (1 errors)
2024-01-22T04:43:53+01:00: verify offsite:vm/103/2024-01-21T23:30:02Z/drive-scsi1.img.fidx failed: chunks could not be verified
2024-01-22T04:43:53+01:00:   check drive-scsi0.img.fidx
2024-01-22T04:44:14+01:00:   verified 13419.25/38352.00 MiB in 21.67 seconds, speed 619.31/1769.98 MiB/s (0 errors)
2024-01-22T04:44:14+01:00: percentage done: 26.19% (22/84 groups)

Dass die Storage-Hardware defekt ist, halten wir für unwahrscheinlich. Es handelt sich um eine neue PM1735 12,8 TB, alle Tests waren unauffällig.
Was könnte das Problem, und wie lässt sich das debuggen?

Liebe Grüße
Stephan

Edit: Unser Problem klingt ein bisschen wie dieses hier:
https://forum.proxmox.com/threads/issue-with-missing-chunks-on-large-backups.109190/
Aber die dort vermuteten Ursachen (harte Abstürze des Systems oder ähnliches) liegen bei uns nicht vor.
 
Last edited:
Der Chunk kann auch beim Transport beschädigt worden sein, obwohl das auch auffallen sollte. Der Chunk ist auf jeden Fall korrupt und sollte beim nächsten sync wieder geholt werden, außer er ist auf dem Quellsystem nicht mehr vorhanden.
 
Der sync besagter VM wurde letzte Nacht erfolgreich verifiziert, dafür schlugen fünf andere Verifikationen fehl. Die Quellen wurden zuvor erfolgreich verifiziert, und auch der Sync-Job selbst lief ohne Fehler. Wo können sich da die Probleme reinschleichen?
 
kaputter RAM waere eine moegliche quelle.. du koenntest auch mal mit nem hexeditor einen der kaputten chunks aufmachen oder die kaputte und "richtige" variante vergleichen..
 
gut dass du die (hoffentlich einzige) ursache gefunden hast!

mehr RAM Ist natuerlich immer gut - weil mehr RAM heisst auch mehr cache ;)
 
  • Like
Reactions: sherminator

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!