A snapshot records a server's state at a particular time. It can be useful before a system change, but it is not automatically an independent, long-term backup. Understand where it is stored, what it includes and what happens if the server or underlying service is deleted.
IN THIS ARTICLE
01 Choose protection for the recovery you need
A whole-server recovery, an individual mailbox restore and a database recovery require different tools. For a business application, consider how much recent data you could lose and how long you can tolerate an interruption. The snapshot quantity shown on a VPS plan does not establish its retention period or replace your backup policy.
- Inventory the data: website files, databases, mail, configuration, licenses and secrets. Check whether attached storage or external services are included in the chosen backup method.
- Configure an independent backup destination with appropriate access control. Protect backups containing customer data and verify that a compromised server cannot trivially erase every recovery copy.
- Before a major change, create an application-consistent backup. Databases may require their own export or supported backup mechanism; a running-machine snapshot alone may capture an incomplete transaction state.
- Create a snapshot through the facility included with your service, if available. Record its timestamp and the change it protects. Wait for successful completion before starting the change.
- Test restoration in an isolated environment or with a representative sample. Confirm that the application can read the restored database, not just that the archive exists.
- Monitor backup jobs, available storage and retention. Investigate missing or failed backups while the live system is still healthy.
What should I check before restoring a server snapshot?
Understand that restoration can replace newer files, orders, emails and settings. Preserve the current state where possible and agree a maintenance window. Review IP assignments, attached disks and credentials after recovery. If customers have written new data since the snapshot, arrange reconciliation before reopening the application.
02 Keep a recovery record
Document how to obtain the backup, who can authorise a restore and where recovery credentials are held. Keep this record accessible when the server is unavailable. Ask support to confirm any unclear snapshot or backup limit in your service; do not wait until an incident to discover that an expected recovery point was never created.