Test History Backup: Why a Backup You Have Never Restored Is Not a Backup

Somebody on your team owns the backup job. Nobody has ever restored from it. That is the normal state of affairs at most companies. It is fine right up until the night a database volume corrupts or a bad migration wipes a table. The team discovers the backup restores fine but the evidence is gone anyway. For a test management system the stakes differ from most databases. A test history backup is not just data you can regenerate. It is the record that a release was tested. Somebody may need to produce that record months later when a customer asks why a bug shipped. An auditor might ask how you know a regulated feature was checked before it went out. This post is a short, procedural answer. It covers what has to be in the backup, how to prove the restore works, and the two numbers you need to agree with whoever cares about this.

What actually has to be in a test history backup

A test management tool is not one file. It is at least three things that have to travel together.

• The database dump itself, usually Postgres, holding test cases, runs, results, and links to defects
• The attachment storage, which holds the screenshots, logs, and video captures teams attach to failed runs
• The configuration that maps one to the other, so a restored database still points at the right attachment paths

Most backup jobs cover the first item well. It is the obvious one. The other two get missed constantly. A team that only backs up the database will find that out the hard way. That usually happens during the one week they actually need the full picture.

The database, the attachments, and the config that links them are all part of the same test case management record. Treat them as one unit for backup purposes, not three separate systems.

Why attachments are the part people lose

Screenshots and log files are usually stored outside the database. They sit on a filesystem volume or in object storage, with the database holding only a reference path or an ID. A backup script that dumps Postgres nightly and calls it done will restore a full set of test cases and results. Every attachment link will point at a screenshot that no longer exists.

The run history looks complete at first glance. Then someone opens a failed test from four months ago to check what actually happened. They find a broken image link where the evidence used to be.

If your evidence obligation is real, meaning someone might genuinely need to open that screenshot later, the attachment volume is not optional. It has to be backed up on the same schedule as the database, with the same retention.

The restore drill as a scheduled exercise

A backup that has never been restored is a hope, not a backup. The only way to know it works is to actually restore it, on a schedule, somewhere that is not production.

• Pick a scratch environment that mirrors production closely enough to matter
• Restore the most recent backup into it once a quarter
• Time the whole thing from the moment you start to the moment the app is usable again
• Write down what broke, what was slower than expected, and what you had to improvise

The first restore drill almost always surfaces something nobody expected. It might be a missing environment variable. It might be a storage bucket with the wrong permissions. It might be a schema version mismatch that nobody tracked.

Finding that in a scheduled drill costs an afternoon. Finding it during a real outage costs the afternoon plus the incident, plus whatever explanation is owed to whoever is waiting on the data.

The two numbers to agree with whoever cares

Before calling a backup plan good enough, get agreement on two numbers with whoever owns the risk. That is usually engineering leadership, or whoever answers to a customer or auditor when things go wrong.

• Recovery point objective: how much history you can afford to lose, expressed as a time window, for example 24 hours of test runs
• Recovery time objective: how long a restore is allowed to take before it becomes its own incident

These numbers should not be guesses. They come from asking what actually happens if a day of test runs vanishes. They come from asking what happens if the tool is down for six hours during a release week.

Write both numbers down somewhere the whole team can see them. Check actual drill times against them every time you run the exercise.

The audit angle that makes this different from any other database

Losing a marketing database is bad. Losing test run history is a different kind of bad. The run history is frequently the only evidence that a specific release was tested against a specific set of cases before it shipped.

If a customer disputes that a feature was checked, the answer usually lives in this database. If a regulator asks for proof of a test process, the same database is where you look. Traceability and audit evidence are only as good as the record they rely on, and that record is only as good as its backup.

A gap in the backup is not just data loss. It is a gap in the record you may need to produce later. There is no way to regenerate it after the fact, because the record captured a moment in time that has already passed.

A worked example with numbers

A team running a nightly Postgres dump alongside a 40 GB attachment volume decided to run its first restore drill after eighteen months of running the tool. The database dump restored in eleven minutes, exactly as expected.

The attachment volume was a different story. It was synced separately with a different tool and a different schedule. The restore took two hours longer than anyone had budgeted. Nobody had checked how long a 40 GB transfer actually takes over the connection to the scratch environment.

Nothing was lost in the end. But the team's assumed recovery time objective of one hour turned out to be off by a factor of three. They only found out because they tried the restore instead of trusting the backup job's green checkmark.

How to make it routine

The teams that get this right treat it the same way they treat any other operational duty.

• Name one owner for the backup and restore process, not a rotating on call list
• Put the quarterly drill on a calendar, not a someday list
• Keep a short written record of each drill's time and any issue found
• Review the two agreed numbers against the drill result every time

None of this is exotic. It is the same discipline teams already apply to production databases. Here it is just pointed at the system holding the evidence that releases were actually tested. The habit costs an afternoon a quarter. The alternative costs a scramble during an incident, with an auditor or a customer waiting on the other end of the answer.

A small amount of routine now buys a lot of confidence later. Once a team has run the drill twice and both times found something worth fixing, the exercise tends to stop feeling optional. It becomes the thing that lets everyone sleep through the next storage outage instead of finding out what actually happened to the evidence at 2am.