- Identify essential files and databases.
- Know your tolerance for lost changes.
- Keep a copy independent of a single machine.
Use the seven daily recovery points
Check the selected server, completion time and recovery point before you depend on it. Seven daily encrypted points protect against everyday changes, but a daily schedule does not capture the latest minute of a busy database.
Keep an independent application export for data that would be difficult to recreate. Store the access and recovery instructions somewhere reachable when the original server is unavailable.
Snapshot before a risky change
Create a named snapshot before a major update or configuration change. Use a label such as before-app-3-2 rather than final-test. Pause writes or use the database’s own consistent backup procedure before capturing important application data.
A filesystem snapshot does not automatically make every application transaction consistent. Use the software’s documented recovery procedure for state that matters.
Restore to a deliberate target
Confirm the server and timestamp. A restore replaces the target’s disk state, so preserve newer data first. Isolate the old application while validating the restored one to avoid two copies accepting conflicting writes.
Check authentication, data writes, scheduled jobs, mail delivery and integrations. A page that loads is only the beginning of a recovery test.
Practise the complete recovery
Restore a copy in an isolated environment, time the process and check critical records. Record the steps that needed human intervention and update the runbook while the details are fresh. Repeat after a significant architecture change.
The runbook should identify the recovery source, service startup order, success checks and traffic-switch procedure.
Keep points with a purpose
Retain meaningful snapshots and remove those that no longer support a change or recovery requirement. Do not let the only data copy and its source depend on the same disk, access key or person’s memory.