A backup is only useful if you can restore it.
Ask about coverage, retention, access, and recovery conditions before you need them. “Backups included” is the beginning of the conversation.
Document research and editorial guidance. No hands-on hosting tests were performed for this guide.
Define what must come back
A website may contain files, a database, uploaded media, mailboxes, scheduled jobs and configuration. A backup of one does not prove coverage of the others. Make an inventory, including anything stored outside the hosting account. Ask whether the backup includes your entire account or only selected services.
Think about the site as a working system. Restoring yesterday’s application files beside today’s database can create inconsistencies. For a shop or booking service, the recovery plan must consider transactions and external systems as well as whether the homepage loads.
Frequency and retention are different
Frequency describes how often a recovery point is created. Retention describes how long it remains available. A daily backup with a short history may be insufficient if you discover corruption weeks later. Record both values and check whether the history changes when your account exceeds a size or file-count limit.
As a provider-published example, Hostinger’s backup documentation describes weekly automatic backups on web and cloud plans and additional daily backups for Business or higher plans. That is not a guarantee for every product or future contract. Verify the exact plan and its current recovery options. We have not restored a Hostinger backup as part of this research.
Find out who can restore
Ask whether you can download a backup yourself, whether restoration is self-service, and whether staff intervention costs extra. Find out whether you can restore one database or file instead of replacing the whole site. Check whether starting a restore overwrites the current state and whether you can make a fresh copy first.
Credentials and access matter too. If the only backup is reachable through an account you can no longer access, it may not help with that particular incident. Keep recovery instructions and account recovery arrangements somewhere you can reach independently.
Keep a separate recovery path
Our editorial recommendation is to keep a separate copy of business-critical data under your control, with access appropriate to its sensitivity. Hetzner’s terms explicitly place responsibility for regular external backups on the customer. Provider snapshots can be convenient, but convenience and independence solve different problems.
Choose a storage destination and retention policy suited to the data. Do not copy passwords or customer information into an unprotected public folder. A backup process should include encryption where appropriate and a clear way to retrieve the required keys.
Rehearse before an incident
Restore into a separate, private environment rather than overwriting production as an experiment. Verify that the application starts, that representative pages and records are present, and that access controls still work. Stop outgoing notifications or payment integrations in a test environment. Record the date, recovery point and steps used.
A rehearsal establishes something about that backup and procedure on that date. It does not prove every future copy will work. Repeat after meaningful application or hosting changes. If a provider cannot explain retention or restore conditions, keep those fields marked unknown and decide whether that uncertainty is acceptable before buying.
Sources
Related reading
- SSD or NVMe? Look beyond the storage label.
- WordPress or a custom app? Start with the runtime.
- Shared, managed, or VPS: who does the work?
- The real cost of hosting starts at renewal.
Reader discussion
No published contributions yet. Thoughtful questions and useful answers are welcome.