AFbackup e' un sofisticato sistema client-server che consente a piu' workstation di sfruttare un sistema di backup centralizzato verso un apposito server.

AFbackup e' un sofisticato sistema client-server che consente a piu' workstation di sfruttare un sistema di backup centralizzato verso un apposito server.
Questo è un sistema di backup client-server che offre a diverse postazioni di lavoro un backup centralizzato in uno speciale server di backup.
È anche facilmente possibile fare il backup di un singolo computer. Qualsiasi dispositivo streamer (normalmente sarà un dispositivo a nastro) può essere usato per scrivervi i dati.
La scrittura dei backup viene di norma fatta in maniera sequenziale: la scrittura sul nastro inizia alla fine della precedente scrittura, non importa da dove si è fatto il ripristino nel frattempo.


Caratteristiche:
- autenticazione client prima che questo prenda il controllo,
- restrizioni di accesso al dispositivo streamer -> sicurezza,
- compressione dei singoli file dal lato client -> affidabilità,
- flusso dei dati scritto sul nastro in frammenti -> ricerca veloce di file,
- logging della posizione del nastro per ogni file,
- utilizzo completo della capacità del nastro,
- backup totali/incrementali,
- possibilità di fare il backup di partizioni raw,
- buffering lato client e server per massimizzare il trasferimento.
Si noti: è necessario Tk se si desidera usare l'utilità grafica di configurazione invece di quella testuale. 
A volte bisogna prendere alcune decisioni che hanno la pruriginosa caratteristica di essere poco convenzionali. Un amministratore di sistemi con un po’ di esperienza alle spalle sa che è bene cercare una soluzione pratica a problemi pratici, piuttosto che addentrarsi nell’estetica del sysadmin. Certo, creare soluzioni eleganti è un piacere quanto leggere un codice raffinato e ben indentato, ma spesso i problemi sopraggiungono a spron battuto ed esigono soluzioni immediate, pratiche, efficienti, semplici.
Si, perché il principio del KISS, Keep It Simple Stupid, è un comandamento da mandare a memoria: quanto più una soluzione è complessa, tanto più è prona a inconsistenze e difficile da manutenere nel tempo.Semplice, semplice ed efficiente.
Quando si hanno diversi clienti, macchine che viaggiano da anni e poco tempo, si deve cercare di razionalizzare, sfrondare i rami non produttivi, ridurre all’essenziale affinché tutto possa essere più facilmente gestibile.
Hai perso i dati? Ok, tira fuori un backup. Be…che?
A volte ci si accorge che qualcuno ha cancellato “per sbaglio” un file importante. E, magari, sono passati mesi prima che sia stata notata la mancanza questo file, vitale ma poco utilizzato. A volte, semplicemente, qualcuno cancella intere directory “per fare spazio”, saltando quella inutile pratica di controllare *cosa* era contenuto al suo interno. A volte, è un semplice “tirone” sulla linea elettrica a mandare tutto a quel paese, oppure un calo di tensione, in ambienti privi di continuità elettrica. In ogni caso, se non avete backuppato, sono guai vostri.
Già, perché poi scopri che il sito del cliente, fatto di quattro pagine in croce, ancora in beta non aperto al pubblico, tutto traballante, faceva 1000 iscritti al giorno, generava fantastiliardi, era di importanza capitale e ogni minuto offline costa all’azienda zilioni di talleri. Ops, ve l’avevo detto di implementare una sana politica di backup 
E non basta dire al cliente “bisogna fare dei backup”. E nemmeno fidarsi quando ci si sente rispondere “si li facciamo”. A me è capitato di vedere dei backup effettuati sulla stessa macchina “backuppata”. Al primo disastro, il sistemista di turno, con espressione vacua, si chiedeva come recuperare i dati dal disco morto del server. Mah. >Ora, l’ideale sarebbe implementare dei backup in rete, su server geograficamente dispersi, prendendo poi i supporti, portandoli altrove, rinchiudendoli in armadi ignifughi e mettendoci un Terminator di guardia. Questo giusto per evitare che le classiche “cassette” vengano danneggiate insieme al server, nel caso in cui un inconveniente di qualche tipo affliggesse l’edificio in cui server e macchine di backup si trovano insieme. Che ne so, un’alluvione, un’invasione di cavallette, rane, attivisti che vogliano liberare i server dalla schiavitù dei rack. Ovviamente, giusto per non sprecare risorse, andrebbe gestita una politica di conservazione dei dati, con backup incrementali, totali, rotazione dei supporti, insomma tutto quello che ci si sente dire ogni volta che ci vengono illustrati i vantaggi di questa sana pratica.  
Perché dovrei usare FTP per trasferire i backup?
Rsync su ssh non si autentica, dato che sul server remoto sshd non è configurato per accettare l’autenticazione tramite le chiavi. Un’alternativa potrebbe consistere nel montare lo spazio remoto come directory e quindi scriverci sopra, ma poi andrebbero implementati i controlli necessari a verificare che lo spazio remoto sia correttamente montato prima delle operazioni di scrittura. No, non c’è tempo e nemmeno ho voglia di porre delle domande ai tedeschi e attendere le risposte. I forum e i wiki forniti dall’ISP sono in tedesco e anche traducendoli online, l’operazione diventa troppo lenta.
Visto che la macchina che ospita i backup è interna alla rete del provider, i rischi che questi vengano sniffati è relativamente basso e, oltretutto, i dati non sono di eccezionale valore, quindi si potrebbe optare per una soluzione pratica e veloce, riesumando le connessioni FTP. Si, certo, il protocollo FTP fa passare qualsiasi cosa in chiaro e quindi il suo utilizzo deve essere limitato a scenari in cui il rapporto costi/benefici sia favorevole, come per esempio in presenza di dati non sensibili da backuppare, oppure di trasferimento degli stessi all’interno di una rete interna, meno soggetta a possibili intrusioni e sniff. In questo caso, i dati non sono sensibili e il backup avviene su rete interna, quindi il rapporto costi/benefici è ottimo. Quindi, non rimane che implementare una soluzione di trasferimento dei backup basata su FTP. Si, va bene, ma quale tipo di backup?
Ok, l’ideale sarebbe usare una utility di livello non troppo alto, in modo che i dati archiviati siano facilmente recuperabili. Il problema, però consiste nel loro difficile utilizzo: programmi come dd, dump o mt non sono familiari a molti sysadmin, sicuramente non ai più giovani che sono cresciuti con strumenti come

1. I dati sono rappresentati in formato specifico, per cui si è vincolati all’applicazione stessa per recuperarli; incrementale:
   • Backup completo - Consente il salvataggio indistinto di qualsiasi file indicato, senza alcuna relazione con backup precedenti; paga: per recuperare un file all’interno di un set incrementale bisognerà recuperare prima il file conservato nell’ultimo backup completo e poi, via via, tutti le copie incrementali, fino ad arrivare al set che contiene la versione richiesta. Il che, ancora intuitivamente, porta l’evidente svantaggio di richiedere tempi di restore lunghi e uno swapping di supporti che in alcuni casi si può rivelare notevole. Diventa quindi necessario implementare una policy di backup che alterni registrazioni complete e incrementali basandosi su fattori contingenti, quali l’importanza data a un restore veloce, per esempio in sistemi pubblici con livelli di servizio cogenti, oppure le limitazioni dovute alla scarsa capacità dei supporti o al loro numero carente, oppure alla frequenza di rilascio dei dati e il conseguente riutilizzo dei supporti stessi o, ancora, alla frequenza con la quale vengono modificati i file da salvare. E’ un’alchimia, più che un’equazione, e il backup è un’arte minore, più che una scienza. Oltretutto, sistemi sofisticati richiedono un database in cui possa venire registrata la corrispondenza fra set di backup, file registrati e supporti sui quali viene salvato il tutto. Il che espone il rischi di trovarsi con un insieme di dati non coerenti nel momento in cui quest’unico database risulti corrotto. Certo, programmi come Afbackup provvedono a spedire un’email dopo ogni backup, allegando un set minimo di informazioni da utilizzare per il recupero dei dati, proprio nel caso in cui venisse a mancare il database di collegamento, ma il rischio permane in soluzioni meno evolute. Che fare, allora? Se non si hanno grandi quantità di dati da backuppare e questi possono essere tenuti giusto per poco tempo, due settimane o un mese, giusto per avere qualche set di emergenza per un pronto ripristino di un server, quindi non per un’archiviazione di lungo termine ma per un disaster recovery, è possibile affidarsi a qualche vecchia conoscenza del mondo Unix, ovvero all’accoppiata TAR/FTP, il tutto condito da poche righe di shell scripting.
     Ultima versione stabile rilasciata: 3.5.3
     

     Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:
     

     
     
     1. I dati sono rappresentati in formato specifico, per cui si è vincolati all’applicazione stessa per recuperarli; incrementale:
        • Backup completo - Consente il salvataggio indistinto di qualsiasi file indicato, senza alcuna relazione con backup precedenti; paga: per recuperare un file all’interno di un set incrementale bisognerà recuperare prima il file conservato nell’ultimo backup completo e poi, via via, tutti le copie incrementali, fino ad arrivare al set che contiene la versione richiesta. Il che, ancora intuitivamente, porta l’evidente svantaggio di richiedere tempi di restore lunghi e uno swapping di supporti che in alcuni casi si può rivelare notevole. Diventa quindi necessario implementare una policy di backup che alterni registrazioni complete e incrementali basandosi su fattori contingenti, quali l’importanza data a un restore veloce, per esempio in sistemi pubblici con livelli di servizio cogenti, oppure le limitazioni dovute alla scarsa capacità dei supporti o al loro numero carente, oppure alla frequenza di rilascio dei dati e il conseguente riutilizzo dei supporti stessi o, ancora, alla frequenza con la quale vengono modificati i file da salvare. E’ un’alchimia, più che un’equazione, e il backup è un’arte minore, più che una scienza. Oltretutto, sistemi sofisticati richiedono un database in cui possa venire registrata la corrispondenza fra set di backup, file registrati e supporti sui quali viene salvato il tutto. Il che espone il rischi di trovarsi con un insieme di dati non coerenti nel momento in cui quest’unico database risulti corrotto. Certo, programmi come Afbackup provvedono a spedire un’email dopo ogni backup, allegando un set minimo di informazioni da utilizzare per il recupero dei dati, proprio nel caso in cui venisse a mancare il database di collegamento, ma il rischio permane in soluzioni meno evolute. Che fare, allora? Se non si hanno grandi quantità di dati da backuppare e questi possono essere tenuti giusto per poco tempo, due settimane o un mese, giusto per avere qualche set di emergenza per un pronto ripristino di un server, quindi non per un’archiviazione di lungo termine ma per un disaster recovery, è possibile affidarsi a qualche vecchia conoscenza del mondo Unix, ovvero all’accoppiata TAR/FTP, il tutto condito da poche righe di shell scripting.
          Ultima versione stabile rilasciata: 3.5.3
          1. I dati sono rappresentati in formato specifico, per cui si è vincolati all’applicazione stessa per recuperarli; incrementale:
             • Backup completo - Consente il salvataggio indistinto di qualsiasi file indicato, senza alcuna relazione con backup precedenti; paga: per recuperare un file all’interno di un set incrementale bisognerà recuperare prima il file conservato nell’ultimo backup completo e poi, via via, tutti le copie incrementali, fino ad arrivare al set che contiene la versione richiesta. Il che, ancora intuitivamente, porta l’evidente svantaggio di richiedere tempi di restore lunghi e uno swapping di supporti che in alcuni casi si può rivelare notevole. Diventa quindi necessario implementare una policy di backup che alterni registrazioni complete e incrementali basandosi su fattori contingenti, quali l’importanza data a un restore veloce, per esempio in sistemi pubblici con livelli di servizio cogenti, oppure le limitazioni dovute alla scarsa capacità dei supporti o al loro numero carente, oppure alla frequenza di rilascio dei dati e il conseguente riutilizzo dei supporti stessi o, ancora, alla frequenza con la quale vengono modificati i file da salvare. E’ un’alchimia, più che un’equazione, e il backup è un’arte minore, più che una scienza. Oltretutto, sistemi sofisticati richiedono un database in cui possa venire registrata la corrispondenza fra set di backup, file registrati e supporti sui quali viene salvato il tutto. Il che espone il rischi di trovarsi con un insieme di dati non coerenti nel momento in cui quest’unico database risulti corrotto. Certo, programmi come Afbackup provvedono a spedire un’email dopo ogni backup, allegando un set minimo di informazioni da utilizzare per il recupero dei dati, proprio nel caso in cui venisse a mancare il database di collegamento, ma il rischio permane in soluzioni meno evolute. Che fare, allora? Se non si hanno grandi quantità di dati da backuppare e questi possono essere tenuti giusto per poco tempo, due settimane o un mese, giusto per avere qualche set di emergenza per un pronto ripristino di un server, quindi non per un’archiviazione di lungo termine ma per un disaster recovery, è possibile affidarsi a qualche vecchia conoscenza del mondo Unix, ovvero all’accoppiata TAR/FTP, il tutto condito da poche righe di shell scripting.
               Ultima versione stabile rilasciata: 3.5.3