Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu

Il 28 giugno 2025, alle 7:45 di un sabato mattina, mi ha chiamato il titolare di una PMI campana - azienda di distribuzione ricambi auto con gestionale Laravel 10 su un Hetzner CX31 - perché il VPS non rispondeva più. Il pannello Hetzner Cloud mostrava il server in stato "running" ma la console VNC presentava un loop di riavvio: il kernel si avviava, tentava di montare il filesystem root ext4, falliva con EXT4-fs error: unable to read itable block, e riavviava. Il server era stato spento bruscamente il giorno prima per un'interruzione di corrente nel data center di Falkenstein (evento raro su Hetzner, ma non impossibile), e il filesystem non era sopravvissuto integro allo spegnimento non pulito.

La situazione era critica per due ragioni. Prima: il database MySQL dell'intero anno - ordini, fatture, listini, anagrafiche clienti e fornitori - era su quel filesystem. Seconda: il backup, come scoprirò poco dopo, non funzionava da tre settimane perché il cron job di BorgBackup falliva silenziosamente con un errore di autenticazione sulla Storage Box che nessuno aveva notato. Cinque ore dopo, con rescue mode, disk image di sicurezza, e2fsck con backup superblock e un import selettivo dei dati, il gestionale era di nuovo operativo. In questo articolo ti racconto ogni passaggio della procedura, perché la corruzione del filesystem è uno degli scenari più spaventosi su un VPS - e la differenza tra recovery totale e perdita dati irreversibile sta nella sequenza di azioni nei primi trenta minuti.

Stai cercando un Consulente Informatico esperto per gestire emergenze di disaster recovery sulla tua infrastruttura? Nel mio profilo professionale trovi l'esperienza concreta su rescue mode, ripristino filesystem e recupero dati su Hetzner, OVH, Contabo e Digital Ocean. Contattami per una consulenza diretta.

Come si riconosce un filesystem corrotto e perché non devi mai fare fsck su un disco montato?

Un filesystem ext4 corrotto si manifesta tipicamente con uno o più di questi sintomi: errori Input/output error quando provi a leggere o scrivere file, messaggi EXT4-fs error nel kernel log (visibili con dmesg), il server che non riesce a bootare e cade in emergency mode, oppure file che appaiono vuoti o con contenuto troncato senza ragione apparente. Le cause più comuni sono: spegnimento non pulito (power loss, kernel panic, hard reboot), hardware guasto (settori danneggiati sull'SSD), e bug del kernel o del driver filesystem.

La regola fondamentale - che non ammette eccezioni - è: non eseguire mai fsck su un filesystem montato. Il fsck (file system check) modifica le strutture del filesystem durante la riparazione; se il filesystem è montato e in uso, il kernel e fsck scrivono contemporaneamente sulle stesse strutture, con risultato quasi certo di corruzione aggiuntiva e possibile perdita totale dei dati. La documentazione di e2fsck è esplicita: "you risk corrupting your file system and losing data if you run fsck on an active disk".

Questo significa che per riparare il filesystem root - quello che contiene il sistema operativo e su cui il server sta girando - devi necessariamente avviare da un sistema alternativo. Su un VPS questo sistema alternativo è il rescue mode del provider.

Fase 1: rescue mode e disk image di sicurezza

Ogni provider serio offre una modalità rescue: Hetzner la attiva dal Cloud Console con un click, OVH dal pannello KVM, Digital Ocean dalla Recovery Console, Contabo via ticket supporto. Il rescue mode avvia il VPS con un sistema Linux minimale caricato via rete (PXE), lasciando i dischi del server accessibili come device block non montati.

Su Hetzner, dopo aver attivato il rescue mode e riavviato il server, mi sono collegato via SSH con le credenziali temporanee fornite dal pannello. Il primo comando non è fsck - è un'immagine del disco:

# PRIMA DI QUALSIASI RIPARAZIONE: creare un'immagine bit-for-bit
# Se fsck peggiora le cose, questa immagine è l'ultima chance
dd if=/dev/sda of=/root/disk-image-20250628.img bs=4M status=progress

# Se non c'è spazio locale, copiare su un server remoto
dd if=/dev/sda bs=4M status=progress | ssh backup@REMOTE "dd of=/root/disk-image.img bs=4M"

Questo passaggio è non negoziabile. Se fsck incontra una situazione che non riesce a riparare e decide di troncare dati o spostare file in lost+found, l'immagine bit-for-bit è l'unico modo per tornare allo stato pre-riparazione e tentare un approccio diverso. Nel caso campano, il disco era da 80 GB di cui 34 GB occupati - l'immagine ha richiesto circa 12 minuti verso una Storage Box Hetzner nella stessa località.

Fase 2: diagnosi - capire cosa è rotto prima di riparare

Con il disco non montato e l'immagine di sicurezza salvata, la diagnosi:

# Messaggi kernel relativi al disco
dmesg | grep -i "error\|ext4\|ata\|scsi\|sda"

# Stato SMART del disco (verifica hardware)
smartctl -a /dev/sda

# Stato del filesystem senza tentare riparazioni (-n = no changes)
e2fsck -n /dev/sda1

Il smartctl nel caso campano non mostrava errori hardware - il disco NVMe era perfettamente sano, il che confermava che la corruzione era da spegnimento non pulito, non da hardware guasto. Il e2fsck -n (dry run) ha rivelato il quadro completo: journal corrotto, 47 inode con errori, 3 blocchi con conteggio referenze errato, e il superblock primario con inconsistenze. Niente di irreparabile - la corruzione da power loss su ext4 con journal è quasi sempre recuperabile, perché il journal contiene esattamente le informazioni necessarie per riportare il filesystem a uno stato consistente.

Fase 3: la riparazione con e2fsck

La riparazione segue un ordine preciso. Prima tento con il journal, poi senza, poi con backup superblock:

# Tentativo 1: riparazione standard con journal replay
e2fsck -fvy /dev/sda1
# -f = forza il check anche se il filesystem sembra pulito
# -v = verbose
# -y = rispondi "sì" a tutte le domande di riparazione

# Se fallisce con errore sul journal, rimuovere e ricreare il journal
tune2fs -O ^has_journal /dev/sda1
e2fsck -fvy /dev/sda1
tune2fs -O has_journal /dev/sda1

# Se fallisce con "Bad magic number in super-block", usare un backup
# I backup superblock su ext4 sono a intervalli regolari
dumpe2fs /dev/sda1 | grep -i superblock
# Output tipico: Backup superblock at 32768, 98304, 163840...
e2fsck -b 32768 -fvy /dev/sda1

Nel caso campano, il primo tentativo (e2fsck -fvy) è riuscito: il journal è stato replayato, 47 inode corretti, 12 file spostati in lost+found/, e il filesystem è tornato consistente. L'output finale - e2fsck: 158247/1310720 files, 2187456/5242880 blocks - confermava che il filesystem era integro.

Fase 4: verifica dei dati e ripristino del servizio

Dopo e2fsck, ho montato il filesystem e verificato l'integrità dei dati critici:

# Montare il filesystem riparato
mount /dev/sda1 /mnt

# Verificare che i file critici esistano
ls -la /mnt/var/www/html/artisan           # Laravel
ls -la /mnt/var/lib/mysql/ibdata1          # InnoDB tablespace
ls -la /mnt/etc/nginx/nginx.conf           # Nginx config

# Controllare i file finiti in lost+found
ls -la /mnt/lost+found/
# Se ci sono file critici, identificarli e rimetterli al posto giusto
file /mnt/lost+found/*

I 12 file in lost+found erano tutti file temporanei di PHP e log di Nginx - nessun file critico perso. Il database MySQL (ibdata1, i file .ibd delle tabelle InnoDB, i binary log) era integro. Ho riavviato il server in modalità normale, verificato che MySQL si avviasse senza errori con mysqladmin status, e testato il gestionale Laravel navigando le pagine principali e verificando che i dati fossero consistenti.

Il totale dall'inizio dell'intervento al gestionale operativo: cinque ore, di cui dodici minuti per il disk image, trenta minuti per la diagnosi, quaranta minuti per il e2fsck, e il resto per verifiche, fix al backup rotto (la chiave SSH per la Storage Box era scaduta) e test di integrità dei dati.

Il caso dei file in lost+found: come identificarli e recuperarli

Quando e2fsck trova file orfani - file il cui inode esiste ma che non sono referenziati da nessuna directory - li sposta nella directory lost+found/ alla root del filesystem. Questi file vengono rinominati con il loro numero di inode (es. #12345) e perdono il nome originale. Il recupero è possibile ma richiede lavoro investigativo:

# Tipo di ogni file in lost+found
file /mnt/lost+found/*

# Per i file di testo, guardare il contenuto per capire cosa sono
head -20 /mnt/lost+found/#12345

# Per i file MySQL .ibd (tabelle InnoDB), l'header contiene il nome
hexdump -C /mnt/lost+found/#12345 | head -5

# Per i file PHP, cercare namespace o class name
grep -l "namespace App" /mnt/lost+found/#*

In casi gravi con centinaia di file in lost+found, uso debugfs per risalire al nome e alla directory originali attraverso le informazioni dell'inode - come documentato nel manuale di debugfs. Il comando stat <inode_number> in debugfs mostra i timestamp di creazione e modifica, la dimensione e i blocchi occupati, che aiutano a identificare il file. Ma nella pratica, se hai un backup funzionante, è quasi sempre più veloce ripristinare da backup anziché ricostruire da lost+found.

Il rescue mode sui diversi provider: cosa aspettarsi

Ogni provider implementa il rescue mode in modo leggermente diverso, e conoscere le differenze prima dell'emergenza fa risparmiare tempo prezioso.

Hetzner Cloud offre il rescue mode dal pannello web con un click: seleziona il VPS, "ISO Images" > "Mount rescue system", riavvia. Il rescue è un Debian minimale con e2fsck, mdadm, lvm, btrfs-progs preinstallati. Per i server dedicati (Robot), il rescue si attiva da robot.hetzner.com > Server > Rescue e include anche la LUKS support per dischi cifrati. La documentazione Hetzner sul rescue è eccellente e include procedure specifiche per ogni scenario.

OVH offre rescue mode dal pannello manager: server > "Boot" > seleziona "Rescue" > riavvia. L'accesso avviene via SSH con credenziali inviate via email. Per i VPS entry-level la procedura può richiedere l'apertura di un ticket se l'opzione non è visibile nel pannello.

Digital Ocean offre la Recovery Console dal pannello del Droplet > "Recovery" > "Boot from Recovery ISO". L'accesso è via browser (console web), non via SSH - il che rende le operazioni di copia più scomode ma funziona anche quando la rete del VPS è compromessa.

Contabo richiede l'apertura di un ticket supporto per attivare il rescue mode - non c'è un'opzione self-service nel pannello. I tempi di risposta sono tipicamente 30-60 minuti durante l'orario lavorativo europeo.

Come prevenire la corruzione del filesystem su VPS

La corruzione da power loss è prevenibile al 90% con due misure. Prima: assicurarsi che il filesystem usi il journaling (ext4 lo ha di default, ma verificare con tune2fs -l /dev/sda1 | grep "Filesystem features" | grep has_journal). Il journal registra le operazioni in corso prima di eseguirle - in caso di spegnimento improvviso, al riavvio il kernel replaya il journal e riporta il filesystem a uno stato consistente senza bisogno di fsck. Seconda: configurare il parametro barrier=1 nel mount delle opzioni fstab (default su ext4, ma da verificare) - le barrier garantiscono che le scritture arrivino al disco nell'ordine corretto.

La prevenzione completa include anche: backup funzionante e testato - il caso campano ha dimostrato che un backup rotto è indistinguibile da un backup assente -, monitoring SMART del disco per rilevare degrado hardware prima del guasto, e un piano di disaster recovery documentato che copra esplicitamente lo scenario "filesystem corrotto". Ho documentato le strategie di backup per VPS con BorgBackup in un articolo dedicato - inclusa la verifica settimanale dell'integrità del backup che avrebbe rilevato il problema della chiave SSH scaduta tre settimane prima.

Se gestisci un VPS con dati di produzione e non hai mai testato cosa succede quando il filesystem si corrompe, stai operando senza rete di sicurezza. Il rescue mode, il dd per l'immagine di sicurezza e il e2fsck sono strumenti che devi conoscere prima che servano - non durante il panico alle 7 di sabato mattina. Se vuoi un audit della resilienza della tua infrastruttura - o se ti trovi adesso con un VPS che non boota e un filesystem corrotto - contattami. L'intervento più costoso è quello che arriva tardi; il rescue mode, una disk image e un e2fsck eseguiti correttamente nelle prime ore possono fare la differenza tra un sabato mattina spiacevole e un lunedì di panico con il business fermo e dati irrecuperabili.