Linux backup e recovery

8/3/2019 Linux backup e recovery

http://slidepdf.com/reader/full/linux-backup-e-recovery 1/6

DEV DEVeloping Software Solutions — n. 118 — maggio 2004

Linux backup e recoverydi Riccardo Corsanici

Backup e recovery costituiscono una delle problematiche di amministrazionepiu delicate e sottovalutate nella gestione di un sistema informativo

Riccardo Corsanici

Si occupa di consulenzasistemistica, integra-zione di sistemi e for-mazione professionale.Insieme ad altri profes-sionisti IT, ha fondatouna societa di serviziinformatici per la ge-stione di architettureinformative distribuitein ambienti critici.



pubblicato suWWW.INFOMEDIA.IT

stampa digitale da

Lulu Enterprises Inc.

stores.lulu.com / infomedia

Infomedia

media e l’impresa editoriale che da quasi venti an-

a raccolto la voce dei programmatori, dei sistemi-

dei professionisti, degli studenti, dei ricercatori e dei

essori d’informatica italiani.

o piu di 800 gli autori che hanno realizzato per le te-

Computer Programming, Dev, Login, Visual Basic

nal e Java Journal, molte migliaia di articoli tecnici,

entazioni di prodotti, tecnologie, protocolli, strumen-lavoro, tecniche di sviluppo e semplici trucchi e stra-

mmi. Oltre 6 milioni di copie distribuite, trentamila

ne stampate, fanno di questa impresa la piu grande ed

ente realta dell’editoria specializzata nel campo della

rammazione e della sistemistica.

tti questi anni le riviste Infomedia hanno vissuto del-

assione di quanti vedono nella programmazione non

la propria professione ma un’attivita vitale e un vero

rtimento.

2009, Infomedia e cambiata radicalmente adottando

uovo modello aziendale ed editoriale e si e organiz-

attorno ad una idea di Impresa Sociale di Comunita,

ecipata da programmatori e sistemisti, separando le

ita di gestione dell’informazione gestite da un board

unitario professionale e quelle di produzione gesti-

a una impresa strumentale. Questo assetto e in linea

le migliori esperienze internazionali e rende Infome-

ancora di piu parte della Comunita nazionale degli

uppatori di software.

media e media-partner di manifestazioni ed eventi in

ito informatico, collabora con molti dei pi u impor-

editori informatici italiani come partner editoriale e

itore di servizi di localizzazione in italiano di testi in

ua inglese.

aginazione automatica di questa rivista e realizzata al

% con strumenti Open Source usando OpenOffice,

cs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp,

hon e BASH

copyright information about the contents of DEV,se see the section “Copyright” at the end of each ar-

if exists, otherwise ask authors. Infomedia contents

2004 Infomedia and released as Creative Commons

BY-NC-ND. Turing Club content is © 2004 Turing

b released as Creative Commons 2.5 BY-ND.

nformazioni di copyright sul contenuto di DEV so-

iportate nella sezione “Copyright” alla fine di cia-

articolo o vanno richieste direttamente agli autori.

ntenuto Infomedia e© 2004 Infomedia e rilasciato

Licenza Creative Commons 2.5 BY-NC-ND. Il con-

to Turing Club e © 2004 Turing Club e rilasciato

Licenza Creative Commons 2.5 BY-ND. Si applicano

le norme di tutela dei marchi e dei segni distintivi.

ogni caso ammessa la riproduzione parziale o tota-

ei testi e delle immagini per scopo didattico purch´ e

gano integralmente citati gli autori e la completa

tificazione della testata.

oscritti e foto originali, anche se non pubblicati, non

stituiscono.

tenuto pubblicitario inferiore al 45%.

biografia dell’autore riportata nell’articolo e sul

www.infomedia.it e di norma quella disponibi-

nella stampa dell’articolo o aggiornata a cu-

dell’autore stesso. Per aggiornarla scrivere a

@infomedia.it o farlo in autonomia all’indirizzo

// mags.programmers.net / moduli / biografia

http://www.infomedia.it/

http://stores.lulu.com/infomedia




http://www.infomedia.it/



Q

uello dei backup è un aspetto

cruciale della gestione di un

sistema informativo che nessun

amministratore dovrebbe affron-

tare con leggerezza. L’impor-

tanza di un piano di salvataggio

ben organizzato potrebbe apparire ovvia: è

semplice trovarsi d’accordo sulla necessità di

eseguire un backup, ma dimensionare oppor-

tunamente una procedura non sempre è un

risultato immediato.

Paradossalmente si incontrano con frequenza

sistemi informativi di ampie dimensioni con

lacune anche gravi nella gestione della sicu-

rezza dei dati. La tendenza a trascurare o sot-

tovalutare il problema è sempre in agguato,

ed in alcuni casi questa “trascuratezza” si

propaga verso il basso anche sulle worksta-

tion ed i PC aziendali. Che siate gli ammini-

stratori di un CED con decine o centinaia diserver da gestire, o semplicemente l’account

root sul vostro computer domestico, non

potete esimervi dall’affrontare il problema

dei salvataggi. Non fidatevi della robustezza

dei vostri impianti o dei contratti d’assistenza

dei fornitori: un comando di cancellazione può

scappare anche dalle dita più esperte, ed i

dispositivi sono pur sempre soggetti a guasti.

Meglio chiudere la stalla “prima”.

Un po’ di chiarezzaPrima di procedere oltre è necessario pun-

tualizzare il significato di alcuni termini per

fugare la possibilità di incomprensioni. Ci aiu-teremo in questo con la Tabella 1, dove per

ognuno dei termini è fornita una breve spie-

gazione ed una schematica descrizione degli

scopi correlati.

Consideriamo ad esempio il significato di

restore e recovery : un fraintendimento può

portare a sorprese spiacevoli o comunque al

rischio di alimentare false illusioni nel cliente.

Nel primo caso, infatti, tutto quello che ci si

può aspettare è la comprovata possibilità di

eseguire una copia da un supporto di backup

(un nastro magnetico o altro, Figura 1).

In molte situazioni questo può essere suffi-

ciente, ma per recuperare un sistema irrime-

diabilmente compromesso è necessario

poter disporre di una valida procedura di reco-

very, che preveda un metodo alternativo per

eseguire il boot e procedere con il ripristino

dei dati. Eseguire un salvataggio, quindi, non

si traduce automaticamente nella possibilità

di eseguire il recovery.

Sistemi di piccole dimensioni, forse per il

fatto di essere facilmente re-installabili, sono

spesso esclusi dai piani di recovery. Ciò non

costituisce automaticamente un problema

nel caso si disponga di risorse e tempo a

volontà. In tutte le altre situazioni investire

qualche ora nel collaudare degli automatismi

permetterà di risparmiarne parecchie in occa-

sione di un problema. In ambienti critici le

procedure di ripristino dovrebbero già essere

a budget, specie se un guasto ed il relativo

disservizio dovessero riflettersi in un danno

economico. Il disaster recovery trova campo

d’applicazione su impianti con ruoli delicati,

adibiti all’elaborazione di informazioni sensi-

bili e consiste, nella sua implementazione più

semplice, nel separare geograficamente isupporti di backup dal sistema di origine, e

può arrivare fino alla replicazione dell’intera

struttura elaborativa. Non si tratta di bilancia-

mento del carico fra più nodi, ma di una con-

tromisura estrema per garantire un livello

accettabile di operatività anche in occasioni

disastrose come inondazioni, incendi e terre-

moti. Fortunatamente esistono soluzioni ade-

guate a qualunque ordine di grandezza che

Backup e recoverycostituisconouna delleproblematichedi amministrazionepiù delicatee sottovalutatenella gestione diun sistemainformativo

Linux backup e recoverydi Riccardo Corsanici > [email protected]

Backup e restore identificano le proceduremediante le quali si esegue una copia deidati su un supporto differente da quello diorigine e viceversa. Una procedura di resto-

re non tiene conto dell’eventualità che ilsistema stesso sia stato compromesso:gestire questo tipo di cir-costanze è compito delleazioni di recovery

FIGURA 1

DEV > n. 118 maggio 2004 89 <<



90 DEV > n. 118 maggio 2004>>

Intermediate

possono essere adottate: le alternative spaziano da blasona-ti prodotti commerciali con licenze a sei zeri a semplici stru-menti adatti anche ad un utilizzo “domestico” (Figura 2).Un ruolo determinante nella scelta delle strategie e di even-tuali prodotti da utilizzare è ricoperto dall’amministratore, chedeve essere in grado di comprendere le necessità operativedel sistema ed integrare con queste una politica di backup erecovery che tenga nella dovuta considerazione il livello di cri-ticità oggettiva. É naturale come una buona conoscenza deglistrumenti disponibili e delle tecniche utilizzabili sia alla basedi questa capacità.

Ecco come procedereLa vastità dei campi di applicazione non consente di formula-

re una ricetta definitiva adatta a tutte le circostanze, tuttaviaè possibile isolare degli step che permettono la scissione delproblema in blocchi più facilmente affrontabili:

• identificare e definire gli obiettivi• studiare il problema in relazione al livello di criticità e

di operatività richiesta• dimensionare opportunamente le strategie• disegnare le procedure• implementare le procedure• verificare l’affidabilità raggiunta• produrre documentazione

Il primo passo non dovrebbe aver bisogno di spiegazioni:quale scopo si vuole ottenere? É la prima domanda da porsi,e non a caso: tutte le azioni successive saranno fortementecondizionate dalla risposta. Sul computer di casa, un salva-taggio periodico della propria home directory (oltre ai file diconfigurazione del sistema) dovrebbe essere sufficiente per la

maggior parte delle esigenze. Di fronte ad un’architettura dis-tribuita composta da un cluster di database server ed un rackdi application server si vorrà probabilmente qualcosa di più.Identificando gli obiettivi da raggiungere lo studio del proble-ma (secondo punto) diventa una conseguenza naturale. Ildimensionamento delle strategie è un’altra fase determinan-te: un errore di valutazione può essere corretto facilmente selo si individua già durante la progettazione. È questo ilmomento di guardarsi intorno per individuare gli strumentiadatti. Per ambienti distribuiti, ad esempio, sono disponibili

TABELLA 1Definizione dei termini “backup”, “restore”, “recovery”, “disaster recovery”

Termine

Backup

Restore

Recovery

DisasterRecovery

Descrizione

Per “backup” si intende la procedura

mediante la quale si esegue una copia deidati su un supporto differente da quello diorigine

Per “restore” si intende la proceduramediante la quale si esegue una copia deidati da un sopporto differente da quello di

destinazione

Per “recovery” si intende l’esecuzione di unaprocedura di ripristino che tenga conto diproblematiche differenti e permetta il recu-pero dell’agibilità di un sistema

Per “disaster recovery” si intende una proce-dura di replicazione dei dati o dell’interosistema informativo in una locazione geogra-fica differente da quella dei dati o del siste-ma di origine

Scopo

Lo scopo di una procedura di backup è quello di sal-

vaguardare l’incolumità dei dati anche da eventiquali:• errori amministrativi (es. cancellazioni acci-

dentali, sovrascritture, etc.)• guasti hardware sui dispositivi• problemi software (procedure distruttive,

difetti nella gestione dei volumi, etc.)• manomissioni• eventi disastrosi

Una buona procedura di backup permette inoltre di:• mantenere uno storico dei dati• replicare completamente il sistema• agevolare le procedure di ripristino

Lo scopo di una procedura di restore è quello digarantire la possibilità di ripristino dei dati salvatimediante una procedura di backup

Lo scopo di una procedura di recovery è quello digarantire il ripristino dell’agibilità di un sistema, ocomunque della fruibilità dei dati. Una corretta pro-cedura di recovery permette fra l’altro di:

• gestire configurazioni in alta affidabilità• gestire problematiche relative a problemi

hardware e software

Lo scopo di una procedura di disaster recovery èquello di garantire la salvaguardia dei dati o l’agibili-tà dell’intero sistema anche in caso di disastri natu-rali e danneggiamenti fisici irreversibili dei supportio del sistema elaborativi

Il modulo di backup fornito con la suite di amministrazioneWebmin rappresenta una soluzione ideale per sistemi di

piccole dimensioni e consente l’esecuzione di backupincrementali. Rappresenta un front-endper il comando di shell “dump”, che puòessere utilizzato per la creazione discript personalizzati

FIGURA 2



prodotti che permettono di centralizzare il controllo dei backupdi tutti i sistemi coinvolti. Il principale vantaggio offerto dasoluzioni di questo tipo è l’astrazione delle tecnologie di bac-kup e restore utilizzate: l’amministratore è sollevato dall’one-re di creare le procedure e può concentrarsi sull’oggetto delsalvataggio, preoccupandosi di “cosa” salvare e non di“come”. La struttura tipica di questi software prevede l’im-piego di uno o più ambienti server (spesso si tratta di sistemidedicati allo scopo) cui si connettono le varie console digestione. Attraverso la console l’amministratore configura ilsoftware agent in esecuzione sul nodo che sarà oggetto deibackup. Non è indispensabile affidarsi a costose soluzioniproprietarie: Linux infatti dispone di tutti gli strumenti neces-sari per implementare procedure adatte a qualunque dimen-sione. Si tratta di programmi di utilità presenti nel corredosoftware di qualunque distribuzione e che possono essereimpiegati, con un po’ di fantasia ed intraprendenza, per lacreazione di strumenti personalizzati di elevato livello qualita-tivo. L’implementazione delle procedure è strettamente dipen-dente dal tipo di soluzione adottata, ma dovrebbe comunque

essere portata avanti favorendone l’elasticità: una proceduraconfigurabile può essere rapidamente adattata a sistemi conesigenze similari, ammortizzando l’investimento di ingegneriz-zazione iniziale. Le verifiche sono imprescindibili: le procedu-re di backup e recovery sono meccanismi di emergenza, ecome tali devono raggiungere il miglior livello di affidabilitàpossibile.

Tecniche di backup e recoveryLe strategie di salvataggio possono essere suddivise in basealle tecniche utilizzate per l’esecuzione del backup. La Tabella

2 illustra le più comuni. I vari approcci descritti trovano il loronaturale campo di applicazione in base alle dimensioni deidati da gestire: nella maggior parte delle circostanze un bac-kup totale eseguito con la giusta frequenza potrebbe apparirela miglior soluzione possibile, tuttavia esistono circostanzeoperative che di fatto impediscono una strategia così lineare.Si pensi a sistemi con necessità operative H24, oppure amotori di database con centinaia di gigabyte di storage: deter-minate condizioni di criticità si riflettono inevitabilmente sullastrategia da adottare. Occorre tener presente che un salva-taggio rappresenta un’attività invasiva nei confronti del siste-ma oggetto: la sua esecuzione toglie risorse macchina e pro-voca un rallentamento.La necessità di esecuzione dei salvataggi rappresenta a volteun punto di attrito fra utenti ed amministratore. Quest’ultimopreferirebbe gravare sull’operatività complessiva in ragione diuno scopo più nobile: proteggere il lavoro dei propri utenti. Gli

utenti, dal canto loro, hanno visibilità unicamente su quelleche sono le “loro” esigenze: progetti in ritardo, applicazioniche non rispondono come dovrebbero e mille altri buoni moti-vi per pretendere un sistema sempre attivo ed interamentededicato. La sola via praticabile consiste nel prendere atto diqueste necessità e coniugarle con l’attività di gestione: lesoluzioni incrementali e differenziali possono risultare adatte

TABELLA 2 La strategia di backup da adottare si basa sulle necessità operative del sistema e degli utenti che lo utilizzano. Coniugarepiù tecniche per creare procedure composte è spesso l’unica via praticabile per garantire la continuità del servizio

Tecnica

Totale

Parziale

Incrementale

Differenziale

Logico

Fisico

Backup

Salvataggio totale del sistema, comprensivosia dei dati che del sistema operativo stesso

Salvataggio parziale dei dati. I dati da salva-re possono essere selezionati in base aparametri dinamici, ad esempio in base alladata di creazione o di modifica

La tecnica incrementale prevede almeno unsalvataggio totale, cui seguono dei backupmirati dei soli dati modificati dall’ultimo bac-kup totale nella prima esecuzione e dall’ulti-mo backup incrementale nelle successive.

ll backup differenziale prevede almeno unbackup totale, e quindi un backup giornalierodei soli dati modificati dall’ultimo salvataggiototale.

Un backup eseguito a livello logico utilizzanormalmente le normali funzionalità delsistema operativo per eseguire il solo bac-kup dei dati, indipendentemente dalla strut-tura fisica in cui sono organizzati.

Il backup fisico ha come scopo l’esecuzione

del dump di un dispositivo, indipendente-mente dalla qualità e quantità di dati in essomemorizzati.

Recovery

Il recovery di un backup totale viene eseguitomediante il restore completo del salvataggio, dati esistema operativo.È possibile estrapolare dal backup totale i soli datidi interesse e procedere ad un restore parziale, ingenere questa procedura comporta un overloadsistemistico ed un incremento dei tempi necessari.Il recovery totale deve prevedere dei meccanismialternativi di boot.

Il recovery non è possibile sulla base di salvataggiparziali. Può essere garantito il ripristino dei solidati di cui è stato eseguito il backup.

ll recovery da backup incrementale viene eseguito intre step:

• ripristino dell’agibilità del sistema (in caso diboot compromesso)

• ripristino del backup totale• ripristino di tutti i backup incrementali ese-

guiti dall’ultimo backup totale

Il recovery da backup differenziale avviene medianteil ripristino dell’ultimo backup totale e quindi dell’ul-timo backup differenziale.

Un recovery da backup logico necessita in generedell’agibilità del sistema operativo. Lo scopo che siprefigge è quello di ripristinare i dati indipendente-mente dalla struttura fisica di origine. Non c’è nes-suna garanzia che il layout fisico di memorizzazionesia identico a quello di partenza.

Il recovery da backup fisico agisce a livello di dispo-

sitivo e non di dato. Può essere utilizzato per il ripri-stino di informazioni su cui il sistema operativo nonha controllo. Il restore garantisce il ripristino delmedesimo layout fisico dell’origine.

DEV > n. 118 maggio 2004 91 <<

Intermediate



L o w L e

v e l Quando si parla di open source vengono subito

in mente pensieri positivi: chiarezza, estendibi-lità, apertura verso l’esterno, sicurezza.Tutti vedono l’open source come una panaceaper ogni male. In molti casi si pensa che dis-porre del codice di un prodotto non possa chefar bene a tutta la comunità di sviluppatori chene fa uso.Ma se il prodotto fosse Windows? Quale sareb-be la risposta del mondo a questa apertura?In realtà nessuno lo può sapere, o meglio, tuttiquelli che dispongono di un sistema P2P lo pos-sono sapere.

Il fattoNei mesi scorsi, un po’ per ingenuità, un po’ pervolontà, un po’ per malizia, sono stati resi dis-ponibili “all’insaputa di Microsoft”, buona partedei sorgenti dell’ormai obsoleto NT4 e di unapiccola parte di Windows 2000 [5]. Si tratta disorgenti ormai datati, essendo stati scritti attor-no all’anno 2000, ma allo stesso tempo poten-zialmente pericolosi.Avendo quei sorgenti, chiunque volesse studia-re il comportamento interno di Windows, puòfarlo anche se limitatamente al poco codice dis-ponibile.Questo studio può esporre, teoricamente, una

serie infinita di nuovi errori, nascosti grazie alfatto che il codice di Windows non è mai statoreso disponibile.In realtà però, anche se ci sono stati molti com-menti sensazionalistici legati a questa notizia[5], a due mesi dall’”indesiderata fuoriuscita”

del codice, è stato scoperto un solo errore,anche se credo che sia dovuto soprattutto alfatto che la comunità ha largamente snobbatoquei sorgenti cosi vecchi.

L’erroreQuesto unico errore è legato alla visualizzazio-ne di bitmap, opportunamente modificate, daparte di vecchie versioni di Internet Explorer [2]

[3] [4].Osservate questo codice:

while (_bmfh.bfOffBits> (unsigned)cbRead)

{

BYTE abDummy[1024];

int cbSkip;

cbSkip = _bmfh.bfOffBits

- cbRead;

if (cbSkip > 1024)

cbSkip = 1024;

if (!Read(abDummy, cbSkip))

goto Cleanup;

cbRead += cbSkip;}

È l’algoritmo di visualizzazione delle bitmap,pubblicato da [4]. Per sapere quanti byte salta-re, nella parte di header di una bitmap, viene

usata una variabile con segno cbSkip per arri-vare al vero e proprio contenuto dell’immagine.Se però viene, volutamente, messo un numerodi _bmfh.bfOffBits > 2^31, cbSkip assume unvalore negativo e la funzione Read legge unvalore sbagliato di byte, sovrascrivendo lo stackdel programma ed esponendo il programmastesso ad un pericolo buffer overflow.

ConclusioniA questo punto cosa pensare? Dopo due mesil’unico bug segnalato è stato questo, tra l’altrolegato ad una versione di Internet Explorerormai obsoleta, 5.01 SP1 (il cui problema piùgrosso non era sicuramente questo, ma altri tri-stemente utilizzati per la diffusione di alcunifamosi virus).Che sia stato tanto rumore per nulla? O unamanovra marketing di tutto rispetto?

Bibliografia[1] http://www.baccan.it, sito di riferimento

per Low Level.[2] http://www.zeusnews.it/index.php3?ar=

stampa&cod=2874&numero=472[3] http://www.securityfocus.com/archi-

ve/1/354059/2004-02-13/2004-02-19/0

[4] http://www.securitytracker.com/alerts/2004/Feb/1009067.html

[5] http://www.zeusnews.it/index.php3?ar=stampa&cod=2866, reso illegalmentepubblico il sorgente di Windows, PaoloAttivissimo

QUANDO L’OPEN SOURCEFA PAURAI sorgenti di Windows alla portata di tutti, rischio di sicurezza o tanto rumore per nulla?

a cura di Matteo Baccan > [email protected]

92 DEV > n. 118 maggio 2004>>

Intermediate

ad affrontare situazioni simili, in quanto si basano su un bac-kup totale di storico e prevedono dei salvataggi ciclici più con-tenuti (e quindi meno invasivi). In molte occasioni sarà neces-sario avvalersi di tecniche composte, ed eseguire, ad esem-pio, un “backup logico incrementale”, unendo in questo modoi potenziali vantaggi di due strategie distinte. Si supponga didover implementare delle procedure di backup e recovery diun database server: in questo caso un salvataggio logicoequivarrebbe all’esecuzione di una export dei dati. In condi-zioni di operatività che non consentono un backup “fisico” deldatabase la soluzione logica sembrerebbe l’unica praticabile.Si consideri però il problema di un eventuale “ripristino”: unaprocedura di import risulterebbe molto più lenta di un restoretotale fisico dei file che compongono il database. Questiaspetti devono essere valutati prima di trovarsi nella necessi-tà di procedere ad un recovery! Spesso esistono soluzioni cherappresentano un buon compromesso: nel caso del databasepuò essere possibile adottare accorgimenti che consentonol’esecuzione di un backup completo senza costringere ad unainterruzione del servizio. In Oracle o DB2, che rappresentano

la quasi totalità del mercato enterprise, sono previste modali-tà di backup che tengono conto di questi problemi.Naturalmente l’elasticità ha un prezzo: le procedure di salva-taggio “a caldo” sono più complesse da realizzare e gestire esi riflettono su tecniche di recovery più difficili e delicate.Nell’ottica di un crash o disaster recovery, le sole proceduredi backup e ripristino non sono sufficienti, ma devono essereaffiancate da meccanismi di sincronizzazione ed allineamentoautomatico dei sistemi coinvolti. In una configurazione cluste-red (crash recovery) i sistemi concorrenti agiscono general-

mente su uno storage esterno condiviso, che può essereagganciato da uno qualunque dei nodi del cluster. Questomodello di struttura provvede implicitamente alla sincronizza-zione dei dati, ma si può dire lo stesso di un mirror geografi-co? Difficilmente un disk array sarà condivisibile da sistemiposti in sedi geografiche distanti tra loro, inoltre la centraliz-zazione dei dati è contraria all’idea stessa di disaster reco-very, che deve essere in grado di gestire persino la distruzio-ne fisica dell’unità di storage. Simili circostanze rendono indi-spensabile una procedura di allineamento dei dati fra i siste-mi e la predisposizione di canali di connettività ridondata fra inodi.

ConclusioniProgettare un piano di backup e recovery è un’attività stimo-lante ed impegnativa. Linux, ed il mondo Unix in generale, for-niscono da sempre una collezione di strumenti semplici epotenti che, nelle mani dell’amministratore, possono esserecombinati per creare procedure robuste, scalabili ed af fidabi-li. Le possibilità quindi non mancano, e tutto quello che vi

serve può essere facilmente reperito nei cd-rom della vostradistribuzione preferita.

Si occupa di consulenza sistemistica, integrazione di siste-

mi e formazione professionale. Insieme ad altri professio-

nisti IT, ha fondato una società di servizi informatici per la

gestione di architetture informative distribuite in ambienti

critici.

Riccardo Corsanici

Documents

Linux backup e recovery