1.

SQL SERVER BUCKUP

Los archivos de datos, grupos de archivos y archivos de registro que conforman una base de
datos de SQL Server pueden, y generalmente deberían, ser respaldados como parte de su
copia de seguridad de la base de datos y estrategia de recuperación. Esto incluye tanto el
usuario como las bases de datos del sistema. Existen tres amplias categorías de respaldo
que un DBA puede realizar: copias de seguridad de bases de datos, copias de seguridad de
archivos y copias de seguridad de registros de transacciones, y dentro de estas categorías
hay disponibles varios tipos diferentes de copias de seguridad.

• Copias de seguridad de la base de datos (Database backups): copie en un archivo de copia

de seguridad los datos y objetos en el archivo de datos principal y cualquier archivo de datos
secundario.

• Copia de seguridad completa de la base de datos (Full database backup): realiza

una copia de seguridad de todos los datos y objetos en los archivos de datos de una
base de datos determinada.

• Copia de seguridad diferencial de la base de datos (Differential database backup):

realiza copias de seguridad de todos los datos y objetos en los archivos de datos de
una base de datos determinada que haya cambiado desde la última copia de
seguridad completa.

• Copias de seguridad del registro de transacciones (Transaction log backups): copie en un

archivo de copia de seguridad todos los registros de registro insertados en el archivo LDF
del registro de transacciones desde la última copia de seguridad del registro de
transacciones.

• Copias de seguridad de archivos (File backups): copie en un archivo de copia de seguridad

los datos y objetos en un archivo de datos o grupo de archivos.

• Copia de seguridad de archivos completa (Full file backup): realiza una copia de
seguridad de todos los datos y objetos en los archivos de datos o grupos de archivos
especificados.

• Copia de seguridad de archivos diferencial (Differential file backup): realiza una

copia de seguridad de los datos y objetos en los archivos de datos o grupos de
archivos especificados que han cambiado desde la última copia de seguridad
completa del archivo.

• Copia de seguridad parcial (Partial backup): realiza una copia de seguridad de la

porción completa de la base de datos que se puede escribir, excluyendo cualquier
archivo / grupo de archivos de solo lectura (a menos que se incluya
específicamente).
 • Copia de seguridad parcial diferencial (Differential partial backup): realiza una
copia de seguridad de los datos y objetos que han cambiado desde la última copia
de seguridad parcial.

Tenga en cuenta que los tipos exactos de copia de seguridad que pueden realizarse y, en
cierta medida, las opciones de restauración disponibles dependen del modelo de
recuperación en el que la base de datos está funcionando (SIMPLE, FULL o BULK_LOGGED).
Discutiremos este tema con más detalle en breve, en la sección Modelos de recuperación,
pero por el momento tal vez el punto más notable para recordar es que no es posible
realizar copias de seguridad de registros de transacciones para una base de datos que opera
en el modelo de recuperación SIMPLE. por lo que las copias de seguridad de los registros no
forman parte de una operación RESTORE de la base de datos para estas bases de datos.
Ahora vamos a ver cada uno de estos tipos de copia de seguridad con un poco más de
detalle.

1.1 SQL Server database backups

La copia de seguridad de la base de datos, que es una copia de seguridad de su archivo de

datos principal más cualquier archivo de base de datos secundario, es la piedra angular del
plan de respaldo y recuperación de cualquier empresa.

Cualquier base de datos que no utilice copias de seguridad de archivos requerirá una
estrategia para realizar copias de seguridad de bases de datos. Considere, por ejemplo, la
situación en la que una base de datos de SQL Server falla, tal vez debido a un error de
hardware, y el archivo de datos en vivo ya no es accesible. Si no existen copias de seguridad
(copias) de este archivo en otro lugar, sufrirá una pérdida de datos del 100%; el escenario
de "colapso" que todos los DBA deben evitar a toda costa.

FULL DATABASE BACKUPS

Una copia de seguridad completa de la base de datos contendrá todos los detalles de su
base de datos: tablas, procedimientos almacenados, funciones, vistas, información de
permisos, índices y, por supuesto, los datos almacenados en esas tablas. También contendrá
la información suficiente del registro de transacciones para garantizar que la base de datos
se pueda restaurar a un estado coherente (por ejemplo, debe hacer una copia de seguridad
suficiente del registro para poder revertir cualquier transacción que se haya iniciado antes
de la copia de seguridad y no se había comprometido por la finalización de la copia de
seguridad) y para volver a poner la base de datos en línea en caso de falla durante una
operación de restauración.[3]

COPIAS DE SEGURIDAD DE LA BASE DE DATOS EN EL MODELO DE RECUPERACIÓN SIMPLE

 Bajo el modelo de recuperación simple, después de cada copia de seguridad, la base de
datos está expuesta a posibles pérdidas de trabajo si ocurriera un desastre. La exposición a
la pérdida de trabajo aumenta con cada actualización hasta la siguiente copia de seguridad,
cuando la exposición a la pérdida de trabajo vuelve a cero y comienza un nuevo ciclo de
exposición a la pérdida de trabajo. La exposición a la pérdida de trabajo aumenta con el
tiempo entre copias de seguridad. La siguiente ilustración muestra la exposición de pérdida
de trabajo para una estrategia de copia de seguridad que utiliza solo copias de seguridad
completas de la base de datos.

Ejemplo:

-- Back up the AdventureWorks2012 database to new media set.

BACKUP DATABASE AdventureWorks2012
TO DISK = 'Z:\SQLServerBackups\AdventureWorksSimpleRM.bak'
WITH FORMAT;
GO

COPIAS DE SEGURIDAD DE LA BASE DE DATOS EN EL MODELO DE RECUPERACIÓN

COMPLETA

Para las bases de datos que utilizan la recuperación completa y masiva, las copias de
seguridad de la base de datos son necesarias, pero no suficientes. También se requieren
copias de seguridad del registro de transacciones. La siguiente ilustración muestra la
estrategia de copia de seguridad menos compleja que es posible en el modelo de
recuperación completa.
Ejemplo:

USE master;
ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;
GO
-- Back up the AdventureWorks2012 database to new media set (backup set 1).
BACKUP DATABASE AdventureWorks2012
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012FullRM.bak'
WITH FORMAT;
GO
--Create a routine log backup (backup set 2).
BACKUP LOG AdventureWorks2012 TO DISK =
'Z:\SQLServerBackups\AdventureWorks2012FullRM.bak';
GO

PARTIAL DATABASE BACKUPS

Las copias de seguridad parciales son útiles siempre que quiera excluir grupos de archivos
de solo lectura. Una copia de seguridad parcial se asemeja a una copia de seguridad
completa de la base de datos, pero una copia de seguridad parcial no contiene todos los
grupos de archivos. En cambio, para una base de datos de lectura / escritura, una copia de
seguridad parcial contiene los datos en el grupo de archivos principal, cada grupo de
archivos de lectura / escritura y, opcionalmente, uno o más archivos de solo lectura. Una
copia de seguridad parcial de una base de datos de solo lectura contiene solo el grupo de
archivos primario.

FULL FILE BACKUPS

Los archivos en una base de datos de SQL Server se pueden respaldar y restaurar
individualmente. Además, puede especificar un grupo de archivos completo en lugar de
especificar cada archivo constituyente individualmente. Tenga en cuenta que si algún
 archivo de un grupo de archivos está fuera de línea (por ejemplo, porque el archivo se está
restaurando), todo el grupo de archivos está fuera de línea y no se puede hacer una copia
de seguridad.

Las copias de seguridad de archivos de grupos de archivos de solo lectura se pueden

combinar con copias de seguridad parciales. Las copias de seguridad parciales incluyen
todos los grupos de archivos de lectura / escritura y, opcionalmente, uno o más grupos de
archivos de solo lectura. Para obtener más información, vea Copias de seguridad parciales
(SQL Server).

1.2 SQL SERVER TRANSACTION LOG BACKUPS

Como administrador de bases de datos, en muchos casos necesitará realizar copias de

seguridad periódicas del archivo de registro de transacciones para una base de datos
determinada, además de realizar copias de seguridad de la base de datos. Esto es
importante tanto para permitir la restauración puntual de su base de datos como para
controlar el tamaño del archivo de registro.

Esencialmente, como se discutió anteriormente, un archivo de registro de transacciones

almacena una serie de registros que proporcionan un registro histórico de las
modificaciones emitidas contra esa base de datos. Siempre que la base de datos esté
funcionando en el modelo de recuperación FULL o BULK LOGGED, estos registros
permanecerán en el archivo de registro en vivo y nunca se sobrescribirán hasta que se
realice una operación de copia de seguridad de registro.[2]

THE LOG CHAIN

Por ejemplo, considere nuestra situación anterior, en la que simplemente realizamos una
copia de seguridad completa de la base de datos una vez cada 24 horas, y estuvimos
expuestos a hasta 24 horas de pérdida de datos. Es posible realizar copias de seguridad
diferenciales entre las copias de seguridad completas, para reducir el riesgo de pérdida de
datos. Sin embargo, las copias de seguridad completas y diferenciales son procesos
intensivos de E / S y es probable que afecten el rendimiento de la base de datos, por lo que
no deberían ejecutarse durante los momentos en que los usuarios acceden a la base de
datos.

Si una base de datos contiene datos críticos para la empresa y prefiere que su exposición a
la pérdida de datos se mida en minutos en lugar de horas, puede usar un esquema mediante
el cual realiza una copia de seguridad completa de la base de datos, seguida de una serie de
copias de seguridad de registros de transacciones frecuentes. seguido de otra copia de
seguridad completa, y así sucesivamente. Como parte de una operación de restauración de
base de datos, podemos restaurar la copia de seguridad completa más reciente (más los
diferenciales, si se toman), seguido de la cadena de copias de seguridad de archivos de
registro disponibles, hasta una que cubra el momento en el que deseamos restaurar la base
de datos.

TAIL LOG BACKUPS

 En caso de que una falla afecte a una base de datos operando en modelo de recuperación
FULL o BULK_LOGGED, la primera acción después de la falla debe ser realizar lo que se
conoce como una copia de seguridad de registro de cola del registro de transacciones activo,
que captura los contenidos restantes de este archivo. De hecho, una operación RESTORE
posterior puede fallar, a menos que el comando incluya WITH REPLACE, lo que indica que la
base de datos existente debe sobrescribirse, o WITH STOPAT, indicando que hay un punto
específico en el que deseamos detener la operación de restauración.

Este tipo de copia de seguridad de registro de cola, así como las copias de seguridad de
registro normales, requieren que la base de datos esté en línea (creo, para que la
información con respecto a la copia de seguridad de registro pueda estamparse en el
encabezado de la base de datos). Si la base de datos está fuera de línea y falla un intento de
restaurarla, quizás porque un archivo de datos no está disponible, una copia de seguridad
de registro de cola con NORECOVERY, así como cualquier copia de seguridad de registro
normal, fallará. Sin embargo, aún puede ser posible realizar una copia de seguridad de
registro de cola, pero utilizando la opción NO_TRUNCATE en su lugar, BACKUP LOG ... WITH
NO_ TRUNCATE. Esta operación realiza una copia de seguridad del archivo de registro sin
truncarlo y no requiere que la base de datos esté en línea.

LOG SPACE REUSE

Para un VLDB que se ha "desglosado" en múltiples grupos de archivos, las copias de

seguridad de archivos pueden reducir el tiempo y el espacio en disco necesarios para la
estrategia de respaldo y, en ciertas circunstancias, hacer que la recuperación ante desastres
sea mucho más rápida. Por ejemplo, supongamos que la arquitectura de una base de datos
consta de tres grupos de archivos: un grupo de archivos primario que contiene solo datos
del sistema, un grupo de archivos secundario que contiene datos comerciales recientes y un
tercer grupo de archivos que contiene datos de archivo, que ha sido designado
específicamente como grupo de archivos READONLY.

La desventaja de las copias de seguridad de archivos es la gran complejidad y la carga

administrativa que pueden agregar a la estrategia de respaldo. En primer lugar, significa que
una "copia de seguridad completa" consistirá en capturar varios archivos de copia de
seguridad, en lugar de solo uno. En segundo lugar, además, tendremos que tomar copias de
seguridad del registro de transacciones para cubrir el tiempo entre copias de seguridad de
archivos de diferentes grupos de archivos. Discutiremos esto con más detalle en el Capítulo
9 pero, brevemente, la razón de esto es que, mientras los datos se almacenan en archivos
físicos separados, seguirán conectados relacionalmente; los cambios realizados en los datos
almacenados en un archivo afectarán los datos relacionados en otros archivos, y dado que
las copias de seguridad de archivos individuales se realizan en diferentes momentos, SQL
Server necesita cualquier archivo de copia de seguridad posterior para garantizar que pueda
restaurar una versión coherente de la base de datos .

2. RESTORE DATABASES
 Restore scenario Under simple recovery
model
Complete database Esta es la estrategia de
restore restauración básica. Una
restauración completa de la
base de datos puede
implicar simplemente
restaurar y recuperar una
copia de seguridad
completa de la base de
datos. Alternativamente,
una restauración completa
de la base de datos podría
implicar la restauración de
una copia de seguridad
completa de la base de
datos seguida de la
restauración y recuperación
de una copia de seguridad
diferencial.
File restore Restaure uno o más
archivos dañados de solo
lectura, sin restaurar toda la
base de datos. La
restauración de archivos
está disponible solo si la
base de datos tiene al
menos un grupo de archivos
de solo lectura.
Page restore No aplicable
Under full/bulk-logged
recovery models
Esta es la estrategia de
restauración básica. Una
restauración completa de la
base de datos implica la
restauración de una copia
de seguridad completa de
la base de datos y,
opcionalmente, una copia
de seguridad diferencial (si
corresponde), seguida de la
restauración de todas las
copias de seguridad
posteriores del registro (en
secuencia). La restauración
completa de la base de
datos finaliza recuperando
la última copia de seguridad
del registro y también
restaurándola (RESTAURAR
CON RECUPERACIÓN).
Restaura uno o más
archivos, sin restaurar toda
la base de datos. La
restauración de archivos
puede realizarse mientras
la base de datos está fuera
de línea o, en algunas
ediciones de SQL Server
2005 y versiones
posteriores, mientras la
base de datos permanece
en línea. Durante la
restauración de un archivo,
los grupos de archivos que
contienen los archivos que
se están restaurando están
siempre fuera de línea.
Restaura una o más páginas
dañadas. La restauración de
página se puede realizar
mientras la base de datos
está fuera de línea o, en
algunas ediciones de SQL
Server 2015 y versiones
posteriores, mientras la
base de datos permanece

Piecemeal restore Restaure y recupere la base
de datos en etapas en el
nivel del grupo de archivos,
comenzando con el
primario y todos los grupos
de archivos secundarios de
lectura / escritura.
[2]
en línea. Durante una
restauración de página, las
páginas que se restauran
están siempre fuera de
línea.
Restaure y recupere la base
de datos en etapas en el
nivel del grupo de archivos,
comenzando con el grupo
de archivos primario.
 RESUMEN

En esta monografía, cubrimos una gran cantidad de terreno necesario, discutiendo los archivos
que componen una base de datos de SQL Server, el papel crítico que juega cada uno, por qué es
esencial que estén respaldados, los tipos de respaldo que se pueden realizar en cada uno y cómo
esto se ve afectado por el modelo de recuperación elegido para la base de datos.

BIBLIOGRAFÍA Y LINKOGRAFÍA

[1] SQL Server Backup and Restore, Shawn McGehee, First published by Simple Talk Publishing
April 2012

[2] Backup and Restore SQL SERVER, Microsoft Corporation, 2017

[3] https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-
restore-of-sql-server-databases?view=sql-server-2017