4 - Ubuntu with LUKS: Backup and Restore with Veeam Part 4 - Getting ready for bare-metal restore

If you have followed the previous parts, you will now have a backup of your Ubuntu computer, but you are not as ready as you could be to perform a restore to bare metal. In this part, I will show what else needs to be done to be able to perform a bare-metal restore. On the off chance that you have lost access to the Ubuntu computer before you were able to perform the steps I will show in this part, but you do have a backup, I will consider this possibility too during restore.

Take note of LUKS container properties, sector/cluster/block sizes

For reasons that I will explain in a later part, it now makes sense to write down a few things. The short explanation is that Veeam cannot restore the LUKS container. You will have to re-create it manually and for that, it helps to know what it looked like before the restore. This is important in particular because when Ubuntu installer creates a LUKS partition and container, depending on your physical disk, it defaults to a different sector size than what you get when you use cryptsetup or Veeam recovery UI to create a new container.

If you have not already done so, save the device name of your operating system disk in a variable. To find out the device name of the operating system disk, see part 1. In my case, the operating system disk is /dev/sda.

OSdisk='/dev/sda'

Partition table, logical/physical sector size of the OS disk

Also note the partition layout in general and the logical and physical sector size of the operating system disk in particular.

admin01@testlabubuntu01:~$ sudo gdisk -l $OSdisk
GPT fdisk (gdisk) version 1.0.8
...
Sector size (logical/physical): 512/4096 bytes
...
First usable sector is 34, last usable sector is 266338270
Partitions will be aligned on 2048-sector boundaries
...
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2203647   1.0 GiB     EF00
   2         2203648         6397951   2.0 GiB     8300
   3         6397952       266336255   123.9 GiB   8300
admin01@testlabubuntu01:~$

EFI system partiton (ESP), mounted as /boot/efi (here: /dev/sda1)

Though rather unimportant (unless you intend to restore to a disk with different logical/physical sector sizes), you can check the cluster size of the FAT32 formated EFI System partition (ESP, here: /dev/sda1). If you created your own Ubuntu live based recovery media, as I have shown previously, you can install mtools

sudo apt install mtools

And then use minfo.

admin01@testlabubuntu01:~$ sudo minfo -i ${OSdisk}1 | grep -E 'sector size|cluster size'
Hidden (2048) does not match sectors (63)
sector size: 512 bytes
cluster size: 8 sectors
admin01@testlabubuntu01:~$

The cluster size in bytes is sector size * cluster size. here: 512 * 8 = 4096. You can ignore the warning 'Hidden (2048) does not match sectors (63)'. It just means that the partition is properly aligned.

Bootloader (GRUB) partition, mounted as /boot (here: /dev/sda2)

As for the /boot partition (EXT4), here: /dev/sda2: Block size of /boot is also unimportant by the way, because it does not impact performance.

admin01@testlabubuntu01:~$ sudo tune2fs -l ${OSdisk}2 | grep "^Block size:"

Block size:               4096

admin01@testlabubuntu01:~$

As far as my testing goes, the sector/block size of the ESP and /boot partition will always be same after the restore as it was before the restore because Veeam restores them as they were before. To a fault actually, because when I tried to restore a backup from a 512e disk onto a 4Kn disk, this led to Veeam not properly restoring the ESP partition.

LUKS container mounted as /dev/mapper/dm_crypt-0 (here: /dev/sda3)

admin01@testlabubuntu01:~$ sudo cryptsetup luksDump ${OSdisk}3 | grep -E 'sector|UUID'

UUID:           d8073181-5283-44b5-b4dc-6014b2e1a3c2

        sector: 4096 [bytes]

admin01@testlabubuntu01:~$

Of interest here is the sector size of the LUKS container and the container/partition UUID, but you might want to take note of some other properties here as well.

admin01@testlabubuntu01:~$ sudo cryptsetup luksDump ${OSdisk}3 | grep Cipher
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
admin01@testlabubuntu01:~$

LVM /dev/mapper/ubuntu--vg-ubuntu--lv mounted as /

Next, check the block size of the LVM mapper device. This should be the same as the LUKS container sector size.

admin01@testlabubuntu01:~$ sudo blockdev --getss /dev/mapper/ubuntu--vg-ubuntu--lv

4096

admin01@testlabubuntu01:~$

Or you can use tune2fs.

admin01@testlabubuntu01:~$ sudo tune2fs -l /dev/mapper/ubuntu--vg-ubuntu--lv | grep "^Block size:"

Block size:               4096

admin01@testlabubuntu01:~$

You can also check with stat.

admin01@testlabubuntu01:~$ sudo stat -f / | grep 'Block size'

Block size: 4096       Fundamental block size: 4096

admin01@testlabubuntu01:~$

Documenting LUKS container properties, sector/cluster/block sizes

I recommend you save the container properties on the disk. This way, it will be backed up and you will have it available during restore. Copy & paste the entire paragraph below and paste it to the shell in one go.

d=${HOME}'/RestoreInfo'

mkdir $d

sudo gdisk -l $OSdisk > ${d}/gdisk

sudo minfo -i ${OSdisk}1 > ${d}/minfo-partition-1

sudo tune2fs -l ${OSdisk}2 > ${d}/tune2fs-partition-2

sudo blockdev --getss \

    /dev/mapper/ubuntu--vg-ubuntu--lv > \

    ${d}/blockdev-ubuntu--vg-ubuntu--lv

sudo cryptsetup luksDump ${OSdisk}3 > ${d}/luksDump  
sudo tune2fs -l \

    /dev/mapper/ubuntu--vg-ubuntu--lv > \

    ${d}/tune2fs-ubuntu--vg-ubuntu--lv

sudo stat -f / > ${d}/stat-root-file-system

You should now have several files which contain all the above information. These are stored in a directory named RestoreInfo in your home directory.

admin01@testlabubuntu01:~$ echo $d

/home/admin01/RestoreInfo

admin01@testlabubuntu01:~$ ls $d

blockdev-ubuntu--vg-ubuntu--lv  stat-root-file-system

gdisk                           tune2fs-partition-2

luksDump                        tune2fs-ubuntu--vg-ubuntu--lv

minfo-partition-1

admin01@testlabubuntu01:~$

But I don't have access to the Ubuntu computer anymore, because it was hacked/I wiped it just to see if I could successfully restore it/it was abducted by aliens! What can I do?

The above information about partition layout and LUKS container properties helps during bare-metal restore, but it is not strictly necessary. It allows you to verify that the partition layout and LUKS container were re-created exactly as they were before the restore. If you don't have that information, you will still be able to successfully restore the system.

Final preparation

Now is a good time to ensure that

• you have created bootable media,
  or you have access to the recovery media files even if the Ubuntu host is offline and you are able to create as needed, bootable media from the ISO files (for instance with Rufus)
  or you have verified that you can successfully create a recovery media using an Ubuntu live system
• the recovery media can successfully boot on the Ubuntu host
• the recovery media can access the host's disks
• the recovery media can access the backup location (in my case, this is a remote repository)
  
• you have knowledge of the 
• operating system disk physical properties
• partition layout 
• file system sector/block sizes
• LUKS container properties

The following is only relevant if the backup will be stored in a repository and you will access it through VBR server. Ensure that

• the recovery media has network connectivity and can reach the VBR server
• you have configured access for a user that will be used to access the repository and restore from backup

System administrators who use Veeam mainly for backing up and restoring virtual machines might have to have set up repository access. To set up repository access for a user, in VBR console go to Backup Infrastructure, right click on the repository and choose "Access permissions ...".

Now choose "Allow the following accounts or groups only" and add a user or group. It can also be an Active Directory user or group. Make sure that this user can access the repository through Veeam recovery media.

Note that you do not need to set up encryption here. The encryption setting in the screenshot above, only pertains to scenarios in which an agent targets a backup repository but is not configured through the VBR server. A scenario that in my opinion does not make sense, because even if the agent works in standalone mode, I still would like to configure the job through VBR.

If all that is there, you should be able to successfully restore the system to bare-metal which is what happens in the next part.