These are parts of one recovery. Looking at them separately makes it easier to see what your current setup covers and what still needs an owner.
Backup keeps a recovery point
A backup keeps data or system states you can restore. Retention and backup frequency decide how much history you have. After a cyber incident a recovery point may need checking before it is safe to restore.
Ask: What is protected, how recent is the data, and who checks the backups?
Disaster recovery keeps you working
DR combines recoverable systems with the infrastructure and process to run them when production is unavailable. Compute capacity, network access, identity and application dependencies all matter.
Ask: Where will we run, which services come back first, and who confirms they work?
Failback completes the recovery
While systems run in DR, their data changes. Moving back to production needs a planned switchover so those changes reach your own environment.
In Immutec’s backup-based approach, the move back means a final backup in DR, shutting DR down, syncing back to your environment and starting the systems there. The business then checks that everything works.
Ask: Who owns the final sync, the downtime window, the readiness of your environment and sign-off?
RPO and RTO answer different questions
Recovery point objective (RPO): how much data you can afford to lose. Backup frequency decides how much recent work could be missing.
Recovery time objective (RTO): how soon the service must work again. Boot time is only part of it; choosing the recovery point, network, dependencies and checks all count.
Set objectives per service and per scenario. A hardware failure and a ransomware attack can need different decisions.
Take these questions to your next review.
Download the plain-text checklist, add your evidence and agree who owns each next step.
Download checklist