OVH DRP
El Plan de Recuperación de Desastres (DRP – Disaster Recovery Plan) es ese gran olvidado, en el peor de los casos, y minusvalorado en la gran mayoría de los que al menos lo tiene como parte de su actividad empresarial o profesional. El incendio en OVH de varios de los bloques que conforman el centro de datos de Estrasburgo, con la pérdida de más de 10000 servidores, afectando a 3,6 millones de páginas, y la desconexión total de centro de datos, por estar afectados de forma total o parcial, el pasado día 10 de marzo, ha puesto de manifiesto, las deficiencias en este tipo de contingencias.
Contenidos
Está bien que OVH venda y anime a los empresarios, a la obligación que tienen como tales, de tener un plan de recuperación de desastres, pero el desastre dejó graves fallas que OVH deberá revisar.
Los usuarios de VPS de OVH, han visto como el pagar por sistemas de backups y snapshots, no les ha servido de mucho pues dichos sistemas estaban ubicados en el propio datacenter o en su defecto.
O como algún cliente nuestro que tiene sistema de failover y backup continuo con nosotros, y pese a tener contratado Backup automatizado (con un precio más que elevado) y snapshots, adía de hoy (4 días después) todavía su servidor VPS ha sido entregado SIN Backup y sin Snapshots, por lo que entendemos que esta «desaparecido». Es decir, sus servicios con OVH en este caso, están a día de hoy desaparecidos, pese a que contrataron esos servicios de protección contra desastres.
Sin embargo, debido a los servicios que les prestamos sus contenido esta operativo al 100% desde la misma mañana del incendio en su máquina failover dentro de nuestros servicios y a la espera de que los servicios de OVH sean restaurados de forma efectiva
Tremendo error, que muchos pagarán con creces, si no tenían un sistema alternativo. Este problema es doble. Por un lado, una empresa como OVH debería tener los sistemas de backup y snapshots en otros centros de datos, y por otro, el contratante, de empresa o profesional, debería informarse de la cualidad y especificación de esos servicios adicionales, ya que muchos de ellos, llevan aviso en sus condiciones de contratación que ciertamente, dejan claro que su utilidad en cuanto a la planificación de contingencias graves es inútil y sin responsabilidad por parte de OVH.
De los temas relativos a NAS HA, no puedo opinar pues no he tenido que atender a ningún cliente afectado por este servicio ya que hace años (desde 2011) que deje de usar dicho servicio, y por supuesto de recomendárselo a ningún cliente en mi propuestas técnicas en planes de despliegue en la nube, ya que hasta en tres ocasiones, un simple fallo en discos, me demostró que la existencia de HA en los discos NAS HA, era una fachada que no fue aplicada en ninguno de los casos en los que los discos alcanzaron una condición de error.
Otro de los elementos que más daño pudo hacer también OVH en su falla en el sistema de comunicación con clientes y técnicos encargados de los planes de recuperación, fue que en la intranet de clientes de OVH, la información sobre el problema no estaba diseñada. En su lugar se limitaron a «desaparecer» los elementos (servicios) contratados por los clientes afectados, tanto en la propia intranet como en la API. Esto llevo a responsables externos como nosotros, a tener que esperar unas horas de oro, hasta ubicar el incidente, en Twitter cuando a las 3:42 del 10 de marzo, Octave Klaba, CEO de OVH, notificaba a través de la red Twitter el desastre que se avecinaba.
Aquí entramos ya de lleno en la responsabilidad de los responsables de datos de las empresas contratantes de servicios de OVH, ya que son varios los escenarios, que queremos describir de mayor a menor.
Es importante entender, que con la salvedad de apreciaciones legales que puedan o no ser discutibles desde el plano legal, aquí hablamos del plano técnico.
Las empresas y profesionales que tenían un plan de recuperación de desastres, diseñado y ejecutado, pudieron recuperar casi toda la información perdida y volver a poner en marcha todos sus sistemas afectados en tiempos que van desde las 3 horas hasta las 8 horas.
Aquí hablamos de un mínimo número de casos, entre los que se incluyen algunos correspondientes a organismos gubernamentales del Reino Unido, de Francia, Africa y algunas empresas tecnológicas cuyos planes estaban bien diseñados.
Un punto óptimo entre el Punto Objetivo de Recuperación (Recovery Point Objective – RPO) y el Tiempo Objetivo de Recuperación (Recovery Time Objective (RTO – time intervals)).
Evidentemente aquí hablamos de distintos factores, para distinguir entre compañías por su volumen de negocios y/o la naturaleza de sus servicios, para entender cuál es el punto razonable de las inversiones necesarias en unos y otros casos.
Los factores hacen la diferencia entre planes de recuperación de desastres son muchos y variados. Alguno surgen de la falta de experiencia o de la toma de decisiones, que por desconocimiento o por falta de visión, nos pueden llevar a engaños, cuyo coste en el momento de la ejecución del plan pueden hacer la diferencia, no sólo en términos de eficacia y/o de visualización negativa de la marca, sino en términos económicos, pues a fin de cuentas, cada dato perdido es dinero y cada minuto sin estar arriba, es dinero.
| Proceso del Plan | Modelos | Incidencia |
|---|---|---|
| Verificación regular del RDP | Cada vez que se incorpora un nuevo elemento afectado por el proceso | Tiempo de recuperación menor y porcentaje de resultados mas elevado |
| De forma regular pero no implicada en cambios | Posibilidad de fallas que requieran mas tiempo o imposibilidad de recuperación de ciertos datos | |
| Sin verificación del RDP (testing) | Posibilidad elevada de fallas en el proceso (parcial o total) | |
| Recuperacion de datos (red) | Conexión 1Gbps o mayor | Rápida restauración de elevadas cantidades de datos. Un 1Tb en 800/1024 Mpbs no tarda mas de 3 horas |
| Conexiones limitadas a 500, 300 Mbps | Reducción drástica de la capacidad para transmitir datos y por tanto, el tiempo de recuperación aumenta de forma casi exponencial. Por ejemplo 1TB en una conexión de 300/500 Mpbs tarda mas 6 horas | |
| Conexiones de 100 Mbps | Pueden ser desastroso y sin embargo es la norma en la mayoría de los sistema de recuperación de datos basados en AWS, Azure cuya tasa ni alcanza en la mayoría de los casos los 80Mbps, pero que suelen ser los elegidos por el descenso de costes (que no llega al 15% de los costes en una solución a medida). Podemos hablar de hasta 24 horas | |
| Modelo encriptado | Servidor de backups bajo coste 12 | Aumento ~ x10 de los tiempos de recuperación frente al modelo no encriptado |
| Servidor de backups alto rendimiento | Solución muy costosa | |
| Backup tradicional progresivo o diferencial | Aumento de los tiempos de recuperación de datos y posibles fallas en la recuperación total | |
| Backup incremental continuo | La máxima velocidad con menor coste de almacenamiento y múltiples puntos de recuperación | |
| Tipo de Software | Propio | El software propio, es en la mayoría de los casos, no solo más económico en cuanto a términos de ROI (Retorno de la inversion), sino en términos de preparación del personal frente a los momentos de aplicación del Plan, sino en la minimización de posibles errores surgidos durante la aplicación del mismo (bugs) 3 |
En esta categoría tenemos la gran mayoría de las empresas, que si bien recuperó la información al completo o con carencías no muy elevadas, la puesta a punto de sus sistemas afectados, tardó más allá de las 8 horas, llegando en algunos casos a prolongarse por 72 ó más horas.
El coste de su error en el diseño del Plan de Recuperación de Desastres, a dañado a la marca, los esfuerzos ahora para reparar la imágen son mayores, y probablemente, se sufran perdidas de clientes y y la recuperación económica sea más larga.
Son múltiples los factores que llevan a esta lentitud, entre los que debo destacar:>
En cualquier caso, los daños colaterales para estas empresas, son meramente visibles a sus clientes y afectados, y sus consecuencias dependen en muchos casos de la habilidad de sus responsables de comunicación para suavizar la triste realidad de en cierta medida, parte de los problemas de sus usuarios, pudo haber sido evitada.>
En este caso me vi afectado hace ya unos años, en los que por cuestiones económicas y consciente de ello, no tenía parque de reserva frente a una posible incidencia. Cuando esta llegó, un error en el sistema de instalación del sistema operativo que usaba, en mis máquinas de OVH, me dejó sin servicio. El cansancio y las malas decisiones producto del estrés que estas situaciones conlleva, me llevó a otro desastre encadenado. 16 horas para conseguir que OVH declarara el incidente como bug, momento en el cual tuve toda su ayuda. El desastre me duró dos días, que se hubieran evitado con algo que desde hace 25 años había mantenido. Tener máquinas en reserva, listas para usar.
De estas situaciones, hay dos escenarios posibles. Aprender y modificar el plan de recuperación de desastres, y dar la importancia debida a los costes ocultos de este plan, y su importancia de implementarlos.
Este es uno de los escenarios a buen seguro de más del 80% de los clientes que a buen seguro han perdido mucho, casi todo o todo. Los escenarios son múltiples y diferentes, pero todos llevan a un escenario en algunos casos, terroríficos y en algunos, incluso deja empresas abocadas al hundimiento y cierre.
Esto no es una afirmación baladí, ya que el al menos el 90% de las empresas que sufren un desastre en sus infraestructuras IT y no tiene un Plan de recuperación de desastres, no sobreviven al desastre, según el estudio Touch Ross Study. Y muchos de estos incidentes, están teniendo más repercusión debido a los blockchains que a incendios en empresa, centros de datos, ya que eston son más visibilizados por la prensa y los medios.
En los últimos tiempos, la escena ha puesto en evidencia muchos desastres por motivos diferenciados y muy distintos.
Esto es algo que dependerá mucho del tamaño de la empresa, su modelo de negocio, su capacidad de comunicación, pero en cualquier caso, los cálculos existentes en distinto estudio indican que la diferencia entre un plan adecuado y uno deficitario multiplica por 200 el coste por minuto.
Desde hace años, en Castris, uso y pongo a disposición de mis clientes, sistemas dobles de protección de datos para servidores Web y de correo, basados en mi propio software por los motivos que he expuesto con anterioridad. He trabajado con dos de los más conocidos en el mundo de las copia de seguridad cuyo nombre prefiero no mencionar, y ellos me sirvieron para entender, que un tema tan sensible como la recuperación de datos en momentos tan delicados, es prioritario, que funcione como uno desea, y tener el control absoluto. Las fallas que ambos me produjeron, ya fuera por excesiva lentitud, o por los propios errores en la recuperación de datos, me llevaron a abandonar este tipo de soluciones. El valor estratégico de una solución propia, a medida de las necesidades reales, es ya de per se, motivo más que suficiente para la inversión en I+D que supone crearla y mantenerla. Por otro lado, el ROI de una solución así, supera con creces los costes de mantenimiento de tan costosas licencias y nos libera del elevadísimo coste de soportes level 4, necesarios si en realidad queremos que el software sea inmune a fallas durante el proceso o al menos tenga un nivel de soporte adecuado a esas fallas.
Sirva este artículo para avisar al lector, si por razón de su negocio o de su cargo tiene responsabilidades ya sean propias o de terceros, tomar conciencia de la importancia de un plan de recuperación de desastres, en el cual se analicen todos los posibles escenarios, los tiempos de recuperación, los costes posibles más allá de la economía inmediata, mala consejera donde las halla, con el fin de que dicho plan nos permita sortear los escenarios más dispares, que si bien, estos sean cuasi imposible ser alcanzados por mera estadística, a alguien le puede tocar ser victima de esa situación, momento en el cual, esta y otras recomendaciones como las del INCIBE Plan de Contingencia y continuidad de negocio, puedan ser la diferencia que marque el principio del fin, de un simple incidente superado con la mejor de las actuaciones.
De este incidente, pese a que mis dos clientes tuvieron online a primeras horas de la mañana sus negocios, también he aprendido. Así pues, una vez de más de cada escenario adverso, debemos y podemos obtener valiosos aprendizajes.
En Castris diseñamos Planes de Recuperación de Desastres para empresas y profesionales, ocupándonos de todos los elementos que lo componen y ofreciendo las mejores soluciones a cada cliente, de acuerdo a sus diferentes necesidades.
En especial atención a clientes de Castilla y León, Cantabria y Comunidad de Madrid.
1 Muchos de los modelos de servidor utilizados en los Planes de Recuperación de Desastres y que ofertan los comerciales de empresas del sector, son equipos, especializados en el almacenamiento de grandes cantidades de datos, pero poco potentes en cuanto a tareas de CPU, e incluso sin tarjetas de RAID usando emulación por software. Esto puede ser un serio hándicap a la hora de la recuperación de datos, ya que la lentitud en la emisión de datos desencriptados es terrorífica y directamente proporcional a la potencia de CPU/Discos
2 La necesidad de encriptación es una falacia cuando hablamos de un entorno privado, siempre y cuando se tomen las medidas de seguridad habituales y necesarias en el servidor de backup, tales como ser usado única y exclusivamente para tal fin, acceso denegado por defecto, y abierto sólo por IP o MAC Address. La diferencia entre la recuperación de no encriptados es de facto, superior a un factor 10.
3 Un incidente durante un proceso complejo de restauración en el que elementos de la empresa, cansados o quizás no suficientemente cualificados, puede tener consecuencias nefastas, máxime cuando hablamos de horarios fuera de lo común donde el soporte de la solución elegida, puede o no ofrecer respuesta, o puede que nosotros no tengamos contratado el nivel de respuesta adecuada a un momento como este.
Gracias por la fotografía a Su San Lee en Unsplash
Comparte este articulo en
¡Hola a todos! Vamos a sumergirnos en el fascinante mundo de Mod Security y aprender…
Ya son muchos años en el sector, muchos años pasando por varios paneles de control,…
La lista UCEPROTECT es una herramienta utilizada por muchos administradores de sistemas y proveedores de…
No es la primera vez que me encuentro con el agotamiento de la memoria en…
Descubre cómo solucionar problemas de acceso a servidores con Centos 7, Almalinux 8, Ubuntu 20.04…
Uno de los mensajes más alarmantes que puedes encontrarte es aquel que indica que tu…