Dès lors qu’un serveur est en production, le temps d’indisponibilité devient un critère important quand une opération de maintenance doit être prévue. Un client a souhaité migrer son système d’un disque SSD à un disque classique parce que la taille du SSD était insuffisante pour son utilisation.

Le disque SSD contenait l’ensemble des données du serveur et par chance le disque dur était monté dans le dossier « /hdd » et ne contenait aucune donnée.

Afin de réduire le temps d’indisponibilité, il fallait effectuer le maximum d’opération avec le serveur en ligne. J’ai donc mis en place la procédure décrite dans les paragraphes suivants.

Préparation du disque dur

L’ensemble du disque dur est un LVM que j’ai démonté puis détruit :

umount /dev/hdd/data
lvremove /dev/hdd/data
vgremove hdd
pvremove /dev/sdb1

Il faut ensuite partitionner le disque dur pour correspondre au besoin : ici, comme LVM est utilisé pour tout sauf la partition racine, j’ai recréé à l’aide de parted la même structure pour disposer de la même liberté par la suite :

parted /dev/sdb

Voici le partitionnement final qui a été mis en place :

Model: Adaptec Volume#1 (scsi)
Disk /dev/sdb: 3760GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 32.3kB 4302MB 4302MB
2 4302MB 6457MB 2155MB
3 6457MB 3760GB 3754GB lvm

Il a fallu ensuite recréer le LVM, en créant dans l’ordre le volume physique, le groupe de volume et les volumes logiques :

# Création du volume physique
pvcreate /dev/sdb3
# Création du groupe de volume
vgcreate hdd /dev/sdb3
# Création des volumes logiques, avec une taille initiale de 4 Go
lvcreate -L4G -n usr hdd
lvcreate -L4G -n var hdd
lvcreate -L4G -n home hdd

Il faut à présent mettre en place des systèmes de fichiers sur les différents volumes logiques et sur la partition racine :

mkfs.ext3 /dev/sdb1
mkfs.ext4 /dev/hdd/home
mkfs.ext4 /dev/hdd/usr
mkfs.ext4 /dev/hdd/var

Ce sont les mêmes systèmes de fichiers que sur le SSD qui ont été mis en place sur le disque dur.

Copie des données

La stratégie adoptée ici pour réduire la durée d’indisponibilité a été d’effectuer la copie des données en deux temps : d’abord une copie en ligne, puis une copie en système rescue, pour les fichiers qu’il n’est pas possible de copier lors que le système est démarré (ex : les bases de données MySQL). De ce fait, la partie la plus longue de la copie n’aura pas d’impact sur la disponibilité du serveur.

La première étape est de monter la future partition racine dans « /mnt » et de recréer la même structure de dossiers sur la racine du disque dur que sur la racine du SSD :

mount /dev/sdb1 /mnt/
for f in `find / -maxdepth 1 -type d` ; do mkdir /mnt$f ; done

❗ Attention : cette commande ne fonctionnera que pour les systèmes où l’ensemble des points de montages sont à la racine.

On monte à présent l’ensemble des partitions du disque dur sur la structure créé dans « /mnt » :

mount /dev/hdd/home /mnt/home/
mount /dev/hdd/var /mnt/var/
mount /dev/hdd/usr /mnt/usr/
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc

La copie sur le système démarré peut à présent commencer : rsync est particulièrement bien adaptée, car il permet d’exclure facilement des dossiers (comme /proc, /sys, /dev et bien sur /mnt) et de conserver les permissions et attributs des fichiers :

rsync --progress --exclude="/mnt/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/dev/*" -v -a -c -r -H -A -X / /mnt/

Une fois la copie sur le système démarré terminé, il faut placer le serveur en système rescue et lancer la copie hors-ligne pour récupérer les fichiers modifiés, ou impossible à copier en ligne. Il faut dans un premier temps monter l’ensemble des partitions du SSD dans « /ssd » et l’ensemble des partitions du disque dur dans « /mnt ». Il reste ensuite à lancer la commande suivante :

rsync --progress --exclude="/mnt/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/dev/*"  -v -a -c -r -H -A -X /ssd/ /mnt/

❗ Attention : La présence des « / » à la fin des chemins est indispensable : les omettre créerait un dossier « /ssd » dans le dossier « /mnt », ce qui n’est évidemment pas le but de la manoeuvre !

Préparation au démarrage sur le disque dur

Une fois les données copiées, il reste encore quelques petites modifications à effectuer pour que le système sur le disque dur soit prêt. Pour éviter toute confusion dans les fichiers à modifier, autant se « chrooter » directement sur le disque dur :

mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt/

Il faut dans un premier temps éditer le fichier /etc/fstab pour supprimer les références au SSD et les remplacer par le disque dur :

vi /etc/fstab

Il faut également corriger le chargeur d’amorçage GRUB pour qu’il utilise le disque dur comme racine lors du prochain démarrage. Il faut pour cela éditer le fichier de configuration de GRUB :

vi /boot/grub/menu.lst

Il reste à présent à installer la nouvelle configuration de GRUB sur le SSD pour pouvoir démarrer sur le disque dur :

grub-install /dev/sda

Au prochain redémarrage, le serveur démarrera sur le disque dur. L’ensemble des données ont été conservées sur le SSD, afin de pouvoir redémarrer sur le SSD en cas d’erreur durant la procédure !