A website backup strategy that works has three parts: back up everything needed to rebuild the site (files, database, configuration and email), keep copies in more than one place, and test restoring them regularly. Most businesses that lose a website did have "backups"; they just discovered too late that the backups were incomplete, stored on the same server, or impossible to restore.
This guide gives you a practical plan you can apply whether you run WordPress, a Next.js app or a classic PHP site.
Why backups fail when you need them
Before building a plan, it helps to know the usual failure modes:
- Backups on the same server as the site. If the server fails or the account is compromised, the backups go with it.
- Files but no database (or the other way round). A WordPress site without its database is just a theme.
- Nobody noticed backups stopped. A full disk or changed password quietly broke the job months ago.
- Only one recent copy. Malware or a bad update was introduced weeks ago, and every backup kept contains it.
- Never tested. The archive is corrupt, or nobody knows the steps to restore it.
The 3-2-1 rule
The classic rule is a good starting point:
- 3 copies of your data: the live copy plus two backups.
- 2 different types of storage or systems, for example your host's backup system and a separate cloud storage account.
- 1 copy off-site, away from the live server and ideally under a different account, so one compromised login cannot delete everything.
For a small business, a realistic version is: your host's automatic backups, plus a periodic download or sync of important data to storage the business controls.
What to back up
| Item | Why it matters | Notes |
|---|---|---|
| Database | Orders, customers, posts, users, settings | The most important and most frequently changing part |
| Uploaded files | Images, documents, product photos | WordPress wp-content/uploads, app upload folders |
| Code | Themes, plugins, custom code | For apps deployed from Git, the repository is your code backup |
| Configuration | Environment variables, server settings, cron jobs | Keep a secure record of environment variables and secrets |
| Mailboxes, contacts, calendars | Often forgotten, and often the most painful loss | |
| DNS records | MX, SPF, DKIM, subdomains | Export or document your zone |
| Domain details | Registrar login, renewal dates | Losing the domain means losing everything else |
For apps deployed from Git, code lives in your repository, so focus backups on the database, user uploads and environment configuration. Never store user uploads only on an app server's local disk if it may be rebuilt on deploy.
How often to back up
Match frequency to how much data you can afford to lose, sometimes called the recovery point objective:
- Brochure site that rarely changes: weekly backups plus a manual backup before any update.
- Blog or site edited a few times a week: daily backups.
- Online store or app with orders and user sign-ups: daily at minimum; consider more frequent database backups for busy stores.
Also decide how long to keep backups (retention). Keeping several weeks of history lets you go back to a point before malware or a bad change was introduced.
Always back up before changes
Take an on-demand backup before:
- Updating WordPress core, plugins or themes.
- Running database migrations.
- Changing hosts or DNS.
- Letting a new developer work on the site.
This is the backup you are most likely to need.
Test your restores
A backup you have never restored is a hope, not a plan. At least a few times a year:
- Pick a backup at random, not just the latest one.
- Restore it to a separate location, such as a staging site or a test database, not over the live site.
- Check it works: pages load, you can log in, recent content and orders are present.
- Time it. Knowing a restore takes an hour helps you plan and communicate during an incident.
- Write down the steps so someone else can do it if you are unavailable.
For a database, a simple manual export is easy to test:
# Export a MySQL database to a compressed file
mysqldump --single-transaction -u app_user -p app_db | gzip > app_db-$(date +%F).sql.gz
# Restore it into a separate test database
gunzip < app_db-2026-06-12.sql.gz | mysql -u app_user -p app_db_test
Protect the backups themselves
- Restrict access. Backups contain the same personal information as the live site. Under POPIA section 19 you must secure personal information wherever it is stored, including backups.
- Encrypt off-site copies, especially if they are stored with a general cloud storage service.
- Use separate credentials for the off-site copy, with two-factor authentication turned on. See two-factor authentication with an authenticator app.
- Keep some copies immutable or versioned, so ransomware or a malicious user cannot overwrite every version.
A simple backup plan template
| Weekly-changing site | Daily-changing site or store | |
|---|---|---|
| Automatic host backups | Weekly | Daily |
| Retention | 4 weeks | 7-30 days |
| On-demand backup | Before every update | Before every update or deploy |
| Off-site copy | Monthly download of database and uploads | Weekly sync of database and uploads |
| Backed up by the email host, plus exported archives for key mailboxes | Same | |
| Restore test | Twice a year | Quarterly |
Backups at NewHost
NewHost app hosting includes automatic backups on every plan, plus on-demand backups whenever you need one:
- Starter: weekly backups kept 4 weeks.
- Developer: daily backups kept 7 days.
- Business and Agency: daily backups kept 30 days.
Restores are done by our support team, so you are not left working through it alone. Compare the plans on our pricing page or see how managed databases fit in. For more ways to protect your site, read our website security checklist, and if you are moving hosts, how to move your website without downtime.
Frequently asked questions
Are my host's backups enough?
They are a good first layer, but keep at least one copy somewhere else under your own control. If your account is compromised or you leave the host, you still have your data.
How long should I keep website backups?
Long enough to go back before a problem you may not notice immediately, such as malware or a broken plugin. Several weeks of history is a sensible baseline for most small businesses.
Do I need to back up my email separately?
Check what your email provider backs up and how long it keeps deleted mail. For important mailboxes, a periodic export adds protection against accidental deletion.
What is the difference between a backup and a Git repository?
Git keeps your code history, which is excellent for code. It does not contain your database, user uploads or production secrets, so you still need backups of those.
How do I know if my backups are working?
Check backup dates and sizes regularly, set up alerts for failures if available, and do a real test restore to a separate location a few times a year.
Want backups handled for you? Every NewHost app hosting plan includes automatic backups and on-demand backups, with restores by our local support team. Compare plans.