These are connected parts of one recovery journey. Separating them makes it easier to see what your current service includes and what still needs an owner.

Backup preserves a recovery point

Backup retains data or system states that can be restored. Retention and backup intervals determine the history available to you. A backup point may still need assessment before it is appropriate to restore after a cyber incident.

Ask: What is protected, how recent is the available data, and who checks the backup service?

Disaster recovery restores operation

DR combines recoverable systems with the infrastructure and process needed to run them when production is unavailable. Compute capacity, network access, identity and application dependencies all matter.

Ask: Where will we run, which services return first, and who confirms they are usable?

Failback completes the journey

While a system runs in DR, its data can change. A return to production needs a planned cutover so the required changes reach the prepared source environment.

For Immutec’s backup-based workflow, the agreed return includes the final DR backup and shutdown, synchronisation back to the source and coordinated startup. The business then validates operation.

Ask: Who owns the final synchronisation, downtime window, source readiness and acceptance?

RPO and RTO answer different questions

Recovery point objective (RPO): the acceptable gap in recoverable data. A backup interval affects what recent work may be missing.

Recovery time objective (RTO): the target time to restore the service. Boot time is only one part; selection, connectivity, dependencies and validation affect usability.

Agree objectives for a defined service and scenario. A hardware failure and a ransomware incident may require different recovery decisions.

Put it to work

Bring the questions to your next review.

Download the plain-text checklist, add your evidence and agree who owns the next step.

Download checklist