Picture a shop owner whose backup job ran every night for two years. The day the server died, he opened the backup folder and found nothing but empty files. For two years the backups ran on schedule and saved nothing. It can happen to anyone who has never tested a restore.
That is the lesson. Having a backup is not enough, you must be sure you can restore it. This post explains how to back up a website safely, in words anyone can follow.
Why back up at all
Think of an important notebook. If you only have one and you spill water on it, everything is gone. If you photocopy it and keep the copy in the same drawer, a house fire takes both. The sure way is several copies in different places.
A website is the same. It can be lost to a broken server, a hack, an accidental deletion, a bad update or a problem at your hosting company. A backup is the only way to put everything back in those moments. If the site was attacked, a clean backup is also the fastest way out, as I described in Website Hacked: How to Spot It and What to Do in the First 24 Hours.
The 3-2-1 rule
This is a simple rule people in the field use, easy to remember.
3 copies of your data: the live one plus two backups. 2 different kinds of storage, for example the disk on your server and a separate storage service, because one kind can fail together. 1 copy far away, meaning a different location from the main server, so that if the whole data center has trouble or your hosting account is locked, you still have a copy.
The reason for the off-site copy is practical. If an attacker gets onto your server and deletes everything, a backup sitting on that same machine is deleted too. Only a copy somewhere else survives. The UK's National Cyber Security Centre (NCSC) describes a backup the same way: a copy of your data kept in a separate, safe location, apart from the original.
What to back up
A website usually has two parts, and you need both.
The first is the files: source code, theme, uploaded images, configuration files. The second is the database, where posts, products, orders and customer accounts live. On WordPress, backing up only the files loses all your content, and backing up only the database loses images and design. The official WordPress documentation also stresses backing up both the database and the files.
Do not forget what sits around the site: server configuration, security certificates, and notes on how to rebuild (where the domain is registered, which service handles email). These are easy to forget until the day you need them.
How often
Ask yourself: if I lose today's data, how much am I willing to lose at most? The answer decides the frequency.
A brochure site that rarely changes: once a week is enough. A blog that posts a few times a week: daily. A shop with constant orders: back up the database several times a day, or record every change. Also back up right before any major update, since updates are when things tend to break.
Keep several versions, not just the latest. If malware sat in the site for 10 days before anyone noticed, yesterday's backup is infected too. A chain of daily, weekly and monthly copies lets you go back to a moment when the site was clean.
Test your restore: the most important part
A backup that has never been restored is not yet a backup, it is a hope. The story at the top is an illustration: the files existed, but nobody checked.
A simple routine: every quarter, or at least every six months, take the latest backup and rebuild it as a test site somewhere else (a separate address, not your live site). Open it and check what matters: does the homepage load, can you log in to admin, do the images show, can you place a test order. Time how long it takes. That number tells you how long your site would be down in a real incident.
Write the restore steps as a short document anyone can follow, even when you are not around. The moment you need it most is usually the moment you are panicking.
Backup plugins: what to look for
For WordPress there are many backup plugins. When choosing, look for these: it backs up both files and database, it runs on a schedule, it can send copies off the server, it keeps several versions, and it has a clear way to restore.
I also built my own backup and migration plugin, SL Migrations. It packs files and database into one package, runs on a schedule, keeps packages on the server and pushes them to another machine over FTP or SFTP. It does not connect directly to cloud storage such as S3, so if you need that, pick another tool. I mention it so you can see one concrete approach, not to push you to use it.
Whichever plugin you use, do not trust only a "backup successful" message. Test a restore as described above.
For those who write code
If you build backups yourself for your own server, the basic idea is a few steps: export the database to a file, compress it with the web folder, check that the archive is intact, then copy it elsewhere.
mysqldump --single-transaction db_name | gzip > db-$(date +%F).sql.gz
tar -czf web-$(date +%F).tar.gz /path/to/site
gzip -t db-$(date +%F).sql.gz && tar -tzf web-$(date +%F).tar.gz > /dev/null && echo OK
The last check only proves the archives are readable, not that the data is right. You still need a real restore test. Keep the database password in a separate config file instead of typing it into the command.
Common mistakes
The most common one is storing the backup in the same place as the site. When the server dies, both go. The second is a backup job that runs fine but fills the disk, so a few months later it silently stops. Turn on a notification for failed backups. The third is keeping only the latest copy and overwriting the older one every night.
What to do next
This week, open wherever your backups live and answer three questions: when is the newest one, where does it sit outside the server, and when did you last test a restore? If any of those makes you hesitate, that is your first job. If you want someone to set up backups and restore testing for your site, message me.
