Disaster Recovery
Design and operate disaster recovery that actually works — automated backups, high-availability architectures, and regular DR drills you can rely on.
What we deliver
- DR strategy, RTO / RPO definition, and runbooks
- Automated backup and offsite replication
- High-availability clustering (RAC, Data Guard, AlwaysOn)
- Cloud DR: pilot light, warm standby, multi-region
- Regular DR testing and failover drills
- Business continuity documentation
RPO and RTO in practical terms
Recovery point objective is how much data you are willing to lose; recovery time objective is how long you can be down. Both sound abstract until they are written as numbers against a specific system. Fifteen minutes of lost transactions might be tolerable for a reporting warehouse and completely unacceptable for order entry, and the architecture that delivers each is different in cost and complexity.
So the first conversation is not about technology. It is about which systems the business actually cannot run without, in what order they need to come back, and what an hour of downtime costs — our cost of downtime calculator is a reasonable starting point for that number. Once the targets are agreed, the design follows from them rather than the other way around.
Why untested DR fails
The most common DR failure is not a missing standby. It is a standby that stopped applying redo months ago while a green dashboard kept reporting success, a backup set that has never been restored, or a runbook that references a server which was decommissioned in the last refresh. Nothing about these problems surfaces until the day you need them, which is the worst possible time to discover them.
The second most common failure is human. A documented procedure that only one engineer has ever executed is not a procedure, it is a dependency on that person being available and calm. We write our field notes on this in is your Oracle DR standby actually working — the short version is that DR you have not exercised is a plan, not a capability.
What a tested DR posture looks like
A DR setup we would sign off on has continuous verification built in: transfer and apply are confirmed at the byte level, gaps are detected and recovered automatically from backups, lag is measured against the agreed RPO rather than assumed, and alerting is tuned tightly enough that any message means something needs doing. Monitoring that reports on its own health matters as much as the replication itself.
On top of that sits regular testing — scheduled drills that prove recovery within the target window, with results recorded and gaps fixed rather than noted. Failover stays a deliberate human decision that no automated job can trigger on its own, and the runbook is written so an engineer who has not touched the system in six months can follow it under pressure. Documentation is part of the deliverable, not an afterthought.
Common questions
How often should we test disaster recovery?
At least annually for a full failover exercise, and more often for the lighter checks — restore validation and standby currency should be verified continuously rather than on a schedule. Any significant change to the environment, such as a version upgrade, a migration, or new hardware, warrants a fresh test because that is exactly when assumptions in the runbook go stale.
Is a backup the same thing as disaster recovery?
No. Backups protect the data; disaster recovery protects the ability to keep operating. A restore from tape or object storage may take many hours before an application is usable again, which is fine if your RTO allows it and useless if it does not. Most organizations need both — reliable backups for data integrity and a replicated standby for speed of recovery.
Can you work with our existing DR setup rather than rebuilding it?
Usually, yes. We normally start with an assessment of what is already in place — whether replication is genuinely current, whether backups restore, whether the documented targets are actually achievable — and then fix the gaps. Rebuilding from scratch is sometimes the right call, but it is a conclusion we reach after looking, not a default recommendation.