Debian 13 : Système de fichiers monté en lecture seule après des erreurs — étapes de récupération minimisant les dégâts

octobre 7, 2025 • février 3, 2026 • Lecture : 35 min • Views: 9

Cet article vous a aidé ?

Une minute votre service fonctionne correctement. La minute suivante il est incapable d’écrire des fichiers PID, les logs ne progressent plus et votre pipeline de déploiement crie « Read-only file system ». Le noyau n’est pas devenu poétique du jour au lendemain ; il protège vos données en refusant d’aggraver la situation.

Ce guide explique ce qu’il faut faire ensuite sur Debian 13 quand un système de fichiers passe en lecture seule après des erreurs. Pas de folklore « lancez fsck et priez ». Des étapes réelles pour limiter les dégâts : diagnostiquer le mode de défaillance, préserver les preuves, choisir la réparation la moins destructive, et seulement ensuite remettre des écritures en production.

Ce que signifie vraiment « monté en lecture seule » (et ce que ça ne signifie pas)

Sur Debian 13 (et Linux en général), le passage d’un système de fichiers en lecture seule est généralement la décision du noyau ou du pilote du système de fichiers, estimant que continuer à écrire risquerait de transformer un problème récupérable en perte permanente. Pensez-y comme un disjoncteur pour l’intégrité des métadonnées.

Deux façons courantes d’en arriver là

Remontage automatique en lecture seule : le système de fichiers était monté en lecture-écriture, a rencontré une erreur sérieuse, et le noyau l’a remonté en lecture seule (ext4 le fait souvent). Vous verrez des logs du type « Remounting filesystem read-only » ou « Aborting journal. »
Monté en lecture seule dès le départ : problème au démarrage, option de montage explicite ro, mode d’urgence systemd ou logique initramfs décidant qu’il est plus sûr de rester en lecture seule jusqu’à réparation.

Ce que cela ne garantit pas

Être en lecture seule ne veut pas dire « les données sont sûres. » Cela signifie « nous avons arrêté d’empirer les choses. » Si le disque sous-jacent est en train de lâcher ou si votre RAID est dégradé et continue d’accepter des écritures aux mauvais endroits, vous pouvez tout à fait perdre encore des données rien qu’en lisant agressivement (timeouts, réinitialisations, bogues du contrôleur, etc.).

De plus : un montage en lecture seule n’empêche pas tous les types de changement d’état. Certains sous-systèmes peuvent toujours mettre à jour des éléments hors du système de fichiers (caches d’écriture du périphérique, métadonnées RAID, tables de microcode du disque). Donc l’état d’esprit doit être : préserver les preuves, minimiser les écritures et agir délibérément.

Faits et historique : pourquoi Linux agit ainsi

Un peu de contexte aide à prendre de meilleures décisions à 3 h du matin. Voici des faits courts et concrets expliquant pourquoi votre machine Debian se comporte de façon « surprotectrice ».

ext2 ne journalisait pas. Autrefois, une coupure de courant signifiait de longs fsck et une chance non négligeable de perdre des métadonnées. Les systèmes de fichiers journalisés (ext3/ext4) ont réduit ça mais introduit le concept d’« abort journal ».
ext3 a rendu le journaling courant sous Linux. ext3 (début des années 2000) a intégré le journaling à la lignée ext ; ext4 a ensuite amélioré l’allocation et l’échelle tout en conservant la soupape de sécurité « abort journal puis remount ro ».
XFS vient du monde UNIX haut de gamme. XFS a été créé chez SGI et a une vision stricte de l’intégrité des métadonnées. Lorsqu’il détecte une corruption, il force souvent une mise hors service pour arrêter davantage de dégâts.
Btrfs considère les sommes de contrôle comme primordiales. Il peut détecter la corruption silencieuse via des checksums, et avec redondance se réparer. Sans redondance, les checksums vous indiquent surtout que vous êtes en mauvaise posture.
Le VFS du noyau cherche à garder le système vivant. Remonter un seul système de fichiers en lecture seule est souvent moins perturbant qu’un panic du noyau ou un crash brutal du nœud.
Les caches d’écriture des disques peuvent vous mentir. Un disque peut accuser réception d’une écriture avant qu’elle ne soit réellement sur un stockage stable. Perte de courant plus comportement du cache = recette classique de problèmes de journal.
Les contrôleurs RAID peuvent « aider » de façon nuisible. Certains firmwares de contrôleur réessaient, remappent ou réordonnent des opérations, masquant des problèmes jusqu’à ce que le système de fichiers trébuche sur des résultats incohérents.
« Errors=remount-ro » est une politique, pas une fatalité. Pour ext4, l’option de montage errors=remount-ro indique au noyau quoi faire lors de certaines erreurs. Vous pouvez choisir panic ou continuer, mais « continuer » est la voie vers la corruption créative.

Une citation pour garder les mains calmes : L’espoir n’est pas une stratégie. (idée paraphrasée, couramment citée dans les équipes d’exploitation)

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est la séquence « arrêtez de deviner ». L’objectif est d’identifier quelle couche échoue : métadonnées du système de fichiers, périphérique bloc, RAID/LVM, ou quelque chose en amont comme un manque d’espace interprété à tort comme corruption.

Premier : confirmer la portée et l’impact (30–90 secondes)

Est-ce qu’un seul montage est affecté ou plusieurs ?
Le système de fichiers racine est-il concerné ou seulement un volume de données ?
Les applications échouent parce qu’elles ne peuvent pas écrire, ou parce que le périphérique subit des timeouts ?

Deuxième : lire l’histoire que raconte le noyau (2–5 minutes)

Cherchez I/O error, Buffer I/O error, EXT4-fs error, XFS (dm-*) forced shutdown, réinitialisations NVMe, données SCSI sense.
Décidez s’il s’agit d’une défaillance média (matériel) ou d’une défaillance métadonnée/consistance (niveau système de fichiers).

Troisième : décider si vous pouvez rester en ligne ou devez arrêter les écritures immédiatement

Si vous voyez des réinitialisations répétées du périphérique, des erreurs média ou une dégradation RAID : priorisez l’imagerie/sauvegarde et minimisez les lectures/écritures.
Si c’est un abort propre du journal après un arrêt brutal et que le disque est sain : planifiez une fenêtre de réparation contrôlée.

Règle : Si vous ne savez pas encore si le périphérique bloc est stable, n’exécutez pas d’outils de réparation destructeurs. Une « réparation » sur un disque défaillant est souvent un moyen rapide de transformer des données partielles en confettis.

Stabiliser le patient : arrêter l’hémorragie sans paniquer

Quand un système de fichiers est en lecture seule, la tentation est de le remonter en lecture-écriture et de continuer. C’est une excellente façon d’apprendre à quoi ressemble la corruption. Vous voulez faire l’inverse : réduire les variables.

Priorités de stabilisation

Capturer les preuves : logs du noyau, état des montages, statut RAID/LVM, santé SMART/NVMe.
Arrêter les écritures inutiles : arrêter les services bruyants, désactiver le spam de logs, éviter les « scripts de nettoyage » qui agressent le disque.
Décider d’un périmètre sûr pour snapshot/sauvegarde : snapshot LVM, snapshot VM, snapshot du stockage, ou au moins une copie fichier des états critiques.
Ensuite seulement, réparer : choisissez l’outil adapté à votre système de fichiers et scénario.

Blague #1 : Le système de fichiers est passé en lecture seule parce qu’il aime vos données plus que votre disponibilité. C’est le seul sous-système du serveur avec des limites saines.

Tâches pratiques (commandes, signification des sorties, décisions)

Voici des tâches pratiques à exécuter sur Debian 13. Chacune inclut : une commande, ce que signifie une sortie typique, et la décision à prendre. Utilisez-les comme une checklist d’incident, pas comme un buffet.

Task 1: Verify what is actually mounted read-only

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | sed -n '1,5p'
TARGET SOURCE        FSTYPE OPTIONS
/      /dev/sda2     ext4   rw,relatime,errors=remount-ro
/var   /dev/vg0/var  xfs    ro,relatime,attr2,inode64,logbufs=8,logbsize=32k
/home  /dev/sdb1     ext4   rw,relatime

Ce que cela signifie : /var est actuellement monté ro. Le root est encore rw, mais a errors=remount-ro donc il peut basculer aussi.

Décision : Évaluer le rayon d’impact. Si seul un montage de données est ro, vous pouvez maintenir le système en marche pendant le diagnostic. Si le root est ro, préparez le mode maintenance.

Task 2: Confirm the kernel remounted it read-only (and why)

cr0x@server:~$ journalctl -k -b --no-pager | tail -n 40
Dec 29 02:11:06 server kernel: XFS (dm-2): metadata I/O error in "xlog_iodone" at daddr 0x1a2c8 len 16 error 5
Dec 29 02:11:06 server kernel: XFS (dm-2): Log I/O Error Detected. Shutting down filesystem
Dec 29 02:11:06 server kernel: XFS (dm-2): Please unmount the filesystem and rectify the problem(s)
Dec 29 02:11:06 server kernel: XFS (dm-2): Corruption of in-memory data detected. Shutting down filesystem
Dec 29 02:11:07 server kernel: XFS (dm-2): Filesystem has been shut down due to log error (0x2).
Dec 29 02:11:07 server kernel: systemd-journald[301]: Failed to write entry (22 items, 812 bytes), ignoring: Read-only file system

Ce que cela signifie : XFS a rencontré une erreur I/O de log. Ce n’est souvent pas « XFS est cassé », mais « la couche bloc n’a pas délivré des lectures/écritures cohérentes ». L’erreur 5 est EIO.

Décision : Traitez d’abord comme une possible instabilité du stockage. Ne vous précipitez pas sur xfs_repair avant d’avoir vérifié les périphériques sous-jacents.

Task 3: Check for obvious device errors and resets

cr0x@server:~$ dmesg -T | egrep -i 'blk_update_request|I/O error|reset|nvme|medium error|critical medium|sense key' | tail -n 30
[Sun Dec 29 02:10:58 2025] nvme nvme0: I/O 112 QID 4 timeout, aborting
[Sun Dec 29 02:10:58 2025] nvme nvme0: Abort status: 0x371
[Sun Dec 29 02:10:59 2025] nvme nvme0: Resetting controller
[Sun Dec 29 02:11:06 2025] blk_update_request: I/O error, dev dm-2, sector 171720 write
[Sun Dec 29 02:11:06 2025] XFS (dm-2): Log I/O Error Detected. Shutting down filesystem

Ce que cela signifie : Timeouts NVMe et réinitialisations de contrôleur corrèlent avec l’arrêt du système de fichiers.

Décision : Supposez un problème de chemin matériel jusqu’à preuve du contraire. Planifiez d’abord une sauvegarde/image, puis la réparation.

Task 4: Map the affected mount to the real block device stack

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,PKNAME
NAME           TYPE  SIZE FSTYPE MOUNTPOINTS PKNAME
sda            disk  1.8T                    -
sda2           part  1.8T ext4   /           sda
nvme0n1        disk  1.9T                    -
nvme0n1p1      part    1G vfat   /boot/efi   nvme0n1
nvme0n1p2      part  1.9T LVM2_member        nvme0n1
vg0-var        lvm   800G xfs    /var        -
vg0-data       lvm  1000G ext4   /data       -

Ce que cela signifie : /var est un XFS sur un LV LVM reposant sur nvme0n1p2. Les erreurs disque mentionnées plus haut sont pertinentes.

Décision : Votre plan de réparation doit inclure des vérifications de santé NVMe et éventuellement déplacer les données hors de ce périphérique.

Task 5: Check LVM health and whether you can snapshot safely

cr0x@server:~$ vgs; lvs -a -o +devices
  VG  #PV #LV #SN Attr   VSize VFree
  vg0   1   2   0 wz--n- 1.90t 120.00g
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  var  vg0 -wi-ao---- 800.00g                                                     /dev/nvme0n1p2(0)
  data vg0 -wi-ao---- 1000.00g                                                    /dev/nvme0n1p2(204800)

Ce que cela signifie : Vous avez 120G libres dans le VG. C’est un espace potentiel pour un snapshot, mais les snapshots ne font pas de miracles : sur un périphérique instable, le churn CoW peut empirer la situation.

Décision : Si le périphérique est stable et que vous avez besoin d’un point de retour, prenez un snapshot. Si le disque subit des timeouts, évitez les snapshots et faites une sauvegarde/image externe à la place.

Task 6: Check NVMe health (NVMe devices)

cr0x@server:~$ nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x01
temperature                         : 49 C
available_spare                     : 96%
percentage_used                     : 21%
media_errors                        : 12
num_err_log_entries                 : 187
warning_temp_time                   : 0
critical_comp_time                  : 0

Ce que cela signifie : critical_warning 0x01 n’est pas bon, et media_errors est un indice formel. Le contrôleur admet des échecs au niveau NAND/média.

Décision : Traitez cela comme une défaillance imminente du périphérique. Priorisez la copie des données. Les réparations peuvent « fonctionner » mais laisser un composant à durée de vie limitée.

Task 7: Check SMART health (SATA/SAS devices)

cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'SMART overall|Reallocated_Sector|Current_Pending_Sector|Offline_Uncorrectable|CRC_Error_Count'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Ce que cela signifie : « PASSED » n’est pas une garantie. Les secteurs pending/uncorrectable indiquent que le disque n’a pas pu lire des données de façon fiable et ne les a pas remappées.

Décision : Si le système de fichiers affecté se trouve ici, prévoyez un remplacement et une migration des données. Sinon, gardez-le sous surveillance.

Task 8: Confirm free space and inode exhaustion (yes, this can cascade)

cr0x@server:~$ df -hT /var; df -i /var
Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var xfs   800G  799G  1.2G 100% /var
Filesystem          Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/vg0-var       0      0       0     - /var

Ce que cela signifie : XFS n’affiche pas les comptes d’inodes comme ext4, mais le point clé est l’utilisation à 100%. Des systèmes de fichiers pleins déclenchent des comportements applicatifs étranges et peuvent révéler des bugs latents, mais ils n’entraînent généralement pas à eux seuls un remontage en lecture seule.

Décision : Si le volume est plein, il faut libérer de l’espace après avoir stabilisé le périphérique et vérifié qu’il ne s’agit pas d’un scénario d’erreur I/O. Ne supprimez pas des fichiers au hasard sur un système de fichiers potentiellement corrompu à moins d’avoir décidé qu’il est sûr d’écrire.

Task 9: Check for RAID degradation (mdadm)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md0 : active raid1 sdb1[0] sdc1[1]
      976630336 blocks super 1.2 [2/2] [UU]

md1 : active raid10 sdd1[0] sde1[1] sdf1[2] sdg1[3]
      3906885632 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [>....................]  recovery =  5.1% (100000000/1953442816) finish=240.0min speed=120000K/sec

Ce que cela signifie : md1 est dégradé ([4/3]). Une reconstruction est en cours, ce qui entraîne une I/O lourde et peut amplifier des problèmes discrets de disque.

Décision : Envisagez de suspendre la reconstruction si elle aggrave la situation et que vous devez d’abord extraire des données. C’est à évaluer cas par cas ; ne la suspendez pas si vous êtes à un disque de la perte totale.

Task 10: Check systemd’s view (did you boot into emergency due to fsck?)

cr0x@server:~$ systemctl --failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
● systemd-fsck@dev-disk-by\x2duuid-1a2b.service loaded failed failed File System Check on /dev/disk/by-uuid/1a2b
● var.mount                 loaded failed failed /var

Ce que cela signifie : Une unité fsck au démarrage a échoué, et le montage a échoué. Debian peut basculer en mode d’urgence ou continuer avec des montages partiels selon la configuration.

Décision : N’enchaînez pas les redémarrages en espérant que ça « se règle tout seul ». Déterminez pourquoi fsck a échoué : mauvais périphérique, pilote manquant, corruption réelle ou disque qui lâche.

Task 11: Identify which process is still trying to write (and failing)

cr0x@server:~$ journalctl -b --no-pager | egrep -i 'Read-only file system|EROFS' | tail -n 20
Dec 29 02:11:07 server systemd[1]: Failed to start Rotate log files.
Dec 29 02:11:08 server nginx[1337]: open() "/var/log/nginx/access.log" failed (30: Read-only file system)
Dec 29 02:11:09 server postgres[2020]: could not write lock file "postmaster.pid": Read-only file system

Ce que cela signifie : Vos applications essaient frénétiquement d’écrire. Cela peut augmenter le bruit et la confusion (retries, timeouts, pannes en cascade).

Décision : Arrêtez proprement les services à forte activité d’écriture. La meilleure réparation se fait sur un système calme.

Task 12: If ext4: inspect filesystem state without writing

cr0x@server:~$ tune2fs -l /dev/sda2 | egrep -i 'Filesystem state|Errors behavior|Last mount time|Last checked|Mount count'
Filesystem state:         clean with errors
Errors behavior:          Remount read-only
Last mount time:          Sun Dec 29 02:05:10 2025
Last checked:             Wed Nov  6 10:12:44 2025
Mount count:              31
Maximum mount count:      -1

Ce que cela signifie : ext4 pense être « clean with errors », ce qui revient à « le journal dit d’arrêter la prétense de normalité ».

Décision : Planifiez un fsck hors ligne (système de fichiers démonté). Si le disque semble malsain, faites d’abord une image.

Task 13: If XFS: check whether the log needs replay (read-only check)

cr0x@server:~$ xfs_repair -n /dev/mapper/vg0-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed.
Mount the filesystem to replay the log, and unmount it before re-running xfs_repair.

Ce que cela signifie : XFS a détecté des transactions de log en attente. Normalement, le montage rejoue le log. Mais si l’I/O du log était problématique, le replay peut échouer ou relancer la mise hors service.

Décision : Si le périphérique est maintenant stable, vous pouvez tenter un montage (éventuellement en lecture seule) pour rejouer le log. Sinon, priorisez la sauvegarde/imagerie, puis envisagez xfs_repair en étant conscient qu’un forçage peut supprimer des données de log.

Task 14: If Btrfs: read-only check and scrub status

cr0x@server:~$ btrfs device stats /data
[/dev/sdb1].write_io_errs    0
[/dev/sdb1].read_io_errs     3
[/dev/sdb1].flush_io_errs    0
[/dev/sdb1].corruption_errs  1
[/dev/sdb1].generation_errs  0

Ce que cela signifie : Btrfs voit des erreurs de lecture et de la corruption. Avec redondance (RAID1/10), il peut s’auto-réparer ; sans redondance, il vous dit surtout « je peux détecter la pourriture, pas la guérir ».

Décision : Si le volume est redondant, lancez un scrub et remplacez le périphérique défaillant. Sinon, restaurez depuis la sauvegarde ou copiez ce que vous pouvez, puis recréez le système de fichiers.

Task 15: Make a safe, minimal “get me writable logs” workaround (tmpfs)

cr0x@server:~$ mount -t tmpfs -o mode=0755,size=512M tmpfs /mnt/tmp-logs
cr0x@server:~$ systemctl stop nginx postgresql
cr0x@server:~$ ln -sfn /mnt/tmp-logs /var/log

Ce que cela signifie : Vous redirigez les logs vers la RAM pour garder un nœud en vie pour le diagnostic sans écrire sur le système de fichiers suspect. C’est un pansement, pas un remède.

Décision : Utilisez ceci seulement si vous devez garder des services minimaux brièvement. Préférez basculer vers un autre nœud si vous en disposez.

Task 16: Capture a forensic snapshot of logs and state (low-risk)

cr0x@server:~$ mkdir -p /root/ro-incident
cr0x@server:~$ journalctl -b --no-pager > /root/ro-incident/journal.txt
cr0x@server:~$ findmnt -a > /root/ro-incident/findmnt.txt
cr0x@server:~$ lsblk -f > /root/ro-incident/lsblk.txt

Ce que cela signifie : Vous avez sauvegardé l’histoire tant qu’elle est fraîche. Si le prochain redémarrage renomme des périphériques ou que la machine ne revient pas, vous avez encore des indices.

Décision : Si le stockage est instable, copiez ce répertoire hors hôte (scp vers un bastion, attachez au ticket, etc.).

Stratégies de réparation par système de fichiers (ext4, XFS, Btrfs)

Les systèmes de fichiers ont des comportements de défaillance différents. Utiliser la mauvaise approche de réparation est la manière dont vous transformez un incident gérable en restauration de plusieurs jours. Votre principe directeur : réparer hors ligne autant que possible, et ne jamais réparer sur un périphérique que vous ne faites pas confiance.

ext4 : abort du journal et « errors=remount-ro »

ext4 remonte souvent en lecture seule après avoir détecté une erreur suffisamment sérieuse pour abréger le journal. Souvent déclenché par des erreurs I/O, parfois par des bogues, occasionnellement par « votre disque a renvoyé des données incohérentes ». ext4 est conservateur. Écoutez-le.

Chemin préféré pour ext4

Confirmez que la pile de périphériques est stable (SMART/NVMe, dmesg, état RAID).
Planifiez une indisponibilité ou démarrez en mode rescue pour démonter le système de fichiers cible.
Exécutez d’abord une vérification non destructive (fsck sans corrections automatiques si vous voulez de la visibilité).
Effectuez une passe de réparation, puis revérifiez.

cr0x@server:~$ umount /dev/sda2
umount: /: target is busy.

Signification : Vous ne pouvez pas démonter root en cours d’exécution. Utilisez un boot de secours, un shell initramfs ou attachez le volume à un autre hôte.

cr0x@server:~$ fsck.ext4 -f -n /dev/sda2
e2fsck 1.47.2 (1-Jan-2025)
/dev/sda2: clean, 812345/122101760 files, 44444444/488378368 blocks

Signification : « clean » est bon signe. S’il rapporte des erreurs en mode -n, vous avez une décision : réparer maintenant, ou image d’abord si le matériel est suspect.

cr0x@server:~$ fsck.ext4 -f -y /dev/sda2
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 1234567 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Entry 'tmp' in /var/tmp (98765) has deleted/unused inode 1234567.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****

Signification : Des réparations ont eu lieu. Vous devez maintenant relancer un fsck jusqu’à obtenir « clean », car la première passe peut révéler d’autres problèmes.

Décision : Si les erreurs apparaissent indéfiniment à chaque passage, arrêtez et réévaluez le matériel. Les systèmes de fichiers ne « produisent » généralement pas un nombre infini d’erreurs sur un média stable.

XFS : arrêt forcé et problèmes de log

XFS n’effectue pas de fsck au montage comme les ext. Son journal (log) est central, et XFS est intolérant aux I/O du log. C’est bon pour la cohérence, agaçant pour la disponibilité.

Chemin préféré pour XFS

Corrigez d’abord le chemin de stockage : câblage, réinitialisations de contrôleur, NVMe défaillant, RAID dégradé, multipath instable.
Tentez un démontage propre si possible. S’il est occupé et déjà arrêté, arrêtez les services et démontez.
Tentez un montage pour rejouer le log (si sûr). Si le montage échoue, passez à la réparation.
Exécutez xfs_repair. N’envisagez le zeroing du log qu’en dernier recours.

cr0x@server:~$ fuser -vm /var
                     USER        PID ACCESS COMMAND
/var:                root      1022 f....  rsyslogd
                     postgres   2020 f....  postgres
                     root      1337 f....  nginx

Signification : Ces processus maintiennent le montage occupé.

Décision : Arrêtez-les. Si vous ne pouvez pas, vous ne faites pas de « réparation », vous faites de la « recherche non planifiée sur la corruption ».

cr0x@server:~$ systemctl stop rsyslog nginx postgresql
cr0x@server:~$ umount /var
cr0x@server:~$ xfs_repair /dev/mapper/vg0-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify and correct link counts...
done

Signification : La réparation a réussi. Cela ne signifie pas que le stockage est sain. Cela signifie que XFS a pu reconstruire des métadonnées cohérentes avec les informations disponibles.

Décision : Remontez et validez les données applicatives. Si des erreurs I/O persistent, migrez immédiatement.

À propos de xfs_repair -L : Il peut effacer le log (« zero log »). Cela peut supprimer des changements récents de métadonnées. Acceptable sur un volume cache, catastrophique sur un volume de base de données. À utiliser uniquement si vous acceptez la perte de ces données.

Btrfs : mode lecture seule, checksums, scrub, et la règle « ne pas lancer repair à la légère »

Btrfs est puissant, mais il a des arêtes vives. Le plus opérationnel : btrfs check --repair n’est pas un outil de routine. Dans bien des environnements, le mouvement préféré est : monter en lecture seule, copier, reconstruire.

Chemin préféré pour Btrfs

Montez en lecture seule si ce n’est déjà fait.
Si la redondance existe, lancez un scrub pour guérir.
Remplacez les périphériques défaillants, puis relancez scrub.
Si pas de redondance et corruption existante : copiez les données critiques et recréez le système de fichiers.

cr0x@server:~$ mount -o ro,subvolid=5 /dev/sdb1 /mnt
cr0x@server:~$ btrfs scrub start -Bd /mnt
scrub started on /mnt, fsid 1b2c3d4e-....
Starting scrub on devid 1
Scrub device /dev/sdb1 (id 1) done
Scrub started:    Sun Dec 29 02:20:01 2025
Status:           finished
Duration:         0:10:12
Total to scrub:   900.00GiB
Error summary:    read=3, csum=1, verify=0, super=0, malloc=0, uncorrectable=1

Signification : Il y a au moins une erreur non récupérable. Sans copie miroir, Btrfs ne peut pas rétablir la vérité manquante.

Décision : Si ce volume est critique, restaurez depuis une sauvegarde ou copiez ce que vous pouvez et reconstruisez. Continuer à l’exploiter est un incident en accéléré.

Quand ce n’est pas le système de fichiers : stockage, RAID et causes au niveau noyau

Les systèmes de fichiers se retrouvent accusés parce qu’ils sont le messager. En réalité, « lecture seule après erreurs » est fréquemment une défaillance de la couche bloc : timeouts, réinitialisations, erreurs média, ou périphériques virtuels défaillants.

Modes de défaillance qui se font souvent passer pour une corruption du système de fichiers

Problèmes de firmware/contrôleur NVMe : réinitialisations périodiques sous charge, bugs APST/états d’alimentation, throttling thermique menant à des timeouts.
Problèmes de liaison SATA/SAS : erreurs CRC, câbles/backplanes défaillants, comportement étrange d’expander. Les erreurs CRC sont précieuses : elles annoncent « problème de transport ».
Stress de reconstruction RAID : la reconstruction amplifie les lectures ; les disques faibles lâchent pendant la reconstruction ; le système de fichiers reçoit des lectures partielles et panique.
Snapshots LVM finement provisionnés : le snapshot se remplit, le périphérique renvoie des erreurs I/O, les systèmes de fichiers se mettent en protection.
Accrocs de stockage en virtualisation : flaps iSCSI, stalls NFS, pics de latence du stockage côté hyperviseur. L’invité voit des EIO ; le système de fichiers abandonne et passe en lecture seule.

Règles rapides et opinionnées

Si vous voyez EIO dans dmesg, supposez matériel jusqu’à preuve du contraire. Les systèmes de fichiers n’inventent pas EIO pour le plaisir.
Si vous voyez un unique besoin propre de replay de journal après une perte de courant, supposez logiciel jusqu’à preuve du contraire. Mais vérifiez quand même SMART/NVMe. C’est une assurance bon marché.
Si le périphérique sous-jacent est instable, votre « réparation » doit commencer par copier les données ailleurs. Les outils de réparation ne sont pas des outils de sauvegarde.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Ils avaient une petite flotte de serveurs Debian qui exécutaient un pipeline analytique fortement en écriture. Un nœud commençait à remonter /var en lecture seule environ une fois par semaine. La routine d’astreinte était toujours la même : redémarrer, ça revient, tout le monde passe à autre chose.

L’hypothèse était simple : « C’est juste ext4 qui fait des siennes après un arrêt non propre. » Il y avait eu un événement de coupure de courant un mois plus tôt, et cette histoire est restée. Les humains aiment les narratifs propres, surtout quand ils sont commodes.

Pendant une semaine plus chargée, le même nœud est repassé en lecture seule pendant un ingest. Cette fois, il a pris un service en dur : le pipeline ne pouvait pas écrire les fichiers spool, et les storms de retries ont proliféré. Quelqu’un a fait ce que font les gens sous pression : a remonté en lecture-écriture pour « tenir la nuit ». Ça a marché une heure puis le système de fichiers a cessé de monter complètement.

Le postmortem était ennuyeux et douloureux. La vraie cause racine était des réinitialisations intermittentes du contrôleur NVMe sous profondeur de queue soutenue. Le log santé du disque montrait des erreurs média depuis des semaines, mais personne ne le vérifiait parce que « SMART dit toujours PASSED ».

Ce qui a changé leur pratique n’était pas un outil sophistiqué. C’était un petit point de checklist : si vous voyez un remontage en lecture seule, vérifiez toujours les erreurs du périphérique et les métriques de santé avant de toucher à la réparation du système de fichiers. Ils ont cessé de traiter le noyau comme dramatique. Le temps d’indisponibilité a baissé ; surprise, la perte de données aussi.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait des « limites de réparation » plus rapides pour leurs services stateful, alors ils ont massivement utilisé les snapshots LVM. Leur idée était élégante opérationnellement : snapshot du LV, exécuter des opérations risquées, annuler si besoin. En staging, ça fonctionnait très bien.

Puis un nœud de production a subi un problème de stockage transitoire. Le système de fichiers a commencé à lancer des erreurs et est repassé en lecture seule. L’astreinte a suivi le runbook : « créer un snapshot avant réparation. » La création a réussi, mais l’espace libre était maigre.

Avec le système de fichiers déjà perturbé, l’amplification CoW du snapshot a fait travailler le disque davantage. Les écritures se sont accumulées, la latence a grimpé et le snapshot s’est vite rempli. Une fois plein, le snapshot finement provisionné a transformé les écritures futures en erreurs côté couche bloc.

L’équipe s’est retrouvée avec un problème en deux couches : l’erreur initiale du système de fichiers plus un comportement du périphérique causé par l’épuisement du snapshot. Les applications voyaient des EIO et plantaient comme si c’était de la corruption de données. Leur « mécanisme de sécurité » était devenu un amplificateur de panne.

La correction n’était pas « ne jamais snapshot ». C’était « snapshoter délibérément ». Ils ont ajouté une exigence minimale d’espace libre, du monitoring et une règle stricte : si le disque est déjà instable, n’ajoutez pas la complexité CoW. Faites une image externe ou basculez.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de taille moyenne exploitait des nœuds Debian dans un système transactionnel. Rien d’exotique : ext4 pour la plupart des volumes, XFS pour de gros logs append-only. Leur équipe SRE était agaçante d’constance sur deux points : vérifications planifiées des systèmes de fichiers en fenêtres de maintenance, et restaurations testées.

Un matin, une mise à jour du noyau plus une coupure de courant malheureuse ont fait démarrer un sous-ensemble de nœuds avec des systèmes de fichiers marqués dirty. Sur deux nœuds, ext4 a aborté le journal et a remonté le root en lecture seule au démarrage. L’instinct des équipes applicatives était « remontez rw ».

Le SRE d’astreinte n’a pas fait de cascade de héros. Il a suivi le plan ennuyeux : démarrer en rescue, lancer fsck hors ligne, valider les montages, puis remonter les services dans un ordre contrôlé. Pendant ce temps, ils ont basculé le trafic vers des nœuds sains.

Parce que les sauvegardes et restaurations étaient répétées en test, ils connaissaient aussi l’option de secours : si fsck était douteux ou la santé du disque incertaine, ils réinstallaient et restauraient plutôt que d’improviser. Cette option change la psychologie de l’astreinte ; on arrête de jouer au casino.

Ils étaient de retour dans leur SLA interne, et la réunion post-incident fut presque décevante de calme. La leçon n’était pas « nous sommes des génies ». C’était « l’hygiène opérationnelle ennuyeuse transforme la crise en checklist. »

Erreurs courantes : symptômes → cause racine → correctif

Cette section est volontairement spécifique. Vous n’avez pas besoin de conseils plus génériques. Vous avez besoin d’un bon appariement de motifs.

1) Symptom: “Remounting filesystem read-only” after a burst of writes

Cause racine : abort du journal ext4 dû à des erreurs I/O sous-jacentes ou des timeouts ; parfois causé par un chemin de stockage instable.

Fix : Vérifiez dmesg/journal pour EIO et réinitialisations du périphérique. Exécutez des contrôles SMART/NVMe. Si le matériel semble sain, faites un fsck hors ligne. Sinon, imagez/migrez d’abord.

2) Symptom: XFS shows “Log I/O Error Detected. Shutting down filesystem”

Cause racine : le stockage n’a pas complété de façon fiable les écritures/lectures du journal. Peut être défaillance du périphérique, réinitialisations de contrôleur, ou problèmes au niveau dm.

Fix : Stabilisez le chemin matériel (remplacez le périphérique, corrigez le multipath, mettez en pause la reconstruction si nécessaire). Puis démontez et lancez xfs_repair. Évitez -L sauf si vous acceptez de perdre des transactions récentes.

3) Symptom: Btrfs flips to read-only and scrub reports “uncorrectable”

Cause racine : corruption détectée sans copies redondantes pour guérir (ou trop de défaillances).

Fix : Copiez ce que vous pouvez, restaurez depuis la sauvegarde, recréez le système de fichiers. Si redondant, remplacez le périphérique défaillant et relancez scrub pour guérir.

4) Symptom: system boots into emergency mode; mount units failed

Cause racine : fsck a échoué, périphérique manquant, UUID erroné, ou corruption réelle. Parfois déclenché par un renommage de périphérique suite à des changements RAID/HBA.

Fix : Utilisez systemctl --failed et journalctl -xb. Vérifiez les UUID dans /etc/fstab via blkid. Réparez hors ligne. Ne rechargez pas en boucle les redémarrages.

5) Symptom: filesystem is read-only but disk looks “fine” and no EIO appears

Cause racine : options de montage (ro explicite), logique de remount systemd, ou un flag d’erreur précédent non effacé.

Fix : Vérifiez findmnt options, /etc/fstab, et tune2fs -l pour l’état ext4. Si le système de fichiers pense avoir des erreurs, faites un fsck hors ligne même si le périphérique semble stable.

6) Symptom: after “successful” fsck, the filesystem goes read-only again quickly

Cause racine : le périphérique sous-jacent jette toujours des erreurs ; fsck n’a traité que le symptôme, pas la maladie.

Fix : Revérifiez SMART/NVMe et les logs du noyau après la réparation. Remplacez le média suspect. Vérifiez câblage/backplane. Si virtualisé, regardez la latence et la stabilité du chemin stockage hôte.

7) Symptom: thin LVM snapshot exists; suddenly I/O errors appear and FS shuts down

Cause racine : le snapshot ou le pool thin a manqué d’espace ; la couche dm renvoie des erreurs ; le système de fichiers s’auto-protège.

Fix : Vérifiez lvs Data%/Meta%. Étendez le thin pool ou supprimez le snapshot. Puis réparez le système de fichiers si nécessaire. Ajoutez du monitoring et des seuils.

Checklists / step-by-step plan

Checklist A: When you first see “Read-only file system” in production

Stop new writes : videz le trafic, mettez en pause les jobs batch, arrêtez les services bavards.
Record state : sauvegardez les logs kernel, options de montage, topologie des périphériques (journalctl, findmnt, lsblk).
Confirm scope : quels montages sont ro et quelles applications en dépendent.
Check device health : SMART/NVMe, dmesg pour réinitialisations/timeouts, état RAID.
Choose a safety boundary : snapshot si stable, backup/image si instable.

Checklist B: Controlled repair plan (minimize damage)

Get to an offline environment : rescue boot, shell initramfs, ou attachez le volume à un autre hôte.
Validate you’re repairing the correct device : mappez montage → LV → PV → disque. Confirmez l’UUID.
Run a read-only check first quand possible (fsck -n, xfs_repair -n).
Run repair avec l’outil adéquat (fsck.ext4, xfs_repair).
Re-run check jusqu’à obtenir un état clean.
Mount read-only first et validez les données clés (fichiers DB, config, état applicatif).
Mount read-write, démarrez les services dans l’ordre, surveillez les logs pour des erreurs I/O renouvelées.
Post-recovery monitoring : compteurs d’erreurs, latence, statut de reconstruction RAID, réinitialisations NVMe.

Checklist C: If hardware looks bad (the “save the data, not the filesystem” plan)

Stop services pour réduire le churn et les timeouts.
Mount read-only if possible, copiez d’abord les données critiques (configs, dumps DB si sûrs, répertoires clés).
Image the block device si vous avez besoin d’une récupération forensique (et si vous avez où stocker l’image).
Replace the device, reconstruisez RAID/LVM, recréez le système de fichiers.
Restore from backup ou depuis les données copiées.

Blague #2 : Si votre première étape de récupération est « force remount rw », félicitations — vous avez inventé un nouveau record de destruction de données.

Prévention qui fonctionne vraiment (et ce qui n’est que du vent)

La prévention n’est pas une prédication. Ce sont des contrôles ennuyeux qui empêchent que le « remontage en lecture seule » devienne un incident récurrent.

Ce qui fonctionne

Monitoring de santé des périphériques digne de confiance : logs d’erreurs NVMe, attributs SMART pertinents (pending/uncorrectable/CRC), et alertes sur réinitialisations/timeouts dans les logs du noyau.
Hygiène RAID : surveillez la dégradation, le statut des reconstructions et les taux d’erreur. Les reconstructions font avouer les disques faibles.
Gestion de capacité : les systèmes de fichiers pleins ne causent pas toujours des remontages en lecture seule, mais provoquent des erreurs opérateurs et du thrashing applicatif pendant les incidents.
Sauvegardes restaurables : testez régulièrement les restaurations. La capacité à reconstruire proprement est le meilleur antidote aux réparations hasardeuses.
Fenêtres de maintenance pour les checksystems : surtout pour ext si vous ne faites pas déjà des vérifs périodiques basées sur le temps.
Design applicatif conscient des écritures : des applis qui échouent proprement quand le stockage devient en lecture seule (libèrent les erreurs, arrêtent d’écrire, dégradent des fonctionnalités) réduisent les dégâts collatéraux.

Ce qui ne marche pas (ou seulement en démo)

Supposer que le journaling signifie « pas de corruption ». Le journaling aide la cohérence des métadonnées ; il ne rend pas le matériel fiable.
Se fier à « SMART PASSED ». C’est un statut grossier, pas une garantie. Les parties intéressantes sont dans les attributs et les logs.
Réparer en ligne. Certains outils le permettent, mais le profil de risque est mauvais. La réparation hors ligne est plus lente et plus sûre.
Ignorer les logs d’erreurs stockage parce que « c’est le système de fichiers le problème ». C’est ainsi que vous remplacez le mauvais composant et répétez l’incident.

FAQ

1) Why does Linux remount a filesystem read-only instead of crashing?

Parce que continuer à écrire après des erreurs de métadonnées peut provoquer une corruption en cascade. Remonter en lecture seule maintient le système partiellement fonctionnel tout en empêchant d’aggraver les dégâts.

2) Can I just run `mount -o remount,rw` and continue?

Vous pouvez, et parfois cela « fonctionne » brièvement. Si l’erreur d’origine venait d’une instabilité I/O ou d’un abort de journal, vous risquez d’empirer la corruption. Ne remontez rw qu’après avoir diagnostiqué et corrigé la cause sous-jacente.

3) What’s the fastest safe action when this happens on a database server?

Arrêtez la base de données proprement, capturez les logs, et confirmez si la couche stockage envoie des erreurs. Si le disque est instable, priorisez la copie des fichiers de données ou la restauration depuis des sauvegardes plutôt que des acrobaties de réparation.

4) ext4 says “clean with errors.” Is that contradictory?

Ça signifie que le système de fichiers a été démonté proprement ou semble cohérent, mais des erreurs ont été enregistrées (souvent à cause d’un journal avorté ou d’incohérences détectées). Traitez-le comme « nécessite un fsck hors ligne ».

5) XFS says to mount to replay the log, but mounting caused shutdown earlier. Now what?

Corrigez d’abord le chemin de stockage. Si vous ne pouvez pas stabiliser le stockage, le replay continuera peut-être d’échouer. Après stabilité, tentez le montage (éventuellement en lecture seule) pour rejouer, puis démontez et lancez xfs_repair. N’utilisez xfs_repair -L que si vous acceptez de perdre des transactions récentes.

6) For Btrfs, should I run `btrfs check --repair`?

Pas par défaut. Préférez scrub (si monté) et remplacement de périphérique quand il y a redondance. Si corruption non récupérable et pas de redondance, copiez et reconstruisez. N’utilisez repair que si vous comprenez le risque et avez des sauvegardes.

7) Does a read-only mount mean my disk is failing?

Pas toujours. Cela peut être une réaction propre après un arrêt brutal ou un bogue ponctuel. Mais des remontages répétés, des messages EIO, des timeouts, des réinitialisations, des secteurs pending ou des erreurs média NVMe indiquent fortement un problème matériel.

8) Should I reboot immediately to “fix” it?

Non. Redémarrer peut détruire des preuves et rendre la récupération plus difficile si le périphérique empire. Capturez les logs et évaluez la santé du disque d’abord. Redémarrez seulement dans le cadre d’un plan de réparation contrôlé.

9) If only `/var` is read-only, can I keep serving traffic?

Peut-être, brièvement, selon ce qui vit dans /var (logs, spool, bases). Si les applications en dépendent pour l’état, vous êtes déjà en panne. Si c’est surtout des logs, vous pouvez tenir avec un logging sur tmpfs le temps de basculer et réparer correctement.

10) How do I know whether fsck will cause data loss?

Tout outil de réparation peut supprimer ou orpheliner des structures corrompues. Lancez d’abord une vérification en lecture seule (fsck -n) pour voir ce qu’il propose de changer. Si le disque est suspect, imagez d’abord pour garder une voie de récupération.

Conclusion : next steps you can execute

Quand Debian 13 monte un système de fichiers en lecture seule après des erreurs, le noyau vous donne une chance de récupérer proprement. Ne la gâchez pas en forçant des écritures et en transformant une seule panne en un hobby forensique.

Faites ceci ensuite :

Suivez le playbook de diagnostic rapide : confirmez la portée, lisez les logs noyau, vérifiez la santé du stockage.
Stabilisez : arrêtez les services lourds en écriture et capturez les preuves.
Créez un périmètre de sécurité : snapshot seulement si le stockage est stable ; sinon sauvegardez/imagez d’abord.
Réparez hors ligne avec l’outil adapté à votre système de fichiers, puis validez.
Après récupération, traitez les remontages répétés en lecture seule comme un incident de chemin matériel jusqu’à preuve du contraire.