How to backup Oracle VM and Oracle Linux Virtualization Manager environments

For Oracle customers there are 2 main virtualization platforms available – already known Oracle VM and brand new Oracle Linux Virtualization Manager

OVM or OLVM – what’s the difference

These are 2 completely different platforms. This means that in the past (Oracle VM) it was Xen-based hypervisor underneath, and now it is going to be KVM, as the Oracle Linux Virtualization Manager is oVirt based platform, which uses KVM as the hypervisor. This obviously also impacts possible options how to protect these environments. Oracle VM still has primary way of doing backups using export storage repository.

However, for Oracle Linux VM we have 3 more strategies, so let me present all 4 of them here. If you like it, you can always try Storware Backup and Recovery for FREE.

Please note that since 2022 Storware vProtect is Storware Backup and Recovery. Before we start, take a look at the new functionality for OLVM – Instant Recovery with Live Migration:

Backup strategy 1 – export storage repository/domain (OVM/OLVM)

For Oracle VM, common approach is to use export storage repository. This repository is actually your solutions staging space which is the target for the data export. Backup itself is done by OVM and your solution collects data and pushes it further.

OVM requires additional clone on the local repository which later can be exported. Hot-clone features allows the VM to be online while being cloned. Then VM can be moved to the target repository.

Similarly the situation can look in OLVM. That is because OLVM is based on oVirt 4.2, it also has v3 API available. Once the snapshot was created you had to clone the VM and later export it.

Why do we need additional clone? The reason was that oVirt/RHV doesn’t allow you to export snapshot directly. Advantage was that the backup process itself was done by the hypervisor, so even with some average scripting skills, you could have snapshot-based backup.

There were however several drawbacks. First – additional cloning, which requires additional storage space and time for backup. Secondly – active export storage domain (OLVM) could only be one in each datacenter, which sometimes was not flexible. Finally, you cloned and exported whole VM, even if you didn’t want specific drives to be exported. Remember also that this approach probably is going to be deprecated in OLVM in the future.

Backup strategy 2 – disk attachment with Proxy VM (OLVM)

In this strategy you have a VM – let’s call it “Proxy VM” that asks your manager to snapshot and attach drives of a specific VM. Now your proxy VM is able to see and dump all of the data from the VM that you want to backup.

What is cool is that you don’t need export storage domain, and you can easily exclude drives which you don’t need. From the setup point of view – you need to install 1 Proxy VM per cluster, so that your backup solution it is able to attach drives. It is also nice starting point for future CBT support (no – in oVirt it not there yet).

Drawbacks… Well, for starters – unlike export storage domain, which uses simple commands/API calls such as snapshot + clone + export – you probably won’t script this at home. This time the backup/restore process actually requires you to think of many aspects such as metadata handling and the disk attachment process itself and overall API handling (which in oVirt/RHV case – may be tricky). This is why you would need a proper backup solution, where somebody has done this part for you.

Backup strategy 3 – disk image transfer API (OLVM)

Now this one is new – it appeared in oVirt/RHV 4.2 – which is also the current version of Oracle Linux Virtualization Manager. Basic idea is to have easy way to export individual snapshots from the RHV manager. So now, instead of having to install multiple Proxy VMs, you can have single external backup solution installation, which just invokes APIs via RHV manager.

Advantages – easier setup – assuming you have OLVM 4.2 – it is sort of plug-to-your-manager-and-play. From network point of view it just requires to additional ports to opened 54322 and 54323 and your data be pulled from hypervisor, and finally you have option to export just changed data.

Unfortunately, there are few problems with current architecture of this solution. The biggest issue is that all traffic passes via the virtualiztion manager, wich impacts latency and transfer rates that you can achieve during the backup process. To put that into perspective – in disk attachment you can basically read data as if it is local drive, where it could potentially be deduplicated even before transferring it to the backup destination. This also impacts scalability, as the bottleneck, sooner or later, will you your manager.

Backup strategy 4 – SSH transfer (OLVM)

To solve the bottleneck problem there is also yet another strategy. Instead of transferring the data over the manager API you can transfer data directly from the hypervisor. The difference is that data is being transfer over SSH when the VM is exported. Restore process still needs to be done via the manager (as it needs to be aware of disks being created).

This basically solves the problem of efficient backup (including incremental) of Oracle Linux Virtualization Manger. You don’t have to install anything on the hypervisor or the cluster and even single data mover can simultaneously transfer data from multiple hypervisors (to have fastest transfers possible).

The only potential drawback is SSH access that is required, but there must always be some tradeoffs.

Wrap up

In the past one had to decide which strategy to choose. But now SSH transfer offers most of the flexibility and efficiency without the need to install anything on the hypervisor. In the previous Oracle virtualization platform, backup options were quite limited. However now, with brand new OLVM release, you can easily setup agent-less backup protection. Learn more about Storware Backup and Recovery.