How to check your backup and test data recovery

A “backup completed” notice confirms that a system task has run. To know whether you can get back to work after a failure, you need to check what that backup contains and test recovery. Those are two separate questions.

You can start small: download a recent export and find your latest invoice. This check does not prove that the whole system can be recovered, but it can reveal problems with readability, content or dates before you need the data.

An initial backup check

1. Find out what you will download. Ask your provider whether it is a data export or a backup that can restore the system. Check whether it includes attachments, relationships between records and settings. A customer CSV can be useful while still leaving out part of your operations.
2. Open the file. If it is a spreadsheet or CSV, check that the columns make sense and the fields you expect contain information. Zeros can be legitimate values; what matters is whether they match your records.
3. Check three recent records. Find the latest three invoices or customers and compare their fields with the system. This is an initial sample, not an integrity check of the entire backup. If records are missing, first check the expected cutoff date.
4. Check that cutoff date. Note which later changes are excluded. The practical question is how much work you would have to reconstruct if you could only recover up to that point.
5. Protect an independent copy. If you save the file on an external device, you can disconnect it afterwards. A protected folder with another service gives you independence from the original provider, but remains connected and needs its own access controls.

The missing test: getting back to work

Ask for a restore in a test environment that will not overwrite production data. Then check a real task: finding a customer, opening an invoice with its attachment or recovering a quotation with its line items. The criteria depend on what your business needs to operate.

Record which backup was used, how long recovery took, which functions were checked and which errors were found. Also note who has access and, if needed, the encryption keys. A recovered file is of little use if nobody can open it.

AWS Backup distinguishes restore testing from simply storing backups: testing evaluates whether restoration is viable and measures how long it takes. That is a feature of the service, not a guarantee about your business software.

Why it is worth checking in advance

Tailscale documented a case of SQLite database corruption detected by a process reading its backups. During the investigation, it added continuous integrity checks of backups and improved its recovery procedures. The case illustrates a possible mechanism; it does not measure your company's risk or mean that your software has the same fault.

This week, you can ask support for two things: a recent export with its cutoff date and a restore test with results. The first lets you examine a sample. The second lets you check whether the data and functions you need come back.