Correzione automatica del filesystem su Debian: fsck fatto bene con systemd nel 2026

C'è una categoria di guasti che mette più ansia delle altre, e quella del filesystem che non monta più al boot è in cima alla lista: il server non riparte, i servizi sono giù, e tu sei davanti a una console di emergenza che chiede la password di root per il rescue mode. Capita soprattutto sui server usati per lo storage, dove molti processi scrivono e cancellano file di grandi dimensioni in parallelo, e dove uno spegnimento improvviso o un disco che inizia a degradare lasciano il filesystem in uno stato inconsistente.

Il metodo classico per questo problema, all'epoca diffuso, era: attivare la riparazione automatica del filesystem al boot tramite una variabile in /etc/default/rcS, e affiancarci un riavvio automatico giornaliero via cron per far scattare il controllo ogni notte. Quell'approccio oggi è obsoleto sotto due aspetti, ed è giusto rivederlo da capo: il file /etc/default/rcS apparteneva al vecchio sistema di init SysV, che Debian ha abbandonato a favore di systemd da molte versioni; e il riavvio giornaliero di un server in produzione è una pratica che oggi sconsiglio sempre.

TL;DR

• Anti-pattern: il reboot giornaliero per innescare il fsck è downtime inutile (e si basava su /etc/default/rcS, che con systemd non esiste più).
• Forzare un fsck al prossimo boot: parametro kernel fsck.mode=force (più fsck.repair=yes) via GRUB, una volta sola, poi rimuovilo.
• Controllo periodico senza riavvii: tune2fs -c/-i sui contatori, oppure un timer systemd con e2fsck offline sul disco dati smontato.
• Filesystem corrotto che non monta: da rescue, e2fsck -f -y /dev/sdaX sulla partizione smontata (attento a LUKS/LVM: usa il device mappato, non la partizione fisica).
• Conta più la prevenzione: SMART, spazio libero, e backup off-site verificato.

Perché il reboot giornaliero per il fsck è un errore

Partiamo dal secondo punto, perché è quello concettuale. Riavviare un server ogni notte solo per innescare un controllo del filesystem significa accettare un downtime quotidiano programmato per risolvere un problema che, nella maggior parte dei casi, non si presenta. Su un web server o un database, un riavvio quotidiano azzera ciò che serve per analizzare e ottimizzare il sistema: le statistiche di esecuzione accumulate, la cache calda, le connessioni stabili. Su un database in particolare, ripartire ogni notte impedisce di raccogliere la storicità necessaria a un tuning serio delle performance.

La filosofia corretta è opposta: un server di produzione si riavvia quando serve, in modo controllato, idealmente dentro una finestra di manutenzione concordata, non per abitudine. Il controllo del filesystem va innescato in modo mirato, non come effetto collaterale di un reboot a forza bruta. Con systemd questo è esattamente ciò che possiamo fare, e con più precisione di prima.

Come si forza un fsck al prossimo boot con systemd

Su una Debian moderna, fino alla stabile corrente, il controllo del filesystem all'avvio è gestito da systemd attraverso il servizio systemd-fsck, che a sua volta richiama gli strumenti specifici del filesystem, come e2fsck per le partizioni ext4. Non si tocca più /etc/default/rcS: si controllano due cose, il parametro di boot e la configurazione in /etc/fstab.

Il modo pulito per forzare un controllo completo al riavvio successivo è passare un parametro alla riga di comando del kernel. Si edita la configurazione di GRUB:

sudo nano /etc/default/grub

e si aggiunge fsck.mode=force (ed eventualmente fsck.repair=yes per riparare automaticamente senza intervento) alla riga dei parametri:

GRUB_CMDLINE_LINUX_DEFAULT="quiet fsck.mode=force fsck.repair=yes"

Dopo la modifica si rigenera la configurazione e si riavvia in modo controllato:

sudo update-grub
sudo systemctl reboot

Al boot, systemd eseguirà un controllo forzato di tutti i filesystem dichiarati in fstab, riparando gli errori se ha trovato inconsistenze. Una volta verificato che tutto è a posto, conviene rimuovere fsck.mode=force dalla riga di GRUB, altrimenti il controllo completo verrà eseguito a ogni avvio, rallentando ogni reboot futuro. È un'operazione una tantum, non una configurazione permanente.

Un dettaglio che conta: il filesystem di root non può essere controllato mentre è montato in scrittura, ed è proprio questo il motivo per cui il controllo avviene nelle primissime fasi del boot, quando il root è ancora montato in sola lettura. Forzare un e2fsck su un filesystem montato e attivo, da sistema avviato, è il modo migliore per corromperlo davvero: non si fa mai.

Quale ruolo ha la sesta colonna di /etc/fstab?

La configurazione che governa quali filesystem vengono controllati al boot, e in quale ordine, vive nella sesta colonna di /etc/fstab, il campo passno. Il valore 1 è riservato al filesystem di root e indica che va controllato per primo; il valore 2 si usa per gli altri filesystem permanenti, che verranno controllati dopo il root; il valore 0 disattiva il controllo per quel filesystem. Verificare che le partizioni dati abbiano passno impostato a 2 è il modo per assicurarsi che rientrino nel controllo automatico, senza dover ricorrere ad alcun reboot pianificato.

Come pianifico un controllo periodico senza riavvii inutili

Se l'obiettivo è la prevenzione regolare, non serve riavviare a comando. Per i filesystem della famiglia ext si usa tune2fs, che permette di pianificare un controllo basato sul numero di mount o sull'intervallo di tempo. Si può impostare un controllo ogni N montaggi:

sudo tune2fs -c 30 /dev/sdaX

oppure su base temporale, ad esempio ogni tre mesi:

sudo tune2fs -i 3m /dev/sdaX

Lo stato corrente di questi contatori si ispeziona con sudo tune2fs -l /dev/sdaX, leggendo i campi relativi al mount count e all'intervallo. Va detto con onestà che molte distribuzioni disattivano questi controlli periodici di default proprio perché un controllo a sorpresa al boot, su un disco grande, può allungare i tempi di avvio in modo imprevedibile: vanno quindi usati con criterio, e su un server con finestre di manutenzione note, non a casaccio.

Dove finisce l'esito del controllo al boot?

La vecchia guida diceva di leggere /var/log/boot, un file che con systemd non esiste più. Oggi l'output del controllo del filesystem, come tutto il resto del boot, vive nel journal di systemd. Per vedere cosa ha fatto systemd-fsck all'ultimo avvio si interroga il journal filtrando per l'unità:

sudo journalctl -b -u [email protected]

Il flag -b limita al boot corrente; per i boot precedenti si usa -b -1, -b -2 e così via. È qui che si trova la traccia di un filesystem riparato, degli errori corretti e degli eventuali file finiti in lost+found: leggere il journal dopo un controllo forzato è il passo che chiude il cerchio, e che la guida di un tempo non poteva contemplare perché systemd ancora non centralizzava i log di avvio in questo modo.

E se volessi un controllo schedulato senza alcun reboot?

Qui systemd offre l'alternativa pulita al cron del riavvio notturno: un timer che esegue un controllo offline a intervalli regolari, sul solo filesystem dati e senza toccare il root. L'idea è creare un servizio che esegue e2fsck sulla partizione dati smontata, e un timer che lo innesca con la cadenza voluta:

# /etc/systemd/system/fsck-dati.service
[Service]
Type=oneshot
ExecStart=/usr/sbin/e2fsck -p /dev/sdaX

# /etc/systemd/system/fsck-dati.timer
[Timer]
OnCalendar=monthly
Persistent=true
[Install]
WantedBy=timers.target

Il flag -p esegue una riparazione automatica dei soli errori sicuri, fermandosi se incontra qualcosa che richiede una decisione umana. Si attiva con sudo systemctl enable --now fsck-dati.timer, e l'opzione Persistent=true recupera l'esecuzione se il server era spento al momento previsto. Resta valida la regola d'oro: il filesystem dev'essere smontato durante il controllo, quindi questo schema vale per i dischi dati, non per il root, che va sempre verificato nelle prime fasi del boot quando è montato in sola lettura.

Una nota sui tempi, perché è la domanda che ricevo più spesso: un controllo completo su un disco da qualche centinaio di gigabyte può richiedere da pochi minuti a oltre un'ora, a seconda del numero di inode e della velocità del supporto. Su storage NVMe è molto più rapido che su un disco meccanico. È un altro motivo per eseguirlo in una finestra programmata e non a sorpresa: un fsck che parte al boot su un disco grande può far sembrare il server bloccato quando in realtà sta solo lavorando, e l'avanzamento si può ispezionare inviando un segnale SIGUSR1 al processo e2fsck, che stampa una barra di progresso.

Su questo tipo di impostazioni di sistema, dal partizionamento alla strategia di manutenzione preventiva di un parco di server, lavoro da molti anni con le PMI: nel mio profilo trovi il metodo e l'esperienza diretta con cui imposto l'amministrazione di infrastrutture Linux che devono restare in piedi per anni, non solo superare il collaudo iniziale.

E quando il filesystem è già corrotto e non monta?

Qui passiamo dall'igiene preventiva all'emergenza vera, ed è la situazione che capita di affrontare di notte. Se il server non avvia perché il root non monta, lo strumento è sempre e2fsck (o fsck per gli altri filesystem), ma con una regola d'oro: il filesystem deve essere smontato, o montato in sola lettura, prima di passarci sopra il controllo riparativo.

Sui VPS la procedura tipica passa per la console di rescue del provider: si avvia il server in modalità di recovery o da un sistema live, si identifica la partizione con lsblk, e si esegue il controllo sul dispositivo non montato:

sudo e2fsck -f -y /dev/sdaX

Il flag -f forza il controllo anche se il filesystem si dichiara "pulito", e -y risponde automaticamente "sì" a tutte le domande di riparazione: utile quando gli errori sono molti, ma da usare con consapevolezza, perché la riparazione aggressiva può spostare file danneggiati nella directory lost+found. Per i casi più gravi conviene procedere in modo interattivo, valutando le proposte di riparazione una a una.

Una complicazione frequente sui VPS moderni riguarda i dischi cifrati e i volumi logici, ed è una trappola in cui ho visto cadere sistemisti esperti sotto pressione. Se la partizione è dentro LUKS, va prima sbloccata con cryptsetup luksOpen per esporre il device mappato su cui eseguire il controllo; se è un volume LVM, il device da passare a e2fsck è quello logico sotto /dev/mapper/, non la partizione fisica sottostante. Puntare fsck sul dispositivo sbagliato è un errore che, nel migliore dei casi, non fa nulla di utile e, nel peggiore, lavora su una struttura che non è quella che credi di star riparando. Prima di lanciare il controllo, una verifica con lsblk per capire esattamente la catena di mapping del disco vale i trenta secondi che costa.

Questa fase di recovery merita un articolo a sé, e l'ho scritto: la procedura completa per rimettere in piedi un disco corrotto su un VPS, dalla diagnosi al recupero dei dati passando per il boot da rescue e l'eventuale chroot, è in ripristino di un filesystem corrotto su VPS Debian e Ubuntu. Vale la pena leggerla prima che serva, perché nel momento dell'emergenza non si ha il tempo di studiare.

ext4, XFS o Btrfs: cambia qualcosa?

Sì, e non poco, perché lo strumento di controllo dipende dal filesystem. Su ext4, che resta il default di Debian per la maggior parte degli scenari, vale tutto quello detto finora con e2fsck. Su XFS la logica è diversa: XFS non viene controllato con fsck al boot, e il suo strumento di riparazione, xfs_repair, va eseguito separatamente sul filesystem smontato. Su Btrfs il controllo si fa con btrfs check, e qui la prudenza è massima, perché la riparazione automatica di Btrfs è notoriamente delicata e va affrontata solo con un backup pronto.

La conseguenza pratica è che la scelta del filesystem al momento dell'installazione determina anche la procedura di emergenza che dovrai seguire: decidere "alla cieca" e scoprirlo durante un guasto è il modo peggiore di gestire un'infrastruttura.

La prevenzione che conta più del fsck

Il controllo del filesystem è una rete di sicurezza, non una strategia. La vera difesa contro la perdita di dati sta a monte, e si appoggia su tre pilastri che chiudo sempre prima di preoccuparmi del passno in fstab.

Il primo è il monitoraggio dello stato fisico dei dischi: su un VPS Hetzner, come su qualsiasi server, gli strumenti SMART e le metriche del provider segnalano un disco che inizia a degradare prima che il filesystem ne risenta, e intercettare quel segnale significa programmare la sostituzione invece di subire il guasto. Il secondo è il controllo dello spazio libero, perché un filesystem riempito al 100% è una delle cause più banali e frequenti di corruzione e di servizi che si bloccano; come liberarlo in sicurezza lo spiego in risolvere i problemi di spazio disco su VPS Debian e Ubuntu. Il terzo, non negoziabile, è il backup off-site e verificato: nessun fsck recupera ciò che un backup avrebbe salvato.

Per chi gestisce un VPS senza un team sistemistico alle spalle, vale la pena avere una procedura scritta da seguire quando le cose vanno storte: ne ho preparata una in checklist di emergenza per VPS Debian e Ubuntu non gestiti, pensata proprio per i momenti in cui il server non risponde e bisogna sapere cosa toccare nell'ordine giusto.

La documentazione di riferimento per gli strumenti è quella ufficiale: il comportamento di e2fsck e dei suoi flag è descritto nelle manpage di util-linux e2fsprogs, e l'integrazione con systemd nel servizio systemd-fsck. Citare la fonte ufficiale, e non una guida copiata, è l'unico modo per essere sicuri che un comando faccia davvero quello che ci si aspetta, soprattutto quando lo si esegue su un sistema in difficoltà.

Il filo conduttore di tutto questo è che la correzione automatica del filesystem, nel 2026, non è più una variabile in un file di init e un reboot a forza bruta, ma una combinazione di configurazione mirata, controllo on-demand e prevenzione a monte. È meno spettacolare della ricetta di un tempo, ma è il modo in cui un server resta affidabile senza che tu debba spegnerlo ogni notte sperando che si aggiusti da solo. Se hai un VPS o un parco di server da rendere davvero resilienti, e vuoi capire come imposto manutenzione, monitoraggio e procedure di emergenza nel concreto, scrivimi dal modulo di contatto: partiamo da come è messo oggi il tuo sistema e da dove conviene intervenire per primo.