qvm-backup-restore fails with "[Errno 2] No such file or directory"

[andrewdavidwong]

Qubes OS version:

R3.2

---

Steps to reproduce the behavior:

1. Create a qvm-backup of my-appvm with the following options:

qvm-backup --encrypt --compress --compress-filter=bzip2 [...]

2. Use qvm-backup-restore --verify-only [...] to verify that the backup is good. The verify-only restore succeeds without any problems.
3. Attempt to perform an actual restore of my-appvm:

Extracting data: 100 MiB to restore
-> Restoring QubesAppVm my-appvm...
ERROR: [Errno 2] No such file or directory: u'/var/tmp/restore_NiWcn/vm5'
*** Skipping VM: my-appvm
-> Done. Please install updates for all the restored templates.
Finished with errors!

The same error occurs with both Qubes Manager and qvm-backup-restore on the CLI.

This only affects some of my VMs, not all of them. But it completely prevents restoring backups of the affected VMs, even from backups made at different points in time.

[andrewdavidwong]

I kept trying progressively older backups until I was able to restore successfully from a two-month-old backup. So, this probably started happening sometime in the last two months.

[andrewdavidwong]

I kept trying progressively older backups until I was able to restore successfully from a two-month-old backup. So, this probably started happening sometime in the last two months.

[tasket]

@andrewdavidwong - Are you able to restore the newer archives using the emergency manual procedure?

[tasket]

@andrewdavidwong - Are you able to restore the newer archives using the emergency manual procedure?

[andrewdavidwong]

@tasket: Sorry, I'm not comfortable using the emergency manual procedure on those backups in a non-emergency situation. My decryption passphrase and the backup data are too sensitive to expose in a domU, even a fresh or disposable one. There's a non-zero increase in risk to the manual procedure relative to using qvm-backup-restore that I'm not willing to take for this purpose. I tried reproducing the issue with a non-sensitive test VM but was unable to do so. If others are also unable to reproduce the issue, we can close it.

[andrewdavidwong]

@tasket: Sorry, I'm not comfortable using the emergency manual procedure on those backups in a non-emergency situation. My decryption passphrase and the backup data are too sensitive to expose in a domU, even a fresh or disposable one. There's a non-zero increase in risk to the manual procedure relative to using qvm-backup-restore that I'm not willing to take for this purpose. I tried reproducing the issue with a non-sensitive test VM but was unable to do so. If others are also unable to reproduce the issue, we can close it.

[tasket]

@andrewdavidwong - I don't have a 3.2 system to test with at the moment. You may want to leave this issue open and post about it in qubes-users to see if others recognize the problem or can test it.

[tasket]

@andrewdavidwong - I don't have a 3.2 system to test with at the moment. You may want to leave this issue open and post about it in qubes-users to see if others recognize the problem or can test it.

[bargulg]

I might have the same issue... backup from qubes 3.2, verification in qubes passed, and now an emergency manual restore doesn't work.
Integrity check of each file passed, but when I try to decrypt, I get this:
bad decrypt 140173445084992:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:569:
I'm really sure there's no typo in password - checked like 20 times, and the same password works when verifying hashes.

[bargulg]

I might have the same issue... backup from qubes 3.2, verification in qubes passed, and now an emergency manual restore doesn't work.
Integrity check of each file passed, but when I try to decrypt, I get this:
bad decrypt 140173445084992:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:569:
I'm really sure there's no typo in password - checked like 20 times, and the same password works when verifying hashes.

[Polygonbugs]

I experienced same issue @andrewdavidwong. Though your case was AppVM but mine was customized fedora-26-minimal template. There was no choice but to throw away that template.

That is the reason I changed my plan to backup one by one. I'm not sure I can reproduce this issue either... Maybe big size VMs make problem?

[Polygonbugs]

I experienced same issue @andrewdavidwong. Though your case was AppVM but mine was customized fedora-26-minimal template. There was no choice but to throw away that template.

That is the reason I changed my plan to backup one by one. I'm not sure I can reproduce this issue either... Maybe big size VMs make problem?

[marmarek]

Do you see anything weird in file sizes? Maybe some parts are truncated (out of disk space somewhere in the process)?

[marmarek]

Do you see anything weird in file sizes? Maybe some parts are truncated (out of disk space somewhere in the process)?

[Polygonbugs]

I backed up multiple template-VMs in one backup so I don't know whether there was a irregular small size backup was existed or not. But I remember another template was restored with very small size below 1GB(I didn't compressed because I used Gui tool for backing up)? I could make VMs based on this template but I couldn't start VMs...

Also after changed plan to backup one VM by one backup file via Qubes Manager, I saw that some of backup files were backed up smaller than usual and there was no weird log while its process.

[Polygonbugs]

I backed up multiple template-VMs in one backup so I don't know whether there was a irregular small size backup was existed or not. But I remember another template was restored with very small size below 1GB(I didn't compressed because I used Gui tool for backing up)? I could make VMs based on this template but I couldn't start VMs...

Also after changed plan to backup one VM by one backup file via Qubes Manager, I saw that some of backup files were backed up smaller than usual and there was no weird log while its process.