Respaldos inmutables y pruebas de restauración

Un respaldo que nunca se ha restaurado es una promesa. Y un respaldo que el atacante puede borrar no protege de nada. La lección de respaldos y almacenamiento híbrido presenta AWS Backup. Con él puedes construir copias que sobrevivan a un error, a un ransomware y a una cuenta comprometida.

Réplica no es respaldo

Necesitas las dos. La réplica cuida tu RTO; el respaldo es tu única salida cuando el problema son los datos mismos.

La regla 3-2-1, adaptada a la nube

AWS Backup: planes, bóvedas y copias

Un plan de respaldo tiene reglas: frecuencia (desde cada hora), ventana, retención y acciones de copia. Cada regla puede copiar el recovery point a una bóveda de otra región y a una de otra cuenta de tu organización. Para recursos que lo admiten, los respaldos continuos permiten restaurar a un momento exacto dentro de 1 a 35 días. Asigna recursos por etiquetas para que lo nuevo quede protegido sin que nadie se acuerde.

La bóveda de destino puede ser un logically air-gapped vault, un tipo de bóveda con protección extra: siempre tiene Vault Lock en modo compliance, se cifra con una llave propiedad de AWS o con una llave administrada por ti, y los respaldos quedan guardados en una cuenta del servicio AWS Backup, no en la tuya. Puedes compartirla con otras cuentas (incluso de otra organización) mediante AWS RAM para restaurar desde allí, y con la aprobación de varias personas (multi-party approval) puedes recuperar los respaldos aunque pierdas el acceso a la cuenta dueña.

Bloqueo contra borrado: Vault Lock y S3 Object Lock

Los dos usan el modelo WORM (write once, read many: se escribe una vez y no se modifica) y los dos tienen un modo governance y un modo compliance.

En Vault Lock defines retención mínima y máxima: los trabajos de respaldo o copia que no cumplan fallan. En S3 Object Lock el bucket necesita versionado, la retención aplica a cada versión, y la retención legal (legal hold) bloquea una versión sin fecha de fin hasta que alguien con el permiso s3:PutObjectLegalHold la quite. Un borrado simple solo agrega un marcador de borrado; la versión bloqueada sigue ahí.

Llaves y permisos: separar funciones

• La llave vive con el respaldo. Cifra las copias de la cuenta de respaldos con una llave de KMS de esa cuenta. Si usas la llave de producción y un atacante programa su borrado, tus copias quedan intactas pero ilegibles. Más en cifrado y secretos.
• Quien puede borrar producción no puede borrar respaldos. Los administradores de la cuenta de producción no tienen acceso a la cuenta de respaldos. Una SCP de AWS Organizations niega acciones como backup:DeleteRecoveryPoint o backup:DeleteBackupVaultLockConfiguration a todos salvo un rol de emergencia con MFA.
• Todo se registra. CloudTrail en una cuenta de auditoría, con alertas ante intentos de borrar respaldos o llaves.

Probar la restauración y medirla contra el RTO

AWS Backup restore testing automatiza la prueba. Creas un plan con frecuencia y ventana de inicio, eliges qué recursos entran y si se restaura el recovery point más reciente o uno al azar. AWS Backup infiere los parámetros de restauración, mide cuánto tarda cada trabajo y borra lo restaurado al terminar. Si quieres validar los datos, puedes retener lo restaurado de 1 a 168 horas y correr tu propia comprobación, por ejemplo una función Lambda que cuente registros. AWS Backup Audit Manager tiene un control que revisa si el tiempo de restauración cumple tu objetivo.

Recuerda la descomposición del RTO de RPO y RTO a fondo: la prueba automática mide la recuperación de datos. Conectar la aplicación, cambiar el tráfico y validar se practican en un simulacro completo (ver runbooks y simulacros).

Pasos para una estrategia sólida

1. 1

   Clasifica por criticidad

   Cada tier define frecuencia, retención y si necesita copia entre regiones.
2. 2

   Crea planes de AWS Backup por tier

   Asigna recursos por etiqueta, como backup=tier1, y aplica las políticas desde Organizations a todas las cuentas.
3. 3

   Copia a otra cuenta y otra región

   Una cuenta de respaldos dedicada, con bóvedas en la región principal y en la de recuperación, o un logically air-gapped vault.
4. 4

   Bloquea

   Prueba Vault Lock en governance, revisa las retenciones y pasa a compliance. Para datos en S3, Object Lock.
5. 5

   Separa llaves y permisos

   Llaves de KMS en la cuenta de respaldos y SCP que niegan borrar respaldos y bóvedas.
6. 6

   Prueba y mide

   Restore testing programado, con alarma si un trabajo falla o tarda más que tu objetivo.
7. 7

   Vigila los trabajos

   Alarma sobre respaldos y copias fallidos y sobre la edad del último recovery point de cada recurso crítico.