No way back

Ask any team whether they have backups, and they'll say yes. Ask when they last restored one, and often nobody knows. A backup is a copy of the data, kept for the day the data is lost. It only proves that it works on the day you put it back. That's a restore.

Backups fail silently. Take a wedding photographer whose site holds a private gallery for each couple. The hosting made a backup every night. When a plugin update deleted the galleries, the photographer asked for a restore, and learned three things. The backup held the pages, but not the photos, which were stored on another service. The newest copy that worked was four months old. Since a disk had become full, every nightly backup had been saved as an empty file, and nobody was told. And nobody knew how to put it back, so it took four days.

None of this shows until you try. So a backup counts only once someone has restored it, on a copy rather than on the live site, and checked that everything came back. This is a restore test. Ask when the last one happened, how long it took, and what was missing. Then repeat it every few months, because what the site stores keeps changing.

The lesson What keeps running asked this as one question at the handover. This lesson looks at what lies behind it.

The example below shows the photographer's backups twice. On the left is what the hosting's backup page said before the problem: everything looked fine. On the right is what a restore test would have shown, months earlier.

A backup protects you only from what it doesn't share with the original. A copy kept next to the original is lost with it.

Think of a sports club that keeps its member database on the treasurer's laptop, and copies it every week to a USB drive. The drive travels in the same bag. When the bag is stolen on a train, both are gone. A copy on the same server has the same weakness: a disk failure, an attack or a mistake that deletes the server takes the copy too. In March 2021, a fire destroyed one of OVHcloud's data centres in Strasbourg. Some customers lost their sites for good, because their backups were in the same place.

Accounts work the same way. If every copy sits with the same provider, in the same account, then a hacked, closed or unpaid account takes them all.

Attackers know this. Ransomware locks an organisation's data and asks for money to unlock it, and the attackers search for the backups first. So at least one copy must be out of their reach: with another provider, in another account, or offline.

Two common tools are not backups at all. A synced folder, such as Dropbox or Google Drive, copies every change to every device, so a deleted or locked file is deleted or locked everywhere. And an online tool that keeps your content on its servers protects its own disks. It doesn't protect you from your own mistakes, or from losing the account.

A common rule sums this up: 3-2-1. Keep three copies of the data, on two different kinds of storage, with one of them in another place.

Problems are rarely noticed on the day they start. A wrong import, a deleted folder or an attack can stay unnoticed for days or weeks. So the question isn't only "do we have backups?" but also "how far back do they go?".

Take a music school's website. A cleaning tool deletes the teachers' photos by mistake. Nobody looks at the teachers' page until a parent asks, sixteen days later. The host keeps one backup a day, for seven days. Every backup that still exists was made after the mistake, so the photos are gone. With a month of backups, they would have come back in minutes.

So ask how many days of backups are kept, and compare that with how long a problem could stay unnoticed.

Then ask how often a backup is made. That depends on how much data the organisation can afford to lose. For a site whose content changes once a month, a weekly backup loses little. For a shop that takes orders all day, a backup every night means losing up to a day of orders. Is that acceptable, or must it be every hour? This is a business decision, so ask the manager, not only the developer. Teams call the answer the RPO.

Last, make sure that someone receives an alert when a backup fails. Otherwise, a backup that stopped in March may stay unnoticed until the day you need it.

Many data losses happen during a planned change, not an attack. Switching to a new payment provider, changing the site's address, running a script over every account, deleting "old" records with one click: each of these can go wrong, and some can't be undone.

Take a city library that wants to merge 4,000 duplicate reader accounts with one script, the evening before the university term starts, when thousands of students will log in. Before you say yes, ask for two things.

First, a fresh backup, made just before the change and checked, not last week's. Without it, a failed merge loses every loan and reservation since the last good copy.

Second, a way back. If it goes wrong, what exactly do we do, who decides, and how long does it take? Agree in advance on what "it went wrong" looks like, such as readers who can't log in. Then the team undoes the change, instead of trying to fix it on the live site for hours.

Then make the risk smaller. Try the change where it can't hurt: on a copy of the data, often called staging, and then on a small part first. Merge 50 accounts, check them, then do the rest. Choose a quiet day, when people are around to watch and fix it, not the evening before the busiest week of the year. And right after the change, check what matters most. Here, that's logging in, borrowing and reserving.

For your portfolio, the way back is simpler. Before the agent rebuilds a whole page, make sure the last version is saved as a commit, and that the host keeps the previous version online. The lesson Following the work shows how.

Ask these questions when you become responsible for a site, before any risky change, and again every few months.

When someone tells you that backups exist, ask when one was last restored, how long it took, and whether everything came back: the pages, the database, the photos and the settings. If nobody knows, ask for a restore test on a copy, with a date. Until a restore has worked, the backups are only a hope.

Ask where each copy is: on the same server, with the same provider, in the same account, or somewhere else. Ask how far back the backups go, and how often they run. Then ask the manager how much data the organisation can afford to lose, a day or an hour, and check that the backups match. Ask who receives the alert when a backup fails.

Before any risky change, ask for a fresh backup, a written way back, and a trial on a copy or on a small part. Ask who checks the important paths right after the change, and who decides to undo it.

For your portfolio, your code is on GitHub, and the host keeps old versions. But where else are your photos, your CV and your form's messages? Keep a copy of your content folder somewhere other than your laptop.