Il blog sull'informatica

Qualche giorno fa mi è capitato di dover effettuare il backup di un sito Web senza conoscere le credenziali FTP. Fortunatamente si trattava di un sito sprovvisto di codice lato server, quindi per me è stato piuttosto semplice salvarne una copia in locale.

Per fare tale operazione ho utilizzato il mitico wget, ed in particolare il comando:

nightfly@nightbox:~$ wget -r www.siteexample.it

Tutto il contenuto del sito è stato automaticamente salvato nella directory www.siteexample.it.

Devo ammettere però che ho avuto un po' di fortuna. Infatti, non tutti i server Web consentono liberamente il dump dei loro siti (il termine phishing vi dice qualcosa?). Proprio per impedire tale pratica, molto spesso viene implementato un meccanismo di protezione basato sul riconoscimento del client Web: nel caso in cui il server si accorgesse che è wget a richiedere le pagine del sito, risponderà picche.

Tale controllo risulta comunque facilmente aggirabile. Infatti wget consente lo spoofing del client, che può essere impostato manualmente digitando:

nightfly@nightbox:~$ wget -r -U "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" www.siteexample.it

Invece, nel caso in cui i controlli si basassero anche sui tempi che intercorrono tra la visualizzazione di una pagina e quella successiva, oppure sulla velocità di download delle stesse, basterà utilizzare correttamente le flag --wait e --limit-rate:

nightfly@nightbox:~$ wget --wait=30 --limit-rate=10K -r -U "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" www.siteexample.it

Ed il backup del sito è pronto.

A presto.

Chi è del mestiere sa che i backup sono di fondamentale importanza, soprattutto quando riguardano dati piuttosto sensibili. Affidare tale operazione agli utenti (anche se si tratta di piccoli ambienti) è sconsigliabile. Ho dunque pensato di creare il seguente script (per reti SOHO) che "zippa" la directory Documenti e la invia, tramite FTP, ad un server interno.

Ovviamente tale script può essere ulteriormente migliorato, se avete dei suggerimenti contattatemi.

Ecco il codice:

set mese=%DATE:~3,2%
set giorno=%DATE:~0,2%
set anno=%DATE:~-4%
set comfile="com.txt"

zip Documenti_PC1_%giorno%_%mese%_%anno% "C:UsersnomeutenteDocuments"
cd "C:Usersvostroutente"

echo username> %comfile%
echo password>> %comfile%
echo put Documenti_PC1_%giorno%_%mese%_%anno%.zip>> %comfile%
echo quit>> %comfile%

ftp -i -s:"com.txt" <indirizzo IP server>

Lo script, da posizionare nella directory di ciascun utente, scrive i dati per la connessione al server FTP ed i relativi comandi su un file, che ho chiamato com.txt. Tale informazioni vengono infine date in pasto al comando ftp, da utilizzarsi con le flag -i (per non visualizzare i prompt interattivi) e -s (che consente di specificare il file sorgente dei comandi). Ovviamente anche il file com.txt deve trovarsi all'interno della directory utente.

Per la precisione, il file com.txt ci apparirà nel modo seguente:

username
password
put Documenti_PC1_29_09_2011.zip
quit

Ora, la realtà nella quale tale script dovrà lavorare è caratterizzata dalla presenza di un solo utente per PC, quindi è stato piuttosto semplice gestire i vari backup. Per ambienti un pò più complessi dovranno essere apportate sicuramente delle modifiche al codice.

Fatene buon uso.

A presto.

PS: per "zippare" la directory ho utilizzato la suite gratuita Info-ZIP, il cui file zip.exe è stato copiato nella dir di ciascun utente.

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.