Disaster Recovery: the complete 2026 guide

TL;DR

Disaster Recovery is the discipline of bringing IT systems back online after a serious failure. It is measured by two numbers: RTO (how long until the service is back) and RPO (how much data can be lost). In 2026, with NIS2 and ISO 27001:2022 fully effective, having a written and tested DR plan is no longer a "best practice": it is a legal requirement for many sectors. This guide covers what is needed to choose, size and maintain a serious DR system.

What Disaster Recovery is

Disaster Recovery (DR) is the discipline that handles IT infrastructure recovery after a disastrous event. "Disastrous" rarely means a flooded datacentre: nine times out of ten it is ransomware, human error, hardware failure or a botched software upgrade.

DR sits inside the broader Business Continuity & Disaster Recovery (BCDR) practice, which also covers people, processes, suppliers and communications. DR is the technical slice: how do we get systems back up.

A useful distinction: backup ≠ disaster recovery. A backup is a copy of data. DR is the bundle of automation, configuration, runbooks and infrastructure that turns that copy into a working system. Having a backup without DR is like having an airbag without a seat belt: better than nothing, but not enough.

The numbers that matter: RTO and RPO

Every DR project revolves around two numbers.

• RTO (Recovery Time Objective) — the maximum acceptable time between the disaster and the return to normal. A 15-minute RTO means the service has to be usable again 15 minutes after the disaster.
• RPO (Recovery Point Objective) — the maximum amount of data the business is willing to lose. A 5-minute RPO means that, in the worst case, only the last five minutes of work are lost.

The smaller these two numbers, the more DR costs. The first step in any project is therefore a Business Impact Analysis (BIA): for each critical application, how many minutes of downtime the business can tolerate, the cost (in euros per minute) and the data loss the business can absorb without manually re-keying a day's work.

The main DR architectures

Five canonical architectures exist, ranked by increasing RTO.

1. Active-active multi-site — two datacentres in production at the same time, traffic balanced. Sub-second RTO, very high cost. Typical of banks and telcos.
2. Hot standby — secondary site always running, continuous replication. RTO from a few seconds to one minute.
3. Warm standby — VMs ready but powered off, data replicated. RTO of a few minutes. The Sefthy sweet spot.
4. Cold standby — off-site backups, infrastructure provisioned at disaster time. RTO from hours to days.
5. Backup-only — just data copies. Not really DR, but the floor for surviving ransomware.

Most Italian SMBs need a warm standby for core systems (ERP, mail, file server) and backup-only for the rest. Spending on active-active for an 80-employee company is almost always overkill.

Cloud DR vs on-premises DR

Historically DR meant a second owned datacentre. By 2026 the model has shifted:

• Cloud DR is almost always cheaper because you pay only for storage, with compute "kicking in" only at failover time.
• It is easier to test: a cloud VM boots, you verify, you shut it back down.
• It is more compliant with NIS2 and ISO 27001:2022 because serious providers (with at least ISO 27001 + 27017 + 27018) hand half the evidence work back to the customer.

When does an on-prem secondary still make sense? Two cases: regulated sectors (defence, level-3 healthcare) or when RTO must be under 30 seconds and public latency is not enough.

The Layer-3 problem and why L2 tunnels exist

Most cloud DR works at Layer 3: the cloud VM gets a new IP, and a site-to-site VPN with NAT connects it back to the customer LAN. This works on paper but in practice creates heavy issues:

• DNS reconfiguration — A records have to change. Previous TTLs propagate the change in 15-60 minutes.
• Apps with hard-coded IPs — pre-2010 ERPs often have IPs hard-coded in source or config files. Reconfiguring them under stress is an error magnet.
• Customer firewall reconfiguration — rules built for a local IP must be reworked for a cloud IP.

Sefthy uses a Layer 2 tunnel (a virtual ethernet cable) between the customer LAN and the cloud. The cloud VM boots with the same IP, the same subnet and the same broadcast domain as the original. Clients reconnect without noticing. No DNS, no NAT, no reconfiguration.

How to choose a DR solution

A short selection checklist:

1. Realistic RTO and RPO from the vendor, not brochure numbers. Ask for a documented real case.
2. Number of drills included in the contract. Untested DR does not work. Sefthy includes quarterly drills in every plan.
3. Provider compliance: ISO 27001:2022, ISO 27017, ISO 27018. Missing 27018 is a red flag for personal data.
4. Data sovereignty. For public-sector or NIS2 entities, an Italian cloud (not just "European") is a tender advantage.
5. Transparent pricing. Beware "pay per restore" — at disaster time the bill can triple.

What changed in 2026

Three things turned DR into a board topic, no longer just an IT one:

• NIS2 — Article 21 mandates measurable continuity controls. A written DR plan is the first thing ACN asks for during an audit.
• Cyber insurance — insurers now require evidence of tested DR before underwriting. Without quarterly drills, premiums are up to 40% higher.
• Customer expectations — a six-hour outage on an e-commerce site makes news in 2026. In 2018 it was normal.

Common mistakes

The three mistakes we see most often:

• Declaring an unrealistically low RTO at sales time and never testing it. Disaster day brings the surprises.
• Confusing snapshots and DR. A snapshot is a disk image; without an application restart plan, it is just storage.
• Skipping runbooks. DR is also organisational: who does what, in which order, with which credentials.

FAQ

How much does cloud DR cost for an SMB?

For a company with 5-15 virtual servers, managed DR with a 10-minute RTO starts around €300-700 per month in Italy. The low end is backup-only, the high end is warm standby with an L2 tunnel.

How often should DR be drilled?

ISO 27001:2022 control A.5.30 and NIS2 Article 21 recommend at least one full drill per year. Mature practice means quarterly tabletops and an annual full failover.

Does DR replace backup?

No. DR uses backups as an ingredient. Backups guarantee the data exists; DR guarantees the service comes back.

How long does a serious DR rollout take?

With an experienced vendor, a 50-100 employee company completes onboarding (deploy, configuration, first drill) in five working days. Below five days you usually skip the BIA; above three weeks you usually missed a stakeholder.

Want a concrete DR plan tailored for your company? Talk to a Sefthy specialist or read the deep dive on how to calculate your real RTO.