Most organizations believe they have a backup. Something runs overnight, a status message appears in the morning, and nobody has needed to restore anything in a long time. That arrangement feels like protection and frequently is not, because the question that matters is not whether backups run. It is whether a restore works, how long it takes, and how much work is lost in the process.
The gap becomes visible at the worst possible moment. A server fails, a database is corrupted, or ransomware encrypts a file share, and the organization discovers that the backup covers only part of what matters, or that the restore takes three days, or that the backup files were on a share the ransomware also reached.
Building Backup & Disaster Recovery capability that actually works starts with defining what the business needs to survive rather than with configuring software, because those requirements determine everything about how the system should be built.
The Two Numbers That Define the Requirement
Every recovery discussion should start with two figures, stated per system rather than generally.
Recovery point objective is how much data the organization can afford to lose, measured in time. A nightly backup means up to a day’s work is at risk. For a finance system processing transactions continuously, that may be unacceptable; for a document archive that changes weekly, it is generous.
Recovery time objective is how long the organization can operate without the system. Some can be down for a day with minor inconvenience. Others stop the business within an hour.
These figures differ substantially between systems, and treating everything identically means either overspending on low-priority systems or underprotecting critical ones.
Setting them requires a business conversation rather than a technical one. The people who know what an outage costs are the ones running the operation, not the ones running the servers.
Once established, these numbers determine backup frequency, retention, storage location, and recovery method, and the design follows from them rather than the reverse.
Why Copies in One Place Are Not Enough
The long-standing principle of keeping multiple copies on multiple media with at least one offsite exists because single points of failure keep proving the point.
Multiple copies protect against a backup itself being corrupt, which happens more often than people expect and is usually discovered during a restore.
Different media or platforms protect against a failure mode that affects one type, including a storage system fault or a platform-level problem.
Offsite copies protect against anything affecting the primary location: fire, flood, theft, or in Florida and similar regions, a storm that damages the building.
An additional principle has become necessary more recently, which is that at least one copy should be immutable or otherwise isolated from the production environment.
The reason is ransomware. Modern attacks deliberately target backup systems before encrypting production, because an organization that can restore does not pay. A backup reachable with the same credentials that reach production is a backup an attacker can delete.
Designing for Ransomware Specifically
The threat has changed what adequate protection means.
Immutable storage, where backup data cannot be altered or deleted for a defined retention period even by an administrator, is the most effective single control available.
Credential separation means backup systems do not use the same authentication as production, so compromise of the environment does not automatically compromise the backups.
Air-gapped or logically isolated copies, whether on removable media or in a separate environment with restricted access, provide a last resort.
Retention long enough to outlast dwell time matters, since attackers frequently remain in an environment for weeks before encrypting. A backup cycle that only retains two weeks may contain nothing clean.
Detection of unusual backup activity, including mass deletion or sudden changes in data volume, can provide early warning.
And restoration procedures should assume the production environment is compromised, meaning the recovery target may need to be built clean rather than restored into existing infrastructure.
Testing Is the Part That Gets Skipped
An untested backup is a hypothesis rather than a protection.
Restore testing should happen on a schedule, not when something breaks. Restoring a file proves very little; restoring a system and confirming it functions proves something useful.
Full recovery exercises, meaning bringing critical systems up in a recovery environment and verifying that applications work and data is intact, reveal the dependencies and configuration details that documentation always omits.
Timing the recovery is the point most often missed. An organization with a four-hour recovery objective and a twelve-hour restore process has a gap it does not know about until it matters.
Testing after significant changes matters, since a new application, a modified environment, or a platform upgrade can quietly break a recovery process that worked previously.
Documentation should be current and accessible without the systems being recovered, which sounds obvious and is frequently not the case.
Involving the people who would actually perform the recovery, rather than only the person who designed it, surfaces the knowledge gaps that would otherwise appear during an incident.
Recovery Is More Than Data
A complete plan addresses the operation rather than only the files.
Communication, meaning how staff, customers, and suppliers are informed during an outage, needs deciding in advance because improvising it during an incident goes badly.
Priority ordering determines which systems come back first, and that should be a business decision made calmly rather than a technical one made under pressure.
Alternative working arrangements, meaning how the organization functions while systems are down, are worth thinking through even briefly.
Authority and roles should be clear, so that decisions get made rather than discussed.
Contact information for vendors, providers, and key staff needs to exist somewhere accessible when systems are unavailable.
Insurance and legal notification requirements may apply, particularly where personal data is involved, and the timeframes can be short.
Keeping It Working
Protection degrades quietly without attention.
New systems need adding to the backup scope, and this is the most common gap. Environments accumulate servers and services that nobody added to the protection scheme.
Retention and capacity need periodic review as data grows.
Success and failure reporting should be monitored by someone, since a backup that has been failing silently for six weeks is a common discovery.
Recovery objectives should be revisited as the business changes, since a system that was non-critical two years ago may now be central.
And someone should own it. Backup systems that nobody is responsible for are the ones found, during an incident, to have stopped working at some point nobody can identify.
