What is the - right - approach from an Urbackup standpoint, in backing up Virtual Machines, and what is the default approach from Urbackup, when it runs backups for virtualized environments. We are running SLES12 VMHOST, hosting 4 Virtualized servers (KVM/QEMU with QCOW2. Our Urbackupserver i running on Win Server 2012R2, version 2.1.15 beta.
I have searched forum on this topic, but haven´t found any - so if this is an ongoing discussion, please direct me to that thread.
Problems with this is, it’s open to interpretation and everyone handles things differently.
Some would say run the file and image backups of the VMs, other say just the file backups, other say just the image backups because they can pull what they want from the image files.
My opinion - given that I am assuming you do not use the host machine for anything other than running VMs - run an image capture of the entire machine, and run file backups of only where you store your VMs. Then run file backups on the VMs you need.
Technically speaking, if a VM ever went down then - you have a fully loaded backup of EVERYTHING about that VM that you could import.
Then again, this is just a suggested approach - and there could be one better.
Hi ttrammell.
Thanks for your input - much appreciated, and much in line with my own thoughts on this.
When you say “run an image capture of the…” you mean?
The VM host (only used for hosting VM´s -) are based on SLE 12SP2 - with only the /-partition, based on xfs. In hindsight, it might have been more feasible to have partioned otherwise, but I didn´t want Btrfs (had my issues here in the past), and LVM din´t seem necessary at that time.
What is your take on that - I can see it would be nicer to have a small root-partition, and then based the location of VM´s in a separate partition, which I could have configured in file-backups of VM´s.
Sorry, I meant of the box (the one hosting the VMs) itself; however, since it is running Linux the image backup will not work anyways.
I would agree that having it on something other than just the root partition would be a great thing, but if it’s now a point where changing it is more trouble than it is worth then I would say stick with it - at least for now, unless you absolutely want to change it.
Did you try dattobd driver? That would possibly solve issue with backing up VHD (or whatever image files you are using) images on host. Not sure if you would need to stop VMs via pre/post scripts, when I was testing this I noticed that you can copy them and they will boot up but I’m not sure what state would databases and such be in.
Well - I don´t think just taking normal filebackup of the VM server is the right approach. Backups are fine, but apparently Urbackup recognizes the size of the VM-disk as nominal value contrary to the real (used) value, meaning it consumes way too much space than needed. One of my VM´s is moved from a Windows Server, and has a virtuel disk attached with a 120GB volume - (because it was created from a physical machine) - but the real used space in the virtual disk is only around 50 GB - but it consumes 120 GB of my backupspace.
The total size of a full backup of the VM-Server is 290 GB - while the actual use (df -h) is 12 G, so …I think I´ll just have to exclude the subdirectory which holds the VM-disk images, and find another way of storing those by rsync to another physical server.
That can’t be right or I misunderstood you - if you are on VM Host and try to copy VMs (the vhd files) those files are supposed to be real size ( 100GB VM will NOT have a 100GB file if it’s not used those 100GBs) (unless you used static, not dynamic, disks, those are fixed size)
Now, if you are talking about backup from the inside - yes and then UrBackup should have some compression built in for cases like that. Ideally it should copy only the blocks that are used, you are 100% sure that’s not the case?
And I was talking about taking backups on Host, not on VMs themselves. Also, dattobd IS supported, it’s just that you have to install it manually Only works on x86_64 systems though.