Disaster Recovery Plan using Microsoft SQL Server Logshipping

Disaster Recovery Plan using Microsoft SQL Server Logshipping

The purpose of this post is to give you a quick view of Logshipping with Microsoft SQL Server 2005/2008 for a scenario Disaster Recovery Plan.

Description
The log shipping is a SQL Server to maintain a backup server to date by applying to regular transaction logs of a database on a secondary database An optional third server instance, known as the monitor server, records the history and status of backup and restore operations and, optionally, raises alerts if these operations fail to occur as scheduled.

The principle is simple:
1. Backup of Transaction Log on the primary server
2. Copy of Transaction Log on the primary to the secondary server
3. Restore Transaction Log on the machine secondary

The method of recovery must be in FULL or Bulk-Logged.

Log Shipping Overview
https://msdn.microsoft.com/en-us/library/ms187103.aspx  

Benefits
• No need for specialized equipment
• Possibility to have multiple secondary servers
• Ability to access the database in read-only secondary
• Possibility to have a cluster on the production site and a simple machine on the backup site

Constraints
• Operating base by base (not server)
• Need to keep the OS on both machines in parallel
• Need to retain both SQL (options, logins, ...)
• Large network bandwidth to copy the databases and logs.
• More input / output discs due to copy transaction logs from one machine to another. It is recommended to stagger the various backup jobs each database.
• Asynchronous operation can thus shift between primary and secondary server. In the case of failover on the secondary site, may be the last transaction logs were not copied, the data from the backup site would then not be in phase with the production site.
• Both machines must be on the same network to communicate and make copies of files. They will have different names.
• Failover and clients connection string must be manually .
• Plan and monitor the capacity directories backup and restore to ensure that storage space is sufficient for newspapers sent.

If you want a solution without data loss synchronous and automatic failover you must choose SQL Server Mirroring instead of Logshipping

Maintenance
• Maintenance must be duplicated on the main server and all secondary servers .
• Any changes to SQL Server such as a configuration change, adding login ... must be made on different servers

Managing Metadata When Making a Database Available on Another Server Instance
https://msdn.microsoft.com/en-us/library/ms187580.aspx

Applying patch or hotfix
• Applying a service pack or hotfix on a SQL Server must be on each machine.SQL Server logshiping allows for rolling patches an upgrades :
- You have to upgrade secondary first
- Then perform a failover
- And upgrade the original primary (now secondary)

Test server backup
• Possible without affecting the production.
• Need to resynchronize the databases on the server after the backup test
• Manual Switches

Failing Over to a Log Shipping Secondary
https://msdn.microsoft.com/en-us/library/ms191233.aspx Changing Roles Between Primary and Secondary Servers
https://msdn.microsoft.com/en-us/library/ms178117.aspx

Plan de reprise d'activité avec Microsoft SQL Server Logshipping

L'objectif de ce post est de vous donner une vue rapide du Logshipping  avec Microsoft SQL Server 2005/2008 pour un scénario de Plan de Reprise d'Activité.

Description
Le log shipping est une technologie SQL Server permettant de maintenir un serveur de secours à jour en appliquant à intervalle régulier les journaux de transactions d’une base de données sur une base de données secondaire. Une troisième instance de serveur facultatif, appelée serveur moniteur, enregistre l'historique et l'état des opérations de sauvegarde ainsi que de restauration, puis déclenche éventuellement des alertes si ces opérations ne sont pas effectuées selon la planification établie.

Le principe est simple :
1. Backup du Transaction Log sur l’instance Primaire
2. Copie du Transaction Log de la machine primaire vers la machine secondaire
3. Restauration du Transaction Log sur la machine secondaire

Le mode de recovery doit être en mode FULL ou Bulk-Logged.

Vue d'ensemble de la copie des journaux de transaction
https://msdn.microsoft.com/fr-fr/library/ms187103.aspx  

Avantages
• Pas de nécessité d’avoir un matériel spécialisé
• Possibilité d’avoir plusieurs serveurs secondaires
• Possibilité d’accéder à la base secondaire en lecture seule
• Possibilité d’avoir un cluster sur le site de production et une machine simple sur le site de secours

Contraintes
• Fonctionnement base par base (et non serveur)
• Nécessité de maintenir les OS sur les deux machines en parallèle
• Nécessité de maintenir les deux SQL (options, logins, …)
• Bande passante réseau importante pour la copie des bases et des logs.
• Davantage d’entrées/sorties disques du fait de la copie des journaux de transaction d’une machine à l’autre. Il est recommandé d'étaler dans le temps les différentes jobs de backup de chacune des bases de données.
• Fonctionnement asynchrone donc décalage possible entre primaire et secondaire. Dans le cas d’un passage sur le site de secours il se peut que les derniers journaux de transaction n’aient pas été copiés, les données du site de secours ne seraient alors pas en phase avec celles du site de production.
• Les deux machines doivent être sur le même réseau pour communiquer et réaliser les copies de fichiers. Elles auront donc des noms différents.
• Basculement et changement des chaines de connexion clientes manuellement.
• Planifier et surveiller la capacité des répertoires de sauvegarde et de restauration pour garantir que l'espace de stockage est suffisant pour les journaux envoyés.

Si vous souhaitez une solution synchrone sans perte de données avec un basculement automatique vous devez vous orienter vers une solution SQL Server Mirroring

Maintenance
• La maintenance doit être dupliquée sur le serveur principal et tous les serveurs secondaires.
• Toute modification de SQL Server telle qu’un changement de configuration, ajout de login, … doit être faite sur les différents serveurs

Gestion des métadonnées lors de la mise à disposition d'une base de données sur une autre instance de serveur
https://msdn.microsoft.com/fr-fr/library/ms187580.aspx

Application de correctif
• L’application d’un service pack ou d’un correctif sur SQL Server doit se faire sur chaque machine.SQL Server Logshipping autorise l'application de correctif de manière différée :
- Vous devez mettre à jours le serveur secondaire
- Puis faire une bascule
- Et mettre à jours le principal (qui est maintenant le serveur secondaire)

Test du secours
• Possible sans affecter la production.
• Nécessite de resynchroniser les bases sur le serveur de secours après le test
• Bascule Manuelle

Basculement vers une base de données secondaire de copie des journaux de transactions
https://msdn.microsoft.com/fr-fr/library/ms191233.aspx Changement des rôles entre les serveurs primaire et secondaire
https://msdn.microsoft.com/fr-fr/library/ms178117.aspx

Plan de Recuperación de Desastres con Microsoft SQL Server Logshipping

El propósito de este post es para darle una vista rápida de Logshipping con Microsoft SQL Server 2005/2008 para un Plan de Recuperación de Desastres Informáticos.

Descripción
El Logshipping es un tecnología de SQL Server para mantener un servidor de copia de seguridad hasta la fecha mediante la aplicación regular de los registros de transacciones de una base de datos en una base de datos secundaria. En una tercera instancia de servidor opcional, denominado servidor de supervisión, se registra el historial y el estado de las operaciones de copias de seguridad y restauración y, opcionalmente, se activan alertas si estas operaciones no se producen según lo programado.

El principio es simple :
1. Copia de seguridad del log de transacciones de la Instancia Primaria
2. Copia del registro de transacciones de la máquina primaria a la máquina secundaria
3. Restaurar registro de transacciones en la máquina secundaria

El modelo de recuperación de la base debe estar en FULL o Bulk-Logged.

Información general de trasvase de registros
https://msdn.microsoft.com/es-es/library/ms187103.aspx  

Beneficios
• No hay necesidad de equipo especializado
• Posibilidad de tener múltiples servidores secundarios
• Capacidad de acceso a la base de datos de sólo lectura en el servidor secundario
• Posibilidad de tener un Cluster MSCS en el lugar de producción y una simple máquina en el sitio de la copia de seguridad

Limitaciones
• Opera a través de una copia de base por base (y no del servidor)
• Necesidad de mantener el sistema operativo en ambas máquinas en paralelo
• Necesidad de mantener ambos servidores SQL (opciones, accesos, ...)
• Importante ancho de banda de red  para copiar las bases de datos y registros.
• Incremento de operaciones de entrada/salida de los discos debido a la copia de los registros de transacciones de una máquina a otra. Se recomienda escalonar las diversas tareas de copia de seguridad para cada base de datos.
• La operación asíncrona puede alternar entre el servidor primario y secundario. En el caso de un cambio en el sitio de seguridad , es posible que los recientes registros de transacciones no se copien, los datos de la copia de seguridad del sitio no estarán en fase con el lugar de producción.
• Ambas máquinas deben estar en la misma red para comunicar y hacer copias de archivos. Deben tener nombres distintos.
• El failover y las cadenas de conexión de cliente son manuales
• Planificar y supervisar la capacidad de los directorios de copia de seguridad y restaurar para garantizar que el espacio de almacenamiento es suficiente para los periódicos enviados.

Si desea una solución sin pérdida de datos síncrona con failover automático, debe referirse on una solución SQL Server Mirroring .

Mantenimiento
• EL mantenimiento debe ser duplicado en el servidor principal y todos los servidores secundarios.
• Cualquier cambio a SQL Server como un cambio de configuración, añadir login ... debe hacerse en distintos servidores

Administrar los metadatos cuando una base de datos pasa a estar disponible en otra instancia de servidor
https://msdn.microsoft.com/es-es/library/ms187580.aspx

Aplicar un parche
•La aplicación de un Service Pack o hotfix en un servidor SQL Server debe ser en cada máquina.SQL Server Logshipping permite la aplicación de parche en diferido :
- Tiene que actualizar primero secundaria
- A continuación, realiza una conmutación en la máquina  secundario
- Y actualizar la primaria (ahora secundaria)

Prueba del Socorro
• Posible sin afectar la producción.
• Necesidad de resincronizar las bases de datos en el servidor de copia de seguridad después de la prueba
• Conmutación manual

Realizar una conmutación por error a una base de datos secundaria de trasvase de registros
https://msdn.microsoft.com/es-es/library/ms191233.aspx Cambiar las funciones entre el servidor primario y secundario
https://msdn.microsoft.com/es-es/library/ms178117.aspx

Michel Degremont | Microsoft EMEA
Product Support Services Developer - SQL Server Core Engineer |