Rutas de recuperación

Es importante comprender las rutas de recuperación si se usan copias de seguridad diferenciales o de registros e, igualmente, si se recupera una base de datos a un momento anterior mediante uno de los métodos siguientes:

  • Realizar una restauración a un momento dado
  • Realizar una recuperación sin restaurar antes todas las copias de seguridad de registros o la copia de seguridad diferencial más reciente.

Si recupera una base de datos a un momento anterior y comienza a utilizarla desde ese momento, se creará una nueva ruta de recuperación. La ruta de recuperación es la secuencia de datos y copias de seguridad de registros que han llevado a una base de datos a un momento determinado, ya sea mediante el uso normal o con una restauración de datos y de registros específicos. Una ruta de recuperación consta de un conjunto exclusivo de transformaciones específicas que han hecho evolucionar a la base de datos a lo largo del tiempo manteniendo su coherencia. En la ilustración siguiente se muestra la relación entre un punto de recuperación y las rutas de recuperación resultantes.

Punto de recuperación y rutas de recuperación resultantes

Por lo general, un punto de recuperación inicia una nueva ruta de recuperación, ya que las transacciones deben revertirse y la base de datos se encuentra actualmente en un estado exclusivo. Puede que las copias de seguridad existentes tengan números de secuencia de registro (LSN) superiores al LSN del punto de recuperación. Los LSN de estas copias de seguridad están en una rama de recuperación diferente de la nueva rama que se ha creado en la operación de recuperación actual.

[!NOTA] El hecho de restaurar una copia de seguridad completa y recuperar la base de datos sin utilizar ningún otro tipo de copia de seguridad crea una nueva ruta de recuperación.

Recomendación Si no desea crear una ruta de recuperación que tenga varias bifurcaciones de recuperación, realice un conjunto completo de copias de seguridad de datos tan pronto como pueda después de recuperar la base de datos. Con este método, se garantiza que todas las copias de seguridad se realizan en una única rama de recuperación. Para comprobarlo, consulte la columna last_recovery_fork_guid de la tabla backupset o el conjunto de resultados RESTORE HEADERONLY.

En las situaciones siguientes se crea una nueva ruta de recuperación ya que la base de datos no se restaura hasta el "fin de los tiempos". Después de esto, existen copias de seguridad que pueden llevar a la base de datos por dos o más rutas de recuperación y todas usan el mismo intervalo de LSN.

  • Restaurar una copia de seguridad completa y una diferencial y recuperar la base de datos sin aplicar las copias de seguridad existentes del registro de transacciones.
  • Recuperar la base de datos hasta el final de una copia de seguridad diferencial que no sea la última realizada.
  • Recuperar la base de datos hasta el final de una copia de seguridad del registro de transacciones que no sea la última realizada.
  • Recuperar la base de datos hasta un momento determinado o una transacción con nombre incluida en una copia de seguridad del registro de transacciones.

Ejemplo de ruta de recuperación

En la siguiente ilustración se muestra la bifurcación de una nueva ruta de recuperación cuando se recupera la base de datos. En esta ilustración se crean una copia de seguridad completa y una secuencia de cuatro copias de seguridad de registros. A continuación, se restaura la base de datos hasta el final de la copia de seguridad de registros 2 (Log Backup 2); para ello, se restauran la copia de seguridad completa y las copias de seguridad de registros 1 (Log Backup 1) y 2 (Log Backup 2). La base de datos se recupera en este momento, creando una nueva bifurcación de recuperación. Después, se utiliza la base de datos y se crean dos copias de seguridad adicionales del registro de transacciones, las copias de seguridad de registros 5 (Log Backup 5) y 6 (Log Backup 6).

Ejemplo de ruta de recuperación

La copia de seguridad de la base de datos y las primeras cuatro copias de seguridad de registros están en la rama 1. Las copias de seguridad de registros 5 (Log Backup 5) y 6 (Log Backup 6) están en la rama 2. La bifurcación de recuperación incluye el último LSN de la copia de seguridad de registros 2 (Log Backup 2) (Log_Backup_2.LastLSN) y el primer LSN de la copia de seguridad de registros 5 (Log Backup 5) (Log_Backup_5.FirstLSN).

Dentro de la copia de seguridad de registros 5 (Log Backup 5), first_recovery_fork_guid identifica a la rama 1 y last_recovery_fork_guid identifica a la rama 2. La ruta de recuperación es rama 1, rama 2.

[!NOTA] No es necesario restaurar la base de datos hasta el final de una copia de seguridad de registros para bifurcar a una nueva ruta.

Para realizar una restauración y realizar una puesta al día con una ruta antigua

Se recomienda evitar el uso de una ruta de recuperación antigua, ya que así la base de datos puede tener transacciones confirmadas en dos intervalos de tiempo diferentes. Sin embargo, si fuera necesario, puede realizar una puesta al día con una ruta antigua, si sigue la secuencia de las copias de seguridad realizadas antes de la creación de la ruta de recuperación actual. Por ejemplo, puede utilizar las copias de seguridad realizadas antes de una recuperación a un momento dado para alcanzar los puntos con la ruta antigua.

[!NOTA] Para crear dos bases de datos de un elemento primario común, en cada base de datos, tenga en cuenta la ruta de recuperación que debe utilizarse para alcanzar el "fin de los tiempos" de la base de datos.

Por ejemplo, según las copias de seguridad creadas en la ilustración anterior, después de crear la copia de seguridad de registros 5 (Log Backup 5) y 6 (Log Backup 6), aún se puede restaurar hasta el final de la copia de seguridad de registros 3 (Log Backup 3), que está en la ruta de recuperación antigua.

Para realizar una restauración y realizar una puesta al día desde una ruta antigua hasta una nueva

SQL Server Database Engine (Motor de base de datos de SQL Server) impide que una sola secuencia de restauración utilice copias de seguridad que no van juntas, es decir, que intente realizar una puesta al día con dos rutas de recuperación distintas. Esta restricción permite mantener la coherencia de una base de datos tras una recuperación.

Para realizar una restauración y una puesta al día con una nueva ruta de recuperación, construya secuencias de restauración distintas para las copias de seguridad realizadas antes y después del punto de recuperación.

  1. Restaure las copias de seguridad realizadas antes de la recuperación que aportó la nueva ruta de recuperación, excluyendo la que incluya el punto de recuperación.
  2. Realice una puesta al día con la nueva ruta de recuperación restaurando las copias de seguridad realizadas desde la creación de la ruta de recuperación.

Por ejemplo, según las copias de seguridad creadas en la ilustración anterior, asuma que la copia de seguridad de registros 3 (Log Backup 3) abarca de las 10 a. m. a las 11 a. m. Se ha realizado una restauración a un momento dado que especificaba STOPAT**=10:**30. Esto ha creado una bifurcación en la ruta de recuperación e iniciado una nueva rama de recuperación: rama 2. La primera copia de seguridad de registros de la nueva rama (Log Backup 5), incluye el mismo primer LSN que la copia de seguridad de registros 3 (Log Backup 3), que es sustituida ya que ahora está inactiva. Para realizar la restauración de las copias de seguridad en la nueva ruta de recuperación (comenzando en la rama 1 y finalizando en la rama 2), la secuencia de restauración es: copia de seguridad completa de la base de datos, copia de seguridad de registros 1 (Log Backup 1), copia de seguridad de registros 2 (Log Backup 2), copia de seguridad de registros 5 (Log Backup 5) y copia de seguridad de registros 6 (Log Backup 6).

Administrar bifurcaciones de recuperación

Una rama de recuperación es una serie de LSN que comparten el mismo GUID. Una ruta de recuperación describe una serie de LSN desde un punto de inicio (LSN o GUID) hasta un extremo (LSN o GUID). La serie de LSN de una ruta de recuperación puede incluir una o varias ramas de recuperación desde el principio hasta el final. Se creará una nueva rama de recuperación cuando se cree una base de datos y RESTORE WITH RECOVERY genere una bifurcación de recuperación.

Una bifurcación de recuperación es el punto (LSN o GUID) en el que se inicia una nueva rama de recuperación cada vez que se ejecuta RESTORE WITH RECOVERY. Cada bifurcación de recuperación determina una relación entre las ramas de recuperación primarias y secundarias.

La recuperación de la base de datos establece el estado de la base de datos completa, incluido el siguiente LSN, en el punto de recuperación. A continuación, se vuelven a utilizar los LSN, empezando con fork_point_lsn. Por lo tanto, cuando se construye una secuencia de restauración, se deben vincular las copias de seguridad mediante la bifurcación de recuperación además del LSN, porque puede que exista el mismo LSN en más de una bifurcación. En la siguiente ilustración se muestra la forma en la que se reutilizan los LSN. Se muestra cómo se reutilizan LSN en diferentes bifurcaciones de recuperación.

Cómo se reutilizan LSN en diferentes bifurcaciones de recuperación

Si una secuencia de restauración debe incluir copias de seguridad que pasan por una bifurcación de recuperación, se debe construir de modo que las copias de seguridad utilizadas sigan la ruta de recuperación correcta hasta el punto de recuperación. Las copias de seguridad incluyen backupset.first_recovery_fork_guid y backupset.last_recovery_fork_guid con este fin. Éstas se utilizan para vincular las copias de seguridad con el fin de asegurarse de que la secuencia sigue la bifurcación adecuada.

Los valores de la tabla del historial backupset permiten determinar qué conjunto de copia de seguridad se debe utilizar:

  • Para cada copia de seguridad de registros de la secuencia que se restaurará, first_recovery_fork_guid debe ser igual a last_recovery_fork_guid de la copia de seguridad anterior en la secuencia.
    first_recovery_fork_guid = last_recovery_fork_guid
  • También se deben vincular las copias de seguridad de datos y diferenciales.
    Si la copia de seguridad de registros incluye tanto el último LSN de una copia de seguridad completa o diferencial de la base de datos como un punto de bifurcación, la prueba de vinculación dependerá de la ubicación del último LSN con respecto al punto de bifurcación.
    Las pruebas de vinculación son las siguientes, con valores de backupset:
    • Si el valor de last_lsn es menor o igual que el valor de fork_point_lsn, el valor de last_recovery_fork_guid de la copia de seguridad de datos o diferencial debe ser igual al valor de first_recovery_fork_guid de la copia de seguridad de registros. En la siguiente ilustración se muestra un caso en el que el valor de last_lsn es menor que el valor de fork_point_lsn.
      last_lsn es menor que fork_point_lsn
    • Si el valor de last_lsn es mayor que el valor de fork_point_lsn, el valor de last_recovery_fork_guid de la copia de seguridad de datos o diferencial debe ser igual al valor de last_recovery_fork_guid de la copia de seguridad de registros. En la siguiente ilustración se muestra un caso en el que el valor de last_lsn es mayor que el valor de fork_point_lsn.
      last_lsn es mayor que fork_point_lsn
  • En el caso de una copia de seguridad diferencial, busque la base diferencial mediante backupset.differential_base_guid.
    Si la diferencial es multibase, el valor de backupset.differential_base_guid será NULL y deberá determinar las bases diferenciales archivo por archivo mediante backupfile.differential_base_guid.

Vea también

Conceptos

Copiar bases de datos con Copia de seguridad y Restaurar
Planear y llevar a cabo secuencias de restauración (modelo de recuperación completa)
Introducción a los números de secuencia de registro
Números de secuencia de registro y planeamiento de la restauración
Base de una copia de seguridad diferencial

Otros recursos

Implementar escenarios de restauración para bases de datos de SQL Server

Ayuda e información

Obtener ayuda sobre SQL Server 2005