How to Back Up Your Website Properly (and Actually Restore It When You Need To)

A website backup is the one thing nobody thinks about until the day it is needed — and on that day, it is the only thing that matters. A bad update, a hacked plugin, a hosting account problem, or one wrong click can take a site down in seconds. A good backup puts it back in minutes. This guide covers what to back up, how often, where to keep it, and — the part most people skip — how to make sure the backup actually works.

What a complete website backup actually includes

A backup that only copies half your site is not a backup. A complete backup has two parts:

1. Your website files — everything in your hosting account's public folder: your theme and plugins, uploaded images and documents, any custom code, and configuration files. For a WordPress site this is the whole public_html folder (or the folder your site lives in).
2. Your database — for WordPress and most other sites, the database holds your posts, pages, comments, settings, user accounts and orders. Files without the database give you an empty shell; a database without files gives you content with nothing to display it.

If your host's backup tool only saves one of the two, it is not a complete backup. Check what it actually includes before you trust it.

Also note the things that live outside those two parts: email accounts and forwarders, DNS records, subdomains, and scheduled tasks (cron jobs). A full site restore will not bring back an email account that was never backed up, so write those settings down separately.

How often should you back up?

The right frequency depends on how often your site changes:

• Daily — if your site changes every day: an online store taking orders, a blog publishing daily, a news site, or any site with user registrations or comments. Losing a day of orders or posts is expensive.
• Weekly — if your site changes a few times a month: a business site with occasional page updates, a portfolio, a brochure site. A weekly backup loses at most a week of small changes.
• Before every change — regardless of schedule, always take a backup before updating your theme, plugins or core software, before installing anything new, and before making any big edit. Most site disasters happen within an hour of a change, and a fresh pre-change backup is the fastest way back.

If your host offers automatic daily backups, that is a good safety net — but it should not be your only copy. Keep reading.

The 3-2-1 rule: never keep your only backup on the same server

The most common backup mistake is keeping the only copy on the same hosting account as the site itself. If the server fails, the account is suspended, or the site is hacked, the backup on that same server can be lost or corrupted with it.

A simple rule professionals use is 3-2-1:

• 3 copies of your data in total (the live site counts as one, plus two backups).
• 2 different places — for example, one copy with your host's automatic backups and one copy downloaded to your own computer or cloud storage.
• 1 copy off-site — at least one copy somewhere completely separate from your hosting account: your own computer, an external drive, Google Drive, Dropbox, or any storage that does not depend on your host being up.

For most small sites this is easy: let the host keep its automatic daily backup, and once a week download a full backup (files + database) to your own computer or cloud drive. That second copy costs you five minutes a week and covers the scenario your host's backup does not.

How to take a backup (three routes)

• Your host's backup tool (easiest). Most hosting accounts with cPanel have a backup feature, and many hosts run automatic daily backups you can restore from in one click. Check whether your plan includes them, how many days back they go, and whether restoring is free or charged.
• A backup plugin (WordPress). Backup plugins can schedule automatic backups, send them to cloud storage, and restore with a few clicks. Pick one with a good track record and recent updates, and check that it backs up both files and database. A plugin is only useful if it is configured — install it, set the schedule, and confirm the first backup actually lands in your storage.
• Manual backup (most control). Download your files with FTP or your hosting file manager, and export your database from phpMyAdmin. It takes longer, but you know exactly what you have, and it works on any kind of site, not just WordPress.

Whichever route you pick, make sure the backup is a complete one — files plus database — and that you know where it is stored.

The step everyone skips: test the restore

A backup you have never restored is a hope, not a backup. Backups fail silently all the time: an export that stopped halfway, a database file that is empty, a compressed archive that is corrupted, a plugin that quietly stopped running months ago.

Test your backup at least once, and then every few months:

1. Check the file exists and has a sensible size. A backup of a real site is rarely a few kilobytes. An empty or tiny file means the backup failed.
2. Open the archive. Make sure it unzips without errors and that it contains both the files and a database export.
3. Restore to a staging copy, not your live site. If your host offers a staging area or a test subdomain, restore the backup there and check that the site loads, pages open, and the login works. That is the only real proof the backup is usable.
4. Check the date. A backup from six months ago restores a six-month-old site. If your last backup is older than your last important change, take a fresh one now.

If the restore test fails, you have found the problem on a quiet day instead of discovering it during an emergency. That is the whole point.

Common backup mistakes

• Keeping the only copy on the same server. The backup disappears with the problem it was meant to fix.
• Backing up files but not the database (or the reverse). Half a backup restores half a site.
• Never checking whether the automatic backup actually runs. Plugins get disabled, schedules break, storage fills up. A monthly glance at the backup list is enough.
• Overwriting your only good backup with a broken one. After a hack or a bad update, do not let the next automatic backup replace the last clean one. Keep at least one known-good copy aside before you start fixing things.
• Backing up everything except the things you need. Email accounts, DNS records and subdomains are not in a standard website backup. Write them down.

A backup routine you can actually keep

• Daily automatic backup from your host, if your plan includes it.
• A manual full backup (files + database) downloaded to your own storage once a week, or before any major change.
• One restore test every few months on a staging copy.
• A note of your email accounts, DNS records and subdomains stored separately.

That routine takes a few minutes a week. The day you need it, it is worth every one of those minutes.

Disclosure: I write about hosting and I am connected with ZedgeHost, a web hosting company in Pakistan — its shared plans start at Rs 1,499/year at zedgehost.com, and daily backups are included. The routine above applies whichever host you use: keep a copy off the server, back up files and database together, and test a restore before you need one.