¿Qué es la regla 3-2-1-1-0?

La regla 3-2-1-1-0 amplía la estrategia clásica de copias de seguridad para añadir una copia aislada o inmutable y pruebas de recuperación sin errores. La versión original pide conservar tres copias de los datos, en dos tipos de soporte, con al menos una fuera del sitio principal. La variante con cinco cifras es una recomendación extendida por proveedores, no una norma universal con una única definición.

La razón de fondo es sencilla: tener varios ficheros llamados «backup» no garantiza que sobrevivan al mismo incidente ni que puedan restaurarse. La estrategia cuenta independencia, ubicación y capacidad de recuperar, no solo el número de tareas verdes en una consola.

Qué cuenta cada número

El primer 3 incluye los datos de producción y al menos dos copias adicionales. El 2 invita a separar tipos de soporte o dominios de fallo; el 1 sitúa una copia fuera del entorno principal. No existe una fórmula mágica para que cualquier conjunto de tres copias sea resiliente. Una réplica y su origen pueden compartir credenciales, red, administración y riesgo eléctrico.

El segundo 1 añade una copia desconectada o protegida contra cambios, según la formulación que se adopte. Una copia inmutable impide alterar o borrar los objetos durante un periodo configurado, mientras que una copia offline limita el acceso porque el soporte no está conectado. Inmutabilidad y aislamiento reducen riesgos diferentes. La configuración debe impedir que una cuenta comprometida pueda acortar la retención o destruir también las copias protegidas.

El 0 expresa que las recuperaciones verificadas no producen errores en las pruebas definidas. En la versión de Veeam, se vincula a validar las copias mediante pruebas automatizadas. El cero no es una promesa de que nunca habrá errores reales. Describe un objetivo de verificación que solo vale para las restauraciones, muestras, sistemas y momentos que se han probado.

-InfraCrew dice: Tener una copia es un verbo; haberla restaurado es una prueba.-

La independencia importa más que la etiqueta

Dos copias almacenadas en el mismo sistema de archivos pueden desaparecer por un fallo común o por una acción administrativa maliciosa. Dos cuentas en la nube también podrían compartir la misma identidad de administración. La separación debe evaluarse por dominios de fallo y control, no únicamente por el nombre del proveedor o la región seleccionada.

Un snapshot puede acelerar la vuelta atrás ante errores operativos, pero si permanece en el mismo sistema y bajo las mismas credenciales quizá no cubra un incidente que afecte a ese sistema. Un snapshot puede formar parte de la protección sin ser una copia independiente suficiente. Comprueba quién puede borrarlo, qué plano de control lo gestiona y cómo se conserva tras perder el entorno primario.

Una copia inmutable también necesita una política bien calculada. El periodo de retención debe cubrir las necesidades de recuperación y las obligaciones aplicables, sin dejar datos inmovilizados más tiempo del necesario. La protección frente a borrado accidental no elimina la responsabilidad de gestionar privacidad, costes y expiración. Documenta quién puede configurar la retención y cómo se revisan sus cambios.

-InfraCrew dice: Si producción y backup comparten la misma llave maestra, comparten más riesgo del que parece.-

Diseñar las copias pensando en restaurar

Empieza por clasificar los sistemas y decidir objetivos realistas de pérdida de datos y tiempo de recuperación. La frecuencia de copia ayuda a cumplir el primero; el tamaño, las dependencias, las licencias y la automatización influyen en el segundo. El plan se diseña desde la recuperación que necesita el negocio y luego se eligen destinos, ventanas y retenciones.

Define qué se copia, quién lo opera, cuánto tiempo se conserva y cómo se separan credenciales y redes. Incluye configuraciones, claves protegidas, catálogos, servicios de identidad y dependencias necesarias para arrancar. Un conjunto de discos restaurado no basta si faltan los datos para descifrarlo o montarlo. Protege también los elementos que permiten localizar y validar las copias.

Las pruebas deben tener alcance creciente: restaurar archivos, bases de datos, máquinas o servicios completos en un entorno controlado. Mide duración, integridad y pasos manuales; conserva resultados y corrige diferencias entre el procedimiento y el sistema real. Leer un informe de éxito del backup no reemplaza una recuperación ensayada.

Una lista práctica para revisar la regla

Cuenta producción y copias, identifica los dos medios o dominios previstos y confirma cuál está fuera del sitio. Después demuestra que una copia puede quedar desconectada o inmutable incluso frente a una identidad administrativa comprometida. Cada cifra necesita una evidencia verificable: ubicación, política, permiso o resultado de restauración.

Prueba además escenarios que afecten a más de un componente: pérdida del centro, credenciales robadas, borrado accidental y recuperación de catálogo. No todo debe ocurrir en producción para validar el procedimiento; los ejercicios controlados permiten encontrar dependencias sin convertir un simulacro en una incidencia. La prueba debe acercarse al orden real de recuperación, no limitarse a comprobar que los archivos existen.

Por último, actualiza la estrategia cuando cambien aplicaciones, plazos de retención, proveedores o permisos. La regla sirve como recordatorio estructural, no como auditoría completa. Lo importante es poder explicar qué copia sobrevive a cada riesgo y demostrar que se puede recuperar de ella dentro del objetivo acordado.

-InfraCrew dice: El cero se gana restaurando, no redondeando un panel verde.-

Diccionario de la Crew

Inmutabilidad — Protección que impide modificar o eliminar datos durante un periodo o condición determinada.

Copia fuera del sitio — Copia guardada en una ubicación física o lógica independiente del entorno primario.

Prueba de recuperación — Ejercicio controlado que confirma que los datos y procedimientos permiten restaurar un servicio.