How to define, package, and deliver a managed backup service MSPs can stand behind
Ask ten MSPs to describe their managed backup offering, and most will say some version of the same thing: "We monitor your backups and fix issues when they come up."
You're babysitting a product you don't own.
A defined service with documented commitments, tested recovery outcomes, and a clear scope is what separates that from real managed backup. When you build it that way, it becomes a revenue engine instead of a support burden.
The first post in this series covered how ransomware turned backup into a board-level concern, why executives started demanding proof of recovery, and what that means for MSPs who haven't adapted yet. The second made the financial case for moving from a reseller model to a managed one. This post takes the next step. Now that you have the why and the financial case, here's what the service should look like on the ground.
A managed backup service covers five things:
Monitoring alone leaves you exposed. When the client's server won't come back up after a ransomware hit, "we were monitoring it" is not a reassuring sentence.
When you define managed backup this way, in writing and in your service agreement, you also close the scope creep door before it opens. "Managed" means something specific. Everything outside that scope requires an explicit conversation before anyone lifts a finger.
The service promise worth making is that you guarantee your clients' systems can be recovered, and you can prove it. That's what separates you from someone who sold a license.
One of the most expensive mistakes in managed backup is skipping the discovery step. Before you can make any meaningful recovery commitment, you need to understand what you're protecting, and that varies enormously from client to client.
Walk every new engagement through a simple data classification exercise:
| Data Type | What It Includes | Backup Frequency | Retention |
| Critical | Databases, ERP, billing systems | Daily minimum | 90 days or per compliance requirement |
| Operational | Email, shared drives, productivity tools | Daily | 30–90 days |
| Business Records | Financial documents, contracts, compliance records | Daily or weekly | 6–10 years (regulatory minimum in most jurisdictions) |
| Personal / Regulated | Employee and customer PII: HIPAA, GDPR, CPRA, PCI-DSS | Per regulation | Per regulation |
This inventory does two things at once. First, it tells you how to architect the backup environment. You know what recovers first, how often, and how long it needs to be retained. Second, it surfaces compliance obligations the client may not even realize they have.
Most business records are legally required to be retained for six to ten years. Most SaaS apps are not backed up by default. Clients rarely know either of those things until you tell them. The ones who do understand why their SQL database has a different recovery profile than their file server are the ones who don't argue about scope when an incident happens.
That clarity is rarer than it should be. 62% of organizations fail to conduct regular system backups and restoration exercises (Cockroach Labs, State of Resilience 2025). Your discovery process is often the first time anyone has asked these questions seriously.
RPO and RTO are probably the most mishandled commitments in managed backup. MSPs either overpromise because a competitor did or leave them undefined entirely and let clients assume the best case. Both are problems.
RPO (Recovery Point Objective) is how much data can be lost. If your RPO is 4 hours, the client may lose up to 4 hours of changes in a worst-case scenario. RTO (Recovery Time Objective) is how fast systems can be restored. If your RTO is 2 hours, you're committing to operational recovery within 2 hours of initiating the process.
Your architecture determines your commitments. As covered in Post 1, cloud-only recovery over a standard broadband connection can take days. That constraint needs to live in your architecture decisions before you make any promises to clients.
A practical starting point by workload type:
| Workload | Architecture | RPO | RTO | Notes |
| File server | Local + cloud hybrid | 4 hours | 2 hours | — |
| SQL database | Local + cloud hybrid | 1 hour | 4 hours | Requires hourly incremental jobs to be configured |
| Virtual machines | Local snapshot + cloud | 4 hours | 1–2 hours | — |
| SaaS (M365, Google Workspace) | Third-party backup | 24 hours | 4–8 hours | — |
| Endpoints / workstations | Cloud backup | 4–8 hours | 4–8 hours | Cloud restore only; no local copy |
A note on cloud-only setups: These figures assume a hybrid local + cloud architecture for servers. If your clients rely on cloud-only backup, your committed RTOs will be significantly longer.
These are illustrative starting points. Your actual commitments depend on your stack and each client's environment. Having defined them in writing before something goes wrong is what separates a professional incident response from a chaotic one. When something fails at 2am, you want a documented plan, not a conversation about what you think you might be able to do.
If you're working through what commitments you can realistically make for your client base, we can walk through that with you. Talk to a NovaBACKUP expert.
The two most common tier design mistakes are building too many (six tiers with overlapping features that paralyze clients) or too few (one flat offering that leaves revenue on the table). The right starting point is two tiers.
Add a third tier only when you have clients with genuinely distinct needs. Healthcare and finance are the most common cases.
When it comes to naming, skip Gold/Silver/Bronze. Those names tell clients nothing about what they're getting. Names like Protect and Recover, or Essential and Resilient, communicate outcomes, which is what you're selling.
The MSP-controlled versus customer-owned infrastructure question is fundamentally about liability. In an MSP-controlled model, you standardize the stack, deploy it, and own the outcome. It's the cleaner arrangement, with less variability, more predictable margins, and easier SLA guarantees.
In a customer-owned model, you're managing their existing environment. That means higher complexity, harder-to-guarantee outcomes, and more caveats in your service agreement.
Most MSPs live in a hybrid reality, inheriting some customer infrastructure while deploying their own stack for new clients. That's fine. The key is to document clearly, before you sign anything, who owns what. That means who's responsible for the hardware, who controls the software credentials, and what happens to the data at contract end.
Something will eventually go wrong. That clarity is what protects everyone when it does. Without it, that conversation happens under the worst possible conditions.
The configuration work happens at onboarding. Each client's backup jobs are set up to match the data classification and RPO/RTO commitments you've defined. Once they're running, the platform needs to let you manage all of them without logging into 20 separate PCs remotely.
NovaBACKUP's multi-tenant management console gives you a single view across all your clients' backup jobs. For an MSP managing 20 or more clients, that's what makes the monitoring component of a managed service practical at scale. You see what's running, what's failed, and what needs attention without switching contexts.
Client-facing reporting turns the RPO/RTO commitments you made in your service agreement into documented proof. The reporting output is how you deliver that proof in a format a non-technical stakeholder can read in a quarterly business review.
Automated restore testing via backup verification backs your recovery commitments as part of your job completion logs.
If you read Post 2, you'll recognize Michael Gustine of MG Technology — a one-man MSP who projected 17–25% customer base growth without adding staff after transitioning to NovaBACKUP Managed Backup. The service structure described in this post is exactly what he built. Read the full case study.
FAQ
A managed backup service covers deployment and configuration, ongoing monitoring, regular restore testing, client-facing reporting, and a defined incident response process. Monitoring alone tells you whether a job ran. A managed service means you own what happens next, including whether the backup can be recovered when it counts.
FAQ
RPO (Recovery Point Objective) is how much data a client can afford to lose, measured as the time since the last good backup. RTO (Recovery Time Objective) is how quickly systems must be back online after a failure. Both need to be documented before an incident. Trying to establish them during a recovery is a conversation nobody wants to have.
FAQ
Start with two tiers: a base tier covering essential daily backups and monthly restore verification, and a premium tier with shorter RPO/RTO commitments, immutable copies, and compliance-ready documentation. See the service tiers section above for the full breakdown. Add a third tier only when a client segment genuinely requires it.
FAQ
Your data classification determines your recovery architecture. Without it, you can't set realistic RPO/RTO commitments, because not all data has the same recovery priority. A regulated PII database and a shared file drive do not belong in the same backup tier, and treating them the same way creates both technical risk and compliance exposure.
FAQ
Monitoring tells you whether backup jobs ran without an error code. Managing backup means you own the outcome. You configure the environment, you test that recovery works, and you can produce documented proof when a client or auditor asks for it.
Your customers want to buy the confidence that their business will survive a disaster. Backup software is simply the means to deliver it. 16% of SMBs never back up their data (Viking Cloud, 2025). And they know something is missing. They're waiting for an MSP who can name it clearly and fix it.
The data classification, the RPO/RTO commitments, the service tiers, and the ownership documentation are all infrastructure for that confidence. When you define your managed backup service with this kind of clarity, you're selling a professional relationship with documented accountability. That's a different (and in a lot of cases easier) conversation than selling a subscription.
Ready to see what this looks like on a real platform? Talk to a NovaBACKUP expert and walk through how the managed model fits your service structure.
This post is part of The Managed Backup Playbook for 2026, a five-part series for MSPs building or growing a managed backup service.