DAR, tool per i backups di Linux

Alcune cose da notare:

        * DIR è la variabile che rappresenta la directory di destinazione.
        * FILE rappresenta il percorso del file di backup di oggi.
        * Uso percorsi assoluti nei comandi perchè il mio account di root non li ha tutti inclusi nell'ambiente di default. Questo è potenzialmente un rischio in ambito di sicurezza. Idealmente dovreste compilare DAR come root e mantenere i binari dove li avete creati, così nessuno potrà toccarli o eseguirvi Tripwire.
        * DAR genera statistiche dopo ogni esecuzione. A noi non servono se eseguite in cron perchè produrrebbero solo mail inutili. Lo stdout è rediretto a /dev/null. Gli errori saranno invece riportati in una mail nel caso qualcosa andasse storto.
        * Gli ultimi due comandi find sono opzionali. Li uso per cambiare i permessi dei file per un normale utente che creerà successivamente i backup. Un ulteriore rischio in fatto di sicurezza. Root dovrebbe eseguire il backup dei file da root e gli utenti i loro. Ma con un sistema mono-user questo non è importante. Se un ipotetico intruso è capace di passare attraverso il mio firewall, inserire la mia password e quindi guardare tutti i miei backup: sono fregato.

    Ora ponete il seguente script per i backup differenziali, quasi identico al precedente, sotto /root/dar_diff.sh:

    #!/bin/sh

    DIR=/var/backups/system
    FILE=${DIR}/`/bin/date -I`_diff
    PREV=`/bin/ls $DIR/*.dar|/usr/bin/tail -n 1`
    /usr/local/bin/dar -m 256 -y -s 600M -D -R / -c $FILE -Z "*.gz"
     -Z "*.bz2" -Z "*.zip" -Z "*.png" -P home/gradha -P tmp -P mnt
     -P dev/pts -P proc -P floppy -P burner -P cdrom
     -P var/backups -A ${PREV%%.*} > /dev/null
    /usr/local/bin/dar -t $FILE > /dev/null
    /usr/bin/find $DIR -type f -exec chown .gradha {} ;
    /usr/bin/find $DIR -type f -exec chmod 440 {} ;

    Gli unici due cambiamenti sono le aggiunte dell'opzione -A e la generazione della variabile PREV con una linea di comando un po' complicata. Vediamo cosa fa questa linea di comando:

        * Prima di tutto, il comando ls crea una lista dei file con estensione .dar presenti nella directory di backup; euesto output è rediretto al comando successivo.
        * Di default ls elenca i file in ordine alfabetico. tail è usato per ottenere l'ultimo file con l'opzione -n 1 che ordina di mostrare solo l'ultima riga.
        * DAR necessita di lavorare con filenames senza il numero di slice e senza estensione. Se non correggiamo noi il nome del file, DAR fermerà il processo e chiederà all'utente se effettuare l'operazione in modo automatico o meno. Separiamo quindi il nome del file con una feature Bash, chiamata parametro d'espansione. Ci sono diverse possibili espansioni, potete digitare man bash per vederle tutte. Usando %% rimuoviamo la più lunga "coda" di caratteri che si trova dopo il %%. Il risultato è il nome base che vogliamo passare a DAR.

    Ora dobbiamo solo mettere questi due script sotto il controllo di cron. Questo è ciò che dobbiamo scrivere dopo il comando crontab -e:

    15 0 2-31 * * ./dar_diff.sh
    15 0 1    * * ./dar_backup.sh

    Controllate in man -S 5 crontab la sintassi del comando. In breve queste due linee dicono a cron di far partire i processi 15 minuti dopo la mezzanotte. dar_backup.sh verrà eseguito solo il primo giorno del mese. L'altro script verrà eseguito tutti gli altri giorni.

    Ecco quì gli scripts di backup per i vostri utenti. Essi sono identici, cambiano solo alcune opzioni di DAR e i percorsi:

    #!/bin/sh
    # dar_backup.sh

    DIR=/var/backups/gradha
    FILE=${DIR}/`/bin/date -I`_data
    # Commands
    /usr/local/bin/dar -m 256 -y -s 600M -D -R /home/gradha -c $FILE
     -Z "*.gz" -Z "*.bz2" -Z "*.zip" -Z "*.png"
     -P instalacion_manual -P Mail/mail_pa_leer > /dev/null
    /usr/local/bin/dar -t $FILE > /dev/null
    /usr/bin/find $DIR -type f -exec chmod 400 {} ;

    #!/bin/sh
    # dar_diff.sh

    DIR=/var/backups/gradha
    FILE=${DIR}/`/bin/date -I`_diff
    PREV=`/bin/ls $DIR/*.dar|/usr/bin/tail -n 1`
    /usr/local/bin/dar -m 256 -y -s 600M -D -R /home/gradha -c $FILE
     -Z "*.gz" -Z "*.bz2" -Z "*.zip" -Z "*.zip"
     -P instalacion_manual -P Mail/mail_pa_leer
     -A ${PREV%%.*} > /dev/null
    /usr/local/bin/dar -t $FILE > /dev/null
    /usr/bin/find $DIR -type f -exec chmod 400 {} ;

    Non dimenticate di aggiungere a crontab le stringhe richieste per i votri utenti.

    Estrarre i backup su macchine vuote

    Venuto il momento di recuperare i vostri backup, in base a quello che avete salvato, avrete il backup completo del mese e tanti backup differenziali quanti quelli che avete fatto. Il processo di recupero dei dati è molto semplice: è uguale a quello descritto nel primo paragrafo (

         Utilizzo essenziale di DAR), l'importante è che prima recuperiate il backup base e solo successivamente quelli differenziali. Questo può essere noioso, così ecco quà un'altro script che potete salvare fra i vostri file di backup:

    #!/bin/sh

    if [ -n "$3" ]; then
     CMD="$1"
     INPUT="$2_data"
     FS_ROOT="$3"
     $CMD -x "$INPUT" -w -R "$FS_ROOT"
     for file in ${INPUT:0:8}*_diff*; do
        $CMD -x "${file:0:15}" -w -R "$FS_ROOT"
     done
     echo "All done."
    else
     echo "Not enough parameters.

    Usa: script dar_location base_full_backup directory

    Dove dar_location è un percorso alla directory con i binari di dar,
    base_full_backup è una data in formato 'YYYY-MM-DD' e directory è
    il posto dove volete mettere i file recuperati, solitamente '/'
    quando eseguito come root."
    fi

    Lo script si spiega da solo. L'unica cosa alla quale dovete fare attenzione è l'opzione -wDAR di sovrascrivere i file trovati. Questo è obbligatorio per i backup differenziali. Ricordate di mettere lo script nella stessa directory dove mettete i file di backup. Ecco un'utilizzo di esempio: che dice a

    ./recover.sh /usr/local/bin/dar 2003-10-01 /tmp/temp_path/

    Provate ad utilizzare questo come utente normale con pochi file di backup. Potete mettere i file recuperati in una directory temporanea, così non dovete svuotare il vostro hard disk per provarlo.

    Aggiungere dei controlli allo script di backup

    Denis Corbin suggerisce che lo script di creazione dei backup verifichi anche l'exit status dei comandi di

    DAR. Per quanto riguarda questo script così semplice, ciò non è di importanza critica perchè DAR stesso stamperebbe a schermo un messaggio d'errore e cron lo riporterebbe via mail (cosa che normalmente non succede se tutto va per il verso giusto)

    Comunque testare l'exit status può essere utile se state verificando il funzionamento dello script e volete sapere quali comandi sono eseguiti:

    #!/bin/sh

    DIR=/var/backups/system
    FILE=${DIR}/`/bin/date -I`_data
    # Commands
    if /usr/local/bin/dar -m 256 -y -s 600M -D -R / -c $FILE -Z "*.gz"
        -Z "*.bz2" -Z "*.zip" -Z "*.png" -P home/gradha -P tmp
        -P mnt -P dev/pts -P proc -P floppy -P burner
        -P cdrom -P var/backups > /dev/null ; then
     if /usr/local/bin/dar -t $FILE > /dev/null ; then
        echo "Archive created and successfully tested."
     else
        echo "Archive created but test FAILED."
     fi
    else
     echo "Archive creating FAILED."
    fi
    /usr/bin/find $DIR -type f -exec chown .gradha {} ;
    /usr/bin/find $DIR -type f -exec chmod 440 {} ;

    Potete testare facilmente questa versione facendo partire lo script e killando i processi di DAR manualmente da un'altro terminale o un'altra console con killall dar, che forzerà la fine dei processi DAR e vedrete che uno dei rami di fallimento sarà raggiunto nello script di backup.

    Un'ulteriore possibile utilizzo per testare il codice può essere la rimozione di archivi incompleti dall'hard disk se qualcosa andasse male o evitare di testare l'archivio creato quando sapete che il primo comando è già fallito. Successivamente si possono facilmente concatenare i comandi di creazione e di test con && in una singola linea di testo. Ciò indica alla shell di eseguire entrambi i comandi in sequenza e impedisce l'esecuzione del secondo se il primo è fallito.

    una procedura di backup, questa versione dello script lascierà archivi errati vaganti. Per prevenire ciò potete fare in modo che lo script esegua una positive verification. Ciò creerà il backup in una directory temporanea insieme con un file *.valid.

    Così un'altro script monitora la directory dove i file temporanei sono messi e sposta in una directory definitiva i file con *.valid eliminando quelli la cui ultima modifica è precedente a un'ora.

Idee per il futuro.
  
        *          Unificare gli script dei backup di base e differenziali in uno unico, cosicchè se all'esecuzione dello script non esistono backup base per il mese corrente questo venga reato. Utile per macchine che rimangono spente molto tempo dopo che il backup mensile è stato fatto.
        *          Aggiornare lo script in modo che crei giornalmente un immagine per CD ROM con cdrecord e la masterizzi automaticamente su un cd riscrivibile presente nel drive. Così nel caso l'intero hard disk si guasti sarebbe disponibile l'ultimo backup su un media rimovibile. Certo la cosa è limitata e non può essere automatica nel caso i backup occupino più spazio di un CDROM. La stessa cosa vale per ZIP/JAZZ/qualsiasi cosa vogliate.
        *          Integrazione dei backup generati con una mini Knoppix bootable o qualsiasi altra ditribuzione che possa essere avviata da CDROM. Così avreste un CDROM per recuperare i dati che può partire automaticamente e formattare il vostro hard disk.
        *          Sincronizzazione delle directory di backup attraverso internet con hosts remoti. In questo modo se l'intera macchina è bruciata fisicamente, ad esempio con la vostra casa, voi avete i vostri backup in qualche altro posto. Potrebbe essere fatto facilmente con programmi come rsync attraverso ssh eseguiti tramite cron.
        *          Inserimento dei parametri comuni in un file separato da inculdere dallo script utilizzando l'opzione di DAR, -B. Per esempio:

          $ cat > /var/backups/system/common.dcf
          -m 256 -y -s 600M -D -R / -Z "*.gz" -Z "*.bz2" -Z "*.zip"
          -Z "*.png" -P home/gradha -P tmp -P mnt -P dev/pts
          -P proc -P floppy -P burner -P cdrom -P var/backups

          Successivamente si può utilizzare questo nello script:

          DIR=/var/backups/system
          FILE=${DIR}/`/bin/date -I`_data
          # Commands
          /usr/local/bin/dar -B ${DIR}/common.dcf -c $FILE > /dev/null
          /usr/local/bin/dar -t $FILE > /dev/null
          /usr/bin/find $DIR -type f -exec chown .gradha {} ;

          Che può essere riutilizzato anche nella versione differenziale!

    In effetti, qualcuno ha già iniziato a creare qualche script a proprio uso e consumo e non ha problemi a condividerli. Per evitare di "disordinare" questo mini-howto ho intenzione di archiviarli come sono nel mio spazio web: http://gradha.sdf-eu.org/dar_scripts/.

    Sentitevi liberi di inviare i vostri lavori e i vostri aggiornamenti e li aggiungerò alla directory. Se avete intenzione di inviare un singolo file di script o un .tar.gz con una intera suite di backup, inserite un semplice file .txt descrittivo che metterò assieme agli altri files, così la gente potrà leggere cosa sono e cosa fanno i files prima di scaricarli. Usate l'inglese nella vostra descrizione e non dimenticate di mettere nome e e-mail così la gente potrà inviarvi bugfixes o miglioramenti.

Per finire.

Versione un po' corretta, con un italiano un po' più scorrevole. Ecco lo scopo che mi ero prefissato per questa revisione. Non so se l'obbiettivo è stato raggiunto, ma non immaginavo che tradurre dall'inglese fosse così difficile. Termini che initaliano non sai come rendere, plurali di nomi inglesi che in italiano rimangono singolari, modi di dire che, una volta tradotti letteralmente, non ti escono più dalla testa. Spero, comunque, che riusciate a capire in modo più agevole questa correzione rimanendo, come sempre, a disposizione. David (link at the beginning of the document)