Backups tend to come up at the worst moment: the host removed an account, an update broke the site, someone deleted a section in the admin panel. That is when it turns out there are no backups, or they exist but are old, incomplete, or will not restore.
The good news is that setting up backups for a small site is not hard. Below is what to copy, where to keep it, and how to make sure the site can really be brought back from it.
What goes into a backup
A site is more than files. A full backup usually has several parts:
- The code and site files, including uploaded images and documents
- The database: requests, orders, users, texts from the admin panel
- Server and environment settings: configs, variables, scheduled jobs
- A list of the accesses and services the site depends on, without plain-text passwords
The database and uploaded files are the parts most often forgotten. Code can be taken from the repository, but last month's orders exist nowhere else.
Where to keep it
A backup that sits on the same server as the site only protects against your own mistakes. If the server goes down, the account is blocked, or a disk fails, it disappears together with the site.
A well-known guideline here is the 3-2-1 rule: several copies, on different media, with at least one kept elsewhere. For a small site this can be the host's own backups plus an automatic export to separate cloud storage that the host has no access to. Choosing a host with decent backups is covered in how to choose hosting.
How often
The frequency depends on how much data you can afford to lose. A brochure site that changes once a month can be backed up rarely. A store or a service that receives requests every day should be backed up at least daily, and the database sometimes more often.
It also helps to make a backup before any noticeable change: a CMS update, a migration, a large edit. Such changes are better tried on a staging copy first anyway.
Older backups are worth keeping for a while, not just the latest one. If the site was infected or data was quietly corrupted, the latest backup may already contain the problem.
Testing a restore
A backup that has never been restored is more of a hope than protection. The archive may turn out empty, the database incomplete, and the restore steps may exist only in one person's head.
- From time to time, deploy a backup to a separate place and check that the site opens
- Check that the restored database contains recent requests and orders
- Write down the restore steps so another specialist could repeat them
- Set up an alert for when a scheduled backup was not created
A failed backup is easy to miss, so it is worth tracking the same way as site downtime. More on that in the post on site monitoring.
Backups and security
A backup holds the most valuable things: client data, database access, keys. So backup storage deserves the same protection as the site itself: separate access, two-factor sign-in, and encryption where possible. General rules are collected in small site security.
Setting up backups and testing restores are part of website support. If you want to check how things stand with your site, get in touch.