Mais comme diraient mes amis « perlistes »… « perliens »… « perleurs »…bref… qui parlent Perl courrament  :

« There’s More Than One Way To Do It  » (TIMTOWTDI).

A l’extrême, une autre façon consiste à faire un bon « disk dump - dd » du disque vers un fichier « raw »   (ie par ex : # dd if=/dev/sda of=/chemin/fichier.raw). Ce fichier sera ensuite utilisé comme disque virtuel. Je n’ai jamais testé, mais je ne vois pas pourquoi ça ne fonctionnerait pas, à condition bien sûr, que le serveur d’origine n’intègre pas de matériels trop exotiques. Cependant, un des avantages de la virtualisation, lié à l’allocation dynamique de l’espace de stockage, est perdu. En effet, l’espace disque libre est « dumpé » et occupera de la place sur le serveur final. Paradoxal non ? Même si le procédé pourrait être amélioré en utilisant « partimage », pour gérer un peu mieux l’espace non occupé, il faut bien avouer que ce procédé demeure quelque peu « bourrin ».

Entre les deux, je vous propose d’explorer une piste nommée « Mondo ».

« Mondo Rescue »  est un utilitaire, sous licence GPL, qui permet de créer, sur des supports variés (CD, DVD, bande, montage réseau ou disque dur), une image complète ou partielle d’un système Linux.  A l’instar de Ignite sous HP-UX ou Ghost sous Windows.

Son premier atout, est qu’il s’installe sur le système et permet de créer l’archive à chaud. L’intégralité de la migration pourra se dérouler avec un serveur physique fonctionnel. Ce dernier sera arrêté au dernier moment, quand la machine virtuelle sera capable de prendre le relai.

Son deuxième atout est sa capacité à créer une image « iso » bootable et compressée, dont la fonction est de restaurer notre système en s’adaptant au nouveau matériel. A l’inverse de « dd » ou de « partimage », qui réalisent des copies physiques de blocs du système de fichier, Mondo re-crée le partitionnement mémorisé, y restaure les fichiers sauvegardés et en dernier lieu, réinstalle le « bootloader ».

Avant d’aller plus loin, j’attire votre attention, chers lecteurs, sur le fait que la solution « mondo » n’est pas fiable à 100%.  Il n’est pas rare, dans le cas de partitionnements un peu complexes (basés sur LVM entre autres), que ce dernier s’emmêle les pinceaux et donne envie irresistible de s’arracher les cheveux (pour peu qu’il nous en reste !). Je ne vais pas vous infliger le refrain « je ne suis pas responsable bla bla bla… », mais faites tout de même gaffe en production. Si je devais qualifier cette solution en quelques mots, je dirais qu’elle est performante mais reste assez artisanale. Ceci dit, si je prends la peine d’écrire ce billet, c’est qu’elle présente un intérêt (enfin, j’espère) et qu’elle peut tout de même rendre de fiers services.

Installation

Le site officiel fournit  les paquets pour de nombreuses distributions. Sous Debian, il est, en plus, possible d’utiliser les dépôts :

deb ftp://ftp.mondorescue.org/debian X.0 contrib

ou X est le numéro de version ( 4 pour Etch, 5 pour Lenny, 6 pour Squeeze).

Par exemple, pour l’installer sous Squeeze :

# echo « deb ftp://ftp.mondorescue.org/debian 6.0 contrib »  > /etc/apt/source.list.d/mondo.list

# apt-get update

# apt-get install mondo

 Note pour Squeeze : Mondo utilise les outils mkisofs pour la génération des images iso et cdrecord pour la gravure de CD. Ces outils ont été respectivement remplacés dans Squeeze, par  genisoimage et wodim. Il est possible de s’en sortir (pas très proprement), en créant des liens symboliques :

# ln -s /usr/bin/genisoimage /usr/bin/mkisofs

# ln -s /usr/bin/wodim /usr/bin/cdrecord

Il m’est arrivé de rencontrer quelques problèmes avec « Mindi » . Pour la création du boot de l’image iso, un ramdisk est utilisé, sur lequel on est parfois à l’étroit.  On peut l’augmenter en dé-commentant et en affectant une plus grande valeur au paramètre « EXTRA_SPACE » du  fichier de configuration de « Mindi »   (/etc/mindi/mindi.conf).

Utilisation

Il y a encore « More Than One Way » pour utiliser Mondo. La première se fait par une interface « curses », affichée par défaut, lors de l’exécution de mondoarchive sans paramètre.

La deuxième est bien entendu en ligne de commande :

# mondoarchive -O -p nomarchive -i -I / -d /destination -E /destination -T /temporaire -S /Scratchdir -s taille

• -O : pour créer une archive, par opposition à -V pour une vérification,
• -p nom : pour donner un nom à l’archive ( mondoarchive par défaut),
• -i : pour générer une ou des images iso,
• -I : pour spécifier de départ de l’arborescence à sauvegarder. « / » est par défaut, mais nous pouvons décider de ne sauvegarder qu’un bout de l’arborescence,
• -d : l’emplacement des fichiers finaux (iso),
• -E : Les répertoires à exclure. /tmp, /proc, /sys et les montages médias sont exclus par défaut, il convient, en plus, d’exclure le répertoire destination de l’image,
• -T : Le répertoire temporaire. Par défaut, Mondo choisira la partition disposant du plus grand espace disponible,
• -S   : Le répertoire du scratchdisk, c’est à dire le répertoire dans lequel seront construites les images pour la génération des fichiers iso, comme pour le répertoire temporaire, Mondo choisira par défaut la partition disposant du plus grand espace libre,
• -s : La taille maximale des fichiers iso. Si le but est de graver ces fichiers, il faudra choisir une taille adéquate en fonction du média utilisé  : ~ 700 Mo (700m) pour un CD, ~4.7 Go (4.7g) pour un DVD. Autant d’images que nécessaire seront générées.

Un exemple :

# mondoarchive -O -p serveur1 -i -I / -d /home/joel/mondo -E /home/joel/mondo -s 10g

Les images iso porteront le nom « serveur1-x.iso » (x = numéro incrémentiel) est seront placées dans le répertoire « /home/joel/mondo« . Ce répertoire est exclu de l’archive  et les images ne feront pas plus de 10 Go.

Les autres options sont laissées par défaut.

Ensuite, c’est le moment, tant connu des informaticiens, de laisser bosser la machines et d’aller vaquer à d’autres occupations.

Quelques « occupations » plus tard, l’image générée peut être utilisée pour installer la machine virtuelle, en la transférant sur l’hyperviseur  et en l’utilisant comme CDRom virtuel par exemple.

Au boot et après une détection du nouveau matériel, l’interface propose diverses options, dont l’une est « Automatique » pour une réinstallation à l’identique, une autre, « Manuelle », permet, entre autre, d’aller trifouiller le partitionnement et l’adapter –  Très utile quand la taille de l’espace disque allouée à la VM diffère du disque original.

Les données restaurées et avant l’écriture du secteur d’amorçage, il est possible de prendre la main dans un chroot, afin de vérifier le bon montage des partitions, modifier si nécessaire les fichiers de configuration et si besoin regénérer le initramfs  pour qu’il prenne en compte le nouveau matériel.

Pour terminer, je vous propose d’illustrer cet article par un screencast. Il reprend la migration d’un serveur physique sous Debian Squeeze vers une machine virtuelle Proxmox VE / KVM ( précédent article).

Click here to view the video on YouTube.

Sources :

• Site officiel,
• Wikipedia.

La manipulation décrite ci-dessous est plus un pense-bête qu’un tutoriel ou un article en tant que tel. A le noter quelque part, autant le partager !

Attention : Le changement de type de raid nécessite un reformatage, donc une perte des données de la partition.

1 – Etat des lieux :

# df -h

Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur

/dev/md1              4,9G  216M  4,4G   5% /

tmpfs                 996M     0  996M   0% /lib/init/rw

udev                   10M  152K  9,9M   2% /dev

tmpfs                 996M     0  996M   0% /dev/shm

/dev/md0               92M  9,6M   77M  12% /boot

/dev/md3               20G  632M   18G   4% /home

/dev/md5              3,9G   73M  3,6G   2% /tmp

/dev/md4              9,7G  707M  8,6G   8% /usr

/dev/md2               30G  2,6G   26G  10% /var

/dev/md6               87G  87G    13M 100% /data

# mdadm --detail /dev/md6

/dev/md6:

        Version : 00.90

  Creation Time : Fri Nov 21 16:39:44 2008

     Raid Level : raid1

     Array Size : 91072384 (86.85 GiB 93.26 GB)

  Used Dev Size : 91072384 (86.85 GiB 93.26 GB)

   Raid Devices : 2

  Total Devices : 2

Preferred Minor : 6

    Persistence : Superblock is persistent

    Update Time : Mon Jul 25 13:35:46 2010

          State : clean

 Active Devices : 2

Working Devices : 2

 Failed Devices : 0

  Spare Devices : 0

           UUID : 2656ada4:ef6970c5:bfe78010:bc810f04

         Events : 0.82

    Number   Major   Minor   RaidDevice State

       0       8        9        0      active sync   /dev/sda9

       1       8       25        1      active sync   /dev/sdb9

2 – Destruction / Reconstruction

# mdadm --stop /dev/md6

# mdadm --create /dev/md6 --level=0 --raid-devices=2 /dev/sda9 /dev/sdb9

# mount /dev/md6

Ces deux applications sont très similaires et proposent, entre autre, un espace de stockage en ligne de 2 Go, dans une version de base gratuite, ainsi que des options payantes permettant d’étendre la capacité à 50 Go ou plus. A ce jour, il faut compter un peu moins de 10 € par mois pour 50 Go. Dropbox propose un système de parrainage qui vous fera gagner 250 Mo supplémentaires chaque fois que vous parrainez une nouvel inscrit (dans la limite de 8Go).

Les fichiers sont accessibles depuis n’importe quel ordinateur connecté à Internet via une interface web. Ceci n’est pas pour déplaire à Mamie,  qui se voit rassurée de pouvoir sauvegarder ses précieuses recettes de cuisine à l’abri d’un incendie ou de je ne sais quelle autre catastrophe domestique.

L’installation d’un logiciel client sur un ou plusieurs postes va permettre de synchroniser un répertoire local avec l’espace de stockage en ligne. Ainsi, un fichier ajouté dans ce dossier sera automatiquement ajouté par synchronisation dans l’espace en ligne.  Ce dernier se synchronisera à son tour avec les autres machines sur lequel le client est installé. C’est très pratique pour Mamie, qui peut taper sa recette de cookies au chocolats sur l’ordinateur de son bureau et l’emporter à son club de cuisine sur son Ipad automatiquement synchronisé – Qu’elle frimeuse cette mamie –   Pour cela, je dois préciser qu’elle a une préférence pour DropBox, porté sur de nombreux systèmes, contrairement à Ubuntu One, qui reste encore limité à un environnement Ubuntu.

Image : Dropbox.com

Enfin, parmi les multiples utilisations possibles, nous trouvons bien entendu la possibilité de partager des fichiers ou des dossiers avec d’autres utilisateurs. Très pratique pour Mamie, qui peut diffuser, à toute la famille, les photos de ses pâtisseries qu’elle prend en 10 MégaPixel grâce à son réflex numérique.

Outre la capacité limitée dans les versions gratuites, le fait que les fichiers soient stockés en clair, on ne sais où, peut-être perturbant. Il est bien sûr possible de chiffrer les données avant leur stockage, mais il faut bien avouer que ce n’est pas très pratique.

Sachant que des outils libres, tels qu’ unison, on largement fait leurs preuves en matière de synchronisation, l’idée de construire ma propre architecture « JopaOne » m’a traversé l’esprit. C’est alors que je suis tombé sur le tuto de KIK-IT : UbuntuOne VS MyOne, décrivant exactement ce que je souhaitais faire : Un espace de stockage sur un de mes serveurs et des répertoires locaux sur mes différentes machines, le tout synchronisé grâce à unision,  de préférence à travers ssh…

Pour conclure et je pense que Mamie sera d’accord avec moi, ma préférence va vers DropBox pour le partage de fichiers non sensibles avec les amis. Ce dernier est plus abouti qu’Ubuntu One et bien plus rapide pour  les synchronisation. La disponibilité du client sous de multiples plateforme est un de ses atouts majeurs… Mamie nous fait remarquer que le client « Androïd » est très sympathique pour ajouter son Smartphone

Pour la synchronisation de documents entre mes machines, j’ai préféré une solution basée sur Unison et ssh… Il n’y a pas a dire, on est bien plus tranquille quand les fichiers sont sur un serveur bien à nous…

Liens :

• Ubuntu One
• DropBox
• MyOne (KIK-IT)

Ce sont des choses qui arrivent si on laisse des partitions se remplir un peu tôt ! Ca m’apprendra à surveiller un peu mieux les espaces disque…

J’ai dû remonter un dump de la base, ce qui, outre les désagréments causés et l’indisponibilité du site, permet d’éprouver la technique de sauvegarde. Ça ne fait pas de mal de temps en temps…

Bref, rien de perdu (à part quelques stats de visites…), c’est l’essentiel.

ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.01: cmd a0/00:00:00:00:00/00:00:00:00:00/b0 tag 0
         cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
         res 50/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x2 (HSM violation)
ata2.01: status: { DRDY }
ata2: soft resetting link
.

Bref des choses qui me font dire que le disque dur n’est pas éternel et qu’il a déjà quelques heures de vol (smart me dit environ 3200 heures).

J’ai sur cette machine 2 OS: une Debian dont je me sert quasiment exclusivement et un Windows XP qui me sert à compiler un logiciel développé à l’aide de la bibliothèque Qt.

Pour ce qui est de la Debian, je n’ai pas grand chose à sauvegarder: les sources du logiciel et quelques fichiers de configuration, donc je m’en débrouille très bien. Par contre pour ce qui est de la partition Windows, j’ai mis en place un environnement de compilation qui m’a donné beaucoup de fil à retordre et qui ne serait pas évident à réinstaller même avec les 10 pages de notes que j’avais prises à l’époque.

D’autre part, depuis un bout de temps, j’avais envie de pouvoir m’affranchir du portable, de manière à pouvoir bosser indépendamment de la machine: je trimbale juste une clef usb bootable (une flash de Mandriva par exemple) et je peux m’installer sur n’importe quel PC pourvu qu’il y ait une connexion Internet. De là, je récupère par le réseau ce dont j’ai besoin et pour la « machine à compiler » Windows, je lance un QEMU situé sur un serveur.

Donc y’avait plus qu’à …

Première étape: état des lieux.

- le partitionnement de mon portable est le suivant:

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000aa1b9

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         261     2096451    6  FAT16
/dev/sda2             262        1477     9767520   83  Linux
/dev/sda3            1478        1599      979965   82  Linux swap / Solaris
/dev/sda4            1600       12161    84839265    5  Extended
/dev/sda5            1600       11325    78124063+  83  Linux
/dev/sda6           11326       12161     6715138+   7  HPFS/NTFS
.

On remarquera qu’il y a une partition en FAT16 (je ne sais pas ce qu’elle fait là, ça doit être une partition créée par le constructeur) et la partition qui m’intéresse, la sda6, celle en NTFS. Quand on est sous Windows, on voit 2 partition: la C: (sda1) et la H: (sda6).

Donc, si vous avez suivi, vous savez que c’est la partition sda6 que je veux mettre dans mon QEMU. Je vais donc commencer par copier cette partition dans un fichier à l’aide d’un:

dd if=/dev/sda6 of=sda6.img
.

Ce qui me donne un gros fichier contenant l’image de la partition Windows, qu’en fait, j’avais copié directement sur une autre machine via NFS, mais ça n’a pas d’importance.

Deuxième étape: création de l’image disque.

A l’aide de la commande qemu-img, je crée une image disque de 10 Go:

qemu-img create disque.img 10G
.

Ensuite, le but du jeu étant de transférer l’image de la partition sur le disque, je démarre QEMU avec mon image disque toute neuve comme premier disque dur, l’image disque de la partition comme 2ème disque dur et le CD netinst de Debian (et oui, il faut bien pouvoir booter sur quelque chose):

qemu -hda disque.img -hdb sda6.img -cdrom debian-40r1-i386-netinst.iso -boot d
.

Vous pouvez choisir ce que vous voulez comme CD de démarrage pourvu que vous ayez accès à un shell (alt+F2 avec le CD d’installation de Debian, de préférence une fois que le clavier est configuré et les modules d’installation chargés). On peut maintenant partitionner le disque à l’aide de fdisk.

fdisk /dev/hda
.

Vous créez une nouvelle partition (qui va être hda1) de type NTFS (7) et la rendez bootable (commande a dans fdisk). Faites attention de bien prendre le même nombre de cylindre que la partition originale (et n’oubliez pas qu’il y a toujours un piquet de plus que de pans de clôture), vous devez obtenir exactement le même nombre de blocs que dans le partitionnement original (dans mon cas  6715138 blocs).

Ensuite, il nous faut copier l’image de la partition vers notre nouvelle partition toute neuve, toujours avec dd:

dd if=/dev/hdb of=/dev/hda1
.

Là, vous pouvez aller boire une bière, voire même plusieurs… (vous êtes dans une machine virtuelle et ça se ressent). De plus, si vous êtes dans la même situation que moi (système Windows sur une partition autre que C:) , ça ne fonctionnera pas, on verra après pourquoi.

Troisième étape: on tente de démarrer l’image transférée.

Pour éviter d’avoir à refaire le dd précédent et être obligé d’aller reboire des bières, vous pouvez soit faire une copie de votre nouvelle image disque, soit faire toutes les manips suivantes avec l’option -snapshot de QEMU qui n’écrira pas sur la nouvelle image disque les changements, sauf si vous lui demandez (une fois que tout fonctionne me parait être à un bon moment).

On démarre maintenant la nouvelle image disque avec le CD d’installation de Windows XP, le but étant de recréer le MBR et le chargeur de démarrage. Vous pouvez, soit créer une image iso de votre CD d’installation, soit utiliser directement le périphérique de cdrom de linux avec QEMU. Perso, j’avais déjà l’image iso, donc je l’ai utilisée (non, je n’ai pas lancé un nouveau dd pour la créer de manière à aller boire une autre bière !).

qemu -hda disque.img -cdrom /chemin/vers/Win_XP_Pro.iso -boot d
.

Une fois le programme d’installation lancé, vous choisissez l’option ‘R’ (pour réparer), et si tout se passe bien il va vous détecter la partition système Windows que vous allez choisir (’1′). Vous vous retrouvez alors dans une sorte de shell avec quelques commandes disponibles (faut pas rêver, c’est pas une busybox non plus, et vous ne pouvez même pas éditer un fichier).

Deux commandes vous nous être utiles: FIXMBR et  FIXBOOT, vous les lancez les 2. Peu importe l’ordre, FIXMBR va écrire un nouveau MBR (master boot record, les 512 premiers octets du disque dur) et FIXBOOT va copier le chargeur de démarrage.

Il ne reste plus qu’à redémarrer (ça se fait tout seul si vous tapez exit)… et là si vous êtes dans le même cas que moi (partition système Windows autre que C:), vous croyez tenir le bon bout mais le système se fige lamentablement au démarrage; ça n’est pas la peine d’attendre et d’en profiter pour aller boire des bières, ça ne va pas plus loin.

Après divers tests (avec plein de dd très longs) pour arriver à faire démarrer mon Windows, j’en ai déduit qu’il fallait absolument que le partitionnement de la nouvelle image disque ressemble le plus possible à celui de la machine originale de manière à avoir la partition système Windows sur H:. J’ai essayé avec fdisk sous Linux et je ne suis pas arrivé à mes fins. Après réflexion, je pense que ça doit être possible mais j’en ai un peu marre des essais à vrai dire.

J’ai donc recréé le partitionnement de l’image disque avec le CD d’installation de windows (mode réparation) à l’aide de la commande diskpart. J’ai créé la première partition en FAT16 de la même taille que sda1 sur mon portable et plusieurs petites partitions en FAT16 (de 20 Mo) jusqu’à arriver à H: où j’ai créé la grosse partition NTFS. Dans diskpart, vous ne pouvez donner que des tailles en Mo, donc pour recréer le même nombre de blocs que dans votre partitionnement original, il vous faudra peut-être tâtonner un peu.

Chez moi j’obtiens ça (le partitionnement a été fait avec diskpart, mais je l’affiche ici avec fdisk ):

Disk /dev/hda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         261     2096451    6  FAT16
/dev/hda2             262        1304     8377897+   f  W95 Ext'd (LBA)
/dev/hda5             262         264       24066    6  FAT16
/dev/hda6             265         267       24066    6  FAT16
/dev/hda7             268         270       24066    6  FAT16
/dev/hda8             271         273       24066    6  FAT16
/dev/hda9             274        1109     6715138+   7  HPFS/NTFS
.

Une fois que le partitionnement est bon, vous pouvez recommencer depuis le début pour copier vos partitions (j’ai mis aussi la sda1 tant que j’y étais, mais je ne sais pas si c’était utile) avec la même méthode, vous démarrez QEMU avec les images des partitions comme disque dur et vous faites des dd.

Si tout va bien, une fois que vous avez reconstruit le MBR et le chargeur de démarrage, vous aurez l’immense satisfaction de voir enfin démarrer votre Windows (avec quelques toussotements et crachotements puisque le matériel émulé par QEMU n’est surement pas le même que sur votre machine originale).

Pour ma part, j’ai transférere l’image sur un serveur (via une ligne ADSL). J’ai compressé l’image avant de la transférer (avec bzip2) et je suis passé de 10 Go à 3,5 Go, donc c’est faisable, faut pas être pressé et puis vous pouvez en profiter pour aller boire une bière parce que, arrivé là, vous l’aurez bien méritée.

Ensuite il ne reste plus qu’à lancer QEMU sur le serveur avec l’option -vnc pour l’utiliser à distance avec vncviewer (faites quand même attention à la sécurité, tout est prévu pour, alors faites un tour dans la doc de QEMU).

N’oubliez pas une fois que tout est terminé d’effacer le Windows original car je doute que la licence de Windows vous permette de faire tourner plusieurs copies en même temps (je doute même que tout ce que je décris ci-dessus soit compatible avec la licence… si ça vous amuse, lisez-là).

Je stocke une quantité inimaginable de scripts, de bouts de codes, de documents, de photos et de projets en tout genre sur mon serveur de fichiers. Quelques Go qui représentent des années de ma vie « numérique ». Le temps passe, le volume des données augmente et il devient urgent de trouver un moyen de sauvegarde plus rapide, plus efficace et surtout moins fastidieux que la gravure sur DVD. - Vous remarquerez au passage la photo prise en exclusivité pour l’illustration de cet article et sa superbe mise en scène réalisée sur le plan de travail de ma cuisine -
La sauvegarde sur DAT ou DLT étant bien trop onéreuse et surtout trop lente, j’ai opté pour le montage d’un serveur de sauvegardes « maison ».

Mise en place :

* Côté matériel, un petit Céléron 900Mhz de récupération fera très bien l’affaire. Je le gonfle un peu en montant la ram à 384Mo et attribue le gros du budget au stockage en lui offrant deux beaux disques dur IDE de 320Go - Ca ! C’est classe ! -

* Côté logiciel, une distribution Debian et un petit script qui combine rsync pour optimiser les transferts réseaux et des liens durs pour garder un historique en limitant l’espace disque utilisé.

Pour simplifier les choses, nous allons appeler le serveur de fichiers « serv_file » et le serveur de sauvegardes « serv_nas« .

Les présentations étant faites, commençons par générer un bi-clés pour ssh sur serv_nas et faire une copie de la clef publique sur serv_file, pour que mon premier puisse parler à mon second, via ssh et sans avoir à fournir de mot de passe. C’est quand même bien plus pratique pour automatiser le bazar !

Concrètement, comment fait-on ?
Sur serv_nas :

srv_nas:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
2d:40:c4:09:67:06:...b:bf:06 root@srv_nas

srv_nas:~# ssh-copy-id root@srv_file
root@srv_file's password :

Tout c’est bien passé ? L’ouverture d’une session ssh de serv_nas vers serv_file devrait se faire sans mot de passe. Essayons…

srv_nas:~# ssh srv_file
Last login: Mon Mar 17 18:10:25 2008 from 192.168.7.102
Linux srv_file 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

srv_file:~#
srv_file:~# exit

srv_nas~#

Si ce n’est pas déjà fait, il faut maintenant installer rsync sur les deux machines :

srv_nas:~# aptitude install rsync
srv_nas:~# ssh srv_file aptitude install rsync

Le script – Initialisation

Allez ! Fini la rigolade, passons au script…
La première chose à faire est de déclarer quelques variables…C’est quand bien plus propre et ça facilite la modification du script par la suite.

• le nom serveur à sauvegarder ($SERVER),
• le répetoire local de stockage des sauvegardes ($DST),
• le fichier de log ($LOG),
• et une date formatée qui va être utilisée pour « horodater » la sauvegarde ($DATE).

#!/bin/bash
#------Début du fichier /usr/local/scripts/snapshot.sh
 
SERVEUR="srv_file"
DST="/srv/sauvegardes"
LOG="/var/log/snapshot-$SERVEUR.log"
DATE=`date +%y%m%d-%H%M`

Le script – rsync :

L’étape suivante, va consister à boucler sur les répertoires à sauvegarder (etc, home, root, data, srv et var dans l’exemple) pour en faire un miroir dans un dossier local nommé « current » (/srv/sauvegardes/current). Ce dernier contiendra toujours la dernière image des fichiers sauvegardés.
La commande rsync avec les options suivantes est la plus à même de réaliser ce travail :

• -r (récursif) pour inclure les sous répertoires,
• -a (archive) pour conserver les propriétés et les droits du fichier original,
• –delete pour supprimer du répertoire destination tout fichier qui ne serait plus présent dans le répertoire source. Cette option est impérative pour la suite des opérations.

# SYNCHRONISATION
 
echo "Début de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
for REP in etc home root data srv var ;  do
    echo "    *    Sauvegarde de  $REP" >> $LOG
    rsync -ra --delete $SERVEUR:/$REP $DST/current 2>> $LOG
done;

Le grand intérêt dans l’utilisation de la commande rsync réside dans le fait que, contrairement à scp, elle ne va copier que les fichiers différents ou inexistants dans le répertoire destination et donc procurer un immense gain de bande passante et de temps.

Le script – Les liens durs :

La dernière étape va créer une image datée du répertoire « current », avant que la prochaine synchronisation ne vienne en altérer le contenu, en optimisant l’espace disque utilisé.

Pour cette opération, la puissante des liens durs va nous être très utile.

Les liens durs associent deux ou plusieurs fichiers à un même espace sur le disque. Les deux fichiers restent indépendants, tout en partageant le même espace disque et donc le même inode . Toute modification de l’un, modifie l’autre, mais la suppression de l’un, casse le lien et ne supprime pas physiquement l’autre.

Dans notre cas, nous allons créer un lien dur de notre dossier « current » et de son contenu vers un dossier portant la valeur de notre variable $DATE (la date et l’heure du début de la sauvegarde).
Il suffit pour cela d’utiliser la commande « cp » avec les options :

• -l (lien) pour la copie par lien dur,
• -a (archive) pour conserver les propriétés et droits des fichiers.

# SNAPSHOT
 
cp -al $DST/current $DST/$DATE 2>> $LOG
 
echo "Fin de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
echo "========================================" >> $LOG
 
#------Fin du fichier /usr/local/scripts/snapshot.sh

En résumé :

Juste après l’exécution du script, le répertoire current et le répertoire « daté » sont identiques. Comme le second est créé par « liens durs », aucun espace disque supplémentaire n’est consommé.

Lors de la sauvegarde suivante, la commande rsync va modifier le répertoire « current » :

• En effaçant les fichiers supprimés sur le serveur depuis la dernière sauvegarde – les liens durs pour ces fichiers seront cassés,

• En ajoutant les fichiers créés sur le serveur – pas d’action sur les liens,

• En recopiant tout fichier modifié sur le serveur, ce qui revient à supprimer l’ancienne version et créer la nouvelle – les liens portant sur les anciens fichiers seront cassés.

En résumé, cette mécanique va permettre de garder un historique des fichiers du serveur, jour après jour, en ne consommant que l’espace utilisé par les ajouts ou modifications de fichiers.

La notion de lien est complètement transparente pour l’utilisateur et sous chaque répertoire, nous retrouvons l’ensemble des fichiers, tels qu’ils étaient sur le serveur à la date correspondante; d’où le nom de « snapshot » donné à cette technique (et à mon script !)

Pour finir, voici le petit script en un seul morceau :

#!/bin/bash
#------Début du fichier /usr/local/scripts/snapshot.sh
 
# PARAMETRE
SERVEUR="srv_file"
DST="/srv/sauvegardes"
LOG="/var/log/snapshot-$SERVEUR.log"
DATE=`date +%y%m%d-%H%M`
 
# SYNCHRONISATION
echo "Début de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
for REP in etc home root data srv var ;  do
    echo "    *    Sauvegarde de  $REP" >> $LOG
    rsync -ra --delete $SERVEUR:/$REP $DST/current 2>> $LOG
done;
 
# SNAPSHOT
cp -al $DST/current $DST/$DATE 2>> $LOG
echo "Fin de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
echo "========================================" >> $LOG
 
#------Fin du fichier /usr/local/scripts/snapshot.sh