Backup and disaster recovery, tested before you need it.

Backup protects your data; disaster recovery protects your operations: one restores files after an outage, the other brings whole systems back within a target time. In 2026 the difference turned urgent because ransomware now targets the backups first, so a copy that can be reached and deleted is not really a backup at all. Argus Root runs both for organisations that have to keep running through an incident, with immutable copies and a recovery you have rehearsed, operated and restored inside the EU.

Modern ransomware goes for the backups before it triggers, so a copy your administrators can delete is a copy an attacker can delete. The 3-2-1-1-0 standard answers that: three copies, on two media types, one offsite, one immutable, and zero recovery errors verified automatically. Immutable storage cannot be altered or deleted by anyone, including an administrator, and an air-gapped copy sits outside the reach of your production network entirely.

CISA now treats immutability as mandatory rather than optional, and the cost has dropped far enough that it is within reach for mid-sized organisations. We build it in by default, and we keep the immutable copies in-region so recovery never depends on a jurisdiction you do not control.

The threat has become deliberate. Ransomware is now written to hunt for backup files specifically, locating, encrypting or deleting them before the main payload triggers, because the attackers know a working backup is what lets you refuse to pay. A recovery strategy that has not changed since 2023 is carrying more risk than its owners realise, defending against the hardware failure of the past while the actual threat goes after the safety net first.

There is a subtler version of the same problem: the contaminated backup. When an intrusion has been spreading quietly for days or weeks before anyone notices, the most recent backups may already contain the attacker's foothold, so restoring the latest copy restores the compromise with it. A real recovery plan accounts for this, keeping enough clean history and the means to recover to a known-good point rather than blindly to the newest one. Immutability protects the copy; knowing which copy to trust is the other half.

Plenty of providers can show you a green backup dashboard. The number that matters is how long it takes to bring a real workload back, and whether anyone has checked lately. We run the backups on infrastructure we operate inside the EU, test the restores on a schedule, and report recovery in the terms a board and an auditor understand: time to recover, data at risk, and the date of the last successful test.

# nightly backup to EU object storage, object-lock = immutable
$ restic -r s3:eu-central.example.com/acme backup /srv /etc --tag nightly
# object-lock is enforced provider-side, so ransomware cannot delete it

# the part most skip: prove the restore actually works
$ restic -r s3:... restore latest --target /restore-test --include /srv/db
$ sha256sum -c /restore-test/srv/db/checksums.sha256   # integrity
# RTO drill: time the full bring-back of one critical system — monthly

Every recovery decision comes down to two numbers. The Recovery Time Objective is how long a system can be down before the damage is unacceptable; the Recovery Point Objective is how much data you can afford to lose, which sets how often it must be backed up. Set them honestly and the architecture follows; guess at them and you either overspend protecting what does not matter or under-protect what does. The old defaults of an eight-hour RTO and a daily RPO were built for hardware failure and do not survive a ransomware scenario.

The numbers are not the same for every system, which is why we tier them. The handful whose loss means immediate financial or regulatory damage, the payment path, the core platform, justify near-real-time replication and an RTO measured in minutes; business-critical applications get a measured failover; supporting functions can tolerate a longer, cheaper recovery. The classification comes from what the business cannot do without rather than from what the IT team finds interesting, so the spend lands where the impact is rather than spread evenly across things that do not need it.

When something fails, a recovery runs on a plan rather than improvisation. The systems are brought back in the order the business depends on them, the critical path first, with each restore verified before the next is trusted, and the people who have to make decisions, declare a disaster, choose a recovery point, accept a degraded mode, have made them before in a drill. The runbook is the difference between a recovery measured in the hours you planned for and one that drifts into days because every step is being worked out live.

The hardest case has its own path. When the failure is a ransomware attack that may have been present before the last backup, the plan does not restore blindly to the newest copy; it recovers to a clean point, in an isolated environment where the restored systems can be checked before they rejoin production, so the recovery does not reintroduce the attacker. Planning for the contaminated-backup case in advance is what separates a recovery that ends the incident from one that restarts it.

A backup is only as sovereign as the place it is restored from. Copies held in a US-controlled cloud, even on European soil, sit under foreign jurisdiction, which means a recovery for a regulated workload can hinge on data that a foreign authority could in principle compel, or that falls outside the rules you are held to. For the same reasons that drive the rest of our work, that is a dependency worth removing from the one process you turn to when everything else has failed.

So the backups and the recovery environments stay inside the EU, on infrastructure we operate, and the residency is documented rather than assumed. The moment of a disaster is the worst time to discover that your recovery path crosses a border you did not account for. Keeping the whole chain in-region means the restore answers to your rules and your jurisdiction alone, which is exactly when that certainty earns its place.

The technology is half of a recovery; the other half is people making fast decisions under stress. Someone has to declare a disaster, which starts the clock and the plan; someone has to choose the recovery point and accept the data lost beyond it; someone has to decide whether to run degraded or wait for full restoration, and to keep customers, staff and regulators informed while the work happens. A plan that names who does each of these, and has had them practise, recovers faster than one that is technically sound but silent on who is in charge.

This is why a drill rehearses the decisions rather than the mechanics alone. The first time a team makes these calls should not be during a real outage with the meter running and everyone watching. We define the roles, the escalation and the communication in the runbook and exercise them, so when it is real the question is which step we are on rather than who is supposed to be doing what. A recovery fails as often on confusion and hesitation as on a backup that would not restore.

The reason all of this matters is that a failed recovery is often a terminal event. A business that cannot get its systems and data back does not merely lose a week; a significant share of organisations that suffer major data loss without a working recovery never fully reopen, undone by the lost revenue, the broken customer trust and the regulatory consequences that follow. The backup nobody tested becomes the reason the company does not survive the incident it was meant to survive.

Recoverability is therefore a continuity-of-the-business question rather than an IT line item, which is why the targets come from leadership rather than the server room. The investment in tested, immutable, tiered recovery is small against the cost of being unable to come back, and it is the cheapest insurance most organisations are underbuying. We frame it that way because the decision is a business one: how much downtime and data loss can you survive, and what is it worth to guarantee you stay inside that.

The clearest case is an organisation under DORA or NIS2, which now have to demonstrate tested continuity with defined recovery targets rather than merely own a backup. Close behind are businesses whose cyber insurer or largest customers require evidence of a tested recovery plan before they will renew or sign. Any organisation whose operations stop when its systems do, which is most of them now, has a recoverability question whether or not it has answered it.

What they share is a gap between the backup they think they have and the recovery they would really get. A business running nightly backups it has never restored, or trusting a cloud provider to protect data the provider's own terms say is the customer's, is the typical fit. Where an organisation genuinely has tested, immutable, tiered recovery already proven, it does not need us; where it has a green dashboard and an untested assumption, it does, and the first assessment usually makes which one it is uncomfortably clear.