Back to Blogs
Most website owners only think about backups on the day something goes wrong. A plugin update breaks the layout, a hacked file starts redirecting visitors, someone deletes a page by mistake, or the hosting account gets suspended over an unpaid invoice. On that day, the only question that matters is whether there's a recent copy of the site that actually works.
I've had clients come to me after losing months of work because the only backup was the one the host said it was taking. So on every site I build or look after, I set up backups the same way. None of it is complicated, but each part covers a gap the others leave open.
What a backup has to include
A website is more than its files. When I say a site is backed up, I mean all of these are copied:
- The files: the code, the theme, and the uploads folder with every image and PDF the client has added.
- The database: pages, blog posts, form entries, orders, users and settings. On a WordPress site or a PHP site with an admin panel, this is where most of the real content lives.
- The config: the database connection file, the .htaccess rules, and any API keys the site needs. I keep these in a safe place separately, because they shouldn't sit in a public folder or a shared drive.
- Notes on the setup: the PHP version, cron jobs, DNS records and email settings. These aren't files you can copy, but rebuilding them from memory during an emergency is slow and easy to get wrong.
A backup of only the files is the most common mistake I see. The site comes back looking right, and then every blog post written in the last year is missing.
Three copies, in more than one place
I follow a simple rule: at least three copies of the site, on at least two different kinds of storage, with one of them away from the hosting company entirely.
1. The host's own backups
Most hosting plans include daily or weekly backups. I turn them on and check how many days they keep, because some cheaper plans only keep a few days or charge to restore. These are the fastest to use for a small mistake, like a page deleted yesterday. But they live on the same company's servers, so they don't help if the account is suspended, closed, or hacked.
2. Automatic backups sent somewhere else
This is the copy that matters most. For WordPress sites I use a backup plugin that sends a full copy to cloud storage the client owns, such as Google Drive or Dropbox. For custom PHP sites I set up a cron job that zips the files, exports the database with mysqldump, and uploads both to off-site storage. Either way, it runs on a schedule without anyone having to remember.
3. A copy before every big change
Before I update plugins, change the theme, move hosts or run a database change, I take a manual backup and download it to my own machine. It takes a few minutes and has saved me more than once. If the update goes wrong, I can put things back in minutes instead of hoping the nightly backup was recent enough.
How often to back up
The right schedule depends on how often the site changes. I ask one question: how much work would the client lose if the site had to go back to the last backup?
- A brochure site that changes a few times a year: a weekly backup is plenty, plus a manual one after each edit.
- A site with a blog or regular content updates: daily database backups and weekly file backups.
- A shop or a site that takes bookings or form entries: the database at least daily, often more, because orders and enquiries come in every day and can't be typed back in.
I also decide how long to keep them. I usually keep around 30 days of daily copies and a few monthly ones. Keeping older copies matters more than people expect, because a hack or a broken file sometimes goes unnoticed for weeks, and by then every recent backup has the same problem in it.
A backup you haven't restored is only a guess
This is the part most people skip. A backup file can exist and still be useless: the zip is incomplete, the database export stopped halfway, or the backup only covered part of the uploads folder. You won't know until you try to use it.
So every few months I restore a recent backup to a test copy of the site, usually on my local XAMPP setup or a staging subdomain. I check that the pages load, images show up, the admin login works, and the latest posts or orders are there. If something is missing, I fix the backup setup while nothing is on fire. It also means that when a real restore is needed, I already know the steps.
Who owns the backups
Backups should belong to the business, not to me. I set up the off-site storage under an account the client controls, and I write down where the backups go, how often they run, and how to restore one. If they stop working with me, or I'm not available on the day something breaks, another developer can pick it up from that note.
I also make sure the client has their own logins for the hosting, the domain registrar and the backup storage. A backup is no help if the only person who can reach it has disappeared.
Keep backups safe too
A backup has everything a hacker would want: the database, user emails, and sometimes passwords in the config file. So I never leave backup zips sitting in the public web folder, where anyone who guesses the file name can download them. Cloud storage gets a strong password and two-factor login. And when a backup plugin or script stops running, I want to hear about it, so I turn on its failure emails or check the storage folder as part of monthly maintenance.
A quick check for your own site
If you're not sure where your site stands, these questions will tell you:
- Where are your backups stored, and is at least one copy outside your hosting account?
- Do they include the database, not just the files?
- When was the last one taken, and how many days back can you go?
- Has anyone ever restored one to check it works?
- Can you get to them yourself, without your developer?
If you can't answer most of these, it's worth sorting out this week, before you need it. If you'd like help setting up backups for your website or checking the ones you have, you can get in touch here.
