La regla 3-2-1 nació en un mundo de disco local y cinta: tres copias de los datos, en dos tipos de medio, con una fuera del sitio. Sobrevivió porque es fácil de recordar y porque resume una idea correcta: la redundancia solo sirve cuando las copias fallan por motivos distintos.

El problema es que, en la nube, es trivial satisfacer los tres números sobre el papel y seguir teniendo una sola copia en la práctica. Bucket de origen, bucket de réplica en otra región y versionado habilitado dan tres artefactos distintos. Si los tres viven en la misma cuenta, responden a la misma credencial administrativa y se rigen por las mismas políticas, comparten el modo de fallo más probable. El recuento dice tres. El dominio de fallo dice uno.

Qué protege cada número

Vale la pena desarmar la regla antes de aplicarla.

Los 3 (tres copias) protegen contra el fallo independiente del medio. La premisa es probabilística: si cada copia falla por su cuenta, la probabilidad de que todas fallen a la vez es el producto de las probabilidades individuales. La premisa se cae entera cuando los fallos están correlacionados.

Los 2 (dos medios) existen para romper esa correlación. Dos discos del mismo lote, en el mismo controlador, con el mismo firmware, no son dos medios a efectos prácticos: son dos instancias del mismo riesgo. La regla pide tecnologías que no fallen por el mismo defecto.

El 1 (una fuera del sitio) protege contra el evento que alcanza al sitio entero: incendio, inundación, robo, corte de energía prolongado. Es la única parte de la regla que trata de un desastre con radio de alcance, y no de un componente.

Observe que ninguno de los tres números habla de permisos, de identidad ni de API. Cuando surgió la regla, eso no era una omisión: para borrar la cinta había que tocar la cinta.

La frontera que importa en la nube es la cuenta

La pregunta útil no es "¿cuántas copias tengo?". Es "¿qué tiene que salir mal para que las pierda todas?". En la nube, la respuesta casi siempre apunta a la cuenta —o tenancy, o subscription, según el proveedor.

Dentro de una misma cuenta, estos eventos alcanzan todas las copias de una sola vez:

Credencial administrativa comprometida. Quien tiene el poder de crear una política tiene el poder de quitar protecciones y borrar. La réplica en otra región obedece a la misma raíz de confianza.
Automatización propia defectuosa. Un script de limpieza con el prefijo equivocado, una política de ciclo de vida aplicada al bucket equivocado, un terraform destroy en el workspace equivocado.
Política de ciclo de vida. Una regla de expiración creada por un equipo convive mal con una retención creada por otro. El dato desaparece sin que nadie haya borrado nada a propósito.
Suspensión o cierre de cuenta. Impago, sospecha de fraude, disputa contractual. El acceso se cae para todo lo que esté bajo ese identificador de facturación.
Eliminación del propio proyecto o compartimento. El contenedor desaparece con el contenido.

Cualquiera de esos eventos convierte tres copias en cero. Por eso, a efectos de 3-2-1, las copias que dependen de la misma credencial y de la misma política cuentan como una.

El versionado y la réplica no son la segunda copia

Dos casos merecen nombre propio, porque aparecen con frecuencia en el diseño de arquitectura.

El versionado mantiene versiones anteriores de un objeto en el mismo bucket. Protege contra sobrescritura y contra borrado accidental simple: el borrado crea un marcador y la versión antigua sigue ahí. No protege contra el borrado de versiones por parte de quien tiene permiso para hacerlo, ni contra la eliminación del bucket, ni contra una regla de ciclo de vida que expira las versiones no actuales. Es un recurso dentro del mismo objeto de infraestructura, descrito en la documentación de versionado de S3. Cuéntelo como resiliencia local, no como copia.

La replicación entre regiones cubre la indisponibilidad regional y la pérdida de medio a escala geográfica. No cubre el comando autenticado: la replicación es unidireccional para el dato, pero el plano de control es compartido. Un atacante con permisos en la cuenta edita la configuración de replicación o borra el bucket de destino. Peor: si la replicación propaga borrados, es un canal de daño, no una barrera. Ese es exactamente el punto que se trata en backup no es sincronización: el espejo obedece al origen, y lo que obedece al origen cae con él.

Qué vale como "fuera del sitio" cuando todo es nube

Traduciendo los tres números a primitivas que existen hoy:

Dos medios se convierte en dos planos de control. No va de disco frente a cinta. Va de que la copia secundaria no responda al mismo conjunto de APIs, a la misma política de IAM y al mismo mecanismo de facturación que la primaria. Una clase de almacenamiento distinta dentro de la misma cuenta no es un segundo medio: la clase cambia el precio y la latencia, no la frontera de control.

Fuera del sitio se convierte, en orden creciente de independencia, en:

Otra región, misma cuenta. Cubre el desastre físico regional. No cubre la credencial.
Otra cuenta del mismo proveedor, con identidad separada. Cubre la credencial y la automatización de la cuenta de producción. No cubre la suspensión del contrato matriz ni el fallo del plano de control del proveedor.
Otro proveedor, con una credencial que no existe en el origen. Cubre también el cierre de cuenta y el incidente de proveedor. Es el diseño descrito en backup de bucket entre nubes.

Hay una prueba sencilla para saber en qué escalón está. Liste todas las credenciales capaces de borrar la copia primaria. Después liste las capaces de borrar la secundaria. Si hay intersección, el conjunto es una sola copia a efectos de riesgo. Haga el mismo ejercicio con la factura: si las dos copias desaparecen cuando se rechaza una tarjeta, dependen del mismo evento.

La copia secundaria también tiene que ser escribible sin ser borrable. La identidad que escribe en el destino no debe tener permiso de borrado de objeto ni de versión, y el destino debe llevar retención inmutable: el razonamiento completo está en backup inmutable con Object Lock, y el comportamiento de los modos de retención está en la documentación de Object Lock en S3.

La variante 3-2-1-1-0

Circula en el mercado una extensión: 3-2-1-1-0, con las tres primeras posiciones iguales, más una copia offline o inmutable, y cero errores en la verificación. No es una norma, no es un estándar publicado por ningún organismo técnico y no sustituye al análisis de riesgo. Es un apodo útil para dos prácticas que ya se sostienen solas.

La posición 1 extra reconoce que "fuera del sitio" dejó de bastar cuando el sitio remoto es alcanzable por API. Offline (medio desconectado) o inmutable (retención que nadie puede quitar antes del plazo) son las dos formas de hacer imposible ese alcance, y no son lo mismo.

El 0 es la parte más descuidada: verificación con resultado de cero errores. Verificar significa leer el dato de vuelta y compararlo con un checksum propio, no comprobar si el objeto existe y tiene el tamaño esperado. Y significa restaurar de verdad, cronometrado, con las identidades reales: asunto de por qué el restore es la parte que nadie. Añada a ese cero la clave de cifrado: una copia independiente de la que nadie consigue extraer el dato es ruido con retención, tema de quién puede abrir su backup.

El costo de la independencia

Separar la copia secundaria cuesta dinero, y el costo tiene una forma previsible. La estructura típica combina cobro por solicitud (LIST, GET y PUT cuentan en categorías propias), cobro por salida de datos en el origen, almacenamiento en la clase elegida y, en las clases frías, mínimo de días facturados y penalización por borrado anticipado. No publico cifras aquí porque las tablas de precios cambian y un precio equivocado es peor que ningún precio: abra la página de precios de su proveedor, en la región exacta del bucket, y sume los cinco componentes antes de encender el primer ciclo. Lo que suele escaparse de esa suma está en lo que desaparece de la factura de un almacenamiento barato.

Checklist

Liste las credenciales que alcanzan cada copia. Una intersección no nula significa copia única.
El versionado y la replicación entran como resiliencia local, no como las tres copias.
La copia secundaria vive bajo una identidad que no existe en la cuenta de origen.
Quien escribe en el destino no borra: sin DeleteObject ni DeleteObjectVersion.
Retención inmutable en el destino, con un plazo mayor que el tiempo realista de detección.
Política de ciclo de vida revisada junto con la retención, nunca por separado.
Clave de cifrado guardada fuera del servidor de backup, con copia probada.
Verificación por checksum propio y al menos una restauración completa cronometrada.
Factura separada o, al menos, un medio de pago que no se caiga junto con el de producción.

Tres copias que mueren con el mismo comando no son tres. La regla sigue siendo válida; lo que cambió fue lo que cuenta como "sitio".

NubliVault es el producto de backup de Nublify: empaqueta millones de archivos pequeños y los guarda en una nube distinta a la de origen. Cómo funciona · Seguridad