[LatinaLUG] BackupPC

Fabrizio Cuseo f.cuseo@panservice.it
Mer 7 Mar 2012 15:57:34 CET



----- Messaggio originale -----
> Da: "Andrea Libralato" <andrea.libralato@gmail.com>
> A: "Fabrizio Cuseo" <f.cuseo@panservice.it>, "LUG Latina" <latina@lists.linux.it>
> Inviato: Mercoledė, 7 marzo 2012 15:41:41
> Oggetto: Re: [LatinaLUG] BackupPC
> 
> Il 07 marzo 2012 13:03, Fabrizio Cuseo <f.cuseo@panservice.it> ha
> scritto:
> > personalmente ho esperienza con BackupPC... pro e contro.
> >...
> > Contro:
> > - Poco evoluto se confrontato con strumenti come amanda o altri
> > commerciali
> 
> Amanda era free software qualche anno fa, o sbaglio?
> Che tu sappia, puoi darmi un ordine di grandezza sul costo di una
> soluzione commerciale che hai valutato e che fa pressapoco quello che
> tu fai con la tua soluzione?

Si, amanda e' ancora free che io sappia. Cosi' come bacula. 
Sono pero' molto piu' complicati da gestire (backuppc e' veramente una passeggiata).

Come soluzione a pagamento, per esempio, c'e' arkeia che conobbi molti anni fa e che era una bomba (ora e' una vita che non li seguo). Anche loro usano la deduplication dei dati, e a quanto leggo sul sito, hanno la formula che mi piace tanto "Backup to disk, replication to cloud", e mi piace soprattutto quando il cloud e' il nostro datacenter :) 
Hanno agent per molti database (e questo e' positivo), e per applicazioni, directory e sistemi di virtualizzazione.
Il rovescio della medaglia e' che e' tutt'altro che economica; ma sulla sicurezza dei dati, potrebbero essere soldi ben spesi.


> > - Nessun agent (pero' ti permette di eseguire una operazione
> > PRE-backup e POST-Backup (ad esempio per fare il dump di un db
> > mysql oppure per creare e cancellare uno snapshot)
> 
> Quindi il backup lato client avviene solo per share di rete nel caso
> di client Windows?

Si. In realta' usa lo share di sistema (password di amministratore... argh); invece per linux usa rsync tramite ssh e chiavi.
 

> > - Memorizza i backup riportando il filesystem sorgente... quindi
> > milioni di file sul filesystem del backup.
> 
> Non ho ben capito cosa intendi con "Memorizza i backup riportando il
> filesystem sorgente".

Volevo dire, riportando la struttura del filesystem sorgente. Quindi il tuo backup non e' un file tar... se avevi 100.000 files sul server di produzione, avrai 100.000 files su quello di backup (in realta' ne avrai di piu').
In pratica devi avere un filesystem pronto per lavorare con un numero elevatissimo di files (anche, e soprattutto, per fare un fsck).


> > Obbligatorio l'utilizzo ALMENO di ext4 o di reiser o altro
> > filesystem che sia veloce nell'fsck
> 
> ReiserFS non č "morto"?

Beh... l'inventore e capoprogetto e' in prigione per uxoricidio.. il filesystem ancora c'e', per quanto lo sviluppo e' rallentato.

> 
> 
> > Requisito fondamentale:
> > - Dischi molto, molto veloci... assolutamente controller raid
> > hardware: parola d'ordine, ottimizzare il filesystem
> 
> Scusa, ma mi sembra che nella soluzione che proponi (come azienda)
> non
> sia incluso un doppio disco, o sbaglio?

Si puo' avere un singolo o doppio disco con l'entry level (l'atom 1.6 per intenderci), fino a 4 dischi con i microserver hp. Poi si sale di costi e quindi non si parla piu' di soluzioni "entry level".

> I microserver hanno comunque un controller adatto al RAID1?

raid software nel caso di linux (md), o zfs e raid zfs nel caso di freenas

> Qual č il motivo per cui il disco deve essere necessariamente veloce?

E' backuppc il problema. Ha una quantita' di files enorme a cui accedere.. inoltre di notte (o di giorno, in base a quando li scheduli) fa girare dei processi che cancellano i file duplicati e creano i link, oltre che cancellare le versioni "expirate" degli incrementali o dei full. Il tutto equivale ad aver bisogno di un I/O molto veloce. Ovviamente dipende sempre da quello che ci metti su come dati... 
 
> Con riferimento sempre a BackupPC, potresti fornire qualche dettaglio
> operativo in pių?

Direi che forse http://backuppc.sourceforge.net/ e' piu' adatto di me :) scherzi a parte, io riassumerei il tutto in:

- Quante macchine devi backuppare, che mole di dati hanno a bordo, che sistema operativo hanno, quanto cambiano i dati nel tempo
- Quanto budget e' disponibile
- Quanto sei disposto a sopportare le limitazioni di un prodotto gratuito e non di livello enterprise, in cambio di un risparmio sui costi

E aggiungerei:

- I server (se di server si tratta) che devi backuppare, sono macchine fisiche ? virtuali ? sistema di virtualizzazione ? Possibilita' di backup delle macchine virtuali (se sono virtuali) a livello di block device e non di filesystem ? 

:) 



> Scusa la pioggia di domande, vorrei solo approfondire la questione
> per
> valutare se adottarlo come sistema di backup o meno.
> 
> --
> Saluti,
> Andrea
> 

-- 
---
Fabrizio Cuseo - mailto:f.cuseo@panservice.it
Direzione Generale - Panservice InterNetWorking
Servizi Professionali per Internet ed il Networking
Panservice e' associata AIIP - RIPE Local Registry
Phone: +39 0773 410020 - Fax: +39 0773 470219
http://www.panservice.it  mailto:info@panservice.it
Numero verde nazionale: 800 901492


Maggiori informazioni sulla lista latina