Backup for virtual environments

When the customer's servers are virtual, the question changes. Instead of protecting the contents of each machine, you can take the whole machine — operating system, configuration and data in one go — and bring it back as a unit.

That sounds like a technical detail, but it decides what a restore feels like in practice. A file restore gives back data. A machine restore gives back a working server.

ARJ Distribution sells exclusively through resellers and MSPs in the Nordics — Sweden, Norway, Denmark, Finland and Iceland — never directly to end customers.

What hypervisor-level backup means

The backup connects to the virtualisation host instead of to each guest. The host takes a snapshot of the virtual machine, and the backup product reads it. No agent has to be installed inside every server, and nobody has to maintain one there either.

The restore is a machine, not a folder. An encrypted or broken server is replaced by itself, rather than reinstalled and then filled with restored data. That is where the hours are saved, and it only shows the day something actually went wrong.

New machines are picked up — if it is set up that way. VM Backup can configure newly discovered virtual machines automatically, but that feature only exists in the highest edition. On a lower edition every new virtual server has to be added by hand — and the most common reason a server has no backup is rarely that someone decided against it. It is that nobody remembered to add it.

Worth checking at every customer: how are the jobs scoped, and are new machines discovered by themselves or not? Ask us how it is configured in the product and the edition your customer runs.

When the hypervisor level is not enough: a database that has to be restored to a specific point in time, or where individual records need to be picked out, usually has to be handled as a database rather than as part of a machine image. Then the two levels are combined. It is one of the most common things we sort out with partners before a quote goes out.

Which product for which hypervisor

Two products in the range work at the hypervisor level. The first thing that decides the choice is not features but which hypervisor the customer actually runs.

Hypervisor	Hornetsecurity VM Backup	Xopero ONE
Microsoft Hyper-V	Yes	Yes
VMware vSphere and ESXi	Yes	Yes
Proxmox VE	Yes	No, not at the hypervisor level

Hornetsecurity VM Backup

Does one thing, and therefore a fair amount within it. But what the customer gets is decided by which edition they buy, and the differences are bigger than people expect. These are the choices that usually decide a deal:

Feature	Standard	Unlimited	Unlimited Plus
Sandbox restore and verification	Yes	Yes	Yes
File-level restore	Yes	Yes	Yes
Restore a machine to a different host	Yes	Yes	Yes
Clusters — Hyper-V CSV and VMware vCenter	—	Yes	Yes
Boot from the backup	—	Yes	Yes
Cross-platform restore	—	Yes	Yes
Exchange item-level restore	—	Yes	Yes
Encryption of the primary backup	offsite only	Yes	Yes
Cloud backup and immutable storage	—	—	Yes
Replication and continuous data protection	—	—	Yes
Automatic configuration of new machines	—	—	Yes
Control Panel for central management	—	—	Yes

The full list is in Hornetsecurity's edition comparison. Three rows deserve extra attention: clusters require at least Unlimited, which surprises a lot of people; immutable cloud storage requires Unlimited Plus, and that is precisely the feature that protects the backup against ransomware; and in Standard only the copy that leaves the network is encrypted, not the local one.

Storage is not included in the licence. The customer provides the space themselves — locally first of all, and beyond that an offsite server can be set up at no extra licence cost, or the copy can be placed as S3 storage with a cloud provider the customer chooses.

Xopero ONE

Does hypervisor backup as one of several workloads in the same console. Against VMware it works agentlessly and reads only changed blocks; individual files can be pulled out of a machine backup, and whole disks can be mounted. Against Hyper-V an agent is installed on the host — not in every guest — and both standalone hosts and clusters are supported.

Where the agentless route is not open — a free ESXi licence, or machines running at a public or private cloud provider — Xopero ONE can instead protect the virtual machine from the inside, with an agent in the guest operating system. The machine ends up protected, but in a different way than via the hypervisor. Which one fits depends on the environment, and that is something we help you work out.

So the choice is between a product specialised in the virtualisation and a console that covers clients, servers, databases and Microsoft 365 as well. If the customer runs Proxmox at the hypervisor level, the choice is already made.

If the machine runs a database, one more setting is needed

A snapshot of a virtual machine is fundamentally crash consistent — roughly like pulling the power in the middle of a transaction. For a file server that is rarely a problem. For a database it is the difference between a copy you can rely on and one you have to hope for.

Both products solve it with Microsoft VSS. The database is quiesced for a moment, writes out what is held in memory, and the copy becomes equivalent to a database that was shut down properly. Hornetsecurity calls it Application Consistent, Xopero calls it application-aware backup. The vendor names SQL Server, Exchange, SharePoint, Active Directory and Oracle as the workloads this applies to.

Three things still make it get missed in practice:

It is set per machine — in VM Backup under the VSS settings — and it is not on by default. No overview warns that it is missing on a database server.
The requirements differ between the hypervisors. Hyper-V handles the transaction logs by default, with no agent in the guest. VMware requires VM Backup VM Tools to be deployed to the guest and log truncation to show as installed. Proxmox VE requires qemu-guest-agent in the guest, and it is enabled via the hypervisor.
If the step fails, the backup continues anyway, in crash-consistent mode — and the job reports green. It shows only in the job history. A green job is therefore not the same thing as a copy the database can be started from.

And two cases fall outside entirely. MySQL is not VSS-aware, not even on Windows — the vendor states it outright. And VSS is a Windows technology, so a database running on Linux gets no application-aware snapshot from either product. In both cases a database dump from the inside is needed, however the machine itself is taken.

It is one of the most common gaps we find when we go through an existing environment at a customer: the machine is protected, but the database inside it is not protected in the way anyone assumed. The full walkthrough, with the conditions per database engine, is on the page about servers and databases.

The offsite server — revenue for the MSP

VM Backup has an offsite server of its own, which Hornetsecurity describes as a free tool for VM Backup users. You install it on a Windows Server in your own data centre — client versions of Windows are not supported — and your customers' VM Backup installations send their copies there over the network.

It is built for multi-tenant operation. Each customer gets an account of their own on the server, and one and the same offsite server can receive copies from several customers' installations. This is not a creative use of the product; it is the intended arrangement.

And the threshold is lower than people think: the offsite server works from Standard upwards, and an offsite copy over the internet is included in every edition. Even a customer on Standard can put their second copy in your data centre. One installation can have up to two offsite locations, and more than one requires at least Unlimited.

The customer gets their second copy outside their own network — which is the whole point when a ransomware attack reaches both production and the local backup — and you get a service to charge for instead of sending the customer off to a cloud provider. The data stays with someone the customer already has an agreement with. The offsite copy can also hold a longer history than the local backup, which is an argument of its own when the customer has requirements for how long data must be kept.

Four things we go through before an arrangement like that is set up

The storage has to sit in the same place as the server. The offsite server's own space cannot be in the cloud — it has to be disks you control, on NTFS or ReFS, or a network path over SMB 3.0.
The first copy can be shipped on a disk. Take a full backup locally at the customer, send the disk to you and read it in; after that only the changes go over the network. That is the difference between a week and an afternoon when the customer has a few terabytes.
Deduplication requires at least Unlimited. Shared blocks are written only once to the backup location — including when they occur in several different machines. If you hold the storage it is your own cost that shrinks, so the edition choice goes straight into the margin on the service.
Firewall and clocks. Traffic to the server has to be allowed through, and the clocks on both sides must not differ by more than five minutes.

Two routes to a running machine at your site

Both end up in the same place: the customer's server runs in your data centre while their own environment is down. What differs is how long it takes — and which edition is required.

Offsite copy and restore. Works in every edition. Backup data is copied between the two locations, and when something happens you restore the machine from the copy at your site. The result is the same, but with a delay — the machine has to be restored before it can be started. For many customers that is entirely sufficient, and it is the route that is open regardless of what the customer has bought.

True replication and CDP. Requires Unlimited Plus. Here a copy is kept restored at all times, and the backup can be taken considerably more often. The machine stands warm instead of having to be built up out of a copy, and the delay shrinks to almost nothing. Three things come with it: the versions have to match — Hyper-V 2019 against 2019, 2022 against 2022, and the equivalent for vSphere — VMware hosts are added via vCenter, and the server has to be able to run the machines. So if you have customers on different versions you need one server per version for replication, while the same server receives offsite copies from all of them.

And be sparing with the frequency. Replication is built on CDP, and the vendor advises setting tight intervals — 15 minutes or shorter — only on the machines that really need it. Everything else shows up in the virtualisation host's performance, and it is the customer's production that pays for it. One tip that saves both time and load: put the swap file on a virtual disk of its own and exclude it from the backup.

And what happens after that?

Anyone who needs to run a customer's servers at their own site has rarely just had half a day of bad luck. Had it been a broken disk or a failed update, the customer would have restored from their local copy the same day. Machines standing at your site usually means the premises are out, or that ransomware took both production and the local backup.

Then it is not a matter of hours. The customer has to acquire new hardware, build an environment and come to terms with their insurer — and in the meantime the business runs at your site. The move back to the customer's new environment is handled by the product; DRaaS is included in Unlimited Plus. How it gets planned is something we go through with you when the arrangement is set up.

And that is where the value of the service lies. You are not selling a button that switches back and forth. You are selling the customer's business continuing to work while they rebuild their own — for weeks if that is what it takes. That is a different conversation, and a different agreement, than a storage service.

So the question to the customer is not whether they want failover, but how long it may take. If the answer is hours, the offsite copy is enough, and you can offer that to any customer at all. If the answer is minutes, it is Unlimited Plus — and then you are selling continuity rather than disk space, which is a completely different agreement and a completely different price tag in both directions. Talk to us before you price either one; it is easy to calculate on raw disk volume and then discover that the edition gives neither the deduplication nor the replication the calculation assumed.

How the backup survives the attack

A ransomware attack goes after the backup too. That is not a theoretical risk but standard procedure — if the attacker finds the backup, there is no negotiating position left. Hornetsecurity has a walkthrough of its own on how VM Backup should be configured to withstand it, and four points from it belong in every installation:

The backup target should have credentials of its own. The vendor writes explicitly that a NAS should use dedicated accounts, not Active Directory accounts. If the domain falls, the backup otherwise goes with it — and that is precisely the order an attack tends to happen in.
Limit who can reach the storage. The network paths to the backup should only be reachable from the machine running the VM Backup console, not from the network at large.
Anti-virus on the targets that are not immutable. The vendor is clear that VM Backup cannot itself stop malicious code from reaching an ordinary backup location. Something else has to do that.
Immutable storage where it is available. Offsite copies can be set as immutable for a fixed period — but the feature requires Unlimited Plus. So it is an edition decision, not a setting you add afterwards.

The old method still works. Rotating disks that are unplugged and carried away give a physical break that no attacker reaches over the network. Every disk in the pool carries a full backup, so a single disk is enough to restore everything — it does not have to be read together with a chain of others. For a customer with no budget for immutable cloud storage it is a perfectly good alternative, and for a customer who has such storage it is one more layer.

The vendor itself calls the offsite copy the last resort once something has happened. That is also the argument for setting it up before something happens — and a concrete reason to go through the four points above at every existing customer, not only on new sales.

What usually goes wrong in an installation

The vendor's own best practice guide points out a number of things that go wrong in practice. Most of them cost nothing to get right from the start and a fair amount to discover later.

The encryption key cannot be recreated. Offsite copies must be encrypted, so the master key is needed the day the copy is to be used. There is no recovery route if it is lost — then the copy is unusable. The key belongs in the customer's password manager, documented, not in the head of whoever set it up.
The console cannot be installed on a domain controller. That is a hard limitation, not a recommendation.
One console per site. The hosts a console manages have to be on the same LAN. If the customer has several sites, one installation per site is needed, followed up from the Central Monitoring Console. Worth knowing before anyone has counted on a single console for the whole customer. The same console does, however, handle Hyper-V, VMware and Proxmox at once — a mixed environment does not require several products.
The backup should not sit on the same disk as production or the operating system, and the backup location should never pass 90 per cent full. Keep at least ten per cent free.
Turn off oplocks on a NAS. On Windows: Set-SmbServerConfiguration -EnableLeasing 0. It is a common cause of jobs that work erratically without anything else looking wrong.
Do not touch the files in the backup folder. Anything moved, changed or deleted there cannot be repaired afterwards.
Do not run snapshots against DFSR databases. That is Microsoft's own limitation — snapshots are not supported by DFSR or other Windows databases with several writing nodes.
Turn on email notifications. It is the difference between discovering a broken job the next morning and discovering it when the customer needs the backup.

The first point is the one we would most like you to check at existing customers. An offsite copy that cannot be unlocked is worse than no copy at all, because everyone believed the protection was there.

Restores that test themselves

A backup nobody has restored is an assumption, not a guarantee. The job reports green, the files are where they should be, and only the day someone needs the machine back does it turn out whether it will start. The vendor is blunt about why: storage breaks, and that is not unusual.

At the hypervisor level you can do something about it that is not possible with file backup: start the machine from the backup in an isolated environment, check that it boots and that the services come up, and shut it down again. Without touching production, and without anyone having to sit and watch. The restored machine has its network card switched off, so it cannot collide with the original on the network — the test is therefore safe to schedule.

Two levels are worth setting up: verification jobs that check that the backup on the storage is intact, and scheduled full restores that prove the machine actually starts. In VM Backup, sandbox restore and verification are included in every edition — so it is not something the customer has to upgrade for.

For an MSP it is also something to show. A report saying the machine actually started from last week's backup is a different conversation with the customer than a job showing green. It is also evidence when the customer has to demonstrate that the continuity plan has been tested and not just written down.

Proxmox — and what is still missing

Proxmox has taken a place in environments that used to be VMware without question, and the question comes up more and more often. Hornetsecurity VM Backup has had full support for Proxmox VE since November 2025, for versions 8.4, 9.0 and 9.1.

The support is newer than the one for Hyper-V and VMware, and there are gaps today that should be known before anyone promises anything:

Replication and continuous data protection are missing. The vendor states explicitly that replication is not supported for Proxmox today, and that it is coming later with no date. So the fast route above is closed on Proxmox — offsite copy with restore does work, so the service can be offered, just with the longer delay.
LXC containers are not covered — only virtual machines. If the customer runs containers on Proxmox they need another solution for them.
Boot from backup works only as verification, not as a way of running the machine on in production.
Disks passed through to the machine are not backed up, and individual disks cannot be excluded from a job.
A restore requires temporary space on the host equivalent to the largest disk in the machine.

None of that is decisive for most environments. But the first three points are worth checking with the customer before the agreement is signed, not afterwards.

Five questions to ask the customer

These five decide which product and which level fits, and we need the answers in order to price a deal:

Which hypervisor, and which version? Older versions fall outside support on both products — and with replication, the version governs what you need standing at your own site.
How many hosts, how many sites, and are they clustered? Clusters require a higher edition, and every site needs a console of its own. Both are easily missed in a calculation.
How long may it take before the server is back? Hours or minutes — that answer decides whether the offsite copy is enough or whether Unlimited Plus is needed.
Which account reaches the backup storage? If it is a domain account, the backup is part of the same attack surface as everything else.
What happens if the whole premises disappear? Fire, water damage or an attack that takes both production and the local backup — that is when the second copy has to carry, and when it needs to be somewhere other than in the same building.

Why through a distributor

We do not sell to end customers. That is not a courtesy, it is the business model: everything goes through you, and we never compete with you at the customer.

What you get beyond the licences: technical pre-sales help before the deal, help in a proof of concept, support in Swedish and English, and a named contact who knows your business instead of a ticket number. The licence models differ between the two products — tell us what the environment looks like and we will work through the numbers together with you.

Get started

Tell us which hypervisor the customer runs and how quickly a server has to be back, and we will tell you which of the products fits and what it costs.