Can Your Cloud Recovery Plan Actually Leave the Platform?
Disruption across three Yandex data-centre locations has left recovery work ongoing. For affected customers, the urgent question is whether critical workloads can run somewhere else before the provider finishes restoring services.
Yandex’s corporate notice separates three events. Its Sasovo site stopped operating after serious damage during the night of 7 to 8 October. Part of the Kaluga infrastructure failed after another attack on 9 October. The Vladimir site stopped operating after an attack during the night of 10 to 11 October. The notice was published on 9 October and revised on 11 October.
In its 18:44 GMT+2 update on 13 October, Yandex Cloud incident 2136 said the platform’s status had not changed and that teams were continuing to restore services. An earlier update described Yandex Cloud as operating in limited mode. The record gives no reliable restoration time.
Another update advised customers to use alternative sites for hosting and reserving resources. The latest update points readers to separately maintained guidance for individual services. That matters because the incident record does not show that every service or workload has the same impact. Each team still needs to establish which dependencies are working, degraded or unavailable.
A 13 October update also said current customers would not be charged for Yandex Cloud services used in Russian availability zones from 8 through 31 October, with the adjustment applied automatically. That reduces incident costs, but it does not prove an application can recover elsewhere.
Recovery begins with a usable copy of state
A recovery environment depends first on state that cannot be recreated from code: databases, object stores, queues and persistent volumes. A recovery plan should identify the newest copy held outside the affected platform, its age, the keys needed to open it and the point after which transactions may require reconciliation.
A backup catalogue is evidence that copies exist, not that a service can use them. A representative restore into the alternative environment should be opened with the intended application identity and tested through a real business transaction. If that cannot be done, the dependency remains unproved and should be treated as a recovery risk.
The recovery controls must be reachable independently
Moving data is only part of the route. The team also needs access to break-glass identities, DNS, certificates, secrets, deployment artefacts, infrastructure definitions and incident contacts without relying on the affected provider. Capacity, network reachability and service quotas in the destination need to be known before a cutover starts.
Dependencies outside the obvious application stack can stop the move just as effectively as missing data. Image registries, build systems, licence servers, monitoring and outbound allowlists should therefore be tested from the recovery environment rather than assumed to be portable.
Cutover decides who may write
The safest cutover establishes one write authority. The original and restored systems should not accept conflicting changes, and the team should record the recovery point and transactions that may need reconciliation. Before moving user traffic, it should prove authentication, one critical workflow, monitoring and support access in the destination.
Traffic can then move in measured stages with a clear stop condition. The same decision record should define what must be true before workloads return or the temporary platform becomes permanent. A workable recovery route is demonstrated by current state, independent control and a controlled change of authority, not by the existence of backups alone.
Sources
- Yandex Cloud incident 2136, latest update 13 October 2026 at 18:44 GMT+2.
- Yandex data-centre notice, published 9 October and revised 11 October 2026.
