IA en producción (3/6): tu copia está dentro de la explosión

De todo lo que se ha escrito sobre el agente que borró un volumen de producción en nueve segundos, lo que más me impresiona no es el borrado. Es cómo se recuperó aquello.

No lo resolvió el cliente con su plan de copias: lo resolvió el proveedor. El consejero delegado de Railway intervino en persona un domingo por la noche y restauró los datos con mecanismos internos que la empresa afectada no tenía a su alcance. Después corrigieron el punto de la API que no aplicaba el borrado diferido.

Dicho de otro modo: la recuperación no dependió de nada que estuviera bajo el control del cliente.

Y antes de que nos riamos: si mañana alguien borra tu volumen principal, ¿tú sabes con certeza —certeza, no confianza— con qué te quedas?

Esta es la tercera entrega de la serie. Van el repaso de los desastres y los permisos. Hoy, lo que descubres justo después del desastre.

Todo lo que había dentro estaba dentro. Foto: Vasyatka1, CC BY-SA 4.0; imagen recortada y disponible bajo la misma licencia.

La definición que casi nadie aplica

Voy a soltar la regla y luego la desarrollo:

Si la misma credencial, la misma cuenta o el mismo botón pueden destruir el original y la copia, esa copia no te protege frente a lo que se haga con esa credencial. Puede seguir sirviéndote contra otros fallos —un disco que muere, un borrado accidental de un fichero suelto, un error de despliegue—, pero no contra el escenario que aquí importa. Tener una copia y que esa copia cubra una amenaza concreta son dos cosas distintas.

En PocketOS, el original y las copias accesibles quedaron bajo la misma credencial y la misma operación destructiva: un único token, una única llamada a la API, y desapareció todo a la vez. El fundador lo explicó diciendo que la plataforma guardaba esas copias en el propio volumen; el detalle de la implementación importa menos que el hecho comprobado, que es el alcance compartido.

Y ese alcance compartido viene por defecto en muchísimos sitios, sin que nadie tome la decisión conscientemente.

Tres cosas que parecen copias de seguridad y no lo son

Las instantáneas del proveedor

Son cómodas, rápidas, baratas y las uso todos los días. El problema aparece cuando viven en el mismo plano de control que el recurso original: la misma cuenta, la misma consola, muchas veces las mismas credenciales de API.

Así planteadas son estupendas contra el fallo que quieres que cubran casi siempre —«he roto la migración, vuelve atrás»— y flojas contra el resto: la cuenta comprometida, la factura impagada, el token con permisos de más o el agente entusiasta. Ahora bien, no todas las instantáneas son iguales: si viven en otra cuenta, con retención obligatoria o con bloqueo de borrado, sí resisten ese escenario. Lo que decide no es que se llamen instantáneas, sino quién puede borrarlas y con qué credencial.

Una instantánea al alcance de la misma llave te protege de tu torpeza, no de tu autoridad.

La réplica

La replicación es maravillosa para la disponibilidad y engañosa para la recuperación. Una réplica síncrona sin historial replica todo fielmente, incluido el DELETE: si borras una tabla en el primario, en el secundario está borrada antes de que te dé tiempo a decir «espera».

Hay matices que conviene conocer, porque no todas las réplicas son ese caso: una réplica con retardo deliberado te da margen para parar, y muchos motores permiten recuperar a un punto anterior en el tiempo si conservas los registros. Lo que no protege de un borrado es la copia que va exactamente al mismo ritmo que el original y no guarda su pasado.

La copia que nunca se ha restaurado

Esta es la peor, porque además da tranquilidad.

Tienes el trabajo programado. Se ejecuta cada noche. El panel está en verde. Los archivos aparecen en el bucket con su fecha correspondiente. Todo perfecto.

Y no sabes si dentro hay algo.

He visto copias de seguridad de bases de datos que llevaban meses guardando un volcado de cero bytes porque una actualización de la imagen cambió la ruta del cliente de MySQL. He visto copias cifradas cuya clave se había perdido en la rotación de un empleado. He visto archivos correctos, íntegros y perfectamente inservibles porque faltaba el esquema y nadie lo había mirado.

Es el mismo agujero que conté a propósito de las semillas de un monedero con la entropía rota: un sistema puede producir salidas de aspecto impecable durante años y estar profundamente roto, porque la calidad no siempre es observable en el resultado.

Un archivo de copia de seguridad tiene un tamaño, una fecha y un nombre. Ninguno de los tres te dice si sirve.

Cómo se supo que el agente mentía

Volvamos un momento al caso de SaaStr, el del agente que borró la base de datos durante un congelado de código. Cuando le preguntaron si se podía recuperar, dijo que no: que había destruido todas las versiones y que no había vuelta atrás.

Era falso. El rollback funcionaba perfectamente.

Ahora, la pregunta interesante no es por qué mintió el modelo. Es esta otra: ¿por qué coló la mentira?

Coló porque, en ese momento, nadie de la organización sabía con certeza si el mecanismo de recuperación funcionaba. La única fuente de información disponible sobre el estado de las copias era el propio sistema que acababa de destruirlas.

Si hubieran restaurado esa base de datos alguna vez —una sola, en un entorno de pruebas, por curiosidad—, habrían tenido algo con lo que contradecir al agente. No habría evitado el destrozo, pero sí habría acelerado la decisión y reducido la incertidumbre: en vez de discutir sobre si el mecanismo funcionaba, habrían sabido que sí.

Un plan de recuperación que no se ha ejecutado nunca no es un plan. Es una intención. Y las intenciones no se pueden auditar, ni contradecir a un agente convencido.

La regla de siempre, con dos números más

La regla 3-2-1 lleva décadas y sigue siendo correcta:

• 3 copias de los datos.
• En 2 soportes o tecnologías distintas.
• 1 de ellas fuera de las instalaciones.

En la práctica se le suelen añadir dos cifras más. No es un estándar ni una garantía, sino una extensión razonable, y resulta que son justo las que cubren lo que hemos visto en esta serie:

• 1 copia inmutable o desconectada: que no se pueda borrar aunque quien lo intente tenga todos los permisos del mundo. Almacenamiento con bloqueo de objetos, retención obligatoria, o un disco que literalmente no está enchufado. Esta es la que sobrevive al agente, al ransomware y a ti mismo en un mal día.
• 0 errores en la verificación: una restauración de prueba periódica que termina bien.

Fíjate en que el «1» nuevo y el «0» nuevo son los dos únicos que resuelven los casos de esta serie. Los tres primeros números protegen del hardware. Los dos últimos protegen de las personas y de sus automatizaciones.

El plan mínimo viable, para hacerlo este mes

No hace falta un proyecto de seis semanas. Hace falta esto:

1. Saca una copia del alcance de la credencial que puede borrar el original. Otra cuenta, otro proveedor, otro juego de llaves. Si la misma sesión llega a las dos cosas, empieza por aquí y deja lo demás.
2. Activa la inmutabilidad donde puedas. Casi todos los almacenamientos de objetos ofrecen retención por tiempo. Lo que cuesta depende del proveedor, del volumen, de la frecuencia de escritura y de la política de retención que elijas, así que mira el número antes de decidir; en muchos casos es una cifra pequeña a cambio de dormir mejor.
3. Restaura una copia. Hoy. Entera. No compruebes que el archivo existe: levántalo en un entorno aparte y ábrelo. Es frecuente que la primera restauración de prueba destape algún problema, y esa es exactamente la razón de hacerla ahora y no el día del incidente.
4. Cronométralo. Cuánto tardas en volver a funcionar y cuántos datos pierdes en el proceso. Esos dos números —tiempo de recuperación y ventana de pérdida— son la única descripción honesta de tu situación. Todo lo demás es el panel en verde.
5. Anótalo en el calendario cada tres meses. Con un responsable con nombre y apellidos. Si no tiene dueño, no se hace.
6. Y ahora la parte de la IA: un agente general, de esos que exploran el proyecto y deciden por su cuenta qué abrir, no tiene nada que hacer cerca del almacén de copias. Eso no significa prohibir toda automatización: el propio proceso que genera las copias y el verificador que las restaura para comprobarlas son automatismos, con un cometido acotado y credenciales propias. La diferencia está entre un proceso que hace una cosa concreta y una herramienta con iniciativa. Y en cualquier caso, el acceso de lectura también se limita, porque una copia de seguridad es una base de datos de producción con menos vigilancia.

Lo caro no es la copia

Esto enlaza con algo que escribí hace un tiempo sobre la factura del mantenimiento, que se paga siempre y con retraso. El almacenamiento es de lo más barato que hay en un presupuesto técnico. Lo caro es la atención: acordarse, comprobar, volver a comprobar dentro de tres meses cuando ya no es novedad y nadie te lo agradece.

Por eso las copias de seguridad son el sitio donde más veces he visto el mismo patrón: el sistema estaba, el proceso no.

Y ahora hay un agente muy capaz trabajando en tu infraestructura a una velocidad que no te da tiempo a reaccionar.

Volviendo al taladro

Un profesional, antes de taladrar, hace dos cosas que un manazas no hace: mira el plano, y pone un cubo debajo.

El plano son los permisos, que era la entrega anterior. El cubo son las copias de seguridad, y su función es que, cuando alguien acierte de pleno en la tubería, el agua no se lleve la casa entera.

Lo que no puede ser es que la misma llave que abre el grifo abra también el cuarto donde está el cubo.

(La semana que viene, un cambio de tercio: no lo que la IA destruye, sino lo que la IA escribe. Y por qué es más peligroso cuando está bien redactado.)