Qui n’a jamais eu un serveur hors-service à cause d’une ligne fstab qui indique un disque de données absent ? Voici comment éviter cette mésaventure et améliorer la résilience de ses serveurs en cas de disque HS ou débranché (hors disque système).

Un fstab cassé, c’est un serveur qui ne boote pas

J’utilise Linux en environnement serveur depuis de nombreuses années, et j’ai souvent été confronté à mes erreurs dans le fichier fstab qui empêchent de booter correctement avec un basculement en mode « rescue ». En cas de disque dur de données défaillant, de disque débranché ou extrait de son rack hot-swap, c’est la même chose. Et le pire, c’est qu’une erreur fstab peut passer inaperçue plus d’un an pour se manifester à un reboot imprévu.

Lorsque cela se produit sous Debian, la console écran affiche les mentions suivantes :

Vérifier le fstab en prévision du boot

Dans ce contexte où la moindre erreur fstab peut provoquer un serveur HS. Voici comment on peut tester son fstab, par exemple la ligne suivante.

Pour commencer je démonte le système de fichier s’il est monté et je le remonte comme ceci :

Je n’ai pas précisé quel filesystem monter dans /data. Si le fstab est correct, cela doit aboutir à un montage correct (commande df  ou mount  pour s’en assurer). Si le fstab n’est pas correctement renseigné pour le point de montage /data, le filesystem ne se monte pas.

Ne pas passer en mode emergency

Encore mieux dans le cas de disques extractibles ou tout simplement externes (USB, eSATA), on peut indiquer au fstab de ne pas basculer tout le système en mode emergency (ou failover) en cas de système de fichiers manquant. Pour cela les deux options en or sont, dans le bon ordre : nofail, auto . Sources : askubuntu.com, reddit.com. Je n’utilise ces options de montage que pour les disques durs non critiques, les disques durs de stockage de données, et jamais le disque système.

Exemple :

Après avoir essayé, l‘option nofail seule est suffisante, même sans « auto » ni « defaults » (à noter que « defaults » comprend » auto »).

Le manuel de fsck le confirme :

fsck ne vérifie normalement pas l’existence du périphérique avant d’appeler un vérificateur de système de fichiers spécifique. Par conséquent les périphériques inexistants risquent d’entraî‐
ner le système en mode de réparation de système de fichiers au démarrage si le vérificateur de système de fichiers spécifique renvoie une erreur fatale. L’option de montage nofail de
/etc/fstab peut être utilisée pour que fsck ignore les périphériques inexistants.

Il en va de même pour le manuel de fstab :

nofail ne pas renvoyer d’erreur pour ce périphérique s’il n’existe pas.

Par précaution j’utilise ces options sur tous mes disques extractibles ou externes, car il vaut mieux un serveur qui boote coute que coute plutôt qu’un serveur en mode emergency qui ne sert à rien ! Un matériel de type KVM ou IPMI peut permettre de récupérer le serveur à distance, mais si on peut s’en passer…

Contrôler l’intégrité des systèmes de fichiers au boot

Si comme moi, vos serveurs passent des centaines de jours en fonctionnement non-stop, vous voudrez peut-être profiter de chaque reboot pour forcer un fsck. Pour cela je vous propose de déposer un fichier nommé « forcefsck » à la racine de chaque système de fichiers. Les paramètres de fréquence de fsck sont également configurables en nombre de jours ou nombre de montages avec tune2fs.