Pour vérifier qu’un répertoire situé sur deux serveurs utilisant la réplication DFS sous Windows 2003 R2 est correctement synchronisé, il faut ouvrir une fenêtre DOS et entrer la commande :

dfsrdiag backlog /receivingmember:filer1 /sendingmember:filer2 /rfname:"Comptabilité" /rgname:"corp.local\docs\Comptabilité"

receivingmember correspond au serveur recevant les fichiers à synchroniser, sendingmember à celui qui les envoit, rfname le nom du répertoire à synchroniser et rgname le nom complet du répertoire DFS.

Si le répertoire est bien synchronisé sur les deux serveurs on obtient le message suivant :

No Backlog – member <filer1> is in sync with partner <filer2>

Operation Succeeded

Dans le cas contraire on obtient le nombre de fichiers en attente de synchronisation et la liste des 100 premiers fichiers en question :

Member <filer2> Backlog File Count: 3
Backlog File Names (first 3 files)
1. File name: Archive_2006.doc
2. File name: Sales_2006.pdf
3. File name: Présentation_Marketing_Paris.ppt

Operation Succeeded

J’utilise deux serveurs Windows 2003 R2 Entreprise avec 1.5 To d’espace disque comme serveurs de fichiers en utilisant le Distributed File System (DFS) et la réplication DFS, ce qui permet de synchroniser les fichiers sur deux serveurs en permanence. De cette manière on augmente les performances ainsi que la tolérance de panne : si un des serveurs tombe en panne, le trafic est redirigé sur le serveur survivant.

En plus de cela j’utilise les Clichés Instantanés (Shadow Copies) pour sauvegarder deux fois par jour les données modifiées sur chaque serveur. Cela permet de conserver jusqu’à 64 versions d’un fichier.

Le problème que j’ai rencontré est que ces Shadow Copies disparaissaient tous les 2-3 jours, ne conservant que la toute dernière sauvegarde. Dans le journal des événements Système j’obtenais une erreur :

Event Type: Error
Event Source: VolSnap
Event Category: None
Event ID: 25
Date: 9/24/2007
Time: 7:01:53 PM
User: N/A
Computer: Filer01
Description:
The shadow copies of volume C: were deleted because the shadow copy storage could not grow in time. Consider reducing the IO load on the system or choose a shadow copy storage volume that is not being shadow copied.

Pour corriger ce problème, il faut ajouter une clé dans la base de registre de chaque serveur présentant ces symptômes : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VolSnap\MinDiffAreaFileSize et lui assigner une valeur qui soit un multiple de 300 dans la limite de 3000. Cela augmente la zone tampon utilisée pour la création des Shadow Copies qui est par défaut de 300 Mo. J’ai pour ma part utilisé une taille de 1800 et depuis je n’ai plus de perte de Shadow Copies.