The morning backup check
At half past eight, an engineer opens the first backup console and scrolls through last night's jobs. Then the Microsoft 365 backup portal. Then the older product still used for two clients with on-premises servers. Then the inbox where the backup alerts go, which contains hundreds of success emails and a few failures, some of which were already resolved by a retry.
The check takes most of an hour. It is dull, and on busy mornings it is skipped. The job that never ran at all (because a server was switched off, or a new client was never added to a schedule) sends no alert, so nobody notices until a restore is needed.
Why backup checking is so error-prone
Each backup product reports on the jobs it knows about. None of them reports on what should exist but does not. And alert emails are designed to say something happened, not to show the absence of something.
- Several products, each with its own console and terminology.
- Success emails drown out failure emails.
- Jobs that are not scheduled or silently disabled send no alerts.
- New devices and mailboxes are not automatically added to backup.
- Warnings (partial success) are treated as success.
Retries confuse the picture as well. A job that fails at midnight and succeeds on a retry at two sends a failure email and a success email, and whoever reads the inbox in the morning has to work out which came last. Multiply that across clients and products and the check becomes guesswork.
When the check is missed
| Missed signal | Consequence |
|---|---|
| Failed job overlooked | A gap in backups nobody knows about |
| Job never scheduled | A device or mailbox with no backups at all |
| Repeated warnings | Backups that may not restore fully |
| Check skipped on a busy day | Failures found days later |
| No record of the check | No evidence for clients or insurers |
Backup expectations (what is backed up, how often, how long it is kept) are set in each client's contract and policy. The view checks reality against those expectations.
The daily backup view we build
- Job results pulled from each backup product's API every night, per client and per protected item.
- An expected-coverage list per client: which servers, workstations, mailboxes, SharePoint sites and shares should be protected, built from your RMM and the client's tenant.
- Comparison of actual jobs against expected coverage, so an item with no backup job shows up as a gap, not as silence.
- Status per item: success, warning, failed, not run, overdue, with the product's own error message.
- Automatic PSA tickets for failures and gaps, with repeats grouped rather than creating a ticket each night.
- A record of each morning's review, for client reports and questionnaires.
The morning check, shortened to what matters
The engineer opens one screen. Across all clients, it shows a short list: a failed server backup that already has a ticket, a Microsoft 365 mailbox for a new starter that is not in any backup policy, and a workstation whose backup has not run for a week because it has been off. The rest is green. The check takes minutes and is logged.
At month end, backup success and coverage figures go into each client's report without anyone collecting them by hand.
Coverage is the part most MSPs have never been able to see. When a client's new starter gets a mailbox, the tenant shows it the next morning, and if the Microsoft 365 backup policy does not include it, the gap appears on the screen straight away. When a server is added to the RMM for a client with an image backup in their contract, the view expects a job for it within a day or two. The engineer either adds it to a schedule or marks it as excluded with a reason, and that decision is kept, so the same gap does not keep reappearing.
Do your backup checks work like this?
- Checking backups means logging into several consoles.
- Backup alerts go to an inbox full of success emails.
- You have found a device or mailbox with no backup at all.
- The morning check is skipped when the desk is busy.
- Warnings are treated the same as successes.