Mi accade spesso di parlare con persone che non hanno ben chiara la differenza tra ridondanza e backup. Si tratta di due concetti diversi, ed è importante avere ben chiare le implicazioni di entrambi.
La ridondanza si utilizza per ottenere la continuità di servizi anche in caso di malfunzionamenti di interi server e/o parti hardware. Il backup consente di ripristinare i dati nel caso di errori umani o logici, manomissioni e guasti in generale.
Il caso più comune di ridondanza si applica alle unità disco tramite la tecnica del RAID (Wikipedia), che previene la perdita di dati anche in caso di rotture di uno o più dischi (dipende dal livello di RAID utilizzato).
In alcuni casi la ridondanza sfocia nel bilanciamento di carico (load balancing), di cui il clustering è un esempio. In questo caso il carico è ripartito in modo trasparente tra diverse istanze del servizio che girano su macchine diverse e collegate tra di loro; in caso di caduta di un nodo (server) in un cluster, il suo carico di lavoro viene automaticamente distribuito tra i nodi rimanenti (failover).
La filosofia di fondo che sottende alla ridondanza è la garanzia della continuità del servizio anche in caso di fermi macchina o di rotture dell’hardware.
Le parti più comunemente candidate alla ridondanza sono: alimentatori, dischi, schede di rete, moduli RAM.
E’ evidente che la ridondanza non salva da errori logici o umani: un utente che cancelli un file per errore, oppure un database danneggiato sono tipici casi in cui la ridondanza non serve a nulla.
In queste occasioni si rimedia con il ripristino dai backup.
Le strategie di backup coprono un ventaglio di possibilità che va dalla replica completa di un intero datacenter (e dei suoi dati) in un sito alternativo, alla semplice copia su filesystem dei file di un disco; non esiste una politica buona per tutti: i backup sono delicati e vanno progettati attentamente in base alle esigenze della struttura ed ai livelli di affidabilità, velocità di ripristino e sicurezza che si vogliono ottenere.
Una delle opzioni da contemplare è il disaster recovery, che oltre ai dati salva anche i sistemi e le loro configurazioni, in modo da velocizzare e semplificare il ritorno alla normalità nei casi più gravi, come catastrofi naturali, incendi o furti.
I backup si progettano tramite “politiche di backup”, cioè un “Insieme di regole e procedure per assicurare che venga eseguito un backup adeguato alle necessità dell’organizzazione aziendale. Una politica di backup definisce il tipo (es. full o incrementale) di backup, la frequenza (generalmente giornaliera), e include le regole per verificare la rispondenza del processo di restore”.
Per una descrizione completa dei metodi e dei mezzi di backup vi rimando alle corrispondenti voci italiana ed inglese di Wikipedia.
Commenti
7 risposte a “Ridondanza e backup”
Bravo!
preciso e conciso.
@
nooooo, sbagli!!!
il server ridondante è definito il “server di backup”… lo sanno tutti…
😉
ci sono anche le persone di backup: nel caso una persona sostituisca un’altra in sua assenza… è il tipico caso di backup… è così palese!!!
hihihi
La ridondanza viene troppo spesso considerata dalla PMI soldi buttati, magari 2 NAS per backup, ma cluster mai :-/
.. bisogna vedere con chi parli.. è un concetto semplice ma.. non tutti hanno una cultura informatica tale da capirci!
La legge sulla privacy impone sia la ridondanza che il backup! Ma sono stesso gli informatici, spesso, a non saperlo ed a non consigliarlo ai clienti.
Leo
[…] Nell’esempio specifico si tratta di RAID5, il livello più diffuso. Al costo di una lieve ridondanza (è stato necessario trasportare un abito in più a testa) ci si è protetti dalla perdita di un […]
Necessitavo questo chiarimento.. rindondanza e backup, OTTIMO chiarimento, grazie.