Backups y recuperación ante desastres en DevOps

Porque el único propósito de un backup es poder restaurarlo cuando hace falta, y tener una copia no garantiza que esa restauración vaya a funcionar. Una copia puede estar corrupta, incompleta, cifrada con una clave que se perdió, guardada en un formato que ya nadie puede leer, o simplemente nunca haber terminado de escribirse correctamente, y en todos esos casos es inútil aunque exista. Lo peor es que estos problemas no se manifiestan mientras todo va bien: se descubren justo en el peor momento, cuando ocurre el desastre y se intenta recuperar. Por eso la práctica correcta no es solo hacer copias, sino probar periódicamente su restauración en un entorno de prueba, verificando que los datos vuelven completos y utilizables. Las organizaciones serias tratan la restauración como un simulacro que se ensaya con regularidad. Una copia que nunca se restauró no es una garantía, es apenas una esperanza, y confiar en ella es uno de los errores más costosos en la gestión de datos.

Es la receta más difundida para diseñar una estrategia de backup robusta, recomendada por organismos de ciberseguridad. Establece tres condiciones. Primero, mantener al menos tres copias de los datos en total, contando el original y dos backups, de modo que la falla de una copia no deje al conjunto sin respaldo. Segundo, guardar esas copias en al menos dos tipos de medio distintos, por ejemplo un disco local y un almacenamiento en la nube, para que un problema que afecte a un tipo de medio no alcance a todas las copias a la vez. Tercero, conservar al menos una copia fuera del sitio, en una ubicación geográfica diferente e idealmente aislada o inmutable, es decir desconectada o protegida contra escritura, de manera que un desastre físico en el lugar principal o un ataque de ransomware que cifra todo lo que está conectado no logre alcanzar esa copia. Esta última condición, la copia aislada, es la que marca la diferencia frente al ransomware moderno, que busca activamente cifrar también los backups accesibles desde la red.

Son los dos números que guían el diseño de una estrategia de backup y recuperación, y tienen el mérito de plantear la decisión en términos del negocio y no meramente técnicos. El RPO, u objetivo de punto de recuperación, responde a la pregunta de cuántos datos se puede permitir perder la organización, medido en tiempo hacia atrás desde el momento del desastre; lo determina cada cuánto se hacen los respaldos, de modo que si se respalda una vez por día, en el peor caso se pierde hasta un día de datos, y si eso es inaceptable hay que respaldar más seguido. El RTO, u objetivo de tiempo de recuperación, responde a cuánto tiempo se puede tardar en volver a estar operativo, medido hacia adelante desde el desastre; lo determina qué tan ágil y automatizado es el proceso de restauración, de manera que un RTO de una hora exige una recuperación muy rápida. Ambos se fijan según cuánto le cuesta al negocio perder datos y permanecer caído, y de ellos se deriva cuánto conviene invertir en la estrategia.

Es un documento probado que describe con precisión quién hace qué, en qué orden y con qué herramientas para que una organización vuelva a operar después de una catástrofe, como la pérdida del servidor principal, un ataque que inutiliza los sistemas o un desastre físico en el centro de datos. Los backups son la materia prima de la recuperación, pero por sí solos no bastan: el plan es lo que los pone en uso de forma ordenada. Un buen plan responde de antemano a preguntas que en plena crisis no hay tiempo de resolver: de dónde se restaura, en qué orden se levantan los sistemas para respetar sus dependencias, quién toma las decisiones, cómo se comunica la situación. Lo decisivo es que el plan esté ensayado mediante simulacros y no solo escrito, porque la diferencia entre una organización que sobrevive a un desastre y una que no rara vez está en la tecnología, sino en tener un procedimiento claro y practicado. Cuando la infraestructura está descrita como código, recrear los servidores es rápido y reproducible, y el plan puede concentrarse en lo verdaderamente insustituible, que son los datos.

Sí, y de hecho un backup aislado y verificado es la mejor defensa para no tener que pagar un rescate, pero solo si está bien diseñado. El ransomware moderno no se limita a cifrar los archivos de trabajo: busca activamente localizar y cifrar también los backups que estén accesibles desde la red, precisamente para eliminar la posibilidad de recuperación y forzar el pago. Por eso un backup conectado permanentemente al sistema que protege ofrece una seguridad falsa, ya que puede ser cifrado junto con todo lo demás. La defensa efectiva es la copia aislada o inmutable que contempla la regla tres dos uno: una copia desconectada, en otra ubicación, o protegida contra escritura durante un período, de modo que el ransomware no pueda alcanzarla ni alterarla. Si además esa copia se prueba periódicamente para confirmar que se puede restaurar, la organización conserva la capacidad de recuperar sus datos por su cuenta y neutraliza buena parte de la extorsión. Complementar esto con la detección temprana y un plan de respuesta completa la protección.

Sí, y entender por qué aclara qué es lo que realmente hay que respaldar. La infraestructura como código permite recrear servidores, redes y configuraciones de forma rápida y reproducible a partir de archivos versionados, de modo que si se pierde una máquina, volver a levantarla es cuestión de aplicar el código en lugar de reconstruirla a mano. Eso reduce enormemente el problema de recuperar la infraestructura en sí. Pero hay algo que el código de infraestructura no contiene y que es insustituible: los datos. El contenido de las bases de datos, los archivos que subieron los usuarios, el estado acumulado de la aplicación, no se pueden regenerar recreando servidores, porque son únicos e irrecuperables si se pierden. Por eso, incluso con toda la infraestructura descrita en código, sigue siendo imprescindible respaldar los datos siguiendo la regla tres dos uno y saber restaurarlos, además de resguardar los secretos y la configuración necesarios para operar. La infraestructura como código cambia dónde se pone el esfuerzo de recuperación, concentrándolo en los datos, pero no elimina la necesidad de backups.