Server and database backup

A server can be protected in two ways: from the outside, through the virtualisation host, or from the inside, with an agent in the operating system. The choice is not a matter of taste — it is decided by what runs in the machine.

For a file server, host level is usually enough. For a database it rarely is — and that is where most of the misunderstandings start, usually on the day somebody needs data back.

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

A machine image gives the server back. It does not necessarily give the database back in the state the customer assumed.

From the inside or the outside — and when

If the server runs as a virtual machine on a hypervisor, the whole machine can be taken from the outside without installing anything in it. That is the efficient route for most servers, and it is described on the page about backup for virtual environments.

Three situations call for an agent inside the server instead:

• Physical servers. There is no host to connect to. The protection has to sit in the machine.
• Virtual machines where the agentless route is not open. A free ESXi licence, or machines running at a public or private cloud provider — there the machine is protected from the inside instead.
• Databases that need to be handled as databases. A machine image gives the whole server back, and with application-consistent backup the database in it is in a clean state too. But if a single database has to be restored on its own, or loaded onto another server, you need a real database dump.

In practice the levels are often combined. The whole machine is taken at host level so it can be started again, and the database is taken separately so it can be handled on its own. That is not duplicated work but two different kinds of recovery — and it is one of the most common things we sort out with partners before a quote goes out.

Physical servers

They are still around at more customers than people think — often precisely the machines nobody has dared touch. Two routes in the range, with very different levels of ambition.

Xopero ONE

Server Agent protects Windows Server from 2008 R2 and up as well as Linux — Alpine, Debian, Ubuntu, Fedora, CentOS, RHEL, openSUSE and SLES. Backup at file level, at image level, and bare metal recovery to new hardware. The same agent handles the databases further down this page, and the same console covers endpoints, NAS and Microsoft 365.

Hornetsecurity Physical Server Backup

A deliberately narrow product for physical Windows servers. It is application-aware through VSS, reads only changed blocks and deduplicates inline, and writes to local disk, removable disk or a network path.

Recovery only goes to Hyper-V — as a VHDX disk or as a virtual machine on a Hyper-V host. The vendor itself calls it a P2V solution. No VMware, no hypervisor hosts, no client operating systems and no Microsoft 365.

What matters for you is that it comes in two forms.

The free version

Free of charge for end customers, and worth knowing about — but know the conditions too:

• No official support. The vendor's community forum only.
• A licence key is required within 30 days, or the installation stops working. The key is obtained through a form at the vendor.
• Each machine is managed on its own.

Licensed through an MSP

This is the one we would rather talk to you about, because it changes both the maths and the operation.

It is licensed per server, at the same cost as a virtual machine. A physical server therefore counts just like the rest of the estate when you price a contract — no separate line, no separate calculation.

And the licensed servers are managed in VM Backup, in the same console as the virtual machines. The physical server becomes one machine among the others in the overview, with the same jobs, the same reports and the same follow-up — instead of a forgotten box in a server room that nobody checks until it is needed. That is the difference between something you deliver as a service and something the customer installed once themselves.

That is why it is worth a conversation: the customer gets protection that did not exist, at a cost that already fits the model, and you get the last machines into the same monitoring as everything else. And on the day they are virtualised, both the tooling and the conversation are already in place.

When the database sits in a virtual machine

Most database servers are virtual, and then the machine is usually taken at hypervisor level. That works for databases too — but only if one setting is right.

Both products can take application-aware copies, and both build on Microsoft VSS: the database is quiesced for a moment and writes out what is held in memory, so the copy is equivalent to a database that was shut down properly. Without it the copy is crash consistent — roughly like pulling the power in the middle of a transaction.

Hornetsecurity VM Backup

Calls it Application Consistent and sets it per machine, under the VSS settings. The vendor names SQL Server, Exchange, SharePoint, Active Directory and Oracle as VSS-aware. The requirements differ between hypervisors:

• Hyper-V handles the transaction logs by default, with no agent in the guest. Just switch the option on for the machine.
• VMware requires VM Backup VM Tools to be deployed to the guest, and Truncate Logs to be enabled and showing as installed.
• Proxmox VE requires qemu-guest-agent in the guest, and the option itself is enabled through the hypervisor.

Xopero ONE

Calls it application-aware backup. For Hyper-V it applies to Windows Server machines, and the vendor describes how VSS quiesces the applications and holds back writes for up to 60 seconds while the snapshot is taken. On endpoints and servers, VSS is enabled under the advanced settings in the backup plan, with the vendor's own warning: without VSS, backup data may be inconsistent.

One choice to be aware of: both products can let the backup continue if the application-aware step fails. That is practical — you rarely want the whole job to fail — but the result is then a copy without that consistency, and it only shows in the report. A green job is therefore not the same thing as an application-consistent copy.

Two exceptions that decide the design

VSS is a Windows technology. A database running on Linux — PostgreSQL, MySQL or Oracle — therefore gets no application-aware snapshot from either product. There the dump from the inside is not an option but the route.

And MySQL is not VSS-aware even on Windows. Hornetsecurity states outright that application-consistent backup is therefore not available for it. A MySQL database needs a dump from the inside regardless of operating system and regardless of how the machine itself is taken. It is one of the most common gaps we find when going through an existing environment — the machine is protected, but the database in it is not protected the way anyone assumed.

Databases from the inside — how Xopero ONE works

If the database is needed as a unit of its own — to be loaded onto another server, because it runs on Linux, or because the machine is not taken at hypervisor level — the backup is done from the inside. There is a misunderstanding here worth clearing up early: Xopero ONE does not read the database directly. A pre-script asks the database itself to create a dump with its own tool, and the dump file is then backed up like any other file.

The approach is the same for all four engines, but the conditions differ:

What actually happens during a restore

The question "can the backup write straight back into the database?" comes up almost every time. It is a reasonable question, but the answer matters less than people think — because that is rarely how a restore happens in reality.

If the whole database is gone, you load the whole copy. That is the simple case, and the dump file does exactly what it should.

But the common incident is a different one. Something has changed or disappeared, and nobody is quite sure what. You do not want to overwrite the whole database with an old copy — you want to see what it looked like before. The way to work is to load the copy alongside, compare using your own database tools, and then move back just what needs to go back. That last step is done in the database tool, not in the backup software — whatever backup product the customer has.

So a dump file is rarely a worse starting point. It can be loaded onto another server without touching production, which is exactly what you need when you are investigating. What belongs in an RTO calculation is that loading takes time — not that the method is inferior.

What is worth asking the customer is how much may be lost if the whole database has to be restored. The vendor's documentation does not mention transaction logs, binlog or WAL for any of the engines, so plan on the latest dump being what you have. For most systems that is reasonable. For a business system where every order counts, it is a question we take to the vendor before anything is promised.

Four ways to end up with a backup that has no database in it

All four produce a job that reports green. That is exactly why they are worth knowing.

• Application-aware backup was never switched on — or failed silently. This applies to virtual machines. It is checked per machine, and the report is the only place a failed VSS step shows.
• The dump directory is not in the selection. The script writes the dump to a directory, and that directory also has to be selected as data to protect. Miss it and the backup runs every night without the database ever coming along.
• The script is not allowed to fail the job. There are two settings: wait until the script finishes, and fail the job if the script fails. Without them the dump can fail silently while the backup reports success — and then yesterday's dump is backed up over and over.
• The prerequisites were never right. Oracle on Windows does not work. Oracle without ARCHIVELOG does not work. Microsoft SQL with Windows authentication only does not work. Quick to check in advance and expensive to discover afterwards.

For all four engines the vendor also recommends a dedicated database account for the backup — the same principle that applies to backup storage: the protection should not fall because some other permission does.

Five questions to ask the customer

These decide what can be promised, and we need the answers to price a deal:

1. Physical or virtual servers? If they are virtual the discussion starts at hypervisor level — and then the first check is whether application-aware backup is enabled for the database machines.
2. Which database engines, which versions, and on which operating system? Linux means a dump from the inside. Oracle on Windows is out immediately, Oracle before 19c likewise, and MySQL needs a dump regardless.
3. When did you last need something out of a database backup — and what was it? The answer is almost always "something that changed", not "the whole database". That shapes the design more than any feature list does.
4. How much may be lost if the whole database has to be restored? If the answer is "nothing", that is the start of a conversation with us, not the end of one.
5. Which account runs the backup? A dedicated account — not a domain administrator, and not the same account everything else uses.

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 your customer.

What you get besides the licences: technical pre-sales help, support during a proof of concept, support in English and Swedish, and a named contact who knows your business instead of a ticket number. Databases are also the area where we most often get questions that need an answer from the vendor — we take those on for you.

Getting started

Tell us which servers and database engines the customer runs and how much may be lost, and we will tell you what can be solved with the products today and what needs to be checked first.

Read more

• Backup for virtual environments — Hyper-V, VMware and Proxmox
• Backup — overview of all workloads

or book a short technical call

About the content on this page. This is a sales-oriented overview — not complete product documentation. The information is checked against the vendors' own documentation in October 2026 and we review it regularly, but features, system requirements and version support change — and a change can get past us. So always check against the vendor's current documentation before anything is promised to a customer: Hornetsecurity's knowledge base and Xopero's help centre for Xopero ONE. That applies in particular to the database engines' versions and conditions, which change more often than the rest. If you are unsure, it is faster to ask us — we take the question to the vendor and come back with an answer you can put in a quote. And if something does not work the way it is described — here or in the vendor's documentation — tell us. We report it to the vendor and correct the page.