Recuperar una base de datos SQL Server usando sólo un archivo de registro de transacciones y archivos antiguos de respaldo

Tener un buen plan de recuperación que asegure que los respaldos de la base de datos están siendo tomados en cuenta de manera regular y almacenados de forma segura en dispositivos de almacenamiento específicos o múltiples, incrementa grandemente la seguridad de la base de datos y las opciones de recuperación cuando un desastre o un accidente ocurren. Sin embargo, crear respaldos completos de la base de datos regularmente no provee una recuperación completa a un punto de tiempo, ya que restaurar el último respaldo completo restaurará la base de datos a un estado apropiado en el tiempo en que el respaldo fue creado, pero todos los cambios, tanto de esquema como de datos, que han ocurrido después del último respaldo completo estarán prácticamente perdidos.

Independientemente de nuestra prevención y medidas de seguridad, algunos DBAs aún se encuentran en la situación donde las medidas de prevención no paran el desastre, y tampoco es posible recuperar la base de datos directamente con las herramientas usuales. Tal es el caso del desastre que destruye completamente nuestra base de datos y las únicas partes salvables son el respaldo antiguo de la base de datos y el archivo .ldf de la base de datos. Afortunadamente, hay una solución para este caso, un respaldo de base de datos combinado con un archivo .ldf son todo lo que se necesita para recuperar completamente la base de datos sin perder ningún esquema o datos de la base de datos original.

Para recuperar una base de datos SQL Server completamente, y para asegurarnos de que esos cambios que han ocurrido pueden ser re ejecutados después de obtener la copia de seguridad que será restaurada, requerimos usar el archivo .ldf desde la base de datos, leyendo la información desde ahí, y finalmente reproduciendo los cambios contra la base de datos. Esto puede ser logrado con ApexSQL Log – un lector de registros de transacciones que permite una vista profunda de los archivos de copias de seguridad y registros de transacciones, y provee algunas capacidades poderosas de recuperación para deshacer cambios no deseados, o reproducir cambios específicos leídos desde los archivos de registros de transacciones.

Asumamos el siguiente escenario:

Los respaldos completos regulares de la base de datos son tomados en las mañanas de domingo, y son automáticamente copiadas a algún almacenamiento por seguridad. A mitad de semana, (por ejemplo, en jueves), un desastre ocurre, y un archivo MDF de nuestra base de datos es generado prácticamente sin uso y la base de datos muestran grandes signos de corrupción. Incluso cuando parece que la única solución restante es restaurar la base de datos a la última copia de seguridad completa, y perder todos los datos de después de eso, este no es el caso. Para recuperar una base de datos de un desastre de estas proporciones, la base de datos necesita ser restaurada a la última copia de seguridad primero (domingo), y luego los cambios que han ocurrido desde ese punto de tiempo hasta el momento del desastre/corrupción necesitan ser reproducidos contra la base de datos restaurada con ApexSQL Log.

El primer paso del proceso es poner la base de datos fuera de línea, de manera que el archivo .ldf actual contenga los últimos cambios de la base de datos que pueden ser copiados, de manera que la información dentro no sea perdida cuando la última copia de seguridad de la base de datos sea restaurada. Dado que el archivo .ldf está bloqueado por SQL Server mientras la base de datos está en línea, y no puede ser copiado sin poner la base de datos fuera de línea primero, eso necesita ser hecho primero. Para hacer esto, los siguientes pasos deben ser realizados:

1. Conéctese a SQL Server vía SQL Server Management Studio.
2. Navegue a la base de datos en cuestión en el panel Object Explorer en la parte izquierda.
3. Abra el menú contextual con un clic derecho en la base de datos y navegue a Tasks y elija la opción Take offline.

   

Con esto, una copia del archivo ldf puede ser creada (con Windows explorer o similar), y la base de datos puede ser puesta en línea de nuevo siguiendo el mismo procedimiento mostrado arriba, y eligiendo la opción Bring online desde el mismo menú contextual.

Ahora que el archivo .ldf está seguro, el proceso de recuperación puede ser iniciado enfocándose en el segundo paso – la restauración de la base de datos.

La manera más simple de realizar esto es de nuevo usando SQL Server Management Studio.

1. Como antes, abra el menú contextual para su base de datos y navegue a Tasks > Restore y elija la opción Database…

   

2. En el diálogo Restore database, elija una copia de seguridad apropiada para ser restaurada (en nuestro caso, esta es la última copia de seguridad creada) y haga clic en el botón OK para realizar la restauración.

   

   Nota: varias opciones relacionadas con la restauración pueden ser especificadas en el diálogo Restore database, y esparcidas a través de las pestañas General, Files y Options del mencionado diálogo que permite a los usuarios afinar el proceso de restauración para adaptarlo a sus necesidades y situación.

3. Después de realizar la restauración de la base de datos, SQL Server Management Studio mostrará un mensaje informativo acerca del éxito del proceso.

   

Ahora que la base de datos ha sido restaurada a la última copia de seguridad, la única cosa restante es mandarle los cambios que han ocurrido después de que la copia de seguridad fuese generada para recuperar completamente la base de datos a su estado original pre desastre. Como se mencionó arriba, ApexSQL Log es la herramienta para el trabajo de leer el archivo .ldf salvado y reproducir los cambios en la base de datos restaurada.

1. Inicie ApexSQL Log y provea las credenciales de conexión a su SQL Server y seleccione la base de datos apropiada, y haga clic en Next para avanzar a través del asistente.

   

2. En el paso Data sources del asistente, deseleccione Online transaction log y añada la copia del archivo ldf que fue creado previamente. Para hacer esto, haga clic en el botón Add file, y navegue al archivo ldf. Asegúrese de que el archivo ldf añadido esté seleccionado, y haga clic en el botón Next para proceder.

   

3. En el paso Select output del asistente, seleccione la opción Undo/Redo.

   

   Nota: la opción seleccionada Undo/Redo permite la creación directa de un script rehacer para reproducir los cambios según los filtros asignados. Si el usuario desea inspeccionar los cambios y realizar un análisis a profundidad de estos en el archivo ldf previo a crear y ejecutar el script rehacer, la opción Open results in grid puede ser una selección válida aquí, ya que permite la visión de los resultados en una cuadrícula y la creación de un script rehacer después de afinar los resultados de la auditoría.

4. Una vez que una salida ha sido seleccionada, el paso Filter setup del asistente ofrece varios filtros y afinación de la auditoría. Para el ejemplo de arriba, elegir auditar una porción del archivo .ldf desde la última copia de seguridad completa, hasta el desastroso jueves, es una manera de hacerlo. Para esto, elija el rango de tiempo/fecha Custom e ingrese los valores apropiados de tiempo/fecha.

   

5. En adición a los filtros de tiempo/fecha, deberíamos asegurarnos de que los cambios DDL son también incluidos en el proceso de auditoría, dado que estos son excluidos por defecto en favor de una mejora en el desempeño. Simplemente haga clic en la pestaña Operations en el panel Filter setup, y seleccione las operaciones DDL para incluirlas.

   

6. Filtros adicionales y opciones avanzadas pueden ser usadas en el panel Filter setup para afinar los resultados, pero, para este caso, es recomendado saltar esto y proceder a hacer clic en el botón Next.
7. En el paso final del asistente, elija la opción de salida Redo (Reconstruct) script y especifique el nombre y localización para el archivo .sql creado.

   

8. Haga clic en el botón Finish y ApexSQL Log generará un script rehacer.

9. Una vez que el proceso sea completado y el archivo rehacer creado, la información de la auditoría puede ser encontrada en el lado derecho de la ventana, debajo de Auditing statistics, y el script rehacer puede ser abierto en el editor interno de ApexSQL Log.

   

10. Desde el editor interno de ApexSQL Log, el script rehacer creado puede ser inspeccionado, alterado si se requiere y ejecutado directamente contra la base de datos. Una vez que la ejecución se completa, todos los cambios que siguieron a la última copia de seguridad hasta el momento del desastre están de vuelta en la base de datos, como si el desastre nunca hubiera pasado, y la base de datos puede ser utilizada como si nada hubiera pasado, sin más problemas después.