La mayoría de las decisiones sobre almacenamiento de backup se siguen tomando con una sola cifra: el precio por terabyte cotizado el día de la compra. Esa cifra es fácil de comparar y de defender, pero describe solo la primera de las muchas partidas de coste que un repositorio de backup genera a lo largo de su vida útil. El resto, desde la ampliación y la renovación del hardware hasta las renovaciones de soporte y las restauraciones lentas, es donde las dos principales opciones de arquitectura divergen.
Esas dos opciones son el appliance de backup de propósito específico, un conjunto integrado de hardware y software de deduplicación que se vende y se renueva como una unidad, y el almacenamiento de objetos software-defined, una licencia de almacenamiento que se ejecuta en servidores estándar y crece añadiendo nodos. Ambas son formas legítimas de alojar datos de backup; acumulan costes en lugares distintos y en momentos distintos.
Este artículo ofrece un marco neutral a cinco años: las partidas de coste, por qué el precio del primer día induce a error, una tabla comparativa, un ejemplo ilustrativo y una lista de comprobación para construir el modelo.
El coste total de propiedad (TCO) de un repositorio de backup es la suma de todos los costes que provoca entre la orden de compra y el día en que los datos se trasladan fuera de él: costes de capital, costes operativos recurrentes y costes menos visibles, como el tiempo del personal, la indisponibilidad durante las restauraciones y la migración al final de su vida útil.
La respuesta simplista considera el TCO como el precio de compra más un contrato de soporte. Ese enfoque falla en el almacenamiento de backup porque los datos crecen de forma continua, la retención se alarga y se espera que el repositorio sobreviva al menos a una generación de hardware. Un modelo que ignora el crecimiento, la renovación y la salida es una cotización del primer día con más decimales.
Un appliance empaqueta controladoras, bandejas de discos y software de deduplicación en un único producto con un único contrato de soporte. La capacidad está ligada al modelo adquirido: ampliar significa añadir bandejas hasta el límite de la controladora y, después, una cabecera mayor o un segundo sistema. Al final de su vida útil, la unidad completa suele sustituirse en una renovación total (forklift refresh), con la migración de los datos al sucesor.
El almacenamiento de objetos software-defined separa la licencia, normalmente tarificada por unidad de capacidad, del hardware, que son servidores estándar con discos internos. Crece añadiendo nodos y, como los servidores son intercambiables, distintas generaciones de hardware pueden convivir en un mismo clúster y los nodos antiguos pueden retirarse de forma individual.
Estas partidas aparecen en casi todos los modelos de TCO de almacenamiento de backup; su peso depende de la tasa de crecimiento, la política de retención y la dotación de personal.
Tres efectos hacen que la cotización inicial sea un mal indicador del coste a cinco años. Primero, la capacidad útil cotizada se basa en un supuesto de reducción de datos que el comprador no puede verificar hasta la producción. Una cotización construida sobre un ratio generoso parece más barata por terabyte útil que otra basada en la capacidad bruta, aunque ofrezca un espacio real similar cuando llegan los trabajos de backup ya comprimidos o cifrados.
Segundo, la cotización refleja un único momento; el precio y la granularidad de la ampliación determinan lo que cuestan los años dos a cuatro. Tercero, la cotización excluye el final. Una plataforma que se sustituye en bloque, con una migración en paralelo, conlleva un coste de salida que no tiene una plataforma capaz de sustituir nodos de forma progresiva.
La tabla es cualitativa: describe cómo se comporta habitualmente cada partida. Los valores corresponden a la hoja de cálculo de cada organización.
| Partida de coste | Appliance de propósito específico | Almacenamiento de objetos software-defined |
|---|---|---|
| Adquisición | A menudo más bajo por TB útil cotizado; depende del ratio de deduplicación supuesto | Tarificado por capacidad licenciada; hardware adquirido por separado o como appliance |
| Incrementos de ampliación | Por bandejas, pasos fijos mayores, limitado por el modelo de controladora | Por nodos, dimensionados según la necesidad, sin límite de controladora |
| Renovación del hardware | Sustitución total de la unidad, migración de datos necesaria | Sustitución progresiva de nodos, generaciones mixtas en un mismo clúster |
| Renovaciones de soporte | Contrato único, las renovaciones de hardware suelen encarecerse en los últimos años | Suscripción de software más soporte de servidores estándar, cotizados por separado |
| Riesgo de reducción de datos | Alto: la capacidad útil depende del ratio alcanzado | Menor: la reducción la gestiona normalmente la aplicación de backup |
| Energía y espacio | Depende de la densidad de la controladora y de las bandejas | Depende de la densidad de servidor elegida; los nodos antiguos pueden retirarse antes |
| Tiempo de operación | Bajo en el día a día, concentrado en proyectos de ampliación y renovación | Bajo en el día a día, repartido entre incorporaciones incrementales de nodos |
| Rendimiento de restauración | La rehidratación puede ralentizar las restauraciones grandes | Lecturas nativas de objetos, en paralelo entre nodos |
| Inmutabilidad | A veces un complemento licenciado o un modelo específico | Incluida con frecuencia mediante S3 Object Lock |
| Salida y migración | Migración completa en cada ciclo de renovación | Los datos permanecen en su sitio mientras el hardware se renueva |
Supongamos que una organización mantiene 500 TB de datos de backup que crecen un 25 por ciento anual y compara un appliance con un almacenamiento de objetos software-defined cotizado aproximadamente un 30 por ciento más caro el primer día para la misma capacidad útil. Este ejemplo es solo ilustrativo y utiliza términos relativos en lugar de precios.
En el escenario del appliance, el ratio de deduplicación alcanzado es aproximadamente un tercio inferior al cotizado porque gran parte del parque ya está comprimido en origen. La capacidad útil se agota un año antes, lo que adelanta una ampliación de bandeja al año dos; la cabecera alcanza su límite en el año cuatro, lo que exige una actualización de controladora; las renovaciones se encarecen en los años cuatro y cinco; y la renovación del año cinco añade una migración con meses de operación en paralelo.
En el escenario de almacenamiento de objetos, se añaden nodos en los años dos, tres y cuatro, cada uno dimensionado para aproximadamente un año de crecimiento. Los nodos del año uno empiezan a retirarse en el año cinco sin migración, y la inmutabilidad está incluida en la licencia base.
Con estos supuestos, la ventaja del 30 por ciento del primer día se consume con la ampliación anticipada y la actualización del año cuatro, y los costes de salida del año cinco sitúan el total del appliance por encima del total del almacenamiento de objetos. Si se cambia la tasa de crecimiento, el ratio alcanzado o el calendario de renovación, la respuesta varía; esa sensibilidad es precisamente el objetivo del modelo.
Scality ARTESCA es un almacenamiento de objetos S3 diseñado para backup, disponible como software sobre servidores estándar o como appliance hardware. Ambos formatos comparten la misma arquitectura scale-out: la capacidad crece añadiendo nodos y las generaciones de hardware pueden mezclarse dentro de un clúster en lugar de sustituirse como una unidad.
La inmutabilidad mediante S3 Object Lock forma parte de la plataforma y no es una función licenciada por separado, lo que elimina una partida del modelo; los detalles están en la página de seguridad y ciberresiliencia. ARTESCA está validado con las principales aplicaciones de backup, incluidas Veeam, Commvault, Rubrik, Cohesity y HYCU, de modo que la reducción de datos y el comportamiento de restauración pueden modelarse a partir de las cifras del propio software de backup. Para traducir los supuestos de crecimiento y retención en número de nodos, consulte el artículo anterior sobre dimensionamiento del repositorio de backup.
Sea cual sea la plataforma en evaluación, pida al proveedor que complete las diez partidas de coste para cada uno de los cinco años antes de comparar precios por terabyte.