Prerequisites
- An inventory of application data
- A separate backup destination
- A person responsible for restore testing
Security note
A snapshot on the same account is useful but is not the only backup you should keep. Protect at least one recoverable copy from server and account-level incidents.
Step 1
Define recovery objectives
Choose the maximum tolerable data loss and recovery time. These decisions determine backup frequency, retention, and restore design.
Step 2
Inventory stateful data
List databases, uploaded files, configuration, secrets, certificates, scheduled jobs, and external dependencies. Rebuildable operating system files usually need a different retention strategy.
Step 3
Create independent copies
Store backups outside the source server. Use access controls, encryption, retention, and deletion protection appropriate to the data.
Step 4
Use application-consistent methods
Databases and active applications may need a dump, quiesce, or vendor-supported backup process before filesystem capture.
Step 5
Automate verification
Alert when a backup is missing, unexpectedly small, too old, or cannot be read. A successful job exit is not proof that the data can be restored.
Step 6
Run restore tests
Restore into an isolated environment, verify application behavior and data freshness, record the time required, and update the runbook after each test.
Troubleshooting
- Backups complete but restores fail
- Check consistency requirements, encryption keys, dependency versions, and whether the restore procedure includes configuration and secrets.
- Backup storage grows without bound
- Apply documented retention tiers and monitor capacity. Never delete the only known-good recovery point during cleanup.
Frequently asked questions
Is a VPS snapshot enough?
A snapshot can speed recovery, but independent backups and tested application-level restores provide protection against a broader set of failures.