Outils pour utilisateurs

Outils du site


expert:systeme_conversion_raid1

Créer un raid 1 logiciel depuis un système installé

Le contexte est le suivant : vous avez un système installé de manière “traditionnelle” sur un disque, et vous voulez le transformer en raid 1 en utilisant un second disque.

Avant de commencer il est bon de prendre quelques précautions, comme avoir une sauvegarde de vos documents, voir de tout le système, car la procédures n'est pas triviale. Considérez également que le raid 1 “miroir” n'est PAS un outils de sauvegarde. Vos données sont répliquées sur deux disques, mais vous n'êtes pas protégé d'un effacement involontaire de documents (ils seront effacés sur les deux disques instantanément), vous n'êtes pas protégé d'une panne simultanée des deux disques (s'ils sont de même modèle et série ça peut arriver, d'autant qu'ils seront soumis à la même activité), les deux disques sont soumis aux mêmes aléas liés à l'alimentation électrique et peuvent griller en même temps (surtension, foudre…), enfin le raid 1 peut corrompre silencieusement les données sur l'un des disques, d'une manière qui passera inaperçue jusqu'à la panne de l'autre (c'est assez rare mais mieux vaut en être conscient). Vous avez donc besoin d'une sauvegarde en plus de votre raid 1.

Préparation du système installé.

Nota : Le système utilisé est Debian GNU-Linux, la procédure doit pouvoir être adaptée facilement, les commandes de mdadm étant les mêmes. Les emplacement des fichiers de configuration et la commande de génération de l'initrd seront sans doute différentes, lisez le manuel ;-) .

Le chargeur d'amorçage est grub2 (pas “grub”, mais son successeur “grub2” ou “grub-pc”). Quelque soit votre distribution il est probable que vous n'utilisiez pas grub2, c'est une bonne occasion pour le découvrir ! Sinon je donne en fin de tuto la procédure pour “grub-legacy” (le “vieux” grub). ( Voir grub et grub2 )

Un signe $ précède les commandes qui ne nécessitent pas de droits administrateur ; un signe # précède celles qui nécessitent des droits administrateur (ces signes ne font PAS partie des commandes). Les lignes qui ne commencent pas par un signe $ ou # correspondent au résultat de la commande précédente.
Les touches utilisées sont indiquées entre crochets, exemple [ctrl] pour la touche “contrôle”

On appellera disque “original” celui sur lequel est actuellement installé votre système, on supposera qu'il est identifié comme /dev/sda par le système. On appellera “nouveau” disque celui qui est destiné à former la paire raid 1 avec le disque “maître”, on supposera que le système l'identifie comme /dev/sdb.

Installation de mdadm, préparation du nouveau disque

  • On installe le programme mdadm, c'est lui qui gère la couche raid. Lors de l'installation quelques options seront paramétrées, les choix par défaut conviennent, en particulier le fait d'assembler et de démarrer automatiquement les volumes raid lors du démarrage. ( voir mdadm )
  • On copie le schéma de partitionnement du disque original sur le nouveau disque, de manière à avoir des partitions strictement identiques sur les deux disques. ATTENTION, la commande suivante ne demandera aucune confirmation, et elle détruit le contenu du disque cible :
# sfdisk -d /dev/sda | sfdisk /dev/sdb
:!: Cette méthode présente un risque d'obtenir un système de fichier corrompu lors de la création du raid, et de nécessiter un très long passage de “e2fsck -cc” (voir plus bas “Problèmes possibles”).
Pour éviter cela réduisez la taille des partitions originales d'environ 1Mo avant d'exécuter “sfdisk”. Une fois l'ensemble des opérations terminées vous pourrez agrandir le système de fichier à nouveau avec “resize2fs”, en l'exécutant cette fois sur les groupes raid directement et non plus sur les partitions.
  • On change le type des partitions sur le nouveau disque pour “fd” (raid auto-detect). Si par exemple vos partitions sont en ext3 elle auront le type “83” si vous les examinez avec “fdisk -l”. Nous changeons ce type pour “fd” qui indique que cette partition fait partie d'un ensemble raid. Sans cette manipulation l'auto-montage au démarrage ne fonctionnera pas !
Si vous utilisez des métadonnées de type 1.* vous n'avez pas besoin de changer le type de système de fichier pour “fd”, mais vous devez renseigner le fichier mdadm.conf et mettre à jour le disque initial de démarrage (“initrd” ou “initramfs”) avant de redémarrer la machine. Pour “l'ancien” format de métadonnées 0.90 cette manipulation reste indispensable.

Vous pouvez faire cela interactivement dans “fdisk” :

# fdisk /dev/sdb

Ensuite touche [t] et validez
numéro de ma partition [1 à 4] et validez
type de la partition [fd] et validez

Répétez pour toutes les partitions, puis pour écrire les changements sur le disque:

touche [w] et validez

Une séquence complète donne:

# fdisk /dev/sdb
GNU Fdisk 1.2.1
[...]
Using /dev/sdb
Command (m for help): t
Partition number (1-3): 1
Hex code (type L to list codes): fd
Changed type of partition 1 to fd (Lnx RAID auto)

Pour quitter sans appliquer les modifications, entrez la touche [q] et validez. Rien n'est écrit sur le disque avant que la commande [w] (write) ne soit entrée.

Création du volume raid1, adaptation du système

  • On crée le volume raid1, mais sans y inclure les partitions du disque original (cela détruirait leur contenu…) :
# mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1

La commande crée un groupe raid 1 (level=1) nommé “md0”, comprenant deux disques (raid-devices=2) dont un est manquant au moment de la création (/dev/sda1 est remplacé par la directive “missing” .). De la même façon vous pourrez renouvelez pour les autres groupes raid1 :

# mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb2

Et ainsi de suite, un groupe par partition du disque original (sauf pour les partitions que vous ne voudriez pas inclure).
Vous aurez une alerte concernant le fait que la partition contient déjà un système de fichier, vous pouvez l'ignorer (voir la note plus haut sur la nécessité de réduire les systèmes de fichiers originaux).

Un mot au sujet de l'espace d'échange (“swap”), officiellement il n'y a pas/plus de problème à utiliser un espace d'échange “swap” sur un raid1. Par le passé cela n'a pas toujours été le cas, à vous de choisir. L'avantage d'un swap sur raid1 est qu'en cas de défaillance d'un disque qui porte la swap, les applications qui y stockaient des données ne planteront pas. En revanche vous améliorerez les performances du système en utilisant un espace swap sur un disque séparé.
On peut optimiser le fonctionnement du groupe raid en jouant sur la taille par défaut des bloques (“chunk”) de données. Les tailles valides vont de 4K à 256K, pour un usage serveur une petite taille est un avantage, pour un usage avec de gros fichiers (édition multimédia…) une taille élevée donnera de meilleurs performances. La taille par défaut de 64k donne de bons résultats dans les cas courants. Pour définir ce paramètre à 128k on utilisera l'option “--chunk=128” lors de la création du groupe raid.
  • On crée un fichier de configuration pour mdadm, et on le sauvegarde :

On fait une copie de sauvegarde de l'original, puis on met à jour le fichier.

# cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.origin
$ su -c "mdadm --misc --detail --brief /dev/md* 2> /dev/null | tee -a /etc/mdadm/mdadm.conf"

À ce stade il est également bon de noter les UUID (identifiants uniques) de vos groupes raid, et de les garder sous la main :

$ ls -l /dev/disk/by-uuid/ | grep md
  • On fait en sorte que le module “raid1” soit chargé suffisamment tôt au démarrage pour permettre l'accès à la partition root sur le volume raid.

ajout du module “raid1” à l'initrd (Initial Ram Disk) :

# echo -e "raid1\nmd_mod" >> /etc/initramfs-tools/modules

Pour les utilisateurs de “sudo” (Ubuntu…), vous pouvez utiliser

$ echo -e "raid1\nmd_mod" | sudo tee -a /etc/initramfs-tools/modules

car sinon un “sudo echo” ne survivra pas à la redirection, et l'accès au fichier vous sera refusé.

Pour que la modification soit effective, il faut mettre à jour l'initrd :

# update-initramfs -u -k $(uname -r)

(utilisez “-k all” pour mettre à jour les initrd de tous les noyaux installés). Si vous n'utilisez pas d'initrd, alors “md_mod” et “raid” devront être compilés “en dur” dans le noyau, pas en modules.

  • Faire en sorte que grub2 charge les modules “raid” et “mraid” le plus tôt possible. Ouvrez dans un éditeur de texte /etc/default/grub, et ajoutez au tout début de la liste des options :
GRUB_PRELOAD_MODULES="raid mdraid"
Sur les version récentes de grub2 les modules nécessaires seront détectés automatiquement lors de l'appel à “update-grub2” ou “grub-mkconfig”. Cependant la présence de cette variable ne sera pas un problème, il y aura juste une double entrée de “insmod” dans le grub.cfg

Vérifiez dans ce même fichier que la directive “GRUB_DISABLE_LINUX_UUID=true” est commentée, ou à “false”, car nous allons nous servir de cette fonctionnalité de grub2 (les groupes raid supportent la désignation par des labels, mais pas encore grub2 :-( ). Une fois les modifications faites, exécutez :

# update-grub
# grub-install --recheck "(hd0)"

(pour les versions récentes de grub2, la commande “update-grub” devient “grub-mkconfig”).

  • Être certains que le système charge les modules raid (c'est superflu sur la plupart des distributions, l'installation de mdadm ayant déjà pour effet de charger les modules nécessaires, mais ça ne nuira en aucun cas) :
# echo -e "md_mod\nraid1" >> /etc/modules

Arrivé là vous avez deux choix, soit redémarrer sur un live-cd pour effectuer les manipulations suivantes alors que toutes les partitions sont inutilisées, ou passer en mode “single user” (ou mode de maintenance) pour remonter la partition système en lecture seule. Dans ce cas utilisez:

# init 1

Si vous n'avez pas d'impératifs particuliers, il vaut mieux redémarrer sur un live-cd. Ici j'utilise SystemRescuecd, mais n'importe lequel fera l'affaire du moment que mdadm y est présent ou peut y être installé.

Copie du système sur le volume raid.

  • Une fois redémarré sur le live-cd, on assemble tous les groupes raid1 (qui ne sont composés que d'une partition chacun pour le moment) :
# mdadm -Ac partitions -m0 /dev/md0

Cette commande cherche les composants de groupes raid dont l'identifiant mineur est “0” (zéro), et crée le périphérique raid correspondant /dev/md0 avant de l'activer. À renouveler avec les différents groupes que vous avez créé (“-m1 /dev/md1”, “-m2 /dev/md2” …). De cette façon on vérifie pour chaque groupe que l'assemblage se passe bien.

  • On crée des points de montage pour les périphériques raid, et on les monte :
# mkdir /mnt/md0 /mnt/md1 /mnt/md2

(ajustez en fonction du nombre de groupes que vous avez créé. Si l'un d'eux est une partition d'échange “swap” il ne sera pas nécessaire de créer de point de montage).

On monte les volumes raid :

# mount -t ext3 /dev/md0 /mnt/md0

Préciser le système de fichier n'est pas toujours indispensable, faites le si “mount” renvoie une erreur.

  • Copie du système sur le volume raid.

On procède de la même façon pour les partitions qui constituent le système original :

# mkdir /mnt/sda1 && mount /dev/sda1 /mnt/sda1

et on lance la copie de leur contenu sur les volumes raid:

# rsync -aHAXP /mnt/sda1/ /mnt/md0/

Faite de même pour toutes les partitions, à l'exception de la “swap”. En fonction de la taille de vos partitions la copie peut-être longue…

nota: Si vous êtes en mode “init 1” ou “single user”, la commande sera:

# rsync -aHAXP / /mnt/md0/

(“cp” peut être utilisé comme alternative à “rsync”)

Répéter pour /home/$(user), /var, /boot … en fonction de votre cas.

Adaptation du système sur le volume raid.

  • Vérifier l' UUID de vos volumes raid :
# blkid /dev/md*

ou

$ ls -l /dev/disk/by-uuid/ | grep md

Il se présente sous la forme “e7v87594-e862-4804-81d6-51dgc632d021”, où la suite de lettres et chiffres sera évidemment différente pour chaque volume raid. :!: Lorsque j'utilise “$(vol_id /)” ou “$(vol_id /home)” dans la suite du tutoriel, cela correspond à l'UUID de votre volume raid correspondant.

  • Éditez le fichier /etc/fstab sur md0 (c'est à dire /mnt/md0/etc/fstab si /dev/md0 est monté sur /mnt/md0), remplacez l'identifiant dans les lignes qui concernent la partition racine “/”, “/home” et “swap”, par l'UUID du volume md* correspondant (adaptez à votre partitionnement).

Par exemple si le fichier fstab contient :

/dev/sda1 /  ext3 [...]
/dev/sd2 /home ext3 [...]
/dev/sda3 none swap

vous le remplacez par :

UUID="$(vol_id /)"  /  ext3 [...]
UUID="$(vol_id /home)"  /home  ext3 [...]
UUID="$(vol_id swap)"  none  swap [...]

Vous noterez que seul l'identifiant change, le reste de la ligne est identique, y compris le type de système de fichier (si vous utilisez reiserfs ou xfs, vous adaptez).

Exemple de fichier /etc/fstab complet :

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

#Entrée pour "/" sur /dev/md0:
UUID=e7b87294-e962-4804-80d6-51dfc639c021       /       ext3    errors=remount-ro,relatime      0       1

#Entrée pour "/home" sur /dev/md1:
UUID=6ee11d47-549b-41ac-b4de-789567b56398       /home   ext3    defaults,relatime       0       2

# Entrée pour "swap" sur /dev/md2:
UUID=e7v87594-e862-4804-81d6-51dgc632d021       none    swap    sw      0       0

/dev/scd0       /media/cdrom0   udf,iso9660     user,noauto     0       0
sysfs   /sys    sysfs   defaults        0       0
proc    /proc   proc    defaults        0       0
none    /sys/bus/usb/drivers    usbfs   devgid=124,devmode=664  0       0

Faite de même dans le fichier /etc/mtab, remplacez l'identifiant dans les mentions de “/” (et éventuellement “/home” si présente) par l'UUID du volume raid correspondant.

  • Éditez le fichier /boot/grub/grub.cfg (donc /mnt/md0/boot/grub/grub.cfg dans notre hypothèse de travail).

Ne changez pas les mentions de :

set root=

qui correspondent à votre partition boot originale. L'idée est que grub va utiliser au démarrage l'installation de grub sur la partition originale, que nous savons en état de marche, pour ensuite monter le volume raid “$(vol_id /)” sur “/”.

Changez les mentions de (racine “/”) :

root=

par: root=/dev/md0 ou root=UUID=“$(vol_id /)” si vous préférez utiliser les UUID ici aussi.

  • Faites les mêmes modifications sur la partition racine originale (/dev/sda1 montée sur /mnt/sda1 par exemple). Vous pouvez simplement copier les fichier fstab, mtab et grub.cfg que vous venez d'éditer sur le volume raid. (comme ça vous recopierez vos éventuelles erreurs, mais n'en ferez pas de nouvelles ! ;-) )

Quand tout ça vous paraît esthétiquement réussi, redémarrez le système.

Une fois le système démarré, vérifiez que la partition racine originale et la partition /home originale (ou toutes celles qui concernent votre partitionnement) ne soient pas montées. La commande “mount” appelée sans argument doit vous lister vos volumes raid comme étant monté sur “/”, “/home”, …etc.
Si vous êtes adeptes des interfaces graphiques, Gparted vous renseignera très bien. Un petit symbole “cadenas” en regard d'une partition signifie qu'elle est montée, comme Gparted ne “voit” pas les volumes raid, il ne devrait vous indiquer aucune partition comme montée (les versions récentes de Gparted prennent en compte les groupes raid, mais n'essayez pas d'intervenir directement dessus par ce biais).

On en est où ?

Nous en sommes à la dernière étape, le système fonctionne maintenant sur les volumes raid, mais ceux-ci sont encore en mode “dégradé” car ils ne fonctionnent que sur un disque. Reste à ajouter à ces volumes raid les partitions du disque d'origine.
Cette étape constitue le point de non-retour, le contenu du disque original va être écrasé par celui du volume raid existant lors de la phase de “synchronisation”. Si vous êtes arrivé jusque là sans problème il n'y a pas trop d'appréhension à avoir !

  • Réunion des partitions en volumes raid :

Lors de la création des groupes raid nous avons désigné une des partitions comme “missing” (manquante), c'est le moment de l'ajouter réellement.
Nous gardons l'hypothèse que /dev/sda est votre disque “original” :

# mdadm /dev/md0 --add /dev/sda1

Cette commande ajoute au groupe raid “md0” la partition sda1. La synchronisation est immédiate, les fichiers présents sur le raid sont recopiés à l'identique sur sda1. Cette phase peut-être longue, en fonction de la taille des partitions. Chez moi cela à pris 1h30 pour 500GB environ. Vous aurez un avertissement concernant la présence d'un système de fichiers sur la partition ajoutée au groupe raid, continuez.
Vous pouvez suivre l'avancement du processus avec :

# watch "cat /proc/mdstat"

Vous pouvez assembler tous les groupes raid à la suite, leur synchronisation sera mis en file d'attente, ça permet d'aller faire autre chose. Le système reste utilisable, mais toute activité allonge la durée de la synchronisation.

  • Toilettage final :

Il reste à s'assurer que l'on pourra bien redémarrer sur le raid, ça se fait en vérifiant les fichiers /etc/fstab , /etc/mtab et /etc/grub.cfg. Dans ce dernier vous devrez modifier les directives “set root=” en :

set root=(md0)

Si /dev/md0 est votre groupe raid qui porte la racine “/” du système. Vous n'avez théoriquement rien à faire pour les deux autres fichiers (fstab, mtab), juste y jeter un œil par sécurité.

Reste à générer l'initrd définitif, installer grub sur le groupe raid, et mettre à jour le grub.cfg :

# update-initramfs -u -k $(uname -r)
# grub-install --recheck "(hd0)"
# update-grub2

C'est fini… sauf si

Problèmes possibles (et leurs solutions ;-) )

  • “Ça ne marche pas”, enfin disons que vous obtenez une erreur “grub”. Redémarrez sur un live-cd, remontez les groupes raid (attention, vous ne devez plus travailler directement sur les partitions !), et vérifiez les points précédent. Regardez particulièrement :
  • dans grub.cfg » “set root=” , “root=” , “search –fs-uuid –set” vérifiez l'UUID de la partition racine, vérifier la présence de la directive “insmod raid1” .
  • dans fstab » Vérifiez l'UUID de la partition racine.
  • Si vous bloquez toujours, vous devrez chrooter sur la partition racine, et ré-exécuter grub-install et update grub.

On considère que la partition racine est montée sur /mnt/md0 :

# mount -o bind /dev /mnt/md0/dev
# chroot /mnt/md0 bin/bash
# install-grub --recheck "(hd0)"
# update grub
# exit
  • Grub se passe bien, mais l'initrd vous donne “waiting for root filesystem” et se bloque.
  • Vérifiez le fstab, et grub comme cas précédent.
  • Vérifiez que /etc/initramfs-tools/modules contient bien “raid1” et “md_mod”, et reconstruisez l'initrd en chrootant sur la partition racine comme précédemment (commande “update-initramfs -u -k all”).
  • fsck bloque le démarrage, et/ou fsck et fdisk vous donnent des erreurs concernant la taille du système de fichier, la table des partitions et le superblock.

Là vous êtes victime d'une “subtilité” qui ressemble fort à un bug. Lorsque l'on crée un groupe raid en mode “missing”, et qu'un système de fichier est déjà présent sur le disque, il semble que mdadm “ajoute” parfois la taille des superblocks créés à celle du système de fichier. Comme le disque est déjà entièrement occupé, c'est impossible, les superblocks résident en fait sur le système de fichier, et l'information de taille contenue dans ces superblocks est fausse.
La taille du volume raid /dev/md*, reportée par le superblock, ne correspond pas à celle des systèmes de fichier sur les disques (/dev/sd*) reportée par leurs tables des partitions.

Cette situation n'est pas catastrophique dans l'immédiat, si vous désactivez les vérification fsck au démarrage tout se passera normalement… jusqu'à ce que le système essaie d'écrire des données là où réside le superblock ! À ce moment l'accès sera refusé, le système risque de planter et vous risquez de perdre des données. Sans compter que désactiver fsck sur un système de fichiers journalisé n'est vraiment pas une bonne idée.

La solution passe par l'assemblage des groupes raid sur un live-cd, la correction des blocks dont le statut est éronné, et le redimensionnement du système de fichier :

# mdadm -Ac partitions -m0 /dev/md0
# e2fsck -cc /dev/md0
# resize2fs /dev/md0
# fsck -f /dev/md0

L'inconvénient c'est que le “e2fsck -cc”, qui détecte et corrige les blocks qui ne sont pas dans un état “propre”, est lent. Chez moi il a fallu un peu moins de 10 heures pour 500 GB

Après cette opération tout devrait rentrer dans l'ordre, et le volume raid pourra être vérifié avec fsck lors du démarrage.
Au fait, j'ai précisé qu'il fallait avoir une sauvegarde des données ? ;-)

Méthode alternative de création du raid

Plutôt que de chercher à recopier la table de partition du disque original, ce qui nécessite de réduire les systèmes de fichiers auparavant ou expose à des problèmes, il peut être plus intéressant de procéder comme suit :

  • Sur le nouveau disque (celui qui ne contient pas de données) créez les partitions souhaitées, ne créez aucun système de fichiers (pas de formatage). Dans “Gparted” vous pouvez choisir “aucun système de fichier”, en console “fdisk” permet de créer une partition sans système de fichier également. Notez soigneusement les caractéristiques de vos partitions, vous pouvez utiliser “sfdisk -d /dev/sd* > infopart.txt” pour obtenir des informations détaillées.
  • Créez les groupes raid en mode dégradé, en y incluant uniquement les partitions (sans système de fichier) que vous venez de créer.
  • Créez les systèmes de fichiers sur les groupes raid (qui ne contiennent qu'une partition chacun pour le moment), par exemple avec :
# mkfs.etx4 /dev/md0

Ici on crée un système de fichier “ext4” sur le périphérique raid “/dev/md0”.

  • Copiez les données de vos partitions originales sur les groupes raid.
  • Créez sur le disque original un partitionnement identique à celui du disque qui forme le raid. “sfdisk” peut prendre en entrée le fichier créé avec “sfdsik -d” précédemment.
  • Ajoutez les partitions du disque original aux groupes raid, et laissez synchroniser.

De cette façon on évite les risque de problèmes liés à l'ajout de superblock raid sur un système de fichier existant.

Annexe pour les utilisateurs de "grub-legacy"

(le “vieux” grub, pas grub2)

Le grub traditionnel ne supporte pas l'option “insmod”, sa modification se borne à changer la désignation de la partition racine “/”, et à le réinstaller sur le volume raid en le faisant démarrer depuis le “nouveau” disque.

Éditez /boot/grub/menu.lst et changez la désignation de la partition root (root=/dev/sda1 » root=/dev/md0). Vous pouvez utiliser “root=LABEL=monlabel” ou “root=UUID=uuid_de_la_partition”. Laissez le reste tel quel. En console exécutez :

# grub
device (hd0) /dev/sdb
root (hd0,0)
setup (hd0)
quit

L'exemple suppose que /dev/sdb1 est la nouvelle partition racine, intégrée au groupe raid, et sur laquelle vous souhaitez redémarrer. Il semble qu'il soit nécessaire de ré-exécuter la commande pour les deux disques après addition du disque original. C'est la seule façon d'identifier les deux disques qui composent le volume raid comme cibles de démarrage possibles. Grub ne supporte pas le fait d'indiquer deux périphériques comme “(hd0)” dans le fichier /boot/grub/device.map.

De cette façon si un disque est défaillant, il sera possible d'amorcer le système sur le second, et c'est alors l'initrd qui charge les modules raid.

Si vous souhaitez modifier le fichier /boot/grub/menu.lst pour y intégrer une option de démarrage de secours (fallback) sur le deuxième disque :

  • Après la ligne default 0 ajoutez une nouvelle ligne avec fallback 1
  • Changez la ligne des options permanentes du noyau “kopt” pour obtenir # kopt=root=/dev/md0 ro
  • Copiez/collez l'entrée qui concerne votre système, ajoutez là en deuxième position du menu, et changez root=(hd0,0) pour root=(hd1,0) dans cette deuxième entrée.
  • Vérifiez que la directive root=/dev/md0 est bien présente dans les deux entrées sur la ligne “kernel”.

De cette façon, en cas de défaillance du disque de démarrage /dev/sda, grub amorcera sur le second disque /dev/sdb automatiquement.

Liens

expert/systeme_conversion_raid1.txt · Dernière modification: 2014/05/09 18:56 (modification externe)