Backup Gaps You Can Prove From Your Own RMM

Every MSP sells backup. Almost every MSP has at least one client with a server that is billed as protected and is not.

This is not negligence. It is the predictable result of an estate that changes faster than the paperwork: a server gets rebuilt and the agent does not come back, a VM gets added during a project and never enrolled, a job starts failing and the alert lands in a mailbox nobody reads. Each is small. Together they mean the sentence "your servers are backed up" is a belief rather than a fact.

The MSPs who turn this into revenue are not the ones with the best backup pitch. They are the ones who can put a specific, checkable list in front of a client: these six servers have no verified restore point.

Three Different Gaps, Three Different Conversations

Precision matters here, because the three failure modes call for completely different responses and clients can tell when you have blurred them.

Not protected at all. No backup agent, no job, no vendor record. The machine exists in the RMM and appears nowhere in the backup system. This is the gap that keeps people awake.

Protected but failing. The job exists and has been failing for eleven days. Somebody is being emailed about it and nobody is reading the email. The client believes they are covered because they are paying for it.

Backed up but never tested. Jobs succeed, restore points exist, and nobody has ever performed a restore. A backup you have not restored from is a hypothesis. This is the least urgent and the most commonly ignored.

The first is an emergency. The second is a service failure you own. The third is a project you can sell. Presenting them as one undifferentiated "backup gap" wastes the first and overstates the third.

How to Build the List

The reconciliation is between two systems you already run.

From the RMM, get the inventory: every server and workstation reporting in, with last-seen dates. Filter to what actually matters — a machine that has not checked in for ninety days is probably decommissioned, and including it makes your whole list look sloppy.

From the backup vendor, get protected assets with their last successful restore point. Whether that is a BCDR appliance, a cloud backup console, or a virtualization-aware platform, the export you need is the same: what is protected, and when did it last succeed.

Match them, and be careful about naming. Hostnames drift between systems and case-sensitivity is a real source of false positives. Nothing destroys a backup report faster than telling a client a server is unprotected when it is protected under a slightly different name. Match on more than one attribute where you can.

Then classify each result into the three buckets above and attach a date to every claim. "Not backed up" is arguable. "No successful restore point since 14 June" is not.

What It Is Worth

Two numbers matter in this conversation and only one of them is your invoice.

Your revenue. Backup and disaster recovery per protected server typically runs $65–$150 a month depending on retention and how the workload is protected. Six unprotected servers at $95 is $6,840 a year from one client.

Their exposure. This is the number that makes the decision. Ask the client what a day of downtime costs — not what you think it costs, what they say it costs. Most have never calculated it, and the act of calculating it out loud does more selling than any statistic about ransomware you could quote.

Cyber insurance is the other lever, and increasingly the decisive one. Most policies now require verified, tested backups; renewal questionnaires ask directly. A client who answers "yes" while six servers have no restore point has a coverage problem that is far more expensive than your BDR line item. You are not selling backup at that point. You are protecting a claim.

Presenting It Without Sounding Like a Scare Campaign

Backup findings are the easiest thing in this category to overplay, and clients have heard the fear pitch before.

Own the ones that are yours. If a server is in your backup contract and has no restore point, that is your failure before it is their risk. Say so first, fix it without charging, and then talk about the ones that were never in scope. An MSP who opens with "three of these are on us and we are fixing them today" has earned the right to the rest of the list.

Show dates, not adjectives. "Unprotected" invites debate. "No successful restore point since 14 June — 44 days" ends it.

Rank by consequence, not by count. The domain controller and the line-of-business database matter more than six workstations. A list ordered by what would actually stop the business is more persuasive than a longer list ordered alphabetically.

Offer the test, not just the product. For clients in the third bucket — backed up, never restored — the sale is a restore test, not more backup. It is a small paid engagement, it is genuinely valuable, and it either proves the backups work or finds the problem while nobody is under pressure. Both outcomes are good for you.

Make It Continuous

A backup gap report is only true on the day you run it. Servers get rebuilt, jobs fail, VMs appear.

The MSPs who do this properly run the reconciliation continuously and treat any new unprotected asset as an internal alert rather than a quarterly discovery. The QBR slide then shows a trend — protected assets versus total, over time — which is a far better artifact than a one-off audit. It demonstrates that the number is being watched, which is ultimately what the client is paying you for.

Frequently Asked Questions

We already get backup failure alerts. Isn't this the same thing?

Alerts tell you a job you know about failed. They cannot tell you about a server nobody ever enrolled, which is the more dangerous gap. Reconciling the RMM inventory against the backup inventory catches the machines that were never in the alerting system to begin with.

What counts as "verified"?

At minimum, a successful job with a restore point inside your stated recovery point objective. Properly, a restore that someone actually performed. The distance between those two definitions is where most unpleasant surprises live, and it is worth being explicit with clients about which one you are reporting.

The client refused backup for that server two years ago. Is it still a gap?

Yes, and it should still appear on the list — annotated as declined, with the date. Documented declines protect you, and circumstances change. A server the client called unimportant in 2024 may be running something critical now. Re-presenting it once a year is diligence, not badgering.

How do we avoid false positives from hostname mismatches?

Match on more than one attribute — hostname plus serial, or hostname plus IP where it is stable — and normalize case and domain suffixes before comparing. Then eyeball the first report before it goes anywhere near a client. One wrong entry costs more credibility than ten correct ones earn.

---

MSProspector is built by Marketopia, the MSP channel's growth partner since 2014. Client Upsell reconciles your RMM inventory against your backup platform read-only and separates the servers that are unprotected, failing, and untested. See how it works.