qvm-backup-restore fails with scrypt: Input is not valid scrypt-encrypted block

[adrelanos]

Qubes OS version:

R4

Affected component(s):

dom0 qvm-backup-restore

---

Steps to reproduce the behavior:

qvm-backup-restore --verbose --verify-only -d dom0-backup /mnt/disk/qubes-backup-...

Expected behavior:

Verification succeeds.

Actual behavior:

Verification fails.

2019-02-06 09:27:00,458 [MainProcess restore._restore_vm_data:1337] qubesadmin.backup: Getting new file: vm80/private.img.410.enc
2019-02-06 09:27:05,560 [MainProcess restore._restore_vm_data:1337] qubesadmin.backup: Getting new file: vm80/private.img.411.enc
2019-02-06 09:27:10,682 [MainProcess restore._restore_vm_data:1337] qubesadmin.backup: Getting new file: vm80/private.img.412.enc
2019-02-06 09:27:15,809 [ExtractWorker3-2 restore.__run__:717] qubesadmin.backup.extract: Finished extracting thread
qvm-backup-restore: error: failed to decrypt /var/tmp/restore33uyonmh/vm80/private.img.412.enc: b'scrypt: Input is not valid scrypt-encrypted block\n'

General notes:

I don't think this is a full disk space issue. The graphical storage indicator and also df -h both showed plenty of free diskspace.

---

Related issues:

[tasket]

I can't reproduce this with a backup from early January that uses compression and a passphrase.

How does verify-only behave with older vs newer archives?

[andrewdavidwong]

I can't reproduce this with a backup from early January that uses compression and a passphrase.

FWIW, I also have not encountered this. (I use qvm-backup-restore --verify-only [...] daily.)

[andrewdavidwong]

I can't reproduce this with a backup from early January that uses compression and a passphrase.

FWIW, I also have not encountered this. (I use qvm-backup-restore --verify-only [...] daily.)

Spoke too soon! I just encountered this error during a routine backup. However, when I ran qvm-backup-restore --verify-only again a second time on the same backup file, I did not receive the error the second time.

Edit: Oh, wait. Actually, my error message was different:

qvm-backup-restore: error: failed to decrypt /var/tmp/restorexxxxx/vmxx/private.img.000.enc: b'scrypt: Decrypting file would take too much CPU time\n'

[marmarek]

qvm-backup-restore: error: failed to decrypt /var/tmp/restorexxxxx/vmxx/private.img.000.enc: b'scrypt: Decrypting file would take too much CPU time\n'

In that case, it is #4683

[marmarek]

I don't think this is a full disk space issue.

During the restore or just before? Number in the file name indicate it's quite big VM - do you have that much free space?

[adrelanos]

More than 100 GB free space still at that point.

Can somehow the number of the VM vm80 be used to deduce the VM name so I can check/try again?

So I can try to verify that VM only?

It's a multi hour process the verify. Didn't even use compression in hope this speeds up things. More than 8-12 hours. And during verification most other processes are blocked. So debugging this takes too much time.

[andrewdavidwong]

Can somehow the number of the VM vm80 be used to deduce the VM name so I can check/try again?

Try grepping qubes.xml.

[marmarek]

Can somehow the number of the VM vm80 be used to deduce the VM name so I can check/try again?

it is QID, try qvm-ls -O name,qid.

[adrelanos]

New hard drive, new disk, new backup, and backup verification failing again.

[1]

qvm-backup-restore --verify-only --verbose -d dom0-backup /mnt/disk/qubes-backup-2019-05-28T074105

2019-05-28 20:20:23,951 [MainProcess restore._restore_vm_data:1337] qubesadmin.backup: Getting new file: vm74/private.img.076.enc
2019-05-28 20:20:29,032 [MainProcess restore._restore_vm_data:1337] qubesadmin.backup: Getting new file: vm74/private.img.077.enc
2019-05-28 20:20:34,120 [ExtractWorker3-2 restore.__run__:717] qubesadmin.backup.extract: Finished extracting thread
qvm-backup-restore: error: failed to decrypt /var/tmp/restoreef40j_ca/vm74/private.img.077.enc: b'scrypt: Input is not valid scrypt-encrypted block\n'
[user@dom0 ~]$ 

qvm-ls -O name,qid | grep 77
vm-name-redacted    77

[2]

qvm-backup-restore --verify-only --verbose -d dom0-backup /mnt/disk/qubes-backup-2019-05-28T074105 vm-name-redacted

So verification of that very VM that failed to verify when verifying the whole backup [1] did not fail when verifying only that very VM (which has a size of only ~ 150 MB).

My disk is 77% full. The biggest VM has a size of 50 GB but I have more than 50 GB disk space.

Are there any free disk space checks before backup verification by Qubes backup code?

How much free disk space is required for backup verification?

[marmarek]

qvm-ls -O name,qid | grep 77
vm-name-redacted 77

Should be 74.

[marmarek]

Are there any free disk space checks before backup verification by Qubes backup code?

Not really.

How much free disk space is required for backup verification?

In worst case scenario, as much as the whole backup. Related/duplicate: #3230, #4791

[github-actions]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)