[SOLVED] Official way to backup proxmox VE itself?

[Kingneutron]

https://github.com/kneutron/ansitest/tree/master/proxmox

Have a look at the bkpcrit-proxmox and bkpsys-2fsarchive scripts. There's also a restore script under Virtbox:

https://github.com/kneutron/ansitest/blob/master/VIRTBOX/RESTORE-fsarchive-root.sh

This should work fine for LVM+ext4; schedule both to run every Friday and before making ANY system changes, including config file edits and package upgrades.

You should probably run the proxmox installer to recreate your disk setup, then boot into a rescue environment and use the script to restore from the .fsa file. After rebooting, your whole proxmox environment should be back to the way it was.

 

[Photon4]

TrueNAS is only an appliance. There you are not supposed/allowed to touch anything that isn't integrated in the webUI.
PVE is a full OS any you can tamper with it as you like, install whatever you want and so on.
If I decide that I want to install a desktop environment and steam to play some games directly on the PVE host, that is possible. How should the backup feature know how to backup the save games of my games so I can continue playing those games once I restore the backup to some other server?
Its a stupid but still valid example.

You could reduce complexity by only backing up the contents of the config.db but then everyone with an advanced usecase would be screwed that requires to install additional packages or edit Debian config files via CLI. Atleast here, most work when setting up PVE is all the stuff that isn't covered by PVE itself. Monitoring agents, Log collectors, SIEM agent, mail server, custom scripts and systemd services, encryption, UPS client, ... all stuff that has to run on the PVE host and not in a VM/LXC.

If you want to cover all of that too, you would need to backup the whole root filesystem.

That makes sense, thanks for the info!

My 2 cents: Make as little changes AP to the PVE host system & document (in a safe place) all changes you've had to make. EVRYTHING else should be in an LXC/VM - then its not to hard to reinstall a fresh system.

Thankfully, I don't have my instance doing too much and I already made my documentation so I can recreate things as needed. I'm replacing my current Proxmox setup running on a NUC with the new Minisfourm MS-01 which is what lead me down the rabbit hole trying to migrate over if possible or fresh install. The other rabbit hole I'm looking down is a single disk OS install or RAID 1 with a complicated replacement process... Haven't decided on that one though.

 

[Kingneutron]

https://github.com/kneutron/ansitest/tree/master/proxmox

Have a look at the bkpcrit-proxmox and bkpsys-2fsarchive scripts. There's also a restore script under Virtbox:

https://github.com/kneutron/ansitest/blob/master/VIRTBOX/RESTORE-fsarchive-root.sh

This should work fine for LVM+ext4; schedule both to run every Friday and before making ANY system changes, including config file edits and package upgrades.

You should probably run the proxmox installer to recreate your disk setup, then boot into a rescue environment and use the script to restore from the .fsa file. After rebooting, your whole proxmox environment should be back to the way it was.

Update - I have been working all morning, testing a restore of my primary PVE host into a VM and put out some proxmox-specific restore scripts.

https://github.com/kneutron/ansitest/tree/master/proxmox

Caveat: The restore won't boot grub for some reason, so keep a copy of Super Grub Disc around and that should boot it. Once up and running you can login as root and ' grub-install /dev/blah '

NOTE - if you test-restore your PVE into a VM and there are zpool(s) and mount points that exist on the host but not in-vm, you should:


systemctl disable zfs-import@zpoolnamehere

in-vm and it should not hold up the reboot anymore. Either that or just recreate the zpool.

Also make sure /etc/fstab is not trying to mount things that don't exist in-vm.

You may also want to disconnect the VM's network interface when test-booting so you don't get IP conflicts.

Please feel free to test these scripts and let me know if there are any issues.

You should know that you'll be able to restore your PVE non-zfs root reliably and get back to a running state in a DR situation, what steps need to be taken to accomplish that goal, and the ETA to accomplish same. 1-2 hours is not unreasonable if you have to change out a disk or have a large root backup / slow network; if you get done before that, so much the better.

 

[Kingneutron]

Update - I have been working all morning, testing a restore of my primary PVE host into a VM and put out some proxmox-specific restore scripts.

https://github.com/kneutron/ansitest/tree/master/proxmox

Caveat: The restore won't boot grub for some reason, so keep a copy of Super Grub Disc around and that should boot it. Once up and running you can login as root and ' grub-install /dev/blah '

BTW I believe I've fixed the problem with grub reinstall, latest script has been uploaded to github

 

[Kingneutron]

The other rabbit hole I'm looking down is a single disk OS install or RAID 1 with a complicated replacement process... Haven't decided on that one though.

For a homelab, you shouldn't need a mirror/RAID1 disk for the OS. Backup your root frequently, have a spare disk handy in case you need to restore/recreate. With proper backups and a TESTED DR procedure, you should be able to get back up and running in ~2 hours or less.

RAID1 for the OS is more for datacenters and prod-critical environments where they can't afford downtime.