How do you test that a backup works?
A backup works when someone has restored data and checked that it is usable. A log showing “success” proves that the copy was written, not that the database opens, that the server boots, or that the encryption key is still known.
Updated October 20264 min read6 sources cited
Key points
- Every day: automatic check of the job and the volume, with an alert sent to a named person.
- Every quarter: restore a file, a mailbox or a table to a test location.
- Every year and after every architecture change: a full restore or boot test, checked by a business user.
- Record the time it takes to get usable data: that is your real RTO.
- ENISA, the European Union Agency for Cybersecurity, like the ANSSI and the CNIL in France, makes restore testing a basic measure.
What the authorities say
Restore testing is a basic measure everywhere:
- the ANSSI, France’s national cybersecurity agency, requires backups to be tested regularly, and a procedure for restoring the information system to be written up and regularly carried out;
- the CNIL, France’s data protection authority, recommends regularly testing the integrity of backups and the ability to restore them, and lists discovering too late that they are unusable among the mistakes to avoid;
- ENISA, in its cybersecurity guide for SMEs, calls for regularly testing the ability to restore data, ideally through a full restore;
- Microsoft sums it up for SQL Server: until you have tested your backups, you do not have a restore strategy.
The NIST, the US National Institute of Standards and Technology, distinguishes three complementary activities: testing validates recovery capability, training prepares people, and exercises reveal gaps in the plan.
Three levels of testing
1. The automatic check, every day. The job has completed. The volume written is plausible (neither zero nor three times the usual amount without explanation); the ANSSI cites an inconsistent volume among the signals to monitor. The alert goes to a person, not just to the mailbox of the server being backed up. This level detects failure. It does not detect an unusable copy.
2. The partial restore, every quarter. Choose a file, a mailbox or a table at least a week old. Restore it to a test folder or machine, not over production. Open the file. For a database, run a consistency check on the restored copy. Measure the time. Note who found the key and the instructions. This is the test that reveals forgotten procedures.
3. The full restore or boot test, once a year and after every architecture change. Start a test server from the image, or start the DRP standby environment, and have a business user check that a real function works (an invoice opens, a customer can be looked up). A server that boots to a login screen but whose business application is broken has not been restored.
| Level | Frequency | What it proves | What it does not prove |
|---|---|---|---|
| 1. Automatic check | Daily | The job ran, the volume is plausible | That the copy can be restored |
| 2. Partial restore | Quarterly | A file or database opens, the key is found | That the whole server restarts |
| 3. Full restore | Annually and after any change | The business service restarts, within a measured time | The recovery of all systems at once |
What to record at each test
- Date, person, system tested, date of the restore point used.
- Time elapsed until the data was usable. This observed time is your real RTO, more honest than the one in the quotation.
- Discrepancies: missing file, wrong permissions, application that does not start, password that cannot be found.
- Decision: correct the backup, the documentation, or the RTO announced to management.
Without this report, the test exists only in the memory of the person who will one day leave. The NIST also recommends keeping a record of changes to the plan after each test.
The most instructive failures
- The backup succeeds but does not include the new disk added four months ago.
- The restore requires a key held by a former service provider.
- The log is green because the job has been backing up an empty folder since a drive letter was changed.
- The test always restores the same small file and never the 200 GB database, whose restore time comes as a surprise on the day of the outage.
- The DRP test stops at “the boot screen appears”, and nobody has checked the application.
If a test fails or an overnight backup is missing, the steps to follow are in Last night’s backup failed.
At WeDoBack
24/7 monitoring raises an alert if a backup fails. This alert corresponds to level 1. It does not replace levels 2 and 3. For the DRP, a monthly boot test of the standby instances takes place without affecting production: it is a boot test, not a business test. A real-world test, lasting up to ten hours, can be ordered on quotation. Restoring a file or a complete server remains in the hands of the customer, or of the support team: two hours per month are included with INTEGRAL, and support is billed per intervention with SMART. Support can be reached on +33 9 72 50 78 28 from 9:00 to 13:00 and from 14:00 to 17:30 (Paris time). The encryption key is held by the customer: each test is an opportunity to check that it is available.
Frequently asked questions
Is my backup software’s integrity check enough?
It checks that the blocks written are not corrupted. It does not check that the application restarts, that permissions are correct, or that the right person knows where to find the key. It is a good level 1, not a restore test.
Can you test on the production environment?
No. You restore to a test folder, mailbox or machine, isolated from the production network if necessary. Restoring over production “to see” risks overwriting recent data or creating duplicates on the network (same name, same address).
How long does a quarterly test take?
Often less than an hour for a file or a mailbox. The annual test of a complete server generally takes half a day to a full day, including the report. That is little compared with the time lost discovering a problem during a real outage.
Sources
Documents consulted in October 2026.
- Backing up information systems – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025) — ANSSI (French agency)
- Security: Backing up — CNIL (French authority)
- Cybersecurity guide for SMEs – 12 steps to securing your business (June 2021) — ENISA, the European Union Agency for Cybersecurity
- Back up and Restore of SQL Server Databases — Microsoft Learn
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- DRP offer (Disaster Recovery Plan) — WeDoBack
Planning a backup, DRP or BCP project?
More than 20 years of experience protecting business data.
Request a quote+33 9 72 50 78 28Protect your data with WeDoBack
Encrypted offsite backup, immutable storage, DRP and BCP: tell us about your servers and we will recommend the right combination.
