Backup entire Proxmox VE host
We will create a full host backup - one that is safe, space-efficient and the re-deployment scenario target agnostic. Entire PVE host install (without guests) typically consumes less than 2G of space and it makes no sense to e.g. go about cloning entire disk (partitions), which a target system might not even be able to fit, let alone boot from.
Rescue boot
First, we will need to access our system offline, from a separately booted system. A method to follow prior to taking steps described below is covered in a separate post on how to rescue boot from PVE ISO installer - it also explains why a regular Debian Live system might NOT be of good use.
Alternatively, a bespoke live system can fulfill this task, especially with a network boot option, like in a professionally maintained setup.
Chroot
Assuming we have the host root filesystem mounted under /mnt, we first require paths to appear as-if real from the viewpoint of a system we are backing up, i.e. everything under mounted under /mnt/ should appear as if it was / on the currently booted system. That’s where chroot has us covered:
chroot /mntUntil we then finalise it with exit, our environment does not know anything above /mnt and most importantly it considers /mnt to be the actual root (/) as would have been the case on a running system.
Full host backup
The simplest backup of any Linux host is simply a full copy of the content of its root / filesystem. That really is the only thing one needs a copy of. And that’s what we will do here with tar:
tar -cvpzf /backup.tar.gz --exclude=/backup.tar.gz --one-file-system / This will back up everything from the (host’s) root (/ - remember we are chroot’ed), preserving permissions, and put it into the file backup.tar.gz on the very (imaginary) root, without eating its own tail, i.e. ignoring the very file we are creating here. It will also ignore mounted filesystems, but we do not have any in this case.
Note
Of course, you could mount a different disk where we would put our target archive, but we just go with this rudimentary approach. After all, a GZIP’ed freshly installed system will consume less than 1G in size - something that should easily fit on any root filesystem.
Once done, we exit the chroot, literally:
exitWhat you do with this archive - now residing in /mnt/backup.tar.gz is completely up to you, the simplest possible would be to e.g. securely copy it out over SSH, even if only just a fellow PVE host:
scp /mnt/backup.tar.gz root@10.10.10.11:~/The above would place it into the remote system’s root’s home directory (/root there).
Tip
If you want to be less blind, but still rely on just SSH, consider making use of SSHFS. You would then “mount” such remote directory, like so:
apt install -y sshfs
mkdir /backup
sshfs root@10.10.10.11:/root /backupAnd simply treat it like a local directory - copy around what you need and as you need, then unmount.
That’s it
Do not forget to gracefully reboot or shutdown the system as described in the rescue boot guide .
If you wonder how this is sufficient, how to make use of such “full” backup (of less than 1G) and ponder the benefit of block cloning entire disks with de-duplication (or lack thereof on encrypted volumes) only to later find out the target system needs differently sized partitions with different capacity disks, or even different filesystems and is a system booting differently - there’s none and we will demonstrate so in a follow-up guide on restoring the entire system from the tar backup .