Recupero dati da SSD: perché non funziona come con un hard disk (aggiornato: giugno 2026)

Quando un hard disk meccanico si guasta, nella maggior parte dei casi il dato è ancora lì. Resta scritto sui piatti magnetici finché qualcosa non lo sovrascrive fisicamente, e recuperarlo richiede comunque procedure di laboratorio tutt'altro che banali, dalla riparazione della scheda elettronica alla sostituzione delle testine in ambiente protetto, fino alla ricostruzione del firmware quando è quest'ultimo a bloccare l'accesso ai dati. Con un SSD questa certezza salta completamente, e il motivo non è la velocità o l'assenza di parti in movimento. È il modo in cui il dato viene gestito a livello fisico.

Vale la pena capirlo prima di collegare l'unità per la decima volta sperando che "questa volta venga letta", perché spesso è proprio quel tentativo a chiudere definitivamente la porta.

Il discorso vale per gli SSD consumer più diffusi, dai Samsung ai Kingston, dai Western Digital/SanDisk ai Crucial, che siano SATA o anche i modelli NVMe montati nei notebook recenti. Cambiano controller, NAND, firmware e strategie interne, ma il principio resta lo stesso: l'SSD non è un supporto "trasparente" come un vecchio disco magnetico. È un sistema complesso che decide continuamente dove, come e quando scrivere davvero i dati.

Il controller decide tutto, e tu non lo vedi

In un SSD i dati non vengono scritti dove il sistema operativo crede. Quando Windows scrive un file all'indirizzo logico X, il controller dell'unità decide in autonomia in quale cella fisica della memoria NAND finiranno davvero quei bit. Questa corrispondenza tra indirizzi logici e posizione reale viene gestita da una mappa interna chiamata Flash Translation Layer, e cambia di continuo.

Cambia perché il controller distribuisce le scritture su tutte le celle disponibili per non consumarne sempre le stesse (è il wear leveling), perché sposta blocchi in background, perché riorganizza lo spazio. Il risultato pratico è che il contenuto grezzo dei chip, letto senza la mappa, è un mosaico sparpagliato e privo di senso. Non un file frammentato in due o tre pezzi come capitava sugli hard disk, ma migliaia di frammenti riposizionati secondo una logica nota solo al firmware dell'unità.

Quando il controller funziona, traduce tutto questo in tempo reale e tu vedi una cartella ordinata. Quando il controller si guasta, o quando il firmware non riesce più a inizializzarsi correttamente, la mappa diventa inaccessibile. Nei guasti seri il controller è spesso coinvolto direttamente o indirettamente, anche se i chip NAND contengono ancora buona parte dei dati. A quel punto leggere i chip non basta: bisogna ricostruire la traduzione da zero.

La cifratura che nessuno ha attivato

C'è un dettaglio che sorprende anche molti tecnici: molti SSD moderni applicano forme di cifratura o trasformazione interna dei dati gestite dal controller, anche quando l'utente non ha mai attivato manualmente BitLocker, FileVault o altri sistemi di protezione. In diversi modelli il controller può applicare una cifratura AES sull'intero contenuto, con una chiave che resta dentro l'unità stessa. Serve a rendere istantanea una cancellazione sicura e, in parte, a gestire meglio le scritture.

L'effetto collaterale, in caso di guasto, può essere pesante. Se il controller muore portandosi dietro o rendendo inaccessibile la chiave, i chip NAND possono contenere dati che, letti direttamente, sembrano rumore. Non c'è software per utente finale che possa interpretarli. Il recupero passa per il ripristino del controller o per la ricostruzione delle condizioni che permettono di rimettere insieme chiave, algoritmo e dato.

Questo è il punto in cui il "fai da te" non solo è inutile, ma diventa controproducente.

Perché i software di recupero ti illudono

Capita spesso questa scena. L'utente lancia un programma di recupero, la scansione gira, e compare l'elenco dei file con nome, dimensione, data. Sembra fatta. Poi avvia il ripristino e i risultati sono documenti illeggibili, foto corrotte, video che nessun player apre.

Non è un bug del software e non è un difetto dell'SSD. È il comando TRIM che ha fatto il suo lavoro. Quando un file viene eliminato, il sistema operativo segnala al controller quali blocchi non servono più, e l'unità avvia la cancellazione fisica di quelle celle in background, in pochi istanti. Il programma di recupero legge ancora i metadati residui, quindi ti mostra l'elenco, ma i blocchi sotto sono già stati azzerati. La finestra utile dopo la cancellazione di un file su SSD si misura in minuti, non in giorni.

E c'è un rischio aggiuntivo che pochi considerano: ogni nuova accensione, ogni nuova scansione, ogni tentativo di clonazione su un'unità instabile la stressa ulteriormente. In laboratorio capita spesso di vedere SSD arrivati dopo due o tre scansioni complete con software diversi: a quel punto il problema non è solo il guasto iniziale, ma anche lo stress aggiunto durante i tentativi. Le celle in sofferenza per errori di ritenzione o read disturb possono passare da "leggibili a fatica" a "perse" proprio durante i tentativi di salvataggio improvvisato.

Chip-off: non è più quello di una volta

Una via di recupero, quando il controller è irrecuperabile, è rimuovere fisicamente i chip NAND e leggerne il contenuto con apparecchiature dedicate. È la tecnica chiamata chip-off. Su una vecchia pendrive USB era relativamente lineare: si leggeva il chip e, con un po' di lavoro, si rimetteva insieme il file system attraverso appositi algoritmi.

Sugli SSD attuali è un'altra categoria di problema. Anche su una pendrive il dato dentro la NAND non è scritto in chiaro: viene mescolato con uno scrambling XOR per ridurre le interferenze elettriche tra celle, distribuito su più chip in interleaving e protetto da codici di correzione errori (ECC) da decodificare. Su un SSD, però, tutto questo diventa molto più complesso, perché i controller gestiscono più canali e schemi di codifica più sofisticati, e a valle si aggiunge quasi sempre la cifratura. Leggere i chip è solo il primo passo. Tutto il resto è ricostruire l'ordine corretto, invertire lo scrambling, applicare l'ECC e riassemblare i frammenti rispettando la geometria interna di quel preciso modello di controller.

È un lavoro che richiede attrezzature professionali, una conoscenza approfondita delle famiglie di controller in commercio e, soprattutto, l'esperienza per riconoscere quale tra decine di varianti di codifica è stata usata su quella specifica unità.

Tre tipi di guasto, tre scenari diversi

Recuperare file da SSD non è un unico problema. Sotto la stessa etichetta ci sono situazioni che richiedono approcci opposti, e capire in quale ti trovi cambia tutto.

Il guasto logico è il più benigno. Il dispositivo viene riconosciuto ed è leggibile, ma il file system è corrotto, una partizione è sparita o un file è stato cancellato. Qui, finché il TRIM non ha già azzerato le celle, un intervento software ha ancora qualche margine. È anche l'unico caso in cui un tentativo casalingo non rischia danni gravi, a patto di lavorare su una copia e mai sull'unità originale.

Il guasto del controller o del firmware è la categoria più frequente tra quelli seri. L'SSD smette di presentarsi come dovrebbe: non viene rilevato, mostra una capacità sbagliata, compare per qualche secondo e poi sparisce. Il dato sui chip può essere perfettamente intatto, ma senza un controller funzionante la mappa di traduzione e la chiave di cifratura restano irraggiungibili. Nessun software entra, perché manca proprio l'interlocutore che dovrebbe rispondere.

Il danno alle NAND è il più insidioso. Le celle perdono carica, accumulano errori di ritenzione, si degradano con i cicli di scrittura. A volte l'unità sembra ancora funzionare e restituisce dati silenziosamente corrotti, una situazione peggiore di un disco morto, perché te ne accorgi quando ormai il file è andato. In questi casi il recupero passa quasi sempre per la lettura diretta dei chip e per un lavoro fine di correzione degli errori.

La conseguenza pratica è una sola: prima di toccare qualsiasi cosa bisogna capire di quale dei tre si tratta, perché la mossa giusta per il primo scenario è esattamente quella sbagliata per gli altri due.

Sintomi tipici di un SSD da non stressare

Ci sono segnali davanti ai quali conviene evitare prove ripetute, soprattutto se i dati sono importanti. Un SSD che non viene rilevato dal BIOS, che compare con capacità errata, che viene visto come 0 GB o con pochi megabyte, che appare e scompare durante l'uso o che blocca il computer durante la copia dei file non va trattato come una semplice partizione danneggiata.

Lo stesso vale quando la copia procede a pochi KB/s, quando il sistema chiede improvvisamente di formattare l'unità, o quando i software di recupero mostrano file con nome corretto ma contenuto corrotto. Sono sintomi comuni su modelli Samsung, Kingston, Western Digital, SanDisk, Crucial e su molti altri SSD SATA o NVMe: il marchio cambia, ma il comportamento tipico di un guasto serio è molto simile.

In questi casi la cosa più utile non è provare un altro programma, ma fermarsi prima che la situazione peggiori.

Quando ha senso fermarsi

La regola pratica è semplice. Se l'SSD non viene riconosciuto dal BIOS, se sparisce dopo pochi secondi, se appare con capacità errata o se i tentativi software restituiscono file corrotti, il problema è quasi certamente a livello di controller, firmware o NAND. In questi casi nessun programma per utente finale può aiutare, e ogni tentativo aggiuntivo riduce le probabilità di un recupero pulito.

A quel punto la scelta sensata è spegnere l'unità e rivolgersi a un laboratorio specializzato nel recupero dati da SSD, come SOSdati.com, dove la lettura diretta dei chip e la ricostruzione del controller si fanno con strumenti adeguati. Conservare l'SSD intatto, senza altri tentativi, è la cosa più utile che si possa fare per i propri dati.