DEV DEVeloping Software Solutions n.

118 maggio 2004

Linux backup e recovery

di Riccardo Corsanici
Backup e recovery costituiscono una delle problematiche di amministrazione ` piu delicate e sottovalutate nella gestione di un sistema informativo

Riccardo Corsanici Si occupa di consulenza sistemistica, integrazione di siste- mi e formazione professionale. Insieme ad altri professionisti IT, ha fondato ` una societa di servizi informatici per la gestione di architetture informative distribuite in ambienti critici.

pubblicato su WWW.INFOMEDIA.IT stampa digitale da Lulu Enterprises Inc. stores.lulu.com/infomedia

Infomedia
` Infomedia e limpresa editoriale che da quasi venti anni ha raccolto la voce dei programmatori, dei sistemisti, dei professionisti, degli studenti, dei ricercatori e dei professori dinformatica italiani. Sono pi` di 800 gli autori che hanno realizzato per le teu state Computer Programming, Dev, Login, Visual Basic Journal e Java Journal, molte migliaia di articoli tecnici, presentazioni di prodotti, tecnologie, protocolli, strumenti di lavoro, tecniche di sviluppo e semplici trucchi e stratagemmi. Oltre 6 milioni di copie distribuite, trentamila pagine stampate, fanno di questa impresa la pi` grande ed u inuente realt` delleditoria specializzata nel campo della a programmazione e della sistemistica. In tutti questi anni le riviste Infomedia hanno vissuto della passione di quanti vedono nella programmazione non solo la propria professione ma unattivit` vitale e un vero a divertimento. ` Nel 2009, Infomedia e cambiata radicalmente adottando ` un nuovo modello aziendale ed editoriale e si e organizzata attorno ad una idea di Impresa Sociale di Comunit` , a partecipata da programmatori e sistemisti, separando le attivit` di gestione dellinformazione gestite da un board a comunitario professionale e quelle di produzione gesti` te da una impresa strumentale. Questo assetto e in linea con le migliori esperienze internazionali e rende Infomedia ancora di pi` parte della Comunit` nazionale degli u a sviluppatori di software. ` Infomedia e media-partner di manifestazioni ed eventi in ambito informatico, collabora con molti dei pi` imporu tanti editori informatici italiani come partner editoriale e fornitore di servizi di localizzazione in italiano di testi in lingua inglese.

Limpaginazione automatica di questa rivista e realizzata al ` 100% con strumenti Open Source usando OpenOffice, Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp, Python e BASH

For copyright information about the contents of DEV, please see the section Copyright at the end of each article if exists, otherwise ask authors. Infomedia contents is 2004 Infomedia and released as Creative Commons 2.5 BY-NC-ND. Turing Club content is 2004 Turing Club released as Creative Commons 2.5 BY-ND. Le informazioni di copyright sul contenuto di DEV sono riportate nella sezione Copyright alla ne di ciascun articolo o vanno richieste direttamente agli autori. Il contenuto Infomedia e 2004 Infomedia e rilasciato ` con Licenza Creative Commons 2.5 BY-NC-ND. Il contenuto Turing Club e 2004 Turing Club e rilasciato ` con Licenza Creative Commons 2.5 BY-ND. Si applicano tutte le norme di tutela dei marchi e dei segni distintivi. ` E in ogni caso ammessa la riproduzione parziale o totale dei testi e delle immagini per scopo didattico purch e vengano integralmente citati gli autori e la completa identicazione della testata. Manoscritti e foto originali, anche se non pubblicati, non si restituiscono. Contenuto pubblicitario inferiore al 45%. La biograa dellautore riportata nellarticolo e sul sito www.infomedia.it e di norma quella disponibi` le nella stampa dellarticolo o aggiornata a cura dellautore stesso. Per aggiornarla scrivere a info@infomedia.it o farlo in autonomia allindirizzo http://mags.programmers.net/moduli/biograa

Linux backup e recovery

di

Riccardo Corsanici > corsanici@infomedia.it

uello dei backup un aspetto cruciale della gestione di un sistema informativo che nessun amministratore dovrebbe affrontare con leggerezza. Limportanza di un piano di salvataggio ben organizzato potrebbe apparire ovvia: semplice trovarsi daccordo sulla necessit di eseguire un backup, ma dimensionare opportunamente una procedura non sempre un risultato immediato. Paradossalmente si incontrano con frequenza sistemi informativi di ampie dimensioni con lacune anche gravi nella gestione della sicurezza dei dati. La tendenza a trascurare o sottovalutare il problema sempre in agguato, ed in alcuni casi questa trascuratezza si propaga verso il basso anche sulle workstation ed i PC aziendali. Che siate gli amministratori di un CED con decine o centinaia di server da gestire, o semplicemente laccount root sul vostro computer domestico, non potete esimervi dallaffrontare il problema dei salvataggi. Non fidatevi della robustezza dei vostri impianti o dei contratti dassistenza 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.

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 occasione 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 dapplicazione su impianti con ruoli delicati, adibiti allelaborazione di informazioni sensibili e consiste, nella sua implementazione pi semplice, nel separare geograficamente i supporti di backup dal sistema di origine, e pu arrivare fino alla replicazione dellintera struttura elaborativa. Non si tratta di bilanciamento del carico fra pi nodi, ma di una contromisura estrema per garantire un livello accettabile di operativit anche in occasioni disastrose come inondazioni, incendi e terremoti. Fortunatamente esistono soluzioni adeguate a qualunque ordine di grandezza che

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

Un po di chiarezza
Prima di procedere oltre necessario puntualizzare il significato di alcuni termini per fugare la possibilit di incomprensioni. Ci aiuteremo in questo con la Tabella 1, dove per ognuno dei termini fornita una breve spiegazione 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 sufficiente, ma per recuperare un sistema irrimediabilmente compromesso necessario poter disporre di una valida procedura di recovery, che preveda un metodo alternativo per eseguire il boot e procedere con il ripristino
DEV > n. 118 maggio 2004

Backup e restore identificano le procedure mediante le quali si esegue una copia dei dati su un supporto differente da quello di origine e viceversa. Una procedura di restore non tiene conto delleventualit che il sistema stesso sia stato compromesso: gestire questo tipo di circostanze compito delle FIGURA 1 azioni di recovery

89 <<

Intermediate

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

Termine
Backup

Descrizione
Per backup si intende la procedura mediante la quale si esegue una copia dei dati su un supporto differente da quello di origine

Scopo
Lo scopo di una procedura di backup quello di salvaguardare lincolumit dei dati anche da eventi quali: errori amministrativi (es. cancellazioni accidentali, 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 di garantire la possibilit di ripristino dei dati salvati mediante una procedura di backup Lo scopo di una procedura di recovery quello di garantire il ripristino dellagibilit di un sistema, o comunque della fruibilit dei dati. Una corretta procedura di recovery permette fra laltro 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 lagibilit dellintero sistema anche in caso di disastri naturali e danneggiamenti fisici irreversibili dei supporti o del sistema elaborativi

Restore

Per restore si intende la procedura mediante la quale si esegue una copia dei dati da un sopporto differente da quello di destinazione Per recovery si intende lesecuzione di una procedura di ripristino che tenga conto di problematiche differenti e permetta il recupero dellagibilit di un sistema

Recovery

Disaster Recovery

Per disaster recovery si intende una procedura di replicazione dei dati o dellintero sistema informativo in una locazione geografica differente da quella dei dati o del sistema di origine

possono essere adottate: le alternative spaziano da blasonati prodotti commerciali con licenze a sei zeri a semplici strumenti adatti anche ad un utilizzo domestico (Figura 2). Un ruolo determinante nella scelta delle strategie e di eventuali prodotti da utilizzare ricoperto dallamministratore, che deve essere in grado di comprendere le necessit operative del sistema ed integrare con queste una politica di backup e recovery che tenga nella dovuta considerazione il livello di criticit oggettiva. naturale come una buona conoscenza degli strumenti disponibili e delle tecniche utilizzabili sia alla base di questa capacit.

maggior parte delle esigenze. Di fronte ad unarchitettura distribuita composta da un cluster di database server ed un rack di application server si vorr probabilmente qualcosa di pi. Identificando gli obiettivi da raggiungere lo studio del problema (secondo punto) diventa una conseguenza naturale. Il dimensionamento delle strategie unaltra fase determinante: un errore di valutazione pu essere corretto facilmente se lo si individua gi durante la progettazione. questo il momento di guardarsi intorno per individuare gli strumenti adatti. Per ambienti distribuiti, ad esempio, sono disponibili

Ecco come procedere

La vastit dei campi di applicazione non consente di formulare una ricetta definitiva adatta a tutte le circostanze, tuttavia possibile isolare degli step che permettono la scissione del problema 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 laffidabilit 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 fortemente condizionate dalla risposta. Sul computer di casa, un salvataggio periodico della propria home directory (oltre ai file di configurazione del sistema) dovrebbe essere sufficiente per la
>> 90 Il modulo di backup fornito con la suite di amministrazione Webmin rappresenta una soluzione ideale per sistemi di piccole dimensioni e consente lesecuzione di backup incrementali. Rappresenta un front-end per il comando di shell dump, che pu essere utilizzato per la creazione di FIGURA 2 script personalizzati

DEV > n. 118 maggio 2004

Intermediate

prodotti che permettono di centralizzare il controllo dei backup di tutti i sistemi coinvolti. Il principale vantaggio offerto da soluzioni di questo tipo lastrazione delle tecnologie di backup e restore utilizzate: lamministratore sollevato dallonere di creare le procedure e pu concentrarsi sulloggetto del salvataggio, preoccupandosi di cosa salvare e non di come. La struttura tipica di questi software prevede limpiego di uno o pi ambienti server (spesso si tratta di sistemi dedicati allo scopo) cui si connettono le varie console di gestione. Attraverso la console lamministratore configura il software agent in esecuzione sul nodo che sar oggetto dei backup. Non indispensabile affidarsi a costose soluzioni proprietarie: Linux infatti dispone di tutti gli strumenti necessari per implementare procedure adatte a qualunque dimensione. Si tratta di programmi di utilit presenti nel corredo software di qualunque distribuzione e che possono essere impiegati, con un po di fantasia ed intraprendenza, per la creazione di strumenti personalizzati di elevato livello qualitativo. Limplementazione delle procedure strettamente dipendente dal tipo di soluzione adottata, ma dovrebbe comunque essere portata avanti favorendone lelasticit: una procedura configurabile pu essere rapidamente adattata a sistemi con esigenze similari, ammortizzando linvestimento di ingegnerizzazione iniziale. Le verifiche sono imprescindibili: le procedure di backup e recovery sono meccanismi di emergenza, e come tali devono raggiungere il miglior livello di affidabilit possibile.

Tecniche di backup e recovery

Le strategie di salvataggio possono essere suddivise in base alle tecniche utilizzate per lesecuzione del backup. La Tabella 2 illustra le pi comuni. I vari approcci descritti trovano il loro naturale campo di applicazione in base alle dimensioni dei dati da gestire: nella maggior parte delle circostanze un backup totale eseguito con la giusta frequenza potrebbe apparire la miglior soluzione possibile, tuttavia esistono circostanze operative che di fatto impediscono una strategia cos lineare. Si pensi a sistemi con necessit operative H24, oppure a motori di database con centinaia di gigabyte di storage: determinate condizioni di criticit si riflettono inevitabilmente sulla strategia da adottare. Occorre tener presente che un salvataggio rappresenta unattivit invasiva nei confronti del sistema oggetto: la sua esecuzione toglie risorse macchina e provoca un rallentamento. La necessit di esecuzione dei salvataggi rappresenta a volte un punto di attrito fra utenti ed amministratore. Questultimo preferirebbe gravare sulloperativit complessiva in ragione di uno scopo pi nobile: proteggere il lavoro dei propri utenti. Gli utenti, dal canto loro, hanno visibilit unicamente su quelle che sono le loro esigenze: progetti in ritardo, applicazioni che non rispondono come dovrebbero e mille altri buoni motivi per pretendere un sistema sempre attivo ed interamente dedicato. La sola via praticabile consiste nel prendere atto di queste necessit e coniugarle con lattivit di gestione: le soluzioni incrementali e differenziali possono risultare adatte

TABELLA 2
Tecnica
Totale

La strategia di backup da adottare si basa sulle necessit operative del sistema e degli utenti che lo utilizzano. Coniugare pi tecniche per creare procedure composte spesso lunica via praticabile per garantire la continuit del servizio

Backup
Salvataggio totale del sistema, comprensivo sia dei dati che del sistema operativo stesso

Recovery
Il recovery di un backup totale viene eseguito mediante il restore completo del salvataggio, dati e sistema operativo. possibile estrapolare dal backup totale i soli dati di interesse e procedere ad un restore parziale, in genere questa procedura comporta un overload sistemistico ed un incremento dei tempi necessari. Il recovery totale deve prevedere dei meccanismi alternativi di boot. Il recovery non possibile sulla base di salvataggi parziali. Pu essere garantito il ripristino dei soli dati di cui stato eseguito il backup. ll recovery da backup incrementale viene eseguito in tre step: ripristino dellagibilit del sistema (in caso di boot compromesso) ripristino del backup totale ripristino di tutti i backup incrementali eseguiti dallultimo backup totale Il recovery da backup differenziale avviene mediante il ripristino dellultimo backup totale e quindi dellultimo backup differenziale. Un recovery da backup logico necessita in genere dellagibilit del sistema operativo. Lo scopo che si prefigge quello di ripristinare i dati indipendentemente dalla struttura fisica di origine. Non c nessuna garanzia che il layout fisico di memorizzazione sia identico a quello di partenza. Il recovery da backup fisico agisce a livello di dispositivo e non di dato. Pu essere utilizzato per il ripristino di informazioni su cui il sistema operativo non ha controllo. Il restore garantisce il ripristino del medesimo layout fisico dellorigine.

Parziale

Salvataggio parziale dei dati. I dati da salvare possono essere selezionati in base a parametri dinamici, ad esempio in base alla data di creazione o di modifica La tecnica incrementale prevede almeno un salvataggio totale, cui seguono dei backup mirati dei soli dati modificati dallultimo backup totale nella prima esecuzione e dallultimo backup incrementale nelle successive.

Incrementale

Differenziale

ll backup differenziale prevede almeno un backup totale, e quindi un backup giornaliero dei soli dati modificati dallultimo salvataggio totale. Un backup eseguito a livello logico utilizza normalmente le normali funzionalit del sistema operativo per eseguire il solo backup dei dati, indipendentemente dalla struttura fisica in cui sono organizzati. Il backup fisico ha come scopo lesecuzione del dump di un dispositivo, indipendentemente dalla qualit e quantit di dati in esso memorizzati.

Logico

Fisico

DEV > n. 118 maggio 2004

91 <<

Intermediate

ad affrontare situazioni simili, in quanto si basano su un backup totale di storico e prevedono dei salvataggi ciclici pi contenuti (e quindi meno invasivi). In molte occasioni sar necessario avvalersi di tecniche composte, ed eseguire, ad esempio, un backup logico incrementale, unendo in questo modo i potenziali vantaggi di due strategie distinte. Si supponga di dover implementare delle procedure di backup e recovery di un database server: in questo caso un salvataggio logico equivarrebbe allesecuzione di una export dei dati. In condizioni di operativit che non consentono un backup fisico del database la soluzione logica sembrerebbe lunica praticabile. Si consideri per il problema di un eventuale ripristino: una procedura di import risulterebbe molto pi lenta di un restore totale fisico dei file che compongono il database. Questi aspetti devono essere valutati prima di trovarsi nella necessit di procedere ad un recovery! Spesso esistono soluzioni che rappresentano un buon compromesso: nel caso del database pu essere possibile adottare accorgimenti che consentono lesecuzione di un backup completo senza costringere ad una interruzione del servizio. In Oracle o DB2, che rappresentano la quasi totalit del mercato enterprise, sono previste modalit di backup che tengono conto di questi problemi. Naturalmente lelasticit ha un prezzo: le procedure di salvataggio a caldo sono pi complesse da realizzare e gestire e si riflettono su tecniche di recovery pi difficili e delicate. Nellottica di un crash o disaster recovery, le sole procedure di backup e ripristino non sono sufficienti, ma devono essere affiancate da meccanismi di sincronizzazione ed allineamento automatico dei sistemi coinvolti. In una configurazione clustered (crash recovery) i sistemi concorrenti agiscono general-

mente su uno storage esterno condiviso, che pu essere agganciato da uno qualunque dei nodi del cluster. Questo modello di struttura provvede implicitamente alla sincronizzazione dei dati, ma si pu dire lo stesso di un mirror geografico? Difficilmente un disk array sar condivisibile da sistemi posti in sedi geografiche distanti tra loro, inoltre la centralizzazione dei dati contraria allidea stessa di disaster recovery, che deve essere in grado di gestire persino la distruzione fisica dellunit di storage. Simili circostanze rendono indispensabile una procedura di allineamento dei dati fra i sistemi e la predisposizione di canali di connettivit ridondata fra i nodi.

Conclusioni
Progettare un piano di backup e recovery unattivit stimolante ed impegnativa. Linux, ed il mondo Unix in generale, forniscono da sempre una collezione di strumenti semplici e potenti che, nelle mani dellamministratore, possono essere combinati per creare procedure robuste, scalabili ed affidabili. Le possibilit quindi non mancano, e tutto quello che vi serve pu essere facilmente reperito nei cd-rom della vostra distribuzione preferita.

Riccardo Corsanici
Si occupa di consulenza sistemistica, integrazione di sistemi e formazione professionale. Insieme ad altri professionisti IT, ha fondato una societ di servizi informatici per la gestione di architetture informative distribuite in ambienti critici.

QUANDO LOPEN SOURCE FA PAURA

a cura di Matteo Baccan > baccan@infomedia.it

I sorgenti di Windows alla portata di tutti, rischio di sicurezza o tanto rumore per nulla?

Low Level

Quando si parla di open source vengono subito in mente pensieri positivi: chiarezza, estendibilit, apertura verso lesterno, sicurezza. Tutti vedono lopen source come una panacea per ogni male. In molti casi si pensa che disporre del codice di un prodotto non possa che far bene a tutta la comunit di sviluppatori che ne fa uso. Ma se il prodotto fosse Windows? Quale sarebbe la risposta del mondo a questa apertura? In realt nessuno lo pu sapere, o meglio, tutti quelli che dispongono di un sistema P2P lo possono sapere.

del codice, stato scoperto un solo errore, anche se credo che sia dovuto soprattutto al fatto che la comunit ha largamente snobbato quei sorgenti cosi vecchi.

Lerrore
Questo unico errore legato alla visualizzazione di bitmap, opportunamente modificate, da parte 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; } lalgoritmo di visualizzazione delle bitmap, pubblicato da [4]. Per sapere quanti byte saltare, nella parte di header di una bitmap, viene

usata una variabile con segno cbSkip per arrivare al vero e proprio contenuto dellimmagine. Se per viene, volutamente, messo un numero di _bmfh.bfOffBits > 2^31, cbSkip assume un valore negativo e la funzione Read legge un valore sbagliato di byte, sovrascrivendo lo stack del programma ed esponendo il programma stesso ad un pericolo buffer overflow.

Conclusioni
A questo punto cosa pensare? Dopo due mesi lunico bug segnalato stato questo, tra laltro legato ad una versione di Internet Explorer ormai obsoleta, 5.01 SP1 (il cui problema pi grosso non era sicuramente questo, ma altri tristemente utilizzati per la diffusione di alcuni famosi virus). Che sia stato tanto rumore per nulla? O una manovra marketing di tutto rispetto?

Il fatto
Nei mesi scorsi, un po per ingenuit, un po per volont, un po per malizia, sono stati resi disponibili allinsaputa di Microsoft, buona parte dei sorgenti dellormai obsoleto NT4 e di una piccola parte di Windows 2000 [5]. Si tratta di sorgenti ormai datati, essendo stati scritti attorno allanno 2000, ma allo stesso tempo potenzialmente pericolosi. Avendo quei sorgenti, chiunque volesse studiare il comportamento interno di Windows, pu farlo anche se limitatamente al poco codice disponibile. Questo studio pu esporre, teoricamente, una serie infinita di nuovi errori, nascosti grazie al fatto che il codice di Windows non mai stato reso disponibile. In realt per, anche se ci sono stati molti commenti sensazionalistici legati a questa notizia [5], a due mesi dallindesiderata fuoriuscita

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/ar chive/1/354059/2004-02-13/2004-02-19/0 [4] http://www.securitytracker.com/aler ts/ 2004/Feb/1009067.html [5] http://www.zeusnews.it/index.php3?ar= stampa&cod=2866, reso illegalmente pubblico il sorgente di Windows, Paolo Attivissimo

>> 92

DEV > n. 118 maggio 2004