Planeando una catástrofe

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.

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.

• 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.

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.

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.

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).