Hosting Backups: What to Ask Your Host Before You Rely on Them
Not all hosting backups are equal. Learn the questions to ask about frequency, retention, location and restores, plus how to add your own off-server backup.
"Daily backups included" appears on almost every hosting page, and it tells you almost nothing. A backup is only valuable if it contains what you need, is stored somewhere that survives the failure you are worried about, and can be restored quickly by you. Before you trust a host with your only safety net, ask a few specific questions and run one real test.
Why backups fail when you need them
Sites are lost in ordinary ways: a plugin update that breaks the database, a hacked account, a deleted folder, a failed server disk, or a mistake by an editor. In each case the question is the same: how far back can you go, and how quickly? Backup problems usually come from five weaknesses: they run too rarely, are kept too briefly, sit on the same server as the original, cover only files and not databases, or have never been tested. Each of these is something you can check in advance.
The questions to ask
How often are backups taken?
Daily is a common baseline. A blog that changes weekly can live with that. A shop taking orders all day cannot lose 23 hours of data, so it needs more frequent database backups. Match the frequency to how much work you could afford to lose, which is called the recovery point.
How long are they kept?
If the host keeps only the last two or three copies, a problem you notice after a week, such as hidden malware, may have overwritten every clean backup. Look for retention that spans at least a few weeks, and ask whether you can keep specific copies longer.
Where are they stored?
A backup on the same disk or the same server as your site protects against mistakes but not against hardware failure, account compromise or a data centre problem. Ask whether copies are stored separately from the production server, and ideally in another location.
What is included?
Confirm that backups contain website files, databases, email and configuration. Some plans back up only the web directory and treat mailboxes or large databases as exceptions. Ask about size limits, because backups of very large accounts are sometimes skipped.
Who can restore, and how fast?
Self-service restore through the control panel is far better than opening a ticket and waiting. Find out whether you can restore a single file, one database, a mailbox or the whole account, and whether restore is free. A restore fee or a queue measured in days is a hidden cost.
A quick comparison
| Question | Strong answer | Weak answer |
|---|---|---|
| Frequency | Daily or better, adjustable | Weekly, or "when we can" |
| Retention | Several weeks of restore points | One or two copies |
| Location | Separate from the live server | Same server or disk |
| Scope | Files, databases and email | Files only |
| Restore | Self-service, granular | Ticket, paid, whole account only |
| Responsibility | Clear in the terms | "Customer is solely responsible" |
The 3-2-1 idea, in practical terms
A well-known rule is to keep three copies of your data, on two different types of storage, with one copy off-site. For a website that can look like this: the live site (copy one), the host's automatic backup (copy two), and your own periodic download stored in cloud storage or on a local drive (copy three). You do not need enterprise tooling. A monthly full download of files and database, plus a manual one before any major change, covers many small sites.
Test a restore
A backup you have never restored is an assumption. At least once, before you need it, restore a copy to a test location, such as a subdomain, and check that the site works, images appear and the database is intact. Time yourself. Write down the steps while you do it, so that a stressed version of you, or a colleague, can follow them during a real incident.
- Create a staging subdomain or temporary site.
- Restore the latest backup into it.
- Check pages, forms, login and uploaded media.
- Note the time it took and any problems.
- Delete the test copy.
Special cases
Shops and membership sites change constantly. A restore from yesterday may lose orders or sign-ups, so keep order records in a system that exists outside the website, or use more frequent database backups. Email is often forgotten: if a mailbox is deleted, messages may be gone for good unless mailbox backups exist. Hacked sites need care: restoring a backup removes the damage only if the backup predates the infection and you also close the hole that let the attacker in, which means updating software and changing passwords. See our security overview for the wider picture.
Common mistakes
- Relying on a CMS plugin that stores backups in the same hosting account.
- Never checking whether scheduled backups are still running.
- Keeping backups with the same credentials that protect the live site, so one compromise exposes both.
- Forgetting that backups can contain personal data and need to be protected and eventually deleted.
Write a one-page recovery plan
Backups only help if someone knows what to do with them. Write a short plan: where backups are, who is allowed to restore, which steps come first (put the site in maintenance mode, take a copy of the broken state for investigation, then restore), and who to contact at your host. Put it where more than one person can find it. Add the login for the control panel and the registrar. A plan like this turns a panicked evening into a twenty-minute job, and it is exactly the kind of preparation that makes the difference between a minor incident and a lost week.
Backups at Zebra Hosting
Every plan runs on Plesk, which includes backup and restore tools you operate yourself, and our team can help when a restore is not straightforward. Read how it works in the knowledge base, and ask us about retention for your plan through the contact page before you order.
