Introduction

Lors de la création d’une base de données SQL Server 2008 on peut choisir le mode de récupération à appliquer pour cette base de données. Ce choix ne doit pas être fait au hasard mais il doit répondre aux besoins de l’entreprise en termes de stratégie de sauvegarde et de récupération.

Types de sauvegardes

SQL Server 2008 offre une multitude de types de sauvegarde pour une base de données sauf que ces types de sauvegarde dépendent du mode de récupération choisi pour celle-ci.

Les types de sauvegarde qu’on peut réaliser sur une base de données sont :

1. Sauvegarde de données
2. Sauvegarde des journaux de transactions
3. Sauvegarde de type copie seule

L’étendu d’une sauvegarde peut être soit une base de données complète, une base de données partielle ou un ensemble de fichiers ou groupes de fichiers. Pour chacun de ces étendues on peut faire soit des sauvegardes complètes soit des sauvegardes différentielles.

Une sauvegarde différentielle dépend de la dernière sauvegarde complète réalisée avant celle-ci, la perte de la sauvegarde complète implique la perte de toutes les sauvegardes différentielles réalisées après.

Chaque sauvegarde de base de données contient la portion du journal de transaction qui permet de remettre la base de données à la fin de l’opération de sauvegarde.

Une sauvegarde de type copie seule (Copy Only) nous permet de réaliser des sauvegardes sans affecter la stratégie de sauvegarde mise en place, ce qui veut dire qu’une sauvegarde en copie seule même si c’est une sauvegarde complète n’affecte pas le chainage entre les sauvegardes différentielles réalisées après celle-ci et la sauvegarde complète normale réalisée avant elle.

Mode de récupération

Si le mode de récupération d’une base de données est Simple, la sauvegarde des journaux de transaction est désactivée pour celle-ci, en effet SQL Server prendra en charge la gestion des fichiers journaux et à chaque point de contrôle les parties inactives du journal seront tronquées.

Le mode de récupération Journalisé en bloc est un mode complémentaire au mode complet qui permet d’optimiser les opérations en bloc mais n’offre pas le même niveau de protection que le mode complet, en effet ce mode ne prend pas en charge la récupération de la base de données à une date et heure précise.

Meilleures pratiques

• Choisir le mode de récupération Simple pour les bases de données de développement et de test
• Si votre base de données est configurée avec un mode de récupération complet ou journalisé en bloc il ne faut pas oublier de réaliser des sauvegardes des journaux de transaction.
• Une sauvegarde différentielle d’une base de données contient toutes les pages de données modifiées depuis la dernière sauvegarde complète, sans la sauvegarde complète de référence une sauvegarde différentielle ne peut pas être restaurée ; dans le cas où on met en place une stratégie de sauvegarde à base de sauvegarde complète et différentielles il faut bien faire attention à ne pas perdre la sauvegarde complète.
• L’application d’une mise à jour ou d’un patch de sécurité qui change le numéro de version de votre serveur SQL doit être suivi immédiatement d’une sauvegarde des bases de données système, en fait les anciennes sauvegardes seront obsolètes dans ce cas.

L’optimisation des performances des serveurs SQL Server passe obligatoirement par la mise en place d’une infrastructure de stockage adéquate. Les consignes suivantes permettent d’améliorer les performances de vos serveurs de bases de données SQL Server.

1. Placer les fichiers de données, les fichiers journaux et la base de données TempDB sur des disques dédiés
2. Aligner les partitions de vos disques (Windows Server 2003 et antérieurs)
3. Aligner le nombre de fichiers de données de vos bases de données et principalement la base de données TempDB au nombre de processeurs du serveur.
4. Formater les disques qui hébergent les fichiers de données avec une taille de cluster adéquate (8, 16, 32 ou 64 Ko), le choix de la taille doit se faire suite à une analyse et des tests qui prendront en compte le contexte d’exploitation de votre base de données et les caractéristiques techniques de votre équipement de stockage.
5. Favoriser les systèmes RAID 1+0 pour les disques qui hébergeront les journaux de transaction et la base de données TempDB
6. Planifier convenablement la taille des fichiers de données, des fichiers journaux ainsi que la taille des fichiers de la base de données TempDB.

Si une base de données est configurée en mode de récupération complet, son journal de transaction ne sera tronqué que suite à la sauvegarde de celui-ci. La réalisation d’un grand nombre de transactions volumineuse peut augmenter indéfiniment la taille du journal des transactions ce qui impliquera un suivi permanent et une charge administratif en plus.

Avec les alertes et les travaux SQL Server on peut automatiser les tâches de sauvegarde du journal de transactions afin d’éviter que le disque hébergeant le journal ne soit rempli.

Pour cela il faudra procéder comme suit :

Créer une unité de sauvegarde

Depuis l’explorateur des objets, développer Server Objects puis cliquer avec le bouton droit de la souris sur Backup Devices et cliquer sur New Backup Device.

Donnez un nom et préciser le chemin du fichier à utiliser pour votre unité de sauvegarde

Cliquer sur Ok

Créer un opérateur pour recevoir les notifications

Créez un opérateur en cliquant sur New Operator

Précisez le nom de l’opérateur, son adresse email si vous voulez utiliser la notification par messagerie électronique et le nom de sa machine en cas de notification par message console.

Cliquer sur Ok

Créer un travail de sauvegarde du journal de transaction

Créer un nouveau Travail en cliquant sur New Job…

Au niveau de l’onglet Général tapez le nom du travail et ensuite passez à l’onglet Etapes.

Créer une étape de Type Script Transact-SQL (T-SQL) avec le script BACKUP LOG NomBase TO BackupDevice avec BackupDevice le nom de l’unité de sauvegarde crée auparavant.

Au niveau de l’onglet Notification choisissez l’opérateur qui doit recevoir une notification et quand.

Créer une alerte relative au compteur de performance (Pourcentage du journal utilisé)

Créez une alerte en cliquant sur New Alerte

Au niveau de l’onglet Général donner un nom à votre alerte de type Alerte de condition de performance SQL Server et configurez la comme illustré au niveau de l’image

Au niveau de l’onglet Réponse choisissez l’exécution du Job de sauvegarde comme réponse et cochez le mode de notification à utiliser.

La configuration de cette alerte qui déclenche le travail de sauvegarde permettra d’éviter que les disques soient remplis et que les journaux de transactions ne grandissent indéfiniment.

Eh bien, il vous est déjà arrivé, en tant qu’utilisateur Outlook d’avoir un message du type :

Pendant l’apparition de ce message, si vous n’êtes pas en mode cache, Outlook ne répond pas.

Le client interroge le client régulièrement le serveur pour avoir des modifications, comme par exemple l’arrivée d’un nouveau message.

Ce message est généré par une requête du client vers le serveur Exchange. Et si au bout de 5 seconds, la réponse ne parvient pas au client, ce fameux message s’affiche.

Le Wrapper est le process générateur de ce message.

Dans les anciennes versions d’Exchange, il y avait des plantages des clients Outlook de manière intempestive et non expliquée. Les développeurs ont donc ajouté ce message de manière à distinguer un plantage lié au fonctionnement d’Outlook d’un autre plantage.

C’est un moyen de debug.

Les causes d’apparition de ce message peuvent être nombreuses. Il peut s’agit :

· Des problèmes liés à l’accès à Exchange à l’Active Directory (DSAccess)

· Des problèmes réseaux

· Des problèmes d’accès aux dossiers Freebusy pour les versions antérieures à Exchange 2007.

Pour plus d’information, merci de se référer à la Kb suivante :

http://support.microsoft.com/kb/892764/fr

Voici le schéma des principaux flux induits par l’utilisation d’Enterprise Vault

L’offline Vaut est la fonction qui permet de disposer de tout ou partie des archives Enterprise Vault en local sur un poste de travail, à des fins d’utilisation en mode déconnecté.

La localisation par défaut du cache est dans le profil utilisateur :

C:\Document and settings\%username%\local settings\application Data\KVS\Enterprise Vault\id du cache\

Le mécanisme peut globalement être présenté comme suivant :

Pour bénéficier de l’Offline Vault, le cache Exchange doit, au préalable être configuré (.ost).

En fonction des raccourcis contenus dans le fichier ost, le client Enterprise Vault fait une demande au serveur pour le téléchargement des archives correspondantes.

Voici le contenu du cache Enterprise Vault :

■ Les fichiers db : ce sont les fichiers qui contiennent les archives.

■ downloadTask.xml : fichier contenant la liste des éléments à télécharger dans le cache

■ oae_l*.xml : fichier qui répertorie les noms des dossiers et leur arborescence

■ oae_c*.xml : fichier qui présente la vue des archives dans l’explorateur des archives

■ storeIDMap.xml : fichier de paramètres de l’Offline Vault

Mécanisme de fonctionnement

L’Offline Vault est un ensemble de fichier au format db localisé sur le poste de travail. Ces fichiers sont par défaut dans le profil utilisateur à l’emplacement suivant :

Pour activer l’Offline Vault d’Enterprise Vault se base sur le contenu du cache Outlook pour fonctionner (fichier OST).

■ Enterprise Vault, par le biais du client installé sur le poste, vérifie le contenu du fichier Ost d’Outlook pour identifier les nouveaux raccourcis, donc des éléments éligibles au titre de l’Offline Vault. Sont identifiés lors de cette opération les noms des dossiers contenant les raccourcis et leur hiérarchie de manière à faire la mise à jour de l’Explorateur des archives, seul moyen de recherche des archives en mode déconnecté, les fonctions de recherche habituelles étant non opérationnelles.

Cette opération génère une fenêtre de mise à jour de l’explorateur des archives

Cette opération est généralement longue. Elle fait, en effet, la mise à jour des différents fichiers XML, enregistre les modifications de la boîte aux lettres depuis le dernier téléchargement. Etant donné qu’elle ne se produit qu’au lancement d’Outlook le matin, elle fait un point précis de la boîte aux lettres depuis 24 heures.

■ Le téléchargement se lance à la fin de la fenêtre précédente. Elle se manifeste habituellement par une 2^e fenêtre qui peut ne pas être vue si le volume des données à synchroniser n’est pas très important.

Durant les phases de POC ou de pilote il peut s'avérer intéressant de générer des messages reconnus comme étant des SPAM par Brightmail.

Cela permet notamment de valider le bon fonctionnement des règles antispam et/ou des règles de conformité positionnées dans l'environnement du client.

Pour cela il est tout à fait possible d'envoyer un email contenant dans l'objet ou dans le corps du message quelques mots ou expressions savamment choisies.

Il est également possible d'utiliser un en-tête SMTP prévu à cet effet dans le moteur antispam des Appliances SBG !

L'astuce consiste à ajouter l'expression X-Advertisement:spam lorsque vous envoyez un email de test sur une invite de commande en telnet (NB : Cette expression doit être saisie après la commande DATA).

Dans l'exemple ci-dessus, l'email est bel et bien reconnu comme SPAM et l'action prise consiste à modifier l'objet du message, puis à envoyer le message dans la quarantaine.

Ce tips est tiré de la note technique suivante :

Testing mail flow and spam detection in Symantec Brightmail products and Symantec Mail Security appliances.

Introduction

Les boitiers Symantec Brightmail Gateway (anciennement SMS 8300) sont des Appliances antispam et antivirus commercialisées par Symantec. Ces Appliances sont également capables d'appliquer des règles de conformité voir de s'intégrer à des solutions DLP.

On distingue plusieurs types de mises à jour sur les boitiers SBG :

• Les mises à jour des définitions antispam sont appliquées automatiquement par le service Conduit (les mises à jour ont lieu toutes les 10 minutes environ)
• Les mises à jour des définitions antivirus sont appliquées automatiquement par le service LiveUpdate en fonction de la planification définie par l'administrateur
• Les mises à jour du logiciel (software) qui sont appliquées manuellement à l'initiative de l'administrateur

C'est bien entendu la troisième catégorie qui nous intéresse ici ! Symantec ne fournit par de roadmap publique précise en ce qui concerne les mises à jour du logiciel. Néanmoins on peut considérer que des mises à jour mineures sont disponibles de manière trimestrielle et que des mises à jour majeures sont effectuées tous les 1 à 2 ans.

A titre informatif, voici la liste des mises à jour du software de ces deux dernières années en ordre chronologique :

• Août 2007 - 7.5
• Mars 2008 - 7.6.1-7
• Août 2008 - 7.6.1-14
• Septembre 2008 - 7.7.0-17
• Janvier 2009 - 8.0.0-24
• Mars 2009 - 8.0.1
• Mai 2009 - 8.0.2
• Octobre 2009 - 8.0.3  

Pour être averti instantanément lors de la disponibilité d'une nouvelle version du logiciel, le plus simple reste d'utiliser les alertes par emails intégrées au sein du produit (cf. capture d'écran ci-dessous).

Les Best Practices

Voici les best practices en ce qui concerne les mises à jour du logiciel d'une Appliance Symantec Brightmail Gateway :

• Effectuer une sauvegarde de la configuration du "control center"
• Vérifier que le "control center" n'est pas en train d'effectuer une synchronisation avec un serveur d'annuaire
• Vérifier que les "scanner" ne sont pas en train d'effectuer une réplication des données LDAP à partir du "control center"
• Configurer la pile MTA des boitiers "scanner" sur "Do not accept incoming messages"
• Mettre à jour les boitiers "scanner" avec le "control center"

Procédure

Pour lancer la mise à jour d'une Appliance via l'interface Web, il faut suivre la procédure suivante :

1. Cliquer sur Version dans l'onglet Administration
2. Aller dans l'onglet Updates

Il faut ensuite sélectionner la mise à jour, afficher la description (les "release notes"), puis cliquer sur le bouton Update.

L'interface Web affiche ensuite la barre de progression ci-dessous :

Aucune précision supplémentaire n'est ensuite affichée dans l'interface Web. Pour suivre de manière plus précise les différentes étapes de l'installation (téléchargement des différents modules, installation...), il faut se connecter en SSH sur l'Appliance avec un client tel que putty et utiliser la commande watch update.log (cf. capture d'écran ci-dessous).

A l'issue de l'installation, il est possible de vérifier la version installée sur le boitier à l'aide de la commande version.

En configurant le service DNS de Windows Server 2008 R2, j’ai détecté une anomalie assez étonnante : les adresses IP des serveurs DNS racines B.root-servers.net et L.root-servers.net sont erronées dans la configuration du DNS de Windows Server 2008 R2 !

En effet, on nous indique les adresses IP suivantes :

• Pour le serveur B.root-servers.net : 128.9.0.107 dans la configuration du service DNS Windows Server contre 192.228.79.201 sur le site http://www.root-servers.org/
• Pour le serveur L.root-servers.net : 198.32.64.12 dans la configuration du service DNS Windows Server contre 199.7.83.42 sur le site http://www.root-servers.org/

En ce qui concerne le serveur « L » appartenant à l’ICANN, on peut retrouver sur leur site un billet indiquant à tous les opérateurs de services DNS de mettre à jour l’adresse IP avant la date de la bascule prévue le 1er novembre 2007…

• http://blog.icann.org/2007/10/advisory-%e2%80%94-l-root-changing-ip-address-on-1st-november/

La liste des nouvelles adresses IP est aussi consultables sur le site de l’Internic (ftp://rs.internic.net/domain/named.root).

La liste des « root hints » de Windows Server 2008, Windows Server 2003 R2 et des versions précédentes semble également touchée.

Symptôme

Lors de l'installation d'Exchange 2010 sous Windows Server 2008 R2 ou Windows Server 2008 x64 SP2, le message d'erreur suivant peut apparaître :

De plus l'évènement suivant est enregistré dans le journal "Application" du serveur :

Event ID : 1002
Source : MSExchangeSetup
Task Category : Microsoft Exchange Setup
Level : Error
Error : The following error was generated when "$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }" was run: "Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.".
Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.

Explication

Cette erreur indique que le service de transport Hub s'est bien installé mais qu'il n'arrive pas à démarrer.

Cette erreur apparaît lorsque le service IPv6 est désactivé au niveau de la carte réseau mais pas au niveau du système.

Résolution :

Pour résoudre le problème deux options sont envisageables :

• Réactiver l'IPv6
• Désactiver l'IPv6 au niveau du système en créant une clé de registre

Cette clé doit être créée avec les paramètres suivants :

• Ruche : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
• Type de clé : DWORD (32 bits)
• Nom de la clé : DisabledComponents
• Valeur de la clé : 0xffffffff hex (4294967295)

Suite à cela les services de transport Hub d'Exchange 2010 acceptent de démarrer. Cette solution est tirée de l'article 952842 de la base de connaissance Microsoft (cette KB n'est pour le moment validée que pour Exchange Server 2007).

http://support.microsoft.com/kb/952842/en-us