viernes, 8 de enero de 2010

Respaldos en MS SQL Server. Parte 3.

Ahora viene lo interesante y la diferencia marcada y el porqué  de la importancia de los modelos de recuperación:
En el modelo simple, los datos se restauran al punto (momento) en que se realizó el último respaldo. Punto, no hay vuelta de hoja.

Ejemplo: Programas un respaldo todos los días a las 2:00 a.m.
Si ocurre un error a las 10:30 a.m., solo puedes restaurar la información hasta las 2 a.m. Si hay pérdida de datos, lo siento mucho, pero no es posible recuperar la información con una restauración, y es hora de echar mano de herramientas especiales para leer el registro y buscar manualmente las sentencias que afectaron la base de datos.

Otra herramienta son las auditorias a las acciones de los catálogos, es decir, emular un registro de transacciones guardando las sentencias sql insert, update y delete que se ejecutan contra la bae de datos, y poder generar un “undo” o “deshacer” para las sentencias que provocaron un error. No obstante esta herramienta es “medicina preventiva”, no correctiva.

Es por eso que este tipo de modelo de recuperación simple solo es recomendado para bases de datos de solo lectura, exclusivamente de consulta, y para pruebas y desarrollo.
Si tienes una base de datos transaccional recurrente de producción con frecuencia alta de actualizaciones, el modelo simple no es para ti, tú debes usar el modelo full.

Entre respaldo y respaldo de la base de datos, debes realizar respaldos periódicos a intervalos menores de tiempo del registro de transacciones, lo que te permitirá asegurar la recuperación de la información de mejor manera y minimizar las pérdidas de la misma.

Ejemplo: Programas un respaldo diario a las 2:00 a.m. de tu base de datos.
Programas un respaldo del registro de transacciones cada 4 horas (2 am, 6am, 10am, 2pm, 6pm, 10 pm).

A las 10:30 un usuario despistado ( que nunca falta ) se “chuta” una tabla. Con el modelo de recuperación full y los respaldos del registro de transacciones de las 2,6 y 10 a.m. puedes recuperar los datos hasta las 10 de la mañana y no solo los del día anterior como con el método simple. (Eso no es todo, es posible recuperar la información en su totalidad restaurando a un momento del tiempo específico, más detalles en la cuarta entrega).

Para restaurar bases de datos con el método full, el conjunto de sentencias sql es:
RESTORE DATABASE [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldo_1.bak' 
GO

RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_1.trn' 
GO

RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_2.trn' 
GO

RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_3.trn' 
GO
...
RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_n.trn' 
GO

Donde se debe respaldar primero la base de datos y posteriormente todos los respaldos de los registros de transacciones subsecuentes a el respaldo de la base de datos, en el orden en que fueron creados.
Bien, eso es todo por ahora, pero en la próxima entrega veremos cómo restaurar bases de datos a un punto especifico de tiempo, con una determinada fecha y hora.

martes, 5 de enero de 2010

Respaldos en MS SQL Server. Parte 2

Ahora veremos la ejecución de los respaldos, y las restauraciones. Me gusta hacerlo desde query Analizer, pero Management Studio y Enterprise Manager tienen cómodos y muy descriptivos asistentes.
La sentencia para el respaldo de una base de datos a disco es:

BACKUP DATABASE [MiBase] TO DISK = N’C:\Respaldo.bak'


Siendo [MiBase] el nombre de la base de datos y Respaldo.bak el nombre del archivo de respaldo.
Esta sentencia funciona para los modelos simple, full y bulk_logged.

Para respaldar el archivo de registro de transacciones, la sentencia sql es:

BACKUP LOG [MiBase]TO DISK = N'C:\Respaldolog.trn’


Donde [MiBase] el nombre de la base de datos y RespaldoLog.trn es el nombre del archivo de respaldo.
Esta sentencia funciona únicamente para los modelos full y bulk_logged.

Restauración.


La sentencia estándar para restaurar bases de datos en SQL Server es la siguiente:

RESTORE DATABASE [MiBase]
FROM DISK = N'C:\Respaldo.bak'


Esta sentencia funciona para los tres modelos de recuperación.

La sentencia estándar para restaurar registros de transacciones es la siguiente:

RESTORE LOG [MiBase]
FROM DISK = N'C:\RespaldoLog.trn'


Esta sentencia solo funciona para los modelos de recuperación full y bulk_logged. Hasta aquí, es la mar de sencillo, pero, por favor, échenle un ojo a la parte 3, que explica más a fondo las distintas situaciones de respaldo que se pueden presentar y como deben ser manejadas.

viernes, 1 de enero de 2010

Respaldos en MS SQL Server. Parte 1.

Lo primero que debes saber es que hay tres tipos de recuperación de datos:
  • Simple
  • Full ( Completa )
  • Bulk logged ( Registro por lotes)
Para una información más completa puedes visitar esta liga: http://msdn.microsoft.com/es-mx/library/ms189275.aspx, pero en términos básicos, se trata de los siguiente:

Simple: Como su nombre lo dice, es un respaldo simple, guarda la información y punto. Al respaldarla, lo hace directamente, deja la base de datos con la información al momento del respaldo. No requiere mayor administración ni operaciones de respaldo sobre el registro de transacciones.

Full ( Completa ): Necesita de más administración, ya que requiere copias de seguridad del registro de transacciones. Tiene como ventajas el poder restaurar la información a un momento dado especificando fecha y hora y, debido a que maneja copias del registro de transacciones, minimizar la posibilidad de pérdida de la información.

Bulk logged ( Registro por lotes ): Es el más complejo y administrado, y el que minimiza más la pérdida de información. Requiere de copias de seguridad al registro de transacciones y minimiza el tamaño del mismo. Tiene la desventaja de no poder recuperar la información a un momento específico del tiempo.

Ahora, hasta aquí ya va la cosa compleja ¿no? Es lo que dice el manual, pero, en la práctica, operativamente, ¿cual utilizar?

Fácil: Para aquellas bases de datos de prueba, desarrollo o de producción pero de solo lectura (exclusivamente consultas), es conveniente utilizar el método simple, ya que no es información actualizada muy frecuentemente.

Para aquellas bases de datos de producción en las que el respaldo de información transaccional es vital, es recomendable los modelos Full y Bulk logged.

Es vital para esto hacer copias de seguridad del registro de transacciones. En el modelo Full, el registro “trunca” los datos al hacer la copia de seguridad, lo que mantiene su tamaño óptimo en disco, caso contrario, fácilmente puede crecer más que la propia base de datos, además de permitir la restauración a un punto dado.

En el caso de Bulk logged, es complemento del modelo Full y se utiliza en aquellos casos en los que las operaciones de inserción por lotes (Bulk insert) son frecuentes.

En resumen:

Hay tres tipos de modelos de recuperación de bases de datos con el gestor MS SQL Server:

  1. Simple.- Respaldo simple. Para bases de datos de prueba, desarrollo o solo consulta. No hace copias de respaldo del registro de transacciones, no puede restaurar a un punto específico de tiempo.
  2. Full.- Respaldo completo. Para bases de datos de producción en el que las transacciones son frecuentes y su respaldo vital. Requiere de copias de respaldo del registro de transacciones y es capaz de restaurar a un punto específico de tiempo.
  3. Bulk logged.- Complemento de los respaldos completo y es para aquellas bases de datos en la que las inserciones por lotes son frecuentes. Requiere de copias de respaldo del registro de transacciones y no permite restauraciones a un punto de tiempo específico.
En el próximo post nos enfocaremos en los procesos específicos de respaldos, principalmente en los primeros dos modelos. Hasta la próxima, y que tengan excelente año nuevo y felices fiestas.

Respaldar o morir

Ó “Introducción a los respaldos en bases de datos”

Si eres un DBA o desarrollador junior en alguna tecnología de datos, seguro conoces la frasesita, y toda persona con la que tratas el tema te dice lo mismo, sin embargo, en los libros en línea y demás publicaciones oficiales, la documentación no está orientada a ser un manual operativo, sino que toca temas de trasfondo, y puede resultar impráctica.

Durante los siguientes posteos, intentaré ser objetivo y práctico en temas relacionados a respaldos en bases de datos de los motores MSSQL Server y MySQL, específicamente en los procesos operativos y mejores prácticas relacionadas con los respaldos en ambos motores.

Comenzaré por MS SQL Server, pueden acceder a la información directamente en este vínculo: Respaldos en MS SQL Server