Your expert in backup and data protection!The solution tailored to your needs
What to do if…
Last night's backup failed
A backup that fails for one night is not a disaster, it is a delay: the last clean copy is at least 48 hours old if the previous night’s had succeeded. Several failures in a row are a protection incident: look for the cause the same day, rather than simply acknowledging the alert.
Key points
- Read the error message, not just the red light: space, missing source, credentials, locked files, bandwidth, stopped agent.
- A “successful” job may have copied an empty folder: look at the size copied.
- Note the date of the last success and tell the manager of the department concerned.
- Rerun after fixing, then check the following night.
- Three failures in a month on the same machine: change the configuration, not just press “rerun”.
1. Read the error, not just the red light
The usual causes, in the order in which they tend to appear:
| Cause | Sign | Fix |
|---|---|---|
| No space left on the destination, or quota reached | Write error, retention getting shorter | Increase the volume, or shorten the history knowingly |
| Source switched off, off the network, path changed | Drive letter or share renamed; “successful” job on an empty folder | Restore the source, correct the path, check the size copied |
| Credentials rejected | Service account password expired | Restore the account: otherwise every night will fail |
| Locked files or database not quiesced | Partial copy | Use the method intended for open databases; a SQL database in this state cannot be restored cleanly |
| Link too slow or cut off | Job interrupted at the end of the window | More efficient incremental backups, a longer window, or less unnecessary data |
| Agent stopped on the machine | Nothing sent | Restart the service, find out why it stopped |
The most misleading case is a green job on an empty folder. The French cybersecurity agency (ANSSI) requires backups to be checked systematically, in particular by monitoring for inconsistent data or file volumes, network slowdowns and configuration changes. A copied size that drops sharply from one night to the next deserves as much attention as a failure.
2. Know when the last success was
It is the only date that counts for the day’s RPO. If it is more than a few days old, tell the person responsible for the department concerned. They are working without a safety net and need to know. Acknowledging the alert in the console without saying so is what turns an incident into data loss two weeks later.
3. Rerun after fixing
Run a manual job once the cause has been dealt with. Wait for it to finish. If the rerun fails, the cause is still there. The next morning, check the following night: many “obvious” fixes do not survive the second run.
A successful job proves that a copy was written, not that it can be restored. For a SQL Server database, Microsoft states that the backup verification command does not check the structure of the data it contains. CERT-MU recommends testing restoration regularly; ANSSI also requires backups to be tested regularly, with a written restore procedure; NIST likewise recommends testing backups to make sure files can be recovered without errors. After a backup incident, a trial restore of a file or a database is the best check. See How do you test that a backup works?.
4. If it keeps happening
Three failures in a month on the same machine: the scope, the bandwidth or the product is not suitable. Change a setting (exclude a huge, useless folder, split the job, increase storage) rather than rerunning by hand every Monday.
Morning checklist
- Have all of last night’s jobs actually completed, rather than simply “not in error”?
- Is the size copied consistent with previous nights?
- Is the last success date for each critical machine less than 24 hours old?
- Have the alerts been read by a named person, and not just received?
- Does the space remaining on the destination cover the planned retention?
At WeDoBack
24/7 monitoring covers the backups and sends an alert when a backup does not complete. The alert is the start of this page, not the end. With INTEGRAL, two hours of support per month can be used to deal with the cause. With SMART, support is billed per intervention: the failure remains visible to the customer in the console, and it is up to them to read it. 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), i.e. from 11:00 to 15:00 and from 16:00 to 19:30 Mauritius time during European summer time, and one hour later in winter. To size the storage, the published rule of thumb is the current volume multiplied by three, then an adjustment after a week of use: a volume that is too tight shows up as failing jobs or a shrinking retention. The encryption key, held by the customer, plays no part in a failed upload: if the job fails, the remote copy has simply not been updated.
Frequently asked questions
Is one failed night serious?
Rarely, if the previous night succeeded and the cause is fixed during the day. The risk comes from accumulation: each failed night increases the amount of work that would be lost in a disaster. Beyond a few days, it is an incident to report to management.
Is a “successful” status enough to prove a backup is good?
No. ANSSI, France’s cybersecurity agency, requires systematic checks of backups, in particular for inconsistent data volumes, and regular restore tests. For SQL Server, Microsoft states that verifying a backup does not check the structure of the data it contains: only an actual restore, followed by a consistency check, proves it.
Who should monitor backup alerts?
A named person, with a deputy for holidays. An alert that lands in a shared mailbox nobody reads is the same as no alert at all. Also decide who informs management when the last success exceeds a threshold agreed in advance.
Further reading
Sources
Documents consulted in October 2026.
- Information system backup – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025, in French) — ANSSI (French cybersecurity agency)
- Guideline on devising a personal backup plan (CMSGu2017-03) — CERT-MU
- RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Offers and prices — WeDoBack
Need help now?
Do not restore anything until you have identified a clean copy. We can guide you.
Call +33 9 72 50 78 28or write to usDealing with an incident right now?
Our teams help you identify the right copy and restore it, Monday to Friday, 9 am to 1 pm and 2 pm to 5:30 pm (Paris time).