Define the recovery scope
Include operational databases, object/media storage as required, model packages, scenario versions, reference data, configuration and the protected material needed to re-establish access. Treat infrastructure definitions and version manifests as part of the recovery package.
Take consistent backups
Use the database and storage tools specified for the deployment. Agree a consistent point across metadata and associated files. Keep backups private, outside the webroot, and apply retention and access controls.
Set recovery objectives
Agree the acceptable data-loss window and time to restore service. Check these against storage size, bandwidth, backup frequency and available personnel.
Test restoration
- Restore into an isolated environment.
- Verify schema and service-version compatibility.
- Check models, scenarios, assignments and reference data.
- Read event records and their media references.
- Process a representative source and confirm the operator result.
Record evidence
A successful backup job does not prove recoverability. Record restoration time, integrity checks, missing material and the corrections made to the procedure.
Master data and reproducible runtime artifacts
Master/control data and reproducible execution artifacts require different recovery strategies. If an image or model can be redistributed from a registry, document that dependency in the recovery plan; do not assume a compute node can reconstruct artifacts whose source is also lost.
Record the recovery point and any missing data. RPO is the agreed maximum data-loss window; RTO is the agreed maximum recovery time. Compare observed restore results with both objectives.