Un MSP que aísla a cada cliente en su propio bucket

El reto

El MSP gestiona el backup de varias organizaciones, cada una con su propio NAS Synology como almacenamiento primario y como punto de partida de las copias. El problema no es técnico de un solo cliente, sino de escala y de aislamiento: cuando ofreces backup como servicio a muchas empresas a la vez, necesitas garantizar que los datos de un cliente nunca puedan tocar los de otro, que la facturación sea clara y atribuible, y que cada cuenta tenga el nivel de retención e inmutabilidad que su contrato exige.

Las soluciones habituales obligan a elegir entre dos males. O bien se monta y se mantiene infraestructura propia de almacenamiento (cabinas, discos, sustituciones, ampliaciones, parcheo, monitorización), lo que convierte al MSP en operador de un datacenter que no es su negocio. O bien se vuelca todo a un único destino compartido, donde la separación entre clientes depende de prefijos y convenciones de nombres en vez de fronteras reales, y donde una sola credencial comprometida expone a toda la cartera.

A esto se suma la mecánica del propio Hyper Backup, que genera muchas peticiones pequeñas (listados, escrituras incrementales, comprobaciones, rotación de versiones). En proveedores que cobran por petición y por borrado, multiplicar eso por una cartera entera de clientes hace que el coste sea difícil de predecir y de repercutir.

La solución con OtterStorage

El modelo es deliberadamente simple: un bucket independiente por cliente. Cada cliente se materializa como un bucket propio en OtterStorage, y cada bucket tiene sus access keys aisladas, generadas y limitadas a ese bucket. La clave que un NAS usa para escribir solo da acceso a su propio bucket; no existe una credencial global que pueda enumerar o leer el resto de la cartera.

En el lado del cliente no hace falta software intermedio ni agentes propietarios. El NAS Synology trata a OtterStorage como un destino S3 estándar, así que Hyper Backup apunta directamente al endpoint https://s3.otterstorage.io con firma v4 y HTTPS. En DSM se configura como servidor S3 personalizado, con los datos del bucket y la región correspondiente (por ejemplo eu-mad para mantener los datos en la UE):

Server address:      s3.otterstorage.io
Signature Version:   v4
Bucket name:         cliente-acme-backup
Access Key / ID:     (clave aislada de ese bucket)
Secret Key:          (clave aislada de ese bucket)
Región:              eu-mad

La separación es total porque no se apoya en convenciones, sino en los propios límites de OtterStorage: cada bucket es una unidad independiente de almacenamiento, credenciales, políticas y consumo. Eso permite además aplicar inmutabilidad o Legal Hold bucket a bucket, ajustando la protección a cada cliente:

• Object Lock (WORM), modos Governance o Compliance: para clientes que exigen retención inalterable de sus copias, el bucket se crea con Object Lock y una política de retención; dentro de ese periodo nadie puede borrar ni sobrescribir un objeto, ni siquiera con las credenciales del propio bucket. El modo Compliance lo hace estricto incluso frente a administradores.
• Legal Hold por bucket: cuando un cliente necesita una retención indefinida (por un requerimiento o una investigación), se activa Legal Hold sobre su bucket sin afectar al resto de la cartera.
• Versionado y lifecycle: cada bucket puede tener su propio versionado y sus reglas de ciclo de vida, de modo que la rotación de versiones de Hyper Backup convive con la política de retención pactada con cada cliente.

La facturación se vuelve clara precisamente porque el consumo está separado por bucket: el almacenamiento de cada cliente es directamente atribuible en TB, sin necesidad de prorratear un pool común. Y como en OtterStorage no hay coste por peticiones (PUT/GET/LIST) ni por borrados (DELETE), la naturaleza intensiva en peticiones pequeñas de Hyper Backup no distorsiona la factura: el MSP paga por TB almacenado y repercute por TB, con un margen previsible.

El resultado operativo es que el MSP deja de mantener infraestructura propia de almacenamiento. No hay cabinas que ampliar, discos que reemplazar ni capacidad que aprovisionar con meses de antelación: dar de alta un cliente nuevo es crear un bucket y unas claves, y darlo de baja es eliminar ese bucket de forma aislada.

Si quieres reproducir este montaje, las piezas concretas están documentadas: la guía de Synology a S3 para apuntar Hyper Backup al endpoint, cómo gestionar las access keys aisladas por bucket, la configuración de Object Lock y de Legal Hold bucket a bucket, y el detalle de precios por TB sin coste por peticiones.

Resultados

• 1 ↔ 1, un bucket por cliente: separación total entre clientes apoyada en límites reales de almacenamiento, no en convenciones de nombres.
• Claves de acceso aisladas: cada NAS escribe con credenciales limitadas a su propio bucket; una clave comprometida no expone al resto de la cartera.
• Synology nativo: Hyper Backup apunta directamente al endpoint S3 desde DSM, sin agentes ni software intermedio.
• Inmutabilidad a medida: Object Lock (Governance o Compliance) y Legal Hold se activan bucket a bucket según lo que exige cada cliente.
• Facturación clara por TB: el consumo es atribuible por cliente, sin coste por peticiones ni por borrados que distorsione la repercusión.
• Sin infraestructura propia: alta y baja de clientes se reducen a crear o eliminar un bucket y sus claves; nada de cabinas, discos ni aprovisionamiento.