The attributes behind your decision
- Decision input
- Measured workload
- Primary variables
- Capacity, control, operations
- Validation
- Representative testing
- Next step
- Swiss hosting privacy
Define acceptable loss and recovery time
Recovery point objective expresses how much recent data can be lost. Recovery time objective expresses how long restoration may take. These targets determine frequency, storage and procedure.
Keep independent, versioned copies
A backup on the same active server can be lost with that server. Maintain copies across an appropriate failure boundary, protect credentials and retain enough versions to recover from delayed corruption.
Back up applications as systems
Include databases, uploaded files, configuration, secrets, certificates, scheduled jobs and infrastructure documentation. Coordinate database consistency rather than copying active files blindly.
Test restoration and record evidence
Restore to an isolated environment, validate integrity and application behavior, and measure elapsed time. Update the runbook whenever the application or infrastructure changes.
Turn a recovery objective into a restore drill
If a business can tolerate losing at most one hour of data, a single daily backup does not meet that objective. If it must recover within two hours, measure how long downloading, restoring and validating the application actually takes. Backup frequency and restoration duration answer different questions.
Run a recovery exercise in an isolated environment. Restore files, database state and required configuration, then test a meaningful business action. Record elapsed time, missing dependencies and access problems. Keep at least one recovery path protected from production credentials and monitor backup failures as well as successful job completion.