The backup I made in qubes os 4.23 cannot be restored in qubes os 4.24 beta. This should not be a 4.24 beta issue.
qube manager tells me that the backup-header does not exist. How can I solve this problem to restore my backup？
unexpected files in archive: got, expected ['backup-header', 'backup-header.hmac']
Thank you for your answers!
I opened the backup file according to Emergency backup recovery (v4) | Qubes OS, but there is no back-header and I can’t do the next step, and i know password
One more thing to add, backup-header.hmac is not there either, but qubes.xml.00.enc, vm1, vm2… all have it. Is there a chance of recovery?
For temporary fix you can install system with 4.23 version, and restore you data
Yes, as stated in the emergency recovery these are the files containing the backups. backup-headers contains some metadata like compression algorithm used, this is not normal it’s not there.
Ideally, treat your backup as compromised when recovering them.
Thanks, do you mean 4.24 cannot recognize “backup files without backup-header”?
I installed version 4.23 and still can’t restore the backup
Given it’s missing a file it’s not going to work. But you can still restore the files manually.
Did you run the backup verify tool after doing the backup?
If neither backup-header nor backup-header.hmac exist it’s going to be tricky to recover the backed up data even manually, because those files contain the backup-id which is part of the low-level scrypt passphrase (not the same as the high-level backup passphrase).
The backup-id seems brute forceable though, as it consists of a second-resolution timestamp (should be in the 20 or so seconds leading up to the mtime of qubes.xml.000.enc) and a PID. One scrypt attempt takes around 3 seconds on my system, so… a few days/weeks/months maybe? Mostly depending on the PID range. I just tried a backup after two weeks of uptime, and the PID was near 100,000.
Thank you for your answer. Does qubes.xml.000.enc need to be decrypted before vm1,vm2,vm3 can be decrypted?
No, but you’ll be flying blind which VM name corresponds to vm1 etc. And to be clear, either way it’s necessary to know the backup-id.
I don’t need to know which vm corresponds to which name. I just need to unlock all vms and take out the key data. Then not knowing the backup-header will not affect it.
Doing that requires a piece of information (the backup-id) that is inside backup-header or backup-header.hmac. You cannot decrypt the VM storage data without getting this backup-id somehow.
BTW this is odd:
There should be something - even if it’s just [] - between got and the comma.
OMG, it seems that I need to traverse. It seems that backup-id is composed of a date and a string of numbers. Do I need to select a minimum vm data file to traverse?
What do you mean?
I performed a test and generated a backup-id = 20250117T214120-2878, where 202501172141 seems to be the time when the backup file was generated. I have this exact date, but I don’t have 20-2878. If this - is fixed in this position, I only need to use the script to automatically try the remaining six digits to unlock the backup?
The part after the dash (the process ID) isn’t necessarily 4 digits long. It’s a number between 2 and /proc/sys/kernel/pid_max (4194304, although more likely something in the 3 to 6 digit range)
The part before the dash is an ISO 8601 timestamp. Take the modification time (the stat command will print it with second resolution) of the extracted qubes.xml.000.enc as the maximum value, and maybe 20 seconds less then that as the minimum value. You might want to do a couple backups first (on the same hardware as the damaged backup) and e.g. if you see that there’s usually a delay of 7 - 15 seconds, prioritize that timestamp range in your brute force script.
Thank you for your reply, you helped me narrow down the scope. It’s strange that there is no backup-header in the backup file generated by qubes os 4.23. Fortunately, I didn’t suffer any property loss, but many of my PGP private keys suffered catastrophic losses (including another account of one of my qubes community). I hope everyone can make backups in time and prevent the backups from being damaged (this way I can reduce the time I spend online and protect my eyes)
It’s definitely very weird if backup-header and backup-header.hmac are both missing. I’ve never heard of that. Does tar print any errors on extracting the backup file?