Long story, I had to restore from backup. I had made a backup beforehand but I’ve only been able to restore 1 VM so far. The most important one says “Error extracting data: failed to decrypt /var/tmp/random/private.img.000.enc: b’scrypt: Passphrase is incorrect” despite the passphrase working when I run the Qubes Backup Restore thing from the Manager.
Since I’m able to restore one file, I’d imagine my passphrase has to be right.
Sven’s post here github com/QubesOS/qubes-issues/issues/6227 implied it was his hardware, but this is the same machine. I was able to restore a ~300 meg VM, but the one I need is almost 900.
I am on 4.1.1 after updating the reinstalled Qubes, so I’m not sure if github com/QubesOS/qubes-issues/issues/4791 still applies.
I tried following qubes-os org/doc/backup-emergency-restore-v4/ but it seems to say I still have the wrong passphrase when I run “scrypt dec -P qubes.xml.000.enc qubes.xml.000”, which I know is optional. That could be my syntax though. Step 6 just gives me a prompt “>”
I’ve tried copying the file right to dom0 and it still gives errors.
Step 6 is a multi-line command, so this shell prompt is telling you to continue typing the next line. After all four lines have been entered, the command executes as a whole.
I reran it and I managed to get a bit further. It says my passphrase is still incorrect. I tried the ‘echo “$backup_id!$f_dec!$backup_pass”’ part on it’s own and got DATE!!password, nothing between the !! if that matters.
It still says the passphrase is incorrect, but all the other steps seemed to work. Is it encrypted with another password?
When you say DATE, do you mean the full backup-id? I’m double checking because that should be date and a minus and a number.
No that’s okay (in the context of how you tried it on its own. The multi-line command assigns the f_dec variable in a subshell, so outside of that subshell it expands to an empty string.)
When I run it as you described, it still says I have the wrong password. The GUI restore tool shows me all the VMs in the backup so I think it’s a misnomer. The drive has enough free space too.
When I try on vm38, after I press enter after “done | gzip -d | tar -xv” I get the error “scrypt: Passphrase is incorrect” then “gzip: stdin: unexpected end of file”, but when I run it on vm1, I get “vm1/private.img” then the same errors. Not sure if that makes a difference.
Sounds like some of the .enc chunk files are corrupted in a way that scrypt reports as a wrong passphrase. I don’t know if it’s at all possible to still wring some data out of those specific chunks.
It should be possible to decrypt the remaining uncorrupted chunk files, but even then the result will be fragments of a gzip stream of a tar stream of a filesystem image - not exactly trivial data recovery…
I kinda figured… Would you keep trying for .15 bitcoin in a wallet?* Is it possible I’ll be able to gleam a few KB keepass DB out of it?
Edit: I mean I have .15 in the wallet, so I don’t know if it’s worth it to me to keep trying if it’s that likely. I don’t mean I’m trying to bribe you.
If it’s just a few KB that doesn’t sound hopeless…
In step 6, replace || break with $f_dec in the third line and remove | gzip -d | tar -xv in the fourth line - like this:
find vmX -name 'private.img.*.enc' | sort -V | while read f_enc; do \
f_dec=${f_enc%.enc}; \
echo "$backup_id!$f_dec!$backup_pass" | scrypt dec -P $f_enc $f_dec; \
done
For every vmX/private.img.N.enc file, that command will create a decrypted vmX/private.img.N file. Each decrypted file is supposed to be 128 bytes smaller than the encrypted file, but in case of corruption it will be incomplete or even empty. So you can then sum up the actual vs. expected sizes of the decrypted files to get a first estimate of how much data will already be missing.
(The decrypted files are not multiple independent gzip files, but fragments of a single big gzip file.)
Before you start, make sure you’ve neutralized the reason for your data corruption (e.g. failing disk or bad RAM).
That gives me multiple lines of “passphrase is incorrect” on two different machines. My phrase is a sentence with punctuation if that matters. When I run the command, then press UP on my keyboard to see past commands, it seems to change that line.
Sure, that’s expected for every corrupted chunk. Just keep it running, and at the end you’ll have multiple decrypted files. Hopefully one or more of them will be larger than 0 bytes.
I did, and it seems like all say that. But when I go back to look at the command I get “backup_id|f_dec|backup_pass” in the command not the “$backup_id!$f_dec!$backup_pass” one. So I tried changing it to “12345-1234!$f_dec!Passphrase” and then I get “bash: !Pas.: event not found” with the . being part of my password in the right place.
They say “100.00 MiB” when I get info, the last one is under 100 MiB, but close. The backup was expected to be 800 meg and change, and I have 675 meg in the other files. I did do “compress backup” too.
Update: For clarity, I mean that yes, the .00x files WITHOUT .enc have the same file sizes except for the first one at 0 bytes and the last at just under 100 MiB.
Update hit the max reply count: All say 104857600 except for the first and last. Last is 78088616. @rustybird just looping you in on the update here.
Update 2 because max reply count for the day: I got the gzrecover thing to work, and I got a file private.img.partial.recovered, and Ark seems to be able to do this too. I just can’t mount the private.img.partial.recovered it says “mount: /mnt/img: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.” when I do “sudo mount -o loop private.img.partial.recovered /mnt/img”. Not sure if I missed a step. Sorry if I shouldn’t keep @rustybird at-ing you as well. I think I’ve come to terms with losing access.