Problem with Instant Recovery when publish physical linux include lvm volumes.

[LunenK]

Due to the recent hardware failure of our Linux (Red Hat7) physical server, we used the Instant Recovery feature for immediate service.
However, due to the aging of the failed hardware, we moved from Instant Recovery to Production to continue operating in a virtualized environment.

In fact, the remaining datastore free space on the ESXi host was about 10TB, and the total capacity of the physical server was about 7TB even though it moved to Thick Provision.
However, production conversion failed due to host datastore capacity overruns, and VMDKs connected to VMs migrating to production had a total capacity of 13TB.
Eventually, after hardware repair, it was normalized to bare metal recovery.

We conducted a separate test on why this phenomenon occurred, and there was a problem as below.

- For physical server environments (using a single disk array)
 lsblk Command Result Value
  sda (750 GB)
  sda1 (200 MB) /boot/efi
  sda2 (1 GB) /boot
  sda3 (560 GB)
  rhel-root (240 GB) /
  rhel-swap (20 GB) /swap
  rhel-home (300 GB) /home
 Result: 750GB capacity per disk should be transferred to Thick

- Recovery to Instant VM results in additional disks being created
 lsblk Command Result Value
  sda (560 GB)
  rhel-root (240 GB) /
  rhel-swap (20 GB) /swap
  rhel-home (300 GB) /home
  sdb (750 GB)
  sdb1 (200 MB) /boot/efi
  sdb2 (1 GB) /boot
 Result: 1.41TB of capacity to go to Thick on 2 disks

be shown in the above resultsThe sda disk partition configured with LV was converted to one disk with LV in the backup.
The physical disk with the boot space appears as another disk with full capacity.
To see if this happens only with Instant Recovery, you can extract a VMDK from that backup with the Export Virtual Disk option.
Partitions and disks in selectable backups also show the same results as the Instant VM above.

However, bare metal recovery via recovery media shows partitioning such as the lsblk result value of the physical server.
When I performed P2V on that server using VMware Converter, it came up to the host with the same value as the physical server.

I understand that the Veeam Backup Repository has a virtualization conversion including VDMK and vmx before it drives Instant Recovery, and I have one more question.
You'll know for sure if you test it, but I want to know if there's any difference from what you think.

When using Instant Recovery, we understand that VM information is created in the C:\ProgramData\Veeam\Backup\IRCache\NfsDatastore subpath by default.
We found that the vmdk file shown here has less capacity than the actual usage, and that Host Datastore uses as much capacity as the actual Thick Provisioned capacity when switching to Production.
However, before the production transition, we also confirmed that vswp on the Veeam B&R server would hold the same amount of memory allocated to the VM.
If the initial configuration of Veeam B&R minimizes the amount of capacity allocated to C:\ to free up space in the Backup Repository, it is likely that Instant Recovery will experience problems with servers or multiple servers, including large memory.
I would like to know if the default installation path for Veeam B&R should be included on the same disk as Repository, or if I can change the location of that NfsDatastore directly.
If it is possible to change it, if you use a Linux Repository for Hardend, I would also like to check if it is available.
If not, if Linux Repository is proposed when taking a Veeam B&R configuration as a one-point backup for physical and virtual environments, I would like to ask you if there is any additional sizing required for the disk capacity of the Veeam B&R server.
In fact, at the time of Instant Recovery, we saw that C:\ had a capacity of 30GB out of 100GB, but up to 90GB.

Thank you.

[HannesK]

Hello,

I would like to know if the default installation path for Veeam B&R should be included on the same disk as Repository, or if I can change the location of that NfsDatastore directly.

per default, the instant recovery path takes the volume with the most free space during installation. If you have an old installation (I believe, before V10), then C:\ is used for the default repository.

The path can be (and should be if pointing to C:\) changed in the repository settings.

For Linux / hardened repositories: the mount server runs only on Windows today. So there is always another server involved for instant recovery.

Best regards,
Hannes