Backups Aren't Simple: What 'We Have Backups' Actually Needs to Mean

Amazon Web Services recently admitted it can't restore some customer data from facilities in the Middle East that were hit during the Iran strikes. Not "it'll take longer than usual". Can't. That's one of the biggest cloud providers on earth, with more redundancy than almost any business could afford to build, telling customers that some of their data is just gone.

I bring that up not to scare anyone into overspending on infrastructure, but because it's a useful reminder that "we have backups" is a sentence that means almost nothing on its own. I've taken over enough systems from other developers, and inherited enough that nobody could fully explain, to know that the backup story is usually the weakest part of the whole setup. It gets set up once, nobody revisits it, and the first time anyone finds out it doesn't work is the day they actually need it.

The question that actually matters

Everyone asks "do you have backups". That's the wrong question. The right one is "when did you last restore from one, and how long did it take". If the answer is "never" or "I'm not sure", you don't have a backup. You have a file sitting somewhere that you're hoping is a backup.

I've seen automated database dumps that had been silently failing for months because a disk filled up and nobody was watching for the error email. I've seen backups stored in the same account, same region, same provider as the live system, so a single outage or a single compromised login takes both down together. Neither of those setups is "no backups". Both look, on paper, exactly like "we have backups".

What a working backup actually needs

A backup that will actually save you needs a few things true at once, not just one of them:

• It has to be tested. Not "the job ran without an error", but an actual restore, done periodically, checked against real data. A backup nobody has ever restored is a theory.
• It has to be separate from what it's protecting. If your live database and your backup live in the same account with the same provider in the same region, you're not protected against that provider having a bad day, which is exactly what happened here.
• It has to cover the right things. Databases are the obvious one. Uploaded files, generated PDFs, sent emails, API credentials and encryption keys are the ones that get missed. A database restore that comes back with no way to decrypt the sensitive fields inside it isn't a full restore.
• It has to have a known recovery time. If restoring means someone manually reconstructing state from three different exports, that's not a plan, it's an emergency you haven't had yet.

Point-in-time versus "last night's copy"

There's a real difference between a nightly snapshot and point-in-time recovery, and it matters more than most business owners realise. A nightly backup means if something goes wrong at 4pm, you're restoring to last night and manually re-entering everything that happened since. For a booking system, an invoicing tool, or anything customer-facing, that's a day of bookings, payments and messages that simply vanish.

Point-in-time recovery, where you can roll a database back to a specific minute rather than a specific midnight, costs more to set up and run, but it turns "we lost a day" into "we lost twenty minutes". For most of the systems I build, that's a decision worth having explicitly rather than defaulting to whatever the hosting platform does out of the box.

What this means if you're not the one who built it

If you're running software someone else built, whether that's a developer who's moved on, an agency you no longer work with, or something stitched together in-house years ago, the backup question is worth asking directly rather than assuming. Where do backups live. Who can access them. Has anyone ever actually restored one. If nobody in the business can answer that with confidence, it's not a technicality, it's a gap. I've written before about what to do when you inherit a system nobody can fully explain, and backups are usually near the top of the list of things to check first, because it's the one failure that isn't recoverable after the fact.

What I actually set up

On the systems I build, backups aren't an afterthought bolted on at the end. For most Laravel projects that means automated database backups stored somewhere separate from the primary hosting, with restore points I can actually test, plus separate handling for uploaded files and anything sensitive that needs its own recovery path. I'd rather spend an hour a quarter confirming a restore actually works than find out it doesn't during an outage, with a client waiting on the phone.

None of this needs to be elaborate. A small business doesn't need multi-region failover or the infrastructure of a bank. But it does need someone who can answer, honestly, what happens if the primary system disappears tomorrow, and how long it takes to be working again. If you can't get a straight answer to that today, that's the moment to ask, not after something's gone wrong.