Manual · Chapter 8

Rescue medium: restoring a computer without a system

Go to the contents

When a computer no longer starts, its disk was replaced or is empty, or the whole computer was replaced, what would normally start a restore is missing: the installed AegisGrid with its bkp_agent.cfg. That is what the rescue medium is for: a small Linux of its own on a USB stick or as an ISO file that starts on any x86-64 computer (BIOS and UEFI, also with Secure Boot) and brings Windows and Linux computers back from their disk backups. A program guides through everything step by step: where the backups are, computer, point in time, target disks, adaptation to the hardware, confirmation, restore.

It needs backups of whole disks made with bkp_agent (a profile with source= on the disk, on Windows \\.\PhysicalDrive0). Such a run records how the computer was built (firmware, storage controllers, network cards, system, system partition); from this the rescue medium recognises the computer and what is different about the new hardware.

8.1 Making the medium#

In the management console: choose the client, then “Tools” › “Create rescue medium...”. The wizard downloads the medium from the update site of this installation (checked by its signature), writes it onto a USB stick or saves it as an ISO file and, if you want, adds the client's credentials package. Windows asks once for administrator rights. After the first backup of a computer the console offers the medium by itself.

On the command line (Linux and Windows, as root or administrator):

bkp_rescue_media --list                                   # USB sticks and removable disks
bkp_rescue_media --usb /dev/sdc --credentials             # medium + credentials of this computer (asks for the password)
bkp_rescue_media --iso /srv/iso/aegisgrid-rescue.iso      # as an ISO, e.g. for a VM or a DVD
  • Only USB sticks and removable disks are written, never a disk of the running system; before writing there is a question (--yes skips it). Everything on the stick is lost. After writing, the medium is read back and compared.
  • Next to the medium the stick gets a small partition AGRESCUE (FAT32). It holds the credentials package <computer>.agk, and the rescue medium can save its log there.
  • The credentials package holds the sinks of the computer with backup servers, API and encryption keys, encrypted with a password (at least 8 characters). Without the password it is useless; keep the package and the password apart from the computer. bkp_maintenance rescue-credentials --out <file>.agk makes a package on its own. Keys from a KMS (kms:) are not put in; they are typed in on the medium.
  • One medium fits all computers of an installation. Making it again is worth it after a big update or when the credentials changed.

8.2 Starting from the medium#

Start the computer from the stick (or from the DVD, or the ISO in a VM); usually a key such as F12, F11 or Esc at power-on opens the firmware's boot menu. The boot menu of the medium offers German and English and starts in German after 10 seconds; more languages (Spanish, French, Croatian) are chosen on the first page of the program.

  • Basic graphics (under “Advanced”) helps with a black screen: the medium then draws without graphics drivers.
  • Command line only starts a root shell without the program, for specialists. From the program, Ctrl+Alt+F2 opens a command line and Ctrl+Alt+F1 leads back.
  • The medium activates neither LVM nor software RAID and uses no swap: no disk of the computer is in use before the restore writes it.

8.3 The steps in the program#

  1. Language and keyboard. Another keyboard layout applies from the next step on.
  2. Network. With a cable the medium gets its address by itself (DHCP). WLAN and fixed addresses: see below. A backup on a USB disk needs no network.
  3. Credentials. The program looks for .agk packages on all disks; the chosen one opens with its password. Without a package the next step asks for the details by hand.
  4. Backups. Where they come from: the credentials package, a store on a disk or stick, a network share, a backup server (address, API key, fingerprint of its certificate) or S3. For encrypted backups choose the key as a file or type it in.
  5. Computer. The backed-up computers and their disks; normally all disks of the computer stay chosen.
  6. Point in time. The runs of the system disk, newest first. The other disks each take their run nearest in time.
  7. Target disks. The proposal is the smallest disk that fits, per backup. Disks that are too small are not offered, the rescue medium itself never.
  8. Adaptation. What is different about this computer compared with the backed-up one (firmware, storage controllers, network cards, physical or virtual) and what the program does about it (see “Other hardware” below).
  9. Confirmation. One warning card per target disk with size, model and what is on it. Only with the tick “I have understood: everything on these disks is lost.” can “Restore now” be chosen.
  10. Restore. Progress per disk, then the adaptation. “Cancel” stops; the target disk is then incomplete.
  11. End. Result and hints (for example: switch to UEFI in the firmware menu), saving the log on a stick, restart or switch off. Pull the stick before restarting.

8.4 Network: WLAN and a fixed address#

On the page “Network” the section WLAN lists the networks of the first WLAN card, strongest first. Choose the network, type the password, “Connect”. Open networks and networks with a password (WPA2, WPA3) are supported; networks with a user sign-in (WPA Enterprise) and the outdated WEP are not – use a network cable then.

Set a fixed address is only needed where the network gives out no addresses: choose the network card, enter the address with its prefix (for example 192.168.1.20/24), the gateway and up to four name servers, “Apply”. “Automatic again (DHCP)” undoes it. For a WLAN, connect first, then fix its address. The settings last only while the medium runs.

8.5 Other hardware#

When a system is restored onto other hardware, bkp_hwadapt adapts it before its first start; the rescue medium does this by itself after the restore. The page “Adaptation” shows beforehand what is different.

  • Windows: loads the drivers of the storage controllers at startup (AHCI, NVMe, IDE; VirtIO, Xen or Hyper-V where installed), removes filter drivers of hardware that is gone (such as Intel RST) and keeps the drive letter of the system. When a VM lacks the VirtIO drivers, the report names SATA and E1000E as the way.
  • Linux: names the file systems in /etc/fstab by UUID, builds the initramfs anew with the drivers for any hardware, puts the boot loader where a new computer finds it without a firmware entry (UEFI: EFI/BOOT/BOOTX64.EFI) and names network settings bound to the old network card. Systems in LVM and LUKS are found.
  • BIOS ↔ UEFI: When the new computer starts differently from the backed-up one, the page “Adaptation” offers to switch. Windows then gets a GPT partition table with a new EFI system partition (from free space or by shrinking its last NTFS partition), or an MBR table with an active system partition, each with the right boot files; Linux gets an EFI system partition or a BIOS boot partition and GRUB for the new firmware. Without switching, the system stays unchanged and the end page says how to set the firmware.
  • Secure Boot: Linux with the GRUB of the medium (when the system lacks the GRUB of the new firmware) is not signed for Secure Boot; the report then says to switch Secure Boot off.

By hand, for example after a restore with bkp_restore on another Linux:

bkp_hwadapt --disk /dev/sdb --dry-run                        # only show what would change
bkp_hwadapt --disk /dev/sdb --profile physical --firmware uefi --convert

Note: BitLocker: a Windows encrypted with BitLocker asks once for its recovery key after a restore onto new hardware. Have it ready beforehand.

8.6 A computer as a new VM#

The disk backups of a computer can also come back as a new virtual machine, for example when its hardware failed and the computer should go on as a VM for the time being. On a Proxmox or Xen host:

bkp_proxmox_restore --store /backup/default.cbs --from-machine pc01 --storage local-lvm
bkp_xenV_restore    --store /backup/default.cbs --from-machine pc01 --vg vg0
  • --name/--run choose the system disk; the other disks of the computer take their run at most a day from it (--single-disk only the one). Cores, memory, firmware and system come from the backup; without them 2 cores and 4 GiB apply and --firmware must be given.
  • The VM always gets a new SMBIOS UUID and a new MAC address (--keep-network-identity keeps the old one when known) and one network card (--bridge, default vmbr0).
  • Proxmox: q35, VirtIO for Linux and a Windows with VirtIO drivers, else SATA (at most 6 disks) and E1000E; UEFI with efidisk0 and for Windows 11 and Server 2022 and later a TPM. Xen: HVM, AHCI and E1000 for Windows.
  • Then bkp_hwadapt adapts the system to the VM. When that fails the VM stays; the message names the command to repeat it.

In the management console the restore wizard offers “As a new virtual machine on this host” for disk backups on a Proxmox or Xen client, with storage or volume group, MAC address, cores, memory and firmware.

8.7 Limits of the rescue medium#

  • Whole disks come back; single partitions or volumes are restored by bkp_restore in the running system (Chapter 7).
  • Software RAID (mdadm) as Linux root is not assembled yet; the adaptation then reports “no system found”.
  • VM backups (Proxmox, Xen, Hyper-V) do not belong on the rescue medium: they come back with the restore programs of the host (Chapter 7).
  • Hyper-V as the target of “a computer as a new VM” follows.