Copias inmutables y la prueba que las valida

Azure Backup ofrece bóvedas inmutables con tres estados: deshabilitada, habilitada, y habilitada y bloqueada. En el estado habilitada, la bóveda bloquea las operaciones que perderían copias, como parar la protección borrando los datos o recortar la retención, pero el ajuste se puede desactivar. Solo en el estado habilitada y bloqueada el ajuste es irreversible, porque el bloqueo no se puede quitar.

Esa diferencia importa ante alguien con rol de administrador sobre la bóveda, porque el primer paso para borrar copias es apagar la protección que lo impide. Además, el borrado suave retiene lo borrado entre 14 y 180 días y por defecto son 14, pero eso permite recuperar lo borrado, no impide que se borre.

Lee la tabla bovedas_azure: Calamar tiene una bóveda en cada estado de los dos últimos.

AWS Backup bloquea una bóveda en dos modos. En el de gobernanza, quien tenga permisos suficientes puede quitar el bloqueo, así que sirve para disciplinar al equipo pero no frena a alguien con las credenciales equivocadas. En el de cumplimiento hay un periodo de gracia, de al menos tres días, durante el cual todavía se puede deshacer; pasada la gracia, ni la persona dueña de la cuenta ni AWS pueden cambiar o borrar el bloqueo mientras haya copias en la bóveda. Los puntos de recuperación no se pueden borrar hasta que termina su retención.

Calcula, para cada bóveda bloqueada en modo cumplimiento, cuándo acaba su gracia: la fecha de bloqueo más los días de gracia. La fecha de la revisión está en la tabla revision. Una bóveda es inmutable de verdad solo si esa fecha ya pasó.

Durante la gracia, el modo cumplimiento todavía se puede deshacer: es el margen que se da para equivocarse. Eso significa que, hasta que acaba, la bóveda no protege contra alguien que use esa ventana. Mientras tanto la bóveda sí rechaza que se borre o se acorte una copia, pero quien puede quitar el bloqueo en la gracia puede quitarlo.

La bóveda más reciente de Calamar se bloqueó hace poco. Con la fecha de bloqueo y los días de gracia de la tabla bovedas_aws, y la fecha de la revisión de revision, se sabe cuántos días le quedan de ventana.

Una copia en la misma cuenta que lo que protege tiene el mismo dueño del riesgo: si alguien consigue credenciales de administrador de la cuenta de producción, puede borrar la carga y su copia en una sola sesión. La guía de AWS sobre recuperación ante desastres recomienda copias entre cuentas por esa razón, para protegerse de amenazas internas y de cuentas comprometidas. El bloqueo de la bóveda añade la segunda defensa: aunque alguien entre, la copia no se puede borrar.

Compara en plan_de_copias la cuenta de origen con la cuenta de la bóveda, y esta con la tabla bovedas_aws. La regla de la casa pide cuenta distinta y bóveda inmutable.

Restaurar de prueba demuestra tres cosas: que la copia existe, que se puede leer con las claves y permisos que haya el día del desastre, y cuánto se tarda de verdad. Pero una restauración que termina sin errores prueba solo que el proceso corrió. Para que la prueba valga hay que comprobar que los datos restaurados son los correctos: un conteo de filas, una suma de control, abrir y validar la firma de unos archivos. Sin esa verificación, una copia que restaura datos vacíos o corruptos pasa por buena.

La tabla pruebas_de_restauracion dice, de cada prueba, qué se comprobó de los datos.