Ideally, keep your /etc/libvirt/qemu (where the XML definitions for VM hardware are stored) on a ZFS dataset that you can replicate as well that way you can boot up directly using the original definitions. Just installed some new app that does some crazy thing and stored its data someplace you didn't expect? Doesn't matter you're replicating the VM as a whole.Īs a bonus, if your backup target is machine enough for the job, you can test your backups by literally booting them up on the backup box itself.
Worth noting: part of the reason I'm so on about this image-based stuff is that you literally can't have accidentally forgotten something you needed you're backing up the ENTIRE virtual machine's storage as a crash-consistent image. Your VM host should have 8GB for storage + whatever your VMs need. A backup target should have 8GB of RAM (although if you're a cowboy and don't mind getting out and kicking it every now and then, you can get away with considerably less - I've used 2GB machines before basically you just end up having to forcibly power-cycle the machine every now and then if it locks up). The catch, of course, is that no you can't use your existing cheap NAS to do it you need a real machine on both ends (and you need to be using ZFS for the storage on your source in the first place). You can either go whole-hog and use Nagios and NRPE to do it right, or you can just cowboy up something that involves checking the output yourself - it exits 0,1, or 2 for OK, Warn, or Crit as well as the text output. That's the CLI output of a Nagios plugin. OK: all monitored datasets (backup/images) have fresh sanoid -monitor-health
0 kommentar(er)
