# Database Backups Before an AI Release: What to Ask

> Before an AI-built release changes your database, is the backup proven? A plain guide to backups, restore tests and rehearsals, with questions to ask.

Canonical: https://bridge-terminal.com/atlas/blog/database-backups-before-ai-release-what-to-ask/
Last updated: 2026-11-06

Published 6 November 2026 · Plain English · Explainer · 7 min read

## The short version

- A backup you have never restored is a hope, not a safety net; the only proof is to restore it somewhere safe and look at the result.
- Database changes are the riskiest part of a release because customer data cannot be rebuilt from code the way a website can.
- Before any AI-built release that touches data, ask for four things: a marked way back, a fresh backup, a restore test, and a rehearsal of the change on the copy.
- You do not need to read code to check this; ask for plain evidence, such as how many records came back and what was compared.
- Going live, deleting data and spending should stay your decisions, not the agent's.

If an AI coding agent is about to change your database, the one thing to insist on is a backup that has been proven by restoring it. A backup that merely "completed" is not enough. Ask to see that the copy was brought back somewhere safe, that the data looked right, and that the change was rehearsed on that copy before the real release.

This guide explains, without code, why this matters, what the steps are and what to ask.

## Why are database changes riskier than other changes?

Most of what an AI agent builds is code: the screens, the rules, the logic. If new code is wrong, you can usually put the old code back. Nothing is lost.

Your database is different. It holds the things your business cannot re-create: customers, orders, invoices, messages, settings. Think of the code as the shop fittings and the database as the stock and the ledger. You can refit a shop. You cannot easily reconstruct last year's ledger from memory.

Many releases change the shape of the database as well as the code. Examples:

- Splitting a single "name" field into first name and last name.
- Adding a new status to every order.
- Merging two customer lists that overlap.

These changes are called migrations. They rewrite existing records in place. If one goes wrong half way, you can end up with some records changed and some not, and the old code may no longer be able to read them. That is why this part of a release deserves extra care, whether a person or an agent does the work.

## What is a backup, and why does "it ran" not prove it works?

A backup is a saved copy of your data, taken at one moment. The copy is only useful if you can turn it back into a working database.

Backups can fail quietly. One practical guide on backup testing says that a backup job that finishes without errors does not prove you can recover from it. It lists how this happens: an archive can be cut short when a disk fills up, a database dump can silently skip a database, and a retention rule can delete the only good copy.

The documentation for Progress OpenEdge, a database product, gives the same advice. It says to test backups regularly so they are valid and available when you need them, and ideally to test one immediately after you make it, so that you can make another if there is a problem. Its warning is blunt: if you wait until you need the backup to test it, the database will no longer be available.

So the useful question is never "do we have a backup?" It is "have we ever restored it?"

## What does a proven backup look like?

In plain terms, proving a backup means restoring it into a separate, throwaway place and checking the result. The backup-testing guide suggests checking these things:

1. **Freshness.** The newest copy is recent enough that losing everything since then would be tolerable.
2. **Readable to the end.** The copy is not cut short or damaged.
3. **Complete.** The important data is there and the database loads without errors. Comparing a sample of records with the live ones is a sensible extra check.
4. **Permissions.** Restored files keep the right owners and access settings. Wrong settings can stop an application from working even when the data is fine.
5. **It works.** The application runs from the restored copy.

There is a detail worth knowing, even if you never touch it. The PostgreSQL documentation, for a very common database, says that when you restore from a plain dump with its standard tool, the restore carries on after an error by default. That can leave you with a partly restored database. The documentation describes a setting that makes the restore stop and report an error instead. A careful restore test uses it. This kind of detail separates a real test from a box-ticking one.

Another detail from the same documentation: the standard tool for copying a single database does not save information about roles, which are the database's users and their permissions. Those are cluster-wide and have to be saved with a separate tool. A backup can look complete and still be missing the pieces that decide who can open it.

## What is a rehearsal, and why do it on the copy?

Once you have a restored copy, you have a safe place to practise. A rehearsal means running the planned database change on that copy first.

This answers questions you cannot answer by reading a plan:

- Does the change finish without errors on real data, with all its odd records?
- How long does it take? A change that is instant on ten test records can take far longer on a million.
- Does the application still work afterwards?
- Did any records go missing or change in a way nobody intended?

If the rehearsal fails, you have lost nothing. Your real data was never touched. You fix the plan and rehearse again.

## What is the safe order for a release that changes data?

A sensible order, whoever runs it, is this:

1. Mark the way back, so everyone knows exactly what "undo" means.
2. Take a fresh backup of the data.
3. Prove the backup by restoring it.
4. Rehearse the database change on the restored copy.
5. Release.
6. Check the result against what you expected.

Skipping step 3 is the common shortcut. It saves minutes and removes the only evidence that step 2 worked.

Atlas is an AI engineering team, built on Claude Code, and its releases beyond the Mac follow these steps: the way back is marked, data is backed up and the backup is proven by restoring it, database changes are rehearsed on that copy, the release goes out, and then it is checked. Atlas also never decides production go-lives or deleting data for you; those stay with a person.

## What should you ask your team or agent?

You do not need to read any code. Ask for evidence in plain words:

- "When was the backup taken, and was it restored somewhere to prove it?"
- "How many customers and orders were in the live data, and how many in the restored copy?"
- "Was the change rehearsed on the copy? How long did it take, and what did you check afterwards?"
- "What exactly is the way back if this goes wrong, and how long would it take?"
- "Does anything in this release delete or overwrite data? Who approved that?"

Good answers are specific: numbers, times, and what was compared. Vague answers such as "it should be fine" or "the backup job is scheduled" are a signal to pause the release.

The backup-testing guide adds one more habit worth borrowing: decide in advance how much data you can lose and how long you can be down, then time a real recovery practice against those limits. If a restore takes six hours and your shop cannot be closed for two, you want to know that before the day it matters.

## What can an AI agent get wrong here?

Agents work fast, which helps in most places and hurts here. Failures to watch for include:

- Reporting "backup complete" when the job ran but nobody checked the output.
- Testing a change on tidy sample data that does not look like your real records.
- Treating a restore as optional because the change looks small.
- Running a change against the real database to "see what happens".

None of these are unique to AI; human teams do all of them. The difference is speed. An agent can make a mistake and move on to the next task in seconds, so the checks have to be part of the process, not a favour someone remembers to do.

## How often should you test restores?

The backup-testing guide describes automated restore tests on a regular schedule, with a weekly one as its example. It also describes a full recovery practice on a fresh server at least a few times a year and after major changes to the setup. It says to alert on a failed restore test, so that it is noticed as quickly as a failed backup. Pick a rhythm that matches how much data you can afford to lose and how long you can afford to be down.

Before any release that changes data, test the restore every time. It is cheap and it protects you from the worst outcome.

## Conclusion

Releases that change your database are the moments when a small mistake becomes a permanent one. The protection is simple and not technical: a way back that is marked, a fresh backup, a restore that has actually been done, and a rehearsal on the copy.

You can ask for all of it in plain words, and a good team or agent can answer with numbers. To see how Atlas handles it, the [Atlas home page](https://bridge-terminal.com/atlas/) describes the release steps it follows.

## Questions people ask

### What does it mean to test a backup?

It means restoring the backup into a separate, safe place and checking that the data is complete and the application works from it. A backup job that finished without errors does not prove you can recover from it.

### Why rehearse a database change before releasing it?

A rehearsal runs the change on a restored copy of your data, so you learn whether it finishes, how long it takes and whether records survive. If it fails, your real data was never touched.

### Do I need to read code to check a release that changes data?

No. Ask for plain evidence: when the backup was taken, whether it was restored, how many records were in the live data and in the copy, and what the way back is. Specific numbers are a good sign; vague reassurance is not.

### How often should backups be test-restored?

One guide describes automated restore tests on a regular schedule, with weekly as its example, plus a full recovery practice a few times a year. Before any release that changes data, test the restore each time.

### Does Atlas prove its backups before a release?

For releases beyond the Mac, Atlas marks the way back, backs up the data, proves the backup by restoring it, rehearses database changes on that copy, releases, then checks. Production go-lives and deleting data stay a person's decision.

## About Atlas: A restored backup before every data-changing release

For releases beyond the Mac, Atlas follows eight steps: the way back is marked, data is backed up and the backup is proven by restoring it, and database changes are rehearsed on that copy before release. Then the release is checked. Production go-lives and deleting data are never decided for you. — https://bridge-terminal.com/atlas/

## Sources

- [Progress OpenEdge: Testing backups](https://documentation.progress.com/output/ua/OpenEdge_latest/dmadm/testing-backups.html)
- [PostgreSQL documentation: SQL Dump (backup and restore)](https://www.postgresql.org/docs/current/backup-dump.html)
- [CubePath: Backup Testing and Restoration validation guide](https://cubepath.com/docs/backup-recovery/backup-testing-and-restoration)

_Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._

## Related

- [Can an AI Coding Agent Work Overnight? A Plain Guide](https://bridge-terminal.com/atlas/blog/can-ai-coding-agent-work-overnight-unattended/)
- [How AI-Built Software Gets Released: A Plain Guide](https://bridge-terminal.com/atlas/blog/how-ai-built-software-gets-released-plain-guide/)
- [AI Coding Agent Risks and How to Reduce Them](https://bridge-terminal.com/atlas/blog/ai-coding-agent-risks-what-can-go-wrong/)