{"id":4,"date":"2008-02-24T17:50:18","date_gmt":"2008-02-24T16:50:18","guid":{"rendered":"http:\/\/www.zarrelli.org\/blog\/index.php\/2008\/02\/24\/backup-in-rete-pratico-e-veloce-con-ftp-2\/"},"modified":"2008-02-24T17:51:53","modified_gmt":"2008-02-24T16:51:53","slug":"backup-in-rete-pratico-e-veloce-con-ftp-2","status":"publish","type":"post","link":"https:\/\/www.zarrelli.org\/blog\/backup-in-rete-pratico-e-veloce-con-ftp-2\/","title":{"rendered":"Backup in rete pratico e veloce con FTP – 2"},"content":{"rendered":"

Dopo quasi, ahem, un anno di stasi, vediamo di chiudere l’agomento inziato con il primo post Backup in rete pratico e veloce con FTP -1<\/a>, passando alla parte pi\u00f9 “operativa”.<\/p>\n

backup_tape.jpg<\/p>\n

Vediamo, qui di seguito, un semplice shell script che si occupa di creare un backup all’interno di un file tgz, che avr\u00e0 come prefisso la data del giorno di archiviazione. Creato il file, provveder\u00e0 a trasferirlo via ftp sulla macchina d’appoggio, e infine canceller\u00e0 l’archivio il cui suffisso sar\u00e0 costituito dalla data odierna – 15 giorni.<\/p>\n

Prima di procedere, per\u00f2, un avvertimento: questo post \u00e8 decisamente lungo e, per qualche verso, anche noioso. <\/p>\n

Non dite che non vi avevo avvisati \ud83d\ude42<\/p>\n

<\/p>\n

Rendere uno script portabile e flessibile, l’intestazione<\/strong><\/p>\n

A cosa serve uno script? Beh, semplicemente, banalizzando, a rendere semplici e veloci operazioni ripetitive, a sollevare l’utente da una routine che non richiede una particolare attenzione.<\/p>\n

Ci\u00f2 vale anche per lo script stesso. Ovvero, non deve solo rendere semplici le altre operazioni, ma deve semplificare al tempo stesso la sua gestione. Uno programma, per quanto piccolo, che dia luogo a malfunzionamenti appena lo si tocchi o sposti, oppure che sia difficile da modificare a seconda delle esigenze contingenti, non assolve pienamente agli scopi cui canonicamente \u00e8 deputato.<\/p>\n

Allora, come rendere semplice la gestione di uno script?<\/p>\n

In prima battuta, possiamo pensare a due potenziali scenari problematici:<\/p>\n

    \n
  1. \n Lo script, che \u00e8 sempre andato bene, deve essere modificato, magari, nel nostro caso, per includere nuove directory o per escluderne altre, per modificare la denominazione dei file di archivio, oppure per modificare l’arco di ritenzione dei backup sul server FTP remoto su cui appoggeremo i file compressi;<\/p>\n<\/li>\n
  2. \nLo script, che \u00e8 sempre andato bene, deve essere spostato su una differente distribuzione Linux o su una variante Unix, nella quale le utility di sistema sono poste in posizioni differenti nell’albero delle directory.\n<\/li>\n<\/ol>\n

    Nel primo caso, saremo costretti a scorrere tutto il file alla ricerca di ogni evenienza della porzione da modificare, mentre i pi\u00f9 esperti dovranno evocare arcane stringhe composte da sed, awk e cut.<\/p>\n

    Nel secondo caso, bisogner\u00e0 scorrere tutto il programma, cercare il riferimento al percorso delle utility impiegate, confrontarlo con il percorso delle stesse nel nuovo sistema e apportare le modifiche del caso.<\/p>\n

    Operazioni scomode entrambe, non vi pare? Scomode e portano via parecchio tempo, prone come sono agli errori.<\/p>\n

    Meglio ricorrere a un espediente del tutto lecito e semplice da utilizzare, ovvero creare
    \nun’intestazione allo script, ovvero una parte iniziale completamente parametrizzata, grazie alla quale ogni elemento modificabile sar\u00e0 racchiuso in una variabile, che verr\u00e0 poi richiamata al momento opportuno, nella parte elaborativa del programma. Per cambiare quindi un valore, baster\u00e0 modificare il contenuto della variabile cui \u00e8 associato e quindi la modifica verr\u00e0 riflessa in ogni punto dello script in cui la variabile stessa verr\u00e0 richiamata. Semplice, efficace, pulito.<\/p>\n

    Il secondo espediente cui ricorreremo \u00e8 definito comunemente “sostituzione di comando”, ovvero si istanzia una variabile non tanto con un valore predefinito, quanto con il risultato di un comando da eseguire. Vedremo in seguito pi\u00f9 dettagliatamente di cosa si tratta, baster\u00e0 ora un esempio schematico.<\/p>\n

    Volendo richiamare il comando tar<\/code>, lo si pu\u00f2 indicare per esteso, per esempio <\/p>\n


    \n\/bin\/tar
    \n<\/code><\/p>\n

    In questo caso, non ci sono particolari note da rilevare. Lo script richiamer\u00e0 il programma semplicemente seguendo il percorso indicato.<\/p>\n

    Piccolo, grande problema: se lo script viene spostato su un sistema in cui l’utility tar si trova in un percorso differente, il programma non eseguir\u00e0 l’utility indicata, dato che il percorso non porter\u00e0 a nulla di utilizzabile. Se, per\u00f2, invece di utilizzare una indicazione statica si chiede a un’utility di sistema di trovare tutte le altre, il punto di fallimento viene ridotto all’unico primo programma richiamato “alla cieca”. Facciamo un esempio<\/p>\n


    \nTAR=$(which tar)
    \n<\/code><\/p>\n

    In questo caso, abbiamo chiesto all'utility <\/code>which<\/code> di trovare il percorso dell’utility tar<\/code> e abbiamo assegnato il percorso stesso alla variabile TAR<\/code>. In questo modo, dovremo fare attenzione unicamente al fatto che which sia richiamabile direttamente dall’ambiente legato all’account utilizzato per eseguire lo script (ovvero che il suo percorso sia compreso nella variabile d’ambiente PATH<\/code>). Accertato ci\u00f2, baster\u00f2 richiamare il contenuto della variabile TAR<\/code> per eseguire il comando rintracciabile al percorso assegnato.<\/p>\n

    Torneremo sull’argomento pi\u00f9 avanti, non vi preoccupate.<\/p>\n

    Lo script di backup<\/strong><\/p>\n

    Un po’ di attenzione, non \u00e8 difficile. Prima vediamo lo script al completo, poi esamineremo le varie parti interessanti.<\/p>\n


    \n#!\/bin\/sh<\/p>\n

    RM=$(which rm)
    \nTAR=$(which tar)
    \nTAR_OPTS=\"cvzf\"
    \nTAR_REMOVE=\"--remove-files -cvzf\"
    \nFTP=$(which ftp)
    \nFIND=$(which find)
    \nECHO=$(which echo)
    \nDATA=$(which date)
    \nDATE=$($DATA +%F)
    \nRM_DATE=$(date --date='15 days ago' +'%Y-%m-%d')<\/p>\n

    ARCHIVE=\"$DATE-nome-del-server.backup.tgz\"
    \nARCHIVE_MYSQL=\"$DATE-mysql.nome-del-server.com.backup.tgz\"
    \nBACKUP_SPOOL=\"\/var\/spool\/backup\"
    \nBACKUP_DIR=\"\/usr\/local\/apache \/usr\/local\/mysql\/ \/var\/mysql \/var\/lib\/awstats \/etc\/ $BACKUP_SPOOL\/$MYSQL_BACKUP_FILE\"
    \nBACKUP_EXCLUDE_DIR=\"\/usr\/local\/apache\/tmp\/ \/usr\/local\/apache\/htdocs\/data\/videos\/ \/var\/spool\/backup \/etc\/passwd \/etc\/shadow\"<\/p>\n

    BACKUP_MACRO=\"backup\"<\/p>\n

    MYSQL_DUMP=$(which mysqldump)<\/p>\n

    MYSQL_OPTS=\"--socket=\/usr\/local\/apache\/mysql.sock\/mysql.sock --all-databases --user=nome_utente --password=password_di_accesso\"
    \nMYSQL_BACKUP_FILE=\"$DATE-mysql.nome-del-server.com.backup.sql\"
    \nSERVER=\"indirizzo-del-server-di-appoggio\"<\/p>\n

    $MYSQL_DUMP $MYSQL_OPTS > $BACKUP_SPOOL\/$MYSQL_BACKUP_FILE<\/p>\n

    $TAR $TAR_REMOVE $BACKUP_SPOOL\/$ARCHIVE_MYSQL $BACKUP_SPOOL\/$MYSQL_BACKUP_FILE<\/p>\n

    $FIND $BACKUP_EXCLUDE_DIR > $BACKUP_SPOOL\/IGNORE.LST<\/p>\n

    $TAR $TAR_OPTS $BACKUP_SPOOL\/$ARCHIVE -X $BACKUP_SPOOL\/IGNORE.LST $BACKUP_DIR<\/p>\n

    $ECHO \"\\$ $BACKUP_MACRO $RM_DATE\" | $FTP $SERVER<\/p>\n

    $RM $BACKUP_SPOOL\/$ARCHIVE $BACKUP_SPOOL\/$ARCHIVE_MYSQL
    \n<\/code><\/p>\n

    Complicato? No, sembra esserlo ma \u00e8 pi\u00f9 semplice di quanto non si immagini.<\/p>\n

    Diamo un'occhiata pi\u00f9 da vicino ad alcune delle prime righe, esclusa la sha-bang, ovvero a quelle che ci consentiranno di creare i nomi dei file di backup, in modo che racchiudano la data in cui gli archivi sono stati creati:<\/p>\n

    <\/code>
    \nDATA=$(which date)
    \nDATE=$($DATA +%F)
    \nRM_DATE=$(date --date='15 days ago' +'%Y-%m-%d')
    \nARCHIVE=\"$DATE-nome-del-server.backup.tgz\"
    \nARCHIVE_MYSQL=\"$DATE-mysql.nome-del-server.com.backup.tgz\"
    \n<\/code><\/p>\n

    Come primo accorgimento, eseguiamo una sostituzione di comando<\/strong>. In pratica, la variabile DATA<\/code> viene istanziata con l’output del comando which date<\/code>.<\/p>\n

    Cosa significa tutto ci\u00f2? Facciamo ricorso alla shell e vediamo cosa succede. Iniziamo con l’eseguire il comando which date<\/code>:<\/p>\n


    \nzarrelli@moveaway:~$ which date
    \n\/bin\/date
    \nzarrelli@moveaway:~$
    \n<\/code><\/p>\n

    Semplicemente, which restituisce il percorso al comando che gli si fornisce come argomento, sempre che il comando sia all'interno di una delle directory indicate nella variabile d'ambiente <\/code>PATH<\/code> correlata all’utente che ha lanciato il comando which<\/code>.<\/p>\n

    Controprova:<\/p>\n


    \nzarrelli@moveaway:~$ echo $PATH
    \n\/usr\/local\/sbin:\/usr\/local\/bin:\/usr\/sbin:\/usr\/bin:\/sbin:\/bin:\/usr\/games
    \nzarrelli@moveaway:~$
    \n<\/code><\/p>\n

    oppure:<\/p>\n


    \nzarrelli@moveaway:~$ env | grep PATH
    \nPATH=\/usr\/local\/sbin:\/usr\/local\/bin:\/usr\/sbin:\/usr\/bin:\/sbin:\/bin:\/usr\/games
    \nzarrelli@moveaway:~$
    \n<\/code><\/p>\n

    Perch\u00e9 utilizzare una sostituzione di comando? Perch\u00e9 in questo modo avremo degli script portabili. Ovvero, posto che si utilizzino delle utility di sistema, anche se queste, a seconda delle distribuzioni utilizzate, o delle varianti Unix adottate, si trovano in un percorsi differenti da quelli in cui risiedono all’interno del sistema utilizzato per creare lo script, la sostituzione di variabile rende sempre possibile invocarle, senza preoccuparsi di dove siano localizzate nel file system.<\/p>\n

    Fatto salvo che, ovviamente, l’utility puntata dalla sostituzione di variabile sia in un percorso compreso all’interno della variabile PATH<\/code>, ma ci\u00f2 \u00e8 verificato nel momento in cui si utilizzino utility di sistema e ambienti variabili di sistema predefinite.<\/p>\n

    Quindi, la variabile DATA<\/code> conterr\u00e0 il percorso all’utility date, ovunque essa si trovi, all’interno delle directory comprese nella variabile PATH<\/code>.<\/p>\n

    Ora che abbiamo la possibilit\u00e0 di richiamare facilmente il comando date<\/code>, istanziamo una variabile DATE<\/code> con il valore restituito ($) dall’utility di sistema date<\/code>, la quale a sua volta mostrer\u00e0 la data di sistema, formattandone l’output nel formato numerico anno-mese-giorno, grazie all’utilizzo del modificatore +%F. Tanto per intenderci<\/p>\n


    \nzarrelli@moveaway:~$ date +%F
    \n2008-02-23
    \nzarrelli@moveaway:~$#
    \n<\/code><\/p>\n

    potrebbe essere interessante, come potreste trovare pi\u00f9 piacevole un<\/p>\n


    \nzarrelli@moveaway:~$ date +%A.%d.%B.%Y
    \nsabato.23.febbraio.2008
    \nzarrelli@moveaway:~$
    \n<\/code><\/p>\n

    Rimane a voi giocare con i modificatori del comando date (man date per consultare il manuale in linea) e trovare la soluzione con la quale vi sentite pi\u00f9 a vostro agio.<\/p>\n

    Ovviamente, al posto di richiamare direttamente l’utility date<\/code>, baster\u00e0 recuperare il valore della variabile DATA<\/code> (ovvero il percorso all’utility date<\/code>) anteponendole il segno di dollaro, e passandole il modificatore. <\/p>\n


    \nDATE=$($DATA +%F)
    \n<\/code><\/p>\n

    Quindi, DATE<\/code> avr\u00e0 come valore l’output del comando \/bin\/date +%F.<\/p>\n

    La seconda riga ha un significato molto simile. Solamente, in questo caso date \u00e8 forzato a mostrare la data di 15 giorni precedenti alla data corrente (–date=’15 days ago’), formattandone l’output nel formato numerico anno-mese-giorno. Da notare che i due modificatori +%F e +’%Y-%m-%d’, sono equivalenti.<\/p>\n

    Nelle due righe seguenti, semplicemente diamo forma ai nomi di due file:<\/p>\n

      \n
    1. \nuno, assegnato alla variabile ARCHIVE<\/code>, verr\u00e0 utilizzato per contenere il backup del file system\n<\/li>\n
    2. \nl’altro, assegnato alla variabile ARCHIVE_MYSQL<\/code>, racchiuder\u00e0 il dump del database MySQL.\n<\/li>\n<\/ol>\n

      Da notate che il nome di ognuno \u00e8 creato preponendo a una parte fissa il contenuto della variabile DATE<\/code>: in questo modo, ogni giorno verranno creati due file i cui nomi rimanderanno direttamente alla data di creazione, rendendoli facilmente riconoscibili.<\/p>\n

      Continuiamo con il seguente blocco di variabili<\/p>\n


      \nBACKUP_SPOOL=\"\/var\/spool\/backup\"
      \nBACKUP_DIR=\"\/usr\/local\/apache \/usr\/local\/mysql\/ \/var\/mysql \/var\/lib\/awstats \/etc\/ $BACKUP_SPOOL\/$MYSQL_BACKUP_FILE\"
      \nBACKUP_EXCLUDE_DIR=\"\/usr\/local\/apache\/tmp\/ \/usr\/local\/apache\/htdocs\/data\/videos\/ \/var\/spool\/backup \/etc\/passwd \/etc\/shadow\"
      \n<\/code><\/p>\n

      La prima riga indica una variabile nella quale viene conservato il valore del percorso a una directory di spool, ovvero la directory nella quale verranno conservati gli archivi contenenti i backup.<\/p>\n

      La seconda riga contiene l’elenco delle directory da sottoporre all’utility di backup. Da notare che uno dei percorsi non \u00e8 indicato direttamente, ma richiamando i valori delle variabili BACKUP_SPOOL<\/code> e MYSQL_BACKUP_FILE<\/code>, concatenandoli e frapponendo una slash (\/<\/code>). Espandendo le variabili concatenate <\/p>\n


      \n$BACKUP_SPOOL\/$MYSQL_BACKUP_FILE
      \n<\/code><\/p>\n

      si avr\u00e0 quindi l’indirizzo:<\/p>\n


      \n\/var\/spool\/backup\/$DATE-mysql.nome-del-server.com.backup.sql
      \n<\/code><\/p>\n

      In pratica, interpretando la riga, si pu\u00f2 facilmente comprendere che nel backup totale di tutti i file si vuole includere espressamente anche il dump giornaliero del database MySQL. Quello e solo quello, anche se ve ne fossero di precedenti nella stessa directory \/var\/spool\/backup<\/code>.<\/p>\n

      La terza indica di quali directory e file non si vuole avere una copia.<\/p>\n

      In effetti, \u00e8 inutile avere una copia delle varie tmp, spool il cui contenuto \u00e8 per s\u00e9 temporaneo, di directory “pesanti”, magari contenenti video di famiglia che si possono facilmente recuperare a casa, ma che incrementerebbero notevolmente la dimensione file di backup.<\/p>\n

      Ragionamento un po’ piu’ complesso per passwd e shadow: in un file di backup in chiaro che passa per un protocollo non criptato, meglio non infilare dati sensibili, a meno di crittare direttamente l’archivio creato, prima di trasferirlo.<\/p>\n

      Ora, \u00e8 il momento del terzultimo blocco di variabili:<\/p>\n


      \nBACKUP_MACRO=\"backup\"
      \nRM=$(which rm)
      \nTAR=$(which tar)
      \nTAR_OPTS=\"cvzf\"
      \nTAR_REMOVE=\"--remove-files -cvzf\"
      \nFTP=$(which ftp)
      \nFIND=$(which find)
      \nECHO=$(which echo)
      \n<\/code><\/p>\n

      BACKUP_MACRO<\/code> viene utilizzata per contenere il nome della macro che andremo a definire a livello di client FTP, il che ci consentir\u00e0 di automatizzare il trasferimento dei dati. Non andiamo oltre, per ora, approfondiremo l’argomento fra poco.<\/p>\n

      Il resto \u00e8 composto da sostituzioni di comando, cui si affiancano variabili che contengono le opzioni da passare ad alcuni di questi comandi. Attenzione. A volte conviene inglobare le opzioni nella stessa variabile che contiene il comando stesso, come in DATE<\/code>, altre volte, specialmente quando la stessa utility debba essere utilizzata in modi differenti, come TAR<\/code>, \u00e8 pi\u00f9 utile separare le opzioni dall’eseguibile, per poter comporre pi\u00f9 facilmente differenti righe di comando.<\/p>\n

      Penultimo blocco di intestazione:<\/p>\n


      \nMYSQL_DUMP=$(which mysqldump)
      \nMYSQL_OPTS=\"--socket=\/usr\/local\/apache\/mysql.sock\/mysql.sock --all-databases --user=nome_utente --password=password_di_accesso\"
      \nMYSQL_BACKUP_FILE=\"$DATE-mysql.nome-del-server.com.backup.sql\"
      \n<\/code><\/p>\n

      Beh, a questo punto dovrebbe esservi chiaro cosa si intende fare. Si recupera il percorso all’utility necessaria a creare il dump dei database contenuti in MySQL, si predispongono le opzioni necessarie per accedere al server db (da notare che in questo caso, essendo il server MySQL in locale, si indica una bella socket a file, tanto per andare pi\u00f9 veloci, altrimenti si pu\u00f2 indicare l’indirizzo IP corrispondente). Infine si predispone un file in cui riversare il dump del database, intestandolo con la data in cui questo verr\u00e0 creato.<\/p>\n

      Ultima informazione contenuta nell’intestazione:<\/p>\n


      \nSERVER=\"indirizzo-del-server-di-appoggio\"
      \n<\/code><\/p>\n

      Nulla di particolare: si tratta dell’hostname, o dell’indirizzo IP (consiglio quest’ultimo), del server FTP sul quale appoggeremo i file di backup.<\/p>\n

      La parte elaborativa dello script<\/strong><\/p>\n

      Passiamo ora all’ultima parte dello script, quella elaborativa, quella, insomma, che compie il lavoro sporco.<\/p>\n

      Avendo creato un’intestazione che raccoglie tutti i dati essenziali, “importante” quindi anche come peso, la parte di processazione sar\u00e0, al contrario, molto leggera, anche se meno espressiva. Leggiamola e commentiamola riga per riga:<\/p>\n


      \n$MYSQL_DUMP $MYSQL_OPTS > $BACKUP_SPOOL\/$MYSQL_BACKUP_FILE
      \n<\/code><\/p>\n

      La prima operazione compiuta dal nostro script consister\u00e0 in un backup del database. Richiamando i contenuti delle variabili sulla riga, verr\u00e0 richiamata l’utility mysqldump<\/code>, cui saranno passate varie opzioni. L’output del programma, ovvero il dump dei database, verr\u00e0 rediretto (><\/code>) sul file il cui percorso \u00e8 indicato dalla seconda parte della riga di comando, creato dinamicamente accedendo ai valori delle variabili di riferimento, in parte generati dall’output del comando date<\/code>. In pratica, in \/var\/spool\/backup<\/code> avrete un file che inizia con la data del giorno in cui avete creato il dump e termina con -mysql.nome-del-server.com.backup.sql<\/code>.<\/p>\n


      \n$TAR $TAR_REMOVE $BACKUP_SPOOL\/$ARCHIVE_MYSQL $BACKUP_SPOOL\/$MYSQL_BACKUP_FILE
      \n<\/code><\/p>\n

      Nulla di particolare: viene creato un archivio compresso del file contenente il dump dei database. Una volta terminata l’archiviazione, il file .sql non compresso viene cancellato.<\/p>\n


      \n$FIND $BACKUP_EXCLUDE_DIR > $BACKUP_SPOOL\/IGNORE.LST
      \n<\/code><\/p>\n

      Quando si esegue l’archiviazione di una directory, normalmente l’utility tar<\/code> seleziona tutti i file in essa contenuti, tutte le sotto directory e tutti i file nelle sotto directory.<\/p>\n

      Non sempre questo pu\u00f2 essere ci\u00f2 che si vuole.<\/p>\n

      Per esempio, si vuole eseguire il backup della directory \/etc<\/code>, ma non di \/etc\/passwd<\/code> e \/etc\/shadow<\/code>, oppure di \/home\/utente<\/code> ma non di \/home\/utente\/.wine<\/code>. Magari si vuole avere un backup dell proprio sito \/usr\/local\/apache\/htdocs\/<\/code> ma non della directory \/usr\/local\/apache\/htdocs\/data\/videos\/<\/code> nella quale sono contenuti i videocast ospitati dal vostro sito, che renderebbero inutilmente pesante il file di backup.<\/p>\n

      Che fare?<\/p>\n

      Semplice, basta chiedere all’utility find<\/code> di elencare tutti i percorsi ai file e alle directory che non si vogliono archiviare, per poi salvare il suo output in una black list che verr\u00e0 passata a tar<\/code>, in modo che li ignori. <\/p>\n


      \n$TAR $TAR_OPTS $BACKUP_SPOOL\/$ARCHIVE -X $BACKUP_SPOOL\/IGNORE.LST $BACKUP_DIR
      \n<\/code><\/p>\n

      Ed ecco tar<\/code> all’opera: archivier\u00e0 tutti i file contenuti nelle directory indicate (e da notare che le sotto directory, cos\u00ec come le directory, sono anch’esse dei file), ignorando (-X<\/code>) quelli contenuti in IGNORE.LST<\/code>.<\/p>\n


      \n$ECHO \"\\$ $BACKUP_MACRO $RM_DATE\" | $FTP $SERVER
      \n<\/code><\/p>\n

      Non rimane che spostare via FTP gli archivi creati. La riga qui sopra vi sembra incomprensibile? Gi\u00e0. Per ora diciamo che l’utility ftp<\/code> viene richiamata indicandole il server il cui indirizzo \u00e8 contenuto in SERVER<\/code> e passandole una macro che si occuper\u00e0 di caricare i nuovi archivi e, per sicurezza, di ricavare dello spazio, cancellando sul server remoto gli archivi pi\u00f9 vecchi della data indicata in RM_DATE<\/code>.<\/p>\n

      Vedremo tra poco pi\u00f9 in dettaglio come si costruisce una macro FTP. Per ora, basti sapere che entra in gioco il file .netrc<\/code>, contenuto nella directory home dell’utente con il quale viene lanciato lo script, il quale consente di passare all’utility non solo le credenziali di login al server FTP ma anche una serie di comandi necessari ad automatizzare le procedure di trasferimento. <\/p>\n


      \n$RM $BACKUP_SPOOL\/$ARCHIVE $BACKUP_SPOOL\/$ARCHIVE_MYSQL
      \n<\/code><\/p>\n

      Siamo arrivati alla fine dello script. Facciamo un po' di pulizie, cancellando dalla spool gli archivi che abbiamo appena spostato sul server remoto.<\/p>\n

      Terminato lo script principale, non rimane che scrivere qualche riga ancora, per automatizzare le operazioni di trasferimento: \u00e8 tempo di affrontare le macro FTP. <\/p>\n

      La macro FTP<\/strong><\/p>\n

      Il \"gioco\" dell'FTP ruota tutto attorno a un file, <\/code>.netrc<\/code>, posto nella directory dell’utente utilizzato per eseguire lo script.<\/p>\n

      Come al solito, vediamone prima l’intera sequenza di comandi, per poi commentarla passo passo:<\/p>\n


      \nmachine localhost
      \n login caricamento
      \n password caricapassword<\/p>\n

      macdef backup
      \n binary
      \n lcd \/var\/spool\/backup
      \n cd archivio_backup
      \n mput *.tgz
      \n delete $1-nome-del-server.backup.tgz
      \n delete $1-mysql.nome-del-server.backup.tgz
      \n quit<\/p>\n

      <\/code><\/p>\n

      Iniziamo con la prima riga:<\/p>\n


      \nmachine localhost
      \n<\/code><\/p>\n

      Possiamo definire questo come il marcatore d’inizio di un contenitore di istruzioni. Quando viene lanciato, FTP cerca nel file .netrc<\/code>, l’istruzione machine<\/code> e compara il valore che la segue con l’argomento che le \u00e8 stato fornito, sulla riga di comando, come indirizzo del server remoto cui collegarsi. Se l’uguaglianza \u00e8 riscontrata, FTP processer\u00e0 tutte le rimanenti istruzioni, fino a fine file o alla seguente istruzione machine<\/code>. <\/p>\n

      Detto in soldoni, machine<\/code> deve riportare lo stesso indirizzo contenuto nella variabile SERVER <\/code>. Volendo, si potrebbero avere pi\u00f9 blocchi machine<\/code> per eseguire login differenti su macchine diverse.<\/p>\n


      \n login caricamento
      \n password caricapassword
      \n<\/code><\/p>\n

      Qui inserite la login e la password del vostro account FTP sul server remoto. Niente di speciale.<\/p>\n


      \nmacdef backup
      \n<\/code><\/p>\n

      Ecco iniziare la parte pi\u00f9 interessante del file. Questo marcatore definisce una macro, il cui nome deve essere indicato sulla stessa riga. In questo caso, si chiamer\u00e0 backup<\/code>. Le righe che seguiranno questa dichiarazione iniziali saranno considerati come facenti parte della macro, fino a che non verr\u00e0 incontrato un carriage return, o due caratteri di newline consecutivi. In pratica, per terminare una macro, dovete semplicemente lasciare una riga vuota alla fine.<\/p>\n

      Vi \u00e8 un limite di 16 macro e 4096 caratteri in totale, per tutto il file .netrc<\/code>, quindi non sprecateli. Da ricordare che esistono due caratteri speciali:<\/p>\n

        \n
      1. \n$<\/code> Seguito da uno o pi\u00f9 numeri viene interpretato come il corrispondente argomento sulla riga di comando che ha richiamato la macro. Se $<\/code> viene fatto seguire da una i<\/code>, la macro viene ciclata e al primo “giro”, i<\/code> viene sostituito con il primo argomento della riga di comando che ha richiamato la macro, al secondo, con il secondo argomento e cos\u00ec di seguito.\n<\/li>\n
      2. \n\\<\/code> Ha la classica funzione di escape, e quindi qualsiasi carattere che venga preceduto da \\<\/code> non verr\u00e0 interpretato.\n<\/li>\n<\/ol>\n


        \n binary
        \n<\/code><\/p>\n

        Ci assicuriamo che il trasferimento dei file avvenga in modalit\u00e0 binaria.<\/p>\n


        \n lcd \/var\/spool\/backup
        \n<\/code><\/p>\n

        Ci spostiamo, sul server remoto, nella directory nella quale vogliamo caricare gli archivi.<\/p>\n


        \n cd archivio_backup
        \n<\/code><\/p>\n

        Ci spostiamo, sul server locale (quello su cui abbiamo creato gli archivi), nella directory di spool nella quale abbiamo creato i file .tgz<\/code>.<\/p>\n


        \n mput *.tgz
        \n<\/code><\/p>\n

        Magia del globbing. In pratica, usiamo *<\/code> per istruire il client FTP affinch\u00e9 carichi sul server remoto tutti i file .tgz<\/code> presenti in \/var\/spool<\/code>.<\/p>\n


        \n delete $1-nome-del-server.backup.tgz
        \n<\/code><\/p>\n

        Ora, ricordate la penultima istruzione dello script? Diamoci nuovamente un’occhiata:<\/p>\n


        \n$ECHO \"\\$ $BACKUP_MACRO $RM_DATE\" | $FTP $SERVER
        \n<\/code><\/p>\n

        Cosa significa questa stringa? Semplicemente, si richiama il client FTP, passandogli come argomento l’indirizzo del server cui collegarsi e, in pipe (|<\/code>) gli si fornisce il nome della macro da richiamare e la data con la quale comporre il nome dei file da cancellare.<\/p>\n

        Fermiamoci un breve inciso.<\/p>\n

        In realt\u00e0, il nome della macro viene accettato da FTP nel formato:<\/p>\n


        \n$ nome_macro
        \n<\/code><\/p>\n

        Quindi, nel nostro caso, il nome della macro accettato da FTP \u00e8:<\/p>\n


        \n$ backup
        \n<\/code><\/p>\n

        che \u00e8 ben diverso da:
        \n
        \n$BACKUP_MACRO
        \n<\/code><\/p>\n

        Quest’ultimo, infatti non \u00e8 altro che l’istruzione per richiamare il contenuto della variabile BACKUP_MACRO<\/code>, quindi, la precedente riga, si deve leggere:<\/p>\n


        \nbackup
        \n<\/code><\/p>\n

        Il client FTP, per\u00f2, accetta il nome della macro, solo se preceduta da $<\/code>$ deve essere passato in modo che non ci siano equivoci, che non possa essere interpretato all’interno della macro, quindi va preceduto dal carattere speciale \\<\/code> e inviato in questa forma come argomento da passare al client.<\/p>\n

        La precedente riga, quindi, interpretata correttamente, operando la giusta sostituzione di variabili, nel sistema utilizzato per questi esempi si risolve in:<\/p>\n


        \n\/bin\/echo \"\\$ backup 2008-02-09\" | \/usr\/bin\/ftp indirizzo-del-server-di-appoggio
        \n<\/code><\/p>\n

        e quindi la precedente riga di macro:<\/p>\n


        \n delete $1-nome-del-server.backup.tgz
        \n<\/code><\/p>\n

        interpretata diventa:<\/p>\n


        \n delete 2008-02-09-nome-del-server.backup.tgz
        \n<\/code><\/p>\n

        dato che 2008-02-09 \u00e8 il primo argomento ($<\/code> privo di escape), passato alla riga di comando che ha invocato la macro. <\/p>\n

        Da notare che si \u00e8 deciso di tenere una quindicina di giorni di archivi, ma l’effettivo arco di ritenzione \u00e8 condizionato solo dallo spazio a disposizione, quindi sta a voi decidere quanto, in base ai vostri personali criteri.<\/p>\n


        \n delete $1-mysql.nome-del-server.backup.tgz
        \n<\/code><\/p>\n

        Qui vale il discorso fatto per la precedente istruzione. Cambia solo la parte finale del nome del file da cancellare, in questo caso l’archivio contenente il dump del database.<\/p>\n


        \n quit
        \n<\/code><\/p>\n

        Finito. Trasferiti i file, si chiude la connessione al server.<\/p>\n

        Copiate il blocco di istruzioni appena viste in un file .netrc<\/code> e ponetelo nella home dell’utente che intendete utilizzare per eseguire lo script.<\/p>\n

        Modificate le propriet\u00e0 del file con il comando:<\/p>\n


        \nchmod 600 .netrc
        \n<\/code><\/p>\n

        altrimenti vi ritroverete con un FTP ricalcitrante. Occhio anche ai permessi e proprietario del file contenente lo script, mai lasciarlo eseguibile o modificabile da altri che non sia l’utente da voi scelto per eseguire questo compito.<\/p>\n

        Ricordatevi, infine, di terminare il blocco di macro, in .netrc<\/code> con una riga vuota.<\/p>\n

        Conclusioni<\/strong><\/p>\n

        Ci\u00f2 che abbiamo visto \u00e8 un esempio di come, sfruttando gli automatismi messi a disposizione dalle utility e dai comandi presenti in un sistema Unix sia possibile automatizzare compiti anche complessi, ma ripetitivi.<\/p>\n

        Ora, se prendiamo il file contenente lo script appena creato, lo rendiamo eseguibile e lo spostiamo nella cartella cron.daily<\/code>, avremo un sistema automatizzato che tutte le notti archivier\u00e0 i dati e li sposter\u00e0 su un server remoto, in modo che avremo sempre a disposizione un backup completo dei file che ci interessa preservare.<\/p>\n

        Certo, non si tratta di un sistema sofisticato, che consente di creare backup totali e incrementali, o meglio, ci vorrebbe ancora un po’ di lavoro perch\u00e9 possa farlo, ma il suo lavoro lo esegue velocemente e senza troppi fronzoli.<\/p>\n

        Si pu\u00f2 migliorare?<\/p>\n

        Certo.<\/p>\n

        Quello che vi ho proposto \u00e8 solo uno scheletro di base. Intendiamoci, gi\u00e0 cos\u00ec funziona senza problemi, ma si potrebbe implementare un’ulteriore struttura di controllo, che verifichi l’effettiva creazione dei file di archivio prima di trasferirli, che ci avvisi se la connessone FTP non \u00e8 disponibile, insomma, che ci dia un feedback sul buon esito di tutta l’operazione.<\/p>\n

        In realt\u00e0, non \u00e8 molto difficile implementare dei controlli. Potrete farlo tranquillamente voi, oppure potrebbe essere l’argomento di un prossimo post.<\/p>\n

        Buon lavoro!<\/p>\n","protected":false},"excerpt":{"rendered":"

        Dopo quasi, ahem, un anno di stasi, vediamo di chiudere l’agomento inziato con il primo post Backup in rete pratico e veloce con FTP -1, passando alla parte pi\u00f9 “operativa”. Vediamo, qui di seguito, un semplice shell script che si occupa di creare un backup all’interno di un file tgz, che avr\u00e0 come prefisso la …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,62],"tags":[102,86,472,87,97,118,139,104,120,484],"class_list":["post-4","post","type-post","status-publish","format-standard","hentry","category-computer","category-sysadmin","tag-102","tag-backup","tag-fon","tag-ftp","tag-giornali","tag-home","tag-linux","tag-mac","tag-shell","tag-sicurezza","without-featured-image"],"_links":{"self":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/4","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/comments?post=4"}],"version-history":[{"count":0,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/4\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/media?parent=4"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/categories?post=4"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/tags?post=4"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}