Gli
SSD hanno ormai soppiantato gli
hard disk meccanici nella maggior parte degli scenari quotidiani. Sono veloci, silenziosi, consumano poca energia e sopportano senza difficoltà enormi volumi di scrittura. Molti "consigli di ottimizzazione", come disattivare l'indicizzazione, spostare il
file di paging o ridurre la generazione di
log, considerati essenziali un decennio fa, non hanno oggi la stessa importanza di allora. Le moderne unità a stato solido gestiscono senza fatica carichi di lavoro molto superiori.
Esiste però un limite strutturale spesso ignorato: la
memoria NAND può perdere gradualmente i dati quando l'unità rimane non alimentata per lunghi periodi. Non si tratta di un difetto, bensì di una conseguenza diretta del modo in cui funzionano queste memorie.
Perdita di carica, il punto debole della NAND
Ogni cella NAND conserva i bit intrappolando elettroni in un piccolo isolante. Con il passare del tempo la carica tende a dissiparsi ed il fenomeno accelera con l'aumento della temperatura. Più elevata è la densità di dati per cella, minore è il margine di sicurezza:
- SLC: una sola informazione per cella, grande stabilità;
- MLC: due bit per cella, margine più ristretto;
- TLC: tre bit per cella, maggiore vulnerabilità;
- QLC: quattro bit per cella, stabilità molto ridotta.
Il progresso verso unità sempre più capienti ha quindi un prezzo: la retention, ossia la capacità di mantenere i dati senza alimentazione, cala sensibilmente. Un vecchio SSD SLC poteva conservare le informazioni per molti anni; un SSD QLC usurato può iniziare a perdere dati già dopo pochi mesi di inattività.
Gli standard JEDEC confermano la tendenza: gli SSD consumer garantiscono un anno di retention da spenti, mentre quelli enterprise, pensati per restare sempre accesi, solo tre mesi.
Accendere l'unità non basta, serve leggere tutto
Un aspetto poco noto è che collegare l'SSD dopo un lungo periodo non è sufficiente a "risvegliarlo". Perché il controller possa rilevare i bit deboli e riscriverli, è necessario leggere l'intera unità. Molti controller eseguono refresh solo al verificarsi di errori correggibili; ciò significa che aprire un singolo file non protegge i dati già memorizzati.
Procedere periodicamente con una lettura completa, ad esempio tramite un comando di copia verso `/dev/null` (dd if=/dev/sdX of=/dev/null su Linux) od uno scrub del file system, è l'unico modo per attivare i meccanismi di correzione.
Firmware più aggressivi e guasti improvvisi
Un ulteriore rischio deriva dai firmware moderni. Se il controller giudica alcuni blocchi troppo degradati, può dichiarare l'unità "FAILED" e bloccare completamente l'accesso ai dati. In tal caso il recupero è possibile solo dissaldando fisicamente i chip di memoria e ricostruendo manualmente il contenuto, operazione riservata a laboratori specializzati.
Le unità più datate (SLC e MLC fino al 2013 circa) risultano paradossalmente più longeve. Le generazioni successive, nate per aumentare la capacità, si affidano a celle più piccole e instabili e a firmware molto più complessi, con un uso intensivo di algoritmi LDPC per compensare la perdita di carica.
Un problema per l'archiviazione, non per l'uso quotidiano
Nell'uso giornaliero gli SSD non presentano rischi: la continua riscrittura mantiene le celle stabili ed il controller può correggere tempestivamente eventuali errori. Il problema riguarda l'archiviazione a lungo termine senza alimentazione, situazioni tipiche per: fotografi che conservano progetti conclusi, ricercatori e professionisti con dataset storici, chi usa SSD come copie offline anti-ransomware, chi ripone vecchi SSD pensando che "durino per sempre".
Il ruolo cruciale della strategia 3-2-1
La regola del backup 3-2-1 resta lo standard di sicurezza più affidabile: tre copie dei dati, su almeno due supporti diversi ed una copia offsite. Usare solo SSD, persino due di marche differenti, non rientra in questo modello, perché il limite fisico della NAND è identico.
Combinare SSD, hard disk tradizionali e soluzioni cloud riduce i rischi legati alla retention, al firmware e ad eventuali eventi disastrosi come incendi, furti o attacchi ransomware.
Chi usa Slackware lo sa, mantenere 
