A website backup is only useful if you can restore it, and you only find out whether you can by trying. The minimum setup for a small business site is a copy of both the files and the database, made on a schedule that matches how often the site changes, with at least one copy stored away from your host, and a test restore a few times a year. The backups themselves can run on a schedule once they're set up; the test restore is the step that's easy to put off, and it's the one that tells you the rest works.
What to back up
For WordPress, the WordPress backup documentation splits a site into two parts and says you need both to restore it fully:
- The database: pages, posts, products, orders, form entries, users and settings.
- The files: WordPress itself, plugins, themes, uploaded images and documents, and configuration files such as
wp-config.phpand.htaccess.
A backup with only one half is easy to end up with, for example when a plugin was set to skip the uploads folder to save space. Open your backup settings and check that both halves are included.
Three things sit outside the website and aren't in a site backup at all:
- Email. Mailboxes are a separate service. Hostinger, for example, lists email mailboxes as excluded from website backups. If you need old email, back it up through your email provider.
- DNS records. Save a copy of your domain's DNS zone after every change. It's a short list, and rebuilding it from memory after a mistake is slow.
- Logins and licenses. Registrar, host, DNS, premium plugin license keys. Keep them in a password manager, not inside the site.
If your site is on a hosted builder rather than WordPress, check what the platform lets you export. Some keep their own backups or version history without giving you a full copy you can take elsewhere, which matters if you ever leave.
How often
The WordPress documentation suggests weekly backups for smaller sites, daily ones for busy sites, and a backup before every upgrade. In practice, match it to what you'd lose:
| Site | Database | Files | Extra |
|---|---|---|---|
| Brochure site, edited a few times a month | Weekly | Weekly | Before every update |
| Site with a blog or bookings | Daily | Weekly | Before every update |
| Shop taking orders every day | Daily, or more often if your tool allows | Daily | Before every update and before sales or big imports |
| Any site | A downloaded copy once a month |
Ask yourself: if the site broke at 5 pm, how much would we lose since the last backup? For a shop, a day of orders and customer accounts is the number that sets the schedule.
Retention matters as much as frequency. If you only keep the last seven daily backups and a problem started ten days ago, every backup you have contains it. The WordPress documentation recommends keeping at least three to five recent backups; for a busy site, keep a few weekly or monthly ones as well as the dailies.
Where to keep the copies
Keep backups in at least two places, and one of them away from your hosting account:
- At the host. Fast to restore, which makes it the first copy you reach for.
- Off the host. Cloud storage your business owns (Google Drive, Dropbox, OneDrive, or object storage such as Amazon S3), filled automatically by your backup plugin or tool.
- Downloaded. Once a month, download one complete backup to a computer or drive you control.
The off-host copy is the one that saves you when the host itself is the problem: an account suspended over a billing dispute, a hosting company that closes, a mistake that deletes the account. Backups that exist only inside that account become unreachable at the same moment as the site.
If your backup plugin stores its archives in a folder on the same server, that's a copy, not a backup. Point it at external storage.
Test a restore before you need one
A backup tool can report "backup complete" for archives that won't open. A test restore is the only check that the whole chain works. Do it a few times a year and after you change hosts or backup tools:
- Download the latest backup from wherever you'd get it in an emergency, not from where it's convenient.
- Open the archive on your computer. If it won't unzip, or the uploads folder is empty, you've found the problem while it's cheap.
- Restore it somewhere that isn't the live site. A staging site from your host, a spare subdomain such as test.yourbusiness.com, or a local install on your computer. Never test by restoring over the live site.
- Restore in the right order. The WordPress documentation says files first, then the database.
- Check the result: the home page and a few inner pages load, images appear, you can log in, the latest blog post or order is there, and the contact form sends.
- Time it and write it down. How long it took, where each piece came from, and the steps that tripped you up. That note is what you'll follow when the live site is broken and you're under pressure.
- Delete the test copy, or block it from search engines and password-protect it if you keep it.
If the test fails, fix the backup setup now: switch on the missing half, change the storage, or change tools.
Before you restore the live site
Restoring overwrites what's there now. Hostinger's backup documentation says plainly that a restore of files or database can't be undone; check your own host's wording before you click. Download a copy of the current, broken state first, and list what changed since the backup date (orders, bookings, form entries), because the restore removes it. If the site was hacked, the hacked site guide explains how to choose a backup that predates the problem; if an update broke it, try disabling the plugin first.
Where Hostinger fits
Hostinger's backup system covers the "at the host" copy: automatic backups run weekly by default and daily on plans that include it (a daily backups add-on exists for weekly-only plans), you can restore files only, the database only or both, and you can download any backup as an archive for your off-host copy. On the entry-level plans, manual backups (one per 24 hours) need an upgrade to Business or higher. Mailboxes aren't included, and the host copy still needs a second copy elsewhere, whatever host you use.