An MSP that isolates each client in its own bucket

The challenge

The MSP manages backup for several organizations, each with its own Synology NAS as primary storage and as the starting point for the copies. The problem isn't a single client's technical issue, but one of scale and isolation: when you offer backup as a service to many companies at once, you need to guarantee that one client's data can never touch another's, that billing is clear and attributable, and that each account has the level of retention and immutability its contract requires.

The usual solutions force a choice between two evils. Either you build and maintain your own storage infrastructure (arrays, disks, replacements, expansions, patching, monitoring), which turns the MSP into the operator of a datacenter that isn't its business. Or you dump everything into a single shared destination, where the separation between clients relies on prefixes and naming conventions instead of real boundaries, and where a single compromised credential exposes the entire portfolio.

On top of that comes the mechanics of Hyper Backup itself, which generates many small requests (listings, incremental writes, checks, version rotation). With providers that charge per request and per delete, multiplying that across an entire client portfolio makes the cost hard to predict and to pass on.

The solution with OtterStorage

The model is deliberately simple: a separate bucket per client. Each client materializes as its own bucket in OtterStorage, and each bucket has its isolated access keys, generated and restricted to that bucket. The key a NAS uses to write only grants access to its own bucket; there is no global credential that could list or read the rest of the portfolio.

On the client side there's no need for middleware or proprietary agents. The Synology NAS treats OtterStorage as a standard S3 destination, so Hyper Backup points directly to the endpoint https://es-mad-1.s3.otterstorage.io with v4 signing and HTTPS. In DSM it's set up as a custom S3 server, with the bucket details and the corresponding region (for example eu-mad to keep the data in the EU):

Server address:      es-mad-1.s3.otterstorage.io
Signature Version:   v4
Bucket name:         cliente-acme-backup
Access Key / ID:     (key isolated to that bucket)
Secret Key:          (key isolated to that bucket)
Region:              eu-mad

The separation is total because it doesn't rely on conventions, but on OtterStorage's own boundaries: each bucket is an independent unit of storage, credentials, policies and consumption. This also lets you apply immutability or Legal Hold bucket by bucket, tailoring the protection to each client:

• Object Lock (WORM), Governance or Compliance modes: for clients that require unalterable retention of their copies, the bucket is created with Object Lock and a retention policy; within that period no one can delete or overwrite an object, not even with the bucket's own credentials. Compliance mode makes it strict even against administrators.
• Bucket-level Legal Hold: when a client needs indefinite retention (due to a legal request or an investigation), Legal Hold is enabled on its bucket without affecting the rest of the portfolio.
• Versioning and lifecycle: each bucket can have its own versioning and lifecycle rules, so Hyper Backup's version rotation coexists with the retention policy agreed with each client.

Billing becomes clear precisely because consumption is separated per bucket: each client's storage is directly attributable in TB, with no need to prorate a shared pool. And since with OtterStorage there is no cost for requests (PUT/GET/LIST) or for deletes (DELETE), Hyper Backup's small-request-intensive nature doesn't distort the bill: the MSP pays per TB stored and bills per TB, with a predictable margin.

The operational outcome is that the MSP stops maintaining its own storage infrastructure. There are no arrays to expand, disks to replace or capacity to provision months in advance: onboarding a new client is creating a bucket and a set of keys, and offboarding is deleting that bucket in isolation.

If you want to reproduce this setup, the specific pieces are documented: the Synology to S3 guide for pointing Hyper Backup to the endpoint, how to manage per-bucket isolated access keys, the configuration of Object Lock and Legal Hold bucket by bucket, and the detail of per-TB pricing with no cost for requests.

Results

• 1 ↔ 1, one bucket per client: total separation between clients backed by real storage boundaries, not naming conventions.
• Isolated access keys: each NAS writes with credentials restricted to its own bucket; a compromised key does not expose the rest of the portfolio.
• Native Synology: Hyper Backup points directly to the S3 endpoint from DSM, with no agents or middleware.
• Tailored immutability: Object Lock (Governance or Compliance) and Legal Hold are enabled bucket by bucket according to what each client requires.
• Clear per-TB billing: consumption is attributable per client, with no cost for requests or deletes to distort the pass-through.
• No in-house infrastructure: onboarding and offboarding clients comes down to creating or deleting a bucket and its keys; no arrays, disks or provisioning.