La restauración de una base de datos a un punto en el tiempo es una habilidad crítica para cualquier DBA. Esta técnica nos permite recuperar datos hasta un instante específico, minimizando así la pérdida de información tras un incidente. En este artículo, abordaremos el proceso de restauración en SQL Server y Azure SQL, dos plataformas muy similares pero en las que vamos a encontrar diferencias a la hora de proceder. Empezaremos con una breve introducción a la restauración a un punto en el tiempo y luego nos adentraremos en los detalles técnicos.
¿Qué es restaurar a un punto en el tiempo?
La restauración a un punto en el tiempo es una técnica avanzada que nos permite revertir una base de datos a un estado anterior específico. Esto es especialmente útil cuando ocurren errores de usuario, fallos en las aplicaciones o cualquier otro tipo de problema que afecte la integridad de los datos. Para SQL Server y Azure SQL, el proceso varía ligeramente, pero el principio básico es el mismo: utilizar copias de seguridad (backups) completas y de logs de transacciones (transaction logs) para reconstruir la base de datos hasta el momento deseado.
Restauración a un punto en el tiempo en SQL Server
Para realizar una restauración a un punto en el tiempo en SQL Server, necesitamos disponer de una copia de seguridad completa de la base de datos y todas las copias de seguridad del registro de transacciones hasta el punto en el tiempo que queremos restaurar. Es, por tanto, necesario tener la base de datos en un modo de recuperación FULL o Bulk-logged.
Primero, asegurémonos de tener todas las copias de seguridad necesarias. La estrategia de copias de seguridad debería incluir backups completos y de logs de transacciones. Opcionalmente podremos disponer también de backups diferenciales. Los backups completos contienen toda la información de la base de datos, mientras que los diferenciales almacenan sólo los cambios desde el último backup completo. Los de log de transacciones, por su parte, registran todas las modificaciones realizadas en la base de datos desde el último backup de log. Una vez que confirmamos que disponemos de todas las copias de seguridad necesarias, procedemos a la restauración.
Para empezar, restauramos la copia de seguridad completa usando el siguiente comando:
RESTORE DATABASE MiBaseDatos
FROM DISK = 'Ruta/De/Mi/BackupCompleto.bak'
WITH NORECOVERY;El parámetro NORECOVERY es crucial, ya que permite aplicar backups adicionales antes de recuperar la base de datos. A continuación, restauramos cualquier backup diferencial (si existe):
RESTORE DATABASE MiBaseDatos
FROM DISK = 'Ruta/De/Mi/BackupDiferencial.bak'
WITH NORECOVERY;Finalmente, aplicamos los backups de los registros de transacciones hasta el punto en el tiempo deseado:
RESTORE LOG MiBaseDatos
FROM DISK = 'Ruta/De/Mi/BackupLog1.trn'
WITH NORECOVERY;
RESTORE LOG MiBaseDatos
FROM DISK = 'Ruta/De/Mi/BackupLog2.trn'
WITH STOPAT = 'AAAA-MM-DD HH:MM:SS';El parámetro STOPAT especifica el punto en el tiempo exacto al que queremos restaurar. Para completar el proceso, recuperamos la base de datos:
RESTORE DATABASE MiBaseDatos WITH RECOVERY;Usar STANDBY para encontrar un momento dado desconocido
En ocasiones, necesitamos restaurar la base de datos a un momento específico pero desconocido, donde ocurrió un evento crítico. En estos casos, la opción STANDBY resulta muy útil. Esta opción nos permite restaurar la base de datos en un estado de solo lectura después de aplicar cada backup de registro de transacciones. De esta manera, podemos inspeccionar la base de datos en diferentes puntos del tiempo hasta encontrar el momento exacto que necesitamos.
Para usar STANDBY, primero restauramos la copia de seguridad completa y cualquier backup diferencial como antes. Luego, aplicamos los registros de transacciones de la siguiente manera:
RESTORE LOG MiBaseDatos
FROM DISK = 'Ruta/De/Mi/BackupLog1.trn'
WITH STANDBY = 'Ruta/De/Mi/UndoFile.bak';
RESTORE LOG MiBaseDatos
FROM DISK = 'Ruta/De/Mi/BackupLog2.trn'
WITH STANDBY = 'Ruta/De/Mi/UndoFile.bak';El archivo UndoFile se utiliza para almacenar la información necesaria para revertir las transacciones no confirmadas, permitiendo que la base de datos se mantenga en un estado de solo lectura. Podemos repetir este proceso, aplicando registros de transacciones de uno en uno, verificando el estado de la base de datos después de cada restauración, hasta que encontremos el momento exacto que buscamos. Una vez que lo encontramos, aplicamos el resto de los registros de transacciones y finalizamos la restauración con WITH RECOVERY como hemos visto antes.
Restauración a un punto en el tiempo en Azure SQL
En Azure SQL, el proceso de restauración a un punto en el tiempo es más sencillo gracias a la infraestructura gestionada por Microsoft. Azure SQL realiza copias de seguridad automáticas y las almacena en un almacenamiento redundante.
Para restaurar una base de datos a un punto en el tiempo específico, usamos el portal de Azure o comandos de PowerShell/CLI. En el portal de Azure, navegamos a la base de datos que queremos restaurar, seleccionamos «Restore» y elegimos la opción «Point-in-time restore». Especificamos la fecha y hora a la que queremos restaurar y confirmamos la operación.
Mediante PowerShell, el comando sería similar a este:
Restore-AzSqlDatabase -FromPointInTimeBackup -ResourceGroupName "MiGrupoDeRecursos" -ServerName "MiServidor" -TargetDatabaseName "MiBaseDatosRestaurada" -PointInTime "AAAA-MM-DDTHH:MM:SSZ"El parámetro -PointInTime debe especificar el punto en el tiempo exacto en formato ISO 8601. Este proceso crea una nueva base de datos a partir del punto en el tiempo especificado.
Conclusión
Restaurar una base de datos a un punto en el tiempo en SQL Server y Azure SQL es una técnica vital que todos los administradores de bases de datos debemos dominar. En SQL Server, la restauración implica una secuencia cuidadosa de operaciones de restauracion de backups completos, diferenciales y de logs de transacciones. En Azure SQL, el proceso está simplificado gracias a las funcionalidades gestionadas por la plataforma.
Dominar esta habilidad nos permite asegurar la continuidad del negocio y la integridad de los datos tras cualquier incidente. Además, nos da la tranquilidad de saber que podemos recuperar información valiosa hasta el instante preciso en que ocurrió el problema. Sin duda, una habilidad indispensable en el arsenal de cualquier DBA experto.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.
