3.2 definicion del esquema de recuperacion.
- Jorge Alejandro Gutiérrez Velázquez - 22010073
- Juan carlos galván hernández - 22010071
- Gabriel Vázqeuz Gutiérrez - 22010085
- JAVIER MAGDALENO PÉREZ - 22010074
Introducción
el esquema de recuperación se refiere a un conjunto de procedimientos y estrategias diseñadas para restaurar informacion a su estado anterior en caso de fallos, errores o desastres.
iNDICE
1. Modelos de recuperación. 2. Dispositivos de copia de seguridad. 3. Familias y conjuntos de medios. 4. Conjuntos de medios de copia de seguridad reflejados. 5. Restauración y recuperación. 6. Información de encabezado e historial. 7. Posibles errores de medios. 8. Modelo de recuperación simple. 9. Modelo de recuperación completa.
10. Archivos y grupos de archivos. 11. Restauraciones de archivos simples. 12. Restauraciones de archivos completas. 13. Por etapas. 14. Registro de transacciones. 15. Transacciones marcadas. 16. Restauración en línea. 17. Transacciones diferidas.
Backups - modelo de recuperación
Un backup o copia de seguridad es una duplicación de la información importante de un sistema o dispositivo para protegerla de pérdidas o daños. Las operaciones de copia de seguridad y restauración de SQL Server se producen en el contexto del modelo de recuperación de la base de datos.
Dispositivos de copia de seguridad
Especificar un archivo de copia de seguridad mediante su nombre físico (Transact-SQL)
La sintaxis de BACKUP para especificar un archivo de copia de seguridad mediante su nombre de dispositivo físico es:
BACKUP DATABASE database_name
TO DISK = { 'nombre_del_dispositivo_de_copia_de_seguridad_física' | @nombre_del_dispositivo_de_respaldo_físico.bak}
Familias y conjuntos de medios.
Familias de Medios:Una familia de medios es una colección de medios de copia de seguridad que se almacenan en un único dispositivo de copia de seguridad.
Conjuntos de Medios:
Un conjunto de medios es una colección ordenada de familias de medios que se utilizan para almacenar una o más operaciones de copia de seguridad.
ejemplo:
Conjuntos de medios de copia de seguridad reflejados (SQL Server)
Un conjunto de medios reflejado consta de varias copias (reflejos) de los conjuntos de medios. Cada reflejo incluye todas las familias de medios del conjunto de medios. Esto significa que si tienes un conjunto de medios con varias familias de medios, cada reflejo contendrá todas esas familias.
Este ejemplo de un conjunto de medios reflejado que incluye dos familias de medios con dos reflejos. Cada familia de medios incluye tres volúmenes de medios, de los cuales se realiza una copia de seguridad por reflejo cada vez.
restauración y recuperación (SQL Server)
Para recuperarse de un error, una base de datos de SQL Server, un administrador de bases de datos tiene que restaurar un conjunto de copias de seguridad de SQL Server en una secuencia de restauración correcta y significativa de forma lógica.
- La base de datos (una restauración de la base de datos completa)
- El archivo de datos (una restauración de archivos)
- La página de datos (una restauración de páginas)
6. Información de encabezado e Historial
La base de datos msdb en SQL Server almacena un historial detallado de todas las operaciones de copia de seguridad y restauración realizadas en una instancia de servidor. Este tema abarca: Recomendación importante: Para minimizar el riesgo de pérdida de datos recientes en el historial, es fundamental realizar copias de seguridad frecuentes de la base de datos msdb.
- Las tablas que contienen el historial de estas operaciones.
- Las instrucciones de Transact-SQL necesarias para acceder al historial.
- Situaciones en las que es útil consultar las listas de archivos de bases de datos y registros de transacciones.
- Cuándo usar la información de encabezado de medios y de copias de seguridad.
6. Información de encabezado e Historial
Tablas del historial de copias de seguridad y restauración
En esta sección se presentan las tablas del historial que almacenan metadatos de copias de seguridad y restauración en la base de datos del sistema msdb .
6. Información de encabezado e Historial
Instrucciones Transact-SQL para tener acceso al historial de copias de seguridad
Las instrucciones de información de la restauración corresponden a información almacenada en ciertas tablas del historial de copias de seguridad.
- RESTORE FILELISTONLY:-- backupfile --Muestra una lista de los archivos de base de datos y registros en un conjunto de copia de seguridad.
- RESTORE HEADERONLY:-- backupset --Proporciona información del encabezado de todos los conjuntos de copias de seguridad en un dispositivo.
- RESTORE LABELONLY:-- backupmediaset --Devuelve información sobre el medio de copia de seguridad de un dispositivo especificado.
6. Información de encabezado e Historial
Archivos de base de datos y de registro de transacciones
La información de los archivos de base de datos y registros en una copia de seguridad incluye el nombre lógico, físico, tipo de archivo, grupo al que pertenece, tamaño, tamaño máximo permitido y tamaño de crecimiento predefinido.
Información de encabezado de medios
La información de encabezado de medios incluye datos sobre el medio, como su nombre, descripción, software creador y fecha de escritura.
Información de encabezado de copia de seguridad
El encabezado de copia de seguridad muestra información sobre todos los conjuntos de copia de seguridad, incluyendo tipos de dispositivos, tipos de copia (base de datos, transacción, archivo o diferencial) y fechas de inicio y fin. Es útil para identificar qué conjunto restaurar o qué copias contiene el medio.
6. Información de encabezado e Historial
Qué conjunto de copia de seguridad se debe restaurar
La información del encabezado de copia de seguridad permite identificar el conjunto a restaurar mediante su posición en el medio, ya que el Motor de base de datos numera cada conjunto.
Comparación de la información del encabezado de medios y del encabezado de copia de seguridad
La diferencia entre los encabezados radica en que el encabezado de medios se obtiene al leer solo el inicio de la cinta, mientras que el de copia de seguridad requiere examinar toda la cinta para cada conjunto.
7. Posibles eRRORES DE mEDIOS
- SQL Server ofrece la opción de recuperación de una base de datos a pesar de los errores detectados. - Un importante mecanismo de detección de errores nuevo es la creación opcional de una suma de comprobación de copia de seguridad que se puede crear mediante una operación de copia de seguridad y validar mediante una operación de restauración. - Puede controlar si una operación comprueba si hay errores y si la operación se detiene o continúa al encontrar un error. - Si una copia de seguridad contiene una suma de comprobación de copia de seguridad, las instrucciones RESTORE y RESTORE VERIFYONLY pueden comprobar si hay errores. Las copias de seguridad reflejadas proporcionan hasta cuatro copias (reflejos) de un conjunto de medios, ofreciendo copias alternativas para recuperar el sistema de los errores provocados por los medios dañados.
7. Posibles eRRORES DE mEDIOS
Comprobaciones de copia de seguridad
- SQL Server admite tres tipos de sumas de comprobación: una suma de comprobación de páginas, una de bloques de registro y una de copia de seguridad. - Al generar una suma de comprobación de copia de seguridad, BACKUP comprueba que los datos que se leen de la base de datos son coherentes con cualquier suma de comprobación o indicación de página rasgada de la base de datos. - Debido a la carga que supone comprobar y generar sumas de comprobación de seguridad, su utilización puede tener consecuencias negativas sobre el rendimiento. - Pueden quedar afectados tanto la carga de trabajo como el rendimiento de la copia de seguridad.- Cuando vaya a generar sumas de comprobación durante una copia de seguridad, supervise cuidadosamente la sobrecarga de CPU en la que se incurrirá, así como el impacto sobre las posibles cargas de trabajo simultáneas del sistema.
7. Posibles eRRORES DE mEDIOS
Back-Up
- BACKUP no modifica nunca la página de origen del disco ni el contenido de una página.
- Cuando se habilitan las sumas de comprobación de copia de seguridad, una operación de copia de seguridad realiza los siguientes pasos:
- Antes de escribir una página en los medios de copia de seguridad, la operación de copia de seguridad comprueba la información en el nivel de página (suma de comprobación de página o detección de página rasgada), si existe. Si no existe, la copia de seguridad no puede comprobar la página.
- Aunque se incluyan sumas de comprobación de página, BACKUP genera una suma de comprobación de copia de seguridad independiente para las secuencias de copia de seguridad. La suma de comprobación de copia de seguridad se almacena en el medio de copia de seguridad y no en las páginas de la base de datos.
- El conjunto de copia de seguridad se marca para indicar que contiene sumas de comprobación de copia de seguridad (en la columna has_backup_checksums de msdb..backupset).
- Durante una operación de restauración, si hay sumas de comprobación de copia de seguridad en los medios de copia de seguridad, de forma predeterminada, las operaciones RESTORE y RESTORE VERIFYONLY comprueban las sumas de comprobación de copia de seguridad y las sumas de comprobación de página.
7. Posibles eRRORES DE mEDIOS
Respuesta a errores de suma de comprobación de página durante una operación de copia de seguridad o restauración
- De forma predeterminada, después de encontrar un error de suma de comprobación de página, una operación BACKUP o RESTORE produce un error y una operación VERIFYONLY continúa. - Sin embargo, se puede controlar si una operación dada se detiene al encontrar un error o continúa de la mejor manera posible.
- Si una operación BACKUP continúa después de encontrar errores, la operación realiza los siguientes pasos:
- Indica en el conjunto de copia de seguridad de los medios de copia de seguridad que hay errores y realiza el seguimiento de la página en la tabla suspect_pages de la base de datos msdb.
- Registra el error en el registro de errores de SQL Server.
- Marca el conjunto de copia de seguridad como conjunto que contiene este tipo de error (en la columna is_damaged de msdb.backupset).
- Emite un mensaje que indica que la copia de seguridad se generó correctamente, pero contiene errores de página.
8. Modelo de Recuperación Simple
El objetivo es restaurar toda la base de datos. Durante el proceso de restauración, la base de datos completa se encuentra sin conexión. Antes de que ninguna parte de la base de datos esté en línea, se recuperan todos los datos a un punto.Se recomienda no adjuntar ni restaurar bases de datos de orígenes desconocidos o que no sean de confianza. Es posible que estas bases de datos contengan código malintencionado que podría ejecutar código de Transact-SQL no deseado o provocar errores al modificar el esquema o la estructura de la base de datos física.Para usar una base de datos desde un origen desconocido o que no sea de confianza, ejecute DBCC CHECKDB en la base de datos de un servidor que no sea de producción y examine también el código.
8. Modelo de Recuperación Simple
Información general de la restauración
- Una restauración completa de base de datos con el modelo de recuperación simple implica una o dos instrucciones RESTORE, en función de si desea restaurar una copia de seguridad diferencial de la base de datos. - Si solo usa copias de seguridad completas de la base de datos, restaure solo la copia de seguridad más reciente, como se muestra.- Si también usa una copia de seguridad diferencial de la base de datos, restaure la copia de seguridad completa más reciente de la base de datos sin recuperar la base de datos y, a continuación, restaure la copia de seguridad diferencial más reciente de la base de datos y recupere la base de datos.
8. Modelo de Recuperación Simple
Sintaxis RESTORE de Transact-SQL básica
- La sintaxis RESTORE de Transact-SQL básica para restaurar una copia de seguridad de base de datos completa es:RESTORE DATABASE database_name FROM backup_device [ WITH NORECOVERY ]- La sintaxis RESTORE básica para restaurar una copia de seguridad de la base de datos es:
RESTORE DATABASE database_name FROM backup_device WITH RECOVERY
NotaUse WITH NORECOVERY si también desea restaurar una copia de seguridad diferencial de la base de datos.
8. Modelo de Recuperación Simple
Ejemplo (Transact-SQL)
- En el siguiente ejemplo se muestra primero cómo usar la instrucción BACKUP para crear una copia de seguridad completa y diferencial de la base de datos AdventureWorks2022. - A continuación, se restauran estas copias de seguridad una después de la otra. La base de datos se restaura a su estado en el momento en que finalizó la copia de seguridad diferencial.
- En el ejemplo se muestran las opciones críticas de una secuencia de restauración en un escenario de restauración de base de datos completa. - Una secuencia de restauración consta de dos o más operaciones de restauración que mueven datos en una o varias fases de restauración. - La sintaxis y los detalles no pertinentes para este propósito se omiten. - Al recuperar una base de datos, se recomienda especificar explícitamente la opción RECOVERY por motivos de claridad, aunque es la opción predeterminada.
USE master;
--Make sure the database is using the simple recovery model.
ALTER DATABASE AdventureWorks2022 SET RECOVERY SIMPLE;
GO
-- Back up the full AdventureWorks2022 database.
BACKUP DATABASE AdventureWorks2022
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
WITH FORMAT;
GO
--Create a differential database backup.
BACKUP DATABASE AdventureWorks2022
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
WITH DIFFERENTIAL;
GO
--Restore the full database backup (from backup set 1).
RESTORE DATABASE AdventureWorks2022
FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
WITH FILE=1, NORECOVERY;
--Restore the differential backup (from backup set 2).
RESTORE DATABASE AdventureWorks2022
FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
WITH FILE=2, RECOVERY;
GO
9. Modelo de Recuperación Completa (Restauraciones de archivos)
- La restauración de archivos permite recuperar archivos dañados sin restaurar toda la base de datos. - Si el grupo de archivos es de lectura/escritura, es necesario aplicar copias de seguridad de registros para actualizarlo hasta el punto de recuperación, normalmente cerca del final del registro. - Para grupos solo lectura, generalmente no se necesitan registros, y se restaura la última copia de seguridad realizada tras marcarlo como solo lectura.
9. Modelo de Recuperación Completa
Restauraciones de archivos
Los escenarios de restauración de archivos son los siguientes:
- Restauración de archivos sin conexiónEn una restauración de archivos sin conexión, la base de datos permanece sin conexión mientras se restauran los archivos o grupos de archivos dañados. Al final de la secuencia de restauración, la base de datos pasará a estar en línea.Todas las ediciones de SQL Server admiten restauraciones de archivos sin conexión.
- Restauración de archivos en líneaEn restauración de archivos en línea, si la base de datos está en línea durante una restauración de archivos, permanecerá en línea durante la restauración de archivos. Sin embargo, cada grupo de archivos en el que se restaura un archivo está sin conexión durante la operación de restauración. Una vez recuperados todos los archivos de un grupo de archivos sin conexión, este se conecta automáticamente.
9. Modelo de Recuperación Completa
Restauracion A PARTIR DE COPIAS DE SEGURIDAD
- Antes de restaurar uno o varios archivos dañados, intente crear una copia del final del registro.Si se ha dañado el registro, no se puede crear una copia del final del registro y se debe restaurar toda la base de datos.
- Restaure cada archivo dañado a partir de la copia de seguridad más reciente de ese archivo.
- Restaure la copia de seguridad diferencial de archivos más reciente, si existe, para cada archivo restaurado.
- Restaure las copias de seguridad del registro de transacciones en orden, comenzando con la copia de seguridad que abarca el más antiguo de los archivos restaurados y finalizando con la copia del final del registro después del error creada en el paso 1.
- Recuperar la base de datos.
- Debe hacer que la base de datos sea coherente; para ello, restaure las copias de seguridad del registro de transacciones creadas después de las copias de seguridad de archivos. - Las copias de seguridad del registro de transacciones se pueden poner al día rápidamente, porque solo se aplican los cambios correspondientes a los archivos restaurados. - La restauración de archivos individuales puede ser mejor que la restauración de toda la base de datos, dado que los archivos dañados no se copian y, posteriormente, ponen al día. - Sin embargo, aún debe leerse toda la cadena de copias de seguridad de registros.
9. Modelo de Recuperación Completa
sECUENCIA DE RESTAURACIÓN SIN CONEXIÓN
--Take the file offline.
ALTER DATABASE database_name MODIFY FILE SET OFFLINE;
-- Back up the currently active transaction log.
BACKUP LOG database_name
TO <tail_log_backup>
WITH NORECOVERY;
GO
-- Restore the files.
RESTORE DATABASE database_name FILE=name
FROM <file_backup_of_file_A>
WITH NORECOVERY;
RESTORE DATABASE database_name FILE=<name> ......
FROM <file_backup_of_file_B>
WITH NORECOVERY;
-- Restore the log backups.
RESTORE LOG database_name FROM <log_backup>
WITH NORECOVERY;
RESTORE LOG database_name FROM <log_backup>
WITH NORECOVERY;
RESTORE LOG database_name FROM <tail_log_backup>
WITH RECOVERY;
- Un escenario de restauración de archivos consiste en una única secuencia de restauración que copia, pone al día y recupera los datos apropiados.
- En esta sección se muestran las opciones esenciales de RESTORE para una secuencia de restauración de archivos. - La sintaxis y los detalles no pertinentes para este propósito se omiten.
- La secuencia de restauración de ejemplo siguiente muestra una restauración sin conexión de dos archivos secundarios, A y B, mediante WITH NORECOVERY. - A continuación, se aplican dos copias de seguridad de registros con NORECOVERY y, después, la copia del final del registro después del error, recuperada con WITH RECOVERY.
Realizar copias de seguridad de archivos y grupos de archivos
Para crear una copia de seguridad de archivos o de un grupo de archivos, use una instrucción BACKUP DATABASE< >file_or_filegroup. Como mínimo, esta instrucción debe especificar:
- Nombre de la base de datos.
- Una cláusula FILE o FILEGROUP para cada archivo o grupo de archivos, respectivamente.
- El dispositivo de copia de seguridad en el que se escribirá la copia de seguridad completa.
La sintaxis Transact-SQL básica para una copia de seguridad de archivos es: BACKUP DATABASE database
{ FILE =logical_file_name | FILEGROUP =logical_filegroup_name } [ ,...f ]
TO backup_device [ ,...n ]
[ WITH with_options [ ,...o ] ] ;
database
FILEGROUP =logical_filegroup_name
Es la base de datos para la que se realiza la copia de seguridad del registro de transacciones, de una parte de la base de datos o de la base de datos completa.
Especifica el nombre lógico de un grupo de archivos que se debe incluir en la copia de seguridad de archivos. En el modelo de recuperación simple, se permite la copia de seguridad de un grupo de archivos solo si se trata de un grupo de archivos de solo lectura.
FILE =logical_file_name
Especifica el nombre lógico de un archivo que se debe incluir en la copia de seguridad de archivos.
backup_device [ ,...n ]
Especifica una lista de 1 a 64 dispositivos de copia de seguridad que se pueden utilizar en la operación de copia de seguridad. Puede especificar un dispositivo físico de copia de seguridad o puede especificar un dispositivo de copia de seguridad lógico correspondiente, si ya se definió.
[ ,...f ]
Se trata de un marcador de posición que indica que se pueden especificar varios archivos y grupos de archivos. El número de archivos o grupos de archivos es ilimitado.
WITH with_options [ ,...o ]
Opcionalmente, especifica una o más opciones, como DIFFERENTIAL. Una copia de seguridad diferencial de archivos necesita una copia de seguridad completa de archivos como base.
Ejemplos
Los siguientes ejemplos realizan copias de seguridad de uno o más archivos de los grupos de archivos secundarios de la base de datos Sales. Esta base de datos utiliza el modelo de recuperación completa y contiene los siguientes grupos de archivos secundarios:
- Un grupo de archivos denominado SalesGroup1 , con los archivos SGrp1Fi1 y SGrp1Fi2.
- Un grupo de archivos denominado SalesGroup2 , con los archivos SGrp2Fi1 y SGrp2Fi2.
A. Crear una copia de seguridad de archivos de dos archivos
En el siguiente ejemplo se crea una copia de seguridad diferencial de archivos solo del archivo SGrp1Fi2 de SalesGroup1 y del archivo SGrp2Fi2 del grupo de archivos SalesGroup2 .
B. Crear una copia de seguridad de archivos completa de los grupos de archivos secundarios
En el ejemplo siguiente se crea una copia de seguridad de archivos completa de cada archivo en los dos grupos de archivos secundarios.
C. Crear una copia de seguridad de archivos diferencial de los grupos de archivos secundarios
En el ejemplo siguiente se crea una copia de seguridad de archivos diferencial de cada archivo en los dos grupos de archivos secundarios.
Limitaciones y restricciones
Recomendaciones
- La instrucción BACKUP no se permite en una transacción explícita o implícita.
- En el modelo de recuperación simple, se debe hacer una copia de seguridad de todos los archivos de lectura/escritura juntos. Esto ayuda a garantizar que la base de datos se pueda restaurar a un punto temporal coherente.
De forma predeterminada, cada operación de copia de seguridad correcta agrega una entrada en el registro de errores de SQL Server y en el registro de eventos del sistema. Si se hace una copia de seguridad del registro de transacciones con frecuencia, estos mensajes que indican la corrección de la operación pueden acumularse rápidamente, con lo que se crean registros de errores muy grandes que pueden dificultar la búsqueda de otros mensajes. En esos casos, puede suprimir estas entradas de registro con la marca de seguimiento 3226 si ninguno de los scripts depende de esas entradas.
Permisos
De forma predeterminada, los permisos BACKUP DATABASE y BACKUP LOG se corresponden a los miembros del rol fijo de servidor sysadmin y de los roles fijos de base de datos db_owner y db_backupoperator.
Los problemas de propiedad y permisos del archivo físico del dispositivo de copia de seguridad pueden interferir con una operación de copia de seguridad. SQL Server debe poder leer y escribir en el dispositivo y la cuenta en la que se ejecuta el servicio SQL Server debe tener permisos de escritura.
Con el modelo de recuperación completa, también debe realizar copias de seguridad del registro de transacciones. Para utilizar un conjunto completo de copias de seguridad de completas archivos para restaurar una base de datos, también debe tener suficientes copias de seguridad de registros que abarquen todas las copias de seguridad de archivos, desde el principio de la primera copia de seguridad de archivos.
Restauraciones de archivos (modelo de recuperación simple)
Este tema solo es relevante para las bases de datos de modelo simple que incluyen como mínimo un grupo de archivos secundario de solo lectura. El objetivo de una restauración de archivos consiste en restaurar uno o varios archivos dañados sin necesidad de restaurar la totalidad de la base de datos. En el modelo de recuperación simple, las copias de seguridad de archivos se admiten únicamente para los archivos de solo lectura.
Los escenarios de restauración de archivos son los siguientes:
- Restauración de archivos sin conexión:
En una restauración de archivos sin conexión, la base de datos permanece sin conexión mientras se restauran los archivos o grupos de archivos dañados. Al final de la secuencia de restauración, la base de datos pasará a estar en línea. Todas las ediciones de SQL Server admiten restauraciones de archivos sin conexión.
- Restauración de archivos en línea:
En restauración de archivos en línea, si la base de datos está en línea durante una restauración de archivos, permanecerá en línea durante la restauración de archivos. Sin embargo, cada grupo de archivos en el que se restaura un archivo está sin conexión durante la operación de restauración. Una vez recuperados todos los archivos de un grupo de archivos sin conexión, este se conecta automáticamente.
Secuencia de restauración de Transact-SQL para la restauración de archivos (modelo de recuperación simple)
La secuencia de restauración solo contiene dos instrucciones de Transact-SQL. La primera instrucción restaura un archivo secundario, el archivo A, que se restaura usando WITH NORECOVERY. La segunda operación restaura otros dos archivos, B y C , que se restauran usando WITH RECOVERY desde un dispositivo de copia de seguridad diferente:
- RESTORE DATABASE base_de_datos FILE =nombre_de_archivo_A
FROM copia_de_seguridad_de_archivo_AWITH NORECOVERY**;**
- RESTORE DATABASE base_de_datos FILE =nombre_de_archivo_B,nombre_de_archivo_C
FROM copia_de_seguridad_de_archivos_B_y_CWITH RECOVERY**;**
Ejemplo
Restauraciones de archivos (modelo de recuperación completa)
La secuencia de restauración de ejemplo siguiente muestra una restauración sin conexión de dos archivos secundarios, A y B, mediante WITH NORECOVERY. A continuación, se aplican dos copias de seguridad de registros con NORECOVERY y, después, la copia del final del registro después del error, recuperada con WITH RECOVERY.
Ejemplos
La sintaxis de un flujo de restauración en línea es la misma que la de un flujo de restauración sin conexión.
1- Restauración en línea del archivo a1.
3- Restauración en línea de las copias de seguridad de registros. Restaura todas las copias de seguridad de registros tomadas desde la copia de seguridad de archivos restaurada, finalizando con la última copia de seguridad de registros (log_backup3, tomada en el paso anterior). Tras restaurar la última copia de seguridad, la base de datos se recupera.
En este momento, el archivo a1 se encuentra en el estado RESTORING, mientras que el grupo de archivos A está sin conexión.
2- Tras restaurar el archivo, realiza una nueva copia de seguridad de registros para asegurarte de capturar el momento en el que el archivo se quedó sin conexión.
Ahora el archivo a1 está en línea.
Restauraciones por etapas (SQL Server)
1- Restauración parcial del grupo de archivos principal y los grupos de archivos A y C.
2- Restauración con conexión del grupo de archivos B.
Todos los grupos de archivos están ahora en línea.
En este momento, los grupos de archivos principal, A y C están en línea. Todos los archivos del grupo de archivos B están pendientes de recuperación y el grupo de archivos está sin conexión.
Registro de transacciones
Requisitos para restaurar las copias de seguridad del registro de transacciones
Para aplicar una copia de seguridad del registro de transacciones, deben cumplirse los requisitos siguientes:
- Secuencia de copias de seguridad completa: Es necesario contar con todas las copias de seguridad de los registros de transacciones necesarias para completar la restauración de la base de datos.
- Orden correcto de restauración: Primero se debe restaurar la copia de seguridad diferencial o la copia completa más reciente antes de aplicar las copias de los registros de transacciones.
- Estado sin recuperar: La base de datos no debe estar en un estado "recuperado" hasta que se aplique el último registro de transacciones, asegurando la consistencia final.
Registro de transacciones
Sugerencia
Es aconsejable restaurar todas las copias de seguridad de registros (RESTORE LOG *database_name* WITH NORECOVERY). A continuación, después de restaurar la última copia de seguridad de registros, recupere la base de datos en una operación aparte (RESTORE DATABASE *database_name* WITH RECOVERY).
Registros de transacciones y recuperación
Suponga el siguiente flujo de eventos.
PROBLEMA
Para restaurar una base de datos al estado de un momento específico (por ejemplo, 9:45 p.m.), existen dos alternativas principales: Alternativa 1: Usar la copia de seguridad completa más reciente
- Crear una copia del final del registro de transacciones actual (momento del error).
- Restaurar la copia de seguridad completa de las 6:00 p.m. (no la de las 8:00 a.m.).
- Aplicar la copia de seguridad del registro de transacciones de las 8:00 p.m. y el final del registro.
Alternativa 2: Usar una copia de seguridad completa anterior
- Útil si no se puede usar la copia de seguridad de las 6:00 p.m. (aunque este método toma más tiempo).
- Crear una copia del final del registro de transacciones actual.
- Restaurar la copia de seguridad completa de las 8:00 a.m.
- Aplicar secuencialmente las copias de seguridad de los registros de transacciones hasta las 9:45 p.m.
Restaurar una base de datos de SQL Server a un momento dado (modelo de recuperación completa)
En este tema se describe cómo restaurar una base de datos a un momento determinado en SQL Server con SQL Server Management Studio o Transact-SQL. Usan los modelos de recuperación optimizados para cargas masivas de registros. Ejemplo (Transact-SQL)
En el ejemplo siguiente se restaura una base de datos al estado en que se encontraba a las 12:00 AM del April 15, 2020 y se muestra una operación de restauración que implica varias copias de seguridad de registros. En el dispositivo de copia de seguridad, AdventureWorksBackups, la copia de seguridad de base de datos completa que se va a restaurar es el tercer conjunto de copia de seguridad en el dispositivo (FILE = 3), la primera copia de seguridad de registros es el cuarto conjunto de copia de seguridad (FILE = 4) y la segunda copia de seguridad de registros es el quinto conjunto de copia de seguridad (FILE = 5).
Problema
Un ejemplo práctico de cómo restaurar una base de datos a un estado específico en el tiempo (12:00 a.m. del 15 de abril de 2020) usando copias de seguridad completas y de registros en SQL Server mediante Transact-SQL.
1. Contexto del Escenario: *La restauración incluye: -Una copia de seguridad completa de la base de datos.-Dos copias de seguridad de registros de transacciones. *Estas copias de seguridad están almacenadas en un dispositivo llamado AdventureWorksBackups.
Problema
2. Identificación de los Archivos de Copia de Seguridad: En un dispositivo de copia de seguridad, como un archivo o cinta, puede haber varios conjuntos de copias de seguridad (o backup sets). Cada conjunto se identifica con un número, como FILE = 3, FILE = 4, etc. FILE = 3: Es el tercer conjunto de copias de seguridad y corresponde a la copia de seguridad completa de la base de datos. FILE = 4: Es la primera copia de seguridad de registros de transacciones, que cubre las transacciones posteriores a la copia completa. FILE = 5: Es la segunda copia de seguridad de registros de transacciones, que contiene más transacciones posteriores.
Problema
3. Proceso de Restauración: *Primero: Restaurar la copia de seguridad completa (FILE = 3). Esto devuelve la base de datos al estado en que estaba en el momento de esa copia.*Segundo: Aplicar la primera copia de seguridad de registros (FILE = 4) para incluir las transacciones que ocurrieron después de la copia completa.*Tercero: Aplicar la segunda copia de seguridad de registros (FILE = 5) para avanzar aún más en el tiempo hasta llegar al punto deseado.
Problema
4. Punto de Restauración: El objetivo es restaurar la base de datos al estado exacto en que estaba a las 12:00 a.m. del 15 de abril de 2020, lo que implica que se usan las copias de seguridad completas y de registros para reconstruir ese momento. Beneficio de este Proceso: Este método permite recuperar una base de datos a un momento exacto, garantizando que todas las transacciones necesarias hasta ese momento estén presentes, gracias al uso de las copias de seguridad del registro de transacciones.
PROBLEMA
Recuperación de bases de datos relacionadas que contienen transacciones marcadas
Recuperación de bases de datos relacionadas que contienen transacciones marcadas
1.-Propósito: Permiten identificar un punto específico en el registro de transacciones mediante un nombre, lo que facilita la recuperación de datos hasta ese punto exacto. 2.-Características: Especificidad por transacción: Las marcas están vinculadas a transacciones específicas. Condición de confirmación: Solo se insertan en el registro de transacciones si la transacción asociada ha sido confirmada (es decir, finalizada con éxito). 3.-Uso: Las marcas pueden asociarse a un proceso o trabajo específico (por ejemplo, una tarea de procesamiento de datos). Durante la recuperación, es posible elegir si incluir o excluir los cambios realizados por el trabajo marcado.
Sintaxis de Transact-SQL para insertar marcas con nombre en un registro de transacciones
*Usa BEGIN TRANSACTION con la cláusula WITH MARK [description].*El nombre de la transacción será el nombre de la marca.*La descripción es opcional y sirve como texto descriptivo, no como nombre.
Información registrada: *Nombre de la marca (nombre de la transacción).*Descripción, base de datos, usuario, fecha/hora, y número de flujo de registro (LSN).La marca se identifica de forma única mediante su nombre y fecha/hora. Para transacciones en varias bases de datos, consulta cómo usar transacciones marcadas en el modelo de recuperación completa.
Sintaxis de Transact-SQL para recuperar hasta una marca
STOPATMARK: Recupera hasta una marca específica, incluyendo la transacción marcada. WITH STOPATMARK = "<mark_name>" STOPBEFOREMARK: Recupera hasta el registro inmediatamente anterior a la marca, excluyendo la transacción marcada. WITH STOPBEFOREMARK = "<mark_name>" STOPBEFOREMARK pone al día hasta la marca y excluye la transacción marcada de la puesta al día.
*Ambas opciones admiten AFTER datetime para trabajar con marcas no únicas.*Sin AFTER datetime: Se detiene en la primera marca con el nombre especificado.*Con AFTER datetime: Se detiene en la primera marca desde la fecha/hora especificada en adelante. Estas cláusulas determinan el punto de recuperación al usar RESTORE LOG.
Restauración con conexión (SQL Server)
Restauración con conexión en SQL Server Enterprise: *Solo soportado en SQL Server Enterprise.*La restauración de archivos, páginas o por etapas es en línea por defecto.*Aplicable a bases de datos con múltiples archivos o grupos de archivos.*En el modelo de recuperación simple, solo para grupos de archivos de solo lectura. Restauración en línea: *Ocurre mientras la base de datos está activa.*Una base de datos está en línea si el grupo de archivos principal lo está, aunque algunos secundarios estén sin conexión.*Modelo de recuperación completa: permite restaurar páginas y archivos en línea.*Todos los modelos de recuperación: permiten restaurar archivos sin conexión mientras la base de datos está en línea.
Transacciones diferidas (SQL Server)
En SQL Server Enterprise, una transacción dañada puede ser aplazada si los datos necesarios para la reversión se encuentran sin conexión durante el startup de la base de datos. Una transacción diferida es aquella que está sin confirmar cuando termina la fase de puesta al día y que se encuentra con un error que impide que se revierta. Si la transacción no se puede revertir, se convierte en una transacción diferida.
Soluciones para Transacciones Diferidas en SQL Server
Para resolver transacciones diferidas, sigue estos pasos según la causa del problema:
1.- Reiniciar la base de datos: Si el problema fue transitorio, esto puede resolverlo. 2.-Poner en línea un grupo de archivos sin conexión:*Usa el comando:RESTORE DATABASE database_name FILEGROUP=<filegroup_name> 3.-Restaurar la base de datos:*Una restauración completa o de páginas específicas puede resolver transacciones diferidas. 4.-Inactivar un grupo de archivos innecesario:*Si no necesitas el grupo de archivos, inactívalo.Nota: Los grupos de archivos inactivos no pueden recuperarse. 5.- Reparar una base de datos dañada (último recurso): *Cambia al modo de emergencia:ALTER DATABASE <database_name> SET EMERGENCY*Usa DBCC REPAIR_ALLOW_DATA_LOSS para reparar y desasignar páginas dañadas.Advertencia: Este método puede causar pérdida de datos.
Gracias Por Ver
3.2 definicion del esquema de recuperacion
Juan Carlos Galván Hernández
Created on November 19, 2024
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Interactive Onboarding Guide
View
Corporate Christmas Presentation
View
Business Results Presentation
View
Meeting Plan Presentation
View
Customer Service Manual
View
Business vision deck
View
Economic Presentation
Explore all templates
Transcript
3.2 definicion del esquema de recuperacion.
Introducción
el esquema de recuperación se refiere a un conjunto de procedimientos y estrategias diseñadas para restaurar informacion a su estado anterior en caso de fallos, errores o desastres.
iNDICE
1. Modelos de recuperación. 2. Dispositivos de copia de seguridad. 3. Familias y conjuntos de medios. 4. Conjuntos de medios de copia de seguridad reflejados. 5. Restauración y recuperación. 6. Información de encabezado e historial. 7. Posibles errores de medios. 8. Modelo de recuperación simple. 9. Modelo de recuperación completa.
10. Archivos y grupos de archivos. 11. Restauraciones de archivos simples. 12. Restauraciones de archivos completas. 13. Por etapas. 14. Registro de transacciones. 15. Transacciones marcadas. 16. Restauración en línea. 17. Transacciones diferidas.
Backups - modelo de recuperación
Un backup o copia de seguridad es una duplicación de la información importante de un sistema o dispositivo para protegerla de pérdidas o daños. Las operaciones de copia de seguridad y restauración de SQL Server se producen en el contexto del modelo de recuperación de la base de datos.
Dispositivos de copia de seguridad
Especificar un archivo de copia de seguridad mediante su nombre físico (Transact-SQL)
La sintaxis de BACKUP para especificar un archivo de copia de seguridad mediante su nombre de dispositivo físico es:
BACKUP DATABASE database_name TO DISK = { 'nombre_del_dispositivo_de_copia_de_seguridad_física' | @nombre_del_dispositivo_de_respaldo_físico.bak}
Familias y conjuntos de medios.
Familias de Medios:Una familia de medios es una colección de medios de copia de seguridad que se almacenan en un único dispositivo de copia de seguridad.
Conjuntos de Medios: Un conjunto de medios es una colección ordenada de familias de medios que se utilizan para almacenar una o más operaciones de copia de seguridad.
ejemplo:
Conjuntos de medios de copia de seguridad reflejados (SQL Server)
Un conjunto de medios reflejado consta de varias copias (reflejos) de los conjuntos de medios. Cada reflejo incluye todas las familias de medios del conjunto de medios. Esto significa que si tienes un conjunto de medios con varias familias de medios, cada reflejo contendrá todas esas familias.
Este ejemplo de un conjunto de medios reflejado que incluye dos familias de medios con dos reflejos. Cada familia de medios incluye tres volúmenes de medios, de los cuales se realiza una copia de seguridad por reflejo cada vez.
restauración y recuperación (SQL Server)
Para recuperarse de un error, una base de datos de SQL Server, un administrador de bases de datos tiene que restaurar un conjunto de copias de seguridad de SQL Server en una secuencia de restauración correcta y significativa de forma lógica.
6. Información de encabezado e Historial
La base de datos msdb en SQL Server almacena un historial detallado de todas las operaciones de copia de seguridad y restauración realizadas en una instancia de servidor. Este tema abarca: Recomendación importante: Para minimizar el riesgo de pérdida de datos recientes en el historial, es fundamental realizar copias de seguridad frecuentes de la base de datos msdb.
6. Información de encabezado e Historial
Tablas del historial de copias de seguridad y restauración
En esta sección se presentan las tablas del historial que almacenan metadatos de copias de seguridad y restauración en la base de datos del sistema msdb .
6. Información de encabezado e Historial
Instrucciones Transact-SQL para tener acceso al historial de copias de seguridad
Las instrucciones de información de la restauración corresponden a información almacenada en ciertas tablas del historial de copias de seguridad.
6. Información de encabezado e Historial
Archivos de base de datos y de registro de transacciones
La información de los archivos de base de datos y registros en una copia de seguridad incluye el nombre lógico, físico, tipo de archivo, grupo al que pertenece, tamaño, tamaño máximo permitido y tamaño de crecimiento predefinido.
Información de encabezado de medios
La información de encabezado de medios incluye datos sobre el medio, como su nombre, descripción, software creador y fecha de escritura.
Información de encabezado de copia de seguridad
El encabezado de copia de seguridad muestra información sobre todos los conjuntos de copia de seguridad, incluyendo tipos de dispositivos, tipos de copia (base de datos, transacción, archivo o diferencial) y fechas de inicio y fin. Es útil para identificar qué conjunto restaurar o qué copias contiene el medio.
6. Información de encabezado e Historial
Qué conjunto de copia de seguridad se debe restaurar
La información del encabezado de copia de seguridad permite identificar el conjunto a restaurar mediante su posición en el medio, ya que el Motor de base de datos numera cada conjunto.
Comparación de la información del encabezado de medios y del encabezado de copia de seguridad
La diferencia entre los encabezados radica en que el encabezado de medios se obtiene al leer solo el inicio de la cinta, mientras que el de copia de seguridad requiere examinar toda la cinta para cada conjunto.
7. Posibles eRRORES DE mEDIOS
- SQL Server ofrece la opción de recuperación de una base de datos a pesar de los errores detectados. - Un importante mecanismo de detección de errores nuevo es la creación opcional de una suma de comprobación de copia de seguridad que se puede crear mediante una operación de copia de seguridad y validar mediante una operación de restauración. - Puede controlar si una operación comprueba si hay errores y si la operación se detiene o continúa al encontrar un error. - Si una copia de seguridad contiene una suma de comprobación de copia de seguridad, las instrucciones RESTORE y RESTORE VERIFYONLY pueden comprobar si hay errores. Las copias de seguridad reflejadas proporcionan hasta cuatro copias (reflejos) de un conjunto de medios, ofreciendo copias alternativas para recuperar el sistema de los errores provocados por los medios dañados.
7. Posibles eRRORES DE mEDIOS
Comprobaciones de copia de seguridad
- SQL Server admite tres tipos de sumas de comprobación: una suma de comprobación de páginas, una de bloques de registro y una de copia de seguridad. - Al generar una suma de comprobación de copia de seguridad, BACKUP comprueba que los datos que se leen de la base de datos son coherentes con cualquier suma de comprobación o indicación de página rasgada de la base de datos. - Debido a la carga que supone comprobar y generar sumas de comprobación de seguridad, su utilización puede tener consecuencias negativas sobre el rendimiento. - Pueden quedar afectados tanto la carga de trabajo como el rendimiento de la copia de seguridad.- Cuando vaya a generar sumas de comprobación durante una copia de seguridad, supervise cuidadosamente la sobrecarga de CPU en la que se incurrirá, así como el impacto sobre las posibles cargas de trabajo simultáneas del sistema.
7. Posibles eRRORES DE mEDIOS
Back-Up
- BACKUP no modifica nunca la página de origen del disco ni el contenido de una página. - Cuando se habilitan las sumas de comprobación de copia de seguridad, una operación de copia de seguridad realiza los siguientes pasos:
- Durante una operación de restauración, si hay sumas de comprobación de copia de seguridad en los medios de copia de seguridad, de forma predeterminada, las operaciones RESTORE y RESTORE VERIFYONLY comprueban las sumas de comprobación de copia de seguridad y las sumas de comprobación de página.
7. Posibles eRRORES DE mEDIOS
Respuesta a errores de suma de comprobación de página durante una operación de copia de seguridad o restauración
- De forma predeterminada, después de encontrar un error de suma de comprobación de página, una operación BACKUP o RESTORE produce un error y una operación VERIFYONLY continúa. - Sin embargo, se puede controlar si una operación dada se detiene al encontrar un error o continúa de la mejor manera posible. - Si una operación BACKUP continúa después de encontrar errores, la operación realiza los siguientes pasos:
8. Modelo de Recuperación Simple
El objetivo es restaurar toda la base de datos. Durante el proceso de restauración, la base de datos completa se encuentra sin conexión. Antes de que ninguna parte de la base de datos esté en línea, se recuperan todos los datos a un punto.Se recomienda no adjuntar ni restaurar bases de datos de orígenes desconocidos o que no sean de confianza. Es posible que estas bases de datos contengan código malintencionado que podría ejecutar código de Transact-SQL no deseado o provocar errores al modificar el esquema o la estructura de la base de datos física.Para usar una base de datos desde un origen desconocido o que no sea de confianza, ejecute DBCC CHECKDB en la base de datos de un servidor que no sea de producción y examine también el código.
8. Modelo de Recuperación Simple
Información general de la restauración
- Una restauración completa de base de datos con el modelo de recuperación simple implica una o dos instrucciones RESTORE, en función de si desea restaurar una copia de seguridad diferencial de la base de datos. - Si solo usa copias de seguridad completas de la base de datos, restaure solo la copia de seguridad más reciente, como se muestra.- Si también usa una copia de seguridad diferencial de la base de datos, restaure la copia de seguridad completa más reciente de la base de datos sin recuperar la base de datos y, a continuación, restaure la copia de seguridad diferencial más reciente de la base de datos y recupere la base de datos.
8. Modelo de Recuperación Simple
Sintaxis RESTORE de Transact-SQL básica
- La sintaxis RESTORE de Transact-SQL básica para restaurar una copia de seguridad de base de datos completa es:RESTORE DATABASE database_name FROM backup_device [ WITH NORECOVERY ]- La sintaxis RESTORE básica para restaurar una copia de seguridad de la base de datos es: RESTORE DATABASE database_name FROM backup_device WITH RECOVERY
NotaUse WITH NORECOVERY si también desea restaurar una copia de seguridad diferencial de la base de datos.
8. Modelo de Recuperación Simple
Ejemplo (Transact-SQL)
- En el siguiente ejemplo se muestra primero cómo usar la instrucción BACKUP para crear una copia de seguridad completa y diferencial de la base de datos AdventureWorks2022. - A continuación, se restauran estas copias de seguridad una después de la otra. La base de datos se restaura a su estado en el momento en que finalizó la copia de seguridad diferencial. - En el ejemplo se muestran las opciones críticas de una secuencia de restauración en un escenario de restauración de base de datos completa. - Una secuencia de restauración consta de dos o más operaciones de restauración que mueven datos en una o varias fases de restauración. - La sintaxis y los detalles no pertinentes para este propósito se omiten. - Al recuperar una base de datos, se recomienda especificar explícitamente la opción RECOVERY por motivos de claridad, aunque es la opción predeterminada.
USE master; --Make sure the database is using the simple recovery model. ALTER DATABASE AdventureWorks2022 SET RECOVERY SIMPLE; GO -- Back up the full AdventureWorks2022 database. BACKUP DATABASE AdventureWorks2022 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH FORMAT; GO --Create a differential database backup. BACKUP DATABASE AdventureWorks2022 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH DIFFERENTIAL; GO --Restore the full database backup (from backup set 1). RESTORE DATABASE AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH FILE=1, NORECOVERY; --Restore the differential backup (from backup set 2). RESTORE DATABASE AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH FILE=2, RECOVERY; GO
9. Modelo de Recuperación Completa (Restauraciones de archivos)
- La restauración de archivos permite recuperar archivos dañados sin restaurar toda la base de datos. - Si el grupo de archivos es de lectura/escritura, es necesario aplicar copias de seguridad de registros para actualizarlo hasta el punto de recuperación, normalmente cerca del final del registro. - Para grupos solo lectura, generalmente no se necesitan registros, y se restaura la última copia de seguridad realizada tras marcarlo como solo lectura.
9. Modelo de Recuperación Completa
Restauraciones de archivos
Los escenarios de restauración de archivos son los siguientes:
9. Modelo de Recuperación Completa
Restauracion A PARTIR DE COPIAS DE SEGURIDAD
- Debe hacer que la base de datos sea coherente; para ello, restaure las copias de seguridad del registro de transacciones creadas después de las copias de seguridad de archivos. - Las copias de seguridad del registro de transacciones se pueden poner al día rápidamente, porque solo se aplican los cambios correspondientes a los archivos restaurados. - La restauración de archivos individuales puede ser mejor que la restauración de toda la base de datos, dado que los archivos dañados no se copian y, posteriormente, ponen al día. - Sin embargo, aún debe leerse toda la cadena de copias de seguridad de registros.
9. Modelo de Recuperación Completa
sECUENCIA DE RESTAURACIÓN SIN CONEXIÓN
--Take the file offline. ALTER DATABASE database_name MODIFY FILE SET OFFLINE; -- Back up the currently active transaction log. BACKUP LOG database_name TO <tail_log_backup> WITH NORECOVERY; GO -- Restore the files. RESTORE DATABASE database_name FILE=name FROM <file_backup_of_file_A> WITH NORECOVERY; RESTORE DATABASE database_name FILE=<name> ...... FROM <file_backup_of_file_B> WITH NORECOVERY; -- Restore the log backups. RESTORE LOG database_name FROM <log_backup> WITH NORECOVERY; RESTORE LOG database_name FROM <log_backup> WITH NORECOVERY; RESTORE LOG database_name FROM <tail_log_backup> WITH RECOVERY;
- Un escenario de restauración de archivos consiste en una única secuencia de restauración que copia, pone al día y recupera los datos apropiados. - En esta sección se muestran las opciones esenciales de RESTORE para una secuencia de restauración de archivos. - La sintaxis y los detalles no pertinentes para este propósito se omiten. - La secuencia de restauración de ejemplo siguiente muestra una restauración sin conexión de dos archivos secundarios, A y B, mediante WITH NORECOVERY. - A continuación, se aplican dos copias de seguridad de registros con NORECOVERY y, después, la copia del final del registro después del error, recuperada con WITH RECOVERY.
Realizar copias de seguridad de archivos y grupos de archivos
Para crear una copia de seguridad de archivos o de un grupo de archivos, use una instrucción BACKUP DATABASE< >file_or_filegroup. Como mínimo, esta instrucción debe especificar:
La sintaxis Transact-SQL básica para una copia de seguridad de archivos es: BACKUP DATABASE database { FILE =logical_file_name | FILEGROUP =logical_filegroup_name } [ ,...f ] TO backup_device [ ,...n ] [ WITH with_options [ ,...o ] ] ;
database
FILEGROUP =logical_filegroup_name
Es la base de datos para la que se realiza la copia de seguridad del registro de transacciones, de una parte de la base de datos o de la base de datos completa.
Especifica el nombre lógico de un grupo de archivos que se debe incluir en la copia de seguridad de archivos. En el modelo de recuperación simple, se permite la copia de seguridad de un grupo de archivos solo si se trata de un grupo de archivos de solo lectura.
FILE =logical_file_name
Especifica el nombre lógico de un archivo que se debe incluir en la copia de seguridad de archivos.
backup_device [ ,...n ]
Especifica una lista de 1 a 64 dispositivos de copia de seguridad que se pueden utilizar en la operación de copia de seguridad. Puede especificar un dispositivo físico de copia de seguridad o puede especificar un dispositivo de copia de seguridad lógico correspondiente, si ya se definió.
[ ,...f ]
Se trata de un marcador de posición que indica que se pueden especificar varios archivos y grupos de archivos. El número de archivos o grupos de archivos es ilimitado.
WITH with_options [ ,...o ]
Opcionalmente, especifica una o más opciones, como DIFFERENTIAL. Una copia de seguridad diferencial de archivos necesita una copia de seguridad completa de archivos como base.
Ejemplos
Los siguientes ejemplos realizan copias de seguridad de uno o más archivos de los grupos de archivos secundarios de la base de datos Sales. Esta base de datos utiliza el modelo de recuperación completa y contiene los siguientes grupos de archivos secundarios:
A. Crear una copia de seguridad de archivos de dos archivos
En el siguiente ejemplo se crea una copia de seguridad diferencial de archivos solo del archivo SGrp1Fi2 de SalesGroup1 y del archivo SGrp2Fi2 del grupo de archivos SalesGroup2 .
B. Crear una copia de seguridad de archivos completa de los grupos de archivos secundarios
En el ejemplo siguiente se crea una copia de seguridad de archivos completa de cada archivo en los dos grupos de archivos secundarios.
C. Crear una copia de seguridad de archivos diferencial de los grupos de archivos secundarios
En el ejemplo siguiente se crea una copia de seguridad de archivos diferencial de cada archivo en los dos grupos de archivos secundarios.
Limitaciones y restricciones
Recomendaciones
De forma predeterminada, cada operación de copia de seguridad correcta agrega una entrada en el registro de errores de SQL Server y en el registro de eventos del sistema. Si se hace una copia de seguridad del registro de transacciones con frecuencia, estos mensajes que indican la corrección de la operación pueden acumularse rápidamente, con lo que se crean registros de errores muy grandes que pueden dificultar la búsqueda de otros mensajes. En esos casos, puede suprimir estas entradas de registro con la marca de seguimiento 3226 si ninguno de los scripts depende de esas entradas.
Permisos
De forma predeterminada, los permisos BACKUP DATABASE y BACKUP LOG se corresponden a los miembros del rol fijo de servidor sysadmin y de los roles fijos de base de datos db_owner y db_backupoperator. Los problemas de propiedad y permisos del archivo físico del dispositivo de copia de seguridad pueden interferir con una operación de copia de seguridad. SQL Server debe poder leer y escribir en el dispositivo y la cuenta en la que se ejecuta el servicio SQL Server debe tener permisos de escritura.
Con el modelo de recuperación completa, también debe realizar copias de seguridad del registro de transacciones. Para utilizar un conjunto completo de copias de seguridad de completas archivos para restaurar una base de datos, también debe tener suficientes copias de seguridad de registros que abarquen todas las copias de seguridad de archivos, desde el principio de la primera copia de seguridad de archivos.
Restauraciones de archivos (modelo de recuperación simple)
Este tema solo es relevante para las bases de datos de modelo simple que incluyen como mínimo un grupo de archivos secundario de solo lectura. El objetivo de una restauración de archivos consiste en restaurar uno o varios archivos dañados sin necesidad de restaurar la totalidad de la base de datos. En el modelo de recuperación simple, las copias de seguridad de archivos se admiten únicamente para los archivos de solo lectura.
Los escenarios de restauración de archivos son los siguientes:
- Restauración de archivos sin conexión:
En una restauración de archivos sin conexión, la base de datos permanece sin conexión mientras se restauran los archivos o grupos de archivos dañados. Al final de la secuencia de restauración, la base de datos pasará a estar en línea. Todas las ediciones de SQL Server admiten restauraciones de archivos sin conexión.- Restauración de archivos en línea:
En restauración de archivos en línea, si la base de datos está en línea durante una restauración de archivos, permanecerá en línea durante la restauración de archivos. Sin embargo, cada grupo de archivos en el que se restaura un archivo está sin conexión durante la operación de restauración. Una vez recuperados todos los archivos de un grupo de archivos sin conexión, este se conecta automáticamente.Secuencia de restauración de Transact-SQL para la restauración de archivos (modelo de recuperación simple)
La secuencia de restauración solo contiene dos instrucciones de Transact-SQL. La primera instrucción restaura un archivo secundario, el archivo A, que se restaura usando WITH NORECOVERY. La segunda operación restaura otros dos archivos, B y C , que se restauran usando WITH RECOVERY desde un dispositivo de copia de seguridad diferente:
- RESTORE DATABASE base_de_datos FILE =nombre_de_archivo_A
FROM copia_de_seguridad_de_archivo_AWITH NORECOVERY**;**- RESTORE DATABASE base_de_datos FILE =nombre_de_archivo_B,nombre_de_archivo_C
FROM copia_de_seguridad_de_archivos_B_y_CWITH RECOVERY**;**Ejemplo
Restauraciones de archivos (modelo de recuperación completa)
La secuencia de restauración de ejemplo siguiente muestra una restauración sin conexión de dos archivos secundarios, A y B, mediante WITH NORECOVERY. A continuación, se aplican dos copias de seguridad de registros con NORECOVERY y, después, la copia del final del registro después del error, recuperada con WITH RECOVERY.
Ejemplos
La sintaxis de un flujo de restauración en línea es la misma que la de un flujo de restauración sin conexión.
1- Restauración en línea del archivo a1.
3- Restauración en línea de las copias de seguridad de registros. Restaura todas las copias de seguridad de registros tomadas desde la copia de seguridad de archivos restaurada, finalizando con la última copia de seguridad de registros (log_backup3, tomada en el paso anterior). Tras restaurar la última copia de seguridad, la base de datos se recupera.
En este momento, el archivo a1 se encuentra en el estado RESTORING, mientras que el grupo de archivos A está sin conexión.
2- Tras restaurar el archivo, realiza una nueva copia de seguridad de registros para asegurarte de capturar el momento en el que el archivo se quedó sin conexión.
Ahora el archivo a1 está en línea.
Restauraciones por etapas (SQL Server)
1- Restauración parcial del grupo de archivos principal y los grupos de archivos A y C.
2- Restauración con conexión del grupo de archivos B.
Todos los grupos de archivos están ahora en línea.
En este momento, los grupos de archivos principal, A y C están en línea. Todos los archivos del grupo de archivos B están pendientes de recuperación y el grupo de archivos está sin conexión.
Registro de transacciones
Requisitos para restaurar las copias de seguridad del registro de transacciones
Para aplicar una copia de seguridad del registro de transacciones, deben cumplirse los requisitos siguientes:
Registro de transacciones
Sugerencia Es aconsejable restaurar todas las copias de seguridad de registros (RESTORE LOG *database_name* WITH NORECOVERY). A continuación, después de restaurar la última copia de seguridad de registros, recupere la base de datos en una operación aparte (RESTORE DATABASE *database_name* WITH RECOVERY).
Registros de transacciones y recuperación
Suponga el siguiente flujo de eventos.
PROBLEMA
Para restaurar una base de datos al estado de un momento específico (por ejemplo, 9:45 p.m.), existen dos alternativas principales: Alternativa 1: Usar la copia de seguridad completa más reciente
- Crear una copia del final del registro de transacciones actual (momento del error).
- Restaurar la copia de seguridad completa de las 6:00 p.m. (no la de las 8:00 a.m.).
- Aplicar la copia de seguridad del registro de transacciones de las 8:00 p.m. y el final del registro.
Alternativa 2: Usar una copia de seguridad completa anteriorRestaurar una base de datos de SQL Server a un momento dado (modelo de recuperación completa)
En este tema se describe cómo restaurar una base de datos a un momento determinado en SQL Server con SQL Server Management Studio o Transact-SQL. Usan los modelos de recuperación optimizados para cargas masivas de registros. Ejemplo (Transact-SQL) En el ejemplo siguiente se restaura una base de datos al estado en que se encontraba a las 12:00 AM del April 15, 2020 y se muestra una operación de restauración que implica varias copias de seguridad de registros. En el dispositivo de copia de seguridad, AdventureWorksBackups, la copia de seguridad de base de datos completa que se va a restaurar es el tercer conjunto de copia de seguridad en el dispositivo (FILE = 3), la primera copia de seguridad de registros es el cuarto conjunto de copia de seguridad (FILE = 4) y la segunda copia de seguridad de registros es el quinto conjunto de copia de seguridad (FILE = 5).
Problema
Un ejemplo práctico de cómo restaurar una base de datos a un estado específico en el tiempo (12:00 a.m. del 15 de abril de 2020) usando copias de seguridad completas y de registros en SQL Server mediante Transact-SQL.
1. Contexto del Escenario: *La restauración incluye: -Una copia de seguridad completa de la base de datos.-Dos copias de seguridad de registros de transacciones. *Estas copias de seguridad están almacenadas en un dispositivo llamado AdventureWorksBackups.
Problema
2. Identificación de los Archivos de Copia de Seguridad: En un dispositivo de copia de seguridad, como un archivo o cinta, puede haber varios conjuntos de copias de seguridad (o backup sets). Cada conjunto se identifica con un número, como FILE = 3, FILE = 4, etc. FILE = 3: Es el tercer conjunto de copias de seguridad y corresponde a la copia de seguridad completa de la base de datos. FILE = 4: Es la primera copia de seguridad de registros de transacciones, que cubre las transacciones posteriores a la copia completa. FILE = 5: Es la segunda copia de seguridad de registros de transacciones, que contiene más transacciones posteriores.
Problema
3. Proceso de Restauración: *Primero: Restaurar la copia de seguridad completa (FILE = 3). Esto devuelve la base de datos al estado en que estaba en el momento de esa copia.*Segundo: Aplicar la primera copia de seguridad de registros (FILE = 4) para incluir las transacciones que ocurrieron después de la copia completa.*Tercero: Aplicar la segunda copia de seguridad de registros (FILE = 5) para avanzar aún más en el tiempo hasta llegar al punto deseado.
Problema
4. Punto de Restauración: El objetivo es restaurar la base de datos al estado exacto en que estaba a las 12:00 a.m. del 15 de abril de 2020, lo que implica que se usan las copias de seguridad completas y de registros para reconstruir ese momento. Beneficio de este Proceso: Este método permite recuperar una base de datos a un momento exacto, garantizando que todas las transacciones necesarias hasta ese momento estén presentes, gracias al uso de las copias de seguridad del registro de transacciones.
PROBLEMA
Recuperación de bases de datos relacionadas que contienen transacciones marcadas
Recuperación de bases de datos relacionadas que contienen transacciones marcadas
1.-Propósito: Permiten identificar un punto específico en el registro de transacciones mediante un nombre, lo que facilita la recuperación de datos hasta ese punto exacto. 2.-Características: Especificidad por transacción: Las marcas están vinculadas a transacciones específicas. Condición de confirmación: Solo se insertan en el registro de transacciones si la transacción asociada ha sido confirmada (es decir, finalizada con éxito). 3.-Uso: Las marcas pueden asociarse a un proceso o trabajo específico (por ejemplo, una tarea de procesamiento de datos). Durante la recuperación, es posible elegir si incluir o excluir los cambios realizados por el trabajo marcado.
Sintaxis de Transact-SQL para insertar marcas con nombre en un registro de transacciones
*Usa BEGIN TRANSACTION con la cláusula WITH MARK [description].*El nombre de la transacción será el nombre de la marca.*La descripción es opcional y sirve como texto descriptivo, no como nombre.
Información registrada: *Nombre de la marca (nombre de la transacción).*Descripción, base de datos, usuario, fecha/hora, y número de flujo de registro (LSN).La marca se identifica de forma única mediante su nombre y fecha/hora. Para transacciones en varias bases de datos, consulta cómo usar transacciones marcadas en el modelo de recuperación completa.
Sintaxis de Transact-SQL para recuperar hasta una marca
STOPATMARK: Recupera hasta una marca específica, incluyendo la transacción marcada. WITH STOPATMARK = "<mark_name>" STOPBEFOREMARK: Recupera hasta el registro inmediatamente anterior a la marca, excluyendo la transacción marcada. WITH STOPBEFOREMARK = "<mark_name>" STOPBEFOREMARK pone al día hasta la marca y excluye la transacción marcada de la puesta al día. *Ambas opciones admiten AFTER datetime para trabajar con marcas no únicas.*Sin AFTER datetime: Se detiene en la primera marca con el nombre especificado.*Con AFTER datetime: Se detiene en la primera marca desde la fecha/hora especificada en adelante. Estas cláusulas determinan el punto de recuperación al usar RESTORE LOG.
Restauración con conexión (SQL Server)
Restauración con conexión en SQL Server Enterprise: *Solo soportado en SQL Server Enterprise.*La restauración de archivos, páginas o por etapas es en línea por defecto.*Aplicable a bases de datos con múltiples archivos o grupos de archivos.*En el modelo de recuperación simple, solo para grupos de archivos de solo lectura. Restauración en línea: *Ocurre mientras la base de datos está activa.*Una base de datos está en línea si el grupo de archivos principal lo está, aunque algunos secundarios estén sin conexión.*Modelo de recuperación completa: permite restaurar páginas y archivos en línea.*Todos los modelos de recuperación: permiten restaurar archivos sin conexión mientras la base de datos está en línea.
Transacciones diferidas (SQL Server)
En SQL Server Enterprise, una transacción dañada puede ser aplazada si los datos necesarios para la reversión se encuentran sin conexión durante el startup de la base de datos. Una transacción diferida es aquella que está sin confirmar cuando termina la fase de puesta al día y que se encuentra con un error que impide que se revierta. Si la transacción no se puede revertir, se convierte en una transacción diferida.
Soluciones para Transacciones Diferidas en SQL Server
Para resolver transacciones diferidas, sigue estos pasos según la causa del problema:
1.- Reiniciar la base de datos: Si el problema fue transitorio, esto puede resolverlo. 2.-Poner en línea un grupo de archivos sin conexión:*Usa el comando:RESTORE DATABASE database_name FILEGROUP=<filegroup_name> 3.-Restaurar la base de datos:*Una restauración completa o de páginas específicas puede resolver transacciones diferidas. 4.-Inactivar un grupo de archivos innecesario:*Si no necesitas el grupo de archivos, inactívalo.Nota: Los grupos de archivos inactivos no pueden recuperarse. 5.- Reparar una base de datos dañada (último recurso): *Cambia al modo de emergencia:ALTER DATABASE <database_name> SET EMERGENCY*Usa DBCC REPAIR_ALLOW_DATA_LOSS para reparar y desasignar páginas dañadas.Advertencia: Este método puede causar pérdida de datos.
Gracias Por Ver