Would my backups get me up and running again?

My nightly backups kept reporting success, but a restore test on July 25, 2026 found four faults. I hadn't run one in a while and had fallen into the familiar trap of trusting the green result. I now use three levels of checks, from reading the backup file to getting a response from the application. Each catches a different reason I might fail to get my data back.

What I need to get back

A database keeps changing while the application uses it. Copying its files as it runs can mix data from different moments, leaving pieces that don't fit together when restored. I let the database produce a consistent export of its own data, then put that file in the backup. When restoring, I still have to load the export back into a database. Unpacking it onto a disk doesn't make the data available to the application.

I also save the application files, configuration, and passwords used by the programs. The settings tell an application where its data lives. A password only lets it in if the database also recognizes its account. Getting back to work depends on all those apparent extras as well as the data itself.

I encrypt the whole backup. One copy stays at home; another goes to a separate location away from home. The copy kept elsewhere doesn't delete a file just because it has disappeared from the source. If I accidentally delete something at home, I don't want the next backup run faithfully repeating the mistake. This prevents that deletion from being passed on. It doesn't make the other copy impossible to delete.

A job that never starts can't report a failure

I watch the age of the last successful backup. Once it gets too old, the elapsed time triggers an alert, even if the backup job never started. I don't have to wait for a missing job to explain itself. A separate alert flags a suspicious file size: the job might have produced a backup containing less data than it should. These alerts tell me when to investigate the job or its output. To find out whether I can recover the data, I have to try restoring it.

Three checks, each with something different to catch

I check the backup file itself. In a full restore test, I recover the data and start the application. Between those full tests, a weekly job restores part of the latest backup. Together, the checks cover gaps that any of them could miss on its own.

Can I read what's in the file?

An integrity check tells me whether the backup file can be read correctly. It can catch a damaged archive before I need it after a failure. Having a file on disk is little comfort if I can't get its contents out.

A perfectly readable archive can still hold an incomplete backup. If I left out a password file, the check can't find anything wrong with it: it never received that file. To discover whether the application is missing something, I need to restore the data and try starting it.

Keep going until the application answers

For a full test, I use a computer that's already been prepared. I download the backup, restore its contents, and check whether the application responds. The test on July 25, 2026 exposed four ways that process could break:

• The database accounts weren't backed up. The data came back, but the application couldn't log in. The report confirmed that data had been saved; it didn't check whether the application's accounts had been saved too.
• The restore script skipped the databases. It unpacked the files without loading the exports into the databases. The backup report saw a successful file copy, not the missing step in the tool meant to restore them.
• An exclusion rule caught password files. It matched more files than intended and left out credentials the applications needed. The backup job followed its instructions, so it had no error to report.
• The data came back under the wrong name. The application would have created a fresh, empty store alongside the restored one, perfectly happy to start from scratch. The files were there, but the program was looking under a different name. The backup report never checked whether the names matched.

I fixed those faults, then repeated the test on August 22, 2026, after reworking the backup script. I wanted to check that all four fixes still held up with backups made by the revised script. They did. I also expanded the test from 3 databases to 7 and started the application.

I wait for a successful response from the application before calling the test complete. For the application to start successfully, the data, accounts, passwords, and settings all have to work together. Stopping after the database restore could leave a missing application login undiscovered. These timings end at the application's first successful response; they don't cover checking every feature.

Stage of the test on August 22, 2026	Time
Download the backup — 1.26 GB	117 s
Unpack and decrypt	about 21 s
Start the database, restore accounts and 4 databases	about 27 s
Restore the remaining 3 applications and their databases	about 44 s
Start the application and wait for its first successful response	about 12 s
Total	about 220 s, or about 3.7 min

Downloading the backup took more than half the total time. That's where I start the clock. Timing from the unpacking step would give me a nicer result while leaving out the longest wait. After a failure, I'd still have to get hold of the backup before I could use it. This measurement starts with a prepared computer; it doesn't include installing the operating system.

The August test also turned up a fault in the recovery tool itself. Had I accidentally run the script on the computer in daily use, it would have overwritten the current configuration with the older backup. A recovery tool with the potential to create its own recovery job. I changed it so that it checks where it's running before overwriting the configuration. Remembering which computer I'm on is no longer the only safeguard. During a failure, I already have enough to keep track of.

A different database gets its turn each week

Between full tests, the weekly job restores the next of five databases from the latest backup, separately from the database in daily use. Each gets tested every five weeks. I chose a fixed order because random selection could leave a database untested for weeks, with no way to know when its turn would come. Going through them in order gives each a predictable turn.

The job uses the restore script taken from the backup itself. A fixed version on my disk could work while the copy inside the backup still contained a bug. The latter is what I'd actually have after a failure, so that's the version I test. I don't swap in a newer script before the run. The backup has to give up its data using the tool packed with it. That tests the tool as well as my ability to dig data out of files by hand.

For the temporary test database, the job uses the same software image as the database in daily use, including the software version and extensions. One database wouldn't restore at all without its extension. Matching the software prevents a missing extension in the test from looking like a broken backup.

A running database doesn't tell me much by itself. An empty one can start quite happily too. For each database, I've set a minimum table count and a separate content check based on what matters in it. Depending on the database, the job counts documents, saved automation workflows, or entries for photos and videos. This checks whether the content the application uses has come back too.

On September 19, 2026, after introducing the rotation, I ran all five databases through the job using that night's backup. All five restored successfully, taking 14 to 47 seconds per database. I also checked that the test could fail: setting a deliberately excessive minimum count made it fail as expected. The job still doesn't start the application, so I don't compare these times with the full restore test.

After each test, the job destroys the decrypted passwords so they aren't left on disk. My manual tests that day triggered a mass-deletion alert from the system watching for suspicious behavior on the server. My own security had mistaken me for an intruder; the automatic runs attract no such suspicion.

That gives me a regular answer to whether the latest backup can still return my data. I repeat the full test whenever I change the backup script or add a database, with no more than half a year between tests. The previous result couldn't have checked a new database or changes I made afterward. The weekly job keeps checking between full tests, and the full test also covers the application it leaves out.

When I add the new machines, I plan to test a restore from scratch on new hardware, including installing the operating system. I'll add the result here once I've run that test.