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.
¿Qué es el coste total de propiedad del almacenamiento de backup?
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.
¿En qué se diferencian estructuralmente las dos arquitecturas?
Appliances de backup de propósito específico
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.
Almacenamiento de objetos software-defined sobre servidores estándar
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.
¿Qué partidas de coste importan a cinco años?
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.
- Adquisición: hardware, software e instalación iniciales. Los appliances suelen tener aquí precios atractivos porque los ratios de deduplicación se aplican a la capacidad útil cotizada.
- Incrementos de ampliación: el paso mínimo en que puede crecer la capacidad y su precio. Las bandejas vienen en pasos mayores, definidos por el fabricante; los nodos pueden dimensionarse más cerca de la necesidad real.
- Renovación del hardware: sustitución como unidad o nodo a nodo, y si es necesario migrar los datos.
- Renovaciones de soporte y mantenimiento: las renovaciones de hardware de los appliances suelen encarecerse en los años cuatro y cinco; las licencias de software y el soporte de servidores siguen curvas distintas y deben cotizarse por separado.
- Supuestos de reducción de datos: el ratio utilizado para convertir la capacidad bruta en capacidad útil. Si el ratio alcanzado es inferior al supuesto (algo habitual con datos cifrados, comprimidos o multimedia), la capacidad útil se reduce y la ampliación llega antes.
- Energía, refrigeración y espacio en rack: determinados por la densidad de los discos y por cuánto tiempo permanece en servicio el hardware más antiguo y menos denso.
- Tiempo de operación: horas dedicadas a planificación de capacidad, aplicación de parches, ampliación y migración, a un coste de personal con cargas incluidas.
- Rendimiento de restauración: rehidratar datos muy deduplicados puede ser más lento que leer datos almacenados en su forma nativa, y cada hora de una restauración grande conlleva un coste de indisponibilidad.
- Licencias de inmutabilidad: si la retención de escritura única (como S3 Object Lock) está incluida o se vende como complemento.
- Salida y migración: el coste de trasladar los datos fuera de la plataforma al final de su vida útil, incluida la operación en paralelo de los sistemas antiguo y nuevo.
¿Por qué induce a error el precio por terabyte del primer día?
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.
Comparación a cinco años de las categorías de coste
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 |
¿Cómo sería un ejemplo ilustrativo a cinco años?
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.
Preguntas que plantear al construir un modelo de TCO
- ¿Qué ratio de reducción de datos supone la cotización y qué ocurre con la capacidad útil si el ratio alcanzado es un 25 o un 50 por ciento inferior?
- ¿Cuál es el incremento mínimo de ampliación, cuánto cuesta y existe un límite de controladora o de nivel de licencia?
- ¿La renovación del hardware es una sustitución completa del sistema o una sustitución progresiva de nodos, y requiere una migración de datos?
- ¿Cuáles son los costes de soporte y mantenimiento en cada uno de los años uno a cinco, cotizados individualmente?
- ¿La inmutabilidad (Object Lock o equivalente) está incluida o se licencia por separado?
- ¿Qué rendimiento de restauración se espera para una recuperación completa del sitio y cuánto cuesta internamente una hora de indisponibilidad?
- ¿Cuántas horas de personal al año se dedican a planificación de capacidad, aplicación de parches, ampliación y migración?
- ¿Cuáles son los costes de energía, refrigeración y rack en el año uno y con la capacidad prevista para el año cinco?
- ¿Cuánto cuesta trasladar todos los datos fuera de la plataforma al final de su vida útil, incluida la operación en paralelo?
- ¿Pueden convivir distintas generaciones de hardware y pueden retirarse nodos individuales de forma anticipada?
Cómo encaja Scality ARTESCA en un modelo de TCO a cinco años
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.