Restaurar base de datos hasta la última transacción, aún en caso de
estar dañado el fichero de datos

INTRODUCCION

En la mayoría de los casos un administrador de datos, dependiendo de los recursos de que disponga y de la importancia que tenga la información que se está guardando, aplicará una estrategia de copias de seguridad, no vamos a entrar en la política que deberíamos o no deberíamos seleccionar.

SITUACIÓN INICIAL

Imaginemos que nuestra empresa realiza un backup completo de todas sus bases de datos todas las noches, y un backup del Log de transacciones cada hora. Concretando más, backup completo a las 00:00 de la madrugada, y tenemos el Log de transacciones de la 1:00, las 2:00, así sucesivamente. Pongámonos en el caso de que el fichero de datos (.mdf) quede dañado a las 11:45 de la mañana.

RESTAURACION DE COPIAS DE SEGURIDAD

Bien, los pasos a seguir para recuperar el backup más reciente sería:

Restaurar backup completo, importante, marcando la opción WITH NOT RECOVERY. A continuación restaurar los ficheros Log uno a uno hasta las 11:00 de la mañana, siempre con la opción WITH NOT RECOVERY, excepto el fichero de las 11:00, al cual marcaríamos como WITH RECOVERY.

Si nos planteamos esta situación, podemos certificar a nuestros clientes, o usuarios de nuestra empresa, que los datos han sido recuperados hasta las 11:00 de la mañana, los 45 minutos restantes han sido perdidos.

ACUERDOS DE NEGOCIO

Imaginaros que nuestra área comercial ha firmado un acuerdo de negocio con el cliente, donde nos comprometemos a mantener la integridad de sus datos hasta el último dato introducido., en caso de no cumplir dicho contrato nuestra empresa tendrá que abonar una indemnización.

SOLUCION APLICADA

Bien, técnicamente se puede solucionar y es lo que vamos a ver a continuación en un ejemplo gráfico paso a paso:

Primero, creamos una base de datos de prueba, llamada por ejemplo dbPruebas.

A continuación creamos una tabla llamada tbEmpleados, con los campos que aparecen en la imagen siguiente:

Insertamos en la tabla un primer registro.

Imaginaros que han llegado las 00:00 y realizamos el backup completo de la base de datos dbPruebas.

En estos momentos tenemos asegurado el primer registro introducido, ahora vamos a insertar un registro más.

Imaginar que pasa una hora y realizamos el backup de Log de transacciones.

Eso nos asegura que con el backup completo y con el backup de Log de transacciones, los datos introducidos los tenemos bien guardados. Ahora vamos a insertar un tercer registro.

Echemos un vistazo a nuestra carpeta donde están ubicadas nuestras copias de seguridad.

Hasta ahora tendríamos bien guardados los dos primeros registros de la tabla tbEmpleados, sin embargo el tercer registro hasta que no se ejecute el siguiente backup del Log, permanecerá en el fichero de transacciones (.ldf)

A continuación, vamos a parar el servicio del motor de la base de datos.

Nos situamos en la carpeta donde están los ficheros de las bases de datos.

Y directamente, eliminamos el fichero “dbPruebas.mdf”, sin miedo alguno.

Una vez eliminado el fichero de datos “dbPruebas.mdf”, se puede llegar a pensar que hemos perdido el tercer registro introducido, y por lo tanto tendremos que indemnizar al cliente. Para todo siempre existe una solución, y es la que vamos a aplicar aquí.

Antes de nada vamos a arrancar el servicio MSSQLSERVER.

Una vez iniciado el servicio, podemos comprobar que la base de datos dbPruebas, aparece en el listado pero no deja lógicamente desplegar su contenido. En versiones anteriores nos hubiese etiquetado la base de datos como sospechosa.

Vamos a crear una nueva consulta y escribimos lo siguiente.

Como podemos observar el backup de Log localiza el fichero “dbPruebas_log.ldf” y por lo tanto le es posible realizar un backup del mismo, incluso con el fichero de datos eliminado.

Echamos un vistazo a la carpeta donde se encuentran nuestras copias de seguridad.

Observamos que tenemos tres ficheros, el backup completo, el backup del Log que en teoría se hizo una hora después, y el backup del Log que acabamos de realizar, el cual contendría el tercer registro introducido.

Como hay muchos incrédulos, vamos a probar a restaurar los tres ficheros. Lo primero que debemos hacer, es borrar definitivamente la base de datos “dbPruebas”, así que nos situamos sobre ella y la eliminamos, sin contemplaciones.

Bien, una vez eliminada la base de datos causante del problema, comenzamos con la restauración del primer fichero, es decir, el backup completo.

Muy importante marcar la opción WITH NOT RECOVERY, para luego seguir añadiendo los ficheros de transacciones.

Al dejar la base de datos en estado NOT RECOVERY, vemos en la siguiente imagen que nos indica que esta base de datos lógicamente no se puede utilizar ya que se está restaurando.

Ahora procedemos a restaurar el primer fichero del Log de transacciones.

Y lo mismo hacemos con el segundo fichero del Log de transacciones, esta vez cuidado al seleccionar las opciones, ahora si que hay que marcar WITH RECOVERY, para dejar estable la base de datos, e informarle de que la restauración ha concluido.

Ahora, ya podemos desplegar el contenido de la base de datos “dbPruebas”, refrescamos por si acaso, y vemos la siguiente imagen.

Para comprobar que el milagro se ha hecho realidad, creamos una nueva consulta, nos situamos sobre la base de datos “dbPruebas”, y consultamos la tabla tbEmpleados.

Increíble, pero cierto. Podemos recuperar hasta el último dato introducido, incluso estando dañado el fichero de datos.