Backup SQL: cómo elegir la copia y comprobar que se puede restaurar
Un backup SQL solo protege una base de datos si se puede restaurar dentro del tiempo disponible y con una pérdida de información asumible. Para diseñar la copia hay que decidir qué recuperar, hasta qué momento, con qué frecuencia y cómo comprobar que el proceso funciona; guardar un archivo no basta.
Qué se necesita recuperar y cuánto tiempo se puede perder
Antes de escoger una herramienta, define dos objetivos operativos. El RPO (objetivo de punto de recuperación) indica cuántos datos se acepta perder, expresados normalmente como tiempo. El RTO (objetivo de tiempo de recuperación) señala cuánto se puede tardar en volver a tener el servicio disponible. Son objetivos de negocio que condicionan la estrategia técnica.
Por ejemplo, en un sistema de pedidos, un RPO de una hora implica que una interrupción no debería dejar sin recuperar más de una hora de cambios. Si el RTO es de cuatro horas, el procedimiento completo —incluida la restauración y las comprobaciones— debe caber en ese plazo. Son cifras hipotéticas: cada organización debe acordarlas según el impacto de una parada y la capacidad de recuperación que realmente tiene.
También hay que delimitar el alcance. Una aplicación puede necesitar, además de la base de datos, ficheros adjuntos, configuración, certificados o claves. Una copia de las tablas que no incluya esos elementos quizá permita recuperar los registros, pero no reconstruir el servicio tal como funcionaba.
Copias completas, incrementales y registros de transacciones
Los términos cambian ligeramente entre gestores, así que hay que comprobar qué entiende por cada modalidad el producto concreto. En general, una copia completa contiene una imagen de la base de datos en un punto determinado. Es sencilla de identificar y restaurar, aunque puede ocupar más espacio y tardar más en generarse que una copia parcial.
Las copias incrementales guardan cambios desde otra copia, mientras que las diferenciales suelen reunir cambios desde una copia completa de referencia. Estas modalidades reducen el volumen de algunas operaciones, pero la restauración puede exigir combinar varias piezas. En determinados sistemas, la cadena de dependencias y el orden de aplicación son esenciales: perder un archivo intermedio puede impedir llegar al estado deseado.
Los registros de transacciones permiten, en gestores que ofrecen esa modalidad y con una configuración compatible, avanzar desde una copia de datos hasta un momento posterior. Esto puede reducir la pérdida de cambios frente a depender solo de copias completas periódicas. No equivale a una copia independiente: necesita una copia base válida y una cadena de registros disponible e íntegra.
La terminología no es intercambiable entre productos. SQL Server, PostgreSQL y MySQL cuentan con herramientas y modelos de recuperación distintos. Por ejemplo, un volcado lógico exporta estructuras y datos en un formato que se puede importar; una copia física conserva archivos o estructuras del gestor y suele depender más de la versión, la configuración y el método de creación. Antes de automatizar, hay que verificar qué modalidad admite el gestor y cómo se restaura.
Cómo diseñar una rutina que se pueda operar
Fijar frecuencia y retención
La frecuencia debe corresponder al RPO, no a una costumbre. Si solo se hacen copias cada noche, un fallo a media tarde podría dejar sin recuperar los cambios del día, salvo que haya otra técnica que capture transacciones entre copias. La retención determina cuánto tiempo se conservan los respaldos. Debe permitir recuperar ante borrados o daños que se descubran tarde, sin acumular archivos indefinidamente.
La retención puede combinar copias recientes de mayor resolución con copias más antiguas y espaciadas. Para decidirla, identifica cuánto tarda la organización en detectar un error y qué periodos necesita consultar. Una copia rotada antes de detectar una corrupción no resuelve el problema.
Separar las copias del sistema protegido
Si el backup se almacena únicamente en el mismo servidor, un fallo del equipo, un borrado accidental o un ataque con acceso administrativo podría afectar tanto a la base de datos como a sus copias. Mantén respaldos en un destino separado y limita quién puede modificarlos o eliminarlos. Cuando el riesgo lo justifique, una copia desconectada o con protección frente a cambios aporta una barrera adicional.
Protege también la confidencialidad: una copia contiene datos de producción y puede ser tan sensible como la base original. El cifrado debe cubrir el almacenamiento o la transferencia cuando proceda, y las claves necesarias para descifrar deben gestionarse de modo que puedan recuperarse durante una emergencia. Si las claves se pierden, un archivo cifrado puede resultar inutilizable.
Controlar el resultado, no solo la ejecución
Una tarea programada que termina con un estado correcto no demuestra por sí sola que el respaldo sea restaurable. Automatiza avisos ante fallos, falta de espacio, duración anómala o ausencia de archivos esperados. Conserva registros con fecha, base de datos, modalidad, resultado y ubicación, evitando que el propio log exponga credenciales.
La prueba decisiva: restaurar en un entorno aislado
La comprobación más útil consiste en restaurar una copia en un entorno separado de producción. Así se puede medir el tiempo real, detectar dependencias omitidas y verificar que la aplicación reconoce los datos. Una copia puede existir y, aun así, fallar por estar incompleta, dañada, cifrada con una clave inaccesible o generada con parámetros incompatibles.
- Selecciona una copia reciente y, si la política lo contempla, otra de una fecha anterior.
- Restaura siguiendo el procedimiento documentado, incluidas las dependencias de copias parciales o registros.
- Comprueba que el gestor abre la base, que los objetos esperados están presentes y que una consulta de control devuelve resultados coherentes.
- Verifica con el equipo responsable que la aplicación puede conectarse y realizar una operación de lectura; las pruebas de escritura deben limitarse al entorno aislado.
- Anota duración, errores, pasos manuales y cambios necesarios, y actualiza el procedimiento.
Una restauración de prueba no obliga a revelar datos reales a más personas. Usa un entorno con acceso restringido y, cuando sea adecuado, datos anonimizados o controles equivalentes. La prueba debe demostrar recuperación, no crear una nueva exposición.
Errores frecuentes al planificar un backup SQL
- Confundir replicación con copia de seguridad. Una réplica ayuda a mantener disponibilidad, pero puede replicar también un borrado o una modificación incorrecta. No sustituye a un respaldo histórico independiente.
- Guardar solo la copia más reciente. Si el daño se detecta tarde, esa copia podría contener ya el problema. Una retención escalonada permite elegir un punto anterior.
- Ignorar la capacidad de restauración. Un backup que tarda demasiado en recuperar el servicio no cumple un RTO exigente, aunque se genere sin errores.
- No incluir configuración y dependencias. Credenciales, claves, permisos, procedimientos de despliegue y datos externos pueden ser necesarios para volver a operar.
La estrategia adecuada es la que conecta una necesidad concreta de recuperación con copias disponibles, protegidas y probadas. Si gestionas varias tecnologías de almacenamiento o necesitas ampliar el diseño de datos, puedes consultar los contenidos de Bases de Datos; las instrucciones de copia y restauración, en cambio, deben ajustarse siempre al motor y a su configuración reales.
