Configurando Log Shipping

Log Shipping automáticamente envía un backup Transaction Log  de una base de datos primaria en un servidor o instancia primario a una o más bases de datos secundarias.

Log Shipping suporta un tercer servidor o instancia opcional , conocido como “Monitor Server”

 

Log Shipping consiste en 3 operaciones básicas:

1.       Respaldar el Transaction Log en el server primario

2.       Copiar el Archivo Log  en el Servidor Secundario

3.       Restaurar el Log en el Servidor Secundario

  

Configuración

1.       Antes de empezar verifiquemos que nuestros SQL Server Agents se estén ejecutando y tengan permisos suficientes para escribir archivos en el otro server.

2.       El primer paso sería inicializar la base de datos en el servidor secundario con un respaldo del servidor primario, dejar la base de datos el modo RESTORE WITH NORECOVERY.

3.       En el servidor primario crear una carpeta compartida llamada “EnviadosLogShipping”.

4.        En el servidor secundario crear una carpeta compartida llamada “RecibidosLogShipping”.

5.       En el servidor primario con la base de datos a realizar el LogShipping, hacer click derecho y nos vamos a propiedades,  opción “Transaction Log Shipping”, hacemos click en “Enabled this as a primary database in a log shipping configuration”.  Por ultimo click en Backup Settings.

 

    6.       En la configuración definimos la ruta donde dejaremos el archivo log,  la carpeta compartida creada previamente.

 

    7.       Ahora vamos a configurar el servidor secundario, haciendo click en Add

 a

 

    8.       Primero hacemos click en Connect,  y nos conectamos a nuestro server secundario.  Completamos las pestanas tal y como se ve en las capturas siguientes.

    9.       Ahora vamos a verificar que es lo se está ejecutando en nuestro log shipping.  Sobre la base datos de cada servidor,  hacer click derecho,  Reports, Standard Reports,  y seleccionamos el ultimo reporte llamado Transaction Log Shipping Status.  Recodar hacerlo para cada servidor ya que cada uno nos mostrará información complementaria.

 

     10.       Ahora vamos a ver como realizar el switch en el caso de que nuestro server primario “muera” o falle y que nuestro server secundario entre como primario.

RESTORE DATABASE Cuentos WITH RECOVERY

IMPORTANTE:  El servidor primario deberá estar fuera de línea para que no continue enviando respaldos o continue como servidor primario en funcionamiento,  de lo contrario podremos perder información al no saber que servidor es el que esta en producción .

Configurando Database Mirroring

Database Mirroring es una solución de Alta Disponibilidad en SQL Server, disponible desde SQL Server 2005 y sensiblemente mejorada en SQL Server 2008, mostrándose como una alternativa a los sistemas de Alta Disponibilidad basados en Microsoft Cluster y/o Replicación de Almacenamiento Datos, siendo también una alternativa interesante a otras tecnologías como Log Shipping o a la Replicación de SQL Server.


Database Mirroring, al igual que Log Shipping, sólo protege a nivel de base de datos (es decir, sólo las bases de datos de usuario) y no a nivel de Instancia, para lo cual sería necesario implementar Server Clustering (y así proteger también las bases de datos del sistema y demás elementos que forman una instancia de SQL Server).

Database Mirroring es una tecnología de Alta Disponibilidad basada en un modo de funcionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos. En consecuencia, no será posible el acceso a la copia de la base de datos del Servidor Espejo.

Database Mirroring requiere que la base de datos que se desee proteger, esté configurada con el Modo de Recuperación Completo (Full Recover Model), algo bastante evidente, al tratarse de una tecnología que basa su funcionamiento en el envío de transacciones de una base de datos principal a una base de datos espejo o secundaria.

Es posible montar Database Mirroring sobre SQL Server 2005 y SQL Server 2008. El hecho de poder montar el Servidor Principal sobre SQL Server 2005 y el Servidor Espejo sobre SQL Server 2008, permite plantearse soluciones de Database Mirroring interesantes para Migraciones de SQL Server 2005 a SQL Server 2008 con a penas corte de servicio y luego romper el Database Mirroring, si no lo queremos mantener.

Es importante tener en cuenta que NO es posible hacer funcionar Database Mirroring con el Servidor Principal en SQL Server 2008 y el Servidor Espejo en SQL Server 2005

Los posibles papeles o roles que puede desempeñar una instancia de SQL Server en una solución de Database Mirroring son:

• Servidor Principal. Mantiene la copia activa de la base de datos (base de datos principal), a través de la cual, se ofrece el servicio a los usuarios. Todas las transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos principal.

• Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base de datos espejo o mirror database), y aplica todas las transacciones enviadas por el Servidor Principal, manteniendo sincronizada la base de datos espejo.

• Servidor Testigo (Witness). Se trata de un elemento opcional. No es obligatorio o necesario implementar un Servidor Testigo (Witness) en una solución de Database Mirroring. Sin embargo, si deseamos que nuestra solución de Database Mirroring ofrezca recuperación automática ante fallos (automatic failover), entonces sí será necesario implementar un Servidor Testigo (Witness Server), pues éste es quién monitorizará los Servidores Principal y Espejo partícipes de una Sesión de Espejo (Mirror Session) con el objetivo de asignar el papel de Principal al servidor Espejo en caso de una caída de servicio o pérdida del primero (es decir, en caso de caída del Servidor Principal, se asignará el papel de Principal al Servidor Espejo, manteniéndose así el servicio). El trabajo realizado por el Servidor Testigo (Witness) no es muy intenso, por lo cual, no requiere de grandes recursos, y además, un mismo servidor puede actuar como Servidor Testigo (Witness) para múltiples sesiones de espejo, sin pérdida de rendimiento.

Database Mirroring ofrece tres modos de funcionamiento, como antes adelantamos:

• Modo de Alta Disponibilidad (síncrono y con testigo). Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Requiere de un Servidor Testigo (Witness) ubicado sobre una tercera máquina (que no sea ni el Servidor Principal ni el Servidor Espejo), gracias al cual es posible la recuperación automática ante fallos (automatic failover) o conmutación automática de roles. En caso de fallo del Servidor Principal durante el envío de transacciones, el Servidor Espejo tiene que terminar las transacciones encoladas antes de poder levantarse como Servidor Principal. Por supuesto también es posible la recuperación manual ante fallos (manual failover) o conmutación manual de roles. En caso de una caída o pérdida del Servidor Espejo, la base de datos principal se mantendrá activa.

• Modo de Alta Protección (síncrono y sin testigo). Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Sin embargo, no utiliza un Servidor Testigo (Witness). En este modo de funcionamiento, no es posible la existencia de pérdida de datos, pero la recuperación ante fallos se realiza de forma manual (manual failover). En caso de una caída o pérdida del Servidor Espejo, la base de datos principal dejará de estar activa, al haber perdido el Quorum.

• Modo de Alto Rendimiento (asíncrono y sin testigo). Las transacciones son aplicadas de forma asíncrona a la base de datos espejo, ofreciendo mejor rendimiento que los anteriores modos de funcionamiento, pero pagando como precio la existencia de posibles pérdidas de transacciones (y en consecuencia, potenciales pérdidas de datos). Evidentemente, la recuperación ante fallos se realiza de forma manual (manual failover), hablando de conmutación forzada (es decir, cambio de roles sin comprobación de datos escritos en el servidor espejo). En caso de una caída o pérdida del Servidor Espejo, el Servidor Principal no se verá afectado.

1. Primeramente preparamos nuestra base de datos espejo en nuestro server o instancia que fungirá como tal, aquí dos puntos importantes: Que la base datos que restauremos sea el ultimo backup realizado desde la principal. A la hora de restaurarla tenemos que marcar la opción de NON RECOVERY.



2. En el Management Studio, Explorador de Objetos, Seleccionamos una base de datos, hacemos click derecho sobre ella en la opción, Task, Mirror.

 
3. El primer paso sería configurar la seguridad, para lo cual vamos a seguir un asistente.


En el primer paso del asistente nos preguntara si queremos tener una instancia de testigo, para este primer ejempo le diremos que No.

4.       Luego definiremos el servidor principal

5.       Ahora definiremos nuestra instancia o servidor espejo

6.       En este paso se definen las cuentas de usuario que utilizaran tanto el servidor principal como el espejo que estén en un dominio. Para nuestro ejemplo dejaremos en blanco esta opción.

7.       Finalmente terminanos de configurar el asistente de seguridad.

8.       Una vez finalizado nos pedirá si deseamos iniciar el mirroring,  le diremos iniciar.

9.       Ya tendremos configurado nuestro mirroring como se muestra en la pantalla siguiente,  desde aquí podemos iniciar el mirroring,  y podemos configurar el tipo de operación que deseamos, tal y cual se planteo al inicio del articulo.  Hacemos click en OK.

La Redirección Automática del cliente en una infraestructura de Database Mirroring, es una funcionalidad muy apreciada, y en este caso, es tan fácil como utilizar una sintaxis determinada en la cadena de conexión a SQL Server, como se muestra en el siguiente:

"Data Source=PORTATIL;Failover Partner=PORTATIL\MIRROR;Initial Catalog=Demo;Integrated Security=True;"

Estrategias de Backup

Existen organizaciones en donde los procesos de back-up no han sido modificados en años aunque los volúmenes de datos crecieran geométricamente.

Sin duda ha llegado el momento de que se reexaminen los requerimientos y recursos para respaldar y recuperar los datos.

Los editores de Enterprise IT Planet, medio de la familia de Datamation, consultaron a varios expertos para pedir diez consejos útiles en la mejora de estos procesos.

El primer consejo nos lo ofrece W. Curtis Preston, VP de GlassHouse Technologies Inc. y consiste en planificar en sentido inverso.

Esto equivale a partir de los requerimientos de recuperación: qué debe recuperarse y en cuánto tiempo. De esta manera, se fija el Recovery Time Objective (en qué tiempo debe restaurarse la data) y el Recovery Point Objective (qué tan actualizados deben ser los datos para cada clase de dato.)

El segundo consejo es el de salvar los archivos a disco antes de migrarlos a cintas. De esa manera, se achican las ventanas de back-up hasta en un 66%, economizando el uso de servidores y ahorrando tiempo de operación.

La tercer recomendación es la de eliminar el exceso de información a respaldar. No hace falta guardar copias diarias de archivos que no han cambiado en meses o copias de e-mails enviadas a varios empleados. La de-duplicación de archivos reduce la cantidad de espacio de storage y acelera los back-ups. Se han logrado reducciones de capacidad del orden de 20 a 1 usando de-duplicación de datos.

En cuarto lugar, se recomienda guardar las cintas de backup fuera de la zona de impacto de un eventual desastre y, si es posible, replicar o espejar los datos en un sitio de recuperación ante desastres lejano para que todo siga en línea si se cae el centro principal.


El quinto consejo tiene que ver con la eliminación de cuellos de botella en la red. Pueden demorar los procesos de backup y recuperación. Esto se hace más evidente con la virtualización de servidores donde múltiples servidores virtuales usan la misma interfaz y tarjeta de conexión a la red. Los drives de cinta pueden ser demasiado veloces para una interfaz de red, aunque ésta sea Gb Ethernet.

El sexto punto es minimizar la cantidad de productos de backup que se usan. Puede ser ventajoso usar a los mejores de su clase en cierto tipo de servidor, pero soportar varios productos puede ser complicado y costoso.

En séptimo lugar: usar varias capas de protección cuando sea adecuado. “Dependiendo de la criticidad y sensibilidad en tiempo de los datos, usamos diferentes métodos,” nos dice el gerente de operaciones de SunGard Availability Services, responsable por el backup de 30 TB de datos diarios. En algunos casos, usan múltiples soluciones para un mismo set de datos, como replicación remota combinada con backup en cintas.

Octavo: guardar una copia del plan de recuperación junto con el backup de los datos. Cuando ocurre un desastre, los que se ocupan normalmente de la operación pueden no estar disponibles. Con una copia del plan, alguien más puede ocuparse de las acciones necesarias.

En noveno lugar, está la conveniencia de probar el proceso de restauración completo y con el equipamiento que será usado en el caso de una emergencia. El sitio de recuperación ante desastres puede tener diferentes servidores o arquitectura de red. Si una aplicación busca una pieza de código o archivo en un servidor en especial ¿Qué ocurrirá si está en un servidor diferente? Prueben todo el sistema y no sólo si los archivos se recuperan adecuadamente.

Por último, queda la sugerencia de dejar la restauración rutinaria de archivos como función del help-desk para casos de archivos Word borrados accidentalmente, etc. De esta manera, los especialistas en storage pueden trabajar en la mejora de los niveles de servicio y atender al crecimiento y la flexibilidad de la operación.

Fuente:
Revista Datamation
www.datamation.com.ar

Implementando Disaster Recovery

Modelos de Recuperación (Recovery Models)

El Modelo de Recuperación es una opción de configuración de base de datos que indica cómo se gestiona el uso del LOG de Transacciones de SQL Server para dicha base de datos (esta opción se configura para cada base de datos de forma independiente). En función de la configuración del Modo de Recuperación debemos elegir la estrategia de Backup y Restauración de SQL Server (o viceversa), y podremos mejorar el rendimiento de ciertas operaciones denominadas Operaciones de Registro Mínimo, minimizando las escrituras en el LOG de SQL Server (y en consecuencia, minimizando el tamaño del LOG de SQL Server).

Tipos de Modelos

-          Simple Recovery

-          Full Recovery

-          Bulk-Logged Recovery

Modo de Recuperación Simple o Sencillo (Simple Recovery Model).

·         Las Operaciones de Registro Mínimo realizarán un registro mínimo en el LOG de SQL Server, minimizando las escrituras en LOG y maximizando el Rendimiento de SQL Server.

·         Sólo se permiten Copias de Seguridad Completas o Diferenciales.

·         No se puede recuperar (RESTORE) a un punto en el tiempo (STOPAT).

·         Los cambios desde el ultimo backup están desprotegidos

·         ALTER DATABASE Demo SET RECOVERY SIMPLE

Cuando usar Simple Recovery

1.       Cuando un punto de recuperación no es necesario

2.       Quieres mejorar el desempeño

 Modo de Recuperación Completo (Full Recovery Model).

·         Las Operaciones de Registro Mínimo no se comportarán como tal, realizándose siempre un registro completo en el LOG de SQL Server.

·         Se permite cualquier tipo de Copia de Seguridad (BACKUP): Completas, Diferenciales, de Fichero, de Grupo de Ficheros (FILEGROUP), y de LOG.

·         Es posible recuperar (RESTORE) a un punto del tiempo (STOPAT).

·         ALTER DATABASE Demo SET RECOVERY FULL

Cuando usar Full Recovery:

1.       Si debes poder recuperar todos los datos

2.       Si debes poder recuperar un punto en el tiempo

§  Si estás dispuesto a incurrir los costos de administración del Log de Transacciones

3.       Si estás dispuesto a incurrir en el desempeño.

 Modo de Recuperación de Registro Masivo (Bulk-Logged Recovery Model).

Este Modo de Recuperación sólo debe ser utilizado de forma intermitente o eventual para mejorar el rendimiento de las Operaciones de Registro Mínimo.

·         Las Operaciones de Registro Mínimo realizarán un registro mínimo en el LOG de SQL Server, minimizando las escrituras en LOG y maximizando el Rendimiento de SQL Server.

·         Se permite cualquier tipo de Copia de Seguridad (BACKUP): Completas, Diferenciales, de Fichero, de Grupo de Ficheros (FILEGROUP), y de LOG,

·         No se puede recuperar (RESTORE) a un momento en el tiempo (STOPAT).

·         ALTER DATABASE Demo SET RECOVERY BULK_LOGGED

Cuando usar Bulk-Logged Recovery:

1.       Si estas corriendo cargas de datos masivos a gran escala,  y no requiras recuperación un punto de recuperación en el tiempo.

2.       Si corres periódicamente operaciones de carga masiva de datos.

3.       Si quieres conservar espacio en el disco usando mínimo LOG.

Tan pronto cuando tus operaciones de carga de datos haya finalizado,  inmediatamente regresa al modo de recuperación Full Recovery Model

Backup Types

Full Backup: Backup de toda la base de datos.

Diferential: Backup de los cambios efectuados desde el último Full Backup.

Transaction Log: Contiene todos los cambios desde el último backup de log. El backup de Log tiene, por defecto, la característica de que, una vez finalizado, dispara automáticamente una   operación de TRUNCATE sobre la log, lo cual libera su espacio utilizado. Sólo es posible bajo los modelos de recuperación Full y Bulk-Logged.

Demo

1.      Verifiquemos la ultima fecha de respaldo de nuestra base “Demo” y de su Log.   En las propiedades de la base de datos. Sección General.

2.      Crear un respaldo de la base de Datos,  de tipo Full Backup.

3.      Crear un respaldo del Log de la base de Datos.  

4.      Verificar nuevamente las fechas de respaldo de nuestra base.

5.      Ahora vamos a suponer que tenemos un caso de emergencia, tenemos corrupción en los datos, o cualquier otro problema con nuestra base.

6.      Vamos a respaldar la base,  seleccionamos el tipo de backup Transaction Log. En la sección de opciones,  apartado de Transaction Log, seleccionamos “Back up the tail of the log, and leave the database in restoring state”

7.      Ahora nuestra base de datos quedo en modo de “restoring”.

8.      A continuación vamos a recuperar nuestra base basado en el último backup que realizamos.  Click Derecho sobre la base, Task, Restore, Database

9.      Seleccionamos todos los respaldos que tenemos,  Full Backup, Transaction Log y Transaction Log (Read Only)

10.  Una vez hecho esto hemos recuperado nuestra base desde el ultimo Full Backup realizado.

11.  Vamos a modificar algunos datos de nuestra base para posteriormente recuperarla en un punto del tiempo.  Supongamos que por error ponemos todos nuestros productos en precio 0.

UPDATE Productos SET Precio  = 0

12.  Ahora procedemos a realizar un Backup Transaction Log y dejamos la base en recuperación como en el punto 6.

13.  Cerramos todas las conexiones a la base debido a que vamos a restaurarla,   seleccionamos todos los archivos de backup y escogemos un punto en el tiempo en la opción “To a Point in Time”, que tiene que ser antes que pasara nuestro error de productos  con precio 0.  Cabe recalcar que no hemos hecho ningún respaldo desde que nuestro backup inicial,  se restaurara basado en el Log de transacciones.