Disaster recovery questions, answered
Short answers to the questions IT heads and business owners ask us most often about DR.
What is the difference between backup and disaster recovery?
A backup is a copy of your data. Disaster recovery is the plan and the infrastructure that let you run your services somewhere else when the main site is lost. You need both. Replication on its own copies mistakes and ransomware just as fast as good data, so backups with older versions are still essential.
What do RPO and RTO mean?
RPO is how much data you can afford to lose, measured in time. RTO is how long the service can be down. An RPO of 15 minutes and an RTO of 2 hours means: lose at most the last 15 minutes of work, and be running again within 2 hours.
Do we need a second data centre?
Not always. A colocation rack, a cloud account, or a well-powered room at another office can all work as a DR site, depending on the tier. What matters is that it does not share the same risks as the main site: same building, same power feed, same flood zone.
How far apart should the two sites be?
It is a trade-off. Synchronous replication, which gives near-zero data loss, generally needs the sites within about 100 km because every write waits for the other site. Protection against regional events such as floods or a grid failure needs more distance, which means asynchronous replication and a small amount of possible data loss. Some organisations use both: a nearby site in sync and a distant site behind it.
Can our DR site be in the public cloud?
For many workloads, yes. Check three things first: whether the data is allowed to sit with that provider and in that region, what it will cost to move data back after a failover, and whether your applications run properly on the cloud's virtual machines without changes.
Does DR protect us from ransomware?
Replication alone does not. Encrypted files replicate to DR like any other change. Ransomware protection needs immutable or offline backups, separate admin credentials for the DR and backup systems, and a tested way to restore from a point before the attack.
How often should we test?
A tabletop review every quarter, a restore test every month, an isolated failover for each tier twice a year, and a full failover of the critical systems once a year. See Testing DR for details.
How long does a DR project take?
For a mid-sized environment, the assessment and design usually take three to six weeks. The build depends mostly on procurement: hardware lead times, network links and the DR site contract. The first drill normally follows a few weeks after the build.
What do you need from us to start?
A list of your applications and their owners, a short description of how backups work today, a network diagram if you have one, and any regulatory or contractual DR requirements. That is enough for a first gap review.
Not sure where your DR stands?
Send us your application list and a short note on how backups work today. We will come back with a plain gap review: which systems are exposed, what a realistic recovery time looks like, and what it would take to close the gap.