A successful backup notification is only the start
A backup is useful when it can restore the parts of your website that matter. A green status message does not tell you whether the latest uploads, database, configuration and access instructions are all recoverable. The practical question is: could someone other than the original developer bring the site back?
For example, a brochure site may need its HTML, images and server configuration. A store may also need orders, customer records and product data. A copy made before yesterday’s orders cannot recreate transactions that happened afterward.
Write down exactly what is covered
The WordPress backup handbook distinguishes database backups from website files. For a WordPress site, plan for both. Do not assume that exporting posts also preserves plugins, uploaded media or server settings.
Ask your hosting provider for a written answer to five questions: what gets backed up, how often, how long copies are kept, where they are stored and who can restore them. Also ask whether restoration is included or charged separately. The word “managed” does not answer those questions by itself.
- List application files, media, databases and configuration separately.
- Record the most recent successful copy for each part.
- Keep recovery access separate from public project documentation.
- Identify an owner who can request and approve a restore.
Run a restore rehearsal away from production
Restore a selected backup into an isolated test environment. Before opening it, disable outgoing customer emails, scheduled jobs and live payments. A restored store should not resend order confirmations or charge real customers during a rehearsal.
Open several pages, inspect images, sign in using an authorised test account and check a sample database record. Compare the restored content with the backup date. A homepage that loads is not enough evidence for a site with forms or account functions.
Write down the elapsed recovery time and any missing dependencies. These are observations from your rehearsal, not a promised recovery time for every incident.
Choose a schedule based on what changes
A monthly portfolio update and an active online shop have different recovery needs. Decide how much recent work the business could reconstruct if a copy were lost. Then compare that tolerance with the backup frequency and retention period being offered.
Before a major release, take a fresh copy and document the rollback steps. After the release, test the important journeys again. A backup protects a previous state; it does not prove that the new version works.
Use this checklist when discussing WebHolick hosting. Confirm the actual backup and restore scope in your proposal rather than assuming a particular frequency or guarantee is included.