Il blog sull'informatica

Sulla falsariga dello script per il backup automatico di un database, ho deciso di crearne uno che effettua periodicamente il backup di un sito Web (un pò come avviene con gli hosting provider).

Ecco il codice:

#!/bin/bash

datasito=$(date +"%d_%b_%y")

montaggiosito=$(mount | grep /media/disk)

#File di log
FILELOG=/var/log/backupmiosito

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

ERRORE1="Errore 1: Devi essere root per eseguire lo script"
echo $ERRORE1
echo "$(date) $ERRORE1" >> $FILELOG

exit 1

fi


if [ ! -n "$montaggiosito"  ]; then

mount /media/disk

fi

if [ ! -d /media/disk/backup/miosito ]; then

cd /media/disk

mkdir /media/disk/backup/miosito

fi

cd /media/disk/backup/miosito

mkdir backup_$datasito

cp -r /var/www/miosito /media/disk/backup/miosito/backup_$datasito

exit 0

Come potete notare, tale script si differenzia da quello per il backup del database sono nelle ultime righe (e per qualche nome assegnato alle variabili). Nella fattispecie, il comando cp -r /var/www/miosito /media/disk/backup/miosito/backup_$datasito non fa altro che copiare tutto il contenuto della directory /var/www/miosito (comprese le sottodirectory, grazie alla flag -r) in /media/disk/backup/miosito/backup_$datasito.

Rendo eseguibile lo script, digitando sudo chmod +x backupsito e successivamente lo copio nella cartella /usr/bin mediante il comando sudo cp /backupsito /usr/bin.

Ora, tale script può essere eseguito ad intervalli di tempo regolari, semplicemente inserendo la seguente istruzione nel file crontab presente nella directory /etc:

0 21   * * *   root    backupsito > /dev/null 2>&1

ed il gioco è fatto.

See ya.

Ormai è risaputo di quanto siano sicure alcune distribuzioni *nix, tra cui la celeberrima FreeBSD (un solo exploit da remoto in 10 anni). Eppure vi sono tante altre distribuzioni che non fanno della sicurezza il loro obiettivo primario. Tra queste vi è certamente DVL (Damn Vulnerable Linux - un nome una garanzia), appositamente forgiata per presentare numerosissime falle di sicurezza ed aiutare gli aspiranti "security consultant" durante la loro formazione. Effettivamente l'idea non è male, in quanto tale distribuzione potrebbe anche essere utilizzata come passatempo, per "testare" l'effetto dei vari exploit sui bug presenti.

Ovviamente trattasi di bug arcinoti e piuttosto datati, per cui le ultime versioni dei software dovrebbero esserne immuni (almeno spero). Comunque, bando alle ciance ed enjoy: http://www.damnvulnerablelinux.org/

Dovendo gestire diversi database su più server ho avuto la necessità di creare uno scriptino che automatizzasse la creazione dei loro backup. Riporto quindi lo script per intero e successivamente provvederò a spiegare le varie sezioni del codice, anche se a primo acchito tutto dovrebbe apparire piuttosto chiaro.

#!/bin/bash

data=$(date +"%d_%b_%y")

montaggio=$(mount | grep /media/disk)

#File di log
FILELOG=/var/log/backup

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

ERRORE1="Errore 1: Devi essere root per eseguire lo script"
echo $ERRORE1
echo "$(date) $ERRORE1" >> $FILELOG

exit 1

fi


if [ ! -n "$montaggio"  ]; then

mount /media/disk

fi

if [ ! -d /media/disk/backup/ ]; then

cd /media/disk

mkdir /media/disk/backup

fi

cd /media/disk/backup

mysqldump nomedatabase -u username -pvostrapassword > database_$data.pl

exit 0

Per prima cosa salvo all'interno della variabile "data" l'output del comando date formattato nel seguente modo:

giorno_prime 3 lettere del mese (in inglese)_anno

successivamente definisco all'interno della variabile FILELOG il pathname relativo al file su cui verranno loggati i vari messaggi di errore dello script, in questo caso /var/log/backup. Dopodichè mi accerto che lo script venga eseguito da root, poichè lo stesso verrà dato in pasto a cron per essere eseguito con tali privilegi.

A questo punto verifico che l'hard disk secondario sia montato, eseguendo il comando:

mount | grep /media/disk

Se tale comando restituisce una stringa vuota eseguo il mount dell'hard disk secondario e successivamente mi posiziono in /media/disk.

Ora devo verificare che la cartalla backup sia presente in /media/disk. Se non lo è provvedo a crearla (in realtà tale operazione verrà effettuata soltanto durante la prima esecuzione dello script).

Bene, posso quindi posizionarmi in /media/disk/backup e successivamente effettuare il dump del database mediante il comando mysqldump. Notate che tra la flag -p e la password per accedere al database non vi sono spazi. Inoltre, il dump verrà salvato in un file il cui nome è costituito dalla stringa database_dataattuale.pl, ad esempio:

database_01_Jul_01.pl

Abbiamo quasi finito, non ci resta che creare un binario criptato (RC4) partendo dal nostro script, poichè quest'ultimo contiene diverse informazioni critiche, quali, ad esempio, username e password di accesso al database.

Per fare ciò possiamo utilizzare una semplice applicazione, ovvero shc (il sito ufficiale è il seguente: http://www.datsi.fi.upm.es/~frosal/)

Scarichiamo tale applicazione tramite wget:

wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.7.tgz

Scompattiamo la tarball:

tar -xvf shc-3.8.7.tgz

e posizioniamoci nella cartella tar -xvf shc-3.8.7:

cd shc-3.8.7/

Lanciamo il make:

make

Dopodichè facciamo un test per verificare che tale operazione sia andata a buon fine:

make test

Se non ci sono errori dovremmo vedere lo script shc presente nella dir shc-3.8.7

Ora trasformiamo il nostro script per il backup in eseguibile mediante il comando:

./shc -f /home/nomeutente/database

dove database è il nome del nostro script.

Se non ci sono problemi di sorta dovremmo ritrovarci i seguenti 2 file nella nostra home:

database.x e database.x.c

Copiamo ora database.x nella dir /usr/bin/

sudo cp database.x /usr/bin

Infine, mediante cron, scheduliamo l'esecuzione di database.x alle 20 e 30 di ogni sera:

sudo nano /etc/crontab

30 20   * * *   root    backupdb.x > /dev/null 2>&1

redirigendo lo standard output e lo standard error su /dev/null.

Il nostro script per il backup giornaliero dei database è finalmente pronto.

See ya.

PS: ovviamente se abbiamo a che fare con database di grandi dimensioni eseguire un backup giornaliero è sconsigliato, sarebbe meglio eseguire backup settimanali o mensili.

PPS: inutile dire che tale script supporta solo MySQL.