How backups work when we're the ones responsible for them

People think about backups exactly twice. The first time is when they sign a contract and the "backups: yes" checkbox feels reassuring. The second time is when the server has died and it turns out the copy is either stale, un-restorable, or was never tested by anyone. The second time is always more expensive.

We're accountable for our clients' data — so here's an honest, no-magic look at what backups are made of when we're the ones responsible: the principles, the mechanics, and — most important — the verification.

A copy nobody has tested isn't a backup

The most common backup myth goes: "we have automated copying, so we're protected." That's half true. Automated copying guarantees that files are written somewhere. It does not guarantee you can restore from them.

Backups fail quietly. The disk they write to fills up, so new copies stop and old ones get overwritten. A database structure changes, so the backup runs but is useless. Someone accidentally disables the job, and nobody finds out because nobody reads the errors. In every one of these cases the "backups: yes" box is ticked, and the data is, in fact, gone.

So the real question isn't "are copies being made" but "has anyone verified they restore." And verified recently, on a schedule, not a year ago.

A principle, not a product: 3-2-1

We build backups around the classic rule the industry calls 3-2-1:

• 3 copies of the data — the original and two backups. One problem should never be able to destroy everything at once.
• 2 different media — copies don't live in one place or on one kind of storage. If one dies, another survives.
• 1 copy off-site — physically elsewhere. Fire, flood, stolen hardware: the data outlives it.

Generations of copies: not a single snapshot, but a history

A single fresh copy saves you from "the server burned down." It doesn't save you from a quieter scenario: ransomware, or a plain mistake, corrupts the data for several days before anyone notices. If there's only one copy and it's overwritten every night, then by the time you notice the next morning, the fresh copy already holds the corrupted data.

So we keep not a single snapshot but a history — using the scheme the industry calls "grandfather-father-son": the three most recent daily copies, plus a weekly and a monthly one. There's always a clean point to roll back to — not just "to yesterday," but a week or a month back.

Encryption that doesn't rely on a secret

A copy is your whole business in a single file, and it shouldn't have anything to say to a stranger. So every copy is encrypted before it ever leaves the system — with a modern, open standard (we use age).

The fact that the standard is open isn't a weakness; it's the opposite. Strong encryption rests on the secrecy of the key, not the secrecy of the algorithm: you can know the name of the lock, but you can't open it without the key. The key stays with the owner of the data, not "baked in" somewhere on our side. Even if an encrypted copy fell into the wrong hands, it would stay a meaningless string of bytes.

But exactly where a given client's copies physically live — only they know. That's part of their security, not a marketing brochure.

Two independent clouds, both off-site

A copy that sits next to the original shares its fate: the same fire, the same flood, the same stolen rack destroys both. So the copies leave the office.

We keep them in two independent clouds, both off-site: different providers, different locations. If one goes down or becomes unreachable, the other remains, and the business still has somewhere to come back from. One cloud is already better than a closet in the hallway, but even a single cloud can be unavailable exactly when it's needed most.

Nightly — and verified

Copies run nightly, automatically, when load on the systems is lowest. But creating them is only half the job. The other half is regular restore testing: we take a copy and rebuild the system from it, the way we'd have to on the day of a real disaster. Not just "the files are there," but a working system that actually comes back up. If something goes wrong, we find out on a calm test — not at three in the morning during a fire.

In the client's technical passport this is spelled out plainly: when the last copy was made, when it was last checked for restorability, and whether that check passed. Not "something is being backed up somewhere," but a concrete line with a date and a status you can see with your own eyes.

The difference between "we think we're protected" and "we know we're protected" — that's exactly what a regular restore test is.

The anti-pattern that costs the most

"You find out on your worst day" isn't a joke — it's a real scenario we've seen more than once. A business paid for "backups" for years without ever testing them, and on the day of the disaster there was nothing to restore from. The price of that saving wasn't the cost of copying; it was weeks of downtime, lost databases, and sometimes the business itself.

A backup is insurance you can't see until it fires. And the only way to know it will fire is to test it while nothing is burning. That's what you pay for when we're responsible for your copies: not the fact that they exist somewhere, but the certainty that on your worst day they'll pull you out.

Three questions for your own IT

You don't have to work with us to get your backups in order. It's enough to ask whoever runs your IT three questions:

1. What principle are our backups built on — are they encrypted, and is at least one copy off-site?
2. When did someone last restore data from a copy to confirm it works?
3. Where can I see the date of the last successful test — with my own eyes, not on your word?

If all three get a calm, concrete answer, your data is fine. If not, now you know where to start the conversation. And if you're only in the process of choosing who to trust with your IT, the same principles are laid out at greater length in seven questions to ask before you sign.