Hello all,
I have proxmox backup server backing up the vm and lxcs. I cannot find the preferred way to backup the hosts?! I have 2 proxmox servers running zfs not ceph.
Currently researching Relax-and-Recover - Linux Disaster Recovery as a possible solution for bare metal recovery?
Whats is your best practice for backing up the physical proxmox server and its zfs data?
Thank you,
Franco
Welcome to the forum!
It depends. My advise is to stay away from ReaR, unless you really want to back up the OS itself. I personally see no reason for backing up an OS, all you want is your programs data. If you run a website, just back up your web pages and reverse proxy configurations on a schedule. If your site has a database, run a dump every so often. If your software has built-in backup commands (like gitlab does), perform that (along with whatever else you need to back up, like the actual git repo and the DB).
With proxmox, you could make a VM template with 1 disk, all configured the same, then add a 2nd disk with specially crafted file systems for each. For example, disk 2 would contain a mysql data volume and a small “local configs” partition. You bind mount the small config volume from disk to, to places like /etc/mysql and whatever else that’s considered “machine state” there, then you use zfs snapshots and zfs send / receive, to back up the VM’s disk 2. Make sure you run some automation through SSH, like stop the DB, take a snapshot on proxmox, start the DB, then move the snapshot to another host - you can look into zfs-autobackup (note that I never used it, I personally just back up my data using restic to a NFS volume).
You make any configuration change, then symlink or bind-mount the file from the general file system, over to the disk 2 volume. Keep all the “machine state” there and you will always have a backup of that disk. Alternatively, instead of zfs snapshots and send, you can just back up that data with other tools (like aforementioned restic).
I’m highly against OS backups, unless really necessary. You should always take backups and have an easy automation script that grabs the restored data and reinitiates the “deployment” (i.e. if you VM crashes and burns, you deploy a new VM, create a new empty vdisk 2 for it and zfs-send the old snapshot to this disk, then mount the disk and run the software deployment, like mysql install and start, using the provided config from the machine state path on disk 2 - absent zfs snapshots, just format the disk 2 and copy the old files to the freshly formatted disk).
You shouldn’t be dependent on your OS to run your software, you should always be able to install the OS fresh, take your old configs and data and resume operations. That’s part of the reason docker is very popular (I’m not a fan of OCI containers, but I see where the enthusiasm around them comes, which is reproducible builds and easy redeployment).