Yandex Cloud admite pérdida de datos tras los ataques con drones a sus centros de datos

Yandex Cloud ha confirmado que los ataques con drones registrados en octubre contra tres de sus instalaciones en Rusia provocaron daños críticos en hardware y la pérdida de aproximadamente el 2,84% de los datos de sus clientes. La compañía afirma que ha recuperado más del 97% y que el incendio y la interrupción más graves se concentraron en la zona de disponibilidad ru-central1-b. El aviso no detalla cuántos clientes se vieron afectados ni qué datos concretos se perdieron.

El incidente no fue un apagón breve. El ataque inicial provocó un fuego y una caída de servicio en ru-central1-b; los ataques posteriores alcanzaron otras instalaciones y afectaron a más servicios de nube y de pago, según el balance publicado por la compañía. Cloudflare, que monitoriza el tráfico de internet, documentó caídas de hasta el 99% en la red de búsqueda de Yandex y del 90% en su nube el 11 de octubre, con una recuperación parcial en los días siguientes.

Qué ocurrió y qué ha reconocido Yandex

Yandex publicó su balance de recuperación el martes 10 de noviembre. La empresa presenta la restauración de más del 97% de los datos como un resultado positivo, pero el dato que importa a quien perdió su información es el complemento: un 2,84% no se pudo recuperar. Yandex atribuye esa pérdida a «daños críticos en el hardware y a la falta de copias de seguridad en la plataforma».

La formulación deja margen a interpretaciones. No queda claro si Yandex se refiere a que su propia infraestructura no conservaba copias, a que sus mecanismos de redundancia no creaban varias copias de los datos de los clientes o a que fueron los clientes quienes no habían configurado una protección adicional. La compañía no ofrece un desglose por servicio ni un listado de los clientes afectados.

El contexto añade dificultad. Los ataques se produjeron en el marco de la guerra en Ucrania y de las sanciones internacionales contra Rusia, que limitan el acceso a hardware y servicios tecnológicos occidentales. Yandex no utiliza las sanciones como explicación en su aviso, pero cualquier proveedor que opere en ese entorno tiene más difícil reponer equipos y ampliar capacidad con rapidez.

Por qué se perdieron datos si la nube es redundante

La redundancia y las copias de seguridad no son lo mismo, aunque se presenten juntas. La redundancia mantiene varias copias de un dato en funcionamiento para que el servicio siga disponible si falla un disco, un servidor o una zona. Una copia de seguridad es una versión separada, con su propia retención, pensada para recuperar el estado anterior si algo se destruye o se corrompe. Un incendio que afecta a varios racks puede llevarse por delante las réplicas que estaban en el mismo edificio.

Eso explica que un proveedor con alta disponibilidad pueda perder datos. Si las réplicas comparten la misma zona de disponibilidad, el mismo sistema de almacenamiento o la misma credencial, un evento suficientemente grave las alcanza a todas. La copia tiene que estar en otro dominio de fallo: otra zona, otra región, otro proveedor o, mejor, un soporte que no dependa de la misma cuenta ni del mismo proceso automatizado.

Yandex ha respondido activando copias de seguridad por defecto para todas las máquinas virtuales que los clientes creen en su nube. La medida se aplica salvo que el cliente decida desactivarla y consume recursos adicionales, que se facturan. Es una decisión razonable, pero también traslada al cliente la responsabilidad de revisar la retención, la ubicación y el coste de esas copias.

La nueva zona ru-central1-f y sus límites

El miércoles 11 de noviembre, Yandex lanzó una nueva zona de disponibilidad llamada ru-central1-f. La empresa no detalla su ubicación exacta, más allá de decir que está en «una nueva ubicación». La zona tiene cuotas que limitan los recursos que un cliente puede utilizar y todavía no puede gestionar tráfico hacia endpoints privados, según el aviso.

Para quien piense en migrar cargas o distribuirlas, esos límites importan tanto como la existencia de la zona. Una zona nueva no es una garantía de capacidad ilimitada ni una solución automática de continuidad. Si se necesita, hay que solicitar cuota, comprobar la compatibilidad de los servicios y probar la conectividad antes de mover producción.

Yandex también enlaza desde su balance a material sobre nubes híbridas y a Stackland, su producto para desplegar parte de su stack en instalaciones propias. Es una indicación de hacia dónde quiere llevar el discurso: la nube pública sigue siendo el centro, pero la empresa admite que una arquitectura híbrida puede formar parte de una estrategia de protección.

Qué deben revisar las empresas

Lo primero es saber qué datos están donde. Un inventario con proveedor, región, zona, propietario y criticidad permite decidir qué necesita copias y qué puede reconstruirse. Después conviene definir dos parámetros: el RPO, que mide cuántos datos se pueden perder como máximo, y el RTO, que mide cuánto tiempo se puede estar sin servicio. Sin esas cifras, una copia de seguridad es una promesa sin contenido.

La copia debe probarse. Una restauración que nunca se ha ejecutado no demuestra que el sistema funcione; solo demuestra que los archivos existen. Conviene hacer pruebas periódicas, medir el tiempo real de recuperación y comprobar que las credenciales necesarias siguen disponibles aunque la cuenta principal haya quedado inaccesible. La regla 3-2-1 sigue siendo útil: tres copias, en dos medios distintos, con una fuera de la instalación.

Para los clientes de Yandex Cloud, la lista inmediata es concreta: revisar si las copias por defecto están activas, cuánto se conservan, dónde se almacenan y cuánto cuestan; exportar los datos críticos a un almacenamiento independiente; comprobar las cuotas de la nueva zona; y actualizar los planes de continuidad con supuestos realistas sobre la capacidad disponible. También merece la pena revisar el contrato, el SLA y el plan de salida, porque la recuperación no termina cuando el proveedor restaura el servicio.

Una lección que no depende del proveedor

El 2,84% puede parecer una cifra pequeña en un comunicado. Para el cliente que pierde su base de datos, sus archivos o el historial de su aplicación, es el 100%. Esa asimetría es la razón por la que las copias no pueden delegarse por completo en la confianza en el proveedor, por bueno que sea su historial.

Yandex ha recuperado la mayor parte de los datos y ha puesto en marcha medidas para evitar que se repita. El episodio, sin embargo, deja preguntas abiertas: qué clientes perdieron qué, si las copias por defecto llegan a tiempo a todos los servicios y cómo se comportará la nueva zona cuando tenga carga real. La respuesta a esas preguntas llegará con el tiempo. La parte que cada empresa puede controlar es la de siempre: saber qué necesita recuperar, cuánto puede esperar y dónde está la copia que no depende del mismo edificio.