# Backups you can actually restore from

> What to back up besides the database, how long to keep it, where to store copies, and how to run drills so a restore stops being improvised.

Published: 2025-09-14 · Source: https://subxcat.com/articles/backups-that-restore · Author: SUBXCAT

Almost everyone has backups. Far fewer people are confident they can rebuild a working product from them, rather than just a database that boots somewhere. The only test of a backup is a restore, so think about it before you need one.

## Two questions to start with

Before picking tools, answer two questions:

- How much data can you afford to lose? An hour, a day, nothing?
- How long can the product be down while you recover?

The first answer sets how often you take copies. A nightly dump means that in the worst case you lose a day of orders and signups. If that's not acceptable, you need point-in-time recovery: the database continuously writes its change log, and you can roll back to any minute. Most managed databases let you turn this on in settings.

The second answer sets how detailed your restore procedure must be. If the product can be down for half a day, a clear written guide is enough. If it's an hour, you need a guide someone has already followed step by step.

## What to back up besides the database

The database is the obvious part, but not the only one:

- Uploaded files. Avatars, documents and attachments usually live in object storage, and a database dump doesn't include them.
- Configuration and secrets. A restored app won't start without its environment variables, and recalling them from memory is a bad plan. Keep them in a password manager or secrets store that has its own history.
- DNS records. There aren't many, but if the registrar account is unavailable, rebuilding your email records from memory is close to impossible.
- A description of the infrastructure: which services, which region, which settings.

## Files and database have to agree

A common trap: the database is restored to last night, the files to this morning, or the other way around. The database points at files that don't exist, and storage holds files nothing points at.

Versioning in object storage helps: a deleted or overwritten file doesn't vanish immediately, and you can bring it back as of a given moment. After a restore, run a script that checks every file reference in the database resolves to a real file.

## How long to keep copies

A reasonable scheme for an early product: daily copies for the last couple of weeks, weekly for a couple of months, monthly for a year. The long tail isn't for outages. It's for the moment you realise a month later that an import quietly corrupted half the records.

If the product stores personal data, write the backup retention period into your privacy policy. A user deleted on request still lives in your backups for a while, and it's more honest to say so than to pretend otherwise.

## Where to keep copies

A copy in the same account as the database protects against a failed disk, but not against a mistake by someone with admin rights, and not against that account being compromised. At least one copy should live separately: a different account or a different provider, with credentials that can't delete it from the main environment. Copies are encrypted, and the encryption key isn't stored next to them.

## Drills

Once a quarter, restore the whole product into a separate environment and write down the steps. During the drill, check:

- how long it took from start to a working login;
- that the copy contains data from the last day;
- that files actually open, not just appear in a listing;
- whether you can restore a single deleted record without rolling back the whole database.

That last one comes up more often than a full outage: someone deleted a client's project by accident, and only that project needs to come back.

## The backup that quietly stopped

A backup job breaks silently. What you need is an alert not on failure but on the absence of success: if no new copy appeared in the last day, someone should hear about it.

SUBXCAT can set up the backups and run the first drills with your team, so the next ones follow a written procedure.