Deleted chunk and loss of the entire archive chain

[Maksimus]

As part of the test stand, the situation was emulated that the HDD began to collapse and one of the chunks became unavailable in the logs error
restore failed: reading file "/sda/.chunks/003f/003f3597cc2f7892e339c9c26d9a38ac886d05669b172df218b12efb7f5c174b" failed: No such file or directory (os error 2) session_write_close
Repeated verification revealed that 2 chanks were damaged
2022-05-16T13:21:44+03:00: can't verify chunk, load failed - storage 'disk1', unable to load chunk '003f3597cc2f7892e339c9c26d9a38ac886d05669b172df218b12efb7f5c174b' - No such file or directory (os error 2) 2022-05-16T13:21:44+03:00: can't verify chunk, load failed - storage 'disk1', unable to load chunk '003a6672bf579879d6fe4c3a3f3ca49201c0a4534a8ca187b3d0e20304bcd3ef' - No such file or directory (os error 2)

And the whole chain of 4 archives became damaged. The question is what to do? how to restore a virtual machine from such a backup.

 

[fabian]

you can't - all backup snapshots referencing that chunk are corrupt (this is what offsite/archived backups are for ). for VM/fixed-index backups you can likely manually restore all but that chunk and only lose a few MB of data - whether that allows meaningful recovery depends on what the raw image contained at the lost offset. for CT/host (/dynamic-index) backups, it's a lot harder - since there is already one layer of indirection between the index and the actual data in the form of a pxar archive.

 

[Maksimus]

Thank you for your prompt response.
That is, a damaged / missing chunk cannot be restored in any way?

Why not add a chunk recovery algorithm for some checksums. Or add N% of the user's choice to the information for recovering damaged/missing chunks?
I created a fresh archive for the broken archives, everything was restored, the chain became 5 pieces, one chunk was damaged, and again the whole chain was destroyed. Maybe it is worth considering in future versions that in the chain of archives 1-2 archives (the last and penultimate or the user's choice) will always be full (a separate set of chunks)? Maybe such a function already exists and I don't see it?

Is it possible to disable deduplication (when 1 out of many archives is broken, it's not so sad when all archives are broken, but it takes up many times more space than synchronizing deduplicated storage)?

 

[fabian]

Thank you for your prompt response.
That is, a damaged / missing chunk cannot be restored in any way?

yes. you should not rely on any single backup storage as your only backup ("3-2-1" is the keyword )

Why not add a chunk recovery algorithm for some checksums. Or add N% of the user's choice to the information for recovering damaged/missing chunks?
I created a fresh archive for the broken archives, everything was restored, the chain became 5 pieces, one chunk was damaged, and again the whole chain was destroyed. Maybe it is worth considering in future versions that in the chain of archives 1-2 archives (the last and penultimate or the user's choice) will always be full (a separate set of chunks)? Maybe such a function already exists and I don't see it?

because any such mechanism would quickly blow up the space requirements without solving the actual problem (you still need another full copy somewhere else - because it is always possible your whole primary PBS will go up in flames/..).

Is it possible to disable deduplication (when 1 out of many archives is broken, it's not so sad when all archives are broken, but it takes up many times more space than synchronizing deduplicated storage)?

no, for the same reason given above.

 

[Maksimus]

The question is closed.