Hi@all,
I’m looking for a solution to backup my vm’s. The kvm host is a ucs-backup 4.2.3 with uvmm. As backup target i have a nas.
It is possible to save the qcow2-files without vm-shutdown?
with best
sven
Hi@all,
I’m looking for a solution to backup my vm’s. The kvm host is a ucs-backup 4.2.3 with uvmm. As backup target i have a nas.
It is possible to save the qcow2-files without vm-shutdown?
with best
sven
Hi,
like other backup techniques one has to make sure that the data is in a consistent state, so it will be hard to backup the disk of a running vm.
The usual approach when a shutdown is not wanted is to freeze the vm and copy the disk-image. As the copy itself will also take some time it is best practise to make use of LVM-based snapshots. For this you need some unallocated space in the volumegroup where the logical volume containing the disk-images resides. The snapshot does not need much space on the disk as it only had to take care of the changes during the time you need to keep the snapshot. 10% is a good value for the unallocated space. But you need to destroy the LVM-snapshot after the copy is done.
There are most likely lots of scripts which can assist you for the backup. I am using virt-backup.pl (http://gitweb.firewall-services.com/?p=virt-backup;a=blob_plain;f=virt-backup;hb=HEAD) for some years on other KVM-systems and it looks like this has support for LVM-snapshots. There is a chance that it also works on UCS.
hth,
Dirk
My qcow2-file are stored in the default-path (/var/lib/libvirt/images) on the kvm-host. The /var him self is a seperate partition in a lv
--- Logical volume ---
LV Path /dev/vg01/kvm02_var
LV Name kvm02_var
VG Name vg01
LV UUID pEhCvf-hdN1-f2IM-GTuJ-dWhW-jlne-qiQce5
LV Write Access read/write
LV Creation host, time unassigned-hostname, 559220-10-08 14:17:36 +0200
LV Status available
# open 1
LV Size 1,91 TiB
Current LE 500562
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
/dev/mapper/vg01-kvm02_var on /var type ext4 (rw,relatime,data=ordered)
root@kvm02:/var/lib/libvirt/images# ls -lh
insgesamt 1,3T
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 239M Okt 22 23:18 clonezilla-live-2.5.6-22-amd64.iso
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 240M Okt 22 23:18 ipfire-2.21.x86_64-full-core124.iso
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 22G Nov 3 11:07 ipfire_disk1.qcow2
-rw-r--r-- 1 root root 302M Okt 22 23:07 KVM Windows drivers (virtio 1.1.141).iso
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 8,2G Nov 3 11:08 saturn_disk1.qcow2
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 212G Nov 3 11:08 saturn_disk2.qcow2
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 548M Okt 22 23:19 systemrescuecd-x86-5.3.1.iso
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 194G Nov 3 11:08 tux_disk1.qcow2
-rwxr-xr-x 1 root root 194G Okt 27 11:14 tux_disk1.qcow2.bak
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 313G Nov 3 10:55 tux_disk2.qcow2
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 306G Nov 3 10:43 tux_disk3.qcow2
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 1,2G Okt 23 00:23 UCS-Installation-amd64.iso
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 79G Nov 3 11:08 wints01_disk1.qcow2
i understand correctly that i am creating a snapshot of the /var lv?
Hey,
even though I’ve answered in another thread, that one was in German. I’ll repeat what I said there in English here for our international readers.
You must not copy storage files of virtualization solutions naively. There are two general issues with that strategy:
If you were to restore a storage file copied that way you’d end up with both file system corruption as well as data loss.
Therefore you need a solution for both issues. No, taking LVM snapshots of the filesystem that contains the storage files does not suffice.
There are several steps you must take in order to prepare the file for copying. These aren’t specific to Univention; they’re general steps applying to all KVM/libvirt
setups. I suggest you Google for something like libvirt backup qcow2 of running vms
.
One of the more interesting hits is the blog post KVM live & incremental VM backup with BORG. Borg is a pretty great backup program featuring things such as client-side encryption, block-based compression & deduplication, the latter of which makes it a great solution for storing huge files which are only change in few places efficiently.
That being said, I strongly advise to look into running backup software within the virtual machine and backing up the files from within the machine instead of backing up the whole storage file itself. The huge drawback of backing up storage files is that it’s impossible (or at least very hard and inconvenient) to restore files inside the VM.
Kind regards
mosu