Backups are corrupted on restore

User Support 4.1
#1

I’ve installed three Qubes 4.1 systems over the past months, backing up and restoring various times. I have been experiencing corrupted restores more often than not. See a photo attached for the error (apologies for the photo, I wasn’t thinking about posting it for support when I took it).
Corrupted AppVM will restore but have no data within.
It’s important to note I’m using Btrfs, so I’m unsure if it could be something with this, or 4.1 in general.

Has anybody experienced issues with backups?

qb_bkupfail
qb_bkupfail1152×268 136 KB

#2

qvm-backup-restore --ignore-size-limit as suggested by the error message seems worth a try.

If that helps, please file an issue to figure out what’s wrong with the size limit calculation.

#3

you understand the suggestion wrong, it the suggestion for tar, not qvm-backup-restore

#4

No.

#5

why?

#6

Those are two error messages from qubesadmin.backup.restore. The second one has nothing to do with tar.

#7

The most recent error was when I backed up one single AppVM (4gb) and left it on my laptop and restored it away from the house. When I went to restore, the single AppVM backup was corrupted. Yucky situation. So I’m doubting it’s related to size of backup/restore.
(I’ve also restored very large backups, similar to size in photo, in many Qubes 4.0* prior to Btrfs without a single issue.)

#8

Did that one show the same second error message that mentions the --ignore-size-limit option?

So I’m doubting it’s related to size of backup/restore.

Eh, hitting this size limit wouldn’t necessarily mean that the VM is too large in absolute terms. It could just be that the size limit calculation itself is somehow buggy, or that something else caused qfile-dom0-unpacker to exit with status 122 (EDQUOT).

#9

I just attempted another restore on that backup file. Yes indeed it is the same error. I did a restore via dom0 CLI with --ignore-size-limit and it restored successfully and with all content (so it seems).

The only other result found in a search is somebody from 2017 with the same issue (pre 4) https://groups.google.com/g/qubes-users/c/0i7RfWhoCxU

1 Like
#10

this is the second post in a few weeks saying backups are corrupted its very concerning

i feel bad for op hope data is recoverable

#11

True, OP should definitely still submit this as a GitHub issue!

I suspect the other one (assuming it’s what you’re referring to) is related to what was fixed in qubes-core-agent 4.1.29+.

1 Like
#12

No need to backup before the installation upgrade to R4.1 because all of the files from R4.0 are saved and secure during the installation upgrade. Backing up is recommended by any experts due to the chances of installation corruption. Restoring it will be pain in the ass to do it.

#13

Just a reminder that everyone with valuable data should be verifying (i.e., test restoring) their backups immediately after creating them, not waiting until they’ve lost the original data and truly need to restore from the backup. The Qubes backup system provides an easy built-in tool to help with this:

This is not to say that the existence of a verification method excuses any corruption bugs. It doesn’t. Any such bugs should be reported and fixed. I’m just pointing this out because it’s a time-tested best practice for data backup, regardless of operating system, and it provides a practical way for you to ensure the preservation of your data right now.

#14

Issue created

1 Like
#15

Had same issue, usually when unchecking encrypt (as suggested to make backups faster). When I restored with the GUI none of the data was there, but restoring with the command line worked.

Posting this link since I didn’t see it on the How To Back Up doc: qvm-backup-restore – Restores Qubes VMs from backup — Qubes Admin client v4.1.21-0-g400ea49-dirty documentation

And here is an example of how to use it that worked for me:

dom0~]$ qvm-backup-restore --ignore-size-limit --exclude=vmtonotrestore --dest-vm=vmwherebackupis /path/to/backup/on/that/vm/qubes-backup-2022-04-05T111111