Nobody gets excited about backups, right up until the day they need one. Then it is the only thing that matters. If your business depends on a system, you need to know, in plain terms, what happens when it breaks.
Backup and recovery are different things
A backup is a copy of your data. Recovery is getting back to a working system using that copy. Many businesses have the first without ever having proved the second. A backup that cannot be restored is worth nothing.
The 3-2-1 idea
A widely used rule of thumb: keep three copies of important data, on two different types of storage, with one copy somewhere else entirely. The point is that no single event, such as a hardware failure, a mistake, a fire or an attack, can take out everything.
Two questions that shape everything
How much data can we afford to lose? If the system fails at 3pm, can you live with losing everything since last night's backup, or do you need it to be much more recent? This is sometimes called the recovery point.
How long can we be offline? If it fails, is an hour acceptable? A day? This is the recovery time. Faster recovery generally costs more.
Answering these in business terms lets your developer and host design something proportionate.
What needs backing up
- The database, where your information lives.
- Uploaded files, such as documents and images.
- Configuration, so a new environment can be rebuilt quickly.
- Code, kept safely in version control.
Test your restores
This is the step most businesses skip. Periodically restore a backup into a test environment and check that it works and that the data is complete. The first time you try should not be during an emergency.
Protect the backups themselves
Ransomware and attackers often target backups too. Keep at least one copy that cannot be changed or deleted by the normal system, and restrict who can access backup storage. Encrypting backups protects personal data if they are ever exposed (see our GDPR checklist).
Know who is responsible
Is it your developer, your host, or you? Many incidents happen in the gap where each assumes the other has it covered. Write down who does what.
Questions to ask your developer or host
How often are backups taken? Where are they stored? How long are they kept? When was a restore last tested? How long would recovery take? Who do I call?
A simple quarterly check
Once a quarter: confirm backups ran, restore one to a test environment, check the data, and record the result. Ten minutes of dull checking can save a business.
Backups are part of security basics and of how we plan every project. See our approach, or ask us about reviewing yours.