Home / Knowledge hub / Disaster recovery
Knowledge hub
Disaster recovery
The plan and tools for restoring systems and data after a major failure.
What it means
Disaster recovery is the part of planning that deals with bringing technology back after a serious failure. The failure might be a lost cloud region, a corrupted database, a ransomware attack or a deleted production account. The plan says what to restore, in what order, from where, and by whom.
It sits inside business continuity. Continuity asks how the business keeps going. Disaster recovery asks how the systems come back, using backups, standby environments, and written steps people can follow when stressed. A good plan is specific enough that someone who did not write it can follow it.
Why it matters
Without a tested plan, recovery is improvised while customers wait. Improvised recoveries take longer than anyone expects, miss dependencies such as secrets or DNS, and sometimes restore the very problem that caused the outage. Each hour offline has a cost in sales, support load and trust.
Contracts and regulators increasingly ask for evidence. Buyers want to see a plan, its targets and the date of the last test. Cyber insurers ask the same. A plan with a recent, honest test result is a sales asset as well as a safeguard.
How it shows up
A working plan lists the systems in priority order, sets a recovery time objective and a recovery point objective for each, stores backups away from the production account, and keeps the steps written down outside the systems they restore. Infrastructure defined as code makes rebuilding faster.
Typical failures are backups never restored in practice, recovery steps that depend on the systems that are down, keys and passwords stored only in the failed environment, and plans that nobody has rehearsed. Run a restore test at least yearly. Check backup integrity regularly, since a corrupt backup is found only at restore.
Questions people ask
Disaster recovery, answered
What is the difference between disaster recovery and a backup?
A backup is a copy of data. Disaster recovery is the whole plan to restore service, including systems, configuration, people and order of steps.
Backups are an ingredient, not the plan.
How often should we test disaster recovery?
At least once a year, and after major changes to systems. Test an actual restore, not just whether the backup job reported success.
Record how long it took and compare it with your target.
Does the cloud remove the need for disaster recovery?
No. Cloud providers keep their infrastructure running, but you remain responsible for your data, configuration and accounts under the shared responsibility model.
A deleted database or compromised account is still your recovery job.
What is a hot, warm or cold standby?
A hot standby is a running copy ready to take over at once. A warm one is partly running and needs minutes or hours. A cold one has to be built from backups and takes longest.
More readiness costs more.
Where should recovery instructions be kept?
Somewhere that survives the failure, such as a printed copy, an offline file or a separate account. Instructions kept only in the system that is down cannot be read.
Check that the right people can reach them.
Related
Terms that sit next to this one
Business continuity
Keeping critical services running, or restoring them fast, through a disruption.
Backup integrity
Knowing your backups are complete, untouched and actually restorable.
Recovery time objective
The longest outage you can accept before a system must be back.
Recovery point objective
The most data, measured in time, you can afford to lose.
Ransomware
Malware that locks your data and demands payment to unlock it.
Can you restore it from scratch?
Recovery plans handle the aftermath. Cyberlop works earlier, finding exploitable flaws in your web app and APIs and proving each with a request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.