Client Windows

rsync est à la base un programme unix. Pour fonctionner sous Windows, il utilise les librairies Cygwin qui traduisent les concepts natifs en leurs équivalents Unix. Cette traduction n’est toutefois pas parfaite, car il n’y a pas de correspondance exacte entre les deux systèmes.

Effectuer une sauvegarde aussi exacte que possible des données d’un client Windows (y compris propriétaires, groupes et permissions) est certainement possible, mais impose un certain nombre de contraintes :

• les extended attributes doivent être activés côté serveur

• activer l’option « fake super » côté serveur afin de stocker dans des extended attributes les valeurs NTFS qui n’ont pas d’équivalent unix (uid plus grands, ACLs )

• la restauration des ACLs ne peut avoir lieu que via rsync car il est le seul à pouvoir interpréter les données qu’il a stockées sous forme d’extended attributes

• côté client rsync doit pouvoir accéder aux fichiers /etc/passwd et /etc/group, situés dans le répertoire d’installation de cygwin, ce qui nous interdit d’avoir un client intégralement situé dans son propre répertoire

Même alors il n’est pas certain que rsync seul suffise à la tâche (je ne suis pas assez versé dans les subtilités de NTFS pour le vérifier par moi-même), et nombre d’articles sur la toile suggèrent l’utilisation d’outils comme SetACL pour sauvegarder les ACLs séparément des données. Inutile de dire que dans ce cas la restauration n’est plus à la portée d’un utilisateur lambda.

Nous irons donc à la solution la plus simple, largement suffisante dans le cadre de la sauvegarde d’un réseau domestique, qui consiste à ne sauvegarder que les données. Si un lecteur parvient à une solution plus complète, je serai ravi qu’il m’en fasse part dans les commentaires !

Installation de SSH et rsync pour Windows

La méthode la plus simple pour obtenir les programmes et librairies nécessaires consiste à installer Cygwin, puis à recopier dans un répertoire séparé les fichiers qui nous intéressent. On pourra ensuite supprimer Cygwin et ne conserver ainsi que les fichiers indispensables qui pourront être utilisés sur toutes les machines que l’on désire sauvegarder.

Télécharger et exécuter le programme d’installation de Cygwin. Sélectionner uniquement les packages openssh et rsync, puis lancer l’installation. Par défaut les fichiers sont installés dans C:\Cygwin. Copier les programmes rsync.exe et ssh.exe situés dans le répertoire C:\Cygwin\bin vers C:\btrbackup. Si vous tentez de les exécuter depuis ce nouveau répertoire, un message d’erreur apparaîtra, indiquant qu’il manque des librairies. Copiez alors ces dernières depuis C:\Cygwin\lib vers C:\btrbackup, puis recommencez l’opération jusqu’à ce que rsync.exe et ssh.exe s’exécutent sans erreur.

Vous pouvez à présent supprimer Cygwin de votre système.

Sauvegarde : première tentative

Tentons maintenant de lancer un script de sauvegarde équivalent à celui que nous avons utilisé pour le client Linux. Outre le fait qu’il sera écrit en batch plutôt qu’en shell, deux différences sont à noter.

Tout d’abord, les librairies Cygwin sur lesquelles repose rsync modifient la syntaxe des noms de fichiers pour les rendre Unix-compatibles. Ainsi les lettres représentant les lecteurs de disques apparaissent sous la forme de sous-répertoires de /cygdrive. Si l’on désire sauvegarder le dossier C:\Users (équivalent à /home sous Linux), il faudra donc donner en argument à rsync le chemin /cygdrive/c/Users.

Ensuite, les options de la commande rsync seront plus simples. Souvenons nous que -a équivaut à -rlptgoD. Si l’on retire comme on l’a vu les options qui préservent le propriétaire (-o), le groupe (-g), les permissions (-p) et les fichiers spéciaux (-D), il nous reste -rlt.

La syntaxe de base pour Windows devient donc :
rsync -e "ssh -l mon_user -p 222 -i ma_clé" -rlt --inplace --delete --exclude "/cygdrive/lecteur/toto/tmp/**" --delete-excluded -v --stats /cygdrive/lecteur/toto server::backup

Après avoir copié depuis le serveur la clé SSH privée client2_sshkey correspondant à notre client Windows, créons donc dans notre répertoire C:\btrbackup le script suivant :

btrbackup-client2.cmd :

rsync -e "ssh -l client2 -p 222 -i client2_sshkey" -rlt --inplace --delete --exclude **/Temporary?Internet?Files/* --exclude **/Cache/* --exclude **/cache/* --exclude **/Temp/* --delete-excluded -v --stats /cygdrive/c/Users server::backup

if ERRORLEVEL 1 goto KO
rsync -e "ssh -l client2 -p 222 -i client2_sshkey" server::backup/bogus .
echo Success
goto END
:KO
echo Failure!
:END

Exécutez ce script avec les droits Administrateur (vous sauvegardez les fichiers de tous les utilisateurs, pas seulement les vôtres) depuis le répertoire C:\btrbackup. Malgré ses privilèges élevés, le script n’ira pas jusqu’au déclenchement des snapshots car le premier rsync aura renvoyé un certain nombre d’erreurs à propos de fichiers impossibles à lire. Que se passe-t-il ?

Fichiers verrouillés et VSS

Lorsqu’un fichier est utilisé par une application, Windows pose un verrou dessus, ce qui le rend inaccessible aux autres programmes ne serait-ce qu’en lecture. Certains fichiers sont ouverts dès que leur propriétaire est connecté, comme NTUSER.DAT qui contient la base de registre spécifique à cet utilisateur. C’est aussi souvent le cas des fichiers *.pst contenant les emails d’Outlook, qui ne peuvent ainsi plus être sauvegardés dès lors que l’utilisateur a ouvert sa messagerie.

Dans sa grande sagesse, Microsoft a toutefois prévu un moyen de sauvegarder ces fichiers verrouillés via le service VSS (Volume Snapshot Service ou Volume Shadow Copy Service). Le principe consiste à prendre un snapshot des fichiers au niveau NTFS. Cette copie des fichiers n’est pas verrouillée et se trouve donc accessible en lecture. Pour rendre justice à Microsoft, ajoutons que ce service est bien pensé : si un fichier est ouvert en écriture par une application, rien ne garantit que son contenu est consistant au moment où un programme tiers tente de le lire. Le service VSS va signaler aux applications concernées qu’un snapshot va être fait de leurs données et qu’elles doivent mettre leurs fichiers sur disque dans un état consistant pour que le snapshot soit cohérent. Ce système introduit une certaine complexité, mais apporte également une sécurité absente sous Linux et Unix en général…

Nous allons donc devoir préalablement à notre sauvegarde rsync effectuer un snapshot VSS de nos données. Microsoft a mis à disposition au fil du temps un certain nombre d’outils pour gérer VSS en ligne de commande. Malheureusement, le nom et la syntaxe de ces outils a changé avec chaque nouvelle version de Windows. J’ai préféré opter pour une solution plus universelle : ShadowSpawn, qui a l’intérêt de fonctionner sur toutes les versions de Windows et de simplifier ainsi dramatiquement nos scripts.

ShadowSpawn va créer un snapshot VSS du lecteur ou répertoire qu’on lui donnera en argument, puis rendra ce snapshot accessible sous la forme d’un nouveau lecteur disque. Enfin, il exécutera un programme (dans notre cas la sauvegarde rsync) et lorsque celui-ci sera terminé, fera le ménage derrière lui en supprimant le lecteur disque et en libérant le snapshot. Les droits Administrateur seront cette fois absolument nécessaires à l’exécution de la sauvegarde car un simple utilisateur n’a pas les privilèges suffisants pour créer des snapshots.

On utilisera donc non pas un mais deux scripts.

btrbackup.cmd :

@echo off

set mapdrive=B
ShadowSpawn C:\ %mapdrive%: rsync-backup.cmd /cygdrive/%mapdrive%/Users

Ce premier script lance ShadowSpawn de manière à ce qu’il crée un snapshot de l’intégralité du lecteur C: auquel on accèdera par un nouveau lecteur (B:). J’ai choisi B: parce qu’il a le double intérêt d’être l’initiale du mot Backup et d’être inutilisé sur la plupart des ordinateurs (qui possède encore un lecteur de disquettes ?). Le lecteur perfectionniste aura a coeur de trouver un moyen de déterminer automatiquement une lettre de lecteur disponible pour le cas peu probable où B: poserait un problème… Une fois le snapshot affecté au nouveau lecteur, le second script est exécuté avec en argument le nom du répertoire à sauvegarder tel qu’il apparaît sous ce lecteur.

rsync-backup.cmd :

@echo off

REM Add the directory where rsync, ssh and needed libraries reside to the PATH
REM We just use %~dp0 (PATH to the excuting script) as everything is here
SET PATH=%~dp0;%PATH%

REM Set CYGWIN variable to 'nontsec'. That makes sure that permissions
REM on your Windows machine are not updated as a side effect of cygwin
REM operations.
SET CYGWIN=nontsec

REM Set HOME variable to your windows home directory. That makes sure
REM that ssh command creates known_hosts in a directory you have access.
SET HOME=%HOMEDRIVE%%HOMEPATH%

REM Change to the directory containing our script (short paths everywhere!)
pushd "%~dp0"

rsync -e "ssh -l client2 -p 222 -i client2_sshkey" -rlt --inplace --delete --exclude **/Temporary?Internet?Files/* --exclude **/Cache/* --exclude **/cache/* --exclude **/Temp/* --delete-excluded -v --stats %1 server::backup
REM Test rsync return code
if ERRORLEVEL 1 GOTO NOK

echo Synchronization successful
rsync -e "ssh -l client2 -p 222 -i client2_sshkey" server::backup/bogus .
goto END

:NOK
echo An error occured during the synchronization
echo The return code is %ERRORLEVEL%

:END
REM Change back to the original directory
popd

Exécutez le script btrbackup.cmd en tant qu’Administrateur depuis le dossier C:\btrbackup. Cette fois tout devrait bien se passer !

Il ne reste plus qu’à créer une nouvelle tâche dans le planificateur de tâches de Windows pour exécuter notre sauvegarde à intervalles réguliers. Les points importants dans les paramètres de la tâche sont :

• Exécuter avec les droits maximaux (Administrateur)
• Exécuter dans le dossier C:\btrbackup
• Si l’on désire récupérer dans un fichier de log le résultat de l’exécution des scripts, la tâche à exécuter doit être cmd.exe avec l’option /C et en argument le script btrbackup.cmd. Cela permet d’utiliser la redirection de la sortie standard et des erreurs vers un fichier.

Restauration

Il reste à trouver un moyen de rendre nos sauvegardes facilement accessibles depuis notre poste Windows, autrement dit trouver un client SFTP qui soit complètement intégré au système et sache se faire oublier.

Il est bien entendu toujours possible d’accéder aux sauvegardes à l’aide de WinSCP ou FileZilla, qui supportent SFTP, mais pour une approche plus native l’idéal est de faire apparaître le répertoire du serveur contenant les sauvegardes sous la forme d’un lecteur réseau avec l’un des outils suivants :

• Dokan sshfs : open source, mais requiert .NET entre autres dépendances
• Expandrive (ex sftpdrive) : payant. L’usage de clés SSH nécessite de passer par Pageant
• Swish : open source, requiert Pageant pour les clés SSH. Intégration sous forme d’une extension de l’explorateur Windows
• SFTP Net Drive : non open source (mais presque !) Pas besoin de Pageant pour les clés SSH, gratuit pour une utilisation personnelle

Ma préférence va à SFTP Net Drive, car il est très simple à mettre en oeuvre. Après téléchargement et installation, voici comment le configurer :

Quelques paramètres sont à changer dans la partie Server Settings :

• désactiver le timeout
• changer le jeu de caractères en UTF-8 (rsync traduit le jeu de caractères natif de Windows en UTF-8 lors de la sauvegarde, c’est donc celui qu’il faut utiliser pour les relire)
• utiliser la racine du serveur SFTP comme racine du lecteur
• désactiver l’ouverture automatique du dossier à la connexion

Cliquer ensuite sur Connect et valider la clé du serveur :

Un nouveau lecteur (R:) est créé, qu’il ne nous reste qu’à ouvrir pour accéder à nos sauvegardes :

Ce lecteur est reconnecté automatiquement au démarrage de Windows, ce qui signifie que l’utilisateur du poste a un accès simple et pernanent à l’ensemble de ses sauvegardes. CQFD !