Troubleshoot initialization errors

[tlaurion]

Hello, it's me again.

After attempting approximative migration from sparsebak to wyng, I got my qubesos installation foobar. Got smart enough to clone my disk to another one prior to mess with it even more and was able to use qubesos native backup to restore daily used VMs on fresh installation.

Now, I still have my sparsebak backups of used and unused AppVMs volumes on internal encrypted additional m2 drive, mounting the luks encrypted container. All backups are there, including the one that got stalled on the prune attempt, under /backups/sparsebak

I would love to know which steps are needed to move things around, do arch-init properly and continue monitor and send operations effectively, while trying to salvage data from the backup that caused it and locked the LVM and caused me to reinstall.

I just cloned my daily used disk to another disk and am ready to test instructions and report back any issue in a migration procedure away from sparsebak to wyng.

Thanks!

[tlaurion]

Attempts

backup AppVM:
mv /run/user/Backup/QubesOS/sparsebak /run/user/Backup/QubesOS/wyng.backup

Exerpt of archive.ini found under /run/user/Backup/QubesOS/wyng.backup/default/:

[var]
chunksize = 65536
compression = zlib
compr_level = 4
hashtype = sha256
vgname = qubes_dom0
poolname = pool00
destsys = qubes://backup
destdir = QubesOS
destmountpoint = /run/media/user/Backup
uuid=blah

dom0:

sudo mkdir /var/lib/wyng
sudo wyng-backup-master/wyng --from=qubes://backup/run/media/user/Backup --subdir QubesOS arch-init

Metadata will be read from the archive;
Please check that the archive is in a trusted, secure condition!
Proceed? [y/N] y
Traceback (most recent call last):
  File "wyng-backup-master/wyng", line 2249, in <module>
    aset         = get_configs_remote()
  File "wyng-backup-master/wyng", line 474, in get_configs_remote
    new_aset = ArchiveSet(aset.name, new_path)   ; new_aset.destsys = aset.destsys
  File "wyng-backup-master/wyng", line 67, in __init__
    self.vgname)
  File "wyng-backup-master/wyng", line 157, in __init__
    s = self.sessions[sprev] = self.Ses(self, sprev, path+"/"+sprev)
TypeError: Can't convert 'NoneType' object to str implicitly

[tlaurion]

Interestingly, /var/lib/wyng.backup/ was created, including archive.ini and other subdirs, including their volinfo.

So I tried:

sudo wyng-backup-master/wyng monitor
Traceback (most recent call last):
  File "wyng-backup-master/wyng", line 2238, in <module>
    aset             = get_configs()
  File "wyng-backup-master/wyng", line 424, in get_configs
    aset    = ArchiveSet(aname, metadir+topdir)
  File "wyng-backup-master/wyng", line 67, in __init__
    self.vgname)
  File "wyng-backup-master/wyng", line 157, in __init__
    s = self.sessions[sprev] = self.Ses(self, sprev, path+"/"+sprev)
TypeError: Can't convert 'NoneType' object to str implicitly

sudo wyng-backup-master/wyng list
Traceback (most recent call last):
  File "wyng-backup-master/wyng", line 2238, in <module>
    aset             = get_configs()
  File "wyng-backup-master/wyng", line 424, in get_configs
    aset    = ArchiveSet(aname, metadir+topdir)
  File "wyng-backup-master/wyng", line 67, in __init__
    self.vgname)
  File "wyng-backup-master/wyng", line 157, in __init__
    s = self.sessions[sprev] = self.Ses(self, sprev, path+"/"+sprev)
TypeError: Can't convert 'NoneType' object to str implicitly

Waiting for any tip @tasket !

[tasket]

@tlaurion I just ran into this bug today! I believe its only triggered by the presence of an empty volume dir. It should be fixed in the beta3 branch now.

Also see my comments in issue #46.

[tasket]

Fixed sprev loop in 5dd5606

[tasket]

In reference to migration guide, I was pretty sure the Troubleshooting section of the readme would suffice. With those two commands no import is necessary.

However, if you are migrating from sparsebak and importing the config at the same time, then skip the 'local' command, do the 'remote' command and then use wyng --from=qubes://backup/run/media/user/Backup --subdir QubesOS arch-init like you did.

[tlaurion]

Downloaded beta3 archive from github.
Moved it in dom0 with:
qvm-run --no-gui --pass-io Insurgo "cat /home/user/Downloads/wyng-backup-beta3.zip" > /home/user/wyng-backup-master.zip

[user@dom0 ~]$ unzip wyng-backup-master.zip 
Archive:  wyng-backup-master.zip
b1673eb57e902b1eaf0a1bfbbf4c4e8b51b6f90d
   creating: wyng-backup-beta3/
  inflating: wyng-backup-beta3/LICENSE  
  inflating: wyng-backup-beta3/README.md  
   creating: wyng-backup-beta3/media/
  inflating: wyng-backup-beta3/media/become_a_patron_button.png  
  inflating: wyng-backup-beta3/media/lp_donate.svg  
   creating: wyng-backup-beta3/misc/
  inflating: wyng-backup-beta3/misc/spbk-assemble  
  inflating: wyng-backup-beta3/wyng  
[user@dom0 ~]$ sudo wyng-backup-master/wyng --from=qubes://backup/run/media/user/Backup --subdir QubesOS arch-init

Metadata will be read from the archive;
Please check that the archive is in a trusted, secure condition!
Proceed? [y/N] y
Traceback (most recent call last):
  File "wyng-backup-master/wyng", line 2249, in <module>
    aset         = get_configs_remote()
  File "wyng-backup-master/wyng", line 474, in get_configs_remote
    new_aset = ArchiveSet(aset.name, new_path)   ; new_aset.destsys = aset.destsys
  File "wyng-backup-master/wyng", line 67, in __init__
    self.vgname)
  File "wyng-backup-master/wyng", line 157, in __init__
    s = self.sessions[sprev] = self.Ses(self, sprev, path+"/"+sprev)
TypeError: Can't convert 'NoneType' object to str implicitly

[tasket]

@tlaurion There is now a debug branch: https://github.com/tasket/wyng-backup/tree/debug

It shows basic info for the volume and each session as they are being loaded. I think the problem is with a damaged 'info' file and this will tell us which one. When the error occurs, could you also post the contents of the 'info' files from the last 2 sessions shown?

[tasket]

@tlaurion I've added a --debug switch to the beta3 branch (which is now merged to master), along with some minor fixes and tying up loose ends. (Also, if you don't normally use deduplication, you'll find that send operations are a bit quicker and smaller now.)

[tlaurion]

@tasket
From master with debug merged:
sudo wyng-backup-master/wyng --from=qubes://backup/run/media/user/Backup --subdir QubesOS arch-init
no error

sudo wyng-backup-master/wyng monitor --debug
[...]
Preparing snapshots...
Warning: vm-whonix-ws-15-private does not exist!
Traceback (most recent call last):
  File "wyng-backup-master/wyng", line 2388, in <module>
    monitor_send(datavols, monitor_only=True)
  File "wyng-backup-master/wyng", line 1530, in monitor_send
    = prepare_snapshots(selected if len(selected) >0 else datavols)
  File "wyng-backup-master/wyng", line 860, in prepare_snapshots
    raise RuntimeError("ERROR: Sessions exist but no map for "+datavol)
RuntimeError: ERROR: Sessions exist but no map for vm-fedora-30-docker-root

Every run of the command gives the same error for different volumes.

until sudo wyng-backup-master/wyng monitor --debug; do echo "retrying"; done
[...]
Preparing snapshots...
Warning: vm-anon-whonix-private does not exist!
Warning: vm-whonix-ws-15-private does not exist!
Traceback (most recent call last):
  File "wyng-backup-master/wyng", line 2388, in <module>
    monitor_send(datavols, monitor_only=True)
  File "wyng-backup-master/wyng", line 1530, in monitor_send
    = prepare_snapshots(selected if len(selected) >0 else datavols)
  File "wyng-backup-master/wyng", line 860, in prepare_snapshots
    raise RuntimeError("ERROR: Sessions exist but no map for "+datavol)
RuntimeError: ERROR: Sessions exist but no map for vm-sys-usb-left-up-private

[tasket]

@tlaurion OK, a missing deltamap on its own is easy to fix. You can do a wyng --remap diff volname to recreate it for each volume.

However, this suggests that you followed a workflow (i.e. use case) that I didn't anticipate. For example, the error message could have at least mentioned --remap diff as a workaround.

I think I understand the use case as having some backed-up LVs present, but needing to re-load the wyng metadata for some reason (that reason being the sparsebak -> wyng snafu we had earlier). So this is an emergency recovery situation in some sense, and wyng could help the user further with recovery.

[tlaurion]

@tasket :
sudo wyng-backup-master/wyng list|awk -F " " '{print $3}'|tail -n +4|while read volname; do sudo wyng-backup-master/wyng --remap diff $volname; done

But doing them one by one, not all at once as expected in the loop

[tlaurion]

Well, doing it in infinite loop until I only get visual output saying there is no more remapping needed.
(would be nice to be able to remap all volumes known to wyng)

[tasket]

Yes, I'm thinking about that one. Maybe an '--all' option for diff.

[tlaurion]

All good for me!