Copias de seguridad y restauración de bases de datos

Hacer copias de seguridad de la base de datos es especialmente importante porque, de todos los componentes de una aplicación, la base de datos suele ser el más valioso e irreemplazable. El código fuente está guardado en un repositorio y puede volver a desplegarse, los servidores pueden reconstruirse y la configuración puede recrearse, pero los datos que contiene una base de datos, como los usuarios, sus pedidos, su historial, sus mensajes o el contenido que han generado, son únicos e irrepetibles, de modo que si se pierden no hay ninguna forma de reconstruirlos a partir de otra cosa. Perder la base de datos puede significar literalmente el fin de un proyecto o de un negocio, junto con graves consecuencias legales y de confianza si afecta a datos de terceros. Las amenazas que pueden provocar esa pérdida son numerosas y variadas: un fallo del disco o del hardware que destruye el almacenamiento, un borrado accidental como ejecutar una eliminación sin la condición adecuada o eliminar una tabla por error, un fallo de la aplicación que corrompe los datos, un ataque de ransomware que los cifra y los secuestra, o un desastre físico como un incendio o una inundación en el centro de datos. Ninguna de estas situaciones se resuelve con las garantías internas de la base de datos, que protegen la coherencia durante el funcionamiento normal pero no ante estos escenarios catastróficos. La única red de seguridad real frente a todas estas amenazas es disponer de copias de seguridad a partir de las cuales se pueda restaurar la base de datos a un estado anterior bueno, lo que convierte a una estrategia sólida de copias en una de las inversiones más importantes y rentables en la protección de cualquier sistema que dependa de sus datos.

La copia lógica y la copia física son dos enfoques distintos para respaldar una base de datos, cada uno con sus ventajas. La copia lógica, a menudo llamada volcado o dump, consiste en generar un archivo que contiene las instrucciones necesarias para recrear la base de datos desde cero, es decir, la definición de su estructura y los datos, en un formato que suele ser texto portable y legible. Su gran ventaja es la portabilidad: al ser un conjunto de instrucciones, una copia lógica se puede restaurar a menudo en distintas versiones del motor de base de datos e incluso trasladar entre sistemas, y resulta cómoda y flexible para bases de datos de tamaño pequeño y mediano. Su desventaja es que, en bases de datos muy grandes, generar y sobre todo restaurar una copia lógica puede ser lento, porque implica reejecutar todas las instrucciones para reconstruir los datos. La copia física, en cambio, consiste en respaldar directamente los archivos a bajo nivel en los que el motor de base de datos almacena físicamente los datos, obteniendo una imagen de ellos. Su ventaja es la velocidad: crear y restaurar una copia física suele ser mucho más rápido en bases de datos de gran tamaño, porque se trabaja directamente con los archivos en lugar de reconstruir todo mediante instrucciones. Su desventaja es la menor portabilidad, ya que una copia física suele depender de la misma versión y configuración del motor, y no se puede trasladar tan libremente entre sistemas distintos. En la práctica, ambos tipos son complementarios, y la elección depende del tamaño de la base de datos, de la frecuencia de las copias y de las necesidades de portabilidad y de velocidad de restauración; muchas estrategias serias combinan ambos enfoques según el escenario.

La regla tres dos uno es un principio ampliamente recomendado para diseñar una estrategia robusta de copias de seguridad, y su nombre resume las tres condiciones que debe cumplir. El tres significa mantener al menos tres copias de los datos, contando el conjunto de datos original en producción y dos copias de seguridad adicionales; la idea es que tener múltiples copias reduce drásticamente la probabilidad de perderlo todo, ya que harían falta varios fallos simultáneos para quedarse sin ninguna. El dos significa guardar esas copias en al menos dos tipos de medio o soporte distintos, de modo que no se dependa de un único tipo de almacenamiento que pudiera tener un modo de fallo común; por ejemplo, no tener todas las copias en discos del mismo tipo y lote, que podrían fallar por la misma causa. El uno significa mantener al menos una de las copias fuera del sitio, es decir, en una ubicación física diferente de donde están los datos originales, ya sea en otro edificio o en la nube, y preferiblemente aislada o desconectada. Esta copia externa es la clave de la regla y la que aporta protección frente a los desastres que afectarían a todo un mismo lugar, como un incendio, una inundación, un robo o un ataque de ransomware que cifre todo lo que esté accesible en la red local. La regla tres dos uno es sencilla de recordar y ofrece un marco muy sólido, ya que combina redundancia mediante varias copias, diversidad de soportes para evitar fallos comunes, y separación geográfica para sobrevivir a desastres locales, cubriendo así un abanico amplio de amenazas con un principio fácil de aplicar y de verificar.

Se dice que un backup no probado no cuenta porque tener copias de seguridad y tener copias de seguridad que realmente funcionan son dos cosas distintas, y solo la segunda ofrece protección real. Una copia que nunca se ha restaurado es, en el fondo, una promesa sin verificar: se asume que a partir de ella se podría reconstruir la base de datos, pero esa suposición no se ha comprobado nunca, y hay muchas razones por las que podría fallar en el momento de la verdad. La copia podría estar corrupta por un error en el proceso de respaldo, podría estar incompleta porque el proceso no incluía todas las tablas o todos los datos relevantes, podría haberse estado generando de una fuente equivocada o desactualizada, el proceso de restauración podría fallar por incompatibilidades o por falta de algún componente, o podría descubrirse que el procedimiento para restaurar no está documentado y nadie sabe realmente cómo hacerlo bajo presión. El problema es que todos estos fallos permanecen invisibles hasta que se intenta restaurar de verdad, y si eso solo ocurre por primera vez el día de un desastre real, se corre el riesgo de descubrir que las copias no sirven justo cuando ya no hay margen para arreglarlo. De hecho, muchas de las pérdidas de datos más graves de la historia no se debieron a la ausencia de copias, sino a copias que existían pero que no funcionaban cuando se necesitaron. Por eso una buena práctica imprescindible es probar periódicamente la restauración, restaurando las copias en un entorno de prueba y verificando que la base de datos reconstruida está completa y es funcional. Solo tras superar esa prueba se puede afirmar que se dispone de un backup de verdad, y no de una mera ilusión de seguridad.

Sí, las copias de seguridad deben ser automáticas siempre que sea posible, porque cualquier proceso que dependa de que una persona se acuerde de ejecutarlo manualmente está condenado a fallar tarde o temprano. La experiencia demuestra que las tareas manuales y repetitivas se olvidan, se posponen o se ejecutan de forma inconsistente, especialmente cuando todo va bien y la necesidad de la copia no se siente como urgente, que es precisamente cuando más importa mantener la disciplina. Una copia de seguridad que se hace solo cuando alguien se acuerda acabará teniendo lagunas, y esas lagunas suelen coincidir, por mala fortuna, con el momento del desastre. La solución es programar las copias como tareas automáticas que se ejecutan de forma fiable según una planificación definida, sin intervención humana, empleando para ello los mecanismos de tareas programadas del sistema o las herramientas propias de gestión de copias. Ahora bien, automatizar la ejecución es necesario pero no suficiente, porque una automatización que falla en silencio da una peligrosa falsa sensación de seguridad: el proceso podría dejar de funcionar por un cambio de configuración, un disco lleno o un error, y si nadie lo supervisa, se creería estar protegido sin estarlo. Por eso la automatización debe acompañarse de supervisión, es decir, de comprobar periódicamente que las copias se están generando correctamente y alertar si alguna falla, y de las pruebas de restauración ya mencionadas. Además, al diseñar la automatización hay que decidir la frecuencia de las copias en función de cuántos datos se puede permitir perder la organización en el peor caso, y la política de retención, es decir, cuánto tiempo se conservan las copias antiguas. Con ejecución automática, supervisión y pruebas de restauración, la estrategia de copias se vuelve fiable en lugar de depender de la memoria y la buena voluntad.

No, ni la replicación ni las garantías ACID sustituyen a las copias de seguridad, porque protegen frente a amenazas distintas y dejan sin cubrir precisamente los escenarios para los que existen los backups. Las garantías ACID aseguran la integridad y la coherencia de los datos durante el funcionamiento normal de la base de datos y ante fallos como caídas a mitad de una operación, pero no protegen frente a un borrado accidental correctamente confirmado, la avería del medio de almacenamiento o la corrupción por causas externas; de hecho, si alguien borra datos por error mediante una transacción válida, ACID garantizará diligentemente que ese borrado se aplique de forma íntegra y duradera. La replicación, por su parte, consiste en mantener copias sincronizadas de la base de datos en varios servidores, y es excelente para la alta disponibilidad y para tolerar el fallo de un servidor, ya que otro puede tomar el relevo; sin embargo, tiene una limitación crítica como mecanismo de respaldo: como las réplicas se mantienen sincronizadas en tiempo real o casi, cualquier operación destructiva, como un borrado accidental o la corrupción introducida por un error de la aplicación o por un ataque, se propaga inmediatamente a todas las réplicas, que quedan igual de dañadas que el original. Es decir, la replicación multiplica la disponibilidad pero también multiplica el error, y no ofrece la posibilidad de volver a un estado anterior bueno. Las copias de seguridad son las únicas que proporcionan esa capacidad de retroceso en el tiempo, ya que conservan estados pasados de los datos que no se ven afectados por lo que ocurra después en producción, especialmente si están aisladas. Por eso una estrategia completa combina las tres cosas: ACID para la integridad operativa, replicación para la disponibilidad, y copias de seguridad probadas y aisladas para la recuperación ante desastres, borrados y corrupciones. Confundir cualquiera de las dos primeras con un backup es un error peligroso y frecuente.