¿Cuál es su plan de recuperación ante desastres? [cerrado]

Question

¿Y qué recomendaría para una aplicación web ASP Net, con una base de datos de servidor SQL no tan grande (alrededor de 10 Gb)?

Me preguntaba, ¿es una buena idea tener una instancia de Amazon EC2 configurada lista para alojar su aplicación en una emergencia?

En este escenario, ¿cuál sería el mejor enfoque para mantener actualizada la base de datos (envío de registros? restauración manual de copia de seguridad?) y la forma más fácil y rápida de cambiar la configuración de dns?

Editar: el tiempo de inactividad aceptable sería entre 4 y 6 horas, por eso consideré usar la opción Amazon ec2 por su menor costo en comparación con el alquiler de un servidor secundario.

Answer 1

Actualización : acabo de ver tu comentario. Amazon EC2 con envío de registros es definitivamente el camino a seguir. No use la duplicación porque eso normalmente supone que la otra base de datos en espera está disponible. Cambiar su DNS no debería tomar más de 1/2 hora si configura su TTL para eso. Eso le daría tiempo para integrar los registros pendientes. Podría encender el servidor una vez por semana más o menos solo para integrar los registros que están pendientes (o menos para evitar acumular costos por hora).

---

Su ubicación de alojamiento principal debe tener redundancia en todos los niveles:

• Múltiples conexiones a internet,
• Múltiples firewalls configurados para conmutación por error,
• Múltiples servidores web en clúster,
• Múltiples servidores de bases de datos en clúster,
• Si almacena archivos, use una SAN o Amazon S3,
• Cada servidor debe tener algún tipo de RAID dependiendo del propósito del servidor,
• Cada servidor puede tener múltiples PSU conectadas a fuentes de alimentación / interruptores separados,
• Software de supervisión del servidor externo e interno,
• Generador de energía que se enciende automáticamente cuando se corta la energía, y un generador de respaldo, por si acaso.

Eso lo mantendrá ejecutándose en su ubicación principal en el caso de la mayoría de los escenarios de falla.

Luego, configure un único servidor en una ubicación remota que se mantenga actualizada mediante el envío de registros e inclúyalo en su script de implementación (después de que sus servidores de producción normales se actualicen ...) Un servidor ubicado en el otro lado del país hace muy bien para estos fines. Para minimizar el tiempo de inactividad de tener que cambiar a la ubicación secundaria, mantenga su TTL en los registros DNS lo más bajo posible.

Por supuesto, tanto hardware será empinado, por lo que deberá determinar qué vale la pena estar inactivo durante 1 segundo, 1 minuto, 10 minutos, etc. y ajustarlo en consecuencia.

Answer 2

Todo depende de cuáles sean sus requisitos de tiempo de inactividad. Si tiene una copia de seguridad en segundos para no perder su negocio multimillonario, entonces hará las cosas de manera muy diferente a si tiene un sitio que lo haga tal vez $ 1000 / mes y cuyos ingresos no se verán notablemente afectados si está fuera de servicio por un día.

Sé que esa no es una respuesta particularmente útil, pero esta es un área grande, con muchas variables, y sin más información es casi imposible recomendar algo que realmente funcione para su situación (ya que realmente no saber cuál es su situación).

Answer 3

El punto de partida para una estrategia DR sólida como una roca es primero determinar cuál es el costo real para el negocio del tiempo de inactividad de su servidor / plataforma.

El siguiente artículo lo ayudará a comenzar en la línea correcta.

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

Si necesita más pautas, el viejo Google puede proporcionar mucha más lectura.

Un proyecto de esta naturaleza requiere que colabore con sus tomadores de decisiones comerciales clave y deberá comunicarles cuáles son los costos asociados del tiempo de inactividad y cuál sería el impacto comercial. Es probable que necesite colaborar con varias unidades de negocios para recopilar la información requerida. En conjunto, debe tomar una decisión sobre lo que se considera un tiempo de inactividad aceptable para su negocio. Solo entonces puede diseñar una estrategia de recuperación ante desastres para cumplir con estos requisitos.

También encontrará que la realización de este ejercicio puede resaltar las deficiencias en la configuración actual de sus plataformas con respecto a la alta disponibilidad y esto también puede ser revisado como un proyecto aparte.

El punto clave que se debe sacar de todo esto es que la decisión sobre qué es un período aceptable de tiempo de inactividad no es solo para que el DBA decida, sino para proporcionar la información y el conocimiento experto necesarios para que una decisión realista pueda ser alcanzado. Su tarea es implementar una estrategia que pueda cumplir con los requisitos del negocio.

Don & # 8217; no olvide probar su estrategia de DR realizando un escenario de prueba para validar sus tiempos de recuperación y practicar el proceso. Si llega el momento en que necesite implementar su estrategia de recuperación ante desastres, es probable que esté bajo presión, su teléfono sonará con frecuencia y la gente estará cerca de usted como mosquitos. Después de haber perfeccionado y practicado su respuesta de DR, puede confiar en tomar el control de la situación e implementar la recuperación será un proceso sin problemas.

Buena suerte con tu proyecto.

Answer 4

No he trabajado con diferentes herramientas de terceros, pero he experimentado nubosidad, y en cuanto a la réplica que obtienes, puedo decir que es un producto de muy alta calidad. La replicación se realiza en intervalos de tiempo realmente pequeños, lo que hace que su réplica sea muy confiable, pero puedo ver que no necesita que su sitio vuelva a funcionar en segundos, por lo que tal vez solicitar una oferta de precio o salirse con un proveedor diferente podría ayudar.