File restore error on LVMs

john.c

@flakpyro said in File restore error on LVMs:

Here is the output of vgdisplay and lvdisplay from the VM being backed up.

  --- Volume group ---
  VG Name               ubuntu-vg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  6
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <58.00 GiB
  PE Size               4.00 MiB
  Total PE              14847
  Alloc PE / Size       14847 / <58.00 GiB
  Free  PE / Size       0 / 0   
  VG UUID               iUJyAl-7Ltq-IvF5-xla3-RA1E-bYP5-QJABwy

  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/ubuntu-lv
  LV Name                ubuntu-lv
  VG Name                ubuntu-vg
  LV UUID                bwEE3c-fkgc-nATq-czqZ-TkdK-xFA1-ULmRGz
  LV Write Access        read/write
  LV Creation host, time ubuntu-server, 2022-05-30 11:47:36 -0600
  LV Status              available
  # open                 1
  LV Size                <58.00 GiB
  Current LE             14847
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

Its basically a bog standard Ubuntu install. The file system on the LV is XFS.

The active system and backup should have the same exact layout. And no missing virtual disks.

Does the UUID from the backup match the one from the live machine?

Does the VG name matchup with backup and live machine?

flakpyro

@john-c Yep nothing has been renamed in regards to the LV or VG name inside the VM. I have not made any recent changes to this VM or the backup job itself.

I assume the UUID matches up as the VM is displayed by its name in the "VMs to backup" section of the backup job and not simply displayed as a UUID.

john.c

@flakpyro said in File restore error on LVMs:

@john-c Yep nothing has been renamed in regards to the LV or VG name inside the VM. I have not made any recent changes to this VM or the backup job itself.

I assume the UUID matches up as the VM is displayed by its name in the "VMs to backup" section of the backup job and not simply displayed as a UUID.

I'm referring to the UUID of VG, PV and LV of the disks used by VM's OS (on live) and in the backup. Cause if these change then it can cause issues with bringing the LVM VG back up into operation.

Thus afterwards the mounting of the LVM LV's from the VG on the VM's Linux based Operating System will have trouble as a result. So wouldn't be able to get the root directory (/). Which is what several people are trying to restore into.

flakpyro

@john-c Do you know what would cause them to change? I am testing a restore from last nights backup so i assume the UUIDs have not changed. I could do a full restore from last nights backup however and compare to be sure.

john.c

@flakpyro said in File restore error on LVMs:

@john-c Do you know what would cause them to change? I am testing a restore from last nights backup so i assume the UUIDs have not changed. I could do a full restore from last nights backup however and compare to be sure.

Do the restore then compare to check, to see whether they have changed.

If you have done any of the following or if XOA has done any of the following when performing the requested functions, it would cause the UUID for LVMs to change:-

Create a new LVM
Edit Metadata Directly
Delete and recreate
Change Filesystem UUID
Change the member disk's location address - virtual bus connecting virtual disk

Also if the actions in XOA or XCP-ng affect the member disk's address visible inside of the VM then this would affect the metadata.

@florent Your employer did that new Debian 12 based XOA since 2021 are the packages for lvm2 and any relevant NodeJS NPM ones included in the appliance?