• Autor de la entrada:
  • Categoría de la entrada:Cloud
  • Comentarios de la entrada:Sin comentarios
  • Tiempo de lectura:6 minutos de lectura

Recientemente ha habido un desastre muy grande en el proveedor de hosting OVH. Han sufrido un incendio, y se les ha quemado un datacenter completo y parte de otro, dejando sin servicio a muchas webs y juegos online. Viendo cosas como esta causadas posiblemente por la falta de un plan de contingencia:

no he podido evitar pensar en cómo es posible que no dispusieran de algún plan de contingencia para sobrevivir a un desastre como este. Por poner un ejemplo, yo también he sufrido la pérdida de esta web debido a que estaba en uno de sus datacenters. Por suerte yo había pensado en la posibilidad de la pérdida total de mis datos, así que diseñé un plan de recuperación en caso de desastre. Esto ha permitido que mi web estuviera caída menos de 24h, siendo tan largo principalmente por el trabajo, la hora del incidente (madrugada), y que no es una web crítica. De haberme puesto en el momento del desastre, la web hubiese estado online de nuevo en poco más de hora y media. Eso contando con la compra del nuevo VPS, instalación de servicios, recuperación de los datos y verificación….

Es por eso que es muy importante que diseñéis un buen plan de contingencia. Para ello os daré unos cuantas pautas a seguir para diseñar el tuyo propio:

  • Piensa siempre en lo peor que pueda pasar
  • Diseña un plan de contingencia
  • Piensa en el plan de continuidad del negocio
  • Intenta reducir la posibilidad de desastre

Piensa siempre en lo peor que pueda pasar

Siempre que vayas a diseñar un plan de contingencia para tu web, es muy importante que pienses en lo peor que puede pasar. En mi caso lo peor que podía pasar es perder todo, así que diseñé mi plan de contingencia basándome en eso.

Diseña un plan de contingencia

Una vez que hayas pensado qué es lo peor que te puede pasar, es hora de que pienses en los siguiente puntos:

  • ¿Qué datos son importantes?. Piensa qué datos de tu aplicación son importante mantener. En mi caso lo son las configuraciones, los datos de la web y por supuesto, la BBDD.
  • ¿Cuál es el mejor método para realizar el backup?. En mi caso la web pesa poquito y la BBDD es de risa, por lo que con un simple script ha sido suficiente. En tu caso es muy importante que pienses si te sirve, o si por el contrario es mejor utilizar métodos más profesionales, como por ejemplo Snapshots, programas como Bareos…
  • Haz siempre los backups offsite. Pensando que es lo peor que te puede pasar, siempre estará la pérdida de todos los datos. Esto puede suceder por corrupción del sistema de ficheros, daños en el servidor irrecuperables, incendio… Por eso, es MUY IMPORTANTE que hagas tus backups fuera del servidor, en otra zona de disponibilidad, y a ser posible en otro país y otro proveedor. Por ejemplo, en mi caso el servidor es de OVH y estaba en Francia, así que decidí hacer los backups en AWS y en Irlanda. Gracias a que mi web es ligera, el coste es muy bajo (inferior a 1€ por 40 días de backup).
  • Si tienes posibilidad, guarda más de una copia en varios sitios. Esto ayudará a reducir las posibilidades de que se aplique la ley de Murphy y los datos de backup tampoco sean accesibles.

Piensa en el plan de continuidad del negocio

Tan importante es pensar en el plan de contingencia, como pensar en el plan de continuidad. Es por eso que es muy importante que lo tengas en cuenta a la hora de diseñar el plan de contingencia. Una vez ocurrido el desastre, no es igual descargar el fichero de un S3 regional, que solicitar la recuperación desde Glacier. La descarga del S3 regional será inmediata, mientras que la descarga desde Glacier se puede demorar hasta 12h. Es por eso que es bueno tener en cuenta lo siguiente:

  • Piensa en cómo vas a recuperar los datos una vez ocurrido el desastre.
  • Elige un almacenamiento que te ayude a reducir el tiempo de recuperación. Por ejemplo, los snapshots de discos son rápidos de recuperar.
  • Realiza pruebas de recuperación periódicamente para asegurarte de que es viable.
  • Automatiza lo máximo posible con plantillas de la infraestructura con herramientas como terraform, y/o de los servidores con salt o ansible. Esto ayudará a que estén en marcha lo antes posible y con la configuración correcta. Gracias a terraform y salt yo he sido capaz de reinstalar un servidor de Elasticsearch en menos de 15 minutos.

Intenta reducir la posibilidad de desastre. Intenta no necesitar el plan de contingencia

¡Pues claro!, obviamente es mucho mejor evitar el desastre que arreglarlo. Es por eso que si dispones de recursos y dinero es muy importante montar infraestructuras a prueba de desastres (dentro de lo posible):

  • Utiliza servicios gestionados con HA en varias regiones de disponibilidad.
  • Si no tienes más remedio que usar servicios en IAS, distribúyelos entre varias zonas de disponibilidad y varias regiones a ser posible. Esto ayudará a que en caso de desastre en uno de los datacenters, haya pocas posibilidades de que el servicio se vea afectado.
  • Inclínate por proveedores grandes, como GCP o AWS. Son más caros pero las garantías que dan también son mayores. En mi caso al ser un blog personal y no poder invertir mucho dinero, me he tenido que inclinar por hostings de bajo coste como OVH. Esto provoca que el rendimiento sea limitado y puedan ocurrir desastres como el acontecido. Además, el SLA de estos proveedores a pesar de ser parecido, dan muchos más problemas (créeme, lo hemos sufrido en otras ocasiones).

Espero que estos consejos os sirvan, y ¡no hagáis como Rust y perdáis vuestros valiosos datos!. Un saludo.

Daniel Carrasco

DevOps con varios años de experiencia, y arquitecto cloud con experiencia en Google Cloud Platform y Amazon Web Services. En sus ratos libres experimenta con Arduino y electrónica.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.