7 Backup as a service for providers is a different problem from backup for a single company. An enterprise protects its own data with one policy set and one security team. A service provider, managed service provider (MSP) or telco protects hundreds or thousands of tenants, each with its own retention rules, its own administrators and its own expectations about what happens when something goes wrong. The storage platform behind the service has to keep every tenant separate, survive the ransomware attack that hits one of them, and still make money at the price the market will pay. This article walks through the building blocks of a backup-as-a-service (BaaS) offering from the provider’s side: what the service actually sells, the target storage architecture, multi-tenancy, immutability, pricing and the operational model that keeps it profitable. If you are evaluating BaaS as a buyer instead, see storage as a service. What a BaaS offering actually sells Tenants are not buying terabytes. They are buying a promise: that their data leaves their site, lands somewhere safe, cannot be deleted by an attacker who owns their network, and comes back fast enough to matter. Most provider offerings fall into a few patterns: Backup copy target. The tenant runs its own backup software on site and sends a second copy to the provider, often over a native cloud connector or an S3 endpoint. This is the most common entry point. Fully managed backup. The provider runs the backup software, schedules jobs and handles restores. The tenant buys an outcome. SaaS application backup. Protection for hosted email, collaboration and productivity platforms, where the provider hosts both the software and the storage. Backup plus recovery. Backup storage combined with the ability to restore workloads into the provider’s infrastructure, which shades into disaster recovery as a service. Each pattern places different demands on storage. A copy target needs high ingest at night and fast bulk restore on a bad day. Managed backup adds the provider’s own operational access. SaaS backup produces huge numbers of small objects. Choosing the target storage architecture The backup software defines how data is written, but the storage target decides cost, density and how far the service can grow. Providers typically consider three options. Block or file repositories Traditional repositories on servers with local disks or NAS are simple to start with. They become harder to manage as tenant count grows: capacity is fragmented across many boxes, rebalancing is manual, and every hardware refresh means moving tenant data. Hardened Linux repositories Hardened repositories add immutability on a Linux server with restricted access. They work well for individual tenants or small deployments, but each one is still a separate box to size, patch and refresh. S3-compatible object storage Object storage pools capacity across many servers, scales by adding nodes and exposes the S3 API that most modern backup software can write to directly. It supports object lock for immutability, per-tenant accounts and buckets, and erasure coding for efficient protection. For providers planning past a few hundred terabytes, it is usually the foundation. Our guide to multi-tenant object storage explains how one platform serves many customers, and what is S3-compatible storage covers compatibility questions. Whatever you choose, test it with the backup software you plan to support. Compatibility claims vary, and real-world testing of S3 behavior under load saves painful surprises. The ARTESCA team has published a practical guide to S3 backup compatibility testing. Multi-tenancy and isolation A BaaS platform has to make every tenant feel like the only one. That means: Separate identities and credentials per tenant, so one tenant’s keys can never reach another tenant’s data. Quotas to stop a single tenant from consuming shared capacity unexpectedly. Per-tenant encryption options, including tenant-held keys for regulated customers. Performance isolation so one tenant’s full backup does not slow everyone else’s restores. Separate reporting and billing data per tenant. The provider’s own administrative access needs equal care. If one compromised provider credential can delete every tenant’s backups, the service has a single point of failure. Immutability as a product feature Ransomware changed BaaS from a convenience into a recovery requirement. Attackers routinely look for backup systems and try to delete or encrypt them before triggering an attack. Tenants now ask directly whether their offsite copy can survive a compromise of their own environment. Immutability answers that question. With object lock in compliance mode, backups cannot be altered or deleted until retention expires, even by an administrator. Some backup platforms also offer a provider-side recycle bin that keeps deleted tenant backups for a period set by the provider. Providers often package these capabilities as tiers: standard retention, immutable retention and extended immutable retention at a premium. Immutability consumes capacity, because locked data cannot be cleaned up early. Plan for it explicitly; immutable backup capacity covers the sizing impact. For the principles, see ransomware-proof backup and the 3-2-1-1-0 backup strategy. Pricing and packaging Most providers price on stored capacity per month, sometimes combined with a per-workload fee (per VM, per server, per user for SaaS backup). The key decisions are: Billable unit. Logical protected data, stored data after deduplication and compression, or raw capacity consumed. Each has different margins and different customer perception. Included features. Whether immutability, restore traffic, early deletion and support are included or charged separately. Commitment levels. Reserved capacity discounts versus pure pay-as-you-go. Margin depends heavily on what the storage costs per usable terabyte over its full life, including protection overhead, power, rack space and refresh. Our article on storage pricing for service providers works through the model, and storage cost per terabyte covers the cost side. Service levels and restore performance Tenants judge BaaS on the restore, not the backup. The SLA should state what is guaranteed and what is a target: Backup availability and durability. Time to begin a restore after a request. Expected restore throughput for large recoveries. Notification and support response times during an incident. Mass restore is the scenario that breaks undersized platforms. When a ransomware event hits a large tenant, or several tenants at once, the platform must deliver sustained read throughput while still taking in nightly backups from everyone else. Plan and test for it; mass restore planning covers what to model. The general structure of an SLA is explained in what is an SLA. Operating the platform at scale The economics of BaaS improve with scale only if operations do not grow linearly with capacity. Practices that keep the platform manageable include: Automated tenant onboarding, creating accounts, buckets, quotas and policies through APIs. Monitoring per tenant, with alerts for missed backups, quota pressure and unusual deletion patterns. Growth in small increments, adding nodes without migrating tenant data. Object storage expansion explains how to plan it. Hardware refresh in place, replacing old servers while the service stays online. Regular restore tests on representative tenant data, since a backup that cannot be restored is a liability. Checklist: building backup as a service for providers Define which service patterns you will offer: copy target, managed, SaaS backup, recovery. Choose a target platform that scales by adding nodes and speaks the S3 API. Validate compatibility and performance with each backup application you support. Enforce tenant isolation for identity, data, encryption, quota and performance. Offer immutability, and size capacity for locked retention. Separate provider administration from tenant administration and protect provider credentials. Choose a billable unit and model margin per usable terabyte over five years. Write SLAs around restore, and test mass restore at realistic scale. Automate onboarding, monitoring and billing data collection. Putting it together Backup as a service for providers succeeds when three things line up: a storage platform that keeps tenants isolated and immutable at scale, a pricing model grounded in the real cost per usable terabyte, and operations that do not grow with every new customer. Start with the restore promise you want to make, build the platform that can keep it under pressure, and package the features tenants now expect, especially immutability, as clear tiers of the service. Frequently asked questions What storage do backup-as-a-service providers use? Many start on server-based repositories and move to S3-compatible object storage as they grow, because it pools capacity, scales by adding nodes and supports immutability and multi-tenancy natively. How do providers keep tenant backups separate? Through separate accounts, credentials, buckets, quotas and encryption per tenant, plus separation between provider and tenant administration. Should BaaS include immutability by default? Increasingly, yes. Many tenants buy BaaS specifically for ransomware recovery. Providers often include a base immutable period and charge for longer retention. How are BaaS offerings usually priced? Most charge per stored terabyte per month, sometimes with a per-workload or per-user fee. Restore traffic and extended immutability are often priced separately. What is the biggest operational risk for a BaaS provider? A mass restore during a widespread ransomware event, where read demand spikes while nightly backups continue. Platforms should be sized and tested for that scenario. Further reading Storage pricing for service providers Launching an S3 storage service Internal backup service chargeback Multi-tenant object storage
