Un archivio che costa poco ma richiede due giorni per tornare online non è un backup operativo. Allo stesso modo, un nastro isolato dal ransomware non serve se nessuno sa più montarlo e verificarlo. La scelta tra LTO e object storage cloud va fatta sul tempo di recupero reale, non sul prezzo nominale per terabyte.
Il tema è tornato attuale il 2 settembre 2026. Il programma LTO ha comunicato che nel 2025 sono stati spediti 160,3 exabyte di capacità compressa; nel primo trimestre 2026 la capacità spedita è cresciuta del 57% rispetto allo stesso periodo del 2025. Il nastro non è un residuo del passato: continua a essere comprato per archivi, backup cyber-resilienti e dati prodotti dai workload AI. Ma questo non lo rende automaticamente la scelta corretta per una PMI.
Il criterio: recuperare i dati, non conservarli soltanto
Confronto le due opzioni su quattro punti: costo totale, tempo di recupero, resistenza a errori e attacchi, carico operativo. È il perimetro che conta per un’azienda che deve conservare backup WordPress, esportazioni di database, media, log di automazioni e dataset usati da sistemi AI.
| Criterio | Nastro LTO on-premise | Object storage cloud |
|---|---|---|
| Costo | Hardware e gestione iniziali, costo marginale basso su archivi grandi e stabili | Nessun drive da acquistare, ma canone, richieste e recuperi vanno modellati |
| Recupero | Serve localizzare, montare e leggere la cartuccia | Ripristino avviabile via API, con tempi che dipendono dalla classe scelta |
| Isolamento | Air gap fisico quando la cartuccia è offline | Immutabilità logica con versioning, policy e Object Lock |
| Gestione | Inventario, rotazione, test, compatibilità e custodia | Lifecycle automatizzabile, IAM, logging e controllo della fattura |
LTO: forte sul dato freddo, debole sulla semplicità
LTO parte con un vantaggio difficile da replicare: una cartuccia rimossa dal drive non è raggiungibile dalla rete. IBM descrive questo air gap fisico come una barriera contro attacchi online; sono disponibili anche supporti WORM, che impediscono la sovrascrittura, e cifratura dei dati a riposo. L’ultima estensione di LTO-10 annunciata dal programma arriva a 40 TB nativi per cartuccia. Sono caratteristiche concrete per una copia che deve sopravvivere alla compromissione dell’ambiente principale.
Il rovescio è operativo. Il nastro chiede un drive compatibile, software di backup, catalogo affidabile, una procedura di rotazione e test periodici di ripristino. Va inoltre pianificata la migrazione fra generazioni. Se queste attività dipendono da una sola persona o non entrano nel calendario, l’air gap diventa un falso senso di sicurezza: il dato esiste, ma il processo di recupero no.
Per un team che possiede già una libreria e produce molti dati poco variabili, il costo marginale può essere interessante. Per una piccola azienda che parte da zero, il CAPEX e la competenza richiesta pesano più del costo della singola cartuccia.
Cloud archive: automazione facile, fattura meno leggibile
L’object storage ribalta il problema. Si integra con API, policy di lifecycle e strumenti di backup già usati nei workflow web. Un export notturno di WordPress può essere cifrato, versionato e spostato automaticamente in una classe archive. Lo stesso vale per media originali, log di n8n o Make e dataset che non devono restare nello storage veloce usato per inferenza.
La comodità non equivale a disponibilità immediata. AWS documenta per S3 Glacier Flexible Retrieval accessi expedited tipicamente in 1-5 minuti, standard in 3-5 ore e bulk in 5-12 ore. Per S3 Glacier Deep Archive il recupero standard arriva entro 12 ore, mentre il bulk può richiedere fino a 48 ore. Deep Archive applica inoltre una durata minima di 180 giorni; transizioni, richieste e ripristini possono generare costi aggiuntivi.
La protezione dal ransomware è logica, non fisica. S3 Object Lock usa un modello WORM e può impedire cancellazione o sovrascrittura durante la retention. Funziona solo se IAM, account di amministrazione e policy sono progettati bene. Una credenziale troppo potente o una retention configurata male resta un rischio. Il cloud toglie il lavoro meccanico, non la responsabilità.
Cosa cambia per WordPress, automazioni e AI
Per WordPress separerei tre livelli. Database e configurazioni con RTO corto restano su storage rapidamente recuperabile. Media originali e snapshot mensili possono scendere in object storage archive. Una copia realmente isolata, su nastro o altro supporto offline, protegge dagli errori che coinvolgono anche l’account cloud.
Nei workflow AI la distinzione è ancora più importante. Dataset attivi, indici vettoriali e checkpoint necessari alla produzione non sono dati freddi. Metterli in Deep Archive per risparmiare significa accettare ore di attesa quando serve ricostruire il servizio. Log storici, versioni dismesse dei dataset e output intermedi riproducibili sono candidati migliori. Prima di spostare tutto, conviene definire RPO e RTO per classe di dato e preparare un export di emergenza del workflow AI.
Il costo va letto nello stesso modo. Il prezzo di storage è una riga; vanno aggiunti recupero, traffico, richieste, test e ore di gestione. È lo stesso errore che si commette valutando l’infrastruttura AI solo dal costo della GPU.
La scelta netta
Per la maggior parte delle PMI che non possiede già competenze e hardware LTO, sceglierei object storage cloud con versioning, Object Lock, account separato e test di restore calendarizzati. È più semplice da automatizzare e rende verificabile l’intera catena.
Sceglierei LTO quando l’archivio è grande, stabile, conservato a lungo e gestito da un team che può mantenere drive, catalogo e rotazione. In quel caso il nastro non sostituisce il cloud: diventa la copia offline del piano ibrido. La decisione corretta non è “vecchio contro nuovo”, ma “chi garantisce il ripristino, in quanto tempo e con quale procedura?”.