Restaurar una base de datos a un punto en el tiempo – parte 1

En varios escenarios, una restauración a un punto de tiempo de la base de datos puede requerirse. Típicamente, las siguientes situaciones requieren este tipo de recuperación:

• Una corrupción de datos ocurrió por una acción de un usuario malicioso. Por ejemplo, un usuario o un DBA puede eliminar o actualizar el contenido de una o más tablas por error, eliminar objetos de la base de datos que aún son requeridos durante una actualización a una aplicación, o realizar un gran proceso de actualización en lote que falla.
• Un proceso de actualización de la base de datos puede ir mal o un script de actualización de la base de datos falla.
• Una recuperación completa después de un fallo de medios no puede ser realizada porque el registro de transacciones requerido y las copias de seguridad de la base de datos están perdidos.

En cualquier situación, una recuperación a un punto del tiempo puede ser usada para retornar los datos y los objetos de la base de datos a su estado funcional previo a que la acción perjudicial haya sido realizada.

La habilidad de realizar este tipo de recuperación depende del modelo de recuperación establecido para la base de datos. La base de datos puede estar ya sea en el modelo de recuperación Completo o Por Medio de Registros de Operaciones Masivas. En el caso de que el modo de recuperación Simple haya sido usado, este método no es posible.

Note que, en caso de usar el modelo de recuperación Por Medio de Registros de Operaciones Masivas, algunos errores pueden ocurrir y la recuperación a un punto de tiempo puede fallar. Un error será lanzado en caso cuando cualquier operación masiva fuera realizada. Como tales operaciones son mínimamente registradas, no hay suficientes datos en un registro de transacciones en particular.

Restaurar una base de datos usando SQL Server Management Studio

SQL Server Management Studio en sí mismo provee un mecanismo para realizar una restauración de la base de datos a un punto en el tiempo. Para hacer eso, localice la base de datos que será restaurada en Object Explorer, seleccione la opción Task en el menú contextual, apunte a Restore y luego haga clic en el elemento del menú Database.

Esto abrirá el diálogo Restore Database – e la página General, use la sección Source para especificar la fuente y localización de los conjuntos de copias de seguridad a ser usados para el proceso de restauración. Adicionalmente, especifique un nombre diferente para la base de datos en la sección Destination para realizar una restauración a otra base de datos.

Use la opción Timeline para abrir el diálogo Backup Timeline, también conocido como la característica Database Recovery Advisor. Este diálogo provee opciones para localizar y especificar copias de seguridad para restaurar la base de datos a un punto en el tiempo. Asegura que sólo copias de seguridad que son requeridas para restaurar al punto en el tiempo seleccionado son seleccionadas. El punto en el tiempo deseado es siempre usado desde una copia de seguridad del registro.

Verifique el artículo de la base de conocimientos para información adicional acerca de crear y mantener una cadena completa de copias de seguridad del registro de transacciones – la cadena de copias de seguridad del registro desde una copia de seguridad completa de la base de datos existe, o una copia de seguridad completa de la base de datos, luego copias de seguridad diferenciales de la base de datos y luego la cadena de copias de seguridad del registro de transacciones desde ahí hasta el punto en el tiempo en el que quiere recuperar los datos.

Después de seleccionar y confirmar el punto en el tiempo deseado, el proceso de restauración puede ser iniciado.

Restaurar una base de datos usando T-SQL

Este método también requiere una cadena completa de registros de transacciones hasta e incluyendo el registro de transacciones que contiene el punto en el tiempo que necesita ser recuperado.

El T-SQL básico para restaurar a un punto en el tiempo es:

RESTORE LOG database_name
FROM <backup_device>
WITH STOPAT = time, RECOVERY…

La cláusula WITH STOPAT asegura que el proceso de restauración no restaura transacciones enviadas después del tiempo especificado (punto en el tiempo) y al mismo tiempo un error será lanzado si una copia de seguridad de los datos es demasiado reciente para el tiempo objetivo especificado.

Aquí está un ejemplo de T-SQL que restaura la base de datos a un punto en el tiempo. El parámetro FILE es usado en caso de múltiples conjuntos de archivos en el dispositivo de respaldo. En este ejemplo, el 2º conjunto es la copia de seguridad completa de la base de datos a ser restaurada, seguida por los 3º y 4º conjuntos que contienen copias de seguridad del registro de transacciones.

-- Restore full database backup
RESTORE DATABASE AdventureWorks2012
   FROM AW2012Backups
   WITH FILE=2, NORECOVERY;

-- Restore transaction log backup which is a part of the full chain
RESTORE LOG AdventureWorks2012
   FROM AW2012Backups
   WITH FILE=3, NORECOVERY, STOPAT = 'June 3, 2013 6:00 PM';

-- Restore transaction log backup which contains a point in time 
RESTORE LOG AdventureWorks2012
   FROM AW2012Backups
   WITH FILE=4, NORECOVERY, STOPAT = 'June 6, 2013 6:00 PM';
RESTORE DATABASE AdventureWorks2012 WITH RECOVERY; 
GO

Ahora que describimos las recuperaciones con SSMS y T-SQL, veamos los costos de tal enfoque de recuperación. Hay dos desventajas principales:

• Todas las copias de seguridad de la base de datos usadas y las copias de seguridad de transacciones deben ser restaurados, lo cual es un proceso que consume mucho tiempo.
• La base de datos siendo recuperada no está disponible para los usuarios hasta que el proceso de recuperación se completa.
• El éxito del proceso de recuperación es incierto hasta que finaliza (por ejemplo, en el caso de ocurrencias de registros de operaciones masivas o, si se usa T-SQL, un tiempo objetivo especificado incorrecto).

La manera fácil

Por otro lado, sólo leer registros de transacciones en línea, registros de transacciones y copias de seguridad de la base de datos parar realizar una recuperación a un punto en el tiempo es otra opción.

ApexSQL Log es una herramienta de recuperación de SQL Server capaz de leer datos del registro de transacciones y recuperar datos perdidos de la base de datos retrotrayendo transacciones a su estado original.

Para realizar la recuperación a un punto de tiempo usando ApexSQL Log:

1. Conéctese a la base de datos que será restaurada.

   

2. En el paso Select SQL Logs to analyze, añada cualquier copia de seguridad de registro de transacciones y/o registros desvinculados que contengan los datos necesitados – creando la cadena completa y proveyendo las transacciones hasta el punto en el tiempo que deseamos restaurar.

   

3. En el mismo paso provea la copia de seguridad completa de la base de datos que será usada como parte del punto de inicio desde el cual la cadena completa de transacciones comienza.

   

4. Usando la pestaña Time range, especifique el punto en el tiempo que es el objetivo para el proceso de recuperación – usado la opción Custom, especificando sólo el valor en From como el objetivo. Esto reducirá la búsqueda y el proceso de lectura al punto de tiempo exactamente requerido.

   

5. Cuando todo esto esté establecido, en el dialogo Result viewing options haga clic en la opción Open results in grid.

Todas las transacciones necesarias para retrotraerse serán mostradas en la cuadrícula principal de ApexSQL Log cuando el proceso finalice.

Ahora, todo lo que queda es crear el script de deshacer y ejecutarlo en la base de datos. Para hacer eso, use la opción Create undo script en la barra de herramientas principal. Abrirá el diálogo Undo script conteniendo el script deshacer resultante que puede ser ejecutado inmediatamente (usando este diálogo) en la base de datos conectada o grabado para uso o análisis posteriores.

Comparado con la recuperación a un punto de tiempo realizado vía SQL Server Management Studio o T-SQL, ApexSQL Log provee más detalles visualmente (cada transacción puede ser revisada) y lo que es más importante:

• Las copias de seguridad de la base de datos y el registro de transacciones siendo procesadas no son aplicadas/retrotraídas a la base de datos sino que son leídas, analizadas y sólo el script deshacer final está siendo aplicado, así que el proceso es más rápido.
• Durante el proceso, la base de datos siendo restaurada está disponible como una base de datos en línea.

Traductor: Daniel Calbimonte