- Yandex says drone attacks damaged three of its data centers. Two stopped operating and one is degraded. BleepingComputer reports that some customers cannot reach their files.
- Yandex told customers to use other infrastructure for disaster recovery. The lesson here is that a backup is only as independent as the place it is stored.
- Leaders can ask where each copy of critical data lives, whether it has been restored from a second provider, and which vendors rely on one operator.
A cloud has an address
If an original and its backup share a provider or a site, one physical event can reach both. That risk is easy to overlook, because the cloud feels weightless. It is a set of buildings. When a building stops working, the customers inside it feel the loss.
On October 12, BleepingComputer reported on Yandex, a Russian cloud provider. Yandex said drone attacks had damaged three of its data centers. It shut down two and partly disabled the third.
What happened, and what is still unknown
Sasovo was hit on October 8. Kaluga followed on October 9. Vladimir was attacked on October 11.
Sasovo and Vladimir stopped working entirely. Kaluga still runs, but at reduced capacity. Yandex reported no injuries.
The report says Ukrainian forces are believed to be behind the attacks. WebPulse cannot verify that.
Yandex is often called "Russia's Google". The report says much of the country's internet infrastructure relies on its services. That covers government and private-sector organizations. The effects could therefore reach beyond Yandex's own products.
What customers are seeing
Yandex posts service status on a public page. In the latest update, most core services sat in one group: running, but with some performance or availability issues. The group spans the management console, the API, identity controls, container storage, databases, file storage and Kubernetes.
IAM is the tool that controls who may log in and what they may do. Kubernetes is software that runs applications in containers.
Yandex rated Compute, AI Studio and its security services as only partly available. A service called Monium was offline.
One customer reported trouble from October 8. Their backups on Yandex Disk were missing thumbnails. They could not download files they had submitted earlier. They saw HTTP 302, 504 and 500 errors.
A 504 means one server waited for another that never answered. A 500 means the server itself failed. The report does not explain the cause.
The report does not say where this customer kept their original files. It also does not say which data centers hold Yandex Disk. One customer's account cannot show more than that.
The status page still teaches something. A service marked "available" with issues may be hard to use in practice.
It is also unclear whether any data has been lost for good. Yandex had not addressed this in its status updates.
The provider's own advice is the lesson
Yandex said it cannot give a reliable date for recovery. One update called the remaining setup "unstable". It said the platform's operating mode was "emergency". It recommended "any other alternative disaster recovery plans".
That advice raises a question. Suppose a backup sits with the same provider as the original. One physical event could then affect both. This is WebPulse's argument. The customer's report does not prove it.
The lesson here is that a backup is only as independent as the place it is stored.
Questions for your team
Teams could start with a few plain questions.
Where does each copy of our critical data physically live? Does any backup share a provider or location with the original?
When did we last restore from a backup held by a different provider? How long did it take?
Which of our vendors rely on a single cloud operator? Do we know their disaster recovery plans?
What does our contract say if a physical event takes a facility offline? What are we owed?
The answers will differ by business. A status page that reads "emergency" is a poor time to find out.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BleepingComputer.
