What happens when the backup path fails too?

What happens when the backup path fails too?

A backup is not resilient because it has a different name. It is resilient when it survives the same event that disables the primary service and can be activated with the people, credentials and information still available at that moment.

Test independence across failure domains: facility and region, network and power, identity provider, encryption keys, control plane, software release, data corruption, supplier, administrator and communications. A second environment in another zone may still share global authentication, DNS, deployment automation or a compromised privileged account.

Recovery also has two objectives: restore the data and restore a trustworthy service. Confirm backup completeness, consistency, malware status, application compatibility and the point in time the business can accept. Reconcile transactions created during degraded operation and decide which source becomes authoritative when systems rejoin.

Exercise with the primary isolated. NIST contingency controls call for separate storage, testing at alternate processing sites and full recovery to a known state. Sampling files is useful but cannot prove that applications, dependencies and operating teams can reconstitute an end-to-end service within the required time.

Measure successful restore rate, achieved recovery time and data point, manual steps, shared dependencies and time to validate business integrity. Maintain an additional path for the most critical outcomes, including a controlled manual mode where practical. The backup path is credible only after the organisation has demonstrated how it behaves when the assumed first recovery option is unavailable too.