Pianificazione per catastrofe


18

Lavoro per una piccola società di marketing che si occupa anche di web design e sviluppo. Ospitiamo tutti i nostri clienti di progettazione e sviluppo web su un server dedicato presso Hostgator. Abbiamo un server dedicato con dischi rigidi configurati RAID 1. Eseguiamo anche backup settimanali automatizzati tramite cPanel e scaricati localmente da software FTP automatizzato.

Oggi discutevamo di cosa faremmo se Hostgator avesse un fallimento catastrofico di qualche tipo. Potrebbe essere il server esploso, Hostgator ha avuto seri problemi di rete, l'FBI ha fatto uno dei loro famosi raid "prendi tutti i server che vediamo", ecc. Praticamente qualsiasi scenario in cui si prevede un'interruzione prolungata. Abbiamo quindi portato al livello successivo e ci siamo chiesti cosa faremmo se Hostgator avesse un'interruzione prolungata e non fossimo in grado di accedere ai nostri backup locali. Ciò potrebbe essere dovuto a incendi, alluvioni, ecc. So che le probabilità che il nostro server rimanga inattivo per un lungo periodo di tempo e che i nostri file locali contemporaneamente inaccessibili siano remoti ma tutto ciò che serve è solo dueaccadono cose brutte ed è lì che staremmo. (Se hai mai avuto una gomma a terra e hai scoperto che la ruota di scorta era piatta o mancante, sai quanto è facile che accadano simultaneamente due cose cattive).

Inutile dire che vogliamo essere preparati per eventi di tipo "scenario peggiore" in quanto ciò ci farebbe quasi certamente fallire. Quindi le mie due domande sono:

  1. Cosa potremmo fare per essere preparati per un'interruzione prolungata di Hostgator? Uno scenario ideale avrà i siti Web dei nostri clienti e, si spera, e-mail, funzionanti e funzionanti rapidamente.

  2. Cosa includerebbe un solido piano di backup in modo che i dati importanti non vengano mai persi? Una soluzione ideale sarà automatizzata.

Puoi presumere che il costo non sia un problema nelle tue risposte, ma più una soluzione è conveniente, meglio è.


Sembra che le risposte qui coprano già un buon terreno. Posso garantire che Amazon cloud è stato molto economico come soluzione di backup fino a questo punto. Non dire cosa riserva il futuro, ma se non altro, è un buon modo per imparare come funziona il cloud.
JMC,

Ecco il calcolatore dei costi stimati per AWS se non l'hai ancora incontrato: calcolatrice.s3.amazonaws.com/calc5.html
JMC

@John Conde: qual è stata la tua esperienza con HostGator, qualche grande downtime? Se sì, per quanto tempo hai ricordato i principali tempi di inattività?
Marco Demaio,

@Marco Demaio, non abbiamo avuto alcun tempo morto con Hostgator. Sono stati estremamente affidabili e il loro supporto è fantastico.
John Conde

Risposte:


15

Ti suggerirei di:

  1. Eseguire il mirroring automatico dell'intero contenuto e della configurazione del server principale su un server di backup secondario su una rete completamente separata in un data center diverso. Usa RSync, FXP, cPanel voodoo o qualunque metodo desideri automatizzare la sincronizzazione.

  2. Utilizzare il passaggio al failover DNS per indirizzare automaticamente il traffico al server di backup nel caso in cui il server Hostgator non risponda.

Ciò significa che hai costantemente un backup "caldo" in attesa di andare nel caso in cui dovesse accadere il peggio, piuttosto che un backup "freddo" che richiede un intervento manuale e molta confusione e panico. Significa anche che i tuoi clienti non sapranno mai che il loro sito è stato chiuso prima di te, il che può essere angosciante per tutti.

È possibile impostare il DNS di failover utilizzando un provider come DNS Made Easy . Per ogni dominio che stai ospitando, dovresti impostare fino a cinque indirizzi IP di backup, uno per ciascuno dei tuoi server di backup. Una volta fatto ...

  1. DNS Made Easy controlla il tuo server primario ogni 2-4 minuti e, se non rileva una risposta, indirizza il traffico verso l'indirizzo IP secondario.

  2. DNS Made Easy continua a controllare il server primario. Quando si presenta, reindirizzerà il traffico al primo server o, se preferisci, lo manterrà nel backup mentre diagnostichi cosa è andato storto e risolvono il server primario.

Naturalmente, questa soluzione aumenterà i costi operativi, che dovrete in qualche modo passare ai clienti, ma — se siete in un settore in cui i tempi di inattività vi metterebbero fuori servizio — probabilmente vale la pena pagare per un server ampiamente ridondante per quella volta salva l'azienda.

Oltre a questo:

Duplica, duplica, duplica

Più backup indipendenti hai, meglio è. Conservo i backup remoti su un disco rigido locale, che è speculare su un disco rigido esterno, su Dropbox, un repository git e un account FTP remoto. Non correre rischi. Duplica il più possibile. Se è necessario ripristinare da un backup manuale, è meglio avere una scelta di cinque rispetto a una scelta di uno. La paranoia è sottovalutata.

Esercitati a ripristinare i backup manualmente

Se non hai mai provato a ripristinare da uno dei tuoi backup, come fai a sapere che funzionano? Vale la pena fare esercitazioni di emergenza per vedere cosa succederebbe se le tue procedure automatizzate fallissero.


AGGIORNAMENTO: Alcuni altri servizi che ho scoperto di recente che vale la pena menzionare in relazione al backup del sito, al ripristino di emergenza e al mantenimento dei tempi di attività:

  • Cloudflare, che fornisce funzionalità di sicurezza e memorizzazione nella cache per mantenere i siti attivi quando il server non funziona. (Rispecchiano il tuo sito e lo pubblicano dalla loro cache distribuita a livello globale anziché direttamente dal tuo server.)
  • Codeguard, che fornisce backup automatici e rollback del codice del sito Web (solo FTP).
  • Site Auto Backup, che fornisce backup automatici e rollback di codice di siti Web, dati e-mail e informazioni MySQL tramite backup cPanel. Si noti che questo è gestito da Hostgator, quindi non è necessariamente adatto se si ospita anche il sito con loro, ma potrebbe aiutare gli altri.

Cloudflare in particolare sembra utile per evitare tempi di inattività e migliorare generalmente la reattività del sito.


Non sapevo che esistesse qualcosa di simile al DNS reso facile. Sarebbe un ottimo modo per reindirizzare rapidamente i siti in caso di inattività del server primario.
John Conde

Sono ottimi anche per l'hosting DNS generale. Compro domini dal mio registrar preferito ma utilizzo DNS Made Easy per ospitare i record DNS. Hanno più nameserver in tutto il mondo, quindi i siti si risolvono rapidamente, si caricano più velocemente la prima volta e non si arrestano quando i server dei nomi del registrar soffocano. Non è neanche così costoso.
Nick,

@Nick: qui dicono che il failover DNS (penso che il servizio che cerchi più facilmente in DNS Made Easy) non sia raccomandato: serverfault.com/questions/60553/… Cosa ne pensi?
Marco Demaio,

@Marco Hanno ragione a sottolineare che non è infallibile, ma ha funzionato benissimo per me per un paio di piccole app web che gestisco.
Nick,

1
A proposito, Stack Exchange utilizza anche il failover DNS. Il data center primario si trova a New Yourk, secondario in Oregon. meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
Palec

6

Il ripristino di emergenza può essere un compito enorme, soprattutto quando si ha a che fare con più server, siti e database. Due elementi chiave da prendere in considerazione con la soluzione selezionata sono gli obiettivi del tempo di recupero (RTO) e gli obiettivi del punto di recupero (RPO).

RTO è essenzialmente l'aspettativa di quanto tempo dovrebbe essere necessario per il backup dei siti. Se hai un RTO di un minuto o due (o meno), dovresti prendere in considerazione una soluzione in linea con ciò che Nick ha suggerito che prevede la replica in tempo reale dei tuoi file e dati su un data center secondario e il failover automatico del DNS che potrebbe essere eseguito con un servizio a pagamento o con hardware in entrambi i data center (come BIG-IP Global Traffic Managerdalle reti F5. Questo può essere costoso, ma dipende in gran parte dalla risposta alla domanda "Qual è il costo dei tempi di fermo?" Se il tuo RTO è di poche ore o anche di qualche giorno, puoi prendere in considerazione procedure di ripristino di emergenza che potrebbero comportare un maggiore coinvolgimento manuale come portare server online, cambiare DNS, ecc. Tedioso, ma sicuramente conveniente se l'RTO lo consente.

RPO è fondamentalmente la frequenza con cui vengono eseguiti i backup e la quantità di dati che si è disposti a perdere in caso di disastro. Se le modifiche al contenuto e / o ai dati si verificano frequentemente, è probabile che tu abbia un RPO di forse minuti o ore e potresti avere a che fare con la replica in tempo reale o backup ad alta frequenza. Se il contenuto non cambia così spesso o hai clienti a cui non importa necessariamente che perdano dati per alcuni giorni, i tuoi backup possono avvenire meno spesso.

Come ho già detto, sono d'accordo con gran parte di ciò che Nick aveva da dire. Un'altra alternativa che potresti prendere in considerazione è quella di utilizzare i servizi basati su cloud da uno dei maggiori fornitori basati su cloud come Rackspace o Amazon. Entrambi questi fornitori, in particolare, dispongono di enormi infrastrutture per essere in grado di gestire praticamente qualsiasi catastrofe. Con qualcosa come un sito cloud o un server cloud (termini usati da Rackspace), hai il vantaggio di essere in grado di ridimensionare e non devi necessariamente preoccuparti dell'aspetto fisico dell'hardware.

Rackspace ha anche opzioni personalizzate in cui puoi mescolare la tua infrastruttura, avendo una combinazione di server cloud, server fisici e file cloud come parte della tua soluzione. Un approccio ibrido può essere qualcosa da considerare a seconda delle esigenze del cliente se non si desidera adottare un approccio a taglia unica.

Se aiuta, c'è anche una pagina dedicata al disaster recovery sul sito Rackspace che puoi trovare qui . (Anche per la cronaca, non sono affiliato a Rackspace, ma ho usato i loro servizi in passato).

Spero che questo abbia aiutato.

EDIT : pensato che questo potrebbe aiutare se stai valutando soluzioni cloud. Il report Quadrante magico di Gartner per l'infrastruttura e come servizio e hosting Web può fornire informazioni dettagliate su altri fornitori di soluzioni.


Non ho mai nemmeno considerato l'uso del cloud hosting come "server" di backup. Sarebbe un modo molto economico per avere un backup pronto per andare rapidamente.
John Conde

2

La replica completa del server in un'altra struttura di un'altra società di hosting sembra la soluzione più ovvia.

I file possono essere sincronizzati con strumenti come rsync e unison. Anche i backup SQL possono essere risincronizzati e quindi caricati nel database slave tramite script.


1

Assicurati di eseguire il controllo versione di tutto il tuo codice con un repository di codice sorgente (SVN o GIT). Stai usando SVN o GIT?

È possibile ottenere un account (gratuito o a pagamento) in un repository di terze parti, come Project Locker , e se si esegue la versione di tutto il codice mentre si sta lavorando, in pratica è stato eseguito il backup di tutto sul proprio repository che si trova in una terza posizione . Riducendo ulteriormente le possibilità (quasi a zero) di perdere tutto il lavoro in una volta.

Puoi eseguire i tuoi commit / checkout SVN dalla riga di comando o tramite un client come Versions (per Mac) o TortoiseSVN (per Windows).


Unico problema con un repository di codice sorgente non esegue il backup del database o di eventuali file caricati dall'utente ecc.
Daveo,

Vero. Ma puoi creare un file di dump del tuo database e aggiungerlo al repository. Potresti persino scrivere uno script per renderlo un processo automatico. Con il database o senza, è almeno un altro posto in cui eseguire il backup del codice e delle risorse, con il vantaggio principale del controllo della versione su tutte quelle cose.
Joel Glovier,

Sfortunatamente non utilizziamo il controllo versione. In effetti, prima di iniziare qui, tutto il lavoro è stato fatto sul sito live! Sono stato in grado di creare un ambiente di sviluppo localmente, quindi almeno questa pratica è ufficialmente morta.
John Conde
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.