How can 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 change of architecture: full restore or boot test, checked by a business user.
- Record the time until the data is usable: this is your real RTO.
- CERT-MU, the Data Protection Act 2017 and the ANSSI, France’s national cybersecurity agency, all treat restore testing as a basic measure.
What the authorities say
Restore testing is a basic measure everywhere:
- in its backup plan guideline, CERT-MU recommends regular restore tests and a copy kept off site;
- the Data Protection Act 2017 (section 31) requires appropriate security measures against the loss or destruction of data, which means regularly checking that backups can be restored;
- the ANSSI, France’s national cybersecurity agency, requires backups to be tested regularly, and an information system restoration procedure to be written and regularly carried out;
- Microsoft sums it up as follows for SQL Server: until the backups have been tested, there is no restore strategy.
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 lists an inconsistent volume among the signals to monitor. The alert goes to a person, not only to the mailbox of the server being backed up. This level detects failure. It does not detect an unusable copy.
2. Partial restore, every quarter. Choose a file, a mailbox or a table dating from at least a week ago. Restore them 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. Full restore or boot test, once a year, and after every change of architecture. Start a test server from the image, or start the DRP standby, and have a business user check that a real function works (an invoice opens, a customer can be searched for). 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 is 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: fix 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 eventually leave. 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 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 is limited to “the boot screen appears”, and nobody has checked the application.
If a test fails or a nightly 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, for 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 support: two hours per month are included with INTEGRAL, while support is billed per intervention with SMART. Support can be reached on +33 9 72 50 78 28 from 9 am to 1 pm and from 2 pm to 5:30 pm (Paris time), i.e. from 11 am to 3 pm and from 4 pm to 7:30 pm Mauritius time during European summer time, one hour later during European winter 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. Restore to a test folder, mailbox or machine, isolated from the production network if necessary. Restoring over production just 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 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.
- Guideline on devising a personal backup plan (CMSGu2017-03) — CERT-MU
- Introductory Guide to the Data Protection Act 2017 — Data Protection Office (Mauritius)
- Backing up information systems – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025, in French) — ANSSI, France’s national cybersecurity agency
- 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.
