Backups are corrupted on restore

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?

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.

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

No.

why?

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

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.)

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).

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

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

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

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.

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.

Issue created

1 Like