restore problem

[BernhardOnline]

Dear all,

a month ago, I finally took the time to switch from Qubes 4.1 to 4.2. But a disaster happened. I first backed up the hard drive before doing a clean install, setup everything everything - and then, while importing my data back discovered the (magnetic) hard drive has sector errors. So I lost some data, but I have older backups on other drives, so I recovered painfully 99% of it.

My hope is to find the rest on my wyng snapshots, that I have been using in parallel with "full takes" the old way. I have these on another external hard-drive, but the dom0-files (containing wyng arch-init whatever data) are gone as well.

So how do I extract data from wyng? Do I first need to run the "arch-init" command or not? I do not want to take any risk of messing up further ...

thank you, Bernhard

[tasket]

Hi Bernhard,

A Wyng archive consists of a directory structure containing files and subdirectories. How much you can recover will depend on how much of the directory contents remain. So the first step in attempting recovery would be to get (what's left of) the archive dir in a readable state & accessible as dirs/files.

To determine what can be salvaged, you should look at the Wyng archive format overview, which shows the placement and role of each file. To have any hope of recovery, you will need to have the chunk files (named like 'x0000000000001000') stored in their subdirectories.... these might be directly restore-able if you turned off encryption when creating the archive. Otherwise, if the archive is encrypted then you must also have either the 'archive.salt' or 'salt.bak' plus the passphrase as a bare minimum.

From there, salvaging raw data from an unencrypted archive can be as simple as decompressing (copies of) the chunk files and then cat-ing them together. For an encrypted archive, its best to have Wyng decode it but how you approach it depends on how much of the .ini and info files are missing; if wyng arch-check can't see the archive then there will be a lot of manual steps to make the encrypted data accessible again. @BernhardOnline

[BernhardOnline]

maybe I explained wrongly. So I have two data backups.

(1) wyng - encrypted. (2) full-take hard drive.

Number (2) is more recent but has failures. Therefore my dom0 (into which I copied a fresh copy of wyng today) does not yet know the existence of (1).

My question is how to re-attach (1) to dom0, and run a recover on one precise VM. So I attach the drive to dom0, mount it somewhere. The dir looks like:

archive.dat  
archive.ini.salt  
salt.bak    
Vol_684800  
Vol_a717c9  
Vol_d5b247
archive.ini  
Vol_29577e  
Vol_86a350  
Vol_cd3379

but running sudo wyng arch-check --dest=file:/mnt/ I get

Wyng 0.8 beta release 20240610
Enter passphrase: 
Traceback (most recent call last):
  File "/home/bernhard/wyng-backup/src/wyng", line 5023, in <module>
    aset        = get_configs(options)    ; dest = aset.dest
                  ^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 2202, in get_configs
    aset = get_configs_remote(dest, cachedir, opts)    ; os.utime(aset.path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 2220, in get_configs_remote
    aset = ArchiveSet(tmpdir, dest, opts, children=0, pass_agent=int(opts.authmin))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 149, in __init__
    mcrypto.load(ci_types[1], self.saltpath, slot=1,
  File "/home/bernhard/wyng-backup/src/wyng", line 1046, in load
    sf = self.keyfile = self.open_saltfile(keyfile)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 1093, in open_saltfile
    sf = open(fpath, "r+b", buffering=0)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/wyngeerius89/archive.salt'

and I am stuck. What now?? Thank you for your fast response above ...

[tasket]

@BernhardOnline You may have created the Wyng archive just prior to some slight changes in Wyng's file naming. Simply renaming your 'archive.ini.salt' to 'archive.salt' should fix the problem.

There is nothing else you need to do to 're-attach' dom0 to the archive.

[tasket]

PS - If your archive is intact you probably don't need to run wyng arch-check. You can just start using wyng receive as needed.

[BernhardOnline]

I did the rename & invoked "receive", which is getting me closer ... but not yet quite there. Maybe something else changed since the 0.4beta version I used before :)

Wyng 0.8 beta release 20240610
Enter passphrase: 
Traceback (most recent call last):
  File "/home/bernhard/wyng-backup/src/wyng", line 5023, in <module>
    aset        = get_configs(options)    ; dest = aset.dest
                  ^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 2202, in get_configs
    aset = get_configs_remote(dest, cachedir, opts)    ; os.utime(aset.path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 2279, in get_configs_remote
    return ArchiveSet(arch_dir, dest, opts, children=depth, allvols=True, prior_auth=aset)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 204, in __init__
    self.mci_count    = mcrypto.set_counter(self.mci_count, saltfile=self.saltpath)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 1146, in set_counter
    self.keyfile = self.open_saltfile(saltfile, verify=True)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup/src/wyng", line 1097, in open_saltfile
    if len(enc_h) < self.saltchksz:   raise ValueError("Wrong salt hash size "+str(len(enc_h)))
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the error message differs slightly. Thank you!

[BernhardOnline]

P.S: same with wyng list --dest=file:/mnt/

[tasket]

@BernhardOnline OK, its from v0.4 so that is older than I anticipated.

In that case I suggest renaming archive.salt back to archive.ini.salt. Then you can either use a v0.4beta release or the v0.8beta1 release. The latter will update the format of the v0.4 archive automatically to match v0.8.

[BernhardOnline]

OK that one seems to work! I can likst the content of the backup.

Only trouble is the "destination". To avoid additional trouble I'd like to use --save-to and make a second copy clear somewhere and then merge different backups by hand. So I gave it --save-to=/somepath/

Wyng 0.8beta release 20230809
Enter passphrase: 
Encrypted archive 'file:/mnt/' 
Last updated 2023-10-07 11:36:49.082842 (+02:00)

!! This will erase all existing data in /somepath/ !!
   Are you sure? [y/N]: y
Traceback (most recent call last):
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 4672, in <module>
    count = receive_volume(storage, aset.vols[dv], select_ses=options.session or "",
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 3946, in receive_volume
    open(save_path, "wb").close()    ; sparse_write = sparse = False
    ^^^^^^^^^^^^^^^^^^^^^
IsADirectoryError: [Errno 21] Is a directory: '/somepath/'

[BernhardOnline]

OK, maybe I can use the --sparse command and write back immediately. But still, I do not know the qubes equivalent of "vg/pool" from the doc's: so pvs gives qubes_dom0 and lvs gives, say, vm-VMNAME-private (which happens to be identical with the "wyng list" output). So I tried

sudo python3 wyng receive vm-VMNAME-private --sparse --local=qubes_dom0/vm-VMNAME-private --dest=file:/mnt/

but I get "local storage is offline" (independently if the VMNAME is started or shut down). What am I missing again??

[tasket]

@BernhardOnline The --saveto option requires a full file path, since it only receives one volume at a time. So the path can end with an existing file (it will be overwritten) or a non-existent filename (a file will be created), but not a dir.

BTW, you can switch back to using the latest v0.8 since the archive is now updated with the proper format.

[tasket]

@BernhardOnline IDK if sparse is a help here; generally its used to save disk space and/or bandwidth.

The correct syntax for --local is volgroup/thinpool. In a default Qubes config it looks like this:

--local=qubes_dom0/vm-pool

---

Whether or not you decide to use --saveto, you should do a qvm-clone to make a backup of the target VM you previously restored. This is in case you run a Wyng command that overwrites the original VM volume path (e.g. if you clone the VM under a different name, then receive without a unique saveto path, then you will have both versions of the VM accessible under the two different VM names.... which is what I think you want).

[BernhardOnline]

That is what I did: clone & receive.

Wyng 0.8beta release 20230809
Enter passphrase: 
Encrypted archive 'file:/mnt/' 
Last updated 2023-10-07 11:36:49.082842 (+02:00)

!! This will overwrite existing data in /dev/qubes_dom0/vm-VMNAME-private !!
   Are you sure? [y/N]: y

Receiving volume 'vm-VMNAME-private' 20231007-113512
Saving to tlvm pool '/dev/qubes_dom0/vm-VMNAME-private'
Diff bytes: 143430254592 Data bytes: 138448029058 / 195421011968
Traceback (most recent call last):
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 4672, in <module>
    count = receive_volume(storage, aset.vols[dv], select_ses=options.session or "",
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 4152, in receive_volume
    save_storage.lvols[l_vol.snap2].create(snapshotfrom=vol.name, addtags=tags)
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 1679, in create
    do_exec([[CP.lvm, "lvcreate", "-kn", "-ay"] + rwmode + addtags + [
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 2491, in do_exec
    return close()[-1]
           ^^^^^^^
  File "/home/bernhard/wyng-backup-0.8beta1/src/wyng", line 2480, in close
    raise SPr.CalledProcessError([x for x in rclist if x][0], commands)
subprocess.CalledProcessError: Command '[['/usr/sbin/lvm', 'lvcreate', '-kn', '-ay', '-pr', '--addtag=wyng', '--addtag=arch-ea8e3b25-ac93-4861-978c-c2fc4a8479f6', '--addtag=S_20231007-113512', '-s', '/dev/qubes_dom0//vm-VMNAME-private', '-n', 'vm-VMNAME-private.tock']]' returned non-zero exit status 5.

Something went wrong ... disc full ??

[BernhardOnline]

I guess disc full (even though it stated 93% only. Anyways, I could mount the restored private volume inside dom0 (the VM would not start) - and I discovered the file I am after is not in this backup either. Bad luck for me, I have to write it again :)

The "overwrite" alert is present, even though I gave it --sparse. Is this wanted?

Maybe the "disc full" problem could be anticipated and a warning put out ? This time, a qvm-remove of the "new" copy saved my system, but i the worst case, a full disc can " freeze qubes to death ". Suffered that, some years ago.

thank you for all you help still