subscription service
Backup and recovery
A backup nobody has tried to restore is an assumption, not a safeguard. We design backup following the 3-2-1 rule and regularly check that it can actually bring you back.
Why this isn’t as obvious as it sounds
Almost every company has a backup. Far fewer companies know exactly what that backup covers and whether a whole system can be restored from it - not just a single file.
The difference only shows up during an incident. A ransomware scenario with three encrypted servers plays out differently in a company with an inventory and a tested backup than in one without:
| without a tested backup | with a tested backup | |
|---|---|---|
| what got encrypted | has to be worked out | known immediately |
| whether the backup covered everything | unknown | verified against documentation |
| recovery time | weeks, because the knowledge has to be rebuilt first | hours to days |
| report to the authority | a rough guess | precise |
Backup doesn’t prevent an attack. It decides whether you come out of it in days or in weeks.
What the service covers
- server backups - configuration, execution and oversight
- database backups - MSSQL, MySQL, PostgreSQL, Firebird, SQLite
- off-site copy to the Dragonfly cloud, optionally
- Microsoft 365 backup with Cube Backup
- data recovery from backup, with periodic testing
- tools: Proxmox Backup Server, UrBackup commercial edition with the CBS agent, and native database mechanisms
What we check first
We start with a question that sounds trivial: when did you last restore data from a backup? If the answer is “never” or “can’t remember”, that’s the first thing to fix - before any change to the configuration.
What a restore test looks like
It’s not about opening a single file. We check whether a working system can actually be stood up from the backup: a virtual machine boots in a separate environment, a database comes up and passes a consistency check, and an application connects to it without manual tinkering with the configuration.
That test also produces a second number that usually nobody knows: how many hours a recovery actually takes. A company that assumes “well, a day” and measures for the first time during an outage is almost always wrong, because on top of copying the data you have to add configuration, updates and testing before letting users back in.
Knowing that number, you can make a sensible decision: accept it or pay to shorten it. Without knowing it, you’re not deciding - you’re just hoping.
Frequency is matched to what you can afford to lose
The question isn’t “how often should we back up”, but “how many hours of work can the company lose without serious consequences”. For an accounting firm at the peak of the season that might be an hour. For a project-based company with long cycles - a day. Frequency and technology follow from that answer, not from a tool’s default settings.
Then there’s retention. Ransomware can lie dormant for weeks, so yesterday’s backup may already be encrypted or compromised. We keep older restore points precisely for that scenario, not to use up space.
Who this works for
Any company where data loss means downtime - which in practice is almost every company with an ERP system, a client database or project documentation. Especially companies covered by GDPR or NIS2, where the ability to restore data is part of the required technical measures, not just good practice.
Frequently asked questions about backup
What is the 3-2-1 rule?
Three copies of the data, on two different media, one of them off-site. The logic is simple: a disk failure, a server room fire and ransomware are three different threats, and one copy in the same building only protects against the first of them.
How often do you check that a backup actually works?
Regularly, as part of the plan, and that matters more than how often the backup itself runs. A backup that runs daily but has never been restored gives a false sense of safety - the problem surfaces exactly when there’s the least time to deal with it.
Is an offline copy really necessary?
For ransomware, yes. Encrypting malware also searches for network shares and backups reachable from the infected machine. A copy disconnected from the network is what’s left once everything else has been encrypted.
What about Microsoft 365 - isn't that already protected?
Microsoft protects its own infrastructure, but doesn’t protect against a user deleting data or against files in OneDrive being encrypted. We run the backup of 365 content separately, with Cube Backup.
