Planeando una catástrofe


18

Trabajo para una pequeña empresa de marketing que también realiza diseño y desarrollo web. Hospedamos a todos nuestros clientes de diseño y desarrollo web en un servidor dedicado en Hostgator. Tenemos un servidor dedicado con discos duros configurados RAID 1. También hacemos copias de seguridad semanales que se automatizan a través de cPanel y se descargan mediante software FTP automatizado localmente.

Hoy estábamos discutiendo qué haríamos si Hostgator tuviera una falla catastrófica de algún tipo. Podría ser el servidor explotado, Hostgator tuvo serios problemas de red, el FBI realizó una de sus famosas redadas de "tomar todos los servidores que vemos", etc. Básicamente cualquier escenario en el que se espera una interrupción prolongada. Luego lo llevamos al siguiente nivel y nos preguntamos qué haríamos si Hostgator tuviera una interrupción prolongada y no pudiéramos acceder a nuestras copias de seguridad locales. Esto podría deberse a un incendio, una inundación, etc. Sé que las probabilidades de que nuestro servidor esté inactivo durante un período prolongado de tiempo y que nuestros archivos locales sean inaccesibles simultáneamente son remotos, pero todo lo que se necesita son solo doscosas malas que sucederán y ahí es donde estaríamos (Si alguna vez se pinchó una llanta y descubrió que su repuesto estaba desinflado o perdido, sabe lo fácil que es que sucedan dos cosas malas al mismo tiempo).

No es necesario decir que queremos estar preparados para los eventos de tipo "peor de los casos", ya que esto seguramente nos sacaría del negocio. Entonces mis dos preguntas son:

  1. ¿Qué podríamos hacer para estar preparados para una interrupción prolongada de Hostgator? Un escenario ideal tendrá los sitios web de nuestros clientes y, con suerte, correos electrónicos, funcionando de nuevo rápidamente.

  2. ¿Qué incluiría un sólido plan de respaldo para que nunca se pierdan datos importantes? Una solución ideal será automatizada.

Puede asumir que el costo no es un problema en sus respuestas, pero cuanto más asequibles sean las soluciones, mejor.


Parece que las respuestas aquí ya cubren mucho terreno bueno. Puedo garantizar que la nube de Amazon ha sido muy económica como una solución de respaldo hasta este momento. No se sabe lo que depara el futuro, pero si nada más, es una buena manera de aprender cómo funciona la nube.
JMC

Aquí está la calculadora de costos estimados para AWS si aún no la ha encontrado: calculator.s3.amazonaws.com/calc5.html
JMC

@ John Conde: ¿cuál fue su experiencia con HostGator, algún tiempo de inactividad importante? En caso afirmativo, ¿cuánto tiempo fue el mayor tiempo de inactividad que recuerdas?
Marco Demaio

@Marco Demaio, no hemos tenido ningún tiempo de inactividad con Hostgator. Han sido extremadamente confiables y su apoyo es fantástico.
John Conde

Respuestas:


15

Te sugiero que:

  1. Refleje automáticamente todo el contenido y la configuración de su servidor principal en un servidor de respaldo secundario en una red completamente separada en un centro de datos diferente. Use RSync, FXP, cPanel vudú o cualquier método que desee para automatizar la sincronización.

  2. Utilice el cambio de conmutación por error de DNS para enrutar automáticamente el tráfico al servidor de respaldo en caso de que el servidor Hostgator no responda.

Esto significa que constantemente tiene una copia de seguridad 'activa' esperando para salir en caso de que ocurra lo peor, en lugar de una copia de seguridad 'fría' que requiere intervención manual y mucha lucha y pánico. También significa que sus clientes nunca sabrán que su sitio se cayó antes que usted, lo que puede ser angustiante para todos.

Puede configurar DNS de conmutación por error utilizando un proveedor como DNS Made Easy . Para cada dominio que aloje, configuraría hasta cinco direcciones IP de respaldo, una para cada uno de sus servidores de respaldo. Una vez hecho eso ...

  1. DNS Made Easy verifica su servidor primario cada dos o cuatro minutos y, si no detecta una respuesta, enruta el tráfico a la dirección IP secundaria.

  2. DNS Made Easy continúa verificando el servidor primario. Cuando aparezca, redirigirá el tráfico al primer servidor o, si lo prefiere, lo mantendrá en la copia de seguridad mientras diagnostica lo que salió mal y repara el servidor primario.

Por supuesto, esta solución aumentará sus costos operativos, que de alguna manera tendrá que pasar a los clientes, pero, si se encuentra en una industria donde el tiempo de inactividad lo sacaría del negocio, probablemente valga la pena pagar por un servidor en gran parte redundante. eso por una vez salva a la empresa.

Más allá de eso:

Duplicar, duplicar, duplicar

Cuantas más copias de seguridad independientes tenga, mejor. Guardo copias de seguridad remotas en un disco duro local, que se refleja en un disco duro externo, en Dropbox, un repositorio git y una cuenta FTP remota. No te arriesgues. Duplica tanto como puedas. Si tiene que restaurar desde una copia de seguridad manual, es mejor tener cinco opciones que elegir una. La paranoia está subestimada.

Practique restaurar las copias de seguridad manualmente

Si nunca ha intentado recuperarse de una de sus copias de seguridad, ¿cómo sabe que funcionan? Vale la pena hacer simulacros de emergencia para ver qué sucedería si sus procedimientos automatizados fallaran.


ACTUALIZACIÓN: Algunos otros servicios que he descubierto recientemente que vale la pena mencionar en relación con la copia de seguridad del sitio, la recuperación ante desastres y el mantenimiento del tiempo de actividad:

  • Cloudflare, que proporciona funciones de seguridad y almacenamiento en caché para mantener los sitios activos cuando su servidor deja de funcionar . (Reflejan su sitio y lo sirven desde su caché distribuido globalmente en lugar de desde su servidor directamente).
  • Codeguard, que proporciona copias de seguridad automáticas y reversión del código del sitio web (solo FTP).
  • Site Auto Backup, que proporciona copias de seguridad automáticas y retrotracción del código del sitio web, datos de correo electrónico e información de MySQL a través de copias de seguridad de cPanel. Tenga en cuenta que esto lo ejecuta Hostgator, por lo que no es necesariamente adecuado si también aloja su sitio con ellos, pero podría ayudar a otros.

Cloudflare en particular parece que sería útil para evitar el tiempo de inactividad y mejorar en general la capacidad de respuesta del sitio.


No sabía que existía algo así como DNS. Esa sería una excelente manera de redirigir rápidamente los sitios en caso de que el servidor primario se caiga.
John Conde

También son excelentes para el alojamiento DNS general. Compro dominios de mi registrador favorito, pero uso DNS Made Easy para alojar los registros DNS. Tienen múltiples servidores de nombres en todo el mundo, por lo que los sitios se resuelven rápidamente, se cargan más rápido la primera vez y no se caen cuando los servidores de nombres de su registrador se ahogan. No es tan caro tampoco.
Nick

@Nick: aquí dicen que la conmutación por error de DNS (creo que el servicio que sintetiza en DNS Made Easy) no se recomienda: serverfault.com/questions/60553/… ¿Qué opinas?
Marco Demaio

@Marco Tienen razón al señalar que no es infalible, pero me funcionó muy bien para un par de pequeñas aplicaciones web que administro.
Nick

1
Por cierto, Stack Exchange también usa la conmutación por error de DNS. El centro de datos primario está en New Yourk, el secundario en Oregon. meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
Palec

6

La recuperación ante desastres puede ser una tarea enorme, especialmente cuando se trata de múltiples servidores, sitios y bases de datos. Dos elementos clave a tener en cuenta con la solución que seleccione son los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO).

RTO es esencialmente la expectativa de cuánto tiempo debería tomar hasta que los sitios vuelvan a funcionar. Si tiene un RTO de un minuto o dos (o menos), entonces debería considerar una solución en línea con lo que Nick sugirió que implica la replicación en tiempo real de sus archivos y datos a un centro de datos secundario y una conmutación por error automática de DNS que podría hacerse con un servicio pago o con hardware en ambos centros de datos (como el BIG-IP Global Traffic Managerde F5 Networks. Esto puede ser costoso, pero depende en gran medida de responder la pregunta "¿Cuál es el costo del tiempo de inactividad?" Si su RTO dura unas pocas horas o incluso unos pocos días, puede considerar los procedimientos de recuperación ante desastres que pueden involucrar una participación más manual, como poner en línea los servidores, cambiar de DNS, etc. Tedioso, pero ciertamente rentable si su RTO lo permite.

RPO es básicamente la frecuencia con la que se realizan las copias de seguridad y la cantidad de datos que está dispuesto a perder en caso de un desastre. Si los cambios en el contenido y / o los datos ocurren con frecuencia, entonces es probable que tenga un RPO de quizás minutos u horas y puede estar lidiando con la replicación en tiempo real o las copias de seguridad de alta frecuencia. Si el contenido no cambia con tanta frecuencia o si tiene clientes a los que no necesariamente les importa perder datos durante unos días, sus copias de seguridad pueden realizarse con menos frecuencia.

Como mencioné, estoy de acuerdo con mucho de lo que Nick tenía que decir. Otra alternativa que puede considerar es utilizar servicios basados ​​en la nube de uno de los proveedores más grandes basados ​​en la nube, como Rackspace o Amazon. Ambos proveedores en particular tienen una infraestructura masiva para poder manejar casi cualquier desastre que se les presente. Con algo como un sitio en la nube o un servidor en la nube (términos utilizados por Rackspace), tiene la ventaja de poder escalar también y no tiene que preocuparse necesariamente por el aspecto físico del hardware.

Rackspace también tiene opciones personalizadas disponibles donde puede mezclar su infraestructura, teniendo una combinación de servidores en la nube, servidores físicos y archivos en la nube como parte de su solución. Un enfoque híbrido puede ser algo a considerar dependiendo de las necesidades de su cliente si no desea adoptar un enfoque único para todos.

Si ayuda, también hay una página dedicada a la recuperación ante desastres en el sitio de Rackspace que se puede encontrar aquí . (También para el registro, no estoy afiliado a Rackspace, pero he usado sus servicios en el pasado).

Espero que esto haya ayudado.

EDITAR : pensé que esto podría ayudar si está evaluando soluciones en la nube. El Informe del Cuadrante Mágico de Gartner para Infraestructura y como Servicio y Hospedaje Web puede brindarle una idea de otros proveedores de soluciones.


Ni siquiera consideré usar el alojamiento en la nube como "servidor" de respaldo. Esa sería una forma muy económica de tener una copia de seguridad lista para funcionar rápidamente.
John Conde

2

La réplica completa del servidor en otra instalación de otra empresa de alojamiento parece la solución más obvia.

Los archivos pueden mantenerse sincronizados con herramientas como rsync y unison. Las copias de seguridad de SQL también se pueden sincronizar y luego cargar en el DB esclavo mediante scripts.


1

Asegúrese de ejecutar el control de versión de todo su código con un repositorio de código fuente (SVN o GIT). ¿Estás usando SVN o GIT?

Puede obtener una cuenta (gratuita o de pago) en un repositorio de terceros, como Project Locker , y si versiona todo su código mientras está trabajando, esencialmente tiene una copia de seguridad en su repositorio que está en una tercera ubicación . De este modo, disminuyen aún más sus posibilidades (casi nulas) de perder todo el trabajo a la vez.

Puede realizar sus confirmaciones / comprobaciones de SVN a través de la línea de comandos o mediante un cliente como Versiones (para Mac) o TortoiseSVN (para Windows).


El único problema con un repositorio de código fuente que no copia la base de datos o cualquier archivo subido por el usuario, etc
Daveo

Cierto. Pero puede crear un archivo de volcado de su base de datos y agregarlo al repositorio. Incluso podría escribir un guión para que sea un proceso automático. Con base de datos o sin ella, es al menos un lugar más para hacer una copia de seguridad de su código y sus activos, con el beneficio principal del control de versiones en todas esas cosas de todos modos.
Joel Glovier

Desafortunadamente no usamos control de versiones. De hecho, antes de comenzar aquí, ¡todo el trabajo se realizó en el sitio en vivo! Pude configurar un entorno de desarrollo localmente, así que al menos esa práctica está oficialmente muerta.
John Conde
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.