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