Before
Define RTO and RPO
How long can you be down, and how much data can you lose? Write the numbers down.
⚠ Guide
Disaster recovery testing that proves the plan works
Disaster recovery testing (DR testing) means causing a real outage on purpose and timing how long it takes to restore service and data. A good DR test measures you against your RTO and RPO and ends with a written report. An untested DR plan is a hope, not a plan.
The DR drill checklist
Before
Pick the disaster
Lost zone, lost region, corrupted database, deleted bucket. One per drill.
During
Start the clock
Inject the failure and time detection, decision and recovery separately.
After
Restore and verify
Check data integrity, not just that the page loads. Then write the report.
What usually breaks
Backups that restore but take four times longer than anyone guessed. DNS TTLs nobody lowered. Credentials for the standby region that expired last year. Runbooks that reference a dashboard that was deleted. A DR drill finds these on a Tuesday afternoon instead of during a real outage.
DR testing FAQ
+ What is the difference between DR testing and failover testing?
Failover testing checks automatic takeover. DR testing covers the full recovery, including manual steps, restores and data checks.
+ How often should we run a DR drill?
At least twice a year, and quarterly if you have compliance requirements or frequent architecture changes.
+ Does DR testing help with compliance?
Yes. SOC 2, ISO 27001 and many regulators expect evidence of tested recovery. Oh My GDaaS run reports double as that evidence.
Safe by design
Every fault Oh My GDaaS runs is aimed at infrastructure you have proved you own, through a DNS record, a scoped cloud role or a deployed agent. Every run has a blast-radius limit, a hard time limit and an abort button. We are not a booter, stresser or DDoS service and never will be.