Descripción de cómo funcionan la restauración y la recuperación de copias de seguridad en SQL Server

Actualizado: 17 de julio de 2006

Este tema es relevante para todas las bases de datos de SQL Server.

La restauración es el proceso de copiar datos desde una copia de seguridad y aplicar transacciones registradas a los datos para ponerlos al día hasta el punto de recuperación de destino. Una copia de seguridad de datos o diferencial contiene suficientes registros de transacciones para permitir poner al día las transacciones activas como parte de la restauración de cada copia de seguridad. Cada copia de seguridad contiene suficientes registros para revertir las transacciones no confirmadas y llevar la base de datos a un estado coherente con la transacción y utilizable. El proceso de poner al día las transacciones no confirmadas, si las hay, y poner la base de datos en conexión se conoce como recuperación.

Conjunto de puestas al día

El proceso de aplicar cambios registrados a los datos de una base de datos para poner los datos al día se conoce como poner al día. El conjunto de todos los datos restaurados se conoce como el conjunto de puestas al día. Un conjunto de puestas al día se define con la restauración de una o más copias de seguridad completas, como una copia de seguridad de base de datos o parcial, o un conjunto de copias de seguridad de archivos. Si una instrucción RESTORE especifica grupos de archivos, archivos o páginas, sólo se incluyen estos elementos en el conjunto de puestas al día. De lo contrario, se incluirán en el conjunto de puestas al día todos los archivos de la copia de seguridad que se está restaurando. Si la copia de seguridad completa contiene entradas de registro, los datos restaurados se pondrán al día mediante este registro.

[!NOTA] Si especifica un grupo de archivos durante la restauración, ésta engloba todo el grupo de archivos tal como existe actualmente. Esto incluye los archivos agregados al grupo de archivos desde que se realizó la copia de seguridad. Para obtener más información, vea Controlar la creación de archivos agregados durante la puesta al día.

Para copias de seguridad diferenciales, si se agregaron archivos a la base de datos desde la base diferencial, la restauración de una copia de seguridad diferencial podría sobrescribir páginas del conjunto de puestas al día con datos de la copia de seguridad diferencial. Para obtener más información, vea Usar copias de seguridad diferenciales.

La restauración de una copia de seguridad diferencial sólo actualiza una página si ésta está en el conjunto de puestas al día; la página se incluye en la copia de seguridad y la instrucción RESTORE muestra la página o su archivo o no muestra ningún archivo ni página.

Con los modelos de recuperación completa y de recuperación por medio de registros de operaciones masivas, se debe realizar una copia de seguridad independiente del registro. Después de restaurar copias de seguridad de datos y (opcionalmente) diferenciales, en general debería restaurar las copias de seguridad de registros subsiguientes para llevar la base de datos al punto de error. Restaurar una copia de seguridad de registros pone al día todas las páginas del conjunto de puestas al día. Para obtener más información acerca de las copias de seguridad de registros, vea Trabajar con copias de seguridad del registro de transacciones.

Secuencias de restauración

Cada escenario de restauración se implementa mediante uno o varios pasos de restauración (operaciones), lo que se denomina secuencia de restauración. Cada operación corresponde a una instrucción RESTORE de Transact-SQL independiente. Una secuencia de restauración mueve los datos afectados a través de una o varias fases de la restauración.

Para obtener más información acerca de las secuencias de restauración de Transact-SQL y de cómo crearlas, vea Trabajar con secuencias de restauración para bases de datos de SQL Server.

Fases de la restauración

Una restauración es un proceso de varias fases. Las fases posibles de una restauración incluyen las fases de copia de datos, rehacer (puesta al día) y deshacer (revertir):

• La fase de copia de datos implica copiar todos los datos, el registro y las páginas de índice desde el medio de copia de seguridad de una base de datos a los archivos de la base de datos.
• La fase de rehacer aplica las transacciones registradas a los datos copiados desde la copia de seguridad para poner al día esos datos hasta el punto de recuperación. Normalmente, en este punto una base de datos tiene transacciones no confirmadas y se encuentra en un estado inutilizable. En ese caso, se requiere una fase de deshacer como parte de la recuperación de la base de datos.
• La fase de deshacer, que es la primera parte de la recuperación, revierte cualquier transacción no confirmada y hace que la base de datos esté disponible para los usuarios. Después de la fase de reversión, no se pueden restaurar las copias de seguridad subsiguientes.

El resto de esta sección examina estas fases con más detalle.

Fase de copia de datos

La primera fase de todo proceso de restauración es la fase de copia de datos. La fase de copia de datos inicializa el contenido de la base de datos, los archivos o las páginas que se restauran. Esta fase se realiza mediante las operaciones de restaurar la base de datos, restaurar archivos y restaurar páginas utilizando copias de seguridad completas o diferenciales.

La fase de copia de datos implica copiar datos de una o más copias de seguridad completas y, de forma opcional, copias de seguridad diferenciales y, a continuación, restablecer el contenido de la base de datos, los archivos o las páginas afectados en el momento en que fueron capturados por esas copias de seguridad.

El archivo o la página más antiguo del conjunto de puestas al día determina el punto de inicio de la siguiente fase: rehacer (puesta al día).

Fase de rehacer (puesta al día)

Rehacer (o puesta al día) es el proceso de rehacer los cambios registrados hasta los datos del conjunto de puestas al día para avanzar los datos en el tiempo Para llevar a cabo la puesta al día, SQL Server Database Engine (Motor de base de datos de SQL Server) procesa las copias de seguridad de registros conforme se restauran, empezando por el registro contenido en las copias de seguridad completas.

La restauración evita las puestas al día innecesarias. Generalmente, si los datos eran de sólo lectura cuando se realizó la copia de seguridad y han permanecido como de sólo lectura, la puesta al día es innecesaria y se omite.

Punto de recuperación

El objetivo de la puesta al día es devolver los datos a su estado original en el punto de recuperación. El punto de recuperación es el punto hasta el que el usuario especifica que debe recuperarse el conjunto de datos. Con el modelo de recuperación completa, puede especificar el punto de recuperación como un momento determinado, una transacción marcada o un número de secuencia de registro. Con el modelo de recuperación por medio de registros de operaciones masivas, sólo puede realizar la restauración a un momento dado si no se ha realizado ninguna operación masiva desde la copia de seguridad de registros anterior.

Coherencia de rehacer (puesta al día)

En la fase de rehacer, los datos siempre se ponen al día hasta un punto que es coherente para rehacer con el estado de la base de datos en el punto de recuperación. Todos los datos se han puesto al día hasta un punto en el que se puede realizar la operación de deshacer.

El archivo principal define el estado de la base de datos, como se indica a continuación:

• Si el archivo principal se está restaurando, el punto de recuperación determina el estado de toda la base de datos. Por ejemplo, si una base de datos se está recuperando a un momento dato justo antes de que la tabla se quitara accidentalmente, toda la base de datos debe restaurarse al mismo momento dado.
• Si el archivo principal no se está restaurando, el estado de la base de datos es conocido y los datos restaurados se ponen al día hasta un punto de recuperación transaccionalmente coherente con la base de datos. SQL Server lo exige.

Sin embargo, la base de datos puede contener cambios realizados por transacciones que no están confirmadas en el punto de recuperación. Para la restauración con conexión, los datos se recuperan a un momento dado coherente con el estado actual de la parte conectada de la base de datos.

Una copia de seguridad diferencial avanza hasta el punto en que se realizó la copia de seguridad diferencial. Las páginas del conjunto de puestas al día se sobrescriben con páginas más recientes de la copia de seguridad diferencial.

Fase de deshacer (revertir) y recuperación

Después de que la fase de rehacer haya puesto al día todas las transacciones del registro, una base de datos suele contener los cambios realizados por las transacciones no confirmadas en el punto de recuperación. Esto convierte los datos puestos al día en transaccionalmente incoherentes. El proceso de recuperación abre el registro de transacciones para identificar las transacciones no confirmadas. Las transacciones no confirmadas se deshacen mediante la reversión, a menos que mantengan bloqueos que eviten que otras transacciones vean datos transaccionalmente incoherentes. Este paso se denomina fase de deshacer (o revertir). Si los datos ya son transaccionalmente coherentes al inicio del proceso de recuperación, la fase de deshacer se omitirá. Después de que la base de datos sea transaccionalmente coherente, la recuperación conecta la base de datos.

[!NOTA] En términos generales, la recuperación es el conjunto de operaciones que hace que una base de datos sea coherente al inicio de esa base de datos. Si la base de datos se apagaba periódicamente, la recuperación omite las fases de rehacer y deshacer. Esto se conoce como recuperación de reinicio.

Después de que se hayan restaurado una o más copias de seguridad, la recuperación suele incluir tanto la fase de rehacer y como la de deshacer. Cada copia de seguridad completa y diferencial contiene suficientes registros de transacciones para permitir que los datos de esa copia de seguridad se recuperen a un estado coherente consigo mismo.

[!NOTA] Durante una recuperación tras bloqueo o una conmutación por error de la creación de reflejo de la base de datos, SQL Server 2005 Enterprise Edition permite a los usuarios obtener acceso a la base de datos durante la fase de deshacer. Esto se conoce como recuperación rápida. La recuperación rápida es posible porque las transacciones que no estaban confirmadas cuando se produjo el error vuelven a adquirir los bloqueos que mantenían antes del error. Mientras estas transacciones se revierten, sus bloqueos las protegen de las interferencias de los usuarios.

Relación de las opciones RECOVERY y NORECOVERY con las fases de restauración

Una instrucción RESTORE específica termina después de la fase de rehacer o continúa con la fase de deshacer, según si la instrucción especificó WITH NORECOVERY, de la manera siguiente:

• WITH RECOVERY recupera la base de datos e incluye las fases de rehacer y deshacer; no se pueden restaurar otras copias de seguridad. Es el valor predeterminado.
  Si el conjunto de puestas al día no se ha puesto al día lo suficiente para ser coherente con la base de datos, la fase de deshacer no se podrá producir. Database Engine (Motor de base de datos) emitirá un error y la recuperación se detendrá.
  Si todo el conjunto de puestas al día es coherente con la base de datos, se realizará la recuperación y se podrá conectar la base de datos.
• WITH NORECOVERY omite la fase de deshacer para preservar las transacciones no confirmadas. Al omitir la fase de deshacer, se pueden restaurar otras copias de seguridad para poner al día la base de datos a un momento posterior. A veces, RESTORE WITH NORECOVERY pone al día los datos hasta donde son coherentes con la base de datos. En estos casos, Database Engine (Motor de base de datos) emite un mensaje informativo indicando que el conjunto de puestas al día se puede recuperar mediante la opción RECOVERY.
  Para obtener información acerca de los conjuntos de puestas al día, vea Descripción de cómo funcionan la restauración y la recuperación de copias de seguridad en SQL Server.

[!NOTA] Existe una tercera alternativa, WITH STANDBY, pero está fuera del ámbito de este tema.

Para obtener una descripción detallada y completa de las opciones RESTORE, vea RESTORE (Transact-SQL).

Rutas de recuperación

Una ruta de recuperación es un conjunto único de transformaciones que han cambiado la base de datos a lo largo del tiempo, aunque han mantenido su coherencia. Para obtener información acerca de las rutas de recuperación y los conceptos relacionados con las bifurcaciones y las ramas de recuperación, vea Rutas de recuperación.

Restaurar una base de datos cuando SQL Server no está conectado

Es posible restaurar y recuperar una base de datos mediante SQL Writer mientras SQL Server no está conectado si no hay ningún catálogo de texto. Si hay un catálogo de texto asociado a una base de datos, primero es necesario iniciar SQL Server o detener el servicio Motor de texto completo de Microsoft para SQL Server (MSFTESQL).

Al ejecutarse, SQL Server obliga a cerrar los archivos del catálogo de texto como preparación para la operación de restauración. Sin embargo, si SQL Server está sin conexión, es posible que MSFTESQL mantenga abiertos determinados archivos de texto. Así se evita que la aplicación de restauración los sobrescriba. Para obligar a esos archivos de texto a cerrarse, una aplicación puede apagar MSFTESQL.

Para evitar tener que hacer esto, realice alguna de las siguientes acciones:

• Inicie SQL Server. Para obtener más información, vea Iniciar y reiniciar servicios.
• Detenga MSFTESQL. Para obtener más información, vea Detener servicios.

Vea también

Conceptos

Información general sobre restauración y recuperación en SQL Server
Trabajar con copias de seguridad del registro de transacciones

Otros recursos

Crear copias de seguridad completas y diferenciales de una base de datos de SQL Server
Implementar escenarios de restauración para bases de datos de SQL Server
Trabajar con secuencias de restauración para bases de datos de SQL Server

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios