Respaldo y Recuperación en SQL Server

Diseñar un plan de respaldo y recuperación involucra decidir qué bases de datos respaldar, con qué frecuencia, donde almacenar los respaldos, qué tan frecuentemente sobre-escrbirlos y qué tan rápido necesitas recuperar la base de datos. Sin embargo, para diseñar una estrategia de respaldo, primero hay que pensar en el proceso de recuperación y en la pérdida de datos que el negocio puede soportar, ya que de ese factor dependerá el tipo de respaldos a realizar, la frecuencia, y el modelo de recuperación (recovery model) a usar para configurar la base de datos.

Las bases de datos en SQL Server soportan tres modelos de recuperación: Full, Bulk-Logged y Simple y cada uno de estos modelos tiene una influencia muy particular sobre el tamaño del Transaction Log y el grado de pérdida de datos en caso de falla.

Bajo el modelo FULL, SQL Server registra todas las transacciones realizadas  dentro de la bitácora de transacciones (transaction log), incluyendo inserciones masivas (bulk), construcciones de índices, y las operaciones regulares. A diferencia del modelo simple, la bitácora de transacciones crece progresivamente hasta que la respaldas explícitamente. Este es el modelo que ofrece la mayor flexibilidad en la recuperación de los datos, através de restauraciones a cualquier punto en el tiempo.

Bajo el modelo SIMPLE las transacciones también se registran en la bitácora de transacciones aunque a menor detalle y las transacciones no activas se descartan de la bitácora de forma regular en cada checkpoint, en vez de en cada respaldo. Es decir, la bitácora no crece progresivamente si no que se trunca en cada checkpoint, a menos que existan transacciones activas. De ser así, entonces la bitácora crece hasta que las transacciones activas terminen y la bitácora pueda ser truncada sin problema.

En cuanto a los tipos de respaldo se refiere, SQL Server ofrece varias opciones: Completo, Diferencial, Filegroup, Bitácora de Transacciones y Copy-Only.

El respaldo completo no necesita mucha explicación ya que involucra respaldar todas y cada una las páginas que forman parte de la base de datos y aquellas asociadas con la bitácora de transacciones que se generaron mientras el respaldo estuvo activo.  La desventaja de los respaldos completos es que si la base de datos es muy grande, entonces pueden requerir bastante tiempo y espacio.

El respaldo diferencial consiste en respaldar todas las páginas que han sufrido cambios desde el último respaldo completo y para poder que funcione tienes que haber tomado un respaldo completo anteriormente.  Dado que se respaldan solamente las páginas que han cambiado desde el último respaldo completo, los respaldos diferenciales generalmente son más rápidos que los completos.

Nota: La base de datos Maestra no puede respaldarse diferencialmente.

El respaldo tipo filegroup consiste en respaldar todos los archivos que pertenecen a un filegroup en particular. Es importante señalar que aunque es posible respaldar un archivo en específico, dicha granularidad no es recomendable ya que el proceso de recuperación requiere que todos los archivos pertenecientes  al filegroup siendo recuperado se encuentren en el mismo punto o estado. Este tipo de respaldos se usan en combinación con los respaldos de la bitácora de transacciones para recuperar secciones de la base de datos.

El respaldo de la Bitácora de Transacciones o Transaction Log solamente puede hacerse cuando el modelo de recuperación de la base de datos es FULL o Bulk-logged y se realiza principalmente con el fin de reducir la cantidad de datos que pudieran perderse en caso de una falla y reducir el tamaño del archivo que almacena la bitácora. Cuando realizas un respaldo de la bitácora, SQL Server respalda todas la páginas nuevas desde el último respaldo completo, diferencial, o desde el último respaldo de la bitácora. Esto significa que cada respaldo de la Bitácora de Transacciones captura todas las transacciones asociadas con un punto en el tiempo.

Detach/Attach

Esta funcionalidad no es necesariamente una estrategia de respaldo pero te permite desconectar o desprender una base de datos de un servidor y conectarla o prenderla en otro. Una vez que haz desprendido la base de datos, puedes copiar los archivos que la comprenden a otro servidor y luego activarla ahí.

Los eventos que pueden afectar negativamente tus bases de datos y para los cuales tienes que prepararte son: Borrar información accidentalmente, corrupción por fallas de hardware y desastres naturales. Las técnicas o procedimientos que seguirás para restaurar una base de datos dependerán de los tipos de respaldos que formen parte de la estrategia de respaldo que diseñaste y pusiste en operación.

Cuando restauras una base de datos de usuario sobre una Master Database nueva, la Master Database se actualiza usando la información contenida en la base de datos de usuario que estás restaurando.

Si la Master Database falla y no tienes respaldo para componerla entonces tienes que correr el programa de setup.exe para tratar de repararla o hacer una Master nueva. Recuerda que la Master Database contiene información sobre la estructura de la base de datos, parámetros de configuración del servidor, cuentas de usuario, dispositivos de respaldo, etc. y por lo tanto es importante respaldarla cada vez que se hagan cambios en estas áreas. Una recomendación común es respaldar la base de datos Master un día si y un día no y mantener varias respaldos a la mano.

SQL Server te permite operar casi normalmente durante los respaldos a excepción de que no puedes agregar o quitar bases de datos ni tampoco reducirlas de tamaño (shrink).  Esta funcionalidad es posible gracias a que SQL Server respalda la sección del Transaction Log que se usó mientras la operación de respaldo estuvo en efecto o activa, lo cual permite que SQL Server sea capaz de deshacer las transacciones que se quedaron a medias o incompletas durante el respaldo.  Sin embargo, si bien es cierto que parte del Transaction Log se incluye como parte de la operación de respaldo, dicha copia no es suficiente para considerar que el transaction log ha sido respaldado. Dicho de otra forma, si tu base de datos ha sido configurada para correr bajo el modelo de recuperación llamado “FULL” o “BULK-LOGGED”, entonces tienes  que respaldar el transaction log por separado. Nota: Para poder respaldar el transaction log, tienes que haber hecho un respaldo completo alguna vez, de lo contrario el respaldo del transaction log arrojará error.

Los parámetros o información mínima que necesitas para respaldar una base de datos son el nombre de la base de datos y el dispositivo de respaldo donde vas a almacenar los datos, ya sea el nombre de un archivo o un <backup device>. Por lo general, los respaldos residen en un solo archivo pero también tienes la opción de especificar varios dispositivos (hasta un máximo de 64).

En SQL Server tienes la opción de hacer los respaldos usando la interface gráfica SQL Server Management Studio (SSMS) o através de comandos T-SQL. Sin embargo, hay que tener en cuenta que si usas T-SQL entonces pierdes uno de los mayores beneficios de SQL Server: Procedimientos de recuperación automatizados.

Backup Devices

Son un objeto que apunta a un archivo físico en disco, en cinta o en la red.  Si el backup device apunta a cinta, entonces el tape drive tiene que estar conectado directamente al servidor y no puede ser remoto. Los backup devices son útiles porque te evitan tener que usar rutas o paths fijos, lo cual te dá flexibilidad a la hora de diseñar scripts para respaldar la base de datos y transportarlos de una región a otra (de TEST a  PROD).

Aunque es posible que juntes varios respaldos en un solo archivo, esta practica no es recomendable y la manera correcta de hacerlo es que cada respaldo resida en su propios archivos.

Respaldo diferencial: Cada archivo tiene un mapa de los extents que residen en él y cada vez que relizas un respaldo completo el mapa se resetea a cero. Al realizar una transacción, la entrada correspondiente para el extent en cuestion se cambia a uno para indicar que ha sido modifcado.

Los mecanismos de alta tolerancia no son un substituto para los respaldos realizados regularmente.

This entry was posted in Funcionamiento. Bookmark the permalink.

Comments are closed.