Last time I looked in January this year, there was nothing appealing. So I scripted away myself. Not for the faint of heart, 900 lines bash script, a handful of helper scripts, maybe 3-4 weeks debugging and exploring, soldering (not kidding).
Step 1 I basically tar up the host filesystems root+boot but without postgresql files and also not any VM qcow2 images and some other stuff.
Step 2 Snapshot VMs sequentially and atomically and copy off all virtual disks to backup place (in my case from SSD to a HDD RAID5). Commit snapshot before going to the next VM. Running VMs are undisturbed by the backup and operate without any downtime.
Step 3 Copy powered off VMs as they are, no snapshot like in step 2 necessary. In step 2 and 3 I will export through libvirt a XML definition file for each VM to aid in restoration should that become necessary.
Step 4 Backup of local postgresql using pg_basebackup and a checkpoint.
Step 5 Archive step 1-4 data using borg backup with zstd level 3 compression. Right now I have 1.83 TB of raw data compressed and deduplicated down to 174 GB. Borg keeps 25 archives right now with 7 daily, 4 weekly, 12 monthly and 5 yearly max. Integrity check of the archive is run every 30 days.
Step 6 Mail me any warnings or worse if they happened, including the current runs full log. Package maintainers on Arch Linux have a habit of breaking random packages.
Step 7 I have bareos tape backup (a bacula clone) running daily with quarterly fulls going to a LTO6 and incrementals going to a LTO5 drive. Since the drives are in my office I modded them using 2.5mm stereo plugs to connect the on-switch of the device potential free with a USB relais box. Reason: Noise. You can't power them on using a mains switch, those drives WANT their button pushed to actually turn on... bummer. So before every tape run a script will execute that turns on the correct drive, waits for it to boot up, loads a tape if present. After each run the tape is ejected and after some cooling off period the drive is turned off again.
Pretty much a boatload of trouble to get everything going. I think something like Xen Orchestra might be better than this kind of KVM bare metal work. Professionally I would just buy Veeam and VMware to do all this, but I wanted to see how far open source does reach in 2018. Quite far, but you need to be a Linux hacker to pull it off. Haven't published anything due to lack of time and out of fear of needing to support this afterwards, sorry.