O2Cloud O2 Cloud, LLC sells hosted capacity that still depends on racks, transit and repair windows

Summary

• O2 Cloud LLC has stronger current operating evidence than the assignment hypothesis suggested. RBC Companies lists the Russian company as active on 12 July 2026, with registration number 1187746216437, tax number 9710050732, a 2018 registration date, 22 average employees, 2025 revenue of 1.418 billion rubles and 2025 profit of 372.9 million rubles. RIPE also records O2 Cloud LLC as a Russian LIR, and AS208349 is currently announced.
• The public service surface is broad: OXYGEN markets VMware public cloud, private cloud, rented server equipment, backup, disaster recovery, S3-style storage, managed databases, security products and smart remote-hands support. Those pages describe useful components, but they do not by themselves prove spare capacity, tested failover, customer-specific recovery time or the exact legal boundary between O2 Cloud LLC, the OXYGEN brand and Business System Telehouse data-centre facilities.
• Network evidence is strong at the routing layer. RIPE and Hurricane Electric show AS208349, AS-O2CLOUD, IPv4 and IPv6 originated prefixes, MSK-IX presence and named upstreams including RETN, Rascom, Rostelecom, MegaFon and StormWall. That is real connectivity evidence, not merely marketing, but it is still not the same as proven application continuity if a rack, facility, support account, payment channel or sanctions-related supplier path fails.
• The article's operating downgrade is therefore not "weak company"; it is "unverified recovery boundary." Buyers should require written answers on facility ownership, MSK East/MSK West placement, rack and power paths, transit independence, backup location, restore tests, hardware stock, data portability, sanctions exposure, and who can act when the customer cannot wait for a normal ticket queue.

The public record proves a live company, not a complete resilience story

The first question with a small or regionally specific cloud provider is whether the operating footprint exists at all. For O2Cloud O2 Cloud, LLC, the answer is stronger than a thin-web-footprint warning would imply. The Russian corporate profile on RBC Companies lists Limited Liability Company O2 Cloud as active, registered on 28 February 2018, with registration number 1187746216437, tax number 9710050732, a Moscow legal address, 22 average employees and a primary activity code for computer and information-technology work. RBC also reports 2025 revenue of 1.418 billion rubles and 2025 profit of 372.9 million rubles, sourced to accounting statements, while noting that its company profile is reference information derived from open data.

RIPE supplies a second identity layer. The RIPE organisation entity for ORG-OCL29-RIPE names O2 Cloud LLC, country RU, registration number 1187746216437 and LIR status. Its address is Tverskaya Street in Moscow, while the RIPE NOC role gives an O2 Cloud NOC, a Volgogradsky prospekt address, a phone number and an [email protected] mailbox. These are not customer testimonials, but they are operational records in the registry system that network operators use to coordinate routing, abuse and administrative responsibility.

The telecom-regulatory record points in the same direction. Roskomnadzor's communications licence register lists O2 Cloud under a telematic communications services licence. RBC and Roskomnadzor use the same Russian legal identity and tax number, while the OXYGEN website presents the customer-facing infrastructure brand. Taken together, the company is visible as a corporate entity, a licensed communications provider and an internet-number holder.

That does not answer the more important customer question. The customer does not only need a company number. It needs to know where its workload runs, who owns or controls the racks, who can enter the hall, which upstreams carry traffic, which backup copy can be restored without the primary cloud, and what happens if a supplier, sanctions authority or billing dispute blocks the normal route to support. A company can be active, profitable and route-visible while still giving customers weak evidence on recovery.

There is also a legal risk layer that cannot be separated from procurement. OFAC's Sanctions List Search detail for O2 KLAUD lists an SDN entity with registration number 1187746216437 and tax number 9710050732, matching the RBC and RIPE identity. The Treasury press release of 23 February 2024 describes O2 Klaud as operating a data center and providing infrastructure security and network products, and says it was designated under the Russia program. This is not evidence of a service outage. It is evidence that some customers, vendors, payment processors, insurers, hardware suppliers and software licensors must treat the relationship as a sanctions compliance problem before they treat it as a normal cloud contract.

The result is a split judgement. O2Cloud should not be dismissed as an unproved operator. The visible evidence supports a real Russian cloud and network business. But the article should not convert corporate existence and marketing pages into a guarantee of customer recoverability. The right standard is narrower: can the customer prove the exact failure path for its own virtual machines, data, addresses, licences and support rights?

What OXYGEN says it sells is infrastructure, even when it is sold as a cloud

The OXYGEN site presents a broad business-infrastructure catalogue. The home page says the cloud infrastructure provides services ranging from equipment rental and virtual machines to database management, backup and security products. The public VMware cloud page describes public cloud on VMware, virtual data centres, virtual machines, configurable CPU, memory and storage, software-defined networking, backup add-ons and support. The private cloud page describes private cloud for customers that need a dedicated environment and stronger control over security and performance. The server-rental page offers dedicated equipment rather than only virtual capacity. The backup page sells cloud backup, and the disaster-recovery page sells recovery capacity for failed sites.

Those pages matter because they locate the service category. O2Cloud is not merely selling a software dashboard or a content site. It is selling hosted compute, storage, networking, backup, recovery and support. Those services are abstractions on top of physical systems: servers, storage shelves, switches, routers, firewalls, cross-connects, power distribution, cooling, operations staff and contracts with upstream carriers and facility operators.

The most useful way to read the service catalogue is to separate visible product from invisible dependency. A public-cloud virtual machine feels like an account setting. In the provider's estate, it is a placement decision on a cluster with finite CPU cores, RAM, storage I/O, backup bandwidth and network capacity. A rented server sounds dedicated, but that dedication increases dependency on the exact hardware stock and maintenance process. A backup product sounds like insurance, but only if the backup is consistent, retained, protected from the same credentials as production and restorable in an independent place.

A disaster-recovery product sounds like continuity, but only if the recovery site has reserved headroom, route capacity, licences and a tested runbook.

The OXYGEN pages give useful service claims. They do not disclose all of the architecture needed to price the risk. They do not publish a customer-by-customer oversubscription policy, placement map, failover test history, storage replication design, exact hypervisor cluster boundaries, spare-part inventory or the circumstances under which a customer can retrieve data without the provider's normal portal. That is normal in commercial cloud sales, but it means the buyer has to ask for evidence rather than rely on the word "cloud."

The ownership boundary is especially important here. RIPE identifies O2 Cloud LLC as the network holder behind AS208349. Uptime Institute identifies Business System Telehouse as the client for Oxygen Data Processing Center, Data Halls 2 and 3, in Moscow. The OXYGEN and O2DC brands are presented together in public material, and O2 Cloud's RIPE routing policy includes Business System Telehouse AS47440 in customer or adjacent routing context. That supports an operational association in the public record, but it is not the same as a customer contract that says which legal person is responsible for power, space, remote hands, hosted cloud, security, backups and data return. A buyer should not let brand continuity substitute for contract clarity.

The Moscow facility story needs site-level proof

OXYGEN's cloud pages point to Moscow facility locations and use data-centre language. Public pages refer to MSK East and MSK West placement, while O2DC material describes a Moscow data-centre network and promotes Tier III characteristics. Uptime Institute's awards list shows Business System Telehouse in Moscow with Oxygen Data Processing Center, Data Halls 2 and 3, carrying Tier III Certification of Design Documents. That is a real third-party design validation, but the scope matters.

It is a design-document certification for named data halls, not a universal certificate for every service, every rack, every cloud cluster or every continuity process sold under the OXYGEN brand.

This distinction is not pedantic. Data-centre reliability is built from independent failure domains. A hall can have a well-designed power topology while a customer deployment still has a single storage system, a single firewall cluster, a single management plane, one backup account or one contract chain. Two Moscow locations can reduce some risks while leaving others common: the same metro region, the same provider administration, the same sanctions constraints, the same software stack, the same support team, the same billing system, and sometimes the same long-haul or exchange dependencies.

The physical list a buyer should settle starts with placement. Which hall is primary? Is there a second hall? Are both in use or is one only available after a recovery order? Does the customer have anti-affinity across clusters, racks, power feeds and storage arrays, or only across virtual-machine names? Does the backup copy sit in the other Moscow site, in the same facility, in object storage, or on media that requires provider action to restore? Can the customer choose or verify the locality of data and logs?

Power and cooling claims also need customer-level interpretation. A Tier III design aims for concurrently maintainable infrastructure, but a customer environment can still fail if both power cords land on the same rack distribution unit, if storage controllers share a dependency, if a cooling incident forces a controlled shutdown of high-density nodes, or if planned maintenance drains the only cluster with spare capacity. The phrase "Tier III" narrows the facility question; it does not answer the cloud-platform question.

Installed capacity is another place where service pages and resilience diverge. OXYGEN can market vCPU, RAM, storage and network options while still reserving the right to place workloads within finite clusters. A customer that buys enough capacity for normal operation has not necessarily bought enough capacity to run during a host, storage shelf, rack, hall or provider-account failure. Recoverable capacity requires spare headroom at the place of recovery, licences that allow the workload to start there, and a tested route for user traffic.

The safest reading is therefore positive but conditional. The Moscow facility record is stronger than a generic "hosted somewhere" claim. It includes named locations, a public data-centre brand and Uptime Institute design-document evidence for Business System Telehouse Oxygen halls. The unresolved question is how an O2 Cloud customer workload maps onto those halls, how many independent failure domains are actually purchased, and who bears the cost and authority to activate them.

Network visibility is real, but route diversity is not application recovery

O2 Cloud's network evidence is one of the clearest parts of the record. The RIPE aut-num entity for AS208349 names AS208349 as O2CLOUDRU and ties it to ORG-OCL29-RIPE. The same entity lists IPv4 and IPv6 uplink policy for RETN, Rascom, MSK-IX, Rostelecom, MegaFon and StormWall. It also records customer or downstream relationships in AS-O2CLOUD, including AS211933, AS47429, AS41667, AS47440, AS206904, AS206301 and AS47763.

RIPEstat's announced-prefixes view for 12 July 2026 showed active AS208349 announcements including 45.134.124.0/22, 5.35.120.0/23, several /24 routes, 185.31.133.0/24 and the IPv6 block 2a0e:7e40::/29. Its routing-status view showed AS208349 as announced, with full IPv4 visibility across 325 of 325 RIS peers and IPv6 visibility across 321 of 322 RIS peers at the query time. Hurricane Electric's BGP Toolkit page similarly showed Russian country of origin, originated IPv4 and IPv6 prefixes, one internet exchange, no originated RPKI invalids, observed BGP peers and MSK-IX Moscow addresses.

That is meaningful operating evidence. It shows O2 Cloud is not simply a reseller name without visible number resources. It originates space, maintains route objects and appears in global BGP measurement. It also shows a network design with multiple named upstream and exchange paths. For customers, this reduces one category of risk: a single carrier failure should not automatically be assumed to isolate the entire estate.

But routing diversity has limits. Two upstream names do not prove two physically diverse fibres from the exact rack. A peering session at MSK-IX does not prove that customer traffic can bypass an outage in the provider's edge, firewall, route reflector or DDoS-cleaning path. A StormWall default route can improve mitigation options while also adding a dependency on filtering policy, redirection and incident coordination. A visible IPv6 prefix proves address family support; it does not prove that customer applications, firewalls, monitoring, DNS and support processes are equally ready for IPv6 failover.

The customer should also distinguish production reachability from control-plane reachability. A virtual machine can remain powered while the portal, billing account, DNS, certificate account or support ticket system is unavailable. Conversely, a portal can be reachable while the customer's storage network, firewall policy or routing advertisement is wrong. The public BGP record cannot settle those internal dependencies.

The concrete failure path to test is not "does AS208349 have routes?" It does. The test is whether a customer application remains reachable when one upstream, one exchange, one edge device, one DDoS path, one DNS provider, one portal account and one Moscow facility dependency are unavailable. If the answer depends on manual provider action, the customer needs the escalation contact, contractual response time and evidence that the provider has performed the operation recently.

Repair windows are set by people, parts and authority

Cloud capacity feels elastic until a failed disk, line card, power supply, fan, server motherboard or storage controller turns the abstraction back into a repair event. OXYGEN's smart remote-hands page is therefore an important part of the evidence. It describes engineering support for customer equipment and data-centre tasks rather than only self-service virtual capacity. That is the correct operational vocabulary for infrastructure: someone has to receive equipment, label assets, connect ports, replace components, check cabling and coordinate physical access.

Remote hands are valuable, but they are not a complete repair guarantee. A facility engineer may be able to replace a cable without being authorised to log into a hypervisor. A cloud engineer may be able to restart a virtual machine without being authorised to touch a customer's dedicated appliance. A spare disk may be available while the exact RAID controller, HBA, NIC, optical module or motherboard is not. An after-hours engineer may acknowledge a ticket quickly while the vendor part, software licence or security approval arrives later.

This is where the hosted-capacity bargain becomes economic. Spare hardware costs money. Reserved compute headroom costs money. Dual carrier paths cost money. A warm recovery site costs money. Keeping senior engineers on call costs money. A cloud provider that offers attractive price points has to decide how much unused capacity and human availability it holds back for failure. Customers cannot see that reserve from a VM price table.

O2 Cloud's sanctions status makes the repair question more than a normal logistics exercise for some counterparties. The OFAC listing does not say a server will fail. It does mean that some US-linked suppliers, payment channels, software vendors, remote service providers and insurers may be restricted or unwilling to support direct transactions. For a buyer outside Russia, this can affect procurement, contract enforceability, payment, hardware replacement, software updates and emergency assistance. For a buyer inside Russia, it can still affect imported parts, third-party software maintenance and cross-border support.

The right evidence is practical. Customers should ask for the support severity matrix, on-site staffing model, remote-hands scope, spare-parts approach, maintenance windows, recent incident examples, vendor-maintenance status, and the person or role authorised to act when a normal ticket queue is too slow. For dedicated equipment, they should ask who owns the hardware, where serial numbers are tracked, whether compatible replacement parts are stocked, and how data-bearing media are handled.

For virtual cloud, they should ask whether host failure is automatic, whether storage failure is protected, and whether enough spare capacity exists during maintenance or a hall-level incident.

The key point is not that O2 Cloud lacks repair ability. The public evidence does not prove that. The key point is that repair is not included merely because a service is called cloud. Repair is a chain of parts, access, contracts and people. A customer that cannot see that chain should assume a longer recovery window than the marketing page implies.

The affected parties are wider than the account owner

A hosted-capacity failure rarely stops with the person who pays the invoice. If O2 Cloud hosts a retail front end, the affected group includes shoppers, payment processors, delivery partners, inventory systems and staff who must reconcile transactions after service returns. If it hosts a database or private application for a Russian enterprise, the affected group may include employees, contractors, customers, auditors and regulators. If it carries customer networks behind AS208349 or downstream members of AS-O2CLOUD, a route or filtering error can affect organisations whose users may not know O2 Cloud's name at all.

This is why the ownership boundary matters. The business user may have contracted for "cloud" or "backup" while the actual recovery task spans a facility operator, a cloud team, a network operations team, a DDoS-mitigation path, a storage vendor, a software licensor, a billing account and perhaps a customer integrator. During a calm month, those layers can look like one service. During a failure, they become separate queues with separate authority.

If the customer's contract only names the front-line seller, the customer may not have standing to call the facility, order remote hands, pay an upstream, renew a licence or retrieve disks.

The downstream routing evidence makes this more concrete. The AS208349 policy does not only announce O2 Cloud's own prefixes; it also describes routes for other AS numbers through AS-O2CLOUD. The article does not treat those names as a verified customer list, but the routing structure still shows that the network can sit in front of other organisations. When an infrastructure provider becomes a transit or hosting dependency for another business, its own repair window becomes part of that business's public reliability. A router restart or filtering change can therefore create a customer-service problem elsewhere.

Billing is another affected-party path. A cloud platform can be technically healthy while a suspended account, payment block, sanctions screening hold or administrative error removes access. This is not a special accusation about O2 Cloud. It is a general cloud failure mode that matters more when the provider sits under sanctions and works with customers whose banks, vendors or insurers may interpret obligations differently. The customer should know who can keep access alive if an ordinary payment channel fails, and what documentation is needed to preserve service while a compliance review is resolved.

The same logic applies to data return. If the hosted workload contains personal data, financial records, medical information, logistics records or evidence needed for litigation, a provider outage can become a rights-of-access problem. Users may not care whether the failure was a rack PDU, a route leak, a storage snapshot issue or a blocked payment. They care whether the service owner can produce the record. That service owner needs a path to data that does not rely on the same failing portal.

For a buyer, this changes the service-level discussion. An uptime percentage is useful but incomplete. The buyer needs a list of business functions that must continue: order intake, payment capture, internal authentication, reporting, email, backup retrieval, incident notification, regulatory evidence and customer support. Each function should be mapped to the O2 Cloud component it relies on and to the alternate path that works if that component is unavailable. That map is the only way to see whether the provider is one dependency or several dependencies sharing one brand.

The most exposed customers are those using the platform as both production and recovery. If primary virtual machines, backups, monitoring, DNS, security filtering and emergency support all sit inside one provider relationship, then the customer has bought convenience but may not have bought independence. The OXYGEN catalogue includes products that can be combined into a resilient design, but the combination matters. A backup in OXYGEN object storage, a recovery cluster in another OXYGEN hall and a firewall managed by the same OXYGEN team may still be a strong design for some Russian workloads.

It is not the same as a provider-independent escape path.

The article's warning is therefore practical. Every organisation using O2 Cloud should decide which parties are harmed first, which parties have legal notice requirements, which systems must resume first, and which evidence is needed to prove restoration. Then it should ask O2 Cloud for the controls that match that impact. A small test environment can tolerate manual recovery and a best-effort answer. A regulated production system should not.

Backup and disaster recovery only count after a restore outside the failed path

OXYGEN's backup-as-a-service page markets cloud backup, and its disaster-recovery page markets emergency recovery. Those are the right services to look for in a hosted-capacity estate. They also create a useful trap for due diligence: the existence of a backup product does not prove that a specific customer has a restorable, independent and contractually portable copy.

The first question is copy independence. A snapshot on the same storage array protects against a mistaken file deletion better than it protects against a storage-system failure. A backup in the same hall protects against application corruption better than it protects against loss of power, cooling, fire access, provider account or sanctions-related supplier failure. A replica in another OXYGEN site can reduce facility risk, but it may still depend on the same provider control plane, administrator credentials, billing relationship and legal jurisdiction.

The second question is consistency. A virtual-machine snapshot is not automatically a clean business-system restore. Databases, message queues, file shares, identity systems, certificates, scheduled tasks, encryption keys, application secrets and integrations must line up. For a customer using hosted infrastructure for ERP, logistics, retail, banking interfaces or regulated personal data, a booted VM is not the same as recovered operations.

The third question is time. NIST's contingency-planning guide treats business-impact analysis, recovery strategies, testing and plan maintenance as central controls. NIST's storage-security guidance distinguishes backups, replication, snapshots and restoration assurance. Public-cloud guidance says the same thing in operational language: AWS's disaster-recovery options range from backup-and-restore through warm standby to active-active designs, and Google Cloud's disaster-recovery planning guide asks teams to confirm bandwidth, facilities, support, power, network infrastructure and tested recovery rather than only copy existence.

For O2 Cloud customers, the practical evidence is a restore report. It should name the production system, the backup source, the recovery location, the data-loss point, the elapsed restoration time, the people involved, the network changes required, the applications tested and the business owner who accepted the result. If backup is a managed service, the report should also show whether the customer can retrieve a copy independently, including encryption keys and documentation, if the provider relationship is interrupted.

Disaster recovery is not an accessory to buy after the outage. It is a capacity reservation and a procedure. If a buyer wants a workload to survive MSK East loss by starting in MSK West, then MSK West must have enough compute, storage, licences, routing, firewall policy and support authority before the incident. If the buyer wants to leave OXYGEN entirely, then the backup must be exportable to a provider-independent format and tested on infrastructure the customer controls.

Data locality is a benefit only when the boundary is explicit

The assignment category includes data sovereignty and locality, and O2 Cloud is a useful case because its value proposition is likely strongest for Russian or Russia-adjacent customers that want domestic hosting, Russian support, local connectivity and 152-FZ personal-data alignment. OXYGEN markets services connected to Russian information-security and personal-data needs. The Roskomnadzor register and RBC profile also place the company and its legal identity in Russia.

For a Russian customer, locality can be a genuine operating benefit. Traffic paths can be shorter. Russian personal-data placement can be easier to document. Support can be local. Payment and contracting can align with domestic procurement. Some workloads may be more comfortable in a Russian provider than in a foreign hyperscale region, especially where data export, regulator access, language and local software support matter.

But locality is not a complete resilience control. If all primary and recovery copies sit in one metro area, a regional facility or connectivity problem may still matter. If the same provider controls the portal, backups, DNS, certificates and recovery environment, the customer still has provider concentration risk. If sanctions complicate foreign software, hardware or payment flows, local hosting can reduce some legal problems while creating others for international customers.

Microsoft's reliability and sovereignty guidance frames the tradeoff well: redundancy across regions can improve continuity while changing jurisdiction, key placement and operator-access questions. The same logic applies outside Azure. A second location is valuable only if it is acceptable under the customer's data-location rules, and a domestic-only deployment is acceptable only if it still has enough separation to meet the customer's downtime and data-loss tolerance.

O2 Cloud customers should therefore document four locations, not one: where production data resides; where replicas reside; where backups, logs and monitoring data reside; and where support access can originate. They should also record who can access data under normal operations, emergency support and legal request scenarios. This is the level at which "RU" becomes more than a region label.

The sanctions layer changes the buyer population. A Russian customer may primarily evaluate local regulation, uptime, price and support. A multinational, a US person, a bank with US exposure, a vendor using US technology or a company that needs cross-border insurance must evaluate OFAC risk before even reaching the technical merits. That is not a moral gloss on the infrastructure. It is a practical fact about payment, support, contract enforcement and emergency procurement.

Migration is the last line of redundancy

Every cloud buyer wants failover. In many real outages, the only durable failover is the ability to leave. O2 Cloud's own catalogue includes services around migration and managed infrastructure, which is a reminder that movement is part of the product surface. A customer should treat exit rights as a recovery feature, not a legal appendix.

The migration problem starts with inventory. A VMware virtual machine can contain licensed operating systems, databases, middleware, proprietary background services, identity integrations, backup clients, firewall rules and monitoring hooks. A dedicated server can include firmware, RAID layouts, local disks and vendor warranties. A managed database can hide replication settings, extension versions and backup formats. A security product can sit in the path of production traffic. None of those components moves automatically just because the customer owns the business data.

The customer needs portable evidence before an incident. That means current configuration exports, VM images or rebuild scripts, database backups, encryption keys, licence records, DNS and certificate control, network diagrams, firewall policies, support contacts and a list of third-party integrations. It also means test capacity at the destination. A database extract is not portable if it cannot be restored inside the maintenance window. A VM image is not portable if the destination hypervisor, storage controller, network mode or licence policy rejects it.

NIST's cloud synopsis and recommendations treats service agreements, data transfer, performance, reliability, security and portability as connected buying questions. That is the right framework for O2 Cloud. The buyer should not ask only "can I get my data?" It should ask in what format, with which keys, within how many hours, at what bandwidth, under which contract state, and with which provider staff available.

O2 Cloud's public routing and service evidence make it plausible that many customers can run ordinary production workloads there. Plausibility is not enough for critical systems. The exit test should be performed while the relationship is healthy: restore a representative backup outside the provider, bring up a copy of the application, direct a test group through the alternate path, reconcile data, and confirm that the provider can delete or retain old copies according to the customer's legal duty.

The more regulated the workload, the more migration needs to include records and evidence. Personal-data systems need location and access logs. Financial systems need reconciliation and audit trails. Retail and logistics systems need interface continuity. Security systems need evidence that policies and logs survive. A customer that waits until a billing, sanctions, facility or support dispute begins may discover that the technical migration was only half of the problem.

The verdict: strong network evidence, conditional operational confidence

O2Cloud O2 Cloud, LLC should be treated as an active Russian infrastructure provider with strong routing evidence and a substantial service brand. The company is visible in corporate records, in communications licensing, in RIPE as a LIR, in AS208349 routing, in OXYGEN service pages and in third-party data-centre certification records tied to Business System Telehouse's Oxygen halls. That is far more than a dormant directory entry.

The downgrade is about recovery proof, not existence. Public pages describe cloud, backup, recovery, security, hardware rental and support services, but they do not publish the customer-specific facts that convert those services into resilience: exact facility placement, power and rack separation, cluster boundaries, spare capacity, storage replication, route independence, escalation authority, backup independence, restore tests, export rights and sanctions-safe supplier paths.

For ordinary Russian workloads that need local cloud capacity and accept the provider's legal environment, O2 Cloud may be a rational candidate if the contract and tests match the workload. For workloads with international counterparties, regulated personal data, strict recovery objectives, imported hardware dependencies or exposure to US sanctions rules, the diligence bar is higher. The provider can be real and still be the wrong recovery boundary for a given customer.

The practical answer is to buy evidence, not adjectives. Ask for the site map, the AS path, the backup architecture, the last restore, the spare-stock policy, the support matrix, the data-location schedule, the sanctions compliance answer and the exit package. Then test a failure that removes the primary facility, the primary route, the normal support path and the provider's self-service portal. If the workload survives that exercise within the business tolerance, O2 Cloud's hosted capacity is doing what cloud buyers pay for. If it does not, the customer's real redundancy is still outside the provider.