[CentOS] KVM vs. incremental remote backups

Wed Mar 31 13:10:31 UTC 2021
Stephen John Smoogen <smooge at gmail.com>

On Wed, 31 Mar 2021 at 08:41, Nicolas Kovacs <info at 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 ?
>
>
For Fedora Infrastructure we use a three prong approach
1. Kickstarts for the basic system
2. Ansible for the deployment and 'general configuration management'
3. rdiff-backup of things which ansible would not be able to bring back.

So most of our infrastructure is KVM only and the only systems we have to
kickstart by 'hand' are the bare metal. The guests are then fired off with
an ansible playbook which uses libvirt to fire up the initial guest and
kickstart from known data. Then the playbook continues and builds out the
system for the rest of the deployment. [Our guests are also usually lvm
partitions so we can use LVM tools to snapshot the system in different
ways.]

After it is done there are usually scripts which do things like do ascii
dumps of databases and such.

As you pointed out this isn't the only way to do so. Other sites have a
master qemu image for all their guests on a machine and clone that instead
of doing kickstarts for each. They also do snapshots of the images via lvm
or some other tool in order to make backups that way.

hope this helps.



> Niki
>
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : info at microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.