Nobody gets excited about backups. They’re not a feature, they don’t show up in demos, and setting them up correctly costs money and time for a problem that, on a good day, never happens.
This is precisely why it’s the topic most businesses avoid until it’s too late.
The pattern I keep seeing
A business can run smoothly for months or even years. Then, suddenly, something goes wrong. A bad deployment corrupts data. A hosting provider experiences an outage that takes longer to resolve than expected. Someone with access makes a mistake and deletes or overwrites the wrong table or file. Ransomware encrypts a server.
The first question is always the same: Do we have a backup? The second question, the one that actually matters, is whether it works.
All too often, the answer to the second question is “no,” or “nobody knows.” Backups exist because someone set them up once and hasn’t checked on them since.
A backup that has never been restored is not a backup
This is the most important thing to understand about backup strategy, yet it’s the part that almost everyone skips.
Configuring an automated backup is the easy part. The database dumps every night, the files sync to another location, and the checkbox gets checked. What doesn’t happen nearly often enough is restoring from the backup to confirm that it works.
I’ve seen backups silently fail for months because a credential expired, and no one was monitoring the logs. I’ve seen backup files become corrupted upon writing, and nobody discovered this until the day they were needed. I’ve seen backups run against the wrong database after a migration, faithfully backing up an unused environment.
None of these issues show up until the moment you need the backup, which is the worst possible time to discover that it doesn’t work.
What an actual backup strategy needs
A backup strategy that can withstand real conditions requires specific elements beyond simply having backups.
It must be automated, not manual. If a backup depends on someone remembering to run it, it will eventually not happen. Automation removes the human factor from the most critical part of the process.
It should be stored somewhere separate from what it’s backing up. Backups stored on the same server as the data they protect don’t protect against server failure, ransomware attacks, or provider outages. It should be stored off-site or in a separate cloud account with different access credentials than production.
It should be tested on a schedule. Not just once at setup. Regularly. A quarterly restore test, even a partial one, detects failures that would otherwise remain undetected until the worst possible moment.
Retain it for a meaningful window. A single nightly backup that gets overwritten every 24 hours won’t help if a problem isn’t discovered for a week. Most businesses need a rolling set of daily backups for at least a couple of weeks, plus periodic longer-term snapshots.
The process should be documented so that more than one person knows how it works. Otherwise, if the person who set up the backup system is the only one who knows how to restore from it, the backup system will have the same single point of failure problem as the infrastructure it’s protecting.
The cost conversation
Backups incur real costs in terms of storage, setup time, and the ongoing discipline required for testing. This cost is easy to defer because doing nothing is free until it isn’t.
Storage for backups is inexpensive for small businesses, usually a small fraction of the hosting cost. Setting up a proper automated backup system with off-site storage typically takes a few hours for a straightforward application. The larger cost is the discipline required for testing restores on a schedule, which is more of a time commitment than a financial one.
Compare that to the cost of actually losing data: This includes lost customer records, lost transaction history, lost work product, time spent trying to reconstruct missing data, and, in some cases, the cost of notifying customers or regulators about a data loss incident. The math almost always favors doing backups properly. However, the cost of doing them properly is visible and immediate, while the cost of not doing them is invisible until it’s too late.
What to ask right now
If you’re not sure where your business stands, now is the time to answer these questions, before something breaks.
- Do we have automated backups of everything that could be detrimental to lose, such as databases, uploaded files, and configurations?
- When was the last time someone restored a backup to confirm that it works?
- Where are the backups stored, and would a problem with our main hosting also affect the backups?
- How far back can we go to recover something that broke a week ago without anyone noticing?
- If the person who set this up left tomorrow, could someone else restore it?
If you can’t confidently answer any of these questions, that’s worth fixing before it becomes the reason for a much worse conversation.