Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backup: verification succeeds then fails on the same backup after reboot #1577

Closed
andrewdavidwong opened this issue Jan 4, 2016 · 3 comments
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@andrewdavidwong
Copy link
Member

What I did and what happened:

  1. Create a backup with qvm-backup.

  2. Verify the backup via Qubes Manager (restore with "verify only" option).

  3. Qubes Manager reports verification successful.

  4. Upload a copy of the backup tarball to a cloud storage service.

  5. A day later, download the backup tarball from the cloud storage service.

  6. Use md5sum to check that the hash of the downloaded tarball matches the hash of the original, local backup tarball. They match.

  7. Attempt to verify the downloaded backup tarball via Qubes Manager.

  8. Verification fails with the following error message:

    ERROR: ERROR: invalid hmac for file /var/tmp/restore_[...]:
    [...]
    Is the passphrase correct?
    Partially restored files left in /var/tmp/restore_*, investigate them and/or clean them up
    
  9. Attempt to verify the original backup tarball via Qubes Manager. It also fails with the same error message.

  10. Reboot dom0.

  11. Re-attempt verification again three times, with the same failure each time.

Given the sequence of events, the most likely explanation seems to be that the original backup was corrupt, and Qubes Manager (or qvm-backup-restore) erroneously reported that verification was successful. If so, this is very serious, since it means users have no reliable way to know whether their backups are corrupt.

Related issue: #1471

@andrewdavidwong andrewdavidwong added T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. C: core labels Jan 4, 2016
@andrewdavidwong
Copy link
Member Author

This problem (and the one in #1471) seem to manifest only after Qubes has been running for a long time (several days) without a host reboot. In fact, I've noticed for a long time now (across several Qubes versions) that Qubes tends to become somewhat unstable after going too long without a host reboot, so perhaps this is one symptom of that (but one of the more serious ones).

@marmarek marmarek added this to the Release 3.0 updates milestone Jan 4, 2016
@marmarek marmarek added the P: major Priority: major. Between "default" and "critical" in severity. label Jan 4, 2016
@andrewdavidwong
Copy link
Member Author

User cubit also appears to be experiencing this bug:
https://groups.google.com/d/msgid/qubes-users/KnFmLnO--3-0%40tutanota.com

@andrewdavidwong
Copy link
Member Author

This issue is being closed because:

If anyone believes that this issue should be reopened, please let us know in a comment here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Development

No branches or pull requests

2 participants