Disaster recovery you have measured, not just written down

Contents

1. 1Executive summary
2. 2The challenge
3. 3Architecture
4. 4How it works
5. 5Capabilities in detail
6. 6Security and data handling
7. 7Where it fits
8. 8Deployment and system requirements
9. 9Technical specifications
10. 10Getting started

1Executive summary

DisasterRecover turns the DR plan into an enforced runbook: servers recover in order at the DR site, health checks prove they work, people confirm each gate, and scheduled drills measure the recovery time and data age you would really get.

2The challenge

Most disaster-recovery plans are documents. Nobody knows the real recovery time until the day it is needed, and on that day steps get skipped under pressure.

The TotalHeal approach. DisasterRecover turns the plan into a runbook the system enforces: servers recover in order at the DR site, health checks prove they work, people confirm the gates, and quarterly drills measure the recovery time you would really get.

3Architecture

4How it works

1. DeclareA second person declares the disaster.
2. SelectThe newest clean, verified point per server is frozen and chosen.
3. RecoverGroups recover in order on the DR servers.
4. ValidateHealth checks run; DNS switch and sign-off are confirmed.
5. ReportAchieved RTO, worst RPO and findings are kept.

5Capabilities in detail

• Plans in orderRecovery groups in order; each server mapped to the DR server it recovers on, original paths or a folder, and health checks (HTTP status, TCP connect, path exists).
• Targets and readinessRPO and RTO targets, worst restore-point age against the RPO, DR servers not seen for an hour, last drill and when the next is due.
• Failover runbookA second person declares the disaster; points are frozen; the newest clean, verified point is selected; groups recover in order; health checks run; DNS switch and business sign-off are confirmed steps; a report closes it.
• Non-disruptive drillsEvery group restores into a scratch folder on the DR server, is cleaned up and reported — every 90 days by default, started by the schedule.
• Measured, not assumedAchieved RTO, worst RPO, targets met, files and bytes restored, checks passed and failed, and findings, kept for audit.
• No skipped gatesA run never skips a gate; a failed step fails the run with its reason.

6Security and data handling

• No skipped gatesRuns never skip a gate; failures stop with a reason.
• Drills do not disruptDrills restore into scratch folders and clean up.
• Two people declareThe starter cannot declare a disaster alone.

7Where it fits

8Deployment and system requirements

9Technical specifications

10Getting started

• TotalHeal RecoveryVault
• A server at the recovery site with the TotalHeal agent

Start a 30 days trial in the TotalHeal console with a Sttiz account. For a quote, an on-premises installation or the procurement dossier (compliance matrix, bill of materials, architecture and hardening, SLA, OEM authorisation letter), write to business@totalhealsecurity.com.