Tomsrtbt

Sauvegarde réseau

Introduction:

Tomsrtbt est une mini-distribution non installable de Linux.

Elle permet d'accéder aux partitions Linux (ext2, ext3, (pour le reiserfs, il faut changer le noyau (une procédure est indiquée sur le Twiki de Tomsrtbt); il est envisagé de créer une image avec le support dans une version future)) et Window$ (FAT16, FAT32 (lecture/écriture), NTFS (lecture seule, il me semble)).
Mais ici nous considérerons la sauvegarde vers un partage window$/samba sur une machine distante.

<<REFAIRE LES TESTS vers NFS>>

Un autre mode de clonage est aussi présenté (utilisant tar et netcat).
C'est plus simple qu'en SMB, mais je ne l'ai testée que plus récemment.

Création de la disquette de boot:

Sous Window$:

• Dézipper l'archive tomsrtbt-<version>.dos.zip
• Redémarrer en mode M$DO$ (pas seulement une fenêtre DO$ sous Window$)
• Se placer dans le répertoire où tomsrtbt a été dézippé
• Exécuter install.bat
  La machine doit redémarrer gentiment sous linux
  
• Insérer une bonne disquette 3.5'' lorsque le script vous le demande.
  Lorsqu'elle aura, fini la machine va redémarrer sur Tomsrtbt si vous laissez la disquette dans le lecteur ou sinon sur votre OS par défaut.
  

Sous Linux:

• extraire l'archive .tar.gz dans un répertoire (tar -xvzf <nom_de_l'archive.tar.gz>)
  
• être root (su)
  
• Se déplacer dans le répertoire tomsrtbt-<version>
• Mettre dans le lecteur une disquette de bonne qualité
  
• Lancer './install.s'
  Le script suppose que votre lecteur 3.5'' soit fd0.
  En théorie tout les lecteurs 1.44 supportent le format 1.722.
  Il paraît que ce format peut détériorer un lecteur (ce n'est pas vraiment un drame vu le prix d'un lecteur (cela ne m'est jamais arrivé, par contre certains lecteurs ou BIOS refusent de booter sur des disquettes ainsi formattées (cela m'est arrivé avec un Compaq))).
  Le script crée le device /dev/fd0u1722 s'il n'existe pas encore sur votre système.
  Si votre système est en glibc / libc.so.6 vous pouvez avoir besoin de faire:
  LD_LIBRARY_PATH=/usr/i486-linux-libc5/lib; ./fdformat /dev/fd0u1722
  

Remarque: La procédure indiquée a été adaptée d'après la traduction effectuée sur le site de MINAList.
En effet sur le site de Tom Oehser, c'est en anglais...

Procédure de sauvegarde et restauration en SMB

Il est possible avec Tomsrtbt (http://www.toms.net/rb/), d'accéder à des partages Window$.

Le reste de la procédure ressemble à la procédure de sauvegarde locale.

Vous devez avoir créé la disquette de boot et avoir identifié le pilote réseau nécessaire pour le client (un recherche via Google avec le nom de la carte réseau et le mot « linux » doit suffire).

L'accès au partages window$ a changé entre les versions 1.7.361 et 2.0.103
Je vais donc préciser les deux cas.

Cas de Tomsrtbt 1.7.361:

Le pilote réseau, le fichier « smbmount » et le module de gestion du système de fichiers « smbfs.o » (qui correspond aux partages window$) disponibles dans les « addons » du site de Tomsrtbt doivent être accessibles (sur une disquette, sur un cdrom ou sur le disque dur) une fois le système booté avec Tomsrtbt.

Imaginons qu'il s'agit du pilote via-rhine.o stocké sous forme compressée via-rhine.o.bz2 que nous avons stocké tout cela sur une disquette.
Après le boot et après s'être logué en tant que root, éjecter la disquette de boot et insérer celle qui contient le pilote, et les fichiers « smbfs.o » et « smbmount »:

Saisissez éventuellement un mot de passe si l'accès au partage est protégé, mais dans tous les cas le partage doit être accessible en écriture.

Cas de Tomsrtbt 2.0.103:

La procédure a changé et j'ai rencontré des soucis avec un certain nombre de cartes réseau pour l'accès à des partages window$.
J'ai plusieurs fois échoué.
Cependant, il semble qu'on obtienne des erreurs, dont il ne faut pas tenir compte (cela fonctionne malgré tout... en principe).

#Avec la nouvelle version Tomsrtbt2.0.23:
#Il y a trois executables:
#smbmnt, smbmount et smbumount et la syntaxe diffère un peu.
#Le smbfs.o a aussi changé.

#Copie des programmes et pilotes vers /tmp:

#Débzipage de ces fichiers:
bzip2 -d *.bz2

#Chargement du module de la carte réseau (via-rhine.o, rtl8139.o,...):
insmod via-rhine.o

#Re-Création du fichier /etc/networks

#Paramétrage de la carte réseau
ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up

#Définition des routes:

#Chargement du module pour les systèmes de fichier Samba/window$:
insmod smbfs.o

#Création du point de montage:
mkdir /mnt/smb

#Création des liens nécessaires au bon fonctionnement de smbmount:
#Lorsqu'on execute smbmount, il y a des appels "internes" à smbmnt et ce fichier doit-être dans le PATH

#Pour accéder à un partage:
smbmount //nom_du_serveur/nom_du_partage /mnt/smb
Un mot de passe est demandé (même si aucun mot de passe n'est nécessaire):
Le fournir et/ou valider avec Entrée.

#Pour éviter qu'un mot de passe soit demandé:
smbmount //nom_du_serveur/nom_du_partage /mnt/smb -o guest

#Pour accéder à un serveur avec un couple login/password sur un partage non public:
smbmount //nom_du_serveur/nom_du_partage /mnt/smb -o username=monlogin,password=monpassword
#Ou
smbmount //nom_du_serveur/nom_du_partage /mnt/smb -o username=monlogin
#Et le mot de passe est demandé après.

#Attention: La commande suivante ne fonctionne pas avec tomsrtbt:
#mount -t smbfs //host /mountpoint -o options

Sauvegarde/restauration:

Abordons ici la partie sauvegarde proprement dite.

Pour la restauration, tout le début de la procédure sera la même et on finira par:

Remarque:    
Si le réseau n'est pas d'une grande fiabilité, ou si le trafic réseau est important, utiliser un cable croisé entre le client et le serveur pour n'avoir que ces deux postes sur un mini-réseau peut être intéressant.

Clonage via tar et nc

Une solution pour le clonage via tar et nc (netcat) est signalée sur le Twiki de Tomsrtbt (en allemand, pour les amateurs... ou les polyglottes).

Je viens de faire quelques tests (avec le temps cette formulation deviendra saugrenue).
Je vous les livre ici:

Comme je ne disposais pas de deux postes identiques lors des tests, j'ai fait un premier essai comme suit:

Sur le client (le poste qui va recevoir les données (le contenu de la partition)):

# loadkmap < /lib/key/fr.map
# mkdir /mnt/floppy
# mount -t vfat /dev/fd0 /mnt/floppy
mount: block device /dev/fd0 is write-protected, mounting read-only
# cp /mnt/floppy/via-rhine.o.bz2 /tmp/
# cd /tmp
/tmp# bzip2 -d via-rhine.o.bz2
/tmp# insmod via-rhine.o
Using via-rhine.o
via-rhine.c:v1.08b-LK1.0.1 12/14/2000  Written by Donald Becker
  http://www.scyld.com/network/via-rhine.html
eth0: VIA VT3043 Rhine at 0xe800, 00:50:ba:ce:78:28, IRQ 10.
eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link 45e1.
/tmp# ifconfig eth0 192.168.52.3
eth0: Setting full-duplex based on MII #8 link partner capability of 45e1.
/tmp# ping 192.168.52.182
PING 192.168.52.182 (192.168.52.182): 56 data bytes
64 bytes from 192.168.52.182: icmp_seq=0 ttl=64 time=0.7 ms
64 bytes from 192.168.52.182: icmp_seq=1 ttl=64 time=0.2 ms

--- 192.168.52.182 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.4/0.7 ms
/tmp# mkdir /mnt/win
/tmp# mount -t vfat /dev/hda1 /mnt/win
/tmp# mkdir /mnt/win/test_nc
/tmp# cd /mnt/win/test_nc
/mnt/win/test_nc/# nc -l -p 2005 | tar xf -
Tar: blocksize = 20
/mnt/win/test_nc/#

Voici le détail de ces commandes:

loadkmap < /lib/key/fr.map

mkdir /mnt/floppy

mount -t vfat /dev/fd0 /mnt/floppy

cp /mnt/floppy/via-rhine.o.bz2 /tmp/

cd /tmp

bzip2 -d via-rhine.o.bz2

insmod via-rhine.o

ifconfig eth0 192.168.52.3

ping 192.168.52.182

mkdir /mnt/win

mount -t vfat /dev/hda1 /mnt/win

mkdir /mnt/win/test_nc

cd /mnt/win/test_nc

nc -l -p 2005 | tar xf -

Sur le serveur (le poste dont une partition est copiée à tra    ver le réseau):

# dmesg | grep eth0
eth0: 3Com 3c905C Tornado at 0xec80,  00:08:74:e0:d1:9a, IRQ 11
eth0: Initial media type Autonegotiate.
eth0: MII #24 status 782d, link partner capability 45e1, setting full-duplex.
# ifconfig eth0 192.168.52.182 up
# ping 192.168.52.3
PING 192.168.52.3 (192.168.52.3): 56 data bytes
64 bytes from 192.168.52.3: icmp_seq=0 ttl=64 time=0.4 ms
64 bytes from 192.168.52.3: icmp_seq=1 ttl=64 time=0.1 ms
64 bytes from 192.168.52.3: icmp_seq=1 ttl=64 time=0.1 ms

--- 192.168.52.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.2/0.4 ms
# mkdir /mnt/win
# mount -t vfat /dev/hda1 /mnt/win
# cd /mnt/win
/mnt/win# tar cf - /mnt/win | nc 192.168.52.3 2005
#

Voici le détail de ces commandes:

dmesg | grep eth0

ifconfig eth0 192.168.52.182 up

ping 192.168.52.3

mkdir /mnt/win

mount -t vfat /dev/hda1 /mnt/win

cd /mnt/win

tar cf - /mnt/win | nc 192.168.52.3 2005

Attention:

1. nc -l -p 2005 | tar xf -

   doit être lancé sur le client avant

   tar cf - /mnt/win | nc 192.168.52.3 2005

   sur le serveur.
   
   
   
2. Ce que j'ai fait aurait convenu pour deux postes identiques.
   Mais là ce n'était pas le cas et j'ai bousillé le window$ du client (disons que j'ai un peu accéléré la dégénérescence naturelle de ce système;o).
   En effet, en précisant /mnt/win dans la commande "tar cf - /mnt/win | nc 192.168.52.3 2005", j'ai inclus dans l'archive créée par tar un chemin absolu (/mnt/win), si bien que sur le client tout a été désarchivé dans le chemin /mnt/win (c'est-à-dire la partition window$ du client (ce qui aurait été parfait si j'avais souhaité cloner ces partitions)).
   Je souhaitais seulement désarchiver dans un sous-dossier de /mnt/win sur le client pour controler que cela fonctionnait et contrôler/comprendre la syntaxe.
   
   Quand je dis "bousiller", c'est exagéré:
   Window$ a démarré mais m'a demandé à réinstaller tout plein de pilotes,...
   Ca démarre, mais je n'ai pas eu le courage de tout remettre au propre et je doute que dans le cas de postes avec des matériels différents on parvienne ains i à quelque chose de propre.
   
   Pour seulement transférer les données et qu'elles soient désarchivées dans /mnt/win/test_nc, il aurait fallu effectuer sur le serveur:
   

   tar cf - mnt/win | nc 192.168.52.3 2005

   sans le / devant mnt/win (auquel cas on obtient tout de même une arborscence /mnt/win/test_nc/mnt/win/*)
   
   ou encore
   

   tar cf - ./* | nc 192.168.52.3 2005

   Ainsi, on envoye le contenu du dossier courant du serveur à savoir le contenu de /mnt/win sans chemin supplémentaire.
   
   
   
3. Cette commande peut être améliorée de plusieurs façons:
   La première à mon gout, c'est qu'il est désagréable de ne pas voir ce qui se passe.
   On peut donc rendre la commande tar un peu plus causante en ajoutant l'obtion v (pour verbeux).
   
   "tar  cvf  ./* | nc  192.168.52.3  2005" sur le serveur et "nc  -l  -p  2005  |  tar  xvf  -" sur le client.
   
   On voit alors défiler des lignes de "a ./windows/system/xxx.dll" sur le serveur ("a" pour archiver) et "x ./windows/system/xxx.dll" sur le client ("x" pour extraire).
   On constate ainsi que ce n'est pas bloqué.
   
   
   
4. La documentation en allemand sur le Twiki de Tomsrtbt signale des variantes pour alléger le trafic réseau.
   Il s'agit de gzipper avant l'envoi:
   
   Sur le serveur: tar cf - ./ | gzip -c | nc 192.168.52.3 2005
   
   Sur le client: nc -l -p 2005 | gzip -d - | tar xf -
   
   On peut ici aussi ajouter l'option v à tar pour savoir ce qui se passe.
   
   
   

Annexes:

Pour quelques précisions sur Linux:

• Création d'une disquette de boot d'après une image
  
  
• Les disques durs et partitions
  
  
• Montages
  
  
• Configuration du réseau

Liens:

Le site de Tomsrtbt: http://www.toms.net/rb/