Dans cet article je vais traiter d’un problème vieux comme Exchange 5.5 
…il s’agit de la gestion des logs et plus précisément du problème d’espace disque qu’ils peuvent poser en cas de dysfonctionnement de la sauvegarde.
Si la sauvegarde se déroule correctement, les logs sont supprimés après chaque sauvegarde complète ou incrémentielle. Les logs ne sont pas supprimés après une copie ou une sauvegarde différentielle.
Dans le cas où la sauvegarde ne se déroule pas correctement, les logs ne sont pas supprimés et ils peuvent prendre toute la place au point de saturer le disque. Les bases sont alors démontées et il n’y a plus de messagerie… se pose la question des logs : que faire ? supprimer tous les logs ? Seulement quelques logs ? les déplacer ?
Tout d’abord petite explication sur le fonctionnement des logs dans Exchange.
Les logs sont là pour enregistrer dans la base Exchange toutes les modifications (transaction) : envoi d’un email par exemple. Tous les fichiers de logs ont la même taille : 5Mo pour Exchange 2000/2003 et 1Mo depuis Exchange 2007. Dans le cas d’un envoi d’un email l’information est stockée dans un fichier de log (un fichier texte) avant d’être enregistrée dans la base Exchange (base de type ESE). Or si les services Exchange s’arrêtent de manière inattendu (par manque d’espace disque par exemple) Exchange n’a pas eu le temps d’enregistrer tous les logs dans ses bases…Il n’est donc pas question de supprimer tous les logs sans discernement !! Il faut différencier précisément les logs qui peuvent être supprimés pour gagner de l’espace disque, des logs qui sont indispensables à la reprise des bases (le montage des bases).
Nous allons voir comment récupérer cette information cruciale.
Je vais prendre un cas concret : Une infrastructure où les services Exchange 2007 SP1 ne fonctionne plus. L’administrateur constate que les disques sont remplis à 100% à cause des logs. On peut penser que le serveur à crashé lamentablement…donc les bases doivent être en état “dirty shutdown”…Comment procéder ?
Et bien c’est très simple et très rapide : il faut lancer ESEUTIL avec les options permettant de récupérer les informations pertinentes, à savoir eseutil /MH :
Pour mémoire l’utilitaire ESEUTIL se trouve dans le répertoire \Bin d’Exchange.
La commande renvoi des informations très utiles. La ligne qui nous intéresse ici est celle qui se nomme “Log Required” :
Il y a deux possibilités, soit la base est dans un état inconsistant (il y a de forte chance), soit la base est dans un état consistant (vous êtes chanceux !).
- La base est dans un état inconsistant (arrêt non propre) : la ligne State est en état “Dirty Shutdown”.
La ligne Log Required renvoi l’information suivante : 368-377 (0×170-0×179)
Kesako ?? et bien c’est la réponse à notre problème !
Un état inconsistant (dirty shutdown) signifie que certains logs n’ont pas été enregistrés dans la base. Si vous supprimez tous les logs, y compris les logs qui ne sont pas encore enregistrés, Exchange ne pourra pas redémarrer (remonter les bases). Il vous faudra passer par une réparation, donc une perte de données… à éviter.
La ligne Log Required (que l’on pourrait traduire par logs en attente) indique précisément quels sont les logs qui ne sont pas enregistrés. L’information est donnée sous forme décimal et hexadécimal (uniquement depuis Exchange 2007 SP1). Ici le serveur Exchange est en attente des logs 368 à 377, ou formulé de manière hexadécimal des logs 0×170 à 0×179.
Dans les deux cas on arrive bien au même nombre de logs (neuf), ouf
Après avoir récupérer cette information il faut aller dans le répertoire des logs :
Nous retrouvons bien nos neuf logs qui ne sont pas encore enregistrés en base. Maintenant nous pouvons déplacer en toute sécurité tous les autres logs, à l’exception de ces neuf fichiers, du log courant (Enn.log) et du checkpoint (.chk). Simple
Et concernant l’état des bases me direz vous ? Et bien lors du remontage le processus de restauration va automatiquement se lancer pour enregistrer les logs manquant. Le processus est transparent. Encore une fois cela fonctionne uniquement grâce à la présence des logs indispensables au montage ! Si votre base est dans un étant inconsistant et que les logs requis sont absent il faudra réparer les bases (avec ESEUTIL ou ISINTEG).
Si je reprend mon serveur Exchange et que je monte les bases, tout ce déroule correctement. Si je relance ESEUTL /MH je constate que la base est bien en état consistant ! Vous voyez que la ligne Log Required est à zéro, donc tous mes logs sont bien enregistrés en base
En allant dans le journal système on constate des événements de source ESE et d’ID 301 :
On retrouve nos logs 0×170 à 0×179 !
- La base est dans un état consistant : la ligne State est en état “Clean Shutdown”
Dans ce cas, tous les logs sont enregistrés en base, vous pouvez déplacer (au pire supprimer) tous les logs, toujours à l’exception du log en cours (Enn.log) et du fichier de chekpoint (Enn.chk).
Voilà j’espère avoir était clair. Et surveillez le bon déroulement de vos sauvegardes !
