---
title: "Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu"
description: "Ripristino filesystem corrotto su VPS Debian e Ubuntu: ddrescue prima di tutto, fsck per ext4, xfs_repair per XFS, btrfs check e scrub, monitoring SMART e backup verificati."
canonical: "https://www.mauriziofonte.it/blog/post/ripristino-filesystem-corrotto-vps-debian-ubuntu.html"
author: "Maurizio Fonte"
date: "2025-07-16T08:26:16+02:00"
modified: "2026-06-25T12:57:04+02:00"
section: "Linux & Server"
tags: ["Linux & Server", "VPS & Hosting"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html)

# [Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/ripristino-filesystem-corrotto-vps-debian-ubuntu.html)

Mercoledì 16 Luglio 2025, alle 08:26 ![Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu](https://www.mauriziofonte.it/image/002110200-ripristino-filesystem-corrotto-vps-debian-ubuntu.jpg)

Qualche mese fa, di sabato mattina presto, mi ha chiamato il titolare di un'azienda del settore distribuzione ricambi, con un gestionale Laravel su un VPS Hetzner, perché il server non rispondeva più. Il pannello Hetzner Cloud mostrava la macchina 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, 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) viveva su quel filesystem. Seconda: il backup, come avrei scoperto poco dopo, non funzionava da settimane perché il cron job falliva silenziosamente con un errore di autenticazione sullo storage offsite che nessuno aveva notato. Alcune ore dopo, con rescue mode, una copia bit-per-bit del disco, `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, esteso ai tre filesystem che incontri davvero in produzione (ext4, XFS, Btrfs), **perché la differenza tra recovery totale e perdita dati irreversibile sta nella sequenza di azioni nei primi trenta minuti** e nella scelta dello strumento giusto per il filesystem giusto.

> Stai cercando un **Consulente Informatico** esperto per gestire emergenze di disaster recovery sulla tua infrastruttura? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su rescue mode, ripristino filesystem e recupero dati su Hetzner, OVH, Contabo e Digital Ocean.

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

Un filesystem 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` (o `XFS (sda1): corruption detected`) nel kernel log visibili con `dmesg`, il server che non riesce a bootare e cade in emergency mode, oppure file che appaiono vuoti o troncati senza ragione apparente. Le cause più comuni sono tre: **spegnimento non pulito** (power loss, kernel panic, hard reboot), **hardware guasto** (settori danneggiati sull'SSD/NVMe) e bug del kernel o del driver filesystem.

La regola fondamentale, che non ammette eccezioni, è: **non eseguire mai una riparazione su un filesystem montato**. Lo strumento di check (`fsck` per ext4, `xfs_repair` per XFS, `btrfs check` per Btrfs) modifica le strutture interne durante la riparazione; se il filesystem è montato e in uso, il kernel e il tool di repair scrivono contemporaneamente sulle stesse strutture, con risultato quasi certo di corruzione aggiuntiva. La regola vale per tutti e tre i filesystem: il manuale ufficiale di [`xfs_repair`](https://man7.org/linux/man-pages/man8/xfs_repair.8.html) è esplicito nel richiedere che *"the filesystem to be repaired must be unmounted, otherwise, the resulting filesystem may be inconsistent or corrupt"*.

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 l'immagine di sicurezza che ti salva il sabato mattina

Ogni provider serio offre una modalità rescue: Hetzner la attiva dal Cloud Console con un click, OVH dal pannello con boot in "Rescue", Digital Ocean dalla Recovery Console, Contabo via ticket di supporto. Il rescue mode avvia il VPS con un sistema Linux minimale caricato via rete (PXE), lasciando i dischi del server accessibili come device a blocchi **non montati**: è esattamente la condizione che ti serve per lavorare in sicurezza.

Il primo comando, una volta dentro il rescue, non è la riparazione. È un'immagine del disco. E qui c'è la prima correzione importante rispetto a come la maggior parte delle guide affronta il problema: **se sospetti anche solo lontanamente che il disco sia fisicamente danneggiato, non usare `dd` per l'immagine, usa `ddrescue`**.

La differenza è sostanziale. `dd` legge in sequenza dall'inizio alla fine: appena incontra un settore illeggibile o si blocca, oppure (peggio) continua a martellare lo stesso settore difettoso infliggendo ulteriore stress a un disco già morente. *GNU ddrescue* usa un algoritmo progettato per le superfici che cedono: come recita il manuale ufficiale, *"tries to rescue the good parts first, scheduling reads inside bad (or slow) areas for later"*, copiando prima tutto il recuperabile e tornando solo dopo sui settori problematici, con il minor danno aggiuntivo possibile.

Il pezzo davvero non negoziabile è il **mapfile**. È un file di stato in cui `ddrescue` annota, blocco per blocco, cosa è stato letto, cosa è ancora da tentare e cosa è definitivamente perso. Ti permette di interrompere e riprendere esattamente dal punto giusto, e di fare più passate sui settori difficili senza ripartire da capo. La [documentazione GNU](https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html) è perentoria: *"Always use a mapfile unless you know you won't need it"*.

```bash
# Disco di destinazione (un volume vuoto, o un file immagine) almeno
# grande quanto il sorgente. Mai scrivere sul disco che stai recuperando.

# Passata 1: copia veloce, salta i settori difficili e li annota nel mapfile
ddrescue -n /dev/sda /mnt/rescue/disk-image.img /mnt/rescue/mapfile.log

# Passata 2: accesso diretto (-d, bypassa la cache del kernel) e fino a 3 retry
# sui settori marcati come problematici nella passata precedente
ddrescue -d -r3 /dev/sda /mnt/rescue/disk-image.img /mnt/rescue/mapfile.log
```

Se invece la diagnosi (SMART pulito, vedi sotto) conferma che il disco è sano e la corruzione è puramente logica da power loss, una copia bit-per-bit con `dd` è sufficiente e più semplice:

```bash
# Solo se il disco è hardware-sano: immagine bit-per-bit di sicurezza
dd if=/dev/sda of=/mnt/rescue/disk-image.img bs=4M status=progress
```

> Questo passaggio è la rete di sicurezza dell'intera operazione. Se la riparazione incontra una situazione che non riesce a risolvere e decide di troncare dati o spostare file in `lost+found`, l'immagine è l'unico modo per tornare allo stato pre-riparazione e tentare un approccio diverso. Sul disco che dovevo recuperare, poche decine di gigabyte occupati, l'immagine ha richiesto pochi minuti verso uno storage nella stessa località.

## Fase 2: capire cosa è rotto prima di toccarlo

Con il disco non montato e l'immagine al sicuro, la diagnosi. La prima cosa da stabilire è **quale filesystem** stai guardando e **se il disco è hardware-sano o sta morendo**, perché le due risposte cambiano completamente la procedura.

```bash
# Tipo di filesystem di ogni partizione (ext4 / xfs / btrfs)
lsblk -f
blkid /dev/sda1

# Messaggi kernel relativi al disco e al filesystem
dmesg | grep -iE "error|ext4|xfs|btrfs|ata|nvme|sda"

# Stato di salute hardware del disco (SMART)
smartctl -H /dev/sda     # verdetto sintetico PASSED/FAILED
smartctl -x /dev/sda     # attributi estesi completi
```

Il comando `smartctl -H` dà il verdetto sintetico di salute; `smartctl -x` (o `-a`) mostra gli attributi completi, come documentato nella pagina di [`smartctl(8)`](https://manpages.debian.org/testing/smartmontools/smartctl.8.en.html). Gli attributi che contano davvero per capire se la corruzione è solo logica o se il disco sta cedendo fisicamente sono tre: **Reallocated Sector Count (ID 5)**, **Current Pending Sector Count (ID 197)** e **Offline Uncorrectable (ID 198)**. Se sono a zero, il disco è sano e la corruzione è logica, quindi riparabile in loco; se uno qualsiasi è non-zero e in crescita, il disco va sostituito e tu devi *salvare* i dati con `ddrescue`, non *ripararli* sul posto. Nel caso che ti sto raccontando, lo SMART era immacolato: corruzione logica da spegnimento non pulito, non hardware guasto.

A questo punto, in base al filesystem, si diramano tre procedure diverse.

## ext4: e2fsck, journal replay e backup superblock

Su ext4 il check di sola lettura è `e2fsck -n`, che riporta cosa farebbe senza toccare nulla. Poi si ripara, seguendo un ordine preciso: prima con il journal, poi rimuovendo e ricreando il journal, infine, se il superblock primario è distrutto, da un backup superblock.

```bash
# Diagnosi non distruttiva: cosa è rotto, senza scrivere
e2fsck -n /dev/sda1

# Riparazione standard con journal replay
e2fsck -fvy /dev/sda1
# -f forza il check anche se il fs sembra pulito, -v verbose, -y "sì" a tutto

# Se il journal è corrotto: rimuoverlo, richeckare, ricrearlo
tune2fs -O ^has_journal /dev/sda1
e2fsck -fvy /dev/sda1
tune2fs -O has_journal /dev/sda1

# Se "Bad magic number in super-block": usare un backup superblock
dumpe2fs /dev/sda1 | grep -i superblock   # elenca i backup, es. 32768, 98304...
e2fsck -b 32768 -fvy /dev/sda1
```

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**. Nel caso reale, il primo tentativo (`e2fsck -fvy`) è bastato: journal replayato, una cinquantina di inode corretti, una dozzina di file spostati in `lost+found/`, filesystem di nuovo consistente.

## XFS: dimentica fsck, esiste solo xfs_repair

Qui sta l'errore che vedo fare più spesso quando una PMI eredita un VPS con root su XFS (lo standard di default su molte derivate enterprise) e prova ad applicare le ricette di ext4. **Su XFS non esiste un fsck funzionante.** Il binario `fsck.xfs` esiste solo per compatibilità con la sequenza di boot, ma non fa nulla: esce immediatamente con successo. La verifica e la riparazione di XFS sono affidate esclusivamente a `xfs_repair`, e il design del filesystem è diverso: XFS si affida al replay del proprio log al mount per gestire le scritture interrotte, quindi nella stragrande maggioranza dei power loss il rimedio corretto è semplicemente **montare e smontare** il filesystem una volta per far replayare il log, non lanciare subito il repair.

```bash
# Scansione di sola lettura: cosa riparerebbe, senza modificare nulla
xfs_repair -n /dev/sda1

# Riparazione effettiva (filesystem SMONTATO, obbligatorio)
xfs_repair /dev/sda1
```

Il flag `-n` su `xfs_repair` *"should not modify the filesystem but should only scan the filesystem and indicate what repairs would have been made"*: è il primo comando da dare, sempre. Se invece il log è "sporco" e non può essere replayato (tipicamente quando provi a montarlo su un kernel di architettura diversa, o dopo un crash particolarmente brutto), `xfs_repair` rifiuta di procedere e suggerisce `-L`. Questo è il punto più pericoloso dell'intera procedura XFS, e il manuale non gira intorno al rischio:

> Il flag `-L` *"forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data."*

Tradotto in pratica: `xfs_repair -L` azzera il log buttando via le scritture non ancora committate. **È un'opzione di ultima istanza, da usare solo dopo aver fatto la disk image con `ddrescue` e solo se non hai alternative**, mai come primo tentativo perché te lo suggerisce un messaggio frettoloso. La sequenza corretta è: prova il mount/umount per il replay del log, poi `xfs_repair -n`, poi `xfs_repair`, e solo all'estremo `xfs_repair -L` con l'immagine già al sicuro.

## Btrfs: btrfs check come ultima spiaggia, scrub come prima linea

Btrfs ribalta la filosofia. Avendo i checksum su dati e metadati, la sua difesa primaria non è un repair offline ma lo **scrub online**: una passata che rilegge tutto il filesystem montato, verifica ogni checksum e, **se esiste ridondanza (profilo RAID1 o DUP), ripara automaticamente copiando dalla replica sana**.

```bash
# Scrub online su filesystem MONTATO: verifica tutti i checksum
btrfs scrub start -B /mnt          # -B = foreground, con statistiche finali
btrfs scrub status /mnt            # avanzamento e contatori di errore
```

Il limite va capito bene, perché su un VPS economico con un solo disco è la norma: su un profilo single (nessuna ridondanza) lo scrub può *rilevare* la corruzione tramite i checksum ma non *ripararla*, perché non esistono copie buone da cui attingere. La documentazione ufficiale [btrfs-scrub](https://btrfs.readthedocs.io/en/latest/btrfs-scrub.html) lo dice senza ambiguità: lo scrub *"can only repair filesystem damage by copying from other known good replicas"*. Su disco singolo, lo scrub ti dice esattamente *quali* file sono danneggiati, e quelli li ripristini dal backup.

Per le corruzioni strutturali profonde c'è `btrfs check`, ma il suo flag `--repair` è dichiaratamente l'opzione più rischiosa di tutto l'ecosistema filesystem Linux. La documentazione [btrfs-check](https://btrfs.readthedocs.io/en/latest/btrfs-check.html) avverte:

> *"Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption."*

Tanto che lo strumento impone un'attesa di 10 secondi prima di partire, per darti il tempo di ripensarci. La regola operativa su Btrfs è quindi: **`btrfs check` in sola lettura per diagnosticare, scrub per riparare dove c'è ridondanza, e per il resto il backup**, riservando `btrfs check --repair` ai casi in cui un developer del progetto ti ha detto esplicitamente di provarlo, sempre su una disk image, mai sul disco originale.

```bash
# Diagnosi in sola lettura (filesystem SMONTATO)
btrfs check /dev/sda1

# Recupero dei dati leggibili verso un'altra destinazione, senza riparare nulla
# (utile quando il fs non monta più ma vuoi salvare i file recuperabili)
btrfs restore /dev/sda1 /mnt/recovered/
```

## Fase 3: verifica dei dati e ripristino del servizio

Riparato il filesystem, lo monto in sola lettura quando possibile e verifico l'integrità dei dati critici prima di rimettere in produzione qualsiasi cosa:

```bash
# Montare il filesystem riparato (read-only finché non sono certo)
mount -o ro /dev/sda1 /mnt

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

# Cosa è finito in lost+found (ext4): tipo di ogni file orfano
file /mnt/lost+found/*
```

I file finiti in `lost+found` nel caso reale erano tutti file temporanei di PHP e log di Nginx, nessun file critico. Il database MySQL (i file `.ibd` delle tabelle InnoDB, il tablespace, i binary log) era integro. Ho riavviato in modalità normale, verificato che MySQL si avviasse senza errori, e testato il gestionale navigando le pagine principali e controllando la consistenza dei dati.

Quando invece `e2fsck` produce centinaia di file orfani con nome perso (rinominati col numero di inode, es. `#12345`), `debugfs` permette di risalire al nome e alla directory originali tramite le informazioni dell'inode, come documentato nel [manuale di debugfs](https://www.man7.org/linux/man-pages/man8/debugfs.8.html). Ma nella pratica vale una regola che non smetto di ripetere: **se hai un backup funzionante, ripristinare da backup è quasi sempre più veloce e più sicuro che ricostruire da `lost+found`**. Il che ci porta al punto che pesa più di ogni comando di questo articolo.

## Perché la riparazione del filesystem non è (mai) un sostituto del backup

Ho aperto questo articolo con un dettaglio che non era un caso di colore: il backup non funzionava da settimane, e nessuno lo sapeva. Questo è lo scenario reale, non l'eccezione. **Un backup che fallisce silenziosamente è indistinguibile da un backup che non esiste**, e te ne accorgi esattamente nel momento peggiore: quando ti serve. Tutte le procedure di repair che hai letto fin qui, da `e2fsck` a `xfs_repair` a `btrfs check`, sono interventi di ultima istanza che provi *perché* il backup non c'era o non bastava. Una riparazione riuscita è fortuna ingegnerizzata; un backup verificato è la cosa che rende quella fortuna superflua.

La differenza sta nella parola *verificato*. Un job di backup che gira non è un backup: è un backup solo quando hai dimostrato di poter fare il restore. Nella mia pratica un backup non testato non conta, e la verifica deve essere automatica e periodica, non un controllo manuale che nessuno fa più dopo la prima settimana. Ho documentato l'approccio operativo, inclusa la verifica periodica dell'integrità che avrebbe intercettato la chiave SSH scaduta prima del disastro, nell'articolo dedicato alle [strategie di backup per VPS unmanaged](https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html), e l'ho inquadrato nel più ampio [piano di disaster recovery per la continuità operativa di una PMI](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html), dove lo scenario "filesystem corrotto" è uno dei rischi da coprire esplicitamente con RPO e RTO realistici.

## Come si previene la corruzione del filesystem su un VPS e come la si scopre prima del disastro?

La prevenzione poggia su due gambe: ridurre la probabilità che il filesystem si corrompa, e accorgersi che il disco sta cedendo *prima* che ti pianti il server. **Sul primo fronte**, ti assicuri che il filesystem usi il journaling (ext4 lo ha di default; lo verifichi con `tune2fs -l /dev/sda1 | grep has_journal`), perché il journal replaya le operazioni in sospeso al riavvio e ti evita gran parte dei `fsck` post-crash. Su XFS e Btrfs il meccanismo è intrinseco (log interno e *copy-on-write* con checksum rispettivamente). Su un'infrastruttura che gestisci tu, vale anche disciplinare gli spegnimenti: l'hard reboot dal pannello è l'ultima opzione, non la prima.

**Sul secondo fronte**, quello che fa la vera differenza, c'è il monitoring SMART proattivo. Non basta lanciare `smartctl` quando il server è già morto: vuoi che il disco ti avvisi mentre è ancora vivo. Due strumenti:

```bash
# Self-test breve (1-2 minuti) e completo (può richiedere ore), poi il log
smartctl -t short /dev/sda
smartctl -t long  /dev/sda
smartctl -l selftest /dev/sda
```

Il flag `-t short` avvia un test di superficie rapido che intercetta i difetti più comuni, `-t long` fa una scansione completa; i risultati finiscono nel self-test log leggibile con `-l selftest`. Ma il pezzo che trasforma il monitoring da reattivo a proattivo è il demone **smartd**: gira in background, interroga i dischi a intervalli regolari (30 minuti di default) e ti manda un'email appena un attributo critico si muove. La configurazione minima che applico mette sotto sorveglianza proprio gli attributi che predicono i guasti, con la direttiva `-a` (che include health, error log e i contatori di settori) più gli alert sugli incrementi:

```text
# /etc/smartd.conf - alert solo sugli INCREMENTI dei settori critici
/dev/sda -a -m alert@example.com -C 197+ -U 198+ -R 5! -s (S/../.././02|L/../../6/03)
```

Qui `-C 197+` e `-U 198+` avvisano solo quando i pending sector e gli offline uncorrectable *aumentano* (così non ricevi la stessa email ogni giorno per un valore fermo), `-R 5!` tratta come critico ogni nuovo settore riallocato, e `-s` pianifica un self-test breve quotidiano e uno lungo settimanale. È la differenza tra scoprire il problema con settimane di anticipo e scoprirlo alle sette di un sabato mattina.

Se gestisci un VPS con dati di produzione e non hai mai testato cosa succede quando il filesystem si corrompe, e soprattutto se il monitoring SMART non ti scriverebbe un'email prima del guasto, stai operando senza rete di sicurezza. Il rescue mode, `ddrescue` per l'immagine, lo strumento di repair giusto per il tuo filesystem e un backup che hai effettivamente ripristinato almeno una volta sono cose che devi conoscere e avere pronte *prima* che servano, non durante il panico. 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 per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami): l'intervento più costoso è quello che arriva tardi, e la distanza tra un sabato mattina spiacevole e un lunedì col business fermo e i dati irrecuperabili sta tutta nelle scelte delle prime ore.

Dall'articolo al lavoro vero

Se questo server lo devi tenere in piedi tu

Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino.

[Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 12:57 [« Articolo precedenteOttimizzare sessioni PHP su VPS gestite senza supporto tecnico: guida avanzata per Debian e Ubuntu15 Luglio 2025](https://www.mauriziofonte.it/blog/post/ottimizzare-sessioni-php-vps-debian-ubuntu.html)[Articolo successivo »Configurare notifiche email su VPS senza supporto tecnico: guida pratica per Postfix su Debian e Ubuntu17 Luglio 2025](https://www.mauriziofonte.it/blog/post/configurare-notifiche-email-postfix-vps-debian-ubuntu.html)

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

- [Correzione automatica del filesystem su Debian: fsck fatto bene con systemd nel 2026](https://www.mauriziofonte.it/blog/post/debian-correzione-file-system-fsck-automatica-reboot.html)

  Un filesystem che non monta più al riavvio blocca tutto. Le vecchie guide per forzare il controllo del filesystem su Debian si basavano su un · 10 Giugno 2026

  ![Correzione automatica del filesystem su Debian: fsck fatto bene con systemd nel 2026](https://www.mauriziofonte.it/image/000260070-debian-correzione-file-system-fsck-automatica-reboot.jpg)
- [Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/blog/post/ripristino-operativita-web-provider-vps-unmanaged.html)

  Quando lo sviluppatore originale è scomparso e il server VPS unmanaged è bloccato, il provider non risolve il problema al posto tuo: ti consegna · 16 Giugno 2025

  ![Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/image/001790070-ripristino-operativita-web-provider-vps-unmanaged.jpg)
- [Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html)

  La checklist operativa in 7 fasi che uso quando un VPS Debian o Ubuntu va in crisi: triage in 60 secondi con lo USE method, diagnosi disco pieno, · 9 Luglio 2025

  ![Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/image/002030070-checklist-emergenza-debian-ubuntu-vps-unmanaged.jpg)
- [Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/risolvere-problemi-spazio-disco-vps-debian-ubuntu.html)

  Un VPS Hetzner da 80GB al 100 : MySQL fermo, Laravel in errore 500, e dopo aver cancellato 30GB di log lo spazio non si liberava. La causa: file · 14 Luglio 2025

  ![Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu](https://www.mauriziofonte.it/image/002090070-risolvere-problemi-spazio-disco-vps-debian-ubuntu.jpg)
- [Recuperare un /boot pieno durante l'upgrade senza reinstallare](https://www.mauriziofonte.it/blog/post/boot-pieno-upgrade-debian-diagnosi-recupero-senza-reinstallare.html)

  Una partizione /boot da 256 MB, tre kernel accumulati, un initrd cresciuto negli anni fino a 80 MB, e l'aggiornamento del kernel muore a metà · 21 Ottobre 2026

  ![Recuperare un /boot pieno durante l'upgrade senza reinstallare](https://www.mauriziofonte.it/image/005720070-boot-pieno-upgrade-debian-diagnosi-recupero-senza-reinstallare.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/ripristino-filesystem-corrotto-vps-debian-ubuntu.html

Pubblicato: 2025-07-16 · Aggiornato: 2026-06-25.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.