qvm-backup-restore: verify integrity of backup by comparing with volumes in current system

[iamahuman]

The problem you're addressing (if any)
Qubes backups are susceptible from silent data corruption in the process of backing up volumes.

Describe the solution you'd like
Qubes should allow users to verify integrity of backup by comparing with the latest snapshot (revision) of volumes that predates the backup in current system.

Where is the value to a user, and who might that user be?
Users can rely on a more robust backup mechanism.

Describe alternatives you've considered

1. Actually restore them and verify manually.

   This is error-prone and can expose users to exploits from malicious VMs. Also, this is not an option if the user does not have enough disk space.

Additional context
This issue concerns only with data corruption happening during the backup process. If something tampered with the encrypted backup result, scrypt would detect it.

Relevant documentation you've consulted

• https://www.qubes-os.org/doc/backup-restore/
• https://www.qubes-os.org/doc/volume-backup-revert/ (volume revisions)

Related, non-duplicate issues

• Restoring from archive should not indicate success when some qubes do not restore. #6236 (only for software faults)
• Qubes backup restoration error reporting does not give any details #6035
  • qubes backup restore fails #5393
  • Improve backup restore and verification to check whether VM data is missing #3498
  • Problems with restore backup #3216

[marmarek]

It isn't going to work in many (perhaps most) cases... It is enough for some VM to stop (which will drop the old snapshot). And if we get #1239 implemented, then it's not going to work for running VMs ever.

[iamahuman]

It isn't going to work in many (perhaps most) cases... It is enough for some VM to stop (which will drop the old snapshot). And if we get #1239 implemented, then it's not going to work for running VMs ever.

I think it's mostly fine as long as all running VMs during backup are disposable, including sys-usb. Also this feature will remain an entirely optional step for users unwilling to interrupt their work for the backup process.

[ddevz]

It isn't going to work in many (perhaps most) cases... It is enough for some VM to stop (which will drop the old snapshot). And if we get #1239 implemented, then it's not going to work for running VMs ever.

Could a hash of each volume get stored at the time of backup, and the verification process then just checks the backup against the hashes?