Almost everyone has backups until the day they need them. Then they find out the copies were on the very server that just failed, that nothing had been generated for months, or that nobody knows how to restore them. A website can be lost to a hosting failure, a bad update, an attack or a simple accidental deletion.
The good news is that setting up a reasonable backup system isn't complicated. You only need to decide four things: what to save, how often, where, and how to check it works.
What to save
Think of everything you'd lose if your server vanished tomorrow. First, the site's files: the code, the design and above all the images and documents you've uploaded, which are usually the hardest to rebuild. Second, the database, if your site has one (WordPress and almost all online stores use one): that's where pages, products, orders and users live.
Third, email, if it's hosted on your domain, since it often holds invoices and conversations with customers. And fourth, what tends to be forgotten: a document with your domain setup and DNS records, and a list of where everything is, so you can rebuild without guessing. Keep passwords in a secure manager, never inside the backup.
How often
The rule is simple: frequency depends on how much you're willing to lose. If your corporate site is updated once a month, a weekly backup or one after each change is enough. If you run an online store that receives orders daily, the database should be copied daily or even more often, because losing a day of orders means losing money and customer data.
Also keep several older versions, not just the latest. If a problem goes unnoticed for a few days, the most recent copy will already contain it, and you'll need to go back to an earlier one.
Where to keep them: the 3-2-1 rule
It's a classic, easy-to-remember guideline: 3 copies of your data (the original plus two copies), on 2 different types of media or locations, with 1 of them away from your usual place. For example: the live site, an automatic copy on the hosting itself, and another in independent cloud storage or on a drive you keep elsewhere.
If the copies contain customer data, protect them: encrypted or with restricted access, and delete old ones when they're no longer needed.
Why a copy on the same server isn't enough
It's the most widespread mistake. If the backup sits on the same server as the site, anything that hits the server takes both: a disk failure, an attack that encrypts or wipes everything, a provider error or a suspended account. An attacker with access to your hosting can also delete the backups sitting next to it.
A local copy is useful for recovering quickly from small mistakes, such as a file deleted by accident. For real disasters you need an external copy, with another provider or on another medium, using credentials different from your hosting's.
How to check they can really be restored
A backup you've never restored is a hypothesis. At least a couple of times a year, and always after changing hosting or system, run a test: restore the copy in a separate environment (a test subdomain or a local server), never on top of the live site. Then check that pages and images display, that forms and the admin login work and, if it's a store, that products and recent orders are there.
Write down the steps and how long it takes. When an emergency comes, having the procedure written down saves hours of stress. Also check that the automatic copies are still being generated: an error alert by email, or a monthly look at the size and date of the latest backup, catches silent failures.
Frequently asked questions
My hosting already makes backups, do I need anything else?
It's worth knowing the details: how often it makes them, how many it keeps, whether you can restore them yourself and whether they're stored away from the main server. Even if they're good, it's prudent to hold your own external copy, because depending on a single provider is a risk.
Are automatic backups enough?
They're the foundation, since manual ones get forgotten. But you need to watch that they keep working and test now and then that they can be restored.
What if my site has no database?
Then copying the files is enough. It's simpler, but the same ideas apply: a copy outside the server, several versions and a restore test.