E se un tornado passasse attraverso il TUO data center?

Lo scorso fine settimana abbiamo avuto forti tempeste qui in Virginia e ovviamente la crisi in Giappone ci ricorda che le cose possono andare male in un batter d'occhio! Una domanda che mi pongo "E se un tornado colpisse il mio data center, sono pronto?"

Ho ottimi sistemi di backup "nel mio rack" incluso un backup su nastro. Poiché il data center non è vicino, non è possibile spostare i nastri fuori dal sito. Quello che mi piacerebbe trovare o creare è un sistema in grado di eseguire il backup di elementi critici come siti Web, database e copiarli in remoto, ad esempio il mio server a casa. Ho FIOS con servizio a 35 mbit, quindi ho la banda larga, quello di cui ho bisogno è il "sistema" per farlo. Sono un programmatore in modo da poter creare qualcosa che le informazioni FTP sono inattive su un programma, ma sono curioso se c'è qualcosa là fuori che possa riempire questo backup remoto ora? I miei server SQL sono sottoposti a backup su array di archiviazione, potrei interrompere tali backup o persino pianificare il mio server SQL qui per la sincronizzazione con i server di produzione su una pianificazione. Uso Windows Server 2008 R2 e SQL Server 2008 R2.

Cosa raccomandate tutti per la strategia off site in una crisi come un disastro naturale che mette fuori uso il nostro data center? Sei preparato? Spero che altri si facciano questa domanda e imparino da questi disastri naturali che abbiamo visto troppo spesso.

Le tue opzioni dovrebbero essere dettate dagli accordi sul livello di servizio con i tuoi clienti e limitati dal tuo budget.

Come minimo, è necessario disporre di backup off-site di tutti i dati critici. Ad oggi, tutti i dati che non è possibile ricreare da zero devono essere archiviati altrove. I backup offline sono migliori: i backup online o la replica potrebbero essere d'aiuto quando si verifica un tornado, ma cosa succede se un dipendente arrabbiato rilascia un database o distrugge un filesystem?

Da una base di backup offline, puoi iniziare a esplorare le opzioni che accelereranno il recupero in cambio di un costo più elevato. Esistono un numero enorme di opzioni che vanno da un singolo host per i backup online che descrivi fino agli ambienti completamente replicati con replica dei dati sincrona in esecuzione attiva (-attiva) + per tempi di inattività quasi zero.

Il recupero da zero sarà molto più semplice se separi i tuoi dati dalla tua infrastruttura nel modo più ordinato possibile. Ad esempio, il ripristino da zero sarà molto, molto più veloce se si esegue la distribuzione utilizzando sistemi come burattini o chef piuttosto che a mano. Rifare tutto il lavoro che hai fatto per costruire i tuoi sistemi sarà molto più veloce se puoi automatizzare il più possibile. Mantenere separati i dati riduce anche la quantità di dati di cui è necessario eseguire il backup: non scartare gigabyte di sistema operativo se hai davvero bisogno di pochi mega di configurazioni di sistema e dati dell'applicazione.

Le opzioni possono diventare piuttosto costose, quindi è necessario determinare ciò che la tua azienda è disposta a spendere per il ripristino di emergenza e quanti tempi di inattività i tuoi clienti possono tollerare. Elimina le opzioni che sono troppo costose o troppo lente per i tuoi clienti.

Dopo aver scelto una soluzione di ripristino di emergenza, assicurati di esercitarla. Consiglierei almeno una volta all'anno o ogni volta che la tua architettura cambia, a seconda di quale situazione si verifichi più spesso.

La continuità aziendale va ben oltre la semplice garanzia di avere accesso a backup leggibili. Ma limitando l'ambito della risposta a ciò, alla fine sarà fattibile solo dove la larghezza di banda end-to-end dal datacenter alla posizione di backup è sufficiente per gestire il volume delle modifiche ai dati.

Quando si parla di un datacenter, per la maggior parte delle persone si tratta di gigayte di dati a settimana.

IME, anche su piccola scala la soluzione migliore è un'operazione distribuita (o speculare). Pianificalo nel modo giusto e ci dovrebbe essere un piccolo costo aggiuntivo rispetto a un singolo datacenter.

Ma se devi copiare tutti i dati in una posizione di standby o anche solo in una memoria remota, allora

1) non usare FTP - è solo il modo sbagliato di farlo per molte ragioni

2) per i file generici, utilizzare qualcosa come rsync che è ottimizzato per lo scopo

3) per i database, guarda gli strumenti disponibili appositamente per il tuo DBMS: la struttura dei file può cambiare in modo massiccio senza che i dati cambino molto. NB questo include il registro MSWindows e i dati MSAD.

Abbiamo una VPN dal nostro ufficio al nostro datacenter esterno. Nel datacenter esterno abbiamo un server su cui è montata una condivisione di rete che configuriamo come destinazione nel nostro software di backup (eseguiamo Symantec BackupExec) ovvero \ OFFSITEDATACENTER \ OFFSITESTORAGE

Facciamo quindi - un backup completo durante il fine settimana in quella posizione
- un incremento ogni sera

Così come i nostri normali backup "onsite"

Eseguiamo anche VMWare VDR per acquisire immagini dei nostri server principali ogni settimana che vengono inserite su un disco SATA da 2 TB crittografato utilizzando FreeOTFE che porto a casa ogni settimana.

Disponiamo di un numero di data center separati attivi / attivi o attivi / semi-attivi con> 50 miglia tra loro, diversi fornitori di energia, sicurezza, collegamenti mesh da 10 GBps a percorso diverso tra loro, oh e spediamo anche i nostri dischi di backup tra di loro. Questo fa per noi.

Le specifiche di gestione di un determinato schema di backup sono state trattate fino alla nausea qui e altrove. Affronterò questa domanda da un punto di vista di alto livello delle linee guida generali per aiutarti a decidere come affrontare il ripristino di emergenza. Sono stato in parecchie situazioni in cui la pianificazione doveva essere in atto nel caso in cui il datacenter diventasse un cratere fumante. Per fortuna, abbiamo dovuto usarlo solo una volta. Le cose più importanti da ricordare sono:

1) Non perdere tempo a cercare di ingegnerizzare troppo e fai in modo che tutto fallisca con precisione <1ms se non devi. Un completo fallimento di tale entità giustificherà generalmente alcune ore di recupero.

2) Come corollario del n. 1, assicurati che le aspettative siano realisticamente determinate e codificate in una politica da qualche parte. Avere un obiettivo prefissato da raggiungere per quanto riguarda i tempi di recupero è importante, dal momento che puoi dedicare tempo illimitato e fare fondi è "ancora meglio".

3) Dai la priorità ai tuoi sistemi. Il piano di recupero deve essere costruito attorno a un elenco definitivo dell'importanza di ogni singolo sistema. Non perdere neanche le cose ovvie, come ottenere DNS e AD prima del resto dei server Windows.

4) Se non è fuori sede E fuori rete, è solo una copia. Ciò è perfettamente in linea con un'altra cosa fondamentale da ricordare: RAID non è un piano di backup.

5) Test, Test, TEST! Prova ogni centimetro del tuo piano che puoi. Se sei in grado di ottenere un fine settimana per un periodo di manutenzione, scollega l'uplink e / o la potenza dell'edificio e verifica i tempi di reazione e l'efficacia del tuo team. Un piano di ripristino di emergenza che non è mai stato testato è solo un pio desiderio.