Backups are not enough without a tested recovery plan

Why backup alone is not enough

A backup is a copy of data at a point in time. A recovery plan is the process that turns that copy back into a running service. Many Czech companies store backups on a NAS in the server room but do not address what happens if the server room burns down or ransomware encrypts the network storage as well. Without a plan you do not know how long it takes to pull terabytes of data back, whether the boot media works, or who holds the passwords for the database server. In audits by the Czech Institute for AI and Data (CIAD), organisations that test recovery regularly reduce outage from weeks to hours.

RTO and RPO in practice

RPO (Recovery Point Objective) defines how much data loss is acceptable. A backup every four hours means an RPO of four hours. RTO (Recovery Time Objective) is the time by which a system must be running again, for example six hours for an e-shop, 24 hours for an internal wiki. If you keep daily backups (RPO 24 hours) but the business process tolerates only one hour of loss, the backups are insufficient. Equally, if you target an RTO of four hours but database restore takes ten hours, the plan does not work. A Czech manufacturer set RPO one hour for ERP and RTO eight hours; a test showed restore from deduplicated storage took 14 hours, so they introduced replication to a secondary site.

What a recovery plan must contain

A disaster recovery plan is more than a server list. It must define roles and responsibilities, who initiates recovery, who communicates with customers, who decides on failover. It must list priority systems in order of criticality, for example Active Directory, then SQL, then application servers, then file servers. It must cover procedures for different scenarios: ransomware, power loss, hardware damage, human error. It must include communication templates for employees, suppliers and authorities such as the Office for Personal Data Protection (ÚOOÚ) in the event of a personal data breach. Finally it must set a test schedule: at least one full simulation per year and quarterly test restores of the key database.

What a meaningful recovery test looks like

A test is not checking that the backup job completed. A test means shutting down the production server, restoring from backup onto clean hardware, verifying application function and measuring the time. A Czech e-shop processing 50,000 orders a month restored a Magento database to a new virtual server in the cloud. The restore took 3.5 hours but application logs showed index errors; fixing them added two more hours. Without the test they would have discovered this during a real incident. After the test they added an automated index rebuild to the post-restore script and reduced RTO to four hours.

Common mistakes and how to avoid them

The most frequent mistake is storing backups in the same network segment as production, so ransomware encrypts both. The fix is air-gapped backups, for example tapes in a vault, or immutable object storage with Object Lock. A second mistake is backing up only data, not configuration such as scripts, certificates and firewall rules. A third is assuming the cloud provider (Microsoft 365, AWS) handles everything; their SLA covers infrastructure availability, not your data against user deletion. A fourth is failing to update the plan after deploying a new application or changing the network topology.

What this means

Backups without a tested recovery plan are only an illusion of security. Real resilience requires defined RTO and RPO, separated backup storage and regular exercises that restore onto a clean environment.