Backup, Disaster Recovery and Business Continuity

We design and test backup and recovery, because a backup nobody has restored from is only an assumption.

Almost every company takes backups. Far fewer know how long a full restore takes, and some find out at the worst possible moment that it does not work. The files were copied, but the database was copied while writing and comes back inconsistent. The backups existed, but lived on the storage array that failed. Or they were reachable with the same credentials the attacker used. A backup has value only at the moment of restore, and that is the one moment when it is too late to fix.

Starting from real requirements

The conversation begins with business impact analysis rather than product selection. Which systems actually stop the business when unavailable, and after how long. How much data can be lost without serious consequence. What a day of downtime costs in money rather than in general terms.

Those answers produce RPO and RTO targets set per system. An ERP might warrant two-hour recovery with fifteen minutes of acceptable data loss, while a document archive tolerates a full day. Applying the strictest requirement everywhere multiplies cost for no benefit, and applying the loosest leaves exposure exactly where it hurts.

How we build protection

We work to the 3-2-1-1 rule: three copies of the data, on two different media types, one off-site and at least one immutable or offline. That last condition became non-negotiable once ransomware operators started deliberately hunting backup infrastructure before encrypting anything else.

Credential separation matters as much as physical separation. The backup system holds its own accounts, sits outside the production domain and applies additional restrictions on deletion. If one compromised administrator can delete every copy, the protection is theatre.

Databases get handled with engine-native tooling rather than generic file copies, since copying an active database at file level frequently produces inconsistent data that looks fine until the first restore attempt. The same applies to virtual machines running transactional workloads, where application-consistent snapshots are the difference between recovery and archaeology.

Testing, the part that gets skipped

A backup that has never been restored is an assumption. We schedule restores deliberately: automated integrity verification, monthly file and virtual machine restores, and an annual full exercise where critical systems are recovered into an isolated environment and the real time to service is measured.

These exercises reliably find something. A service depending on configuration held on another server, a licence tied to a hardware identifier, a procedure that assumes access to a system unavailable in the very scenario being simulated, or a restore time three times the estimate. Learning that during a test costs a morning; learning it during an outage costs considerably more.

Business continuity

The continuity plan extends past technology. It covers who decides to invoke it, how the situation is communicated internally and to customers, which processes run manually while systems are down, and how you return to normal afterwards. It includes verified contact lists, because a list full of former employees’ numbers is worthless at three in the morning.

For organisations in NIS2 scope, business continuity and crisis management are explicit requirements, and evidence of testing is requested during assessment. We document each exercise with results and the corrective actions that follow, which serves both engineering and audit purposes.

Who this is for

The service fits companies where downtime translates directly into lost revenue, organisations with regulatory continuity obligations, and teams that have been through an incident and found recovery took far longer than anyone expected. As an EU-based provider we keep backup copies within EU regions by default, which keeps the residency question straightforward for data that is, by definition, a complete copy of everything you hold.

The outcome is simple to describe: when someone asks how long a full recovery would take, the answer comes from a measurement rather than from an optimistic guess.

Frequently asked questions

We already run daily backups. What else is needed?

The useful question is not whether backups run but when you last restored from one. The problems we find most often are jobs that run reliably yet skip systems added later, databases copied at file level that are inconsistent on restore, and backup storage reachable with the same credentials as production.

How do backups protect against ransomware?

Only if the attacker cannot delete them. At least one immutable or offline copy with credentials entirely separate from production infrastructure is essential. Many organisations hit by ransomware discover their backup system was encrypted alongside everything else because it sat in the same domain with the same administrative accounts.

What do RPO and RTO mean in practice?

RPO is how much data you can afford to lose, expressed as time: a four-hour RPO accepts losing the last four hours of work. RTO is how long until the service is usable again. Both should be set per system, since not everything carries equal weight, and cost rises steeply as either number approaches zero.

How often should restores be tested?

File and virtual machine level restores monthly, and a full recovery exercise for critical systems at least annually, or twice yearly in regulated environments. NIS2 business continuity expectations require evidence that the plan has been tested, not merely that it has been written.