Un backup efectivo es más que una copia de los datos: Es efectivo cuando se puede recuperar la información después de un error humano, una falla de hardware o un ataque de ransomware. Tradicionalmente se usa como punto de partida la regla 3-2-1: Conservar tres copias, en dos medios (lugares) diferentes, y mantener al menos una fuera del lugar principal. Pero hay algunos detalles más a considerar para hacerlo bien y salir invictos de la próxima caída.
No alcanza con copias en el mismo disco, ni tampoco con contratar un segundo servidor dentro del mismo proveedor. Las copias deben estar verificadas (¿se hicieron bien y completas? ¿se pueden abrir?). Y debemos tener cierta seguridad de que un atacante o ransomware no podrá acceder a las copias para eliminarlas o encriptarlas también.
Volvamos al 3-2-1. La primera copia es la información activa. Las otras dos deben tener cierta independencia: Por ejemplo, una copia local (mismo servidor o mismo proveedor) para recuperar rápido y otra en almacenamiento remoto. Remoto significa fuera del alcance de la falla que se intenta evitar, puede ser un servidor en otro proveedor en otra zona del mundo, o un servidor local en tu oficina. La frecuencia debe responder a cuánto trabajo se está dispuesto a perder: Un backup al día puede ser suficiente para algunos casos, pero totalmente insuficiente para una operación más dinámica, como un ecommerce con decenas de operaciones al día.
Para una persona que no administra servidores, la práctica puede ser sencilla: Activar el respaldo automático de fotos, contactos y documentos importantes del teléfono y la computadora en un servicio de almacenamiento en la nube, y hacer además una copia cada tanto en un disco externo. Para nuestros archivos personales, la nube es una protección más que suficiente frente a la pérdida o el robo del equipo. Pero hay un concepto clave a considerar: Sincronización no es backup. Si borrás accidentalmente, o un atacante toma tu cuenta y elimina tus archivos, la nube replicará la eliminación y perderás la copia. Además, siempre, por favor, usá contraseñas complicadas y únicas por servicio, con un buen gestor de contraseñas y, siempre que sea posible, segundo factor (token, OTP).
Para los más técnicos, herramientas como restic ayudan a organizar los backups como snapshots, estados recuperables de la información en distintos momentos. Son muy fáciles de automatizar, guardan los datos en repositorios cifrados, transfieren solo lo que cambió ahorrando tiempo y espacio, permiten conservar varias copias históricas sin que se desborde el almacenamiento necesario, y permiten verificar la integridad. Pero esto no elimina la necesidad de revisar y probar restauraciones. Un backup puede ejecutarse sin errores pero igual estar equivocado o incompleto.
Hay otra decisión de arquitectura menos común que puede mejorar mucho la protección: Quién inicia la copia. En el modelo habitual, el servidor de producción sube sus backups al servidor de respaldo. Pero deja la puerta abierta a que, así como subió los datos, los pueda quitar. Si el servidor se ve comprometido, el atacante puede encontrar las credenciales del servidor de backup y borrar las copias o encriptarlas también. Por eso también conviene tener un backup con un modelo pull, en el que el servidor de respaldo se conecta a producción y descarga los datos. De esta forma, el servidor de producción no tiene idea de cómo acceder a los backups.
Si bien este servidor requiere el mismo cuidado, porque tiene las credenciales de producción, es un poco más sencillo de proteger si no corre ningún otro servicio, un equipo local sin acceso remoto es un buen ejemplo. De esta forma ningún equipo comprometido puede destruir todas las copias, o al menos es prácticamente imposible que afecte a todas a la vez. Como siempre, en seguridad no se trata de ser infalible, que no existe, sino de ponerlo lo más difícil posible.
La pregunta decisiva no es “¿tenemos backups?”, sino “¿podemos reconstruir el sistema si mañana desaparece el servidor principal?”.