Hi Niki, I'm using a similar approach like Stephen's, but with a kink.
* Kickstart all machines from a couple of ISOs, depending on the requirements (the Kickstart process is controlled by Ansible) * Machines that have persistent data (which make up about 50% in average) have at least two virtual disk devices: The one for the OS (which gets overwritten by Kickstart when a machine is re-created), and another one for persistent data (which Kickstart doesn't touch) * Ansible sets up everything on the base server Kickstart provides, starting from basic OS hardening, authentication and ending with monitoring and backup of the data volume * Backup is done via Bareos to a redundant storage server That way I can reinitialise a VM at any time without having to care for the persistent data in most cases. If persistent data need to be restored as well, Bareos can handle that as soon as the machine has been set up via Ansible. OS files are never backed up at all. An improvement I'm planning to look into is moving from Kickstart to Terraform for the provisioning of the base machines. Currently it takes me about 10 minutes to recreate a broken VM provided the persistent data is left intact. Cheers, Peter. > On 31. Mar 2021, at 14:41, Nicolas Kovacs <i...@microlinux.fr> wrote: > > Hi, > > Up until recently I've hosted all my stuff (web & mail) on a handful of bare > metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI, > Roundcube) as well as mail and a few other things were hosted mostly on one > big > machine. > > Backups for this setup were done using Rsnapshot, a nifty utility that > combines > Rsync over SSH and hard links to make incremental backups. > > This approach has become problematic, for several reasons. First, web > applications have increasingly specific and sometimes mutually exclusive > requirements. And second, last month I had a server crash, and even though I > had backups for everything, this meant quite some offline time. > > So I've opted to go for KVM-based solutions, with everything split up over a > series of KVM guests. I wrapped my head around KVM, played around with it (a > lot) and now I'm more or less ready to go. > > One detail is nagging me though: backups. > > Let's say I have one VM that handles only DNS (base installation + BIND) and > one other VM that handles mail (base installation + Postfix + Dovecot). > > Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images. > > With the old "bare metal" approach I could perform remote backups using Rsync, > so only the difference between two backups would get transferred over the > network. Now with KVM images it looks like every day I have to transfer the > whole image again. As soon as some images have lots of data on them (say, 100 > GB for a small OwnCloud server), this quickly becomes unmanageable. > > I googled around quite some time for "KVM backup best practices" and was a bit > puzzled to find many folks asking the same question and no real answer, at > least not without having to jump through burning loops. > > Any suggestions ? > > Niki > > -- > Microlinux - Solutions informatiques durables > 7, place de l'église - 30730 Montpezat > Site : https://www.microlinux.fr > Blog : https://blog.microlinux.fr > Mail : i...@microlinux.fr > Tél. : 04 66 63 10 32 > Mob. : 06 51 80 12 12 > _______________________________________________ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
