Qual è il tuo piano di ripristino di emergenza? [chiuso]

Question

E cosa consiglieresti per un'applicazione web ASP Net, con un database SQL Server non così grande (circa 10 Gb)?

Mi stavo solo chiedendo, è una buona idea avere un'istanza Amazon EC2 configurata pronta per ospitare la tua app in caso di emergenza?

In questo scenario, quale sarebbe l'approccio migliore per mantenere aggiornato il database (log shipping? ripristino manuale del backup?) e il modo più semplice e veloce per modificare le impostazioni DNS?

Modifica: il tempo di inattività accettabile sarebbe tra le 4 e le 6 ore, ecco perché ho preso in considerazione l'utilizzo dell'opzione Amazon ec2 per il suo costo inferiore rispetto al noleggio di un server secondario.

Answer 1

Aggiorna - Ho appena visto il tuo commento. Amazon EC2 con log shipping è sicuramente la strada da percorrere. Non utilizzare il mirroring perché normalmente si presume che sia disponibile l'altro database di standby. La modifica del DNS non dovrebbe richiedere più di 1/2 ora se si imposta TTL su quello. Ciò ti darebbe il tempo di integrare tutti i registri in sospeso. Potrebbe accendere il server una volta a settimana o giù di lì solo per integrare i registri in sospeso (o meno per evitare di accumulare costi orari).

---

La posizione di hosting principale dovrebbe avere ridondanza a tutti i livelli:

• Più connessioni Internet,
• Più firewall impostati su failover,
• Più server Web cluster,
• Più server di database in cluster,
• Se memorizzi i file, utilizza una SAN o Amazon S3,
• Ogni server dovrebbe avere una qualche forma di RAID a seconda dello scopo del server,
• Ogni server può avere più alimentatori collegati a fonti di alimentazione / interruttori separate,
• Software di monitoraggio server esterno ed interno,
• Generatore di corrente che si accende automaticamente quando si spegne e un generatore di riserva per buona misura.

Ciò ti consentirà di rimanere nella posizione principale in caso di maggior parte degli scenari di errore.

Quindi, impostare un singolo server in una posizione remota che viene mantenuto aggiornato utilizzando la distribuzione dei log e includerlo nello script di distribuzione (dopo l'aggiornamento dei normali server di produzione ...) Un server associato nell'altra parte del paese fa bene per questi scopi. Per ridurre al minimo i tempi di inattività dovuti al passaggio alla posizione secondaria, mantieni il tuo TTL sui record DNS il più basso possibile.

Ovviamente, così tanto hardware sarà ripido, quindi dovrai determinare cosa vale la pena abbassare per 1 secondo, 1 minuto, 10 minuti, ecc. e regolare di conseguenza.

Answer 2

Tutto dipende dai requisiti di downtime. Se hai ottenuto di eseguire il backup in pochi secondi per non perdere la tua attività da molti miliardi di dollari, allora farai le cose in modo molto diverso se hai un sito che ti rende forse $ 1000 / al mese e le cui entrate non saranno notevolmente influenzate se in calo per un giorno.

So che non è una risposta particolarmente utile, ma questa è una grande area, con molte variabili e senza ulteriori informazioni è quasi impossibile raccomandare qualcosa che effettivamente funzionerà per la tua situazione (dal momento che non sapere qual è la tua situazione).

Answer 3

Il punto di partenza per una solida strategia DR è quello di capire innanzitutto quale sia il vero costo per il business dei tempi di inattività del server / della piattaforma.

Il seguente articolo ti farà iniziare nella giusta direzione.

https : //web.archive.org/web/1/http: //articles.techrepublic%2ecom%2ecom/5100-10878_11-1038783.html

Se hai bisogno di ulteriori linee guida, il buon vecchio Google può fornire molte più letture.

Un progetto di questo tipo richiede la collaborazione con i principali responsabili delle decisioni aziendali e sarà necessario comunicare loro quali sono i costi associati ai tempi di inattività e quale sarebbe l'impatto sul business. Probabilmente dovrai collaborare con diverse unità aziendali per raccogliere le informazioni richieste. Collettivamente è quindi necessario prendere una decisione su ciò che è considerato downtime accettabile per la tua attività. Solo allora puoi escogitare una strategia di DR per soddisfare questi requisiti.

Scoprirai inoltre che condurre questo esercizio potrebbe evidenziare carenze nella configurazione attuale delle tue piattaforme per quanto riguarda l'alta disponibilità e potrebbe anche essere necessario rivederlo come progetto a parte.

Il punto chiave da togliere a tutto ciò è che la decisione su quale sia un periodo di inattività accettabile non spetta solo al DBA, ma piuttosto a fornire le informazioni e le conoscenze degli esperti necessarie affinché una decisione realistica possa essere raggiunto. Il tuo compito è implementare una strategia in grado di soddisfare i requisiti aziendali.

Don & # 8217; t dimentica di testare la tua strategia di DR conducendo uno scenario di test per convalidare i tempi di recupero e mettere in pratica il processo. Se dovesse venire il momento in cui dovessi implementare la tua strategia di DR probabilmente sarai sotto pressione, il tuo telefono squillerà frequentemente e le persone si libreranno intorno a te come zanzare. Avendo già affinato e messo in pratica la tua risposta alla DR, puoi essere sicuro di assumere il controllo della situazione e attuare il recupero sarà un processo regolare.

Buona fortuna con il tuo progetto.

Answer 4

Non ho lavorato con diversi strumenti di terze parti ma ho sperimentato il cloudendure e, per quanto riguarda la replica ottenuta, posso dire che è un prodotto davvero di fascia alta. La replica viene eseguita in intervalli di tempo davvero minuscoli, il che rende la tua replica molto affidabile, ma posso vedere che non hai bisogno di eseguire il backup del tuo sito in pochi secondi, quindi forse chiedere un'offerta di prezzo o scappare con un altro fornitore potrebbe essere d'aiuto.