Ovviamente è il restore, ma non tutti sembrano mettere in pratica davvero questa regola.
La maggior parte delle persone (dall’utente casalingo al SysAdmin) si preoccupa del backup, ovvero dell’efficienza e (ammettiamolo) dell’estetica delle procedure di backup, tralasciando completamente la parte di restore.
Quando l’ambiente funziona a dovere, il restore è semplice; se l’utente cancella un singolo documento di Word ci sono i wizard, le interfacce grafiche, gli automatismi, le protezioni, i manuali online…
Ma se il danno è più grave o più esteso?
Posto che i costi della simulazione di un vero ripristino da disastro sono poco sopportabili da molte realtà, di seguito elenco alcuni punti da considerare quando si pianifica un backup.
KISS
Accesso – Crittografare i backup con password o chiavi è una buona cosa per prevenire i furti, ma assicuratevi che le credenziali siano note e disponibili a più di una persona e che non siano registrate solamente nei dati che state salvando.
Accesso al NAS – I NAS sono comodissimi come storage per i backup e il loro costo ha soppiantato quasi interamente i DAT a 4mm e alcune soluzioni a nastro LTO di fascia medio-bassa. Alcuni ritengono che sia una bella idea utilizzare le credenziali di dominio Active Directory per accedere ai NAS e, di fatto, dimenticarsi delle credenziali amministrative locali. Comodo e utile per uniformare gli accessi, ma se dovete ripristinare i/il Domain Controller assicuratevi di poter accedere facilmente al NAS.
Protocolli del NAS – Anche i protocolli di accesso ai dati sono importanti: se iSCSI potrebbe essere più performante di SMB, dovete tener presente che, in caso di problemi seri, l’accesso ai vostri dati necessita di un client iSCSI. Inoltre, in un contesto PMI, avere anche una copia rsync/robocopy di tutti i dati in uno share SMB potrebbe risolvere due problemi in un colpo solo: da un lato un power user potrebbe essere istruito ad accedere ai dati per fare autonomamente il restore di un singolo file, dall’altro lo share SMB di un NAS potrebbe costituire il server di emergenza da utilizzare in caso di disastro.
Usare enclosure fisicamente diversi e separati tra loro – Qualcuno crea due LUN o due raidset sul medesimo storage (NAS o SAN che sia) per registrare dati e backup. Inutile dire che, per quanto ridondato, se salta per aria lo storage si porta via dati e backup. Anche mettere un secondo disco nel server per fare gli unici backup non è una grande idea. Meglio ancora gli storage con i backup sono in un’altra stanza rispetto al server.
Software – Il software deve generare dei backup il più possibile rileggibili. Da evitare assolutamente formati proprietari, compressioni esotiche o cose di questo tipo. È bene avere sotto mano una chiavetta USB con la copia del kit di installazione e le chiavi di attivazione del software di backup.
Strategia – Dove è possibile, fare sempre backup full e lasciare incrementali, differenziali e altre amenità a casi dove non è possibile farne a meno. Magari fare un backup full dei soli dati ogni giorno e la domenica fare un backup disaster recovery dell’intero server. Fanno eccezione i programmi che hanno opzioni come il reverse incremental di Veeam con cui si ha la versione full dell’ultimo backup e gli incrementali dei backup precedenti.
Rotazione – Valutare sempre la strategia di rotazione. Per alcuni server (come i Domain Controller) non ha senso avere una storicizzazione spinta, mentre per altri potrebbe essere necessaria se non obbligata da enti regolatori. Ci sono diversi schemi di rotazione che vanno dal comune FIFO, al nonno-padre-figlio fino ad altri più esotici e complicati come la torre di Hanoi (che prende il nome dal lamento del backup operator quando deve avere a che fare con quella strategia).
Aggiornamento 31/5/2012 – Luca Dell’Oca ha ampliato il tema del backup in un articolo del suo blog, che vale la pena di leggere.
Lascia un commento