Continuity and recovery
The backup is the input. A tested restore is what supports continuity.
Why copies, integrity, retention and restoration testing form one process guided by acceptable data loss and required return time.
Recovery cycle
Copy, confirm and restore
-
Copy Move data away from the failure point
Off-node copies reduce physical and operational concentration.
-
Verify Integrity needs to be demonstrated
The presence of a file says nothing about its content; the hash does.
-
Restore Return requires order and criteria
Data, application and dependencies return in a planned sequence.
Acceptable loss and return time are different decisions
The recovery point describes how far data may need to go back; recovery time describes how long the operation can wait. Copy frequency, retention and restoration methods depend on those objectives.
Not every system has the same criticality. Defining priorities prevents one generic rule from being applied to data with different rhythms and consequences.
Distance and integrity serve different roles
Keeping a copy away from the production node protects against local failures, and distributing across providers reduces concentration on one vendor. Access control, retention and verification still apply in both cases.
Project copies already leave the production node. Distribution across providers is being implemented and will be considered complete after a tested restore from the second provider.
Restoration must rebuild a trusted condition
Restoring involves matching structure, data, permissions and dependencies, with the application validated before it returns to use.
The test shows the real return time and the dependencies left out. The result becomes documentation and priority for the next cycle.