What to know
- Define acceptable data loss and downtime before choosing a schedule.
- Keep a protected copy outside the production server’s failure boundary.
- Test a restore without sending real emails or triggering payments.
Start with two business questions
How much recent work could the business afford to lose, and how long could the website remain unavailable? These become your recovery point objective (RPO) and recovery time objective (RTO). The AWS recovery-objectives guidance explains why they should reflect the workload rather than an arbitrary backup schedule.
For example, a daily copy may be unsuitable for an order system that cannot afford to lose a full day of transactions. A brochure site with infrequent edits can have a different target. These are planning examples, not promises about a particular hosting plan.
List everything a working site needs
Include application files, uploaded media, database records and the configuration required to reconnect them. Document scheduled tasks and any external services used by the application. Keep secrets protected; a backup containing credentials needs access controls too.
For a changing database, use a backup method that produces a consistent recovery point. Copying a live database file without understanding its engine can create an archive that looks complete but cannot support a dependable restore.
Separate the backup from the failure
A copy stored only on the same server shares important failure risks with the site. The CISA StopRansomware guide recommends offline, encrypted backups and regular testing. Depending on the storage service, an isolated or immutable copy may form part of a broader plan; check who can delete it and how recovery credentials are protected.
Understand what your hosting backup can restore
With cPanel, full-account and partial backups have different restoration workflows. The cPanel backup documentation notes that automatic full-account restoration is handled through WHM or the provider rather than the ordinary cPanel interface. Confirm retention, available restore points, storage limits and who performs the restore.
Before you need a recovery, ask whether databases, mail and uploaded files are included, and whether there is a charge or response window for provider-assisted work.
Run a drill away from production
- Choose a backup and record its timestamp.
- Restore into a private, isolated environment.
- Prevent outgoing customer mail, payment calls and scheduled jobs from running accidentally.
- Check database consistency, uploaded files, sign-in and a representative workflow.
- Measure the elapsed recovery time and compare it with the target.
Record the person responsible, missing dependencies and any manual step. Repeat the drill after important application changes, not only after the first installation.
When does a backup count as ready?
A useful completion record includes a successful restore, a known recovery point and an owner who can access the tools. The existence of an archive alone is not that record. Keep backup monitoring separate from the site so a server outage does not hide a failed backup.
Review Kiava hosting options and discuss your recovery requirements with our IT team. Confirm the agreed backup and management scope before ordering. For server access and maintenance, continue with the VPS security guide.
Sources & further reading
Primary sources supporting this article. The practical recommendations are Kiava’s general guidance and should be adapted to your project.