Access to qubes backup on secondary drive

[tntomato]

I was running qubes 4.2 with a backup/archive appVM that was running on an LVM spanning two external SSDs (both LUKS encrypted). I used this post as a guide:

How to create a secondary internal drive just for qubes backups

I havre a fresh installation of qubes running on my internal /dev/sda drive. Now, I have a secondary LUKS encrypted internal drive at /dev/sdb. What I want to do, is automatically mount the secondary drive at boot, and then be able to backup my qubes (Using qubes backup application) directly to the secondary encrypted drive. I have followed the Example HDD setup for installing a secondary drive, but those instructions assume that you want to use the secondary drive to run current qubes off of, …

I tried to do an in-place upgrade to 4.3, but after stage 3 I rebooted and it couldn’t find the kernel. I figured I screwed something up and just did a fresh install of 4.3 on my internal nvme. I can see both LUKS drives using fdisk -l (dev/sda and dev/sdb), but don’t know how to get access to my backups.

I’m thinking I screwed up by creating a thinpool and spanning the backup/archive appVM over 2 drives…

Does anyone know how I can get access to the data on these 2 drives now that I have upgraded to 4.3?

Thanks!

[corny]

Use cryptsetup to luks unlock both drives

Use lvscan and vgscan to get the lay of the land (names of the qubes you need to mount)

Use vgchange to make the volume group active

Mount the needed qube LV (where the backups are) and copy them to the new Qubes install

I assume because you did this complicated setup that you know how to do these things but let me know if you need a cli command or two

[tntomato]

Isblk gives me the following:

sda
|__luks-9dbbedaa-…
sdb
|__luks-eo48c70b-…
nvme0n1 (with all my current qubes pools under it)

When I type sudo cryptsetup luksOpen /dev/sda recoveryTarget, I get prompted for a password which I enter and it tells me “Cannot use device /dev/sda which is in use”.

I can’t get past this for some reason. Thanks again for your help.

[corny]

Does lsblk show sda being at /dev/mapper/recoveryTarget ?

Can you sudo mount /dev/mapper/recoveryTarget /mnt

Or

Vgscan

Lvscan

Or vgchange -ay qubes_dom0

Then sudo mount /devPathtoVM /mnt

[tntomato]

No, no mounting point for sda or sdb by lsblk.

I did the mount command and it says “fsconfig system call failed: /dev/mapper/recoveryTarget: Can’t lookup blockdev”.

sudo vgscan gets me" found volume group “qubes_dom0” using metadata type lvm2

sudo lvscan gets me all of my active VM pools (?). All under /dev/qubes_dom0/, but no mention of /dev/sda or sdb

[corny]

Is lvscan showing the new install lv’s or the appVM backup lv’s ?

Perhaps the vg name for the new Qubes install is the same (qubes_dom0) as the one on the old backup spanning sda sdb. Can you do the recovery on another computer ? Or put sda and sdb in USB enclosures and attach them to an appVM (so they don’t see dom0 vg and lv’s) ?

When I do a recovery I do it the latter way