Keep at least one copy of your website and business data in a place that a failure at your main host cannot reach. That is the whole idea of an off-site backup. It sounds obvious, but two well-documented incidents show how often it is missed, even by technical teams and large providers.
This article explains what happened in each case, how the simple 3-2-1 rule prevents it, and how to set up and test a backup this week, even if you are not technical.
- A backup stored in the same place or account as your original data can be lost in the same incident.
- The 3-2-1 rule means three copies, on two types of storage, with one copy off-site.
- A backup is only proven when you have restored from it. GitLab's 2017 incident shows what untested backups can cost.
- Back up the database, uploads, and records, not only the visible website files.
GitLab, 2017: Five Backup Methods and None That Worked
On January 31, 2017, an engineer at GitLab, the code-hosting company, accidentally deleted a directory on the wrong server while working on a database problem. Around 300GB of production data was wiped, and only about 4.5GB remained by the time the command was stopped. This account comes from The Register's reporting, which quoted GitLab's own live notes.
The notes showed that the backups the company expected to rely on had problems. Regular backups were producing files only a few bytes in size, the backups to cloud storage had left an empty folder, and disk snapshots had not been turned on for the database servers. The one usable copy was a snapshot that an engineer had happened to take by hand about six hours earlier, so six hours of data was lost.
The lesson is not that GitLab was careless. It was a technical company with several backup methods. The lesson is that none of them had been proven by a restore, so nobody knew they were broken until the day they were needed.
OVHcloud, 2021: When the Backup Was in the Same Building
On March 10, 2021, a fire destroyed one data center and damaged another at OVHcloud's Strasbourg site in France. Netcraft estimated that around 3.6 million websites across about 464,000 domains went offline, as reported by Goldstein Report. Some customers recovered. Others lost data permanently.
Two years later, a French court ordered OVHcloud to pay damages to two customers. According to Blocks & Files, one of them believed its backup data was stored in a separate building from its production server, but the backup system was in the same building. That is a legal dispute, and you should not read it as advice about who is at fault. But the practical lesson holds either way: a backup in the same building, or on the same account, is not an off-site backup.
A backup that sits next to your original data protects you from mistakes. Only an off-site copy protects you from disasters.
The 3-2-1 Rule in Plain Language
The 3-2-1 rule is the standard answer to both problems. It says to keep three copies of your data: the original and two backups. Store them on two different types of storage, so one kind of failure cannot take out both. Keep one copy off-site, away from your main location. Backblaze's explanation credits photographer Peter Krogh with popularizing it, and notes that Carnegie Mellon recommended it in a 2012 paper for US-CERT.
For a small business, it can look like this: your website lives on your host, a second copy sits on a different storage service, and a third copy is on an external drive you keep somewhere else. Each of the three can fail without taking the other two.
What to Back Up (It Is More Than the Website Files)
Many people save the files they can see and forget the parts that make a site work. Use this list to check what you have:
Your website files and uploads
Themes, plugins or code, and your images and downloads. Uploads are often the largest part and the hardest to recreate.
Your database
If you use a content system, your posts, pages, orders, and settings often live in the database, not in the files. A files-only backup can leave you with a shell and no content.
Customer and business records
Customer lists, invoices, email lists, and spreadsheets. Export them regularly from the tools that hold them.
Access and settings
Domain and DNS records, hosting details, and recovery codes for your key accounts. Store them somewhere safe that is not on the same machine.
The Restore Test: Proof That a Backup Works
GitLab's case makes the most important point of this article: a backup is only real once you have restored from it. A restore test does not need to be dramatic. Once a quarter, take your latest backup and use it to rebuild the site or open the data in a separate, empty place. Check that the pages load, images appear, and the latest content is there.
While you test, time the process and write down the steps. If you ever need to recover under pressure, you will be glad to have them.
A 5-Step Plan to Set Up Your Backup This Week
Step 1: List what you cannot afford to lose
Write down the site, the database, customer records, and key documents. This is your backup scope.
Step 2: Turn on automatic backups of your site
Use your host's backup feature or a reputable backup tool for your platform. Set a daily schedule if your content changes daily, and weekly if it changes rarely.
Step 3: Send one copy off-site
Store a copy with a different provider than your host, under a separate login. If you prefer a physical copy, keep an external drive in a different location.
Step 4: Keep older versions
Do not let each new backup overwrite the last. Keeping several versions lets you go back before a mistake, a hack, or a corrupted file. This also helps if ransomware encrypts your current files.
Step 5: Restore it once, then schedule a check
Do a first restore test now, and put the next one on your calendar. Set a reminder to review your backup scope whenever you add a new tool or collect new data.
Use this short checklist every month:
To keep your files reachable from any device, see our guide to cloud-first working, and to protect the accounts that hold your backups, read cybersecurity basics.
3 Mistakes That Leave You Without a Backup
Mistake 1: Trusting only your host's backups
Host backups are useful, but they usually sit with the same provider as your site. Keep your own copy with someone else.
Mistake 2: Confusing sync with backup
A synced folder mirrors changes, including deletions and encrypted files. A backup keeps older versions you can go back to.
Mistake 3: Never testing a restore
This is the GitLab lesson. An untested backup is a guess. Test it while nothing is wrong.
Make One Copy Someone Else's Problem
Disasters, mistakes, and hacks do not announce themselves. A fire, a wrong command, or a stolen password can take your main copy in minutes. An off-site copy under a separate login is the difference between an annoying day and a business-ending one.
Start with the checklist today. Turn on an automatic backup, send one copy off-site, and schedule your first restore test. Then you will know your backup works before you need it.
Frequently Asked Questions
How often should I back up my website?
Ask how much recent work you could afford to lose. If you publish or sell every day, back up daily. If the site changes rarely, weekly is usually enough. GitLab's incident lost about six hours of data, which shows how much the gap between backups matters.
Is my hosting company's backup enough?
It helps, but it is not the whole answer. It is usually stored with the same provider as your site, so keep at least one copy somewhere else under a different login.
Does cloud storage count as an off-site backup?
Yes, if it is separate from your main host and keeps older versions. Cloud storage is the most common off-site copy for small businesses.
Do I need to test restores if I back up automatically?
Yes. Automatic backups can fail quietly, as GitLab's incident showed. A test every few months is the only way to know that your backup works.
