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

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à).

Pour cela, je dispose d’une Fonera 2.0 flashée sous Openwrt kamikaze (8.09 RC1) sur laquelle est connecté un disque usb formaté en ext3. Le réseau est correctement configuré et opérationnel.

Commençons par installer quelques paquets indispensables :

• kmod-usb2 : gestion de l’ USB,
• kmod-usb-storage : gestion des périphériques de stockages USB,
• kmod-fs-ext3 : prise en charge des systèmes de fichiers ext3,
• nfs-kernel-server : serveur nfs,
• nfs-kernet-server-utils : utilitaires optionnels (tels que nfstat),
• portmap : indispensable pour le serveur nfs et pourtant oublié dans les dépendances.

# opkg update
# opkg install kmod-usb2
# opkg install kmod-usb-storage
# opkg install kmod-fs-ext3
# opkg install nfs-kernel-server
# opkg install nfs-kernel-server-utils
# opkg install portmap

Une fois les paquets installés, le disque devrait être reconnu et automatiquement monté dans /mnt/usbdrive.

Le suite consiste à configurer l’export nfs.

Pour cela, il faut éditer le fichier /etc/exports.

/mnt/usbdrive    192.168.7.0/24 (rw,no_root_squash,async)

• export de /mnt/usbdrive,
• pour toutes les machines du réseau 192.168.7.0,
• en lecture et écriture,
• autoriser root à accéder aux fichiers,
• en asynchrone.

Il ne reste plus qu’à démarrer le serveur nfs :

# /etc/init.d/portmap start
# /etc/init.d/nfsd start

Pour activer le lancement automatique des démons au démarrage d’openwrt :

# /etc/init.d/portmap enable
# /etc/init.d/nfsd enable

Côté client nfs, le montage se fait classiquement :

# mount -t nfs adresse_ip_fonera:/mnt/usbdrive /mnt/owrt

Ensuite, peu importe le type de RAID, tout se passe dans le fichier de configuration /etc/raidtab.

En voici quelques exemples  :

Chaque partition, utilisée pour construire le Raid doit être typée « fd » : Linux Raid auto.

Raid 0 (Volumes agrégés)

raiddev /dev/md0
raid-level              0
nr-raid-disks           2
persistent-superblock   1
chunk-size              4
device                  /dev/sda1
raid-disk               0
device                  /dev/sdb1
raid-disk 1

Raid 1 (Miroir)

raiddev                   /dev/md0
raid-level                1
nr-raid-disks             2
persistent-superblock     1
chunk-size                16
device                    /dev/sda1
raid-disk                 0
device                    /dev/sdb1
raid-disk                 1

Raid 5 (Volumes agrégés par bandes)

raiddev                   /dev/md0
raid-level                5
nr-raid-disks             3
nr-spare-disks            0
persistent-superblock     1
parity-algorithm          left-symmetric
chunk-size                32
device                    /dev/sda1
raid-disk                 0
device                    /dev/sdb1
raid-disk                 1
device                    /dev/sdc1
raid-disk                 2
.

Le raid configuré, il se lance ou s’arrête avec les commandes « raidstart » et « raidstop ».

# raidstart /dev/md0

Avant de l’utiliser, il convient, biensûr, de créer le système de fichier.

# mkfs.ext3 /dev/md0

Il ne reste plus qu’à monter la partition.

Avant toute chose, il faudra installer les modules noyau pour la gestion du stockage usb et les systèmes de fichier fat (fat 16 et fat32). La clef utilisée étant formatée en fat16.

root@OpenWrt:/# opkg install kmod-usb-storage
Installing kmod-usb-storage (2.6.26.5-atheros-1) to root...
Downloading http://downloads.openwrt.org/snapshots/atheros/packages/./kmod-usb-storage_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (195.56.146.238:80)
kmod-usb-storage_2.6 100% |************************************************************************************************************| 47028  00:00:00 ETA
Installing kmod-scsi-core (2.6.26.5-atheros-1) to root...
Downloading http://downloads.openwrt.org/snapshots/atheros/packages/./kmod-scsi-core_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (195.56.146.238:80)
kmod-scsi-core_2.6.2 100% |************************************************************************************************************| 69267  00:00:00 ETA
Configuring kmod-scsi-core
Configuring kmod-usb-storage
 
root@OpenWrt:/# dmesg
...
SCSI subsystem initialized
Driver 'sd' needs updating - please use bus_type methods
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access     SanDisk  U3 Cruzer Micro  4.05 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 8013453 512-byte hardware sectors (4103 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 8013453 512-byte hardware sectors (4103 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
scsi 0:0:0:1: CD-ROM            SanDisk  U3 Cruzer Micro  4.05 PQ: 0 ANSI: 2
usb-storage: device scan complete

Ok pour ça… On obtient un disque scsi émulé sda et une partition : sda1. Occupons nous maintenant de la gestion des systèmes de fichiers fat.

root@OpenWrt:/# opkg list|grep vfat
kmod-fs-vfat - 2.6.26.5-atheros-1 - Kernel module for VFAT filesystem support
 
root@OpenWrt:/# opkg install kmod-fs-vfat
Installing kmod-fs-vfat (2.6.26.5-atheros-1) to root...
Downloading http://downloads.openwrt.org/snapshots/atheros/packages/./kmod-fs-vfat_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (195.56.146.238:80)
kmod-fs-vfat_2.6.26. 100% |************************************************************************************************************| 37463  --:--:-- ETA
Installing kmod-nls-base (2.6.26.5-atheros-1) to root...
Downloading http://downloads.openwrt.org/snapshots/atheros/packages/./kmod-nls-base_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (195.56.146.238:80)
kmod-nls-base_2.6.26 100% |************************************************************************************************************|  3704  --:--:-- ETA
Configuring kmod-fs-vfat
Configuring kmod-nls-base

Premier essai : pas très concluant :

root@OpenWrt:/# mount -t vfat /dev/sda1 /mnt/usbdrive/
mount: mounting /dev/sda1 on /mnt/usbdrive/ failed: Invalid argument
 
root@OpenWrt:/# logread
...
Oct 16 08:33:36 OpenWrt user.err kernel: FAT: codepage cp437 not found
Oct 16 08:38:49 OpenWrt user.err kernel: FAT: codepage cp437 not found
Oct 16 08:39:11 OpenWrt user.err kernel: FAT: codepage cp437 not found
Oct 16 08:39:45 OpenWrt user.err kernel: FAT: codepage cp437 not found
Oct 16 08:40:08 OpenWrt user.err kernel: FAT: codepage cp437 not found
Oct 16 08:40:37 OpenWrt user.err kernel: FAT: codepage cp437 not found

Il s’agit d’un problème de page d’encodage… Nous avons dû louper un module…

root@OpenWrt:/# opkg list |grep cp437
kmod-nls-cp437 - 2.6.26.7-atheros-1 - Kernel module for NLS Codepage 437 (United States, Canada)
root@OpenWrt:/usr/local/apache2/htdocs/cam1# opkg install kmod-nls-cp437
Installing kmod-nls-cp437 (2.6.26.7-atheros-1) to root...
Downloading http://downloads.openwrt.org/snapshots/atheros/packages/./kmod-nls-cp437_2.6.26.7-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (195.56.146.238:80)
kmod-nls-cp437_2.6.2 100% |*********************************************************************************************************************************************************|  2954  --:--:-- ETA
Configuring kmod-nls-cp437

Deuxième essai : On progresse… mais ce n’est pas ça !

root@OpenWrt:/# mount -t vfat /dev/sda1 /mnt/usbdrive/
mount: mounting /dev/sda1 on /mnt/usbdrive/ failed: Invalid argument
 
root@OpenWrt:/# logread
...
Oct 16 08:42:28 OpenWrt user.err kernel: FAT: IO charset iso8859-1 not found
Oct 16 08:43:10 OpenWrt user.err kernel: FAT: IO charset iso8859-1 not found

Codage caractères ce coup-ci…

root@OpenWrt:/# opkg list|grep iso88
kmod-nls-iso8859-1 - 2.6.26.5-atheros-1 - Kernel module for NLS ISO 8859-1 (Latin 1)
kmod-nls-iso8859-15 - 2.6.26.5-atheros-1 - Kernel module for NLS ISO 8859-15 (Latin 9)
kmod-nls-iso8859-2 - 2.6.26.5-atheros-1 - Kernel module for NLS ISO 8859-2 (Latin 2)
 
root@OpenWrt:/# opkg install kmod-nls-iso8859-1
Installing kmod-nls-iso8859-1 (2.6.26.5-atheros-1) to root...
Downloading http://downloads.openwrt.org/snapshots/atheros/packages/./kmod-nls-iso8859-1_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (195.56.146.238:80)
kmod-nls-iso8859-1_2 100% |*******************************|  2622  --:--:-- ETA
Configuring kmod-nls-iso8859-1

Troisième essai : C’est la bonne !

root@OpenWrt:/# mount -t vfat /dev/sda1 /mnt/usbdrive/
root@OpenWrt:/#

La commande tune2fs va nous permettre, grâce à son option « -m »  d’ajuster ce pourcentage.

Par exemple, la commande :

  # tune2fs -m 1 /dev/sda1

va réajuster la réservation à 1%, pour la partition sda1.

Une autre option de tune2fs, qui mérite un petit mot, est l’option « -L » qui va nous permettre de changer le nom (label) d’une partition.
Ainsi :

# tune2fs -L « MonDisqueAMoi » /dev/sda1

va donner le nom « MonDisqueAMoi » à la partition sda1.

L’intérêt n’est pas des moindres puisque nous pourrons utiliser ce label à la place du device pour monter la partition. Bien pratique pour des périphériques USB, qui, en l’absence de règle udev, sont attachés aux devices en fonction de leur ordre de connexion.

Pour un montage manuel :

# mount -L MonDiqueAMoi /mnt/hd

Ou dans le /etc/fstab

LABEL=MonDisqueAMoi /mnt/hd ext3 defaults 0 2

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

Je vais vous proposer une méthode un peu moins « violente » et qui, bien que logicielle, reste bien plus efficace qu’un simple formatage.

Nous allons pour cela utiliser l’utilitaire shred qui permet de « déchiqueter » un fichier en effectuant plusieurs passes d’écritures.

Pour donner un exemple, la commande :

$ shred -n 40 -z -u mon_secret.txt

va :

• Réécrire 40 fois le fichier mon_secret.txt avec des données aléatoires (-n 40),
• effectuer un dernier passage avec des « 0″ pour masquer le « déchiquetage » (-z ),
• puis, finalement, tronquer et supprimer le fichier (-u).

Grâce à l’approche Unix/Linux des périphériques (« tout est fichiers ») , nous pouvons utiliser la même commande sur un disque ou une partition (de préférence démontée).

# shred -n 40 -z /dev/[périphérique]

[périphérique] remplace le nom (handler) associé à la partition ou au disque :
Sur la plupart des systèmes Linux, le premier disque dur IDE est /dev/hda, le premier disque dur SCSI ou SATA est /dev/sda, le deuxième disque dur IDE est /dev/hdb, et ainsi de suite.
Pour donner un autre exemple, la commande qui permettra d’effacer le premier disque dur maître IDE sera :

# shred -n 40 -z /dev/hda

Si on ne souhaite traiter que la première partition de ce disque :

# shred -n 40 -z /dev/hda1