Dimensionar un repositorio de backup empieza con una pregunta engañosamente sencilla: ¿cuántos datos necesita proteger?
La respuesta es solo el punto de partida. Una empresa con 500 TB de datos de producción puede necesitar bastante más de 500 TB de capacidad de backup una vez que se tienen en cuenta los periodos de retención, las tasas de cambio diarias, la frecuencia de backup, el crecimiento de los datos y la retención inmutable. La cantidad también puede variar significativamente según el software de backup y las tecnologías de reducción de datos en uso.
Eso convierte el dimensionamiento del repositorio de backup en un ejercicio de planificación de capacidad y no en una copia directa de los requisitos del almacenamiento de producción. El objetivo es entender cuántos datos de backup se acumularán con el tiempo, cuánto tiempo deben permanecer disponibles y cuánto margen necesita el repositorio para operar y crecer de forma fiable.
Esta guía explica las principales variables implicadas y ofrece un marco práctico para estimar los requisitos de almacenamiento de backup.
¿Qué es el dimensionamiento del repositorio de backup?
El dimensionamiento del repositorio de backup es el proceso de estimar la capacidad de almacenamiento necesaria para conservar los datos de backup durante un periodo definido.
El volumen de datos protegidos es la base del cálculo, pero raramente es la cifra final. La capacidad de backup también se ve afectada por:
- La cantidad de datos protegidos
- La rapidez con la que cambian esos datos
- La frecuencia con la que se ejecutan los backups
- El tiempo durante el que se conservan los puntos de recuperación
- El método de backup utilizado
- La compresión y la deduplicación
- Los requisitos de retención inmutable
- El crecimiento previsto de los datos
- Las copias adicionales de recuperación o secundarias
- La capacidad reservada como margen operativo
Estas variables explican por qué dos organizaciones que protegen la misma cantidad de datos de producción pueden tener requisitos de almacenamiento de backup muy distintos.
Un entorno de 500 TB con una tasa de cambio diaria baja y una política de retención de 30 días tiene un perfil de capacidad diferente al de un entorno de 500 TB que genera grandes volúmenes de datos nuevos cada día y conserva los puntos de recuperación durante un año.
La pregunta correcta, por tanto, no es simplemente “¿cuántos datos de producción tenemos?”. Es “¿cuántos datos de backup necesitaremos conservar en cualquier momento dado?”.
7 factores que determinan la capacidad de almacenamiento de backup
Una estimación útil del almacenamiento de backup empieza por entender las variables que hacen que se acumulen los datos de backup almacenados.
1. Volumen de datos protegidos
El volumen de datos protegidos es la cantidad de datos de origen incluidos en el entorno de backup.
Puede incluir máquinas virtuales, bases de datos, sistemas de archivos, aplicaciones, datos de usuario y otras cargas de trabajo. Es importante distinguir la capacidad total de almacenamiento de producción de los datos realmente protegidos. Un entorno de almacenamiento de 1 PB, por ejemplo, puede contener capacidad sin utilizar o conjuntos de datos excluidos del backup.
Utilice como base para el dimensionamiento la cantidad de datos que realmente se protegerá.
2. Tasa de cambio diaria
La tasa de cambio diaria mide cuántos datos protegidos se crean o modifican entre ciclos de backup.
Es una de las variables más importantes en el dimensionamiento del repositorio, porque los backups incrementales generalmente almacenan los cambios en lugar de otra copia completa de cada conjunto de datos protegido.
Si se protegen 500 TB y aproximadamente un 2% cambia cada día, eso representa unos 10 TB de datos modificados antes de tener en cuenta la compresión, la deduplicación u otras formas de reducción de datos.
Una carga de trabajo con una tasa de cambio del 10% produciría un requisito de capacidad muy distinto a pesar de tener la misma capacidad protegida inicial.
Las tasas de cambio también pueden variar sustancialmente entre cargas de trabajo. A las bases de datos, las máquinas virtuales, los repositorios multimedia y el almacenamiento de archivos general no se les deberían asignar automáticamente las mismas suposiciones.
3. Frecuencia de backup
La frecuencia de backup determina con qué frecuencia se crean nuevos puntos de recuperación.
Una organización que realiza un backup al día generará una cantidad de datos de backup distinta a la de una que protege sus sistemas críticos varias veces al día.
La frecuencia adquiere especial importancia cuando las políticas de backup varían según la carga de trabajo. Las aplicaciones de primer nivel pueden tener objetivos de punto de recuperación mucho más exigentes que los sistemas menos críticos, lo que se traduce en más puntos de recuperación y, potencialmente, en un mayor consumo de almacenamiento.
El dimensionamiento del repositorio debería reflejar, por tanto, las políticas de protección reales en lugar de aplicar una única frecuencia de backup a todo el entorno.
4. Periodo de retención
La retención determina cuánto tiempo permanecen los datos de backup en el repositorio.
Una política de 30 días mantiene un historial de recuperación mucho menor que una política de 90 días, de un año o de varios años. Algunas organizaciones también utilizan políticas de retención por niveles, como conservar los backups diarios durante varias semanas, los semanales durante varios meses y los puntos de recuperación mensuales o anuales durante periodos más largos.
Los requisitos regulatorios, legales y de negocio pueden ampliar aún más la retención.
Lo importante es que la capacidad de backup es acumulativa. El repositorio debe alojar al mismo tiempo todos los puntos de recuperación que permanecen dentro de la ventana de retención.
5. Método de backup
La arquitectura de backup afecta a cuánta capacidad física se consume.
Los enfoques habituales incluyen backups completos, backups incrementales, backups completos sintéticos y combinaciones de estos métodos. Las plataformas de backup también pueden aplicar compresión, deduplicación u otras técnicas de reducción de datos.
Como resultado, el volumen lógico de backup y el consumo físico del repositorio no son necesariamente iguales.
Al dimensionar un repositorio, utilice suposiciones realistas basadas en la aplicación de backup, la carga de trabajo y la política de protección, en lugar de asumir una ratio de reducción universal.
6. Crecimiento de los datos
Los entornos de producción raramente mantienen el mismo tamaño.
Si una organización protege hoy 500 TB y sus datos crecen un 20% anual, los requisitos del repositorio aumentarán aunque la propia política de backup no cambie.
El crecimiento se acumula en periodos de planificación más largos:
- Hoy: 500 TB
- Tras un año con un crecimiento del 20%: 600 TB
- Tras dos años: 720 TB
- Tras tres años: 864 TB
Dimensionar solo para el entorno actual puede, por tanto, crear un repositorio que alcance sus límites mucho antes de lo esperado.
7. Inmutabilidad y requisitos de recuperación
La ciberresiliencia introduce otra consideración importante: algunos datos de backup pueden ser, intencionadamente, imposibles de modificar o eliminar durante un periodo definido.
La retención inmutable de backups protege los puntos de recuperación frente al ransomware, las credenciales de administrador comprometidas y el borrado accidental. También significa que la capacidad no puede recuperarse simplemente cuando un administrador quiera hacer espacio.
Si un punto de recuperación debe permanecer inmutable durante 30 días, la infraestructura necesita capacidad suficiente para mantener esa ventana protegida mientras siguen llegando nuevos backups.
La inmutabilidad no significa necesariamente que toda organización necesite mucho más almacenamiento. Significa que las políticas de retención y de capacidad deben estar alineadas para que el repositorio pueda respetar la ventana de protección requerida sin generar presión sobre la capacidad.
Una fórmula sencilla para dimensionar el almacenamiento de backup
No existe una única fórmula que modele con precisión todas las arquitecturas de backup, pero una estimación básica puede ayudar a establecer la escala del requisito.
Para un modelo de backup incremental, un punto de partida simplificado es:
Capacidad de backup estimada = Datos protegidos iniciales + datos modificados retenidos + puntos de recuperación a largo plazo + crecimiento + margen operativo
Por ejemplo, consideremos una organización con:
- 500 TB de datos protegidos
- Tasa de cambio diaria media del 2%
- Un backup incremental diario
- 30 días de cambios diarios retenidos
Los datos modificados diariamente serían aproximadamente 500 TB × 2% = 10 TB al día. Treinta días de datos modificados representarían 10 TB × 30 = 300 TB.
Antes de considerar la reducción de datos, los puntos de recuperación completos adicionales, el crecimiento o el margen, el requisito lógico simplificado sería, por tanto, de aproximadamente 500 TB + 300 TB = 800 TB.
Se trata deliberadamente de un ejemplo simplificado. El consumo real del repositorio dependerá de cómo almacene la plataforma de backup los puntos de recuperación y de la eficacia con la que puedan reducirse los datos.
La parte útil del cálculo no es la cifra de 800 TB. Es entender qué suposiciones la han producido.
Cómo cambia la retención los requisitos de almacenamiento de backup
La retención puede tener un efecto mayor sobre la capacidad a largo plazo que el backup completo inicial.
Utilizando el mismo ejemplo simplificado, 500 TB de datos protegidos con una tasa de cambio diaria del 2% producen aproximadamente 10 TB de datos modificados al día.
Ignorando, a efectos ilustrativos, la reducción de datos y otras copias completas:
| Periodo de retención | Datos modificados retenidos | Datos iniciales + cambios |
|---|---|---|
| 30 días | 300 TB | 800 TB |
| 60 días | 600 TB | 1,1 PB |
| 90 días | 900 TB | 1,4 PB |
| 180 días | 1,8 PB | 2,3 PB |
Esto no significa que todo entorno de 500 TB requiera exactamente estas capacidades. El software de backup real puede almacenar los datos de otra forma, y la deduplicación o la compresión pueden alterar significativamente el consumo físico.
Sí demuestra por qué importan las suposiciones sobre retención.
Las organizaciones también deberían separar la recuperación operativa a corto plazo de la retención a largo plazo. Conservar todos los puntos de recuperación diarios durante años puede ser innecesario cuando el requisito real es mantener puntos de recuperación recientes y frecuentes y un número menor de copias mensuales o anuales.
El diseño de la retención y el dimensionamiento del repositorio deberían, por tanto, realizarse conjuntamente.
Cómo afecta la inmutabilidad a la planificación de capacidad de backup
El almacenamiento de backup inmutable impide que los datos protegidos se modifiquen o eliminen hasta que expire su periodo de retención.
Esa capacidad se ha convertido en una parte importante de la resiliencia frente al ransomware, porque los atacantes apuntan con frecuencia a la infraestructura de backup para intentar eliminar las opciones de recuperación antes de cifrar los sistemas de producción.
Desde el punto de vista del dimensionamiento, la inmutabilidad hace más importante una planificación precisa de la capacidad.
En un repositorio convencional, los administradores pueden responder a veces a la presión de capacidad eliminando datos de backup antiguos. Esa opción puede no existir para los datos que aún están dentro de un periodo de retención inmutable.
Supongamos que una organización requiere 30 días de backups inmutables. El repositorio necesita capacidad utilizable suficiente para alojar toda la ventana inmutable activa mientras sigue ingiriendo nuevos backups.
La relación puede plantearse así:
Requisito de capacidad inmutable = datos de backup que entran en la ventana inmutable más rápido de lo que los datos pasan a ser candidatos a expirar
Si los volúmenes de backup aumentan de forma inesperada, cambian las políticas de retención o los datos de producción crecen más rápido de lo previsto, el consumo de capacidad puede aumentar en consecuencia.
Por eso el diseño de backups inmutables debería considerar tanto la política de seguridad como la economía del almacenamiento. El objetivo no es conservarlo todo para siempre. Es mantener un historial de recuperación protegido suficiente para satisfacer los requisitos de recuperación y de cumplimiento sin crear un modelo de capacidad insostenible.
No olvide el crecimiento futuro de los datos
Una de las formas más fáciles de infradimensionar un repositorio de backup es calcular los requisitos a partir de la capacidad protegida actual y detenerse ahí.
Consideremos una empresa que protege 1 PB de datos con un crecimiento anual del 25%. Sus datos de producción podrían alcanzar aproximadamente:
- Año 1: 1,25 PB
- Año 2: 1,56 PB
- Año 3: 1,95 PB
Los requisitos de capacidad de backup crecerán, por lo general, en paralelo.
El efecto puede ser aún mayor cuando el aumento de la capacidad de producción va acompañado de una retención más larga, cargas de trabajo adicionales o una mayor frecuencia de backup.
Un ejercicio útil de dimensionamiento del repositorio debería incluir, por tanto, al menos tres escenarios:
- Crecimiento esperado — la previsión más probable de la organización
- Caso de alto crecimiento — un escenario de crecimiento más rápido que pone a prueba la facilidad con la que el repositorio puede ampliarse
- Caso de cambio de política — el efecto de ampliar la retención o de añadir cargas de trabajo protegidas adicionales
El objetivo no es predecir con exactitud los requisitos de capacidad a varios años vista. Es evitar elegir una arquitectura que resulte difícil o costosa de ampliar cuando esas previsiones cambien, como inevitablemente ocurrirá.
La capacidad bruta y la capacidad utilizable no son lo mismo
Los sistemas de almacenamiento se describen a menudo en términos de capacidad bruta, pero la capacidad bruta no es necesariamente la cantidad disponible para los datos de backup.
Parte de la capacidad puede consumirla los mecanismos de protección de datos, la sobrecarga del sistema y otros requisitos arquitectónicos. La cantidad disponible para las aplicaciones tras tener en cuenta estos factores es la capacidad utilizable.
Los equipos de backup deberían evitar, por tanto, comparar plataformas de almacenamiento únicamente en función de los terabytes o petabytes brutos.
Pregunte cuánta capacidad utilizable estará realmente disponible para los datos de backup y cómo cambia esa cifra a medida que el sistema se amplía.
El margen operativo también importa.
Hacer funcionar un sistema de almacenamiento de forma continua a su capacidad máxima teórica deja poco espacio para el crecimiento inesperado, las operaciones de mantenimiento o los aumentos repentinos del volumen de backup. La planificación de capacidad debería incluir un colchón en lugar de asumir que puede consumirse cada byte disponible.
Repositorios de backup scale-up frente a scale-out
La forma en que se amplía un repositorio de backup puede ser tan importante como su capacidad inicial.
Una arquitectura scale-up (escalado vertical) aumenta generalmente la capacidad añadiendo recursos a un sistema de almacenamiento existente. Esto puede funcionar bien dentro de los límites de la plataforma, pero los entornos grandes pueden acabar encontrándose con límites de hardware o de arquitectura.
El almacenamiento scale-out (escalado horizontal) distribuye los datos entre varios nodos y permite aumentar la capacidad añadiendo nodos adicionales al sistema.
Para los entornos de backup en crecimiento, esto cambia la pregunta del dimensionamiento.
En lugar de intentar adquirir desde el primer día capacidad suficiente para todos los posibles requisitos futuros, las organizaciones pueden establecer un despliegue inicial y ampliarlo a medida que crecen los datos protegidos.
Esto puede ser especialmente útil cuando el crecimiento es difícil de predecir. Las adquisiciones, las nuevas aplicaciones, los requisitos regulatorios y los cambios en las políticas de ciberresiliencia pueden alterar los requisitos de capacidad de backup más rápido de lo esperado.
La consideración importante es si la ampliación puede realizarse sin crear nuevos silos de almacenamiento ni requerir migraciones disruptivas.
¿Cuánto margen debería tener un repositorio de backup?
No existe un porcentaje universal de capacidad libre que sea adecuado para todos los entornos de backup.
El margen debería reflejar, en cambio, la rapidez con la que el entorno puede consumir almacenamiento adicional y la rapidez con la que puede añadirse nueva capacidad.
Un entorno que ingiere varios terabytes de nuevos datos de backup cada día tiene menos tiempo para reaccionar ante una escasez de capacidad que un entorno más pequeño con datos relativamente estáticos.
Los equipos deberían considerar:
- La ingesta diaria típica de backup
- Los periodos de ingesta máxima
- El crecimiento previsto de los datos
- Los datos inmutables que aún no pueden expirar
- El tiempo necesario para adquirir y desplegar capacidad adicional
- La capacidad necesaria durante escenarios de mantenimiento o de fallo
- Los cambios inesperados en las políticas de retención
Un umbral operativo útil debería dar tiempo suficiente para identificar el aumento del consumo y añadir capacidad antes de que el repositorio quede limitado.
Esto convierte la monitorización de la capacidad en una parte continua de las operaciones de backup, en lugar de un cálculo puntual realizado durante el despliegue.
Preguntas que plantear antes de comprar almacenamiento de backup
El dimensionamiento del repositorio debería ayudar, en última instancia, a determinar si una arquitectura de almacenamiento puede dar soporte al entorno de backup durante su vida útil prevista.
Antes de seleccionar almacenamiento de backup, pregunte:
¿Cuántos datos protegemos hoy?
Mida la capacidad protegida real en lugar del almacenamiento de producción total.
¿Con qué rapidez cambian esos datos?
Utilice tasas de cambio específicas por carga de trabajo cuando sea posible.
¿Durante cuánto tiempo deben conservarse los puntos de recuperación?
Separe los requisitos de recuperación a corto plazo de la retención a largo plazo.
¿Durante cuánto tiempo deben permanecer inmutables los backups?
Asegúrese de que el sistema de almacenamiento puede mantener la ventana de protección requerida a medida que llegan nuevos datos.
¿Con qué rapidez crecen los datos de producción?
Modele la capacidad futura en lugar de comprar únicamente para la huella actual.
¿Qué reducción de datos deberíamos esperar de forma realista?
Utilice suposiciones medidas o validadas por el fabricante en lugar de ratios idealizadas.
¿Cuánta capacidad utilizable proporcionará el sistema?
Compare la capacidad de almacenamiento utilizable en lugar de la bruta.
¿Cómo se amplía el repositorio?
Entienda si el crecimiento requiere nodos adicionales, sustitución de hardware, migraciones o nuevos sistemas de almacenamiento.
¿Qué ocurre cuando la capacidad empieza a agotarse?
Determine cómo se monitoriza la capacidad, con qué rapidez puede ampliarse el sistema y si la retención inmutable podría restringir una limpieza de emergencia.
¿Puede el repositorio seguir escalando sin aumentar la complejidad operativa?
La capacidad es solo una dimensión. Una infraestructura que se vuelve progresivamente más difícil de operar a medida que crece puede generar sus propios costes.
Planificar el almacenamiento de backup para los próximos tres años
Un plan práctico de capacidad de backup no necesita predecir el futuro con precisión. Necesita exponer las variables que podrían cambiar sustancialmente el requisito.
Empiece por la capacidad protegida actual y modele después las tasas de cambio esperadas, las políticas de backup y la retención. Aplique suposiciones realistas de reducción de datos basadas en el entorno de backup. Añada el crecimiento previsto de producción y un margen operativo suficiente.
Después, ponga a prueba el modelo frente a escenarios menos cómodos:
- ¿Qué ocurre si los datos crecen un 30% en lugar de un 15%?
- ¿Qué ocurre si la organización cambia su política de retención inmutable de 14 a 30 días?
- ¿Qué ocurre si se incorporan a la protección otros 500 TB de cargas de trabajo?
- ¿Qué ocurre si los requisitos regulatorios obligan a conservar ciertos puntos de recuperación durante más tiempo?
Las respuestas revelan algo más útil que una única cifra de capacidad: cuán resiliente es la arquitectura de backup frente al cambio.
Un repositorio perfectamente dimensionado para los requisitos actuales pero difícil de ampliar puede acabar siendo una peor elección que uno diseñado para escalar a medida que evolucionan los requisitos de backup.
Cómo apoya ARTESCA el almacenamiento de backup escalable
Scality ARTESCA es almacenamiento de objetos diseñado para entornos de backup en los que la ciberresiliencia, la escalabilidad y la simplicidad operativa son requisitos fundamentales.
ARTESCA proporciona almacenamiento de objetos compatible con S3 para aplicaciones de backup y admite una protección de datos inmutable diseñada para ayudar a preservar los datos de recuperación frente al ransomware y otros intentos de modificar o eliminar los backups.
Su arquitectura scale-out permite a las organizaciones ampliar el almacenamiento a medida que aumentan los requisitos de backup, en lugar de tratar el despliegue inicial como un techo de capacidad fijo. Esto puede ayudar a los equipos de infraestructura a absorber conjuntos de datos protegidos en crecimiento, políticas de retención cambiantes y requisitos de backup inmutable en expansión sin crear silos de almacenamiento separados.
Para el dimensionamiento del repositorio de backup, el principio general es sencillo: no seleccione el almacenamiento basándose únicamente en la capacidad que necesita hoy.
Empiece por los datos que protege. Entienda con qué rapidez cambian. Defina cuánto tiempo deben conservarse y protegerse. Modele el crecimiento a lo largo de la vida prevista del entorno. Y después elija una arquitectura de almacenamiento de backup capaz de crecer con esos requisitos.
Eso produce una respuesta mucho más útil a la pregunta “¿cuánto almacenamiento de backup necesitamos?” que multiplicar la capacidad de producción actual por un número arbitrario.