Web Hosting Backups: What You Actually Need
Builder exports need their own recovery check
Record what the download contains and how you would restore or deploy it. Content, code and business-data exports may require different destination tools. Preserve design references separately and check that the saved materials cover the functions your business needs.
Our recommended rehearsal is to use the documented import or deployment procedure on a separate destination. List missing services and data before calling the export a complete recovery copy.
Compare builder content exports, code exports and backups before moving hosts.
Include external product files in the recovery inventory
If the store's files live outside the website account, ask whether the website backup includes them and how they would be recovered. Record the product version, file location and the access records needed to reconnect an existing customer's purchase.
Our recommended restore rehearsal checks an earlier customer's download and a new purchase using controlled accounts. Recovering the storefront without its product files or working access links is an incomplete business recovery.
Check hosting for digital downloads, protected delivery and separate media storage.
A backup is not merely a feature listed on a pricing table. It is a recoverable copy of the website, stored safely enough and retained long enough to help when something goes wrong. The words “daily backups” sound reassuring, but they do not tell you who controls the copy, how many restore points exist, what is included, or what a restore costs.
What a complete website backup should cover
- Website and application files
- Databases containing content, settings, users, and orders
- Uploaded images, documents, and media
- Configuration files and server rules
- DNS records and domain settings
- Email, if mailboxes are hosted on the same account
- Credentials or documentation needed to restore third-party connections
No single backup method always captures all of these. A WordPress plugin may copy the application but not the hosting account. A hosting snapshot may omit externally hosted email. The safe approach begins by knowing where each part lives.
Use the backup retention guide to verify how far back a usable copy remains available, then rehearse the procedure with our restore-test checklist.
Frequency and retention are different
Frequency describes how often a copy is created. Retention describes how long those copies remain available. A daily backup with one restore point can be less useful than several weeks of retained copies, especially when a problem is discovered late.
Match frequency to how often the site changes. A brochure site updated monthly may tolerate daily backups. A store processing orders throughout the day may need much more frequent database protection. A membership site, forum, or busy publication can lose meaningful activity even when the most recent copy is only a few hours old.
For a suspected compromise, coordinate the recovery point and cleanup before replacing live data. Our WordPress malware recovery checklist covers the incident record, ownership and verification.
Ask how restores work
The best backup interface is the one you can use during a stressful incident. Confirm whether restores are self-service, whether individual files or databases can be selected, how long a restore normally takes, and whether support must approve the request. Check if restoration is included or charged separately.
Staging restores are especially useful. They allow a copy to be inspected before replacing the live site. Without that option, download the backup and test it in a separate environment when the website is business-critical.
Keep one copy outside the hosting account
If every backup lives inside the same account, one billing dispute, security incident, accidental deletion, or provider failure can affect both the site and its recovery copies. Keep at least one independent backup in storage controlled by the website owner.
Independent does not mean forgotten. Protect the storage account with strong authentication, restrict access, encrypt sensitive data where appropriate, and remove copies according to the organization’s privacy and retention requirements.
Planning to leave the host? Download and test your independent copy before you cancel or request a refund. Our hosting cancellation and refund checklist covers the domain, email, billing, and service-end steps that belong alongside the backup.
Common backup gaps
- Backups exist, but nobody has tested a restore. A corrupted or incomplete copy is discovered only during an emergency.
- The retention period is too short. Malware or a broken change remains unnoticed until every clean copy has expired.
- Email is missing. The website is restored, but mailboxes stored on the hosting account are not.
- The domain is not documented. Site files are safe, but nobody can quickly change DNS or verify ownership.
- The backup depends on the live site. A plugin dashboard becomes inaccessible when WordPress fails.
A practical backup schedule
For an ordinary small-business WordPress site, a reasonable starting point is an automated daily application backup, multiple retained restore points, and a separate periodic copy outside the host. Increase frequency when orders, memberships, user submissions, or frequent publishing make data loss more costly.
Before a major update, migration, redesign, or plugin change, create an additional manual restore point. Keep it until the change has been tested on desktop and mobile and the site has completed its normal business processes.
Run a restore test before you need one
A successful backup notification proves that a job ran; it does not prove your site will work after a restore. Ask whether the host can restore a point into staging or another isolated location so the test does not overwrite current orders, posts, or form submissions. If staging is unavailable, ask for a downloadable copy and a documented way to test it separately.
- Choose a restore point and record its date and time. Note what changed on the live site afterward.
- Restore files and the matching database into the test location. Check that the home page, a deeper page, images, login, and a representative form or application workflow work there. Use test data for the workflow.
- Confirm that email, DNS, payment connections, and other external services are documented separately; a site backup may not include them.
- Record how long recovery took, what was missing, and who had access to the copy. Repeat after a major site change or a change in backup service.
Two useful targets are recovery point (the point in time to which you need the data restored) and recovery time (how quickly service needs to return). For a store, a daily copy can still leave many hours of orders and customer changes outside the restore point. Decide how much loss and downtime the business can tolerate, then choose backup frequency and a restore process that fit those limits.
Retention, downloads and the real cost of a restore
Before you compare two “daily backup” promises, write down how many copies remain available, whether you can download one, whether email is included, and whether replacing a live site requires an add-on or support request. A restore point is useful only if it predates the problem and you can still access it when you need it.
For example, SiteGround’s backup documentation states, as checked October 14, 2026, that its standard service keeps up to 30 daily copies on shared hosting and up to seven on Cloud. Its standard service includes restore options for those copies; one-click downloads require Premium Backup. A separate deleted-site recovery guide says post-deletion restoration is a paid support request and lists retention of up to 60 days on shared plans and seven days on Cloud; the guide does not give a dollar fee. Treat that as distinct from restoring an available copy on an active account, and ask for a current quote before deleting a site. Deleting a site removes access to the standard copies in the account; the paid post-deletion support restore is a separate recovery path. Keep an independent copy off-site before cancellation.
Hostinger’s restore guide, checked October 14, 2026, explains that a full WordPress restore replaces both website files and the database. It says restoration usually takes 10–15 minutes, depending on site size; a partial file restore may require restoring the matching database separately to the same date. If you restore just the site files, check whether the matching database also needs restoration. Its exclusions guidance says that archives created by certain third-party backup plugins are skipped in its automated backups; save any plugin-made copy you depend on separately.
Those are examples, not guarantees for every plan. Ask a prospective host: “For this exact tier, how many daily and manual points do I get; can I download them without an add-on; do email and staging count; can I restore a copy away from the live site; and what charges apply?” If the site takes orders or collects submissions, test what happens to changes made after the restore point before pressing the button.
How to compare hosts on backups
- Identify the backup frequency for the exact plan.
- Find the number of retained restore points.
- Confirm whether restores are self-service and included.
- Check whether files, databases, email, and account settings are covered.
- Ask whether a downloadable or off-site copy is available.
- Read the provider’s statement explaining that customers remain responsible for their own data.
Use these questions alongside our hosting-with-daily-backups shortlist and hosting-features guide. A backup claim earns trust only when the restore process is clear.