Service resilience after infrastructure failure
In October 2026, reported Ukrainian drone strikes hit Yandex data centres in Russia. The resulting disruption prompted claims that Russian propaganda accounts had gone offline. This report examines the evidence and the lessons for service resilience and disaster recovery.
Incident case study. Evidence reviewed 17 October 2026.
The central finding
A provider outage and an end-to-end service failure are different events. Recovery is proven when useful work completes correctly within agreed limits.
- Separate observed traffic from claims about operator identity.
- Design recovery around dependencies, state and usable capacity.
- Validate transactions, outstanding work and safe failback.
1. Background and context
The event in brief
In October 2026, during the Russia-Ukraine war, Ukrainian drone strikes reportedly hit data centres operated by the Russian technology company Yandex at Sasovo, Kaluga and Vladimir in Russia. The attacks disrupted services and affected businesses using Yandex infrastructure. Public claims then linked the disruption to a supposed disappearance of Russian propaganda accounts from Western social media. Lawfare describes both the strikes and the claims, including their amplification by Ukrainian President Volodymyr Zelensky. [3]
This case concerns physical attacks on computing infrastructure and their service consequences. It does not describe a demonstrated intrusion into Yandex's software or a confirmed deletion of customer data. Damage to a building, an interruption to network traffic and loss of application state are separate failure modes. The evidence reviewed here does not establish the extent of every one of them.
What Yandex and its data centres provided
Yandex operates a search engine; Yandex Cloud provides internet-accessible computing services. The cloud platform includes virtual machines, storage, managed databases and networking. Customers can run their own applications using these resources rather than maintaining all the underlying equipment themselves. Yandex's documentation describes this provider role and its responsibility for the platform's hardware and software. [6]
A data centre is a physical facility containing computing, storage and networking equipment, supported by electricity, cooling and communications links. Search infrastructure uses such equipment to collect and process information for search results. Cloud infrastructure supplies resources to customer workloads. These functions can share an operator's name while serving different users and producing different traffic.
A customer workload is the application or automated job running on that infrastructure. A service is the useful outcome delivered to its users, such as retrieving a document, completing a payment or processing a queued job. Losing a workload's original host can interrupt that outcome, but an alternative host may preserve it. The case study follows that distinction from physical disruption to measurable service behaviour.
Why the word "bot" caused confusion
In this report, an automated web request is a request produced by software. A search crawler visits websites to build a search index. Malicious automation may scan for vulnerabilities or send unwanted requests. A social-media bot is an account that automates actions such as posting or replying. An influence operation is a coordinated effort to shape an audience's views or behaviour; it may use people, automation or both.
These categories are not interchangeable. A crawler can be legitimate. A political account can be operated by a person. An account expressing a political opinion is not, on that evidence alone, a bot or part of a Russian operation. "Russian-origin traffic" describes the observed network origin, not proven nationality, state sponsorship or physical location of an operator.
From an outage to a public claim
The reasoning behind the public claim required several links: attacks disrupted Yandex infrastructure; that infrastructure hosted particular political operators; those operators could no longer work; their absence materially reduced political activity. Evidence for the first link cannot establish the remaining links. A graph of fewer automated web requests therefore needs a separate account-level investigation before it can support a conclusion about propaganda.
The political communities discussed later include accounts associated with Germany's Alternative für Deutschland, abbreviated AfD, and the United States' Make America Great Again movement, abbreviated MAGA. They are the subjects of the claims being tested. Their inclusion does not classify their participants as Russian, automated or inauthentic.
What evidence was available and when
The report closes its evidence review on 17 October 2026. It uses Cloudflare's published network observations, Graphika's published analysis of political communities and Lawfare's contextual reporting. Cloudflare observes web requests through its infrastructure; Graphika studies activity in sampled online communities. Neither view is an inventory of every Yandex customer's systems. The following incident record gives publication dates and reported event windows before comparing the measurements.
The engineering purpose is to explain how activities can continue despite a major infrastructure loss, what such continuity proves, and what additional controls a stateful business service needs. The report does not determine military effectiveness, establish the intended target of each strike or attribute a specific influence operation to Yandex. Its recovery designs and numerical planning examples are recommendations, not descriptions of a verified internal deployment.
2. Executive assessment
The October 2026 Yandex incident illustrates a basic problem in resilience assessment: loss of infrastructure and loss of service are different measurements. A provider can suffer severe disruption while an activity continues through other resources. Equally, continued aggregate activity can conceal failures among individual customers.
The published evidence does not establish that Russian propaganda operations had minimal operational impact. It establishes narrower observations about network traffic and sampled political communities. Those observations are useful for engineering, provided their measurement boundaries remain explicit.
Principal finding. Service resilience must be demonstrated at the point where useful work completes. Provider traffic, surviving servers and backup inventories are supporting signals. None alone proves successful recovery.
This report separates published observations from engineering deductions. It provides a recovery model for legitimate services, acceptance criteria and a delivery plan. The reference architecture and all worked calculations are illustrative, with no claim that Yandex or any influence operator used them.
3. Incident record and measurement boundaries
Lawfare reports strikes at Sasovo, Kaluga and Vladimir between 8 and 11 October, with service disruption affecting Russian businesses. Graphika describes the wider incident window as 7 to 11 October. These publication-level dates are not a forensic event log. [3] [2]
- Reported attack and disruption window.
- Graphika publishes its community analysis.
- Cloudflare publishes network analysis; Lawfare examines the public claims.
- Evidence review for this report closes.
Cloudflare is a web infrastructure and security provider. It measures web requests using the Hypertext Transfer Protocol, abbreviated HTTP. For October 11, it reports traffic lows of 99% below baseline for Yandex Search, AS13238, and 90% for Yandex.Cloud, AS200350. Search losses were predominantly verified crawling. It observed matching JA4 connection fingerprints, request paths, headers and user-agent identifiers reappearing from Radist and Selectel after Yandex.Cloud requests to one gambling customer stopped. Russian bot requests to gambling accounts totalled 167.7 million before and 170.1 million after, a reported 1.4% increase. [1]
A JA4 fingerprint describes characteristics of a client connection; paths identify requested resources, while headers and user-agent identifiers carry request metadata. Matching these signals supports continuity of behaviour without proving who controlled the clients.
An autonomous system number identifies a routing domain. HTTP requests observed leaving that domain measure activity within a particular observation window. They do not count all services in a data centre, and cannot identify political operators by themselves.
4. Political activity and the attribution gap
Graphika, a company analysing online networks and communities, found no collapse in the Western communities named in viral claims. Its AfD-related sample recorded 42,040 posts from 1,037 accounts on the previous Sunday and 40,365 posts from 1,022 accounts on October 11. The roughly 4% posting decline fell within normal variation. MAGA mentions increased 25% against matched hours on four previous Sundays. Graphika assessed its overall conclusion with moderate confidence and noted incomplete collection for the newest days. [2]
| Measure | Earlier comparison | Post-strike observation | Interpretation |
|---|---|---|---|
| AfD-related posts | 42,040 | 40,365 | 4.0% lower; normal variation in the source analysis |
| AfD-related active accounts | 1,037 | 1,022 | 1.4% lower; no attribution of these accounts to Russia |
| MAGA mentions | Matched hours on four Sundays | 25% higher | Mentions measure conversation, not operator continuity |
Lawfare identifies the inferential gap between crawler disruption and claims about political accounts, and explains how reduced platform-data access limits verification. [3] Stable conversation volume could result from unaffected ordinary users, independent infrastructure, replacement activity or actual recovery. The public record does not distinguish those mechanisms for a named influence operation.
A claim of successful disaster recovery would require a linked chain of evidence: an identified service depended on the failed resource; its work stopped or degraded; an alternate resource took over; useful output and state integrity then met defined targets. That chain is unavailable here. Absence of a community-wide collapse is therefore evidence against the broad viral claim, rather than proof that every malicious operator remained fully effective.
5. Evidence quality and causal limits
| Evidence | Supported conclusion | Unresolved question |
|---|---|---|
| Provider HTTP telemetry [1] | Severe disruption within the observer's network view | Facility damage, all-customer availability and exact recovery time |
| Behavioural matching across providers [1] | A recognisable request pattern continued elsewhere | Operator identity, automation of the move and pre-existing standby capacity |
| Community activity [2] | The sampled political conversations did not collapse | Individual operation losses, account attribution and delayed effects |
| Published incident reporting [3] | Physical attacks and wider disruption were reported | Complete technical root cause and internal incident chronology |
The unit of analysis matters. A million repeated requests may be one automated job, while one successful financial transaction may depend on dozens of services. Neither request counts nor account counts alone describe business impact. A resilient-looking output graph can also conceal longer latency, rejected work, lost state or a growing queue.
This is an external case analysis. No internal Yandex incident report, recovery runbook, replication log, service-level objective or transaction-integrity record was available in the cited material. There is no defensible incident-specific recovery time objective achievement or recovery point objective achievement to calculate.
6. Resilience mechanisms and their limits
Portable execution reduces dependence on one provider
The engineering inference from cross-provider continuity is that some execution was replaceable. For a legitimate worker service, reproducible images, versioned configuration and externally recoverable job state can make replacement practical. A replacement host still needs working credentials, network access, compatible runtime libraries and permission to reach its destination.
Stateless request generation is a weak analogue for a transactional service. A scanner may tolerate duplicate requests and abandoned work. A payroll system must preserve authorisation, payment status and audit records. Copying an execution model without its correctness requirements can produce availability while damaging the business.
Redundancy must survive the actual failure domain
Two machines protect against a machine failure. They offer little protection if both depend on one power supply, network path or storage controller. Two regions can still share identity, account administration, billing or deployment systems. Provider diversity adds another boundary, but also adds incompatible APIs, operational work and more configurations to maintain.
Repeated physical attacks also change the planning assumption. The recovery site may become the next failed site before the original returns. Capacity planning must cover sustained operation away from the primary location, constrained replacement equipment and a second failure during recovery.
Control dependencies can prevent recovery
AWS distinguishes the data plane that serves requests from the control plane that configures resources, and recommends minimising control-plane dependence during failover. [5] Applied here as a design principle, standby resources should be usable when provisioning APIs, the deployment registry or the primary identity service cannot be reached. Pre-provisioning has a cost, but it removes time-critical creation steps.
Resilience includes reduced service and human decisions
A service can preserve essential transactions while pausing reports, recommendations or bulk processing. That reduced mode needs an explicit contract. Silent loss of a core function is a failure even if the homepage stays online. Operators also need authority to invoke recovery, communications outside the failed platform and a safe way to stop a mistaken failover.
7. Reference recovery design for a stateful service
The following design is an engineering recommendation, not a reconstruction. It assumes one active writer, an independently hosted recovery environment and asynchronous state replication. Availability during a partition is subordinate to preventing conflicting writes.
Primary failure domain
Application and worker capacity
Active database writer
Recovery failure domain
Ready application capacity
Replica and tested promotion
| Dependency | Required separation | Verification |
|---|---|---|
| Routing and name resolution | Administration and health checks survive primary loss | Change destination while primary management access is blocked |
| Identity, secrets and encryption keys | Recovery credentials and key access remain available | Authenticate and decrypt a restored backup with primary identity unavailable |
| Application artefacts | Images, configuration and infrastructure definitions are recoverable | Deploy the approved version without the primary registry |
| Database and queues | Documented promotion, fencing and replay rules | Prevent the old writer returning; reconcile accepted work |
| Network and external services | Routes, certificates and destination allowlists cover recovery | Complete a real transaction through each external integration |
| People and observability | Runbooks, contacts and monitoring survive the outage | Recover using only independently accessible instructions and telemetry |
Before promotion, the incident commander must establish that the former writer cannot continue accepting writes. A quorum, fencing mechanism or equivalent lease design should enforce that invariant. If the system cannot prove exclusive ownership, it should suspend writes or enter a defined read-only mode rather than create divergent records.
Replication and backups serve different purposes. Replication shortens the interval of missing state, but can copy corruption. AWS guidance explicitly retains point-in-time recovery alongside replication. [5] Recovery therefore needs retained versions, protected deletion controls and independently recoverable keys. A backup is only usable after an isolated restore verifies its contents.
8. Recovery objectives and worked engineering model
NIST SP 800-34 provides a framework for setting contingency requirements and priorities. [4] For this report, the recovery time objective, RTO, is the target elapsed time from disruption to an agreed usable service level. The recovery point objective, RPO, is the maximum tolerable interval of lost data. Both are business decisions that constrain architecture.
Redundancy describes spare resources. High availability describes service continuity through expected faults. Disaster recovery restores service following a disruption outside normal operation. Resilience includes these capabilities and the ability to sustain useful work under degraded conditions. A service-level indicator, SLI, measures an outcome; a service-level objective, SLO, sets its target.
In this example, a service owner sets a 15-minute RTO and a 60-second RPO. At a failure at 10:00:00, a recoverable replica containing commits through 09:59:20 has a 40-second recovery-point gap. It meets the time-based RPO if that commit boundary is verified, but operations must still identify which accepted transactions were lost. A dashboard reporting replication lag is insufficient evidence of the recovered state.
Suppose the service accepts 200 jobs per second and queues work throughout a 15-minute interruption. It accumulates 180,000 jobs. If recovery processes 300 jobs per second while 200 new jobs per second continue arriving, net drain is 100 jobs per second. Clearing the queue takes another 1,800 seconds, or 30 minutes. Restoring the endpoint after 15 minutes therefore does not mean all work is current. If processing capacity equals new demand, the backlog never drains.
For equal sites sharing a fixed load, loss of one of two sites doubles the load on the survivor. If each initially runs at 60% of usable capacity, the survivor would require 120%. This simple calculation excludes retry traffic and performance nonlinearity, so it is an optimistic bound. Reserve capacity must be tested at the post-failure workload, including dependencies and rate limits.
Record the service's availability against successful, correct transactions within a latency threshold. Measure queue age, rejected work, duplicate side effects and reconciliation exceptions separately. Declare reduced service restored only against its agreed minimum; declare full recovery only after backlog and integrity targets also pass.
9. Selecting a recovery strategy
AWS groups recovery strategies into backup and restore, pilot light, warm standby and multi-site active/active. [5] The comparison below applies that taxonomy to a generic service. Actual recovery times depend on data size, automation, capacity and tests; no universal timing guarantee is implied.
| Strategy | Provisioning at disruption | Main tradeoff | Appropriate decision condition |
|---|---|---|---|
| Backup and restore | Rebuild runtime and restore state | Lower standing cost; longer and more variable restoration | The business can tolerate a measured rebuild interval |
| Pilot light | Core state exists; expand application capacity | Less idle compute; provisioning remains on the critical path | Scale-up and quota access have passed a realistic outage test |
| Warm standby | Usable smaller service already runs | Higher standing cost; spare capacity may still be needed | Essential journeys can run immediately at agreed reduced capacity |
| Multi-site active/active | Multiple sites already serve work | More coordination and data-consistency complexity | Continuous service justifies the tested operational burden |
For many stateful services, warm standby with one writer is easier to reason about than a multi-writer design. That is a recommendation conditional on the service's requirements, not a universal preference. A low-volume archive may justify backup and restore; a payment path with a strict interruption limit may justify substantially more standing capacity.
A second provider is justified when provider-wide failure is within scope and the team can operate both platforms. It should not be selected solely because this case includes provider migration. A poorly exercised second environment may deliver less dependable recovery than a simpler design whose limits are measured and accepted.
10. Recovery validation and operating procedure
A credible recovery exercise removes the resources assumed to be lost. Leaving primary identity, databases or deployment tools reachable can turn a failed design into a passing demonstration. The recovery owner should retain timestamps, configuration versions, transaction identifiers and reconciliation results so another engineer can reproduce the conclusion.
| Stage | Action | Acceptance evidence |
|---|---|---|
| Prepare | Approve scope, safety limits, recovery targets and rollback authority; seed traceable transactions | Business owner and incident commander sign the test contract |
| Disrupt | Isolate the primary runtime and its scoped control dependencies | External probes show the intended failure; monitoring remains available |
| Recover | Fence writers, select a validated state point, promote and reroute | Elapsed recovery time is within RTO; recovered commit boundary is within RPO |
| Validate | Run authenticated read/write journeys and replay pending work | No conflicting writes or duplicate irreversible effects; transaction records reconcile |
| Sustain | Run recovery at expected peak with retry load and backlog | Latency, error rate, queue age and capacity stay within agreed limits |
| Fail back | Resynchronise from the authoritative site, verify integrity and switch under controlled ownership | One writer throughout; no lost acknowledged work from the transition |
| Close | Record deficiencies, owners and completion dates | Failed controls are corrected and affected scenarios are retested |
Use separate scenarios for primary site loss, provider management outage, corrupted state and loss of recovery credentials. A capacity-only test cannot validate backup recovery. A backup restore cannot validate routing or failback. Repeat the relevant exercises after material changes to data layout, identity, networking or recovery tooling.
During an actual event, the incident commander records the disruption time, business impact and decision to invoke recovery. The database owner controls state promotion; the service owner verifies user journeys; the communications owner publishes the service state and next update time. These responsibilities need named deputies and communications that survive loss of the primary platform.
Failback is another production change. Rebuild the old environment as a follower, reconcile state from the current authority, test it and then transfer ownership under the same fencing rules. Returning traffic merely because the old site answers health checks can reintroduce stale data or conflicting writers.
11. Implementation priorities and final findings
| Period | Accountable owner | Deliverable and completion condition |
|---|---|---|
| First 30 days | Service owner with operations lead | Approve essential journeys, impact tolerances, RTO/RPO and dependency inventory; demonstrate one isolated restore |
| Days 31 to 60 | Platform and database leads | Remove primary-only recovery access; verify fencing, recoverable artefacts and alternate capacity under load |
| Days 61 to 90 | Incident commander with business owner | Complete a primary-loss exercise and failback; reconcile transactions and close blocking defects |
| Ongoing | Service owner | Retest after material changes; review recovery costs, failed controls and objective compliance |
The case's strongest lesson is about the boundary of a claim. Infrastructure disruption, recognisable activity continuing elsewhere and political conversation remaining active are different observations. Combining them into a story about a verified propaganda recovery system would exceed the evidence.
For service engineering, the practical conclusion is firmer. Design replacement capacity around dependencies and state, set business recovery tolerances before selecting technology, and test the complete route back to correct transactions. A useful recovery record includes elapsed time, recovered commit position, sustainable throughput, outstanding work and the result of failback. Those measurements turn apparent continuity into an auditable resilience capability.
12. References and method
Cloudflare, Marina Elmore and Lai Yi Ohlsen, 14 October 2026. Yandex outage: Data shows that instead of going dark, malicious bots went on the move.
Primary HTTP telemetry and behavioural matching. Visibility is limited to traffic observed by Cloudflare.
Graphika, John Kelly, 13 October 2026. Did the Yandex Data Center Strikes Silence Russian Bots? What the Data Shows.
Primary community analysis. The newest days were only partly collected when the data was pulled.
Lawfare, Renée DiResta, 14 October 2026. The Russian Bots Went Silent. Or Did They?.
Incident context and analysis of attribution and platform-data limitations.
NIST, May 2010, updated November 2010. SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems.
Contingency planning framework. Used for recovery planning, not as evidence about Yandex.
Amazon Web Services, accessed 17 October 2026. Disaster recovery options in the cloud.
Recovery strategy taxonomy and control-plane considerations. Vendor guidance, not a description of this incident.
Yandex Cloud, accessed 17 October 2026. Yandex Cloud platform overview.
Primary provider documentation explaining cloud computing, platform responsibilities and service categories. Used for background, not independent incident verification.
Links and publication details checked on 17 October 2026. Published aggregate results were reviewed; underlying private telemetry and account-level datasets were not independently reprocessed. Figures 1 and 2 redraw reported numbers. Figures 3 and 4 and tables 2 to 5 are original engineering models and recommendations. Percent changes use the earlier value as denominator and are rounded.
This HTML file contains the complete report, styles and figures. It can be saved, copied and read offline without other files. Following the source links requires internet access.