Pour voir comment le wizard fonctionne, suivons-le écran par écran. Ouvrez Enterprise Manager, étendez le noeud du serveur primaire, creusez jusqu'au noeud Management, et lancez le Database Maintenance Plan Wizard.
Sur le premier écran du wizard, illustré figure 2, sélectionnez la base de données source, puis cochez la
case Ship the transaction logs to other SQL Servers (log shipping) en bas de l’écran. Vous pouvez bâtir un plan de maintenance de base de données pour seulement une base de données source à la fois. La case à cocher n’est disponible que quand vous définissez la base de données source sélectionnée d’après le modèle full ou bulk_logged recovery parce que seuls ces modèles permettent des sauvegardes de journaux de transactions.
Les écrans suivants proposent des options permettant d’associer des sauvegardes de bases de données complètes et l’activité de maintenance, avec le plan de maintenance de la base de données. Cependant, sachant qu’un plan comportant plus d’une fonction n’est pas très clair, je conseille de tenir les plans de log shipping séparés des autres plans.
Sur l’écran Specify Transaction Log Backup Disk Directory, cochez la case Use this directory et naviguez jusqu’au dossier transaction-log du serveur primaire. Assurez-vous que la durée Remove files older than indiquée est suffisante pour garder les fichiers log sur le serveur primaire jusqu’à ce que vous les sauvegardiez dans le cadre du plan de sauvegarde normal. Si la durée indiquée est trop courte et si le job de copie sur le serveur secondaire échoue, le job SQL Agent du serveur primaire supprimera les fichiers transaction-log avant que SQL Server n’ait pu les copier sur le serveur secondaire, et le log shipping échouera. Spécifiez l’extension .trn par défaut pour les fichiers transaction-log, que le plan nommera d’après le format dbname_tlog_yyyymmddhhmm.trn.
L’écran suivant, Specify the Transaction Log Share, n’apparaît que si vous avez précisé que le plan installera log shipping. Sur cet écran, vous devez indiquer le file share sur le serveur primaire. Vous pouvez utiliser le bouton ellipse (…) pour naviguer vers le file share.
L’écran Specify the Log Shipping Destination permet d’ajouter votre ou vos serveurs secondaires, un à un. Cliquez sur Add pour ouvrir la boîte de dialogue Add Destination Database, illustrée figure 3, et dans laquelle vous allez entrer toute l’information sur le serveur secondaire. La boîte de texte Server Name contient le nom du serveur secondaire que vous avez enregistré dans Enterprise Manager lors des étapes de préparation. Dans la boîte de texte Directory, entrez le nom du répertoire de serveur secondaire qui recevra les copies des journaux de transactions de la base de données source. Ce nom est un nom de chemin local, pas un file share. Vous pouvez choisir l’option de Create and initialize new database sur le serveur secondaire, auquel cas SQL Server copiera et restaurera la sauvegarde de base de données initiale. Ou bien, vous pouvez choisir Use existing database (No initialization) si vous avez déjà effectué la restauration de la base de données. S’il s’agit d’une grande base de données, vous pouvez fort bien faire votre propre sauvegarde et restauration pendant les heures creuses.
La base de données de destination doit être en état non repris pour que SQL Server puisse y restaurer les journaux de transactions. Il y a deux possibilités concernant l’état de chargement de la base de données : No recovery mode ou Standby mode. Le mode No recovery signifie que les utilisateurs ne peuvent pas interroger la base de données ; les restaurations du journal de transactions seront la seule activité le concernant. Le mode Standby laisse la base de données en état de lecture seule, afin que vous puissiez l’interroger quand vous n’êtes pas en train de restaurer les journaux de transactions. L’écran Add Destination Database présente également une option Terminate users in database (Recommended) pendant la restauration de la base de données (si vous utilisez une base de données existante) ou pendant les restaurations du journal de transactions. Pendant une restauration de base de données ou de journal de transactions, le processus de restauration est le seul « utilisateur » autorisé dans la base de données. C’est pourquoi Microsoft conseille d’utiliser cette option parce que la présence d’autres utilisateurs dans la base de données retardera la restauration.
Vous pourriez aussi sélectionner l’option Allow database to assume primary role, qui permet à la base de données de destination de devenir une nouvelle base de données source de log shipping, permettant ainsi une éventuelle future inversion des rôles entre les serveurs primaire et secondaire. Si vous choisissez cette option, spécifiez le file share du journal de transactions du serveur secondaire comme l’emplacement pour les sauvegardes de journaux de transactions provenant de la nouvelle base de données source.
Sur l’écran suivant, Initialize the Destination Databases, vous pouvez choisir d’utiliser une sauvegarde récente ou d’en faire une nouvelle. Pour de grandes bases de données, il est plus pratique d’utiliser une sauvegarde existante. Toutefois, tous les journaux de transactions survenus depuis cette sauvegarde doivent résider dans le file share du journal de transactions du serveur primaire, dans le style de nommage correct, afin que le wizard puisse les copier et les restaurer sur le serveur secondaire. Pour des bases de données plus petites, il est plus simple de laisser le wizard générer la sauvegarde.
Sur l’écran Log Shipping Schedules, vous définissez la fréquence des sauvegardes des journaux de transactions pour la base de données source et des jobs de copie et de chargement SQL Agent que le wizard crée sur le serveur secondaire. Les fréquences de log shipping peuvent aller jusqu’à une fois par minute, mais une fois toutes les 5 minutes est un choix plus courant pour de grandes bases de données.
L’écran Log Shipping Thresholds présente des options pour définir les temps de latence acceptables pour les jobs de sauvegarde, copie et restauration des journaux de transactions. Quand les limites de temps sont dépassées, la boîte de dialogue Log Shipping Monitor sur le serveur moniteur déclenche une alerte.
En parlant du serveur moniteur, l’écran suivant, Specify Log Shipping Monitor Server Information, permet de préciser quel serveur utiliser comme serveur moniteur. Attention : vous pourriez être tenté d’accepter simplement la proposition par défaut, mais c’est souvent le serveur primaire. Il est déconseillé d’utiliser le serveur primaire ou secondaire comme un serveur moniteur parce que vous ne pourrez pas déterminer l’état courant du log shipping si l’un de ces serveurs devient indisponible.
Après quelques écrans de reporting, le dernier écran du wizard permet de choisir un nom de plan. Par souci de clarté, il est bon que les deux mots log shipping figurent dans ce nom. Il vaut mieux ne pas inclure les noms de serveurs dans le nom du plan si vous voulez effectuer un futur changement de rôles des serveurs. Cliquez sur Finish. Le wizard installe automatiquement le log shipping du serveur primaire sur le serveur secondaire et met en place le Log Shipping Monitor sur le serveur moniteur.
Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.
