This is an automated archive made by the Lemmit Bot.
The original was posted on /r/selfhosted by /u/esiy0676 on 2025-01-10 17:18:48+00:00.
Summary: Restore a full root filesystem of a backed up Proxmox node -
use case with ZFS as an example, but can be appropriately adjusted for
other systems. Approach without obscure tools. Simple tar, sgdisk and
chroot. This is a follow-up to the previous post on backing up the
entire root filesystem offline from a rescue boot.
Better formatted at:
No tracking. No ads. OP r/ProxmoxQA
Previously, we have created a full root filesystem backup of our
host. It's time to
create a freshly restored host from it - one that may or may not share
the exact same disk capacity, partitions or even filesystems. This is
also a perfect opportunity to also change e.g. filesystem properties
that cannot be further equally manipulated after install.
Full restore principle
We have the most important part of a system - the contents of the root
filesystem in a an archive created with stock tar 1 tool - with
preserved permissions and correct symbolic links. There is absolutely NO
need to go about attempting to recreate some low-level disk structures
according to the original, let alone clone actual blocks of data. If
anything, our restored backup should result in a defragmented system.
IMPORTANT This guide assumes you have backed up non-root parts
of your system (such as guests) separately and/or that they reside on
shared storage anyhow, which should be a regular setup for any
serious, certainly production-like, system.
Only two components are missing to get us running:
- a partition to restore it onto; and
- a bootloader that will bootstrap the system.
NOTE The origin of the backup in terms of configuration does NOT
matter. If we were e.g. changing mountpoints, we might need to adjust
a configuration file here or there after the restore at worst.
Original bootloader is also of little interest to us as we had NOT
even backed it up.
UEFI system with ZFS
We will take an example of a UEFI boot with ZFS on root as our target
system, we will however make a few changes and add a SWAP partition
compared to what such stock PVE install would provide.
A live system to boot into is needed to make this happen. This could
be - generally speaking - regular Debian, 2 but for consistency, we
will boot with the not-so-intuitive option of the ISO installer, 3
exactly as before during the making of the
backup - this part is
skipped here.
[!WARNING] We are about to destroy ANY AND ALL original data
structures on a disk of our choice where we intend to deploy our
backup. It is prudent to only have the necessary storage attached so
as not to inadvertently perform this on the "wrong" target device.
Further, it would be unfortunate to detach the "wrong" devices by
mistake to begin with, so always check targets by e.g. UUID,
PARTUUID, PARTLABEL with blkid 4 before proceeding.
Once booted up into the live system, we set up network and SSH access as
before - this is more comfortable, but not necessary. However, as our
example backup resides on a remote system, we will need it for that
purpose, but everything including e.g. pre-prepared scripts can be
stored on a locally attached and mounted backup disk instead.
Disk structures
This is a UEFI system and we will make use of disk /dev/sda as
target in our case.
CAUTION You want to adjust this accordingly to your case, sda is
typically the sole attached SATA disk to any system. Partitions are
then numbered with a suffix, e.g. first one as sda1. In case of and
NVMe disk, it would be a bit different with nvme0n1 for the entire
device and first partition designated nvme0n1p1. The first 0
refers to the controller.
Be aware that these names are NOT fixed across reboots,
i.e. what was designated as sda before might appear as sdb on a
live system boot.
We can check with lsblk 5 what is available at first, but ours is
virtually empty system:
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashfs 4.0
loop1 squashfs 4.0
sr0 iso9660 PVE 2024-11-20-21-45-59-00 0 100% /cdrom
sda
Another view of the disk itself with sgdisk: 6
sgdisk -p /dev/sda
Creating new GPT entries in memory.
Disk /dev/sda: 134217728 sectors, 64.0 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 83E0FED4-5213-4FC3-982A-6678E9458E0B
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 134217661 sectors (64.0 GiB)
Number Start (sector) End (sector) Size Code Name
NOTE We will make use of sgdisk as this allows us good
reusability and is more error-proof, but if you like the interactive
way, plain gdisk 7 is at your disposal to achieve the same.
Despite our target appears empty, we want to make sure there will not be
any confusing filesystem or partition table structures left behind from
before:
WARNING The below is destructive to ALL PARTITIONS on the
disk. If you only need to wipe some existing partitions or their
content, skip this step and adjust the rest accordingly to your use
case.
wipefs -ab /dev/sda
sgdisk -Zo /dev/sda
Creating new GPT entries in memory.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
The operation has completed successfully.
The wipefs 8 helps with destroying anything not known to sgdisk.
You can use wipefs /dev/sda* (without the -a option) to actually see
what is about to be deleted. Nevertheless, the -b options creates
backups of the deleted signatures in the home directory.
Partitioning
Time to create the partitions. We do NOT need a BIOS boot partition on
an EFI system, we will skip it, but in line with Proxmox designations,
we will make partition 2 the EFI partition and partition 3 the ZFS pool
partition. We, however, want an extra partition at the end, for SWAP.
sgdisk -n "2:1M:+1G" -t "2:EF00" /dev/sda
sgdisk -n "3:0:-16G" -t "3:BF01" /dev/sda
sgdisk -n "4:0:0" -t "4:8200" /dev/sda
The EFI System Partition is numbered as 2, offset from the beginning
1M, sized 1G and it has to have type EF00. Partition 3
immediately follows it, fills up the entire space in between except
for the last 16G and is marked (not entirely correctly, but as per
Proxmox nomenclature) as BF01, a Solaris (ZFS) partition type. Final
partition 4 is our SWAP and designated as such by type 8200.
TIP You can list all types with sgdisk -L - these are the short
designations, partition types are also marked by PARTTYPE and that
could be seen e.g. lsblk -o+PARTTYPE - NOT to be confused with
PARTUUID. It is also possible to assign partition labels
(PARTLABEL), with sgdisk -c, but is of little functional use
unless used for identification by the /dev/disk/by-partlabel/ which
is less common.
As for the SWAP partition, this is just an example we are adding in
here, you may completely ignore it. Further, the spinning disk
aficionados will point out that the best practice for SWAP partition is
to reside at the beginning of the disk due to performance considerations
and they would be correct - that's of less practicality nowadays. We
want to keep with Proxmox stock numbering to avoid confusion. That said,
partitions do NOT have to be numbered as laid out in terms of order. We
just want to keep everything easy to orient (not only) ourselves in.
TIP If you got to idea of adding a regular SWAP partition to your
existing ZFS install, you may use it to your benefit, but if you are
making a new install, you can leave yourself some free space at the
end in the advanced options of the installer 9 and simply create
that one additional partition later.
We will now create FAT filesystem on our EFI System Partition and
prepare the SWAP space:
mkfs.vfat /dev/sda2
mkswap /dev/sda4
Let's check, specifically for PARTUUID and FSTYPE after our setup:
lsblk -o+PARTUUID,FSTYPE
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTUUID FSTYPE
loop0 7...
***
Content cut off. Read original on https://old.reddit.com/r/selfhosted/comments/1hy9i7k/restore_entire_proxmox_ve_host_from_backup/
