22 June 2026
Four layers between your data and disaster
Application, files, replica, full VM: each layer covers a different risk. 30-second replication for critical systems, daily copy to a second data centre.
Ask any company director whether they have backups and the answer will be yes. The useful question is a different one: what exactly does that backup protect you from? A file deleted by mistake, a database that has to be put back to the state it was in at 14:30 yesterday, a server that dies on a Tuesday morning and a ransomware attack detected three days late are four different disasters. A single backup doesn’t cover all four.
That’s why our managed backups are not “a backup”: they are four stacked layers, and each one exists because it covers a risk the others don’t.
Layer 1: the application backs itself up. Nobody knows how to back up a database better than the engine that manages it. The first copy is generated by the application itself: SQL Server, for example, dumps its full, differential and transaction-log backups to a dedicated disk, following reference procedures such as Ola Hallengren’s. This is the copy that lets you go back to an exact logical point of a database. It recovers a piece of data.
Layer 2: files, with versions. With Backup for Workgroups we copy to an external server the files the applications have already generated — database dumps, web files, configurations, exports — and we keep previous versions. Someone deleted or overwrote a file? That file is recovered, without touching anything else. It recovers a file.
Layer 3: the replica. Every virtual machine that requires it has a live copy on another physical server, kept up to date with Hyper-V Replica. If the main server fails, the replica starts up and work continues. The replica is updated every 5 minutes at most — and on the most critical systems, every 30 seconds: that is what can be lost. It isn’t a historical archive — it’s continuity. It recovers the service.
Layer 4: the whole machine, with memory. With Hornetsecurity VM Backup we copy each virtual machine in its entirety from an external server and keep a history with GFS retention: daily backups for the last week, weekly for the last month and monthly going several months back. This layer answers the question the replica cannot: what if the problem has been inside for days? Ransomware that encrypts silently gets copied to the replica too; the history lets you go back to an earlier, clean point. It recovers the history.
And all of the above, on one condition: that it doesn’t live in a single building. Every day a copy is taken off-site to a second data centre, physically separate from the main one, where at least the last week of backups is kept. If the main data centre became unavailable — fire, flood, a serious electrical failure — the infrastructure would still exist somewhere else.
There remains the nuance that separates a backup from the feeling of having a backup: a backup is only worth anything if its restore has been tested. A job finishing “without errors” proves nothing. That’s why periodic verifications are run in which the virtual machine is mounted from the backup itself to confirm it is usable, and every morning the report of all the night’s jobs is reviewed.
This architecture isn’t theoretical. A printing and document-management company with two data centres of its own uses it in crossed mode: we installed a backup appliance — a server prepared and managed by us — at each site, and each one stores the other’s backups. A raw-materials wholesaler with its own data centre has one of our appliances on its premises: local backup for fast restores and daily off-site copying to our data centre — if its site went down entirely, we would bring its infrastructure up in our cloud. It’s the same principle we apply in hybrid cloud environments and, of course, to our own infrastructure: we are our own first client.
One last figure, demonstrable: the repositories where these backups land reach up to 9,111 MB/s write and 8,706 MB/s read in sequential tests with CrystalDiskMark, measured with the volumes at 72% and 77% full — not empty. It’s a measurement of the storage, not a promise of end-to-end backup speed; what it guarantees is that, when a restore is needed, the disk won’t be the bottleneck.
The diagram below sums it up. If, reading it, you can’t say which of the four layers your business has — or you suspect it only has one — that is exactly the conversation worth having.
A backup that has never been tested isn't a backup. It's a hope.
The service behind this piece
Managed backups →