This article provides general preparation guidance. Final service recommendations depend on the actual software, data, licensing, integrations, and operating requirements involved.
A backup is useful only when it can be restored
Healthy backup planning includes a known schedule, enough retention to recover from delayed problems, and occasional restore testing. A file that exists but cannot be opened is not a recovery plan.
Snapshots and application backups are different
A platform snapshot may capture the service at one moment, while an application-aware backup can preserve databases and data in a more consistent state. The correct approach depends on the workload.
Keep important copies outside the live service
Critical worlds, databases, websites, and project files should also be retained independently by the client. Provider backups improve recovery but should not be the only copy of irreplaceable data.
Choose retention around the risk
Frequent changes may need more restore points. Stable private servers may need fewer. The advanced configurator lets you state the requested number so the final plan can be reviewed.
Never place passwords, private tokens, recovery codes, API keys, database credentials, or license keys into a public form or unverified message.