A backup is not a copy of your data. It is a promise about the future: that on some bad morning you will be able to rebuild what was lost, quickly enough that the business survives, from a copy that the same event could not touch. Most backup programs that fail an organization did not fail because no copy existed. They failed because the copy was reachable from the very account that got compromised, because nobody knew how long a full restore actually takes, or because the copy had quietly stopped running weeks earlier and no one was watching. Designing backups for recovery means treating that promise as something you have to engineer and prove, not something a nightly job silently grants you.
This guide keeps the topic concrete and defensive. It is about the handful of design choices that decide whether a copy survives a ransomware event, whether you can restore before deadlines start slipping, and whether you would actually know if the whole thing broke. None of it requires a large team, only clear thinking about what you are promising and to whom.
Why a copy the attacker can reach is not a backup
The single design idea that separates a real backup from a false comfort is reachability. If a backup lives on a share that is mounted on the same server it protects, and an administrator account can delete or overwrite it, then an intruder who holds that account can erase your recovery copies as easily as your live data. This is exactly what ransomware operators look for, because destroying backups is what turns a recoverable event into a ransom demand. The defensive answer is to put distance between the working environment and the copy, so that compromising the first does not grant control of the second.
That distance takes a few practical forms. An offline copy is disconnected from the network except during the window when it is being written, so most of the time there is nothing to reach. An immutable copy uses storage that will not allow changes or deletions for a defined retention period, even by an administrator, so a stolen credential cannot rewrite history. A well-worn shorthand captures the spirit: keep several copies, on at least two kinds of media, with at least one kept off-site or otherwise out of reach. The details matter less than the principle, which is that at least one copy must survive the total compromise of everything else. Because the account that manages backups is such a high-value target, it deserves the same scrutiny described in Service Accounts and Secrets .
Recovery objectives: how much time and how much data
Two numbers turn backup from a vague good intention into a design you can check. The first is how much data you can afford to lose, measured as the gap between backups, sometimes called a recovery point. If you back up once a day, you are implicitly accepting that a bad event could cost you a day of work; if that is unacceptable for the customer database but fine for a file archive, then those two things need different schedules. The second number is how long a restore may take before the delay itself becomes the emergency, sometimes called a recovery time. A copy that technically exists but needs three days to rebuild is not much comfort to a business that fails after one.
Naming these two numbers per system is the quiet heart of backup design, because they force honest trade-offs. Frequent backups and fast restores cost more in storage and effort, so you spend that budget where the business actually needs it and accept slower recovery where it can tolerate the wait. Deciding which systems deserve the tightest objectives is really a question about impact, which is why this pairs naturally with Impact and Blast Radius : the systems whose loss spreads the widest are the ones whose recovery numbers should be tightest.
What evidence matters?
Backup design is unusually easy to fool yourself about, so the evidence that matters is the evidence that a promise is actually being kept. A green status on last night’s job is a start, but it only tells you the copy was written, not that it can be read back into a working system. The stronger evidence is a record of the last successful restore: a date, the person who ran it, the system that was rebuilt, and how long it took. If that record does not exist, then in a real sense the backup is untested and its promise is unproven. The companion guide Restore Drills is entirely about generating exactly this kind of evidence on purpose.
Beyond restore records, the useful facts are the ones that describe reachability and coverage. Where does each copy physically live, and what account can modify or delete it? Is the immutability window long enough to outlast the time an intruder might sit quietly before triggering encryption, a dwell period discussed in the Ransomware Timeline ? Are the systems you assume are covered actually in the backup scope, or has something drifted out of it unnoticed? Each of these is a plain, checkable fact with an owner and a timestamp, which is what makes it evidence rather than assumption.
Toy example
Imagine a fictional bakery-supply company, Prosser Provisions, with a customer database, an order system, a shared drive of recipes and label art, and a laptop fleet. Their backups run nightly to a network appliance in the same office, and everyone feels covered. A defender doing a calm review asks one question: if the account that manages that appliance were compromised, could the copies be deleted? The answer is yes, which means the design protects against a failed hard drive but not against ransomware.
The redesign is modest and specific. The nightly appliance stays, because it makes ordinary restores fast, giving the order system a tight recovery time. A second copy is written to immutable cloud storage with a retention window measured in weeks, so a stolen administrator credential cannot erase it. The customer database, which the business cannot run without, gets a tighter recovery point than the recipe archive, which changes slowly. Nobody has proven recovery yet, but the promise is now shaped correctly: at least one copy would survive total compromise, and the two recovery numbers reflect what the business actually needs.
Common mistakes and false positives
The most expensive mistake is confidence without a restore. A wall of green backup jobs feels like safety, but until a copy has been read back into a working system, it is a hypothesis. Closely related is the silent-failure trap, where a job stops running or a system falls out of scope and no alert fires, so the gap is only discovered on the worst possible day. A third mistake is protecting the data but not the backup account, leaving the recovery copies as reachable as the originals. And a subtle one is retention that is too short: if an intruder sits quietly for six weeks and your immutable window is two, the clean copies may have already rotated away by the time you need them.
Not every worrying signal is a real failure, though, and calm review matters here too. A skipped job may be a planned maintenance window, a shrunk retention setting may be an approved cost decision, and a missing system may have been deliberately excluded. The discipline is the same as everywhere else in defense: write down the observable fact, ask the owner, compare against what the policy intended, and only then decide whether you are looking at a gap or a choice.
What to do next
Start by writing down your two recovery numbers for the systems that matter most, then find the evidence that they are achievable rather than aspirational. Locate every copy, name the account that can modify each one, and confirm that at least one copy is genuinely out of reach through offline storage or immutability. Where you cannot point to a recent, successful restore, treat that as the most important gap to close, because it is the one that hides until an emergency.
For learning, sketch a fictional environment and design its backups deliberately: assign recovery numbers per system, mark which copy would survive a full compromise, and note where you have no restore evidence yet. Then move into Restore Drills to turn the design into proof, and read Detecting Encryption Behavior and Containment Decision Trees so that the early warning and the recovery plan reinforce each other.
How this guide was made
This page is defensive education drawn from public recovery frameworks and openly published guidance, illustrated with a fictional company and invented systems. It focuses on the design choices that make backups survivable and restorable, and it avoids any operational offensive detail. It makes no claim to certification, legal advice, or incident-response authority; treat it as a way to reason about your own recovery posture, not a substitute for professional planning.
Official references
For orientation rather than certification, the CISA StopRansomware Guide explains why offline and immutable copies are central to surviving ransomware, NIST SP 800-61 Rev. 3: Incident Response Recommendations places recovery within the wider incident lifecycle, and the CIS Critical Security Controls v8 describe the data-recovery safeguards this guide reflects.
Related guidebooks
Pair this with Restore Drills to prove the design works and Ransomware Timeline to understand what the backups must survive, and read Detecting Encryption Behavior alongside Containment Decision Trees for the detection and response that buy your backups time.
