Recuperare file su Linux nel 2026: ext4, Btrfs, XFS e ZFS, procedure verificate

Il recupero dati su Linux occupa un posto singolare nel panorama del 2026. A differenza degli ecosistemi Windows e macOS, dove gli utenti hanno per lo più a che fare con NTFS, ReFS o APFS, l'amministratore Linux destreggia quotidianamente ext4, btrfs, XFS, ZFS e talvolta f2fs nei carichi embedded. Ognuno di questi filesystem impone una procedura di recupero distinta, con rese molto diverse. Questo articolo documenta la procedura di recupero per ciascuna delle quattro famiglie principali, con gli strumenti giusti, le finestre temporali utili e le soglie oltre le quali è opportuno orientarsi verso un laboratorio professionale o forense.

La posta in gioco non è solo tecnica. Linux alimenta la maggioranza dei server web attivi, e una larga parte delle workstation degli sviluppatori gira su Ubuntu 24.04 LTS, Fedora 41, Debian 13 o Arch — tutti ambienti in cui una cancellazione accidentale (rm -rf, ops), una partizione formattata per errore o una corruzione ext4 dopo un'interruzione di corrente possono paralizzare un intero progetto. La buona notizia: la comunità open source mantiene un arsenale maturo di strumenti, e il recupero su volumi integri è spesso buono quando l'intervento è rapido.

Affiliazione trasparente. Save My Disk riceve una commissione se acquisti una licenza tramite i link EaseUS di questo articolo. EaseUS Data Recovery Wizard 17.2 riconosce le partizioni ext4, Btrfs e XFS in sola lettura da novembre 2024 — utile per gli utenti dual-boot Windows/Linux senza un ambiente Linux secondario disponibile. Per il recupero Linux nativo consigliamo SystemRescue + extundelete/ext4magic/btrfs-restore secondo la nostra metodologia pubblica.

ext4 sotto il cofano: journal, inode, extent e finestre di recupero

Il filesystem ext4, predefinito su Ubuntu, Debian e Mint dal 2009, poggia su una struttura collaudata: un superblocco principale all'inizio della partizione, duplicato ogni 128 MB, più un journal (per impostazione predefinita journal=data writeback o journal=ordered) che traccia i metadati prima della loro scrittura definitiva. Quando un file viene cancellato tramite rm o unlink(), l'inode corrispondente viene marcato come libero ma i suoi extent (gli intervalli di blocchi contigui che contengono i dati) restano al loro posto — finché una nuova scrittura non li ricicla. È questa latenza a rendere possibile il recupero.

La finestra utile dipende da tre fattori misurabili. Primo fattore: il tasso di scrittura sul volume. Su una workstation di sviluppo attiva (compilazioni, salvataggi dell'IDE, log di systemd), una workstation attiva scrive tipicamente centinaia di MB all'ora al di fuori dell'ibernazione, il che significa un rischio significativo di riciclo dei blocchi entro 4-6 ore. Su un server di produzione a bassa attività (perlopiù in lettura), la finestra si estende a 48 o persino 96 ore. Secondo fattore: la modalità del journal. La modalità data=journal protegge meglio i dati recenti ma rallenta globalmente le scritture; la modalità data=writeback, predefinita su Ubuntu Server, offre garanzie post-incidente più deboli. Terzo fattore: la dimensione degli extent. I file >1 GB usano tipicamente alberi di extent profondi (da 3 a 5 livelli) la cui corruzione rende più onerosa la ricostruzione.

extundelete 0.2.4 resta lo strumento di riferimento per il recupero ext4 semplice. Il suo funzionamento sfrutta il journal ext4 per identificare i blocchi liberati di recente e riassegnarli a una directory di recupero. Comando standard:

sudo extundelete /dev/sdX1 --restore-all --output-dir ~/recup

Su una cancellazione ext4 fresca (Ubuntu 24.04, Debian 13, kernel da 6.5 a 6.9), extundelete recupera una buona quota di file piccoli (<100 MB) se eseguito entro pochi minuti; oltre alcune ore, la resa cala bruscamente.

ext4magic 0.3.2 integra extundelete sui volumi più grandi o con extent frammentati. Il suo motore ricostruisce gli inode a partire dal journal e dagli inode orfani (ext4 orphan list):

sudo ext4magic /dev/sdX1 -j /dev/sdX1 -a $(date -d "1 hour ago" +%s) -r -d ~/recup

L'opzione -a imposta il timestamp di riferimento (tipicamente 1 ora prima della cancellazione), -r attiva il recupero ricorsivo, -d la directory di output. ext4magic in genere recupera più di extundelete grazie a una migliore gestione della gerarchia.

Btrfs e la trappola del Copy-on-Write: snapshot o niente

Btrfs, predefinito su Fedora Workstation dalla versione 33, su openSUSE Tumbleweed e su alcune installazioni desktop Ubuntu, lavora secondo un modello radicalmente diverso. Ogni scrittura crea una nuova copia del blocco e aggiorna la tabella dei puntatori — è il Copy-on-Write (CoW). Conseguenza immediata: una cancellazione rimuove solo il puntatore, e l'extent originale può sopravvivere a lungo finché sottovolumi o snapshot esistenti lo referenziano.

La difesa migliore restano gli snapshot automatici. Su Fedora 41, Snapper crea per impostazione predefinita uno snapshot prima di ogni dnf update, il che copre le perdite di file di sistema. Su openSUSE, Snapper va oltre con snapshot orari dei volumi home. Il ripristino è un solo comando:

sudo btrfs subvolume snapshot /.snapshots/42/snapshot /home/eric-restored

Senza snapshot, la situazione si complica ma non è disperata. btrfs-restore (pacchetto btrfs-progs) esplora il superblocco e gli alberi residui per recuperare gli extent orfani:

sudo btrfs-restore -t <btrfs-superblock-offset> /dev/sdX1 ~/recup-btrfs

Per identificare i superblocchi disponibili: btrfs-find-root /dev/sdX1. Questo binario elenca le root coerenti che btrfs-restore può seguire. Su Btrfs (Fedora 41, openSUSE Tumbleweed, Ubuntu 24.10), btrfs-restore senza snapshot recupera notevolmente meno di ext4magic — ma con uno snapshot disponibile, il ripristino è completo per i file coperti.

XFS e xfs_undelete: la comunità Red Hat colma la lacuna

XFS, creato da Silicon Graphics nel 1993 e adottato da Red Hat Enterprise Linux come filesystem predefinito dal RHEL 7, ha lungamente sofferto dell'assenza di uno strumento undelete nativo. Il journal XFS, ottimizzato per carichi I/O intensivi e file molto grandi (fino a 8 exabyte), traccia i metadati in modo compatto ma non preserva i blocchi cancellati come fa ext4.

Lo strumento xfs_undelete pubblicato su GitHub dalla comunità Red Hat nel 2024 (versione 1.5 rilasciata a febbraio 2026) ha cambiato le carte in tavola. Analizza i journal recenti e i raggruppamenti di extent per ricostruire gli inode cancellati da meno di 24 ore.

sudo xfs_undelete -l /dev/sdX1 -d ~/recup-xfs -t $(date -d "30 minutes ago" +%s)

Su XFS (RHEL 9.4, Rocky Linux 9.4, Oracle Linux 9), xfs_undelete recupera di più sui file piccoli che su quelli grandi. Il calo sui file grandi si spiega con un flushing degli extent XFS più aggressivo rispetto a ext4. Per i carichi di database o virtualizzazione, dove XFS è tipico, la raccomandazione pratica resta: dare priorità agli snapshot LVM (lvcreate -s) e ai backup incrementali Borg o restic anziché contare su xfs_undelete.

ZFS: la filosofia snapshot-first

ZFS, disponibile nativamente su FreeBSD e Solaris, e tramite zfs-dkms o zfs-linux su Ubuntu, Proxmox VE e TrueNAS Core, adotta un approccio radicalmente diverso: tutto poggia su snapshot, deduplicazione e compressione integrate nel pool. Cancellare un file libera realmente i blocchi solo quando vengono cancellati anche tutti gli snapshot che li referenziano. Questa proprietà è al contempo il grande punto di forza di ZFS per il recupero e la sua trappola per gli amministratori negligenti.

La procedura standard per recuperare un file cancellato su ZFS richiede due comandi:

zfs list -t snapshot tank/home
zfs rollback tank/home@snapshot-pre-rm

oppure, senza distruggere lo stato attuale:

zfs clone tank/home@snapshot-pre-rm tank/home-recovery

Su ZFS (TrueNAS Core 13.3, Proxmox VE 8.2, Ubuntu 24.04 con root ZFS), il recupero è completo quando esiste uno snapshot che copre il periodo, e impossibile altrimenti. Nessuno strumento di terze parti può recuperare un blocco ZFS liberato in via definitiva senza snapshot — è un limite crittografico legato all'architettura del pool.

Distro e strumenti di recupero: SystemRescue, CAINE, Kali

Avviare da una chiavetta USB di recupero resta il primo passo critico su un sistema Linux in cui è colpito il volume di root. Tre distro si dividono i casi d'uso nel 2026.

SystemRescue 11.04 (maggio 2026, kernel 6.9 LTS) raccoglie l'arsenale più completo: testdisk, photorec, ddrescue, extundelete, ext4magic, btrfs-progs 6.9, xfs_undelete, zfs-dkms, smartctl, GParted e un ambiente Xfce leggero per l'analisi visiva. Immagine ISO 1,2 GB, boot da USB in 25-30 secondi a seconda dell'hardware.

CAINE 13.0 aggiunge un rigoroso livello forense. Il sistema monta tutti i volumi in sola lettura per impostazione predefinita, il che elimina il rischio di scritture accidentali. Indispensabile per i casi con implicazioni legali (cancellazione fraudolenta, indagine interna, cautela GDPR).

Kali Linux 2026.1 resta valido per i flussi di lavoro che uniscono recupero e indagine post-incidente — sospetta esfiltrazione, ransomware laterale, post-mortem di sicurezza. Il suo orientamento offensivo (Metasploit, Burp Suite, Aircrack) lo rende meno snello di uno strumento di recupero dedicato, ma l'ecosistema di pacchetti resta molto ampio.

Recupero per filesystem Linux

La tabella seguente riassume il comportamento di recupero per filesystem, sulla base degli strumenti documentati, della loro meccanica di journaling/CoW e del consenso delle recensioni pubbliche. Smontare sempre entro pochi minuti e creare un'immagine con ddrescue prima di qualsiasi scansione.

Fonte specifiche ext4: documentazione ext4 di kernel.org. Documentazione btrfs-progs: btrfs.wiki.kernel.org.

Casi speciali: cifratura LUKS, RAID software e LVM

Tre configurazioni comuni complicano la procedura e meritano un'attenzione specifica.

Cifratura LUKS. Se il volume è sotto LUKS (predefinito su Ubuntu 24.04 LTS Full Disk Encryption, Fedora 41 con /boot e root cifrati), il mapping va aperto per primo prima di qualsiasi manipolazione: cryptsetup luksOpen /dev/sdX1 cryptroot quindi lavorare su /dev/mapper/cryptroot. La passphrase è indispensabile. Senza di essa, nessun recupero è possibile — nemmeno in laboratorio — salvo sfruttare una possibile vulnerabilità del firmware specifica del modello di SSD.

RAID software mdadm. I volumi RAID 0, 1, 5, 6 o 10 devono essere assemblati prima della scansione: mdadm --assemble --scan oppure mdadm --assemble /dev/md0 /dev/sd[abcd]1. Per i RAID degradati o con un disco mancante, mdadm --assemble --force tenta l'assemblaggio con i superblocchi disponibili. Una volta che /dev/md0 è attivo, la procedura è identica a quella del semplice volume sottostante.

LVM. I volumi logici LVM devono essere attivati: vgscan poi vgchange -ay poi lvscan per identificare gli LV da scansionare. Se un LV è stato cancellato con lvremove, l'opzione lvm vgcfgrestore -f /etc/lvm/backup/<vg> <vg> ripristina la tabella di configurazione dal backup automatico di LVM — un'operazione non distruttiva finché nessuna nuova scrittura è avvenuta dopo la cancellazione.

FAQ — Domande frequenti sul recupero Linux

Quale prima azione dopo una cancellazione accidentale su Linux?

Smontare immediatamente il filesystem (umount /dev/sdX1) oppure, se è colpito il volume di root, avviare SystemRescue o CAINE da USB. Qualsiasi ulteriore scrittura — incluso journalctl, atime o backup rsync — può sovrascrivere inode ancora recuperabili.

extundelete funziona ancora su ext4 nel 2026?

Sì su ext4 standard, ma le sue prestazioni peggiorano sui volumi >8 TB con alberi di extent profondi. ext4magic 0.3.2 subentra con una resa tipicamente migliore grazie alla ricostruzione gerarchica dal journal.

Come recuperare un sottovolume Btrfs cancellato?

Tre casi: 1) snapshot disponibile → btrfs subvolume snapshot, ripristino completo istantaneo. 2) senza snapshot, cancellazione recente → btrfs-restore -t sfrutta il residuo CoW. 3) cancellazione vecchia o extent riciclati → btrfs-find-root poi btrfs-restore con rootid specifico.

ZFS e XFS offrono soluzioni equivalenti a ext4?

Non secondo la stessa logica. ZFS = snapshot-first: completo con uno snapshot, impossibile senza. XFS = xfs_undelete 1.5 dal 2024, che recupera di più sui file piccoli che su quelli grandi.

Quale distribuzione Linux per il recupero nel 2026?

SystemRescue 11.04 (arsenale completo, kernel 6.9 LTS), CAINE 13.0 (rigorosa modalità forense con blocco in scrittura), Kali Linux 2026.1 (recupero + indagine post-incidente).

Verdetto: Linux recupera bene quando ci si prepara, male quando si improvvisa

Il recupero Linux nel 2026 dipende meno dallo strumento che da due decisioni prese a monte. Prima decisione: la scelta del filesystem in base al profilo di rischio. Per una workstation utente senza snapshot automatici, ext4 + ext4magic offre il miglior compromesso sui file piccoli cancellati di fresco. Per un server o una workstation configurati da un amministratore, Btrfs o ZFS con snapshot orari automatizzati (Snapper, sanoid/syncoid, zfs-auto-snapshot) garantisce un recupero pressoché completo in pochi secondi.

Seconda decisione: la rapidità d'intervento. Su un volume attivo, la finestra utile si conta in minuti, non in ore. La regola che riassume tutto: smontaggio immediato, imaging con ddrescue, scansione sull'immagine — mai sul volume sorgente. Un amministratore che padroneggia SystemRescue o CAINE, che automatizza i suoi snapshot e che sa identificare il filesystem di destinazione in meno di 30 secondi supera la grande maggioranza degli incidenti senza intervento a pagamento.

Per i casi oltre il perimetro software — corruzione hardware del disco, RAID degradato senza superblocco, cifratura senza chiave — orientarsi verso un laboratorio resta indispensabile. Calcolare da 600 a 2.200 € presso Ontrack, DriveSavers o Recoveo per un caso Linux classico con disco fisico integro, e fino a 5.000 € per le configurazioni combinate LUKS + RAID + LVM.