Upload
infomedia-editori-coop
View
235
Download
0
Embed Size (px)
Citation preview
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 siste- mi e for-mazione professionale.Insieme ad altri profes-sionisti IT, ha fondatouna societa di serviziinformatici per la ge-stione di architettureinformative distribuitein ambienti critici.
8/3/2019 Linux backup e recovery
http://slidepdf.com/reader/full/linux-backup-e-recovery 2/6
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
8/3/2019 Linux backup e recovery
http://slidepdf.com/reader/full/linux-backup-e-recovery 3/6
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 <<
8/3/2019 Linux backup e recovery
http://slidepdf.com/reader/full/linux-backup-e-recovery 4/6
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
8/3/2019 Linux backup e recovery
http://slidepdf.com/reader/full/linux-backup-e-recovery 5/6
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
8/3/2019 Linux backup e recovery
http://slidepdf.com/reader/full/linux-backup-e-recovery 6/6
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