Bare metal recovery Linux machine (efi) partition information

I played a bit around with a physical linux machine which boots with efi. The goal is to do a bare metal restore to a virtual machine (hosted on HyperV).
For backup I used something like:
restic backup -v --password-file /path/to/password.txt --repository-file /path/to/repo.txt --exclude-file /path/to/excluded.txt
The excluded files were /proc/*, /sys/*, /var/*, /mnt/*, /media/*, /run/*

The backup went through without errors

I created a VM with a sufficiently large virtual hard disk and attached the iso of a live linux (GRML). I tied mounting the hard disk in to the live linux, but do not have any partition, file system etc. information, so writing to the disk is a bit difficult. I could recreate them with the information on the backup source, but in an actual hardware failure such information would no longer be available.

Is there a way to store that information in the backup and more importantly a way for restic to write that information during recovery?

Simply creating one large partition with ext4 filesystem obviously did not make the system bootable, but everything from the backup seemed to go onto the disk.

Please advise how to do a bare metal recovery with an efi system.

Thanks in advance and best regards.

[Edit]I found out that the efi and boot partitions are saved as regular folders and files.[/Edit]

Restic isn’t written to do full system and bare metal restores like that, so no. You’ll have to fix the partitions yourself. I guess you could dump partition layouts to a file and include that in the backup, then restore it when you’re doing the backup in order to more easily be able to set up the partitions.

Thanks. I guess if the program does not do that, it is my only option. Have you got a good method to read and dump all the relevant info?

Since the two other partitions are mounted to /boot and /boot/efi on the running system, what do I do with them during backup and restore? Right now they are saved in backup as regular directories/files. Do I include them in the backup but restore them to the other partitions?

Can’t remember when I last had to do that, but I think parted and similar tools can both export and import partition layouts easily.

No idea. This type of restore is not something restic was built for. Personally I don’t see why one wouldn’t just install a new OS and then restore the key things onto it instead.

Perhaps someone else has ideas - there’s been threads on this topic before so if you search around you might find some, either here or in the issues over at GitHub.

I have recently done just that on an Ubuntu system that I wanted to convert from ecryptfs to LUKS. And it worked perfectly. My restic datbase includes the my /home dirs on multiple systems.
Specifically, I did the following:

  1. Booted the live system from the USB, wiped the disks, and installed the OS, this time using LUKS
  2. After the install, I confirmed that the UID/GID of the installer-created user and the restic data were the same
  3. I installed restic and did the restore of the /home for that machine into newly restored OS. This worked perfectly. All of the creation and access dates were correctly preserved, but one has to wait until the restic restore command completes to verify that.
  4. I also periodically make a copy of the /etc and installed package list for restoring the deb packages. I retrieved the package list using restic mount

No problems.


I’ve had some cases for this, mainly involving a third-party commercial app: with a bare-metal restore you get up and running with your server data, apps and configurations only having to wait for the restore to complete.
If you cannot do a bare-metal, then the time to get up and running increases, sometimes a lot (think on enterprise servers: time to install os + time to recover + time to third-party engineers to setup their software, apps and services and get everything running, this one is by far the one you want to avoid whenever possible).
Time to recover can be determinant for a backup solution (this is why I’m moving all my servers from Duplicati to Restic), and having a bare metal recovery is a sweet feature on any backup system.

1 Like