Hello all,
I'm looking for a way to backup my KVM guests that are hosted on 3 KVM hosts within my environment. I recently had a blunder and had to rebuild all my virtual servers (more time consuming than difficult). I currently have a SAN set up via iSCSI (hardware RAID 5 with LVM running on top of the RAID) using targetcli to the KVM guests. I have the LUNs mapped to my hosts as block storage and have provisioned the guests on the iSCSI block devices. I've Googled a bunch but it seems that everything I have found seems to be geared toward a single host running an LVM configuration and not with storage running off a SAN. I would appreciate any direction anyone could give me. Thanks!
[SOLVED] KVM guest backups
[SOLVED] KVM guest backups
Last edited by phoenix83 on 2018/08/13 22:34:19, edited 1 time in total.
-
- Posts: 2019
- Joined: 2015/02/17 15:14:33
- Location: Bulgaria
- Contact:
Re: KVM guest backups
You might consider creating external disk snapshots (for DBs you need also --quiesce) , backup the read-only disk and then perform blockcommit (merge snapshot with new data).
You might need the 'qemu-kvm-ev' package and it's dependencies (in RHEL 7 it's qemu-kvm-rhev)
And backup of the actual VMs configuration!
Here is a nice tutorial.
You might need the 'qemu-kvm-ev' package and it's dependencies (in RHEL 7 it's qemu-kvm-rhev)
And backup of the actual VMs configuration!
Here is a nice tutorial.
Re: KVM guest backups
Than you hunter86_bg! I'll check this out in the morning and report my results. It looks pretty straightforward.
Re: KVM guest backups
So I've attempted to perform the live snapshot but I keep getting this error:
I did install the qemu-kvm-ev packages and rebooted the VM but I still get the above error. The VM I'm using as a test is pfSense version 2.4.3 (FreeBSD 11.2). Could the OS be an issue?
Code: Select all
virsh -c qemu:///system snapshot-create-as --domain FW --name Lab_FW --diskspec vda,file=/home/rodgort/Lab_FW.qcow2 --disk-only --atomic --live
error: Operation not supported: live snapshot creation is supported only with external checkpoints
-
- Posts: 2019
- Joined: 2015/02/17 15:14:33
- Location: Bulgaria
- Contact:
Re: KVM guest backups
Remove the '--live' option. It's only used for checkpoints (snapshots of memory and disk).
Also consider setting proper SELINUX contexts on the home dir, as SELINUX won't allow you to create snapshots there (if this command was run from a systemd service or cron job -> root user is not restricted from SELINUX perspective, but cron is).
Also consider setting proper SELINUX contexts on the home dir, as SELINUX won't allow you to create snapshots there (if this command was run from a systemd service or cron job -> root user is not restricted from SELINUX perspective, but cron is).
RE: [SOLVED]KVM guest backups
That did it! It's working perfectly. Though with the VM I tested, the .qcow2 file was only listed at a few MB (5.3 to be exact). Is that since it's a snapshot versus a full disk copy? I am going to test the restoration as well to make sure we have full solution but I'll still mark this as solved.hunter86_bg wrote: ↑2018/08/13 03:46:58Remove the '--live' option. It's only used for checkpoints (snapshots of memory and disk).
Also consider setting proper SELINUX contexts on the home dir, as SELINUX won't allow you to create snapshots there (if this command was run from a systemd service or cron job -> root user is not restricted from SELINUX perspective, but cron is).
Thank you for all your help
-
- Posts: 2019
- Joined: 2015/02/17 15:14:33
- Location: Bulgaria
- Contact:
Re: [SOLVED] KVM guest backups
The snapshot is just containing the deltas (anything changed) and as best practice you shouldn't keep it very long.
In your case, you should copy the base disk , as it is a read-only file untill you block commit (a.k.a. merge).
Also there is an extra option ( '--no-metadata' ) which you can use , so you won't have to delete the snapshot at later point.
As far as I remember, there are 2 types of commits :
1.Base disk to snapshot (a lot of delta happened and the snapshot is very large)
2.Snapshot to base (when snapshot is smaller)
You can use them not only to merge base disk with snapshot, but also snapshot with another snapshot.When you have chain of disks ( for example multiple snapshots ) , the performance of the VM drops.
As I don't remember the option names, you can check the wiki for them.
In your case, you should copy the base disk , as it is a read-only file untill you block commit (a.k.a. merge).
Also there is an extra option ( '--no-metadata' ) which you can use , so you won't have to delete the snapshot at later point.
As far as I remember, there are 2 types of commits :
1.Base disk to snapshot (a lot of delta happened and the snapshot is very large)
2.Snapshot to base (when snapshot is smaller)
You can use them not only to merge base disk with snapshot, but also snapshot with another snapshot.When you have chain of disks ( for example multiple snapshots ) , the performance of the VM drops.
As I don't remember the option names, you can check the wiki for them.