[LatinaLUG] BackupPC

[Andrea Libralato]

Il 07 marzo 2012 15:57, Fabrizio Cuseo <f.cuseo@panservice.it> ha scritto:
>
> Il rovescio della medaglia e' che e' tutt'altro che economica; ma sulla sicurezza
> dei dati, potrebbero essere soldi ben spesi.

Indubbiamente, ma magari una soluzione free/open hai la possibilità di
testarla (più o meno per bene) per verificare se possa funzionare per
quello che serve, mentre una soluzione closed devi prenderla così
com'è fidandoti del commerciale di turno (e mi risparmio i
commenti...) piuttosto che di una brochure.


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

Quindi quando cambiano la password dell'utente il backup non viene
eseguito e bisogna creare un'utenza apposita.


> 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).

Questa non mi sembra una buona cosa, sicuramente è "comodo" per
ripristinare un/dei file al volo, ma se volessi fare un backup storico
su DVD sarebbe un bel problema...


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

Conosco la storia di Reiser, ma da quello che ho letto e leggo in giro
più che rallentato sembra paralizzato...


> Direi che forse http://backuppc.sourceforge.net/ e' piu' adatto di me :)

Non fare il modesto, sai meglio di me che l'esperienza sul campo non
può essere riassunta in nessuna pagina web... :-P


> 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

Il numero di client può variare, generalmente da 3 a 10, i dati non
cambiano molto velocemente, per lo più sono i classici documenti da
ufficio.
Normalmente c'è un server, di solito funziona da file server, ma può
essere anche db server (tipicamente MSSQL).


> - Quanto budget e' disponibile

Domanda retorica... basso, normalmente poche centinaia di €.


> - Quanto sei disposto a sopportare le limitazioni di un prodotto gratuito
> e non di livello enterprise, in cambio di un risparmio sui costi

Questo mi preoccupa meno perchè:

- Lato cliente: deve costare "poco"? Bene, questa è la soluzione e ti
becchi pregi e difetti!
- Lato fornitore: dato che costa poco è necessario che gestisca io
eventuali restore, quindi se posso "personalizzare" i task di backup e
la relativa storicizzazione in modo agevolarmi il lavoro senza
impazzirmi troppo ben venga un servizio "chiuso" verso le possibilità
dell'utente. D'altra parte, corregimi se sbaglio, credo che anche le
tue soluzioni non consentano al tuo cliente di poter ripristinare un
file "al volo" o tramite una procedura "semplice" di restore (full o
selettivo che sia).


> 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 ?

Per ora lo scenario è tipicamente macchine fisiche, ma in futuro è
possibile che ce ne saranno di virtuali, nel secondo caso, oltre che
individuare una soluzione per la virtualizzazione adatta/comoda da
gestire, credo che convenga effettuare degli snapshot o dei backup
integrali dei dischi virtuali, o ci sono altre soluzioni/consigli?

-- 
Saluti,
Andrea