Topic: Backup di SME Server su 2 macchine remote tramite tar e cron

[Lord Quicksilver]

Salve a tutti.
Come dice il titolo, in questo post voglio spiegarvi come effettuo il duplice backup giornaliero dei dati del mio server SME. Ringrazio Stefano - nenonano per l'aiuto che mi ha dato al riguardo.

Sostanzialmente si crea un file di script che esegue un tar delle directory importanti di SME e lo copia in remoto, dopodiché lo si manda in esecuzione automatica tramite cron.
Il metodo di backup da me preferito è quello di eseguirne due, uno verso mezzogiorno (per salvare i dati della mattina) e uno verso mezzanotte (per quelli del pomeriggio / sera).
Il primo backup viene eseguito su una macchina dotata di masterizzatore dvd (nel mio caso, un portatile con windows), tramite il quale masterizzo un dvd di dati più o meno ogni settimana.
Il secondo backup viene eseguito su un'altra macchina (nel mio caso una workstation ubuntu), a rotazione settimanale (cioè ogni 7 giorni si sovrascrive il backup più vecchio). Il secondo backup serve non solo per diminuire la perdita di dati in caso di incidente, ma anche per avere sempre a disposizione un backup "fresco" quando il portatile non è in ufficio. La scelta di una rotazione settimanale dei file è stata obbligatoria, dal momento che questa macchina ha un hd da 20 giga già bello pieno di estensioni di compiz-fusion e menate varie. Siccome avevo già preparato uno script strutturato per funzionare con samba, ho preferito utilizzare quest'ultimo anche per il backup linux (i puritani vorranno la mia testa).

Ho diviso tutta l'operazione in 3 punti.

1) settaggio cartelle remote sulle 2 macchine e delle directory di mount sul server SME.
Questo do per scontato che sappiate farlo da soli.

2) creazione dello script (premetto che il codice l'ho riadattato da altri codici presi qua e là)
Create sul Server SME un file di nome

Code: [Select]

run_backup.sh nella directory /opt/backup (se non esiste, createla), dopodiché editatelo con il vostro editor preferito (in fondo trovate il codice tutto insieme, qui lo analizzo pezzo per pezzo):

Code: [Select]

#!/bin/sh

# Costanti per connessione remota
PC_NAME=$1
SHARE_NAME="share"
DIRECTORY="backupdir"
CREDENTIALS_FILE="/root/.smbaccess${PC_NAME}"

Questi sono i dati fondamentali per accedere alle cartelle remote sulle 2 macchine di backup: modificateli adattandoli alle vostre esigenze.
I file /root/.smbaccess<nome macchina> li vedremo più avanti.

Code: [Select]


# Creo il file di backup
case "${PC_NAME}" in
        "windows")
                        FILE_BACKUP="smeserver_$(date +%y_%m_%d).tgz";;
        "ubuntu")
                        FILE_BACKUP="smeserver_$(date +%w_%a).tgz";;
esac
/sbin/e-smith/signal-event pre-backup
/bin/tar -z --directory / --create --files-from /opt/backup/backup_dirs  --file=/opt/backup/${FILE_BACKUP}

Semplicissimo, faccio uno switch su che macchina ho chiamato da script e do al file di backup un nome di conseguenza: per la macchina windows il nome sarà qualcosa tipo smeserverAAMMGG.tgz (es.: smeserver080620.tgz), per quella ubuntu qualcosa tipo smeserverGGG.tgz (es: smeserverFri.tgz, dove Fri sta per Friday; in questo modo tra 7 giorni il file sarà sovrascritto).
Il comando tar prende in pasto il file

Code: [Select]

/opt/backup/backup_dirs, che gli dice quali directory vanno compresse nel backup e che analizzeremo in seguito.

Code: [Select]


# Monto la directory remota per salvare il file
smbmount //${PC_NAME}/${SHARE_NAME} /mnt/${PC_NAME} -o credentials=${CREDENTIALS_FILE}

I file delle credenziali sono del tipo .smbaccess<nome_macchina> e contengono le credenziali necessarie a creare una condivisione samba. Come dicevo li vedremo dopo.
La parte che segue l'ho elaborata basandomi sullo script di Hans Zoebelein

Code: [Select]


# Controllo che sulla directory remota ci sia abbastanza spazio per spostarvi il file di backup
DEVICE="//${PC_NAME}/${SHARE_NAME}"
MINFREE=`ls -l /opt/backup/${FILE_BACKUP} | awk '{print $5}'`
MAIL_TO_ME='root@localhost'
MINMB=0
ISFREE=0
MAILED=""
let MINMB=$MINFREE/1024/1024
DF="`/bin/df`"
ISFREE=`echo $DF | sed s#.\*$DEVICE" "\*[0-9]\*" "\*[0-9]\*" "\*## | sed s#" ".\*##`
if [ $ISFREE -le $MINMB ] ; then
        let ISMB=$ISFREE/1024
        echo  "WARNING: $DEVICE only $ISMB mb free. You need at least $MINMB mb free to run backup" >&2
        echo  "WARNING: $DEVICE only $ISFREE mb free. You need at least $MINFREE mb free to run backup" >&2
        echo -e "\a\a\a\a"
        echo "WARNING: $DEVICE only $ISMB mb free.
(Trigger is set to $MINMB mb)" \
        | mail -s "WARNING: $DEVICE only $ISMB mb free!" $MAIL_TO_ME
        # si possono inserire qui altre azioni come ad esempio la pulizia delle directory temporanee
else
        /bin/mv /opt/backup/${FILE_BACKUP} /mnt/${PC_NAME}/${DIRECTORY}
        # si puo' inserire qui un comando simile al precedente per mandare un'email di conferma dell'avvenuto backup
fi
smbumount /mnt/${PC_NAME}/

Quest'ultima parte di codice si occupa di controllare la grandezza del file di backup appena eseguito e di vedere se nella cartella remota in cui andrà copiato c'è abbastanza spazio: in questo modo, se non ce n'è, manderà un'email di avviso all'amministratore e si risparmierà di cominciare una copia del file che molto probabilmente fallirebbe per mancanza di spazio.
Ciò è ottenuto chiamando il comando df e cercando il nostro device remoto all'interno dell'output, poi si confronta lo spazio disponibile con l'output del comando

Code: [Select]

ls -l <file_di_backup>Volendo è possibile cambiare lo script per far sì che la copia in remoto non venga eseguita se dopo di essa rimarrebbe troppo poco spazio libero a disposizione (basta modificare $MINFREE).
root@localhost potete cambiarlo con un indirizzo email di vostro piacimento.
Infine, con smbumount chiudiamo la connessione alla macchina remota.

Con questo abbiamo terminato lo script principale, ve lo riincollo intero qua sotto per comodità:

Code: [Select]

#!/bin/sh

# Variabili di connessione al netowrk
PC_NAME=$1
SHARE_NAME="share
DIRECTORY="backupdir"
CREDENTIALS_FILE="/root/.smbaccess${PC_NAME}"

# Creo il file di backup
case "${PC_NAME}" in
        "windows")
                        FILE_BACKUP="smeserver_$(date +%y_%m_%d).tgz";;
        "ubuntu")
                        FILE_BACKUP="smeserver_$(date +%w_%a).tgz";;
esac
/sbin/e-smith/signal-event pre-backup
/bin/tar -z --directory / --create --files-from /opt/backup/backup_dirs  --file=/opt/backup/${FILE_BACKUP}
# Monto la directory remota per salvare il file
smbmount //${PC_NAME}/${SHARE_NAME} /mnt/${PC_NAME} -o credentials=${CREDENTIALS_FILE}

# Controllo che sulla directory remota ci sia abbastanza spazio per spostarvi il file di backup
DEVICE="//${PC_NAME}/${SHARE_NAME}"
MINFREE=`ls -l /opt/backup/${FILE_BACKUP} | awk '{print $5}'`
MAIL_TO_ME='root@localhost'
MINMB=0
ISFREE=0
MAILED=""
let MINMB=$MINFREE/1024/1024
DF="`/bin/df`"
ISFREE=`echo $DF | sed s#.\*$DEVICE" "\*[0-9]\*" "\*[0-9]\*" "\*## | sed s#" ".\*##`
if [ $ISFREE -le $MINMB ] ; then
        let ISMB=$ISFREE/1024
        echo  "WARNING: $DEVICE only $ISMB mb free. You need at least $MINMB mb free to run backup" >&2
        echo  "WARNING: $DEVICE only $ISFREE mb free. You need at least $MINFREE mb free to run backup" >&2
        echo -e "\a\a\a\a"
        echo "WARNING: $DEVICE only $ISMB mb free.
(Trigger is set to $MINMB mb)" \
        | mail -s "WARNING: $DEVICE only $ISMB mb free!" $MAIL_TO_ME
        # si possono inserire qui altre azioni come ad esempio la pulizia delle directory temporanee
else
        /bin/mv /opt/backup/${FILE_BACKUP} /mnt/${PC_NAME}/${DIRECTORY}
        # volendo qui si puo' inserire un comando simile al precedente per mandare un'email di conferma dell'avvenuto backup
fi
smbumount /mnt/${PC_NAME}/

Per farlo funzionare sul vostro Server SME, dovete necessariamente modificare i seguenti parametri:
SHARE_NAME : il nome della vostra condivisione windows / linux samba (e.g.: "backups")
DIRECTORY : la cartella in cui finirà il backup (e.g.: "SME Server")
"windows" : il nome di rete della macchina per il backup incrementale
"ubuntu" : il nome di rete della macchina per il backup a rotazione settimanale
MAIL_TO_ME : non è obbligatorio cambiarlo, ma vi consiglio di usare un indirizzo email esterno al server

Passiamo ora a backup_dirs: create sulla directory opt/backup del Server SME un file con quel nome ed editatelo mettendoci dentro tutte le cartelle da backuppare:

Code: [Select]

home/e-smith
etc/e-smith/templates-custom
etc/e-smith/templates-user-custom
etc/passwd
etc/shadow
etc/group
etc/gshadow
etc/samba/secrets.tdb
etc/samba/smbpasswd
etc/smbpasswd
etc/sudoers
etc/ssh
root

Mi raccomando una directory per riga.
Volendo è possibile creare un file simile di directory da NON backuppare, e inserirlo all'interno del comando tar con l'opzione

Code: [Select]

--exclude-from FILE (es.: --exlude-from /opt/backup/no_backup_dir).
Può essere un'opzione interessante per tutte quelle cartelle il cui contenuto sapete non cambiare mai, in modo da risparmiare tempo e spazio sul backup (anche se poi in fase di un eventuale restore ci sarà da lavorare un po' di più, vedete voi se il gioco anzi il giuoco vale la candela).

Infine ci sono i vari /root/.smbaccess<nome_macchina> (uno per ogni macchina remota su cui finiranno i backup).
Createli nella cartella root (in modo da impedire a chicchessia di leggere i vostri login/password di rete) ed editateli come segue:

Code: [Select]

username=utente_di_rete_su_questa_macchina
password=password_di_rete_su_questa_macchina

Mi raccomando di andare a capo tra username e password.
Per un'ipotetica macchina 'pirlo' in cui avete creato una condivisione per l'utente 'andrea' con password 'beccatevi_sto_gol', dovrete creare sul Server SME il file /root/.smbaccesspirlo editandolo come segue:

Code: [Select]

username=andrea
password=beccatevi_sto_gol

Con questo gli script del backup sono terminati.

Faccio alcune precisazioni.
Se non c'è abbastanza spazio su disco, viene inviata l'email di avviso e il backup rimane nella cartella /opt/backup, questo per permettervi di spostarlo in remoto una volta liberato lo spazio. Attenzione però, perché potrebbe riempirvisi il disco rigido dello SME Server (per esempio voi andate in vacanza un mese e sul disco del portatile avete 100 mega liberi, immaginatevi cosa succede). Il problema non è tanto il backup a rotazione settimanale, che si auto sovrascrive, quanto quello incrementale.
Quindi volendo si può inserire un controllo nello script che evita di creare il file se c'è poco spazio disponibile (chiaramente voi non potete sapere a priori quanto sarà grande il backup, se non approssimativamente). Alternativamente, se sul server SME avete solo le ibay e poco altro, potete controllare lo spazio correntemente usato, e stabilire che ve ne deve essere altrettanto libero (è un metodo grossolano, dal momento che con la compressione il backup sarà certamente più piccolo, ma almeno funziona quasi sempre).
Un'altra soluzione, sicuramente più solida (ma potenzialmente vi farà perdere più tempo) è quella di dire allo script di cancellare il file di backup se la copia in remoto non va a buon fine. L'eventuale stringa va inserita in quel pezzo di codice dove c'è il commento:

Code: [Select]

# inserire altre azioni qui come ad esempio la pulizia delle directory temporaneeIn questo caso, quando vi accorgerete della mancata effettuazione del backup, dovrete procedere manualmente a rilanciare il backup da shell.
Nel caso in cui andiate in vacanza per 30 giorni con 100 mega di spazio liberi, non intaserete il vostro server SME, ma in compenso non avrete nessun backup degli ultimi 30 giorni.
Vedete voi.

Bene, con il backup abbiamo finito. Adesso ci resta solo da automatizzarlo.

3) automazione dello script con cron.

Create un file /etc/e-smith/templates-custom/etc/crontab/backup_sme ed editatelo come segue:

Code: [Select]

# backup giornaliero incrementale dei dati del server
30     12     *     *     1-6        root       /opt/backup/run_backup.sh derossi

# backup giornaliero settimanale dei dati del server
30     0     *     *     1-7        root       /opt/backup/run_backup.sh pirlo

'derossi' è il portatile windows con masterizzatore dvd, 'pirlo' la workstation ubuntu per backup a rotazione settimanale.
Come avete notato, il primo backup viene eseguito alle 12:30 solo da lunedì a sabato (1-6) mentre il secondo alle 00:30 anche la domenica (1-7).

Ora espandiamo la template così creata tramite il seguente comando da shell:

Code: [Select]

/sbin/e-smith/expand-template etc/crontab

Et voilà.
Federico

PS: è il mio primo post di questo tipo quindi spero di non essermi dimenticato niente!

[Stefano]

Ciao

solo per farti i complimenti per il post..

l'unica cosa che aggiungerei, dopo la creazione del tar gzippato è la verifica dello stesso (se non ricordo male flag -d di tar..)

ma va bene anche così

Stefano

[Lord Quicksilver]

Ciao intanto grazie.
Dunque per quanto riguarda il compare, non mi ero posto il problema perché pensavo che fosse eseguito automaticamente in qualche modo quando lanciavo il mio vecchio script che usava smbclient, in quanto mi è capitato più di una volta che mi giungesse dal cron daemon una tra queste due email:

Code: [Select]

/bin/tar: home/e-smith/files/ibays/ibay_mia/file/~file_mio.doc: Cannot stat: No such file or directory
/bin/tar: Error exit delayed from previous errors

oppure:

Code: [Select]

/bin/tar: home/e-smith/files/ibays/ibay_mia/file/~file_mio.doc: file changed as we read it
/bin/tar: Error exit delayed from previous errors

Pensavo che questo fosse il risultato di una comparazione che viene eseguita non so bene perché né da chi. Suppongo non da Cron, visto che non ne vedo il motivo, quindi probabilmente da Samba: su Google non ho trovato  una risposta definitiva, in compenso è un errore molto diffuso tra gli utenti di tar.

Email di questo tipo me ne arrivano spesso, e in quel caso l'archivio backup risulta spesso essere incompleto (ma non sempre! Lo vedo facilmente dal size del file), quindi l'unica cosa che mi rimane da fare è lanciare di nuovo il backup manualmente da shell.

Ora, è ovvio che l'errore dipende da azioni (scrittura - cancellazione) che i miei dipendenti eseguono sui file che vengono backuppati durante il backup, ed è poco realistico pensare di dire loro di non lavorare mentre è in corso il backup delle 12:30...

Ciao
Federico