Cloud server snapshots and backups: plan your recovery
A recovery point is useful only when you know what it contains, how long it remains available and how you would restore it. Use this guide to plan protection for a self-managed server; check which options are enabled for your server in Console.
Updated
| What to compare | Snapshots | Backup plans |
|---|---|---|
| Purpose | A disk-state recovery point before a change, or on a schedule. | Recorded backup archives under the selected plan. |
| Capacity and cost | Available snapshot slots; extra slots may cost more. | A separate subscription, subject to published availability. |
| Retention | Manual snapshots and scheduled retention follow different rules. | Frequency and retained restore points follow the purchased plan. |
| Recovery | Check the snapshot and current server requirements. | Compatible backups can replace the current stopped server disks. |
01Choose around the change you are making
Before an operating-system update or configuration change, consider a current snapshot. For a longer recovery routine, review the separately offered backup plan and retain application exports where appropriate. A snapshot is not an independent backup strategy, and neither option guarantees an application-consistent database copy.
02Leave room for scheduled snapshots
Where enabled, schedules can run daily or weekly in your chosen timezone. Keeping N automatic snapshots needs at least N+1 total slots, plus space for manual snapshots. For example, keeping three automatic snapshots needs at least four slots before counting manual ones. A full quota can prevent a scheduled run; saving a schedule does not buy extra slots.
03Check the complete cost
The server resource calculator excludes optional extras. Compare additional snapshot slots and the published backup plan separately. Backup estimates can depend on the region and configured disk size rather than the amount of guest-used space. Choosing a backup preference during server setup does not by itself purchase that backup subscription.
04Prepare for a backup restore
For an available compatible backup, review its time and the affected server. The primary account owner must stop the server, confirm the exact server name, acknowledge data replacement and downtime, and complete identity verification. Restoring overwrites disk contents and returns guest credentials to their backup state; incompatible configurations require support.
05Verify the application after recovery
A backup restore does not automatically start the server. After a successful result, inspect it and start it when appropriate, then check application startup, database health, important files and external connections. If the operation needs attention, review its recorded status and contact support rather than submitting another restore blindly.