How managed backup services work and what to expect

Most small businesses do not shop for managed backup because they got excited about backup. They shop for it because something went wrong, or almost went wrong, and they realized that the quiet service running in the background was not as healthy as they assumed. A server crashed and the restore did not work. A ransomware incident hit a peer in their industry. An auditor asked for documentation that did not exist. At that point, handing backup to someone whose full-time job is keeping backups running starts to look reasonable.

But “managed backup” is a loose term. Two providers can describe their service the same way and deliver very different things. One might install an agent, point it at cloud storage, and send you a monthly invoice. Another might monitor every job daily, run documented test restores, and take operational responsibility for making sure your data is actually recoverable. The difference only becomes visible when you need a restore.

This article walks through what a real managed backup service does, what the onboarding process looks like, what you should expect on an ongoing basis, and how to evaluate providers without getting talked into a brochure version of the truth.

What a managed backup service actually covers

A managed backup service is a subscription where a provider takes operational responsibility for your backup and recovery. They supply the software, the storage, the monitoring, and the people who respond when something breaks. You pay a recurring fee and receive working, tested, recoverable backups as the outcome.

This is broader than just Backup as a Service. BaaS is the product layer: the software, the cloud storage, the portal. A managed backup service adds the human layer around it – a team that watches the jobs, handles the failures, runs the restores, and tunes the configuration as your environment changes. In practice, most good BaaS offerings are sold as managed services, because the value of the service is the operations work, not the software license.

A managed backup service typically covers four categories of systems:

• Servers. Physical and virtual, on-premises or in a colocation facility. Backups include operating system, applications, and data, with bare-metal or image-level recovery where supported.
• Workstations. Laptops and desktops, especially for users who keep important data locally instead of in cloud storage. Often skipped in self-managed setups and often the first thing that causes pain when it is not there.
• Cloud applications. Microsoft 365 mailboxes, OneDrive, SharePoint, Teams, and similar services for Google Workspace. Microsoft does not back up your tenant data the way most people assume, and the built-in retention is not enough to recover from deletion, corruption, or a compromised account.
• Applications with special backup needs. Databases (SQL Server, MySQL, Postgres), line-of-business applications, and accounting systems like QuickBooks that need application-aware snapshots rather than raw file copies.

A provider who only backs up servers and ignores everything else is not delivering a complete service. When you ask for a proposal, ask explicitly which of these four categories are in scope.

What happens during onboarding

Onboarding is the part of the relationship that tells you the most about how the provider operates. A sloppy onboarding is a preview of a sloppy service. A methodical one usually means the team has done this enough times to know where things go wrong.

Environment discovery

The first phase is figuring out what actually exists. The provider asks for a list of servers, workstations, applications, and cloud tenants to protect. They ask about data volumes, retention requirements, and any compliance constraints. They also ask about recovery objectives: how quickly you need to be back up after an incident, and how much data loss is acceptable. If those terms are unfamiliar, the RTO and RPO article explains what they mean and how to figure out yours.

Expect a provider to push on this step rather than accept rough answers. “Everything needs to be back in an hour” sounds reasonable in a meeting, but it has serious cost implications and is rarely what the business actually needs when you map it to individual systems. A good provider will help you sort the critical systems from the nice-to-have ones.

Sizing and proposal

Once they understand your environment, the provider sizes the storage, licensing, and infrastructure needed. For businesses with significant on-premises data, this often includes a local backup appliance for fast recovery in addition to cloud replication. For cloud-heavy environments, it might be entirely cloud-to-cloud.

The proposal should spell out:

• What systems are covered
• Backup frequency and retention for each category
• Where backup data is stored and how many copies
• Recovery targets (RTO and RPO) for each tier of systems
• What support is included
• What tests are run and how often
• What the monthly cost includes and what is billed separately

If the proposal is a single line item with no detail, push back. Vague proposals lead to disputes later about what was actually promised.

Agent deployment

Once the agreement is signed, the provider deploys backup agents to your systems. This is usually done remotely for workstations and servers using your existing RMM tool or a deployment script, and through API integration for Microsoft 365 and other SaaS applications. For servers and databases, there is often a scheduled window to avoid impacting performance during business hours.

Expect the initial deployment to take anywhere from a few days for a small environment to a few weeks for a larger one with multiple sites. The long tail is usually edge cases: a server with an unusual operating system, a database that needs application-aware configuration, a SharePoint site with non-standard permissions. Good providers work through these methodically instead of cutting corners.

Initial seed backup

The first full backup is the heaviest. For a business with a few terabytes of data and a normal internet connection, the initial seed can take days or weeks to upload. Providers handle this in one of three ways:

• Direct upload. The fastest path if you have spare bandwidth. Expect the provider to throttle during business hours to avoid saturating your connection.
• Seed device. The provider ships a physical drive or appliance, your team copies the initial backup onto it, and ships it back. Once loaded into the provider’s environment, subsequent backups are incremental and ride over the network.
• Local appliance first. If a local backup appliance is part of your deployment, the initial backup stays on-site and replicates to the cloud in the background over days or weeks.

Ask how they handle the seed. For anything larger than a few hundred gigabytes, direct upload is often not practical.

Configuration and policy tuning

Once backups are running, the provider tunes the configuration. Retention policies are set per system tier: critical servers might have 90 days of daily backups, 12 months of weekly, and 7 years of yearly; workstations might have 30 days. Backup windows are scheduled to avoid performance conflicts. Alerts and reports are configured.

This phase is where a lot of “managed” services quietly stop. The backups work, and the provider moves on. A real managed service keeps tuning as your environment changes.

Documentation and handoff

You should receive documentation at the end of onboarding: what is protected, where it is stored, what the restore process looks like, and who to contact for what. This documentation should be updated as things change. If the provider cannot tell you what is covered six months from now, the service is not actually being managed.

What you should expect on an ongoing basis

The difference between a real managed backup service and a thin one is in the day-to-day operations, not the initial setup. Here is what a serious provider does.

Daily monitoring and failure response

Every backup job is reviewed. When a job fails, someone investigates the cause, fixes it, and confirms that the next run succeeds. This is the single most valuable thing a managed service does, because failed backups in a self-managed environment often sit unacknowledged for weeks.

There is a meaningful difference between automated monitoring (the system sends an email when a backup fails) and active monitoring (a technician reviews failures every morning, regardless of whether an alert fired). Ask the provider specifically which one they do. If their answer involves an inbox and a best-effort response, that is automated monitoring with extra steps.

Periodic test restores

This is the question that separates most providers. Untested backups have a bad habit of failing when you need them. A managed service should run test restores on a defined schedule, covering different scenarios:

• File-level restore. Monthly or more frequent. Proves that the backup catalog is readable and individual files come back clean.
• Database restore. Quarterly at minimum. Proves that application-aware backups are actually application-aware and that the database comes up in a usable state.
• Full system or bare-metal restore. Annually. Proves that a critical server can actually be rebuilt from backup into a working state within the committed RTO.

Each test should be documented with what was restored, how long it took, and whether it succeeded. You should be able to ask for this documentation at any time. If the provider cannot produce it, the tests are not happening. If you are not familiar with why this matters, the backup testing article covers the categories of failure that only appear during a real restore.

Ransomware-aware backup architecture

Any modern managed backup service should be architected with ransomware in mind. That means:

• Backup copies that are immutable – they cannot be modified or deleted within the retention window, even by an administrator account
• Air-gapped or logically isolated offsite copies that are not reachable from the production network
• Separate authentication for the backup environment, so a compromised domain admin does not automatically mean a compromised backup
• Retention long enough to outlast dwell time – attackers often sit in a network for weeks before executing, and backups from the day of the attack may already be poisoned

If the provider cannot explain how their architecture survives a ransomware event that reaches your domain controller, keep looking. The ransomware and backup article explains why this matters.

Restore support

When you need data back, the provider handles it. What that looks like in practice varies. For a single deleted file, a self-service portal is often enough. For a database corruption or a full server rebuild, you want to be able to open a ticket and have the provider do the work.

Ask what the restore response time looks like for different scenarios. A serious provider will give you SLAs: four hours to start working a critical server restore, file-level requests within one business day, Microsoft 365 mailbox restores within a specific window. A less serious provider will promise best effort.

Monthly reporting and reviews

You should receive a monthly report showing backup job status, data volume trends, storage utilization, restore test results, and any incidents. Reports are useful for compliance documentation and for spotting trends – a server whose data is growing 10% per month needs attention before the backup window stops fitting.

For relationships beyond a few users, expect quarterly reviews where the provider walks through the report, flags risks, and proposes changes. This is also where backup scope gets adjusted: a new server added, an old one retired, a retention policy updated for a new compliance requirement.

Configuration drift management

Environments change. A new application goes in without backup being considered. A server is rebuilt and the agent is not reinstalled. A Microsoft 365 tenant adds a domain and the backup scope is not updated. Over time, these small gaps accumulate into a backup that covers half of what it should.

A real managed service catches this. The provider checks backup coverage against your actual environment regularly, usually through integration with an RMM tool or periodic audit. When something is missing, they flag it and add it.

SLA expectations: what to ask for in writing

SLAs are where marketing claims meet reality. Get specifics in writing. (What is an SLA and why it matters for your IT support covers the general framework – response vs resolution, priority tiers, service credits – that applies equally to backup SLAs.)

• Backup success rate. What percentage of scheduled jobs complete successfully? Anything below 99% over a month is a problem. Ask how they measure, because selective reporting is common.
• Recovery time objective for each system tier. The provider commits to starting and completing a restore within a defined window. Understand whether the SLA is to start the restore or to complete it.
• Recovery point objective. How much data loss is acceptable in a worst case? This determines how often backups run. Daily backups mean up to 24 hours of lost data in an incident.
• Monitoring response. How quickly is a failed backup investigated? A same-business-day commitment is reasonable. A 72-hour response is not.
• Restore response. For critical systems, expect a commitment measured in hours. For file-level requests, a business-day commitment is normal.
• Test restore documentation. Provider commits to running specific tests on a specific schedule and providing documentation of results.

If a provider is reluctant to put these in writing, they are not going to deliver them in practice.

What is usually out of scope

Even a well-scoped managed backup service has boundaries. Clarify these upfront.

Endpoint-level user data that was never on a backed-up system. If a user saves a critical file only to their desktop and the desktop is not in the backup scope, it is not covered. Workstation backup is an option, but usually billed separately and often declined for cost reasons. Users need to understand where to save work.

Legal hold and e-discovery. Standard retention is built around operational recovery, not litigation. If you need to preserve specific mailboxes beyond normal retention for a legal matter, that is usually a separate feature and may cost extra.

Data loss prevention and classification. Backup protects against data loss; it does not classify what your sensitive data is or prevent it from being exfiltrated. Those are separate security controls.

Disaster recovery beyond data. Managed backup gets your data back. Getting your business back – reconnecting users, redirecting DNS, spinning up replacement infrastructure, coordinating with staff – is disaster recovery, which is a broader service. A managed backup provider may offer DR as an add-on or as part of a larger managed backup and disaster recovery relationship, but it is worth understanding the distinction.

Very large restores at unusual speeds. Shipping physical media for a multi-terabyte restore, or provisioning emergency cloud infrastructure for failover, is often billed separately. Your standard restore SLA assumes normal network-based recovery.

How to evaluate and compare providers

When you compare proposals, push beyond the brochure.

Ask how they handle a scenario. Give them a realistic situation: a file server is ransomware-encrypted on a Friday night, your domain admin credentials were likely compromised, and the business needs to be operational by Monday morning. Ask how their service responds. Answers that involve “we would coordinate with you” are weaker than answers that include specific steps, specific tools, and specific timelines.

Ask for restore test documentation. A serious provider can produce anonymized examples. If they cannot, tests are not being run consistently.

Ask for a reference who went through a real restore. Anyone can say they do managed backup. A customer who needed a restore and got one tells you more than a sales pitch.

Compare total cost honestly. Cheaper monthly pricing with per-GB storage overages and per-restore fees often ends up more expensive than a higher bundled price with clear scope. Run the numbers on your actual environment.

Understand their stack. Do they use a well-known backup engine (Veeam, Datto, Acronis, Axcient, Commvault) or something proprietary? Proprietary is not inherently bad, but a standard engine means the skills and documentation exist to migrate if the relationship ends. Ask how data portability works if you leave.

Check their response time on a non-urgent question. Send a question during onboarding and see how quickly and specifically they respond. That response time is usually a good predictor of what support looks like once you are a customer.

How Sequentur delivers managed backup

We run managed backup as part of our broader managed IT relationship, not as a standalone product. For most clients, that means a local backup appliance for fast recovery, cloud replication for offsite protection, and Microsoft 365 backup through an independent provider. We configure immutable retention and separate authentication on the cloud copies so that a compromise of a client’s domain does not reach the backup environment.

Backup jobs are reviewed daily by our operations team, not triaged from an alert queue. We run file-level test restores monthly, database restores quarterly, and full system restores annually for critical servers, and we keep the documentation so we can produce it for audits or for our own verification. When a client needs a restore, we handle it directly, and we track restore metrics against the RTOs we committed to in the original scope.

We also keep the backup scope in sync with the environment. When a new server goes in or a workstation is swapped, backup coverage is updated as part of the normal change process rather than as a separate project.

If you are running backup internally and are not sure whether it would survive an actual incident, or if you are on a managed backup service today and the answers to the questions in this article are making you uncomfortable, we are happy to review your current setup and tell you honestly what we see. You can reach us through our contact page to start that conversation.