Business Data Backups: Why Restore Drills Matter Just as Much

Almost every business owner agrees that data should be backed up. Customer records, orders, payments, and transaction history are part of what your business is worth. The catch is that many businesses only discover their backups are broken, incomplete, or impossible to open once the data is already gone.

This article covers why that happens, what a sound backup looks like, and why a restore drill matters just as much as the backup itself. The examples come from Numekara, the education business run by Lumekara's owner, which runs daily backups and restore drills for its production database.

Why backups fail when you need them

Backups rarely fail because of one big mistake. Usually it's something small that nobody ever checked:

• Never test-restored. The backup file exists, but nobody knows whether it actually works.
• Stored in the same place. The backup sits on the same server as the live data. When the server has a problem, both disappear together.
• Incomplete. Only some tables or files are included, and the gap only shows when you need it.
• The key or password is lost. An encrypted backup is useless if nobody kept the key safe.
• Silently stopped. The backup schedule fails for weeks, and no one is told.
• The procedure lives in one person's head. When that person isn't around, nobody knows how to restore.

What a sound backup looks like

A good backup doesn't have to be expensive, but it should meet a few basics:

• Automatic and scheduled. It runs on its own, for example daily, without relying on anyone's memory.
• Encrypted. Its contents can't be read by the wrong people, even if the file leaks.
• Stored away from the main server. Use separate storage, so trouble on the main server can't wipe the backup too.
• Checksummed. A checksum is a file's digital fingerprint. Comparing it tells you whether the backup is intact or damaged.
• Monitored. There's a place to see when the last backup succeeded, and an alert when one fails.

At Numekara, a daily workflow dumps the database, encrypts it, writes a checksum, and ships it to separate storage on Cloudflare R2. Backup status also appears on an admin page next to error monitoring, so the owner never has to guess whether last night's backup ran.

How often, and how long to keep them?

The easiest way to set a backup schedule is to ask: how much data can you afford to lose? If a day's orders could be pieced back together from emails and bank statements, daily backups are enough. If transactions arrive every minute, you may need a tighter schedule or your database provider's built-in recovery features.

Keep several older versions too, not just the latest. Data mistakes, such as an order deleted by accident, are often noticed days later. By then, last night's backup already contains the mistake.

Restore drills: the only proof a backup works

A restore drill means restoring a backup somewhere separate to prove the data really comes back. Think of it as a fire drill: the point is to find problems while things are calm, not in a panic.

1. Fetch the latest backup from off-server storage, just as you would in an emergency.
2. Check the checksum before opening anything, to make sure the file wasn't damaged in transit.
3. Decrypt it with the key stored according to your procedure.
4. Restore it into an empty database that is separate from production.
5. Inspect the result: are the key tables there, do the record counts look sensible, and did user accounts come back too?
6. Write down the outcome, including any problems found and how they were fixed.

One safeguard is non-negotiable: a drill must never touch the production database. Numekara's restore-drill script is built to refuse to run if it's pointed at production.

A real story: the drill that failed first

In Numekara's second restore drill on 15 October 2026, a production backup was pulled straight from off-site storage. Download, checksum check, and decryption all went smoothly. But the first attempt failed at the restore step, because the dump contained built-in objects from the database platform in use, and those objects don't exist in the plain database used for the drill.

The script was then fixed to skip only the platform's own objects, while application data and user accounts were still restored in full. The next attempt, using the same backup file, passed, and the result was recorded as written evidence.

The lesson is simple. The backup itself was fine, but without a drill, the problem in the restore procedure would only have surfaced during a real emergency. The drill bought time to fix it calmly.

Next steps

Ask your team or developer three questions: where are the backups stored, when did the last one succeed, and when was one last test-restored? If nobody can answer the third, schedule your first restore drill. After that, repeat it regularly and whenever the system changes significantly.