Posts Tagged ‘archivi digitali’

Nelle reti neurali il futuro dei data center (e degli archivi digitali)?

neural network

neural network di onkel_wart (thomas lieser), su Flickr

L’idea di fondo che permea buona parte dei post pubblicati in questo blog è che in tempi di cloud computing imperante, gli archivi digitali stiano tendenzialmente finendo per coincidere con i data center; questi ultimi, nella teoricamente impalpabile nuvola, rappresenterebbero la parte “materiale” (la ferraglia, per intenderci) del sistema, nella quale i nostri dati e documenti digitali trovano riparo.
Quest’approccio archivistico ai data center, inevitabile alla luce di quelli che sono i miei interessi, mi ha dunque inesorabilmente portato a prendere in considerazione queste infrastrutture strategiche essenzialmente nella loro “staticità” (intendendo con tale termine la capacità di offrire, materialmente, ricovero ai dati e documenti caricati nella nuvola), sottacendo nella maggior parte dei casi l’insieme di compiti computazionali che in misura crescente deleghiamo “al lato server“.
L’annuncio dato da Google con un post nel suo blog circa l’applicazione di tecnologie machine learning in uno dei suoi data center (DC), oltre ad aprire scenari che fino a pochi anni fa avrebbero trovato posto al più nei libri di fantascienza, spariglia le carte e mi impone a riflettere se l’impostazione sin qui adottata rimanga corretta o sia al contrario da rivedere.
Ma, prima di abbandonarci a voli pindarici, partiamo dalla notizia che, va detto, in sé non rappresenta nulla di trascendentale: in sostanza i tecnici dell’azienda di Mountain View, sempre alla ricerca di nuovi metodi per tagliare i consumi energetici dei propri DC, invece di seguire le teorie “classiche” che puntano su aspetti quali la dislocazione geografica (con tentativi talvolta stravaganti, come il fantomatico data center galleggiante approntato nella baia di San Francisco proprio da Big G e che così tanto ha fatto discutere lo scorso autunno), hanno ottenuto importanti risparmi implementando un “neural network” capace di apprendere dal comportamento di quei macchinari presenti nel DC e deputati al raffreddamento dei server (aspetto, come noto, costosissimo ma fondamentale per garantirne la massima operatività ed efficienza), prevedendo l’andamento dei consumi e, passaggio successivo, ottimizzandoli.
Ma cosa intende Google per rete neurale (artificiale)? Come specificato in un white paper diffuso per l’occasione, l’idea di fondo è realizzare “[a] class of machine learning algorithms that mimic cognitive behaviour via interactions between artifical neurons”; tali algoritmi permettono di avviare nelle macchine un processo di “apprendimento” (training) progressivo e cumulativo (nonché potenzialmente infinito) che ha come obiettivo l’accrescimento complessivo della “conoscenza” e l’accuratezza / qualità dei dati raccolti, con il fine dichiarato di individuare “patterns and interactions between features to automatically generate best-fit model”.
Nel concreto che hanno fatto i ricercatori di Google? Hanno applicato una serie di sensori in punti chiave del data center (quali refrigeratori, torri di raffreddamento, scambiatori di calore, pompe, etc.) ed hanno iniziato a cambiare, uno alla volta, i vari parametri tenendo nel frattempo costanti gli altri. Sono in tal modo riusciti a vedere non solo gli effetti, sull’intero sistema, dei cambiamenti apportati ma, grazie agli algoritmi di apprendimento utilizzati, sono stati in grado di far “imparare” il sistema dalle performance passate sviluppando progressivamente capacità predittive tali da migliorare quelle future.
Si capirà dunque come i titoloni circolati nei giorni scorsi (vedi le “superintelligent server farms” di cui ha parlato Techcrunch) siano eccessivi: Google, in definitiva, ha “semplicemente” reso operativo, peraltro in via sperimentale, un primo fascio di reti neurali artificiali applicato a quella che è la parte “meccanica” dei DC.
Il data center supercervellone capace di agire (ed interagire) sulla falsariga del celeberrimo HAL 9000 del film “2001 – Odissea nello spazio” (ovvero un supercomputer dotato di intelligenza artificiale ed in grado, se interrogato, di fornirci risposte), è dunque lungi dal divenire realtà.
Una volta depurata la notizia dai risvolti “fantascientifici” con i quali è stata subito ricoperta, bisogna però pure ammettere come essa, al di là del suo significato “basico” (ovvero la possibilità, anche per quei DC che svolgono funzioni di “archivio”, di adottare algoritmi di machine learning grazie ai quali ottenere considerevoli risparmi), riveste effettivamente una notevole importanza archivistica.
E’ stato infatti compiuto, con il progetto pilota di Google, un importante salto qualitativo: è infatti solo questione di tempo prima che i sensori vengano applicati, oltre che alla parte meccanica, ai server medesimi. Quando ciò avverrà il neural network instaurerà nessi e collegamenti (assimilabili in qualche modo al vincolo archivistico impuro?) tra i vari dati e documenti conservati sprigionandone l’intero potenziale informativo (tema connesso a quello dei big data ed al warehouse computing del quale ho parlato giusto nel mio ultimo post) e decretando così l’importanza strategica degli archivi.
Inoltre, aspetto non secondario, d’ora in poi l’idea statica di “data center come archivio”, ovvero come luogo fisico nel quale risiedono concretamente i dati ed i documenti digitali, è destinata a lasciar posto a quella, dinamica, di data center come luogo nel quale si instaurano collegamenti e percorsi nuovi e non prevedibili da parte… di un’intelligenza artificiale; l’attenzione si sposterà, in altri termini, dal contenitore (il DC) al suo contenuto.
Con tutto ciò che ne consegue.

Il data warehouse in archivi e biblioteche

Teradata Storage Rack

Teradata Storage Rack di pchow98, su Flickr

Dei beni culturali come “oro nero dell’Italia” o, leggera variante sul tema, come “giacimenti” capaci di fungere da volano per l’economia nazionale si parla e scrive da decenni. L’idea di fondo, in ogni caso, è la medesima: la “cultura” genera ricchezza in modo tangibile e non solo in modo indiretto (ad es. attraverso il “godimento” di un quadro oppure in virtù delle benefiche ricadute sul capitale umano)!
Un neo di questo approccio era rappresentato dal fatto che i beni archivistici e librari venivano tradizionalmente considerati come le “cenerentole”, spettando al contrario a musei e siti archeologici la parte del leone.
Tale scenario è radicalmente cambiato, a ben guardare, con l’avvento dell’era digitale: nel mondo dei bit ad avvantaggiarsi della possibilità di essere trasformati in una sequenza di 0 ed 1 sono, piuttosto che le statue ed i quadri (almeno fino a quando realtà virtuale / aumentata non faranno il salto di qualità, n.d.r.), proprio libri e documenti. Questi ultimi, come noto, sono sempre più oggetto di trattamenti (che avvengono perlopiù in automatico) volti a raccogliere le informazioni / i dati in essi contenuti.
Sulle implicazioni teoriche e tecnico-pratiche di questo fenomeno ho già scritto qualcosa in questo blog, senza però mai affrontare quelli che sono, non nascondiamocelo, i motivi principali per cui i dati e le informazioni risultano così “attraenti”, vale a dire gli evidenti risvolti di business.
Del resto di business information in biblioteca si parla da decenni (basta pensare al vetusto “Business Information. How to Find and Use It” di Marian C. Manley, pubblicato nel lontano 1955…) ed oggi è normale che le principali biblioteche pubbliche offrano un servizio dedicato (vedi la British Library); analogamente è superfluo rilevare come gli archivi digitali rappresentino, in quanto a ricchezza di dati e documenti da destrutturare (data / text mining) al fine di ricavarne utili informazioni, un autentico Eldorado.
In altri termini non ci si deve scandalizzare per l’accostamento, che può apparire dissacrante specie in un paese come l’Italia in cui l’approccio predominante ad archivi e biblioteche è quello storico-umanistico, alle concrete questioni di business; al contrario, credo che vadano esplorate a fondo le evidenti, allettanti prospettive che si aprono (a fianco, si badi, di altre applicazioni che, invece, altro non sono che un modo nuovo di fare qualcosa che per certi versi si è sempre fatto).
Ritengo in particolare ci si debba soffermare sul concetto di data warehouse (letteralmente traducibile come “magazzino di dati”, n.d.r.), dal momento che esso presenta interessanti analogie con quello di archivio.
Infatti, a prescindere ora dal tipo di architettura con la quale lo si implementa (ad uno, due oppure tre livelli oppure top-down o bottom-up), esso può essere considerato una specie di “archivio” informatico o, più correttamente, un repository nel quale sono stipati dati selezionati (il che ne fa una sorta di collezione, cioè dal punto di vista teorico l’antitesi di un archivio, n.d.r.) sfruttati da un’organizzazione (in genere un’azienda di grosse dimensioni) per facilitare e velocizzare la produzione di analisi e di relazioni il più possibile attendibili / predittive e pertanto utili a fini decisionali ed, in subordine, operativi.
In breve, un sistema di data warehousing raccoglie dati provenienti dall’interno (allocandoli in tal caso in data mart) e dall’esterno dell’organizzazione, li trasforma, ed una volta “puliti” (cleaning), omogeneizzati e corredati di un adeguato numero di metadati, li stocca nelle unità di storage da dove vengono “richiamati” (aggregandoli / analizzandoli / comparandoli) e presentati alla persona deputata a compiere in primis le scelte aziendali strategiche “pure” così come quelle relative ad aree quali il controllo di gestione, l’e-commerce, il risk e l’asset management, il supporto alle vendite / marketing, etc.; si tratta dunque di un imprescindibile sistema di business intelligence.
E se si deve ribadire che il (contenuto di un) data warehouse non è un archivio né tantomeno una biblioteca, non devono nemmeno essere sottaciute alcune potenziali aree di interesse: i vertici della Pubblica Amministrazione, chiamata in questi anni ad un titanico sforzo di rinnovamento in chiave digitale, possono ignorare le potenzialità informative di quegli inesauribili “magazzini di dati” che sono gli archivi?
Similmente le biblioteche, che così precocemente si sono gettate nella mischia offrendo servizi di business information, possono non compiere l’ulteriore passo entrando nell’agone del business intelligence?
Peraltro per le biblioteche accademiche (specie quelle afferenti ai dipartimenti di scienze) i compiti potrebbero essere ben più “critici”: nel momento in cui la mole di dati ottenuta dalle varie ricerche condotte dai team si fa immane, non è logico pensare che la tradizionale funzione di supporto alla didattica ed alla ricerca avvenga non solo mettendo a disposizione i risultati di analoghe ricerche nel mondo (mediante i consueti canali quali riviste scientifiche peer reviewed, abstract, e-journal, etc.) ma anche concorrendo alla “manutenzione” di quei sistemi deputati a contenere e rielaborare i dati grezzi come sono per l’appunto quelli dedicati al data warehouse?
Insomma, anche su questo fronte le opportunità non mancano. Come sempre ci vuole, oltre ad un minimo di lungimiranza, una buona dose di coraggio ed intraprendenza per saperle cogliere.

Fog computing, l’archivio dell’Internet delle Cose

THETA Notes di petahopkins

Photo credits: THETA Notes di petahopkins, su Flickr

In questo blog mi sono occupato più volte di cloud computing: troppe infatti le ripercussioni sulle modalità di creazione, sedimentazione e conservazione degli archivi digitali (tanto di persona quanto di organizzazioni pubbliche e private) per non parlarne!
Proprio per questo motivo è il caso di presentare, a chi non ne avesse già sentito parlare, quella che potrebbe essere la nuova buzzword del mercato IT per i prossimi anni.
Mi sto riferendo al concetto di fog computing il quale, si badi, non ha al momento avuto implementazioni pratiche né alcuna definizione standard da parte di organizzazioni internazionali quali ad esempio il NISO.
Il fog computing infatti è un paradigma sviluppato, in analogia a quello di cloud computing, un paio d’anni fa da un gruppo di ricercatori di Cisco ma che è diventato oggetto di discussione da parte di un pubblico più amplio rispetto a quello degli addetti ai lavori solo in tempi recenti.
Ma cosa si intende, più precisamente, con fog computing? La stessa terminologia è di aiuto a comprendere per bene: se la nuvola (cloud) si staglia in alto nel cielo, la nebbia (fog) si colloca ad un livello intermedio tra questa e la Terra, anzi… assai aderente al suolo! Detto fuor di metafora il fog computing si prefigge di creare un’infrastruttura (con le canoniche risorse di calcolo, storage e rete) capace di rispondere in misura migliore rispetto alla Nuvola a quelle che saranno le probabili esigenze del prossimo futuro, futuro che sarà caratterizzato dall’exploit del cosiddetto Internet delle cose (in inglese Internet of Things o, più brevemente, IoT), ovvero dalla massiccia ed attiva presenza in Rete non solo di agenti umani ma anche di oggetti (e non solo quella serie di dispositivi indossabili tipici del wearable computing ma anche e soprattutto automobili, impianti semaforici, elettrodomestici, sensori vari sparsi per la città e lungo le vie di comunicazione con la funzione precisa di catturare dati relativi all’ambiente, alle condizioni del traffico, etc.).
Secondo gli esperti di Cisco, in altri termini, per far sì che l’IoT funzioni adeguatamente bisogna disporre di una infrastruttura ad hoc (la “nebbia”, per l’appunto) che sia complementare rispetto a quella fornita dalla cloud, ritenuta troppo centralizzata e “distante” (e di conseguenza con tempi di latenza troppo elevati rispetto a quelli richiesti allorquando in ballo ci sono i dati relativi, ad esempio, al traffico stradale ed il semaforo deve calcolare in frazioni di secondo, in base al numero di autovetture, bici e pedoni in procinto di attraversamento, come regolarlo nel modo più efficiente); le caratteristiche del fog computing sono dunque la bassa latenza, l’elevata distribuzione geografica, la connettività mobile (tramite punti di accesso Wi-Fi o reti LTE, ma in ogni caso con netta predominanza del wireless), la forte presenza di applicazioni in streaming o, ancora più probabile, in real time (come ben esemplificato dal caso del semaforo presentato poc’anzi).
Dal punto di vista fisico tutto ciò si traduce, come sempre, nella creazione di data center; come ricordato all’inizio la realizzazione di questi ultimi non è ancora stata avviata ma, considerando il requisito dell’elevata distribuzione geografica, verosimilmente essi saranno di dimensioni più contenute e più “agili”; in particolare le risorse di storage non saranno pensate per l’archiviazione di medio lungo periodo bensì per quella di breve e contraddistinte pertanto da alte prestazioni ed alti costi (non so quali soluzioni abbiano in mente quelli di Cisco, diciamo che trovo improbabile l’utilizzo di tape library!); i dati che necessitano di un più approfondito esame o semplicemente di una conservazione più lunga verranno invece avviati alla cloud dove, stipati assieme ai dati provenienti dalle altre fog geograficamente distribuite sulla superficie terrestre, andranno a creare la moltitudine di big data destinati ad un’analisi altrettanto “big” (big analytics).
Ciò che credo vada qui sottolineato è in primo luogo che il fog computing risponde all’esigenza, avvertita da più parti, di maggior “concretezza” e solidità rispetto al cloud computing (indicativo di questa tendenza, anche nel nome, il servizio Metal as a Service); in secondo luogo va rimarcato come i dati trattati dal nuovo modello proposto da Cisco, pur essendo provenienti dall’IoT, non sono per questo meno importanti e, soprattutto, sensibili rispetto a quelli che finiscono nella cloud per la conservazione di lungo periodo: infatti accanto ai dati relativi all’umidità relativa ed alla percentuale di polveri sottili nell’aria potrebbero pure figurare, man mano che l’e-health prenderà piede, quelli relativi al nostro livello di glucosio nel sangue trasmessi al nostro medico oppure quelli, più banali ma non meno invasivi, inviati dall’auto durante i nostri viaggi (georeferenziazione). La definizione di Internet delle cose è infatti per certi versi ingannevole; quest’ultima infatti non è solo smart city o smart grid o altri termini tanto accattivanti quanto vaghi; al contrario essa è, andando oltre agli slogan, composta di moltitudini di dati che riguardano le persone: finiscano essi nella nebbia o nella nuvola, vanno adeguatamente trattati.
Insomma, altro lavoro in vista non solo per i responsabili IT, per i sistemisti ed i data analyst ma anche per gli archivisti.

Per ulteriori materiali di approfondimento consiglio la lettura dello Storify appositamente realizzato.

Archiviazione digitale: la soluzione è il peer to peer?

Il modello di cloud p2p di Space Monkey

Il modello di cloud p2p di Space Monkey (fonte: http://www.spacemonkey.com/press)

Il cloud computing è stato un modello tecnologico che sin dal suo apparire ha fortemente diviso la comunità degli informatici e dei CIO tra fautori ed oppositori. A fronte degli evidenti (?) vantaggi di natura economica e di disponibilità H24 dei propri dati / documenti, si è sempre sottolineato come si perdesse il controllo diretto sugli stessi; forti dubbi inoltre venivano (vengono) sollevati in ordine alla tutela della privacy anche se, puntualizzavano i favorevoli, ciò appariva come un qualcosa di accettabile in ragione della sicurezza complessiva garantita dalle strutture (quegli enormi data center che Google, Facebook, Amazon, Apple, etc. vanno costruendo per mezzo mondo) che li ospitavano.
L’uragano Sandy ha però fatto in parte crollare queste certezze; ciò, unitamente a motivazioni di ordine economico (molti servizi non sono poi così convenienti come vorrebbero far credere…) ed ideologico (la ricerca di soluzioni di archiviazione green meno energivore rispetto ai data center, il ritorno ad un computing decentrato) ha indotto a sviluppare soluzioni alternative, soprattutto di personal digital archiving (dal momento che chi ha capacità e disponibilità economiche si costruisce la sua bella private cloud!), che salvassero i vantaggi minimizzando gli svantaggi.
Le linee ad oggi seguite sono state essenzialmente due: la prima è stata quelle di realizzare una cloud domestica (altresì detta personal cloud) con tanto di mini server, gruppi di continuità in grado di salvaguardare dagli sbalzi di corrente e garantire un minimo di autonomia in caso di interruzione nell’erogazione di energia elettrica, etc.; la seconda strada è stata quella di realizzare una rete interconnessa di sistemi di storage di piccole dimensioni. E’ di quest’ultima che mi occupo in questo post.
Spieghiamo innanzitutto in che cosa consiste una “nuvola” P2P? In estrema sintesi si tratta di un sistema che permette la condivisione di risorse di storage connesse alla rete; in pratica ciascun appartenente al network mette a disposizione una porzione del proprio spazio di archiviazione ottenendone a sua volta in cambio dell’altro da parte degli altri aderenti alla rete: un apposito software provvede ad effettuare in automatico una copia (spacchettata e criptata) dei nostri dati / documenti inviandola a kilometri di distanza e garantendone in tal modo la sopravvivenza in caso di rotture del dispositivo di storage, di calamità naturali, etc.
Un esempio concreto è Space Monkey: per 10 dollari al mese questa azienda fornisce ai suoi utenti un dispositivo ad hoc da 3 terabyte di memoria (uno disponibile, i rimanenti due destinati ad ospitare file altrui) che promette di essere più veloce nelle operazioni di upload/download nonché energeticamente più efficiente; la “sopravvivenza” dei propri dati è garantita, come anzidetto, dal fatto che essi vengono replicati in molteplici dispositivi di storage ma anche dall’ulteriore copia che viene fatta nel data center gestito, quale ulteriore precauzione, da Space Monkey stessa. Un sistema siffatto, questa è l’idea, dovrebbe risentire assai meno di eventuali outage (qualunque ne sia la causa) e garantire pertanto l’accesso ai propri dati o perlomeno ad una buona parte di essi.
Personalmente ritengo che questa soluzione, almeno dal punto di vista archivistico, non risolva granché i problemi di personal archiving dal momento che la questione della sicurezza e della eventuale sottrazione di dati / documenti resta sul tappeto. Come non pensare, giusto per fare un banale esempio, che un eventuale malintenzionato si abboni al servizio e tenti, dall’interno, di violarne le difese? In questo senso un tradizionale data center concepito a mo’ di fortino mi sembra molto più rassicurante! Considerando poi che un sistema siffatto non ha pretese di garantire autenticità, affidabilità, integrità, etc. né tantomeno la conservazione nel medio – lungo periodo si deduce che esso non soddisfa i requisiti per fungere da valido sistema di archiviazione digitale (al massimo può essere uno dei tanti modi per diversificare il rischio, così come suggerito dagli esperti del National Digital Information Infrastructure and Preservation Program).
Paradossalmente però un modello distribuito strutturato sulla falsa riga di Space Monkey potrebbe rivelarsi felicemente applicabile ad archivi “istituzionali” massimamente in paesi territorialmente poco estesi come l’Italia: posto che, in attesa dell’entrata in vigore del “Regolamento generale sulla protezione dei dati” (redatto a livello europeo), il trasferimento degli stessi all’estero presenta non poche controindicazioni, bisogna prendere atto che per il momento le soluzioni non possono che essere nazionali; a sua volta ciò deve portare a riconoscere che, ai fini del disaster recovery, è impresa improba (in special modo una volta eliminate le numerose zone a rischio sismico, idrogeologico, etc.) riuscire ad impiantare nello Stivale due data center che si trovino ad una distanza di sicurezza soddisfacente l’uno dall’altro!
Giusto per fare un esempio concreto PARER, il principale Polo italiano per la conservazione digitale, ha due data center rispettivamente nelle province di Bologna e Milano più un sito di back-up offline in quella di Roma. Specie nel primo caso le distanze non mi sembrano sufficientemente rassicuranti (tra Bologna e Milano ci sono appena 200 km mentre tra Bologna e Roma 300 e tra Milano e Roma 480; qui uno strumento per farvi i vostri calcoli!): d’accordo, eventi come il citato Sandy sono improbabili in Italia, ma considerando la tropicalizzazione cui a detta di molti esperti va incontro il bacino del Mediterraneo ed alla luce dei frequenti eventi estremi dei quali siamo testimoni, un po’ di preoccupazione ce l’avrei!
In altri termini sarebbe il caso di valutare se un sistema distribuito che preveda la realizzazione di un unico data center in una zona scelta con tutti i crismi del caso affiancato da una cospicua quantità di “punti di storage” (una per provincia?) nei quali replicare più e più volte i dati sia più confacente al caso italiano. Caso italiano, ricordo, caratterizzato tradizionalmente da un policentrismo spinto e da più centri di produzione e sedimentazione documentaria. Motivo ulteriore per verificare la fattibilità della soluzione.

Capacità di storage come asset centrale della biblioteca del futuro?

Vatican Library, Rome di bharat.rao, su Flickr

Vatican Library, Rome

In un mio post di qualche tempo fa mi soffermavo sulla crescente importanza, per i moderni archivi digitali, che va assumendo l’infrastruttura tecnologica.
Ovviamente da questo trend non sono immuni nemmeno le biblioteche e la riprova la si ha leggendo la notizia, diffusa pochi giorni fa, della partnership instaurata tra EMC, colosso statunitense con quasi quarant’anni di esperienza alle spalle nei sistemi di storage ed archiviazione, e la Biblioteca Apostolica Vaticana: in estrema sintesi EMC, all’interno di un più vasto programma che unisce saggiamente filantropia a marketing, si impegna a fornire le risorse di storage necessarie ad immagazzinare l’intero patrimonio di libri manoscritti, incunaboli e cinquecentine che ci si appresta, in un arco di tempo stimato in tre anni, a digitalizzare.
Se ad impressionare è l’enorme spazio di memorizzazione messo a disposizione, ovvero 2,8 petabyte (equivalenti a 2.936.012,800 gigabyte; per rendere l’idea tale cifra la si raggiunge unendo 587.202 computer con disco rigido da 500 GB), non meno importanti sono le riflessioni che si possono ricavare da questa vicenda.
Innanzitutto appare evidente come una simile infrastruttura abbia dei costi particolarmente elevati (peccato che nulla venga detto a proposito e che non sia nemmeno possibile fare ipotesi, non essendo noto il tipo di memoria adottato) ed anzi probabilmente fuori dalla portata della maggior parte delle biblioteche al mondo.
Ma quel che più conta è il ruolo strategico assunto dall’infrastruttura di storage: essa infatti funge da ponte imprescindibile tra passato, cioè i libri “analogici” posseduti, e futuro, ovvero la loro copia digitalizzata, la quale consentirà a) di “risparmiare” ai primi tutti quegli stress meccanici derivanti dall’uso nonché l’esposizione a fattori ambientali quali luce, (sbalzi di) umidità e temperatura, etc. b) di far godere, nel presente, questi capolavori ad una platea di pubblico potenzialmente molto più vasta rispetto a quella degli studiosi che solitamente ha la fortuna di consultarli.
Sarebbe stato bello, per concludere, sapere qualche dettaglio tecnico-operativo in più, ad esempio se chi si occuperà della gestione del sistema di storage (verosimilmente tecnici EMC) sarà sotto la sovrintendenza del Prefetto della Biblioteca Vaticana, monsignor Pasini o, in alternativa, quale tipo di controlli verranno messi in atto per assicurarsi che il sistema risponda a tutti i requisiti in termini di sicurezza ed operatività.
Non meno interessante sarebbe sapere dove effettivamente è localizzato il data center (e se esiste un sito secondario) così come se si fa ricorso al modello del cloud computing
Tante domande che non fanno che rafforzare la mia convinzione che le capacità di storage siano un asset strategico per le biblioteche.

Samsung Galaxy Camera ed i nuovi archivi fotografici

Samsung Galaxy Camera

Samsung Galaxy Camera

L’arrivo sugli scaffali dei principali negozi di informatica italiani della Samsung Galaxy Camera mi offre l’occasione per una veloce riflessione sullo stato degli archivi fotografici in questo cruciale momento di trapasso al digitale.
Prima però è opportuno presentare la nuova fotocamera digitale prodotta dallo chaebol sudcoreano dal momento che essa segna probabilmente un punto di rottura rispetto alle “macchinette fotografiche”, reflex o compatte che siano, sin qui realizzate. La Galaxy Camera infatti affianca ad un’ottica di tutto rispetto un altrettanto ricco lato software: attraverso lo schermo touch da 4,8 pollici è possibile interagire con il sistema operativo Android 4.1 Jelly Bean, ergo con tutte le applicazioni esistenti in questo ricchissimo ecosistema sia per il ritocco delle immagini stesse (cito qui il solo Instagram esclusivamente perché quello tra i più in voga del momento) sia per la loro immediata condivisione attraverso le proprie reti sociali. E quest’ultimo aspetto ci introduce alla vera novità della Galaxy Camera, vale a dire la presenza di connettività Wi-Fi e 3G la quale, si badi, ha un’utilità non solo, per così dire, “ludica” ma ne ha una molto più eminentemente pratica; a riprova del fatto che questa nuova fotocamera è fatta per restare sempre connessa (entrando a far parte a pieno titolo dell’Internet delle cose di cui tanto si parla), buona parte della memoria è allocata sulla cloud. A fronte di una memoria interna da 8 Giga (espandibile a 32 con scheda MicroSD / MicroSDHC) Samsung, che ha stretto un apposito accordo con Dropbox, ne mette a disposizione gratuitamente ben 50 sulla nuvola!
Il salto in avanti a mio modesto parere è netto e spiace che i puristi della fotografia abbiano perso di vista le novità di fondo fermandosi invece a rimarcare come, numeri alla mano, con i 549 euro necessari per aggiudicarsela si può comprare una reflex dalle caratteristiche tecniche (per quanto riguarda la sola ottica) decisamente superiori ed in definitiva bollando la Galaxy Camera come un costoso giocattolo che un “vero fotografo” mai si sognerebbe di usare.
Purtroppo mi pare che a costoro sfugga il non trascurabile dettaglio che oramai esiste un cospicuo numero di figure professionali (penso in special modo – ma non sono le uniche – a quelle legate al new journalism come blogger, live twitterer, storifyer senza dimenticare i più tradizionali giornalisti e fotoreporter free-lance!) che svolgono la loro attività attraverso l’uso di strumenti quali smartphone, tablet e per l’appunto foto/videocamere ai quali essi richiedono non tanto (o, per essere più precisi, non solo) le massime prestazioni possibili ma anche semplicità d’uso, affidabilità, poco ingombro… e naturalmente connettività.
Ma al di là dei risvolti di mercato la comparsa di device così concepiti ha naturalmente un impatto profondo sul modo in cui vengono a formarsi gli archivi fotografici digitali; cerchiamo di enucleare alcuni tra gli aspetti più rilevanti:
1) le foto digitali, prese come singularitas, divengono (paradossalmente) allo stesso tempo più instabili e “cangianti” rispetto alle parenti analogiche così come assai più “circostanziate” e ricche di informazioni. Alcuni semplici esempi presi dall’esperienza quotidiana rendono meglio l’uno e l’altro aspetto: mentre nel mondo analogico, trovandoci in presenza di un negativo e di un positivo fissati rispettivamente alla carta fotografica ed alla pellicola del rullino, le possibilità di “ritocchini” erano limitate ed opera perlopiù di esperti oggigiorno potenzialmente chiunque, attraverso appositi programmi (che partono dal livello amatoriale, dove consistono nell’applicazione di qualche filtro, ed arrivano ai programmi professionali per veri esperti), può alterarle. A fronte di questa possibilità praticamente universale di alterare la foto “originale”, si constata l’aumento della mole di dati che la corredano contribuendo a collocarla spazialmente e temporalmente: oramai di ogni foto scattata possiamo sapere in automatico non solo l’ora / data dello scatto e quale macchinetta abbiamo utilizzato ma persino il luogo in cui l’abbiamo fatta (georeferenziazione; per la Galaxy Camera tale dato verosimilmente deriva dall’incrocio dei segnali forniti dal Wi-Fi e dalla connessione cellualre) e chi abbiamo immortalato (in questo caso l’operazione di tagging avviene ancora in modo manuale). Insomma, una miniera di dati che, per inciso, qualora venissero resi anonimi e raggruppati in dataset e descritti con linguaggio RDF diventerebbero sicuramente utilissimi nell’ottica di un riuso all’insegna dei big (open) data! Del tutto opposta, ma purtroppo parimenti possibile, l’evenienza che di essi si faccia un uso “spavaldo” con palesi violazioni della privacy
2) l’instabilità è un tratto che caratterizza le fotografie digitali anche quando prese nel loro complesso, ossia nel loro essere “archivio”: questi ultimi infatti stanno seguendo, di supporto in supporto (CD-ROM, DVD, hard-disk, drive a stato solido, etc.), la stessa peregrinazione toccata in sorte a tutti gli altri tipi di file digitali ed ora stanno chiaramente prendendo la via della Nuvola, che come risaputo anche dal punto di vista tecnologico non è sicuramente infallibile (come provato, da ultimo, dall’uragano Sandy) né si può dire che una foto digitale sia molto più stabile delle ostiche pellicole in nitrato di cellulosa e meno bisognosa, negli anni, di pazienti cure! Insomma, la preservazione degli oggetti digitali e soprattutto la loro conservazione nel lungo periodo rimane un’incognita.
3) non lascia trascorrere sonni tranquilli neppure l’altro grande punto debole del modello cloud, ovvero quello attinente alla sfera legale e a quello, accennato poco sopra, della tutela della privacy; anzi, considerando l’elevata (ed immediata) sfruttabilità delle immagini, i rischi paiono essere persino superiori rispetto a quelli incombenti su altre tipologie di oggetti digitali! Instagram ad esempio, è notizia di questi giorni, dopo essere stata acquistata a suon di miliardi da Facebook ha annunciato la modifica unilaterale dei Termini di Servizio facendo paventare la possibilità di vendere a terzi le foto presenti nella piattaforma (peraltro senza assicurare alcun “ristoro” a chi quella foto l’ha caricata!) inclusa la possibilità di usarle all’interno di campagne pubblicitarie. Come prevedibile la notizia ha scatenato un putiferio tra gli utenti di Instagram, molti dei quali hanno annunciato di passare ad altri servizi come Flickr (qui in molti casi si tratterebbe di un ritorno…), Photobucket, Pinterest, Snapchat ed altri. Tra gli scontenti, a testimonianza dell’importanza che assumono questi archivi fotografici, pure National Geographic (la qualità dei cui reportage fotografici è universalmente riconosciuta), che conta sul network la bellezza di 660mila follower. Ovviamente Instagram è corsa ai ripari, ritrattando su tutta la linea ma oramai il danno era fatto, tanto più che molti utenti erano già indispettiti dalla cessazione del supporto a Twitter (fatto che risale invece alla settimana scorsa…). Insomma, la posta in palio attorno agli archivi fotografici del futuro prossimo venturo è elevata, come comprovato dal fatto che Twitter stesso ha reagito alla mossa di Instagram avviando il proprio servizio di hosting fotografico, dopo essersi appoggiato a lungo al citato Photobucket; se aggiungiamo che pure Flickr ha (ri)lanciato il guanto di sfida, mettendo a disposizione degli utenti (contestualmente al rilascio della sua nuova applicazione mobile) vari tool per ritoccare / modificare le foto, appare manifesto come sia in corso un autentico big game e spiace che anche in questo caso non esistano alternative pubbliche (o, perlomeno, frutto della collaborazione pubblico – privato) per chi vuole archiviare in modo sicuro le proprie foto.
Pare dunque, per concludere, segnato il destino degli archivi fotografici digitali: complice la proliferazione sul mercato di dispositivi connessi alla Rete capaci di scattare immagini (con la Galaxy Camera a rappresentare il punto più alto di questa “evoluzione”) e la presenza di operatori valutati milioni di dollari che realizzano applicazioni sulla nuvola per utenti sempre connessi e per organizzazioni che parimenti orientano sempre più il loro marketing (e talvolta il loro intero business) sulle nuove tecnologie, la loro destinazione finale è l’impalpabile cloud. Con tutto ciò che ne consegue, nel bene e nel male.

Gli archivi sulla nuvola alla prova dell’uragano Sandy

A quanto pare è destino che gli uragani fungano da banco di prova per gli archivi digitali: nel 1995 l’uragano Marilyn colpì violentemente le Isole Vergini provocando vittime e danni ad edifici tanto pubblici quanto privati: sulla scorta di quell’evento il National Media Lab redasse delle linee guida (una sintesi in italiano la trovate all’interno del volume “Memorie digitali: rischi ed emergenze”, pubblicato dall’ICCU nel 2005) su come minimizzare i danni in simili casi.
Alcuni dei consigli forniti allora mantengono appieno la loro validità (in particolare quelli su dove collocare fisicamente i sistemi di archiviazione ed i sistemi ed i supporti informatici contenenti dati, ovvero in piani che non siano il primo e l’ultimo ed in locali non affacciantesi sull’esterno) ma molti altri appaiono anacronistici ed evidenziano quanta strada abbia fatto la tecnologia in questi tre lustri e, di riflesso, quanto la nostra vita dipenda in modo sempre più stringente da quest’ultima.
Un esempio su tutti: 15 anni fa il NML suggeriva di scollegare dalla rete elettrica tutte le apparecchiature elettroniche e di impacchettarle in apposite buste di plastica mentre oggi la lotta con l’uragano Sandy si è giocata tutta, al contrario, proprio sul riuscire ad evitare di finire offline! Del resto all’epoca l’ipotesi di “vivere senza Internet” ed i vari dispositivi tecnologici ad essa collegati per alcuni giorni non sollevava particolari problemi, a differenza di oggi dove la cosa sarebbe vissuta come una tragedia!
Non è dunque un caso se siti e blog nordamericani hanno fatto a gara a raccontare, praticamente minuto per minuto, quali e quanti data center (con relativi servizi) “andavano giù”; molti commentatori infatti hanno sottolineato come fosse, quella presente, una prova del nove della sostenibilità del modello del cloud computing (con annesso servizio di archiviazione) il quale ha come imprescindibile corollario l’essere always on.
Come spesso accade non c’è unanimità sul fatto che la prova sia stata superata o meno: come mostra l’analisi di Renesys (sintetizzata nel video qui sopra) in termini percentuali appena il 10% dei network dell’area di New York sono rimasti colpiti anche se, aggiunge poco sotto la stessa società, considerando la densità di reti è come se l’intera Austria si fosse bloccata, il che non è esattamente una cosa da niente!
Vittime di Sandy, del resto, sono stati anche servizi di primo piano come Gawker (che annovera tra i suoi siti pure il tecnologicissimo Gizmodo!) ed il celeberrimo Huffington Post, tutti “ospitati” nei server della newyorkese Datagram Inc. che, nel momento in cui scrivo, ha da poco terminato di svuotare i propri locali dall’acqua ed opera dunque ancora in regime di piena emergenza.
L’acqua infatti, oggi come per gli archivi cartacei dei secoli passati, si è rivelata ancora una volta essere la minaccia principale: evidentemente molti data center erano fisicamente collocati in locali non idonei (vuoi vedere che macchinari dal valore complessivo di centinaia di migliaia di dollari sono finiti negli scantinati?!) o comunque senza tener conto di possibili criticità idrauliche (l’agglomerato urbano di New York in definitiva sorge su più isole ed è attraversato da grossi fiumi come l’Hudson e l’East River).
Sono stati proprio gli allagamenti diffusi, una volta che la Conedison (la società energetica che serve New York; n.d.r.) ha interrotto l’erogazione di corrente, ad impedire ad un gran numero di generatori ausiliari di entrare in azione! Ma va tenuto presente che anche nei casi in cui i generatori sono correttamente entrati in funzione si è palesata la limitatezza dell’autonomia vuoi perché le scorte non erano sufficienti (le 48 – 72 ore di norma previste sono risultate troppo poche per un’emergenza di questa portata) vuoi perché gli stessi serbatoi erano finiti in ammollo. Questo ha costretto molti tecnici ad un’affannosa ricerca per la città di pompe di benzina per sopperire alla carenza del prezioso carburante! Su “The Verge” Adrianne Jeffries ha spiegato con dovizia di particolari un’emergenza tipo, con i tecnici sistemisti che, una volta riempite le taniche, hanno dovuto travasare a mano il loro contenuto nei serbatoi dei generatori operando in ambienti invasi da un misto di acqua, carburante e rifiuti.
Un’altra criticità chiaramente emersa, e che deve far profondamente riflettere, riguarda poi la collocazione geografica dei centri secondari di back-up e ripristino: è evidente che se i succitati servizi sono andati giù ciò è dipeso dal fatto che non solo i siti primari ma anche quelli secondari hanno fatto cilecca. Difatti è emerso che molti di questi siti secondari si trovano nel vicino New Jersey (vicino in senso relativo; è più o meno come se un’azienda di Milano avesse il suo sito secondario nei pressi di Bologna…), investito anch’esso dalla furia di Sandy.
Ovviamente non tutto è filato storto, anzi, prendendo per buona e rigirando la statistica citata all’inizio si può a buon diritto affermare che nel 90% dei casi le procedure ed i sistemi d’emergenza hanno funzionato a dovere (qui alcuni esempi). Pertanto mi sembra si possa tranquillamente affermare che complessivamente il “modello cloud computing” abbia retto all’urto e che anzi esso, se sarà capace di metabolizzare le lessons learned ovvero:
1) porre serbatoi, generatori e sale macchine in zone al riparo dagli allagamenti,
2) costruire i centri secondari di ripristino a debita distanza dal primario, sacrificando magari qualche frazione di secondo in fatto di tempi di latenza,
potrà, almeno dal punto di vista tecnologico, divenire davvero un modello altamente affidabile tale da assicurare un elevato grado di sopravvivenza ai nostri archivi digitali sulla nuvola.
Certo, resta il problema di fondo della dipendenza assoluta dall’energia elettrica, ma questo è un limite generale della nostra società e personalmente non vedo soluzioni soddisfacenti all’orizzonte (la diversificazione, magari puntando sulle rinnovabili, al momento non è che un palliativo) e pertanto lo lascerei fuori dal dibattito fin qui fatto.
Va infine sottolineata l’eccezionalità, relativamente alle aree geografiche interessate, del fenomeno meteorologico in oggetto ed anzi c’è da domandarsi (ma qui mi rendo perfettamente conto che entriamo nel campo della pura speculazione): quanti archivi, digitali ed analogici, sarebbero sopravvissuti se un’emergenza simile si fosse verificata in Italia?

Con Glacier anche gli archivi storici vanno sulla nuvola

Inside the library

Inside the library di muegyver, su Flickr


LA NOTIZIA

Non sarà passato inosservato ai più l’annuncio, dato da Amazon qualche settimana fa, del lancio di Glacier, servizio di archiviazione sulla nuvola appositamente pensato per quei dati / documenti digitali oramai “vecchi” e poco utilizzati ma dei quali per svariati motivi (prescrizione legislativa, ragioni di opportunità e convenienza, etc.) è prevista la conservazione nel lungo periodo.
Come spiegato in un post di Werner Vogels, CTO di Amazon, il servizio si rivolge ad un pubblico eterogeneo: si spazia dalle grandi aziende alle PMI, passando naturalmente per le giovani e dinamiche start up, senza ovviamente dimenticare gli enti di ricerca, i governi, le aziende sanitarie, le media company, le biblioteche, etc.
A tutti costoro Amazon propone di sottoscrivere un contratto sicuramente aggressivo ed “accattivante”: appena 0,01 dollari per Gigabyte al mese (0,011 qualora come data center di riferimento si scelga quello irlandese) purché non si “movimenti” più del 5% di quanto caricato o non lo si cancelli entro 90 giorni dall’upload; in tale evenienza Amazon applica una tariffa che parte da 0,011 GB nel primo caso e fissa di 0,033 nel secondo (per ulteriori dettagli sul piano tariffario rimando a questa pagina). L’intento è chiaro, ovvero disincentivare gli utenti a fare un uso “improprio” di Glacier che, per l’appunto, è dedicato all’archiviazione (caratterizzata da un relativamente minor numero di operazioni di recupero) e non allo storage di breve respiro; a fungere da ulteriore deterrente a comportamenti “da furbetti”, oltre alla tariffazione, è il tempo stesso impiegato per l’operazione di estrazione dei dati / documenti richiesti, mediamente quantificato in 5 ore!

LE REAZIONI

Dal momento che la stessa Amazon, in linea con tutte le “novità” che gravitano attorno al cloud computing, ha impostato la sua proposta puntando sull’elemento cost-effectiveness, non deve sorprendere che il dibattito sui siti e blog specializzati si sia sviluppato con l’obiettivo preciso di confutare o meno la convenienza del nuovo servizio omettendo quasi del tutto di chiedersi se esso, al di là della dimensione economica, risponda realmente alle esigenze di archiviazione: è banale sottolinearlo ma gli eventuali risparmi ottenibili da soli non giustificano il passaggio ad un diverso sistema di archiviazione, soprattutto qualora quest’ultimo non sia archivisticamente valido almeno quanto quello che si abbandona! Ciò nondimeno, anche alla luce delle perduranti ristrettezze economiche, credo sia utile sintetizzare le posizioni dei due schieramenti, rimandando ai paragrafi successivi per una trattazione più dettagliata delle caratteristiche squisitamente archivistiche di Glacier e delle problematiche sollevate.
I detrattori del nuovo servizio di Amazon si sono sforzati, conti alla mano, di dimostrare come esso non sia competitivo rispetto alle librerie di nastri che vorrebbe pensionare dal momento che costa circa 10 volte tanto (soprattutto in presenza di archivi di notevoli dimensioni; siamo sull’ordine delle decine di Petabyte, n.d.r.). Se da Amazon si sono affrettati a rispondere che per vedere i risparmi bisogna (giustamente a mio avviso, dal momento che stiamo parlando di archiviazione nel lungo periodo) fare proiezioni di spesa che vadano oltre i 5 anni, altri analisti hanno rilevato come i sostenitori delle tape library abbiano omesso di mettere in conto alcune voci di spesa non esattamente irrilevanti, come quelle derivanti dalla necessità di allestire un sito secondario di ripristino oppure ancora una buona quota di quelle di manutenzione e di gestione (e come ben sintetizza Enrico Signoretti, quel che conta è il TCO e non il TCA, vale a dire il costo totale di possesso e non quello di acquisto!); morale della favola, aggiungendo queste ulteriori voci di spesa le soluzioni finiscono per l’equivalersi ma con il vantaggio innegabile, per coloro che si affidano a Glacier, di venir “affrancati” da ogni incombenza diretta sulla materia e soprattutto con la certezza di non venire mai a trovarsi nella poco invidiabile situazione di essere dotati di infrastrutture vuoi sottodimensionate vuoi sovradimensionate (origine nel primo caso di sprechi e di inefficienze, nel secondo di onerosi upgrade); con Glacier, così come con tutti gli altri servizi ispirati al modello del cloud computing, si paga infatti solo in base all’effettivo consumo (pay-as-you-go) con la possibilità di scalare verso l’alto o verso il basso a seconda delle esigenze.

OSSERVAZIONI DI NATURA TECNICA

Come accennato poc’anzi uno dei tratti salienti di Glacier è l’abbandono del nastro magnetico come supporto principe (e low cost!) per l’archiviazione di massa di lunga durata; sollecitata a dare delucidazioni sulle soluzioni tecnologiche adottate, Amazon ha confermato attraverso un portavoce che “essentially you can see [Glacier] as a replacement for tape” che gira su “inexpensive commodity hardware components” (verosimilmente, chiosa l’autore dell’articolo, si tratta di un “very large storage arrays consisting of a multitude of high-capacity low-cost discs”).
Si tratta di una informazione di non poco conto dal momento che si abbandonano i nastri, con la loro lenta memoria ad accesso sequenziale (in sostanza per accedere ad un determinato dato occorre percorrere tutto il nastro a partire dall’ultimo punto cui si era acceduti), in luogo delle più performanti memorie ad accesso diretto: peccato che ciò sia vanificato dai lunghi tempi di latenza (circa 5 ore) entro i quali Amazon garantisce il recupero. Insomma, un servizio low cost ma anche very slow!
Per il resto viene ovviamente posto l’accento sulla ridondanza delle copie: ogni dato viene archiviato in più strutture ed in più dispositivi all’interno della singola struttura, al punto che si garantisce, come anzidetto, la durabilità annuale del 99.999999999% con periodiche, rigorose operazioni di verifica dell’integrità dei dati medesimi.

OSSERVAZIONI DI NATURA ARCHIVISTICA

Dal punto di vista archivistico con Glacier viene fino ad un certo punto ricostituita sulla nuvola l’unitarietà fisica e logica dell’archivio: giusto per restare in casa Amazon se su Amazon Web Services (AWS) va la parte corrente su Glacier va quella storica con la prospettiva, come ricordato da Vogels nel post citato, che in un prossimo futuro le due parti possano dialogare pienamente con il trasferimento dall’una una all’altra.
Ma oltre a questa premessa di cappello ci sono altre considerazioni archivistiche da fare; vediamo in modo un po’ più articolato:
1) poche righe sopra scrivevo che viene a ricrearsi l’unità dell’archivio “fino ad un certo punto”: questa precisazione perché non esiste ad oggi una soluzione intermedia per la fase di deposito né è dato sapersi se mai esisterà! Oramai infatti il cambiamento di status tra le varie fasi, al di là di alcuni aspetti giuridici (ad esempio il passaggio di responsabilità dai responsabili dei vari uffici a quello della conservazione), si risolve dal punto di vista “fisico” nell’allocazione dei dati / documenti in device sempre più omogenei e che differiscono, come ben esemplificano i prodotti di Amazon, “solo” per diverse scelte architetturali e per il livello di prestazioni
2) le cinque ore di tempo di latenza entro il quale Amazon assicura il recupero dei dati e la possibilità di effettuarne il download sono oggettivamente troppi: per anni si è scritto che l’avvento del digitale avrebbe garantito una fruizione universale ed istantanea degli archivi storici, favorendone nel contempo la valorizzazione, ed ora ci si dovrebbe accontentare di un tempo di recupero mediamente assai superiore rispetto a quello occorrente in un Archivio di Stato per vedersi consegnata la busta (cartacea) richiesta?!
Mi si potrà obiettare che non necessariamente i dati / documenti devono essere accessibili al pubblico ed inoltre che, in linea con l’Hyerarchical Storage Management (HSM), è sempre possibile allocare quei dati / documenti “di valore” negli storage device più prestanti, ma ciò vuol dire non tener conto di quanto ultimamente si va dicendo in fatto di big data =>
3) riguardo a quest’argomento assai in voga io stesso in un post di qualche mese fa ho evidenziato come, alla luce degli usi e riusi inaspettati che si fanno (e si faranno sempre più) degli open (linked) data, il relativo life-cycle stia mutando: meno picchi ma al contrario un uso più costante e prolungato nel tempo e soprattutto con numeri di istanze mediamente più elevati. In buona sostanza, considerando che Amazon stessa indica tra i vari scenari applicativi quello degli open data (i quali praticamente per definizione non si sa se, come, quando e da chi verranno utilizzati), non è sensato far aspettare un eventuale ricercatore per ore ed ore! Questo aspetto ci introduce al punto seguente =>
4) il mutato ed imprevedibile data life-cycle dei giorni nostri, al contrario di quello “scontato” che l’ha preceduto (caratterizzato da alto uso durante la fase attiva e poi istanze man mano decrescenti nella fase passiva), rende ovviamente più difficile l’individuazione, che giocoforza deve essere effettuata a priori, di quali dati caricare e conseguentemente delle soluzioni di archiviazione più idonee. Del resto questo problema rimanda a quello più amplio della discrezionalità (in assenza di strumenti avvicinabili al massimario di selezione e scarto), circa cosa caricare e ai conseguenti rischi di rottura del vincolo archivistico
5) critici pure alcuni aspetti denunciati da Andrea Rota (che ha avuto modo di provare Glacier) sul suo blog personale: a prescindere dal fatto che le “operazioni di upload e download possono essere effettuate solo tramite la programmazione delle API di Amazon” (quindi in modo non immediato), Rota sottolinea che “come già avviene per altri servizi di storage di Amazon, i file caricati perdono il loro nome originale, che viene sostituito con una lunga stringa alfanumerica”, motivo per cui “se si vuole tracciare l’associazione fra nome e stringa identificativa, ad esempio per ricercare i file per nome, è necessario mantenere un indice esterno a Glacier oppure usare i metadati associati agli archivi”. Pare dunque di capire che, in assenza di adeguate cautele, vi sia l’elevato pericolo di perdita dei legami esistenti tra i vari dati / documenti.

OSSERVAZIONI DI NATURA LEGALE

Non meno importanti gli aspetti di natura legale sulla valutazione complessiva del servizio: valgono infatti in toto le considerazioni fatte a suo tempo per i servizi di storage sulla nuvola. Non a caso l’uso di Glacier è soggetto al medesimo contratto che regolamenta Amazon Web Services (si veda a riguardo AWS Customer Agreement) ed in particolare, tra le tante, vige la seguente condizione (punto 11; i grassetti sono miei, n.d.r.):

WE AND OUR AFFILIATES OR LICENSORS WILL NOT BE LIABLE TO YOU FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES […], EVEN IF A PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. FURTHER, NEITHER WE NOR ANY OF OUR AFFILIATES OR LICENSORS WILL BE RESPONSIBLE FOR ANY COMPENSATION, REIMBURSEMENT, OR DAMAGES ARISING IN CONNECTION WITH: (A) YOUR INABILITY TO USE THE SERVICES, INCLUDING […] (II) OUR DISCONTINUATION OF ANY OR ALL OF THE SERVICE OFFERINGS, OR, (III) WITHOUT LIMITING ANY OBLIGATIONS UNDER THE SLAS, ANY UNANTICIPATED OR UNSCHEDULED DOWNTIME OF ALL OR A PORTION OF THE SERVICES FOR ANY REASON, INCLUDING AS A RESULT OF POWER OUTAGES, SYSTEM FAILURES OR OTHER INTERRUPTIONS; […] (D) ANY UNAUTHORIZED ACCESS TO, ALTERATION OF, OR THE DELETION, DESTRUCTION, DAMAGE, LOSS OR FAILURE TO STORE ANY OF YOUR CONTENT OR OTHER DATA. IN ANY CASE, OUR AND OUR AFFILIATES’ AND LICENSORS’ AGGREGATE LIABILITY UNDER THIS AGREEMENT WILL BE LIMITED TO THE AMOUNT YOU ACTUALLY PAY US UNDER THIS AGREEMENT FOR THE SERVICE THAT GAVE RISE TO THE CLAIM DURING THE 12 MONTHS PRECEDING THE CLAIM

Condizioni, si intende, che definire sbilanciate è un eufemismo e che peraltro stridono con le numerose rassicurazioni date in ordine all’affidabilità tecnica (si veda il 99.999999999% di durabilità media annuale): non ha senso da un lato promettere mari e monti e dall’altra declinare praticamente ogni responsabilità impegnandosi a risarcimenti spesso irrisori!

CONCLUSIONI

Tirando le somme, Glacier è sicuramente interessante in quanto costituisce il primo esempio di servizio sulla nuvola pensato per la conservazione permanente di dati e documenti digitali, questi ultimi in prospettiva “raccordati” pure con la parte corrente; è questa probabilmente l’unica nota positiva assieme al pricing aggressivo (che indubbiamente costituisce un ottimo biglietto da visita) giacché è bastata la veloce analisi alla quale ho sottoposto il nuovo servizio made in Seattle per evidenziare come esso patisca le consuete “tare”: discrezionalità su cosa caricare con conseguente rischio di rottura del vincolo, assenza di metadati (la cui presenza dipende dalla buona volontà di chi carica i dati), termini legali insoddisfacenti, cui si aggiungono un tempo di latenza imbarazzante e la vexata quaestio se sia o no un vantaggio affidare a terzi la gestione dei propri archivi digitali (o più correttamente delle infrastrutture sulle quali questi risiedono). Come saprete ritengo che almeno le istituzioni pubbliche dovrebbero farsi carico di queste incombenze ma a vedere il trend sono in minoranza…

Tra metacloud e personal cloud passa il destino degli archivi di persona digitali?

Zero PC Cloud - Storage Analyzer

Zero PC Cloud – Storage Analyzer

Di metacloud me ne sono già occupato in questo blog ed in particolare con l’occasione avevo descritto il funzionamento di Zero PC; ritorno oggi sull’argomento non solo perché di recente quest’azienda ha rilasciato la nuova versione del suo servizio web-based (rammento che non ho alcun tornaconto a spingere per questo o quel servizio) ma soprattutto perché le linee di sviluppo seguite sembrano paradossalmente confermare le altrettanto recenti previsioni di Gartner circa l’inarrestabile ascesa dello storage sulla nuvola in special modo da parte di privati.
Quali sono dunque, per iniziare, le novità introdotte da Zero PC? Oltre ad una grafica più pulita ed intuitiva, la nuova release si caratterizza innanzitutto per l’accresciuto numero di servizi terzi che si possono gestire: in particolare ci sono, eccezion fatta per iCloud, tutti i principali provider di cloud storage come Box, Dropbox, Drive, Skydrive, etc. al punto che solo ad essere membri free di questi servizi si raggiunge il ragguardevole valore di 40 GB di spazio disponibile (per vedere in dettaglio quanto ce ne rimane di residuo sui vari servizi c’è l’utilissimo Storage Analyzer all’interno del Cloud Dashboard). Ma Zero PC non è mero un gestore di spazi di “archiviazione” e di backup, anzi la nuova versione dimostra appieno la volontà di andare oltre a questo ruolo: a fianco dell’Universal Inbox (che gestisce tutta la messaggistica, quindi non solo email ma anche tweet), hanno fatto la loro comparsa il browser di navigazione interno, il player in HTML 5 e soprattutto la suite di produttività online ThinkFree che permette di creare documenti in formato .doc, fogli di calcolo Excel e presentazioni in Power Point.
Ne risulta, per l’utente, la sensazione di trovarsi in un unico spazio di lavoro e di archiviazione, connotato da condivisione spinta ed elevata versatilità.
E qui il ragionamento si salda con le previsioni di Gartner (spesso tutt’altro che infallibili ma che nello specifico caso ritengo verosimili) alle quali avevo fatto cenno all’inizio: secondo questa importante società di analisi e di ricerca nel 2016 gli utenti / consumatori caricheranno nella nuvola circa il 36% dei propri contenuti digitali (essenzialmente foto e video; a far da volano al fenomeno è infatti la diffusione di device, come i tablet e gli smartphone, con foto/videocamera integrata) mentre la percentuale di contenuti archiviati on premise scenderà dall’attuale 93 al 64%. Anche quando effettuata in locale non si tratterà più comunque di un’archiviazione “statica”: soluzioni di personal cloud capaci di integrarsi in primo luogo con la propria rete domestica ed in seconda battuta con quelle di altri utenti diventeranno la norma.
Questo mix di storage remoto e locale sarà inevitabile anche in vista della crescita esponenziale dei dati posseduti: sempre secondo Gartner ciascun nucleo familiare passerà dagli attuali 464 GB ai 3,3 TB del 2016. L’uso massiccio e quotidiano che verrà fatto delle diverse tipologie di storage condurrà alla loro trasformazione in commodity: per l’utente finale, in poche parole, un servizio varrà l’altro il che non è esattamente il massimo del desiderabile per le aziende che vi basano il proprio business (di qui l’invito di Gartner, rivolto a queste ultime, a ripensare strategicamente il proprio approccio)!
In effetti già ora con i servizi di metacloud, di cui Zero PC è esempio lampante, tutto tende a confondersi nella mai così nebulosa cloud, al punto che non fa apparentemente differenza che un file risieda su Dropbox anziché su Skydrive (tanto Zero PC mi ritrova tutto e posso spostare lo stesso file da una parte all’altra con la massima facilità!): in realtà le condizioni contrattuali, le soluzioni tecnologiche adottate, la qualità del servizio, etc. che sono alle spalle dei diversi servizi possono differire anche sensibilmente! Ma di ciò l’utente medio non è consapevole oppure non vi attribuisce la dovuta importanza.
In altre parole temo che nel prossimo futuro tutto (da una parte i servizi di metacloud che ti invitano a caricare sulla nuvola tanto ci pensano loro a gestire il tutto, dall’altra l’archiviazione in locale che si fa commodity) concorrerà ad aumentare la “disinvoltura” con la quale gli individui “gestiranno” i propri archivi digitali di persona, con le immaginabili conseguenze in termini di potenziale perdita dei dati, di (mancata) tutela della privacy, di (non) oculata gestione della propria identità digitale, etc. Insomma, prospettive non esattamente incoraggianti!
Concludo però facendo notare come il tipo di tecnologia è sì importante ma non decisivo: dati e documenti sono andati definitivamente persi per noncuranza o semplice ignoranza (ed in alcuni casi per deliberata volontà!) in ogni epoca e a prescindere dalla tipologia di supporti adottati. Come ricordato in altri post il problema che ora si pone in ambiente digitale è che serve una chiara e duratura volontà di mantenere “vivi”, conservandoli nel tempo, i vari oggetti digitali che andiamo creando in maniera esponenziale nel corso della nostra esistenza. Questa volontà, a sua volta, non può prescindere dalla presenza, nel soggetto produttore (il singolo individuo, nel caso specifico) di una particolare sensibilità per queste tematiche e soprattutto la consapevolezza che dei fatti, degli avvenimenti, delle cose teniamo memoria non solo perché è un obbligo di legge o perché ne abbiamo materialisticamente l’interesse ma soprattutto perché la memoria è un valore. Temo purtroppo che i nostri tempi non siano i migliori per un simile scatto culturale.

La natura infrastrutturale degli archivi contemporanei

IMG_20110415_151845 di GrigorPDX, su Flickr

Left: air filters - they look like plain old disposable filters you'd have in your furnace. Right top: louvers leading to outside air Right bottom: louvers leading to the "hot" side of the data center racks.
(Foto di GrigorPDX, su Flickr)


INTRODUZIONE.

In un celebre quanto datato articolo Robert-Henry Bautier, insigne archivista e medievista francese, proponeva una interessante periodizzazione circa la storia degli archivi; in particolare egli individuava quattro fasi, la terza delle quali veniva definita come “celle des archives arsenal de l’authorithé” e che sarebbe stata caratterizzata dalla concentrazione dei fondi all’interno di edifici realizzati ad hoc che erano in tutto e per tutto castelli, vale a dire muniti di fossati, mura e torrioni difensivi in pietra (da manuale i casi del castello di Simancas in Spagna oppure quello di Castel Sant’Angelo nello Stato Pontificio). Dietro a simili realizzazioni stava una concezione che attribuiva ai documenti un’importanza decisiva per il regolare andamento della macchina amministrativa, l’attestazione dei diritti e delle prerogative regie così come per l’attuazione della politica estera (per riprendere Bautier gli archivisti, e gli archivi, “se font auxiliaires de la politique e de la diplomatie“) motivo per cui la dimensione del corretto ordinamento delle carte procedeva di pari passo con quella della loro “sicura custodia”. Insomma, il ricorso a questa terminologia “militaresca” da parte di Bautier non era dettato da semplici motivazioni retoriche ma dalla constatazione di una realtà oggettiva: così come l’arsenale è una struttura deputata alla costruzione, alla riparazione, all’immagazzinamento ed alla fornitura di armi e munizioni, similmente l’archivio era il luogo in cui trovavano riparo quei documenti che sarebbero stati usati alla stregua di armi nel corso delle bella diplomatica del XVII secolo.

I DATA CENTER, ARSENALI DEL XXI SECOLO.

Con le debite differenze, sulle quali torno poco sotto, mi sembra che gli odierni “arsenali archivistici” siano rappresentati dagli enormi data center che si vanno costruendo in giro per il mondo; il paragone appare calzante in quanto 1) in essi si vanno concentrando le “memorie digitali” relative a milioni e milioni di persone, enti ed aziende 2) nella loro realizzazione vengono adottate precauzioni ed accorgimenti del tutto affini a quelle delle basi militari. Basta dare una scorsa alle misure di sicurezza messe in campo da Amazon per capire come l’accostamento con la realtà militare sia tutt’altro che campato per aria:

Amazon has many years of experience in designing, constructing, and operating large-scale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities, and critical facilities have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

Amazon only provides data center access and information to employees who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical and electronic access to data centers by Amazon employees is logged and audited routinely.

Fin qui le affinità; venendo alle differenze, ve ne sono due di macroscopiche: 1) gli archivi residenti nei data center, per quanto militarizzati, almeno in linea di principio non sono concepiti per essere al servizio di un qualche potere vessatorio ma bensì sono la base per offrire “servizi” e/o custodire dati, documenti, etc. di cittadini liberi, di aziende operanti nel libero mercato e di istituzioni democratiche 2) diversamente dai secoli passati, lo Stato sembra latitare ed i principali data center sono di proprietà di colossi ben noti al grande pubblico come Amazon, Apple, Google, Facebook ma anche di provider / fornitori come Carpathia, Cogent, OVH, Rackspace, Digital Realty; operatori che ovviamente poi sono ben lieti di offrire i propri “servizi” ai vari enti pubblici! Ad esempio sia Amazon che Carpathia hanno sviluppato apposite soluzioni per il Governo Federale degli Stati Uniti, il quale attinge largamente in modalità cloud computing a questo tipo di servizi (cliccate qui per una lista parziale); in Europa invece, essendo la legislazione comunitaria relativa al trasferimento transfrontaliero dei dati decisamente più restrittiva, si è molto più cauti nell’affidarsi a privati.
Ciò nonostante, ragionando in prospettiva, è verosimile ipotizzare che nell’Unione Europea o si allenteranno le citate restrizioni al trasferimento dei dati (a riguardo si sta delineando una spaccatura tra stati nordici, non disponibili ad un simile passo, e stati mediterranei, più possibilisti), dando dunque la possibilità di avvalersi dei servizi offerti da privati, oppure si procederà alla realizzazione di data center europei in territorio europeo. Personalmente ritengo la seconda opzione come la più lungimirante per i seguenti motivi: 1) il possedere dei data center è, dal punto di vista archivistico, premessa necessaria (ma non sufficiente) per attuare le indispensabili procedure tese a garantire la continuità operativa ed il disaster recovery (il che consente in primis di salvaguardare la parte “corrente”, vale a dire quei dati e documenti contenuti nei server ed indispensabili per il proseguimento dell’attività “istituzionale” del produttore, ed in ultima analisi di garantire la conservazione nel lungo periodo; ovviamente anche un privato può attuare questi piani ma quando si tratta della cosa pubblica e, soprattutto, sono in ballo aspetti così delicati, sono dell’avviso che la P.A. debba occuparsene direttamente) 2) assicura indipendenza ed in un ultima analisi “libertà”. Il rovescio della medaglia, evidente, è che ci si deve fare carico di tutti i costi: realizzativi, di gestione e di manutenzione.

DATA CENTER: MODELLI REALIZZATIVI, ASPETTI TECNICI…

La maggior parte dei moderni data center non è costituita da pochi supercomputer o pochissimi mainframe, bensì dall’unione all’interno di un medesimo spazio fisico di migliaia di elaboratori di fascia medio – bassa. E’ questo, tra i tanti, l’approccio di Google che significativamente lo definisce wharehouse computing e così lo descrive:

The hardware for such a platform consists of thousands of individual computing nodes with their corresponding networking and storage subsystems, power distribution and conditioning equipment and extensive cooling systems. The enclosure for these systems is in fact a building structure and often indistinguishable from a large warehouse

Tale definizione individua quelli che sono gli elementi principali di un data center ovvero “n” elaboratori, custoditi in una sorta di armadietto definito in gergo rack, a loro volta siti all’interno di un edificio e collegati tra di loro. Da ciò deriva che in un DC ricoprono un ruolo cruciale i seguenti sistemi:
1) UPS (Uninterruptible Power Supply; Gruppo di Continuità), il quale assolve a tre compiti fondamentali, ovvero a) garantire l’erogazione continua di energia elettrica alla struttura e, qualora dovesse verificarsi un’interruzione nella fornitura da parte della public utility, b) far intervenire la batteria fintantoché non interviene il generatore di emergenza, il tutto c) senza che si verifichino dannosi sbalzi di tensione
2) PDU (Power Distribution Units), ovvero il sistema di distribuzione dell’energia elettrica, distribuzione che avviene attraverso quadri e/o interruttori elettrici in genere “annegati” nel pavimento del data center
3) sistema di condizionamento; il metodo più diffuso vede la presenza di CRAC (Computer Room Air Conditioning), vale a dire di “stanze” dalle quali spira aria fredda che, scorrendo sotto il pavimento (tra il pavimento vero e proprio e quello che effettivamente si calpesta e sul quale sono collocati rack, CRAC, etc. può esserci sino ad un metro e mezzo di spazio vuoto; n.d.r.), esce attraverso delle specie di grate giusto in corrispondenza dei rack da raffreddare; l’aria calda uscita dai rack fluisce verso l’alto all’interno di un ulteriore spazio vuoto posto nel soffitto e di qui indirizzata verso il CRAC per riprendere il circolo. Nei DC più evoluti la gestione dei flussi d’aria è così raffinata che ad ogni singolo server perviene la necessaria aria di raffreddamento alla temperatura ottimale (una via alternativa è il cosiddetto in-rack cooling nel quale ogni “armadietto” è praticamente “cablato” da serpentine che fungono da scambiatori di calore; questa soluzione ovviamente ottimizza il raffreddamento ma è assai costosa dal momento che l’impianto di raffreddamento viene ad estendersi su tutta la superficie del centro dati oltre che relativamente più pericolosa giacché, in caso di rottura delle serpentine, il liquido di raffreddamento potrebbe finire sulla parte elettrica… evenienza assolutamente da scongiurare!).

Cabinet Airflow

Cabinet Airflow di talk2stu, su Flickr

Va ricordato, per finire, che per aumentare il livello di sicurezza spesso e volentieri i citati elementi sono ridondanti; così se in un data center Tier I vi è un’unico canale di raffreddamento e di distribuzione dell’energia in un Tier IV (il più elevato della scala) ve ne sono due di attivi oltre che ulteriori percorsi di emergenza. Non va ovviamente neppure dimenticato che fondamentale risulta essere la localizzazione geografica del data center: non dovrebbe trovarsi, ad esempio, in zone sismiche, in prossimità di corsi d’acqua ed in generale in aree soggette ad allagamenti o frane (“a rischio idro-geologico”) così come andrebbero evitate zone troppo fredde od al contrario troppo calde! Inoltre, sarebbe auspicabile che nella realizzazione dei DC europei si metabolizzasse l’approccio “green” di Gartner e, pertanto, si facesse ricorso a fonti di energia rinnovabile.

… E L’OBIETTIVO INDEROGABILE DELLA CONTINUITA’ OPERATIVA.

Castelli e fortezze, spesso progettati dai migliori architetti militari, erano in grado di resistere a lunghissimi attacchi ed assedi senza che si verificasse un sensibile degradamento della loro capacità bellica; similmente tutte le soluzioni tecnologiche descritte nella precedente sezione sono finalizzate a garantire la continuità operativa (business continuity), ossia il normale funzionamento dei servizi ICT utilizzati per lo svolgimento delle attività istituzionali, anche in presenza di disguidi tecnici, di “attacchi” o di altri eventi imprevisti. A fronte di avvenimenti che provocano l’indisponibilità prolungata del data center in cui normalmente si opera / al quale ci si appoggia (sito primario), viene attivato il piano di disaster recovery, il quale prevede l’attuazione di un mix di soluzioni tecnologiche ed organizzative tese a garantire la pronta ripresa dell’attività istituzionale in siti alternativi (detti secondari) rispetto a quelli primari/di produzione per il tempo necessario a rendere nuovamente operativo il sito primario.
Si tratta, manco a dirlo, di argomenti da tempo dibattuti in ambito internazionale ma che in Italia, dal punto di vista legislativo, solo di recente hanno finalmente trovato piena recezione; ad esempio le “Linee guida per il Disaster Recovery delle Pubbliche Amministrazioni”, redatte ai sensi dell’art. 50-bis, co. 3 del CAD (D. Lgs. 82/2005), hanno visto la luce solo nell’autunno 2011 ed imponevano che ogni ente presentasse entro il 25 aprile 2012 un Piano di Continuità Operativa (PCO) ed uno di Disaster recovery (PDR), individuando contestualmente una figura responsabile (RCO). Al di là del fatto che le varie amministrazioni abbiano ottemperato o meno nei tempi prescritti ai suddetti obblighi di legge, mi preme qui rilevare come l’input sia stato essenzialmente “archivistico”: nelle citate Linee Guida si trova infatti testualmente scritto che “il processo di dematerializzazione promosso dal CAD […] ha trasformato da ordinatoria a perentoria l’azione di eliminazione della carta, comporta[ndo] un incremento della criticità dei sistemi informatici che non possono più contare su un backup basato sulla documentazione cartacea”.
Da quanto innanzi detto derivano a cascata alcuni cambiamenti di una certa portata:
1) la continuità operativa ed in subordine il disaster recovery sono possibili a patto di individuare preliminarmente, accanto al sito primario, un sito secondario al quale trasferire come operazione di routine i dati / documenti prodotti dal primario; in caso di “problemi” il sito secondario diviene temporaneamente operativo fintantoché il primario non ritorna disponibile e pertanto deve disporre delle necessarie risorse hardware e software =>
2) nelle procedure di BC / DR diventa un fattore cruciale il trasferimento tra i due siti; le Linee Guida prevedono sei livelli (Tier 1 – 6) nei primi due dei quali il trasferimento consiste nel trasporto fisico (ad esempio a mezzo di apposito furgone) dal sito primario a quello secondario dei dischi ottici contenenti la copia di backup. E’ inutile sottolineare, però, come nell’epoca di Internet, grazie anche all’innalzamento delle velocità di upload / download ed ai migliori tempi di latenza, la Rete sia la soluzione più in voga e come il paradigma del cloud computing sia la soluzione sulla quale oggi si punta di più
3) dando per assodato che il trasferimento dei dati avvenga attraverso la Rete, va osservato che le operazioni di copia (Data Mirroring) finiscono per riguardare anche gli applicativi; le Linee Guida infatti lo definiscono “un processo con cui dati ritenuti critici vengono copiati secondo precise regole e politiche di backup al fine di garantire l’integrità, la custodia e la fruibilità degli archivi, dei dati e delle applicazioni e la possibilità di renderli utilizzabili, ove fosse necessario, procedendo al ripristino degli archivi, dei dati e delle applicazioni presso un sito alternativo a quello primario”. In particolare uno degli obiettivi principali è ottenere l’allineamento dei dati (ovvero il “coordinamento dei dati presenti in più archivi finalizzato alla verifica della corrispondenza delle informazioni in essi contenute”; per inciso l’allineamento, a seconda del Tier prescelto, può essere asincrono o sincrono) ed eventualmente il retroallineamento (ovvero “caricare” i dati prodotti nel sito secondario durante una fase di emergenza in quello primario in vista della ripresa dell’operatività di quest’ultimo) =>
4) dal punto di vista archivistico l’attuazione del Piano di Continuità Operativa significa il trasferimento costante di dati / documenti dal sito primario a quello secondario con questi ultimi che, nel caso di Tier 6, sono de facto speculari, motivo per cui (fatto salvo il caso di mancato allineamento), mi sembra si possa parlare della presenza di originali in duplice copia (per quanto poco senso possa avere la distinzione originale – copia in ambiente digitale). Inoltre è interessante osservare come, proprio perché parte integrante delle policy messe in atto, l’instabilità e l’ubiquità di dati e documenti sia, soprattutto nella fase corrente, più la regola che l’eccezione.
5) il legislatore ha chiaro come le operazioni di backup da un sito all’altro non equivalgono alla conservazione di lungo periodo per finalità storico – documentali; a proposito nelle Linee Guida ci si limita a ricordare come occorra raccordarsi al Manuale di conservazione e come il “salvataggio” debba avvenire su supporti adeguati. Sulla scorta di tali suggerimenti mi vien da ipotizzare due possibili soluzioni: a) all’interno della medesima coppia di data center vanno predisposti dei rack attrezzati con storage server di elevata qualità (diversamente dai rimanenti che, abbiamo visto, possono essere di livello medio – basso) nei quali destinare quei dati e documenti per i quali è prevista la conservazione permanente (la cosa è fattibile in quanto la “destinazione finale” è nota sin dal momento della creazione) b) che accanto alla coppia di data center deputati alla fase operativa / corrente ne venga costruita una ad hoc per quella di conservazione.
A prescindere da quale delle due opzioni prediligere (motivazioni di contenimento dei costi / ottenimento di economie di scala mi fanno propendere per la prima soluzione), va rimarcato come venga confermato che la migliore strategia conservativa sia quella di assicurare (potendolo provare attraverso audit, file di log, etc.), che la vita dei dati / documenti è sempre avvenuta all’interno di un sistema sicuro ed inviolato (e qui ritorniamo alle specifiche costruttive che devono possedere i data center) e che le procedure di copia sono avvenute senza errori.
6) Superfluo, da ultimo, sottolineare come gli aspetti tecnici non debbano mettere in secondo piano quelli organizzativi (come sempre deve venir coinvolta l’intera organizzazione!); mi preme solamente evidenziare come vada assolutamente individuata una catena di comando strutturata gerarchicamente secondo un modello che guarda caso rimanda nuovamente all’ambiente militare.

CONCLUSIONI.

Considerando la formazione prettamente umanistica della maggior parte degli archivisti (sottoscritto naturalmente incluso), comprendo come gli argomenti trattati in questo post appaiano oggettivamente ostici; eppure con tali tematiche occorre confrontarsi in quanto, è la mia convinzione, l’archivio del prossimo futuro coinciderà de facto con i moderni data center. Si tratta di un cambiamento di prospettiva di notevole portata per almeno i seguenti motivi: a) in primo luogo perché si torna a parlare di archivio nel suo complesso e non per questa o quella delle ripartizioni logiche – corrente, deposito, storico – nelle quali la teoria e la legislazione tradizionalmente l’hanno suddiviso b) in secondo luogo perché l’archivio diviene infrastruttura strategica e centrale per il “regolare svolgimento” della vita (digitale) di cittadini, aziende ed enti pubblici c) ultimo perché, della costruzione di tali data center / archivi “arsenali”, devono tornare a farsene carico gli Stati, meglio ancora se in chiave europea, l’unica che può garantire il necessario apporto finanziario nonché quell’ampiezza di spazi geografici tali da rendere la localizzazione dei DC veramente adeguata al raggiungimento dei dichiarati obiettivi di business continuity e di disaster recovery.

A chi volesse approfondire questo importante argomento consiglio di leggere la versione su Storify di questo post, ricca di documenti utili.

%d blogger hanno fatto clic su Mi Piace per questo: