Website backup discipline: a copy is not a backup

A backup is not a copy you own: it is a restore you have performed, timed, and survived.

Ask a business owner whether their website is backed up and the answer comes instantly: yes. Ask which restore was last rehearsed and the room goes quiet. In our experience the checkbox exists and the discipline does not, and the gap between the two is where small businesses quietly lose years of work. A website is no longer a brochure. It is the database of every order, every customer record, every page written at midnight, and all of it lives on someone else's computer until you prove otherwise.

So let us define the term honestly. A backup is a copy that lives somewhere else, is recent enough that losing the gap would not end the business, and has actually been restored at least once by someone who timed it. Remove any one of those three conditions and what you have is not a backup. It is a hope with a schedule. The nightly job that writes to the same disk as the site fails exactly when the disk does. The copy stored inside the same account falls with the account.

The subtler failures are the ones everyone believes are covered. Many owners assume whoever hosts the site handles backups completely, and some hosts do, but assumptions deserve reading rather than trust: how far back the copies go, how fast a restore happens, who is allowed to request one. And the most common failure of all is the restore that has never been tested, which stays theoretical until the day it is needed, which is the worst possible day to learn it was never real.

What deserves backing up is broader than most owners think. The site files, certainly, but also the database underneath them, because a modern site is mostly a database with clothes on. Beyond that: the content that would be painful to rewrite, the configuration that took weeks to get right, the media library, the record of who changed what. Losing code is annoying. Losing the accumulated record of your business is something else entirely, and no subscription fee brings it back.

The test that matters is simple and slightly uncomfortable: restore it on purpose. Pick a quiet day, take a real copy, and bring the site back from it on a separate environment, watching the clock. How long was the business down? What broke that the backup did not include? Who knew the steps, and are they written anywhere? We rehearse restores for our own systems precisely because a backup without a rehearsal is a claim, and we do not make claims about anything that matters until we have tested it ourselves.

Platform specifics belong with whoever actually runs your system: retention windows, storage locations, and recovery steps differ by setup, and the team operating it should document and rehearse them. Our position, as a company that runs its own infrastructure, is narrower: treat the backup as a discipline, not a checkbox. A copy somewhere else, recent enough to matter, restored at least once on purpose, with the downtime measured. That is the whole practice. It is also, unglamorously, the difference between a bad afternoon and a lost business.