Vérifier le disque de données avant de lancer les services

Lorsqu’un disque de données ne se monte pas, l’application ne signale pas forcément une erreur immédiatement. Le répertoire /srv/data, prévu comme point de montage, reste un simple répertoire du disque système. Le service peut donc continuer à y écrire jusqu’à saturer ce disque. Une fois le montage rétabli, ces fichiers sont masqués par le système de fichiers monté, laissant deux ensembles de données difficiles à distinguer. Avant la mise en service, il faut vérifier le système de fichiers associé au chemin, et pas seulement l’existence du répertoire.

1. Identifier le disque de données et délimiter les opérations

Les exemples de cet article utilisent Ubuntu Server 24.04 LTS et une partition de données disposant déjà d’un système de fichiers ext4. Aucune opération de partitionnement ou de formatage n’est effectuée. Les commandes s’exécutent sur le serveur via SSH ; les informations de connexion CloudSFP sont consultables dans la console après paiement. Si plusieurs adresses sont indiquées, utilisez la première.

La configuration standard comprend deux disques NVMe de 1 To, chacun raccordé directement, sans RAID matériel. Le numéro d’un périphérique ne permet pas de savoir s’il s’agit du disque système ou du disque de données, ni d’en déduire une quelconque redondance. Si un RAID logiciel ou une autre couche de stockage est déjà en place, il faut monter le système de fichiers de la couche supérieure, et non un disque membre en contournant cette couche.

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
sudo blkid
findmnt -T /
findmnt -T /srv

Identifiez la partition cible en recoupant sa capacité, son type de système de fichiers, ses points de montage actuels et les notes d’installation, puis consignez son UUID. Un UUID est plus stable qu’un nom attribué au périphérique lors de sa détection, mais il n’est pas nécessairement unique : le clonage d’un système de fichiers peut aussi copier son UUID. En cas de doublon, résolvez d’abord le conflit d’identification avant de renseigner la configuration de démarrage.

Les modifications suivantes doivent être réalisées avant l’utilisation du disque de données en production. Sur une machine déjà en service, il faut d’abord arrêter les écritures, vérifier les sauvegardes et la procédure de restauration. Ne démontez jamais un système de fichiers en cours d’utilisation simplement pour effectuer un test.

2. Tester le montage avant de l’inscrire dans fstab

Créez un point de montage vide et vérifiez qu’il ne contient aucun fichier, y compris caché. Si le répertoire n’est pas vide, déterminez d’abord l’origine de son contenu, sans rien supprimer ni écraser.

sudo mkdir -p /srv/data
sudo find /srv/data -mindepth 1 -maxdepth 1 -print
read -r -p 'Filesystem UUID: ' DATA_UUID
sudo blkid -U "$DATA_UUID"
sudo mount -t ext4 -o ro "UUID=$DATA_UUID" /srv/data
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID

Ne poursuivez le montage que si la sortie de blkid correspond aux informations consignées pour le disque. Le premier montage, en lecture seule, sert à examiner le contenu ; ce n’est pas une méthode de réparation d’un système de fichiers endommagé. Ici, findmnt -M vérifie le point de montage exact. À l’inverse, findmnt -T recherche le système de fichiers qui contient le chemin : si le disque de données n’est pas monté, cette commande peut renvoyer le système de fichiers racine. Son seul code de retour réussi ne suffit donc pas à valider le montage.

Après avoir confirmé la source et le contenu, démontez le système de fichiers monté en lecture seule. Sauvegardez /etc/fstab, puis modifiez ce fichier ; n’ajoutez pas plusieurs entrées pour le même point de montage. L’UUID de l’exemple doit être remplacé par la valeur réelle que vous venez de vérifier :

UUID=<已核对的文件系统UUID> /srv/data ext4 defaults,nofail,x-systemd.device-timeout=15s 0 2

Cette ligne permet au système de poursuivre son démarrage si le disque est absent. Le délai maximal d’attente du périphérique choisi pour cet exemple est de 15 secondes ; il ne constitue pas un engagement de délai de livraison ou de rétablissement. Si les exigences de l’application imposent de bloquer le démarrage du système en l’absence du disque, il faut définir une stratégie de démarrage adaptée plutôt que reprendre nofail tel quel.

sudo umount /srv/data
sudo cp -a /etc/fstab /etc/fstab.before-data-mount
sudoedit /etc/fstab
sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo mount /srv/data
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID

Si la validation échoue, corrigez d’abord la configuration et ne poursuivez pas le montage. Montez uniquement le chemin cible afin qu’un montage global ne masque pas d’autres problèmes de configuration. Une syntaxe valide ne garantit pas non plus que le périphérique soit disponible : le résultat du montage réel doit encore être contrôlé.

3. Lier le démarrage du service au montage

nofail règle le comportement du système au démarrage, mais ne protège pas l’application. Le service qui utilise le répertoire de données doit déclarer une dépendance de montage. Dans l’exemple, app.service représente une unité applicative réellement existante : remplacez ce nom par celui de votre service et vérifiez que cette unité lance bien le processus qui effectue les écritures.

Exécutez sudo systemctl edit app.service, puis ajoutez :

[Unit]
RequiresMountsFor=/srv/data
AssertPathIsMountPoint=/srv/data

RequiresMountsFor déclenche les montages nécessaires à l’accès au chemin et définit l’ordre de démarrage. L’assertion empêche le lancement lorsque le répertoire existe sans être un point de montage. Ces deux directives ne permettent ni de détecter un mauvais disque ni de remplacer les contrôles de cohérence des données effectués par l’application. La vérification de la source à partir de l’UUID reste donc une étape distincte.

sudo systemctl daemon-reload
sudo systemctl cat app.service
sudo systemctl show app.service -p Requires -p After

Vérifiez que la configuration complémentaire de l’unité est bien appliquée et que le répertoire de données réellement utilisé par l’application se trouve sous /srv/data. Si un script de démarrage redirige les écritures vers un autre chemin, une dépendance correcte ne suffit pas à empêcher l’écriture au mauvais endroit. Les tâches planifiées, les scripts lancés manuellement et les autres services n’héritent pas automatiquement de ces contraintes : chacun doit être vérifié séparément.

Ne créez les sous-répertoires applicatifs qu’après un montage réussi, puis définissez leur propriétaire et leurs permissions selon le compte réellement utilisé par le service. N’accordez pas à tous les comptes un droit d’écriture sur l’ensemble du disque de données et n’inscrivez pas d’identifiants de connexion dans la configuration de montage.

4. Tester l’absence du disque et le rétablissement avant les premières écritures en production

Ce test doit être effectué avant la présence de données de production et en l’absence d’écritures actives. Arrêtez d’abord l’application, puis l’unité de montage du disque de données. Vous pouvez vérifier le nom de l’unité correspondant à /srv/data avec systemd-escape --path --suffix=mount /srv/data ; pour les chemins complexes, ne tentez pas de le deviner manuellement.

sudo systemctl stop app.service
sudo systemctl stop srv-data.mount
sudo systemctl mask --runtime srv-data.mount
sudo systemctl start app.service
sudo systemctl status app.service srv-data.mount --no-pager

Le masquage temporaire de l’unité simule l’indisponibilité du montage et empêche son rétablissement automatique au lancement de l’application. Le résultat attendu est un échec du démarrage, sans processus applicatif en cours d’exécution. Si le démontage indique que le système de fichiers est occupé, identifiez ce qui l’utilise ; ne contournez pas cette vérification par un démontage forcé ou différé.

À ce stade, vérifiez qu’aucun nouveau fichier n’est apparu dans le répertoire /srv/data sous-jacent. Une fois le test terminé, retirez d’abord le masquage, puis rétablissez le montage :

sudo systemctl unmask --runtime srv-data.mount
sudo systemctl start srv-data.mount
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID
sudo systemctl reset-failed app.service
sudo systemctl start app.service

Le rétablissement n’est considéré comme terminé que si la source correspond au disque attendu et si le contrôle de bon fonctionnement de l’application réussit. À la fin de la validation, assurez-vous impérativement que le masquage temporaire a été retiré. Les dépendances de démarrage protègent principalement la phase de lancement ; elles ne détectent pas les défaillances du disque pendant l’exécution. La suite de l’exploitation nécessite aussi une gestion des erreurs dans l’application et une supervision.

5. Conserver un compte rendu de mise en service vérifiable

Le compte rendu doit inclure l’identité du disque, son UUID, le point de montage, le type de système de fichiers, les modifications de fstab, la configuration complémentaire du service et les résultats du test d’absence du disque. Prévoyez une validation après redémarrage avant la mise en production, afin de confirmer que le montage se termine avant le lancement du service. Un montage manuel réussi à un instant donné ne remplace pas la vérification du démarrage.

Si l’occupation du disque système semble anormale après le montage, vérifiez d’abord si d’anciens fichiers sont masqués par le système de fichiers monté. Il faut arrêter les écritures concernées et organiser une inspection. Ne démontez pas le système de fichiers sur une machine en service pour supprimer immédiatement ces fichiers, et ne fusionnez surtout pas à l’aveugle le contenu du répertoire sous-jacent avec celui du disque de données.

Les critères de validation finale sont les suivants : la source est correcte, le chemin est bien un point de montage, les dépendances du service sont actives, aucune écriture n’a lieu au mauvais endroit en l’absence du disque et le contrôle de bon fonctionnement réussit après rétablissement. La configuration de montage n’apporte ni redondance ni sauvegarde ; ces deux aspects doivent être conçus et validés séparément.

Questions fréquentes