On 08/15/2011 01:25 PM, Gelpi Andrea wrote: > Per prima cosa, io separerei i backup da tutto il resto mettendo ad > esempio un Qnap o qualche cosa di simile il più lontano possibile, > fisicamente, dai dati. Avere il backup vicino ai server con i dati non è > una buona idea, a meno di non avere sistemi antincendio in grado di > sopprimere qualsiasi incendio in poco tempo, tipo quelli usati in certe > banche e assicurazioni. Qualsiasi sistema antincendio non tutela in modo idoneo per diversi motivi. Primo potrebbe non essere l'incendio il tuo problema, ma p.es. il terremoto che ribalta il rack contenente la tua infrastruttura (quanti rack hai mai visto avvitati a terra come prescritto?) o le canne dell'acqua che si rompono o la fuga di gas che fa esplodere il locale attiguo... > I backup su nastro vanno benissimo, ma costringono a spostare > continuamente i nastri e soprattutto a comprarli nuovi ogni anno se vuoi > essere sicuro di leggere il backup. Perdona ma è una stupidata colossale. La tape library può essere messa anch'essa in luogo remoto e connessa in fibra alla SAN, quindi non devi spostare nulla. Secondariamente il nastro è ad oggi il supporto più affidabile per il backup.Certo che se per un'infrastruttura di questo tipo ti affidi a tecnologie obsolete come DAT allora meriti ogni possibile improperio. Se invece ti affidi a LTO parliamo di supporti garantiti 30 anni e la storia prova che nastri di oltre 30 anni sono stati riletti. Altrettanto non si può dire dei dischi. > Non hai idea di quante volte ho trovato sistemi di backup a nastro con > il backup e relativa verifica che dava tutto OK, ma dopo due giorni il > nastro non lo leggevi più. Non certo nastri LTO. > Purtroppo la verifica di ciò che viene scritto su un nastro subito dopo > la scrittura non garantisce che riuscirai a rilegger il nastro. > A conti fatti consiglio di abbandonare i nastri a favore di nas seri. Ma per carità. NAS e Tape hanno funzioni nettamente distinte e un NAS non può sostituire il tape. Trovano entrambi posizione ideale in una soluzione di backup multi-tier, ma se devo scegliere a cosa rinunciare e se i tempi di restore non sono un fattore realmente critico non c'è alcun dubbio che sia nettamente meglio affidarsi al tape. > Qualunque altro dato non è detto che sia perdibile. Da mio punto di > vista anche un server di test se lo perdi, il danno sta nel tempo che va > dedicato a rimetterlo in piedi ed è comunque un danno economico. Quindi > non deve andar perso. Ma un server di test rientra nel normale backup e non nel disaster recovery. Quindi p.es. lo salvo sul NAS del cavolo che tanto c'ho spazio ma non lo trasferisco sul tape . > Su NAS e simili consiglio di usare sempre una qualche forma di raid in > modo da non perdere dati. Perché esiste ancora qualche sistema (ad esclusione dei notebook) su cui non si configuri almeno il mirroring? > A proposito di RAID, sapevate che le statistiche dicono che quando un > disco si rompe, è alta la probabilità di guasto di un altro disco > soprattutto, mentre si fa il riallineamento del raid? > E' pertanto consigliato usare sempre un disco di spare. C'è stata un'interessante discussione a tal riguardo a febbraio, intorno all'8, sul newsgroup it.comp.os.linux.sys ("Raid10 vs. Raid5"). Consiglio di leggerla. Avere l'hot spare non migliora di praticamente nulla le probabilità di morte del secondo disco. L'unica cosa che fa è accorciare i tempi di funzionamento in condizioni critiche che è certamente positivo ma non risolutivo. Non sono le 24 ore necessarie per la sostituzione del disco guasto quelle che rappresentano il problema maggiore. > Sui QNAP pertanto con dischi da 2TB puoi arrivare a 12TB effettivi, in > quanto due dischi ti servono per la gestione del raid. Se devo perdere due dischi allora con quel tanto configuro un raid 6 che mi offre realmente garanzie contro la rottura di due dischi e le cui performance, per il backup, restano assolutamente sufficienti. -- Flavio Visentin A computer is like an air conditioner, it stops working when you open Windows -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx