Re: [qubes-users] Backup verification error

2018-10-17 Thread Chris Laprise

On 10/17/2018 06:13 PM, 'awokd' via qubes-users wrote:

Kelly Dean wrote on 10/17/18 6:00 PM:
On Qubes 4.0, I did a full backup to an external hard drive using the 
standard backup utility, which completed successfully. 225GB total, 
compressed 130GB, took about 12 hours.


Then I tried to verify it (restore with verify-only option), and 
watched it for a few minutes to make sure it was running ok, then left 
it alone. Last line in the message window at the time was:

Extracting data: 209.6 GiB to restore

Came back a few hours later and the next line was:
Finished with errors!

And there was a dialog box:

[Dom0] Backup error!
ERROR: failed to decrypt
/var/tmp/restorexnuw0a8p/vm31/private.img.034.enc: b'scrypt:
Decrypting file would take too much CPU time\n'
Partially restored files left in /var/tmp/restore_*, investigate them
and/or clean them up
OK

So now I don't know if I have a good backup. The error message also 
leaves me doubtful that I'd be able to restore the backup even if it 
is good.


The indicated file doesn't exist in dom0. Neither does any other 
/var/tmp/restore* file. Googling the message (Decrypting file would 
take too much CPU time) finds nothing.




Looks like that error string comes from scrypt. There is a command line 
option (-f) to scrypt that forces it to proceed even if it might take 
excessive memory or CPU time, but I'm not sure how to pass it on through 
qubes-backup-restore.


Looking at the scrypt source, this error code results from the estimated 
number of operations exceeding a max time limit. Using -f should 
override this check.


In restore.py the function 'def launch_scrypt' contains the line 
starting with:



command_line = ['scrypt', action, input_name


This could be changed to:


command_line = ['scrypt', action, '-f', input_name


Of course, this advice is offered "at your own risk" and a backup copy 
of restore.py should be made before doing any modification.


-

BTW, since your backups are rather large, you might be interested in a 
new backup tool I'm writing that can perform fast incremental backups 
even on large volumes:


https://github.com/tasket/sparsebak

Its still experimental but could be in beta as soon as December.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ddd8b81d-9558-9bfc-aeee-a950e3236cb4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Backup verification error

2018-10-17 Thread 'awokd' via qubes-users

Kelly Dean wrote on 10/17/18 6:00 PM:

On Qubes 4.0, I did a full backup to an external hard drive using the standard 
backup utility, which completed successfully. 225GB total, compressed 130GB, 
took about 12 hours.

Then I tried to verify it (restore with verify-only option), and watched it for 
a few minutes to make sure it was running ok, then left it alone. Last line in 
the message window at the time was:
Extracting data: 209.6 GiB to restore

Came back a few hours later and the next line was:
Finished with errors!

And there was a dialog box:

[Dom0] Backup error!
ERROR: failed to decrypt
/var/tmp/restorexnuw0a8p/vm31/private.img.034.enc: b'scrypt:
Decrypting file would take too much CPU time\n'
Partially restored files left in /var/tmp/restore_*, investigate them
and/or clean them up
OK

So now I don't know if I have a good backup. The error message also leaves me 
doubtful that I'd be able to restore the backup even if it is good.

The indicated file doesn't exist in dom0. Neither does any other 
/var/tmp/restore* file. Googling the message (Decrypting file would take too 
much CPU time) finds nothing.



Looks like that error string comes from scrypt. There is a command line 
option (-f) to scrypt that forces it to proceed even if it might take 
excessive memory or CPU time, but I'm not sure how to pass it on through 
qubes-backup-restore.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/88ea4d17-f523-9813-d73c-0c16ac1a3ea0%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Backup verification error

2018-10-17 Thread taii...@gmx.com
Considering how long it takes and the chance for errors I also make a
post fsck dd backup of the entire drive/partition and then sha1sum it
just in case, which has saved me a few times.

I wish there was a choice to use more RAM to make it go faster or what not.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5297d787-63b2-5814-39c3-30e94bb31484%40gmx.com.
For more options, visit https://groups.google.com/d/optout.