INCOSOFT 1 Cloud Lab s.r.o. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• 1 Cloud Lab s.r.o. is an active Slovak company with a current service storefront, 2025 service revenue of EUR262,866 and net tangible fixed assets of EUR125,593. Those facts support a real operating business, although they do not establish the installed capacity, ownership or engineering design of any particular data-centre site.
• The legacy AS20949 name, INCOSOFT, is still attached to the company in Internet registries, but RIPE measurements show that AS20949 has originated no visible address space since July 2023. Other systems associated with the 1 Cloud Lab and ColoCall names remain active, so AS20949 alone is a poor proxy for current customer reachability.
• The storefront sells IaaS, private infrastructure, VPS, bare metal, backup space, network access, DDoS protection and Kubernetes in broadly labelled Ukraine and European Union locations. It does not publicly name the European facility, publish a site-by-site capacity inventory, identify power and carrier paths, or show a tested cross-site recovery result.
• The standard terms put important limits around the commercial promise. They contain no quantified availability commitment, service-credit schedule or recovery objective, disclaim responsibility for third-party communication channels, and allow suspension and later deletion for non-payment. Buyers should treat backup, portability, billing continuity and escalation as engineering dependencies, not administrative details.

The old network name is not the whole operating company

INCOSOFT survives as a network label. In the RIPE registration for AS20949, the autonomous system is called INCOSOFT, while the linked organisation is 1 Cloud Lab s.r.o. The resulting composite name is useful for finding the record, but it compresses several different facts into one line: a legacy routing identity, a Slovak legal company, a commercial service brand and a wider set of network resources that use the 1 Cloud Lab or ColoCall names.

The legal company is easier to date. Slovakia's commercial register records 1 Cloud Lab s.r.o., company number 52 335 267, as incorporated on 6 June 2019. Its registered address changed in October 2024 to Staré Grunty 3546/7A in Bratislava-Karlova Ves. The registered activities include computer services and services related to computer data processing, alongside broader trading and administrative activities. The RIPE NCC member page gives the same Bratislava location and identifies Slovakia and Ukraine as areas served.

That continuity matters, but neither address proves the location of a machine room. A corporate seat can house management, mail or contracting functions without containing customer racks. The 1 Cloud Lab website describes the business as a Bratislava data centre and offers an EU location in its configurators, yet it does not publish a street address for that facility. A customer deciding where regulated or latency-sensitive data resides still needs a contract schedule that names the building, country, operating company and permitted failover locations.

There is also evidence of a longer operating lineage than the Slovak company itself. The site's company history describes the ColoCall data centre as founded in March 2000 and serving its first customer that August. The current 1 Cloud Lab home page says it has managed equipment and clouds for more than 20 years. Those statements describe the heritage of the service operation and brand family; they should not be read as saying that the Slovak limited company existed in 2000. The distinction is especially important in due diligence because experience may reside in a team or associated Ukrainian operator, while contractual liability rests with the entity named on an invoice.

What customers can actually order

The service catalogue is broad for a small provider. The main storefront lists cloud infrastructure, private cloud infrastructure, bare-metal servers, cloud servers, backup space and Kubernetes, plus cloud disks, network channels and DDoS protection. Its ordering pages permit a customer to choose either Ukraine or the European Union for many services. That combination positions 1 Cloud Lab between a local hoster and a regional infrastructure reseller: it packages compute, storage and connectivity, while also exposing enough hardware detail for a buyer to select processor class, memory, disk medium and bandwidth.

The IaaS configurator offers pools of CPU, RAM, HDD, SSD or NVMe capacity, virtual networks, public addresses, firewall rules and backup space. It advertises provisioning in up to one day. The private infrastructure page goes further, describing dedicated physical compute nodes for one customer's exclusive use and a spare server included for fault tolerance. It offers Intel E5, Intel Gold or Platinum and AMD Rome or Milan platforms, with local and shared storage choices.

Those details expose a crucial difference between capacity that exists in a catalogue and capacity that can withstand a failure. Local NVMe is described as binding a virtual server to one compute node, without migration. Shared cloud storage is intended to permit more flexible movement. A buyer selecting the fastest local medium may therefore surrender the recovery characteristic implied by the general cloud label. The spare node offered with private infrastructure is meaningful only if it is powered, cabled, compatible, monitored and able to assume the failed node's workloads within a defined time.

The public page does not disclose the orchestration method, admission threshold, rebuild time or amount of capacity held back across customers.

The bare-metal configurator is similarly concrete and ambiguous. It lists Supermicro platform generations, ECC memory, local drives, RAID or HBA controllers, IPMI access, bandwidth and optional backup space, with stated preparation of one to three days. The available generations span older Intel E5 systems through newer Intel scalable processors and AMD Rome or Milan. That range can be commercially useful, particularly for price-sensitive workloads, but it also makes spare-part planning central. A failed motherboard, RAID controller or drive does not recover because a web page still lists the product family. Recovery depends on compatible stock at the relevant site and a technician authorised to fit it.

For virtual servers, the VPS ordering page advertises provisioning within an hour, selectable disk classes, snapshots, firewall rules and basic support. The more descriptive cloud server page says storage keeps two copies of customer data and that cloud systems are reserved and geographically distributed. It also says snapshots may be scheduled daily or created manually. These are useful service claims, but they leave several variables open: whether replicas occupy separate racks, halls, buildings or countries; whether both copies share a control plane; whether snapshots are crash-consistent or application-consistent; and how often restoration is exercised.

The backup-space service supports FTP, FTPS, SFTP, SCP and rsync, with selectable transfer speed and an option for traffic outside 1 Cloud Lab networks. This is a relatively portable set of access methods. It is nevertheless not evidence that a backup is independent. If the production server and backup repository share a facility, power system, administrative credentials or storage controller, one incident can affect both. Customers need the repository's physical location, immutability controls, retention rules, restore throughput and deletion behaviour before calling it a disaster-recovery copy.

The latest service addition is Kubernetes. The Kubernetes order page offers clusters in Ukraine or the EU, while describing the infrastructure as running in a Ukrainian data centre. A separate Kubernetes description says the Ukrainian infrastructure is underground and meets a Tier III level of engineering reliability. The site's September 2025 announcement names ColoCall and directs orders to colocall.net. These pages show an actively maintained offer, but they also illustrate why location has to be specified per order rather than inferred from the language or domain of the storefront.

The accounts show activity, assets and external dependence

The most recent Slovak accounts provide stronger evidence of operation than marketing language alone. The official Register of Financial Statements entry lists annual filings from the company's formation onward. The 2025 financial statement, submitted on 7 July 2026, reports EUR262,866 of net turnover, all recorded as revenue from services. It reports EUR31,331 of profit after tax and total assets of EUR255,257.

The balance sheet also shows EUR125,593 of net tangible fixed assets at year-end: EUR22,395 in structures and EUR103,198 in movable assets and collections of movable assets. That is consistent with a business holding physical equipment. It is not enough to infer a rack count, server count or data-centre ownership. Accounting categories aggregate assets and do not identify where they are installed, whether they are pledged, whether equipment serves one or several locations, or whether the structures line represents a technical facility.

The year-on-year movement adds context. Service revenue fell 17.3% from EUR317,742 in 2024, while profit after tax fell 43.8% from EUR55,741. Total assets rose 10.3%, but net tangible fixed assets fell 12.8% from EUR144,094. Cash in bank increased to EUR115,025. None of those changes proves distress or expansion by itself. They describe a profitable but modest business whose equipment base is being depreciated and whose reported revenue can move materially from one year to the next.

The cost structure is even more informative for resilience. Purchased services were EUR188,549 in 2025, equal to 71.7% of service revenue, while material, energy and other non-storable supplies were EUR9,152. The statement records no personnel cost. This does not prove that nobody works on the service: directors, contractors, affiliated-company staff or suppliers may provide labour under other headings. It does show that much of the economic activity sits in services bought from outside the Slovak company rather than in a large payroll.

For a hosting provider, that is an ownership-boundary clue. Facility space, electricity, transit, remote hands, hardware maintenance, licences, mitigation capacity and intercompany services can all appear as purchased services. A provider can run reliably with such a model, but its continuity is partly the continuity of its contracts. A lease dispute, unpaid carrier bill, unavailable contractor or changed related-party arrangement can affect customers even when the customer-facing virtual machines are technically healthy.

Short-term liabilities reinforce the need to understand that boundary. The 2025 accounts show EUR131,208 of current liabilities, including EUR37,982 of trade liabilities and EUR91,469 owed to shareholders or an association. There are no reported bank loans. These figures are not a prediction of failure, and the company held substantial cash. They do show why customers should identify which critical assets and agreements belong to the Slovak entity, which belong to a related operator, and which are supplied by an unrelated facility or carrier. Continuity rights are strongest when the contract maps those dependencies explicitly.

Routing evidence separates a quiet legacy ASN from active networks

An autonomous system is not a data centre, and a data centre does not have to originate its own routes. Still, routing visibility is one of the few independent ways to test whether a claimed network identity is currently carrying public address space. In this case it changes the interpretation materially.

RIPEstat's current overview of AS20949 identifies the holder as “INCOSOFT 1 Cloud Lab s.r.o.” but marks the system as not announced. Its routing-status data says the last observed route was 193.108.236.0/23 on 25 July 2023. As of 12 July 2026, none of 326 IPv4 or 322 IPv6 RIPE RIS peers saw AS20949, and its announced address space was zero. Hurricane Electric's AS20949 record independently says it has not been visible in the global table since 26 July 2023.

The registration itself has not disappeared. The RIPE whois data retains policy entries naming AS15497, AS25521 and AS29442, and it retains the assigned status. Registration and operation are different states: an assigned number can remain in the registry while no route from it reaches the public Internet. For customers, the practical question is not whether AS20949 exists on paper but which ASN and prefixes their purchased service will actually use.

Other 1 Cloud Lab-linked networks are active. RIPEstat identifies AS206110 as 1 Cloud Lab s.r.o.; on 12 July 2026 it showed five IPv4 prefixes covering 1,024 addresses, full visibility among RIPE's IPv4 collectors and one observed neighbour. That one-neighbour observation suggests a stub-like public topology at the time measured. It does not prove that every customer has only one physical route, because a provider may use internal links, other origins or addresses supplied by another network. It does make the actual service attachment worth asking for.

AS15497, described by RIPEstat as “Colocall 1 Cloud Lab s.r.o.,” was substantially larger: 19 IPv4 prefixes covering 16,896 addresses, one IPv6 prefix and 37 observed neighbours on the same date. AS12837, registered to the Ukrainian “1 CLOUD LAB” LLC, announced nine IPv4 prefixes, one IPv6 prefix and had five observed neighbours. These active systems fit the storefront's Ukraine-and-EU service model, yet the names alone do not establish which legal entity operates each rack, carries each customer contract or controls each address block.

The key conclusion is therefore narrower than “the network is inactive.” AS20949 is inactive as a public origin, while service activity under the 1 Cloud Lab and ColoCall names continues through other resources. A customer should receive the actual ASN, prefix, upstream and facility for each service location. Without that mapping, a route-diversity claim can accidentally count two commercial labels that converge on the same physical fibre, router, building entrance or upstream organisation.

Racks and power define the usable ceiling

Cloud capacity is sold in divisible units, but its supply arrives in indivisible entities: servers, drive shelves, switches, cross-connects, power circuits and racks. The difference between installed capacity and usable capacity is the reserve kept for failures and peaks. A provider may own 100 units of compute and still be able to sell much less if it intends to survive a node outage without contention. Conversely, it may sell close to the physical ceiling and rely on best-effort recovery.

1 Cloud Lab's private infrastructure configurator says one additional server is included for fault tolerance. That is a welcome acknowledgement of the reserve problem. The public material does not say whether the spare is dedicated per customer, shared across customers or merely part of the proposed bill of materials. Nor does it state the failure domain. One extra host in the same rack protects against some server faults, but not a failed top-of-rack switch, power distribution unit, cooling zone, building or inaccessible city.

The cloud page says systems are geographically distributed and storage holds two copies. Geography can mean two rooms on one campus, two cities, or two countries; each offers a different protection level. Two synchronous copies can also share a control fault or be corrupted together. The service pages do not publish a failure-domain diagram, a replication distance, a quorum design, a recent failover result or a statement of what happens when the link between sites is lost.

Power is similarly visible only through its absence. The standard terms make the contractor responsible for supplying electricity and maintaining climate conditions, but the public pages do not identify utility feeds, UPS topology, generator autonomy, fuel contracts or tested maintenance arrangements for the European location. For the Ukrainian offer, the underground-site statement addresses physical protection at a high level, not the duration of independent power or the logistics of repair during a prolonged disruption.

The 2025 financial statement's EUR9,152 line for materials, energy and other non-storable supplies should not be treated as the total electricity cost of all customer infrastructure. A leased or bundled facility service can put much of the power expense into purchased services. That accounting possibility is another reason the asset and supplier boundary matters. If the company rents racks with power included, the facility operator's maintenance and credit arrangements become part of the customer's availability chain.

Hardware inventory limits recovery in a different way. The catalogue spans several processor generations, disk types and controller choices. Replacement is quickest when the same board, memory type, drive interface and firmware are on site. It slows when a part must be sourced, shipped across a border or substituted with a platform that requires a migration. The dedicated-server description says failed leased equipment is replaced in 24/7 mode without waiting for a supplier. It does not commit to a maximum replacement time. “Shortest time” is operationally different from a four-hour repair promise.

Transit diversity has to survive a physical cut

The communication-channel page sells world and Ukrainian bandwidth, firewall rules, cleaned traffic and private peering through an Internet exchange. It also says a connection can be delivered at the provider's sites while the customer arranges transport separately. This is useful flexibility, but it creates several possible responsibility boundaries: 1 Cloud Lab may provide the server and local port, another company the metro circuit, an exchange the peering fabric, and one or more upstreams the global route.

The public BGP record demonstrates more than one named relationship historically for AS20949, and AS15497 currently has many observed neighbours. Neither fact proves physical path diversity for a particular customer. Two sessions can run over fibres in the same duct. Two carriers can buy capacity from the same wholesale network. IPv4 and IPv6 can differ. A DDoS service can redirect traffic through a scrubber whose own failure removes reachability.

The DDoS page advertises mitigation of attacks up to one terabit per second in Ukrainian and EU data centres. An older news item claimed 1.2 terabits per second. These are vendor statements, and the public pages do not identify the mitigation partner, scrubbing locations, clean-traffic capacity delivered to the customer's port, attack classes covered, or service credits if diversion fails. Buyers should distinguish headline absorption capacity from the clean bandwidth available to their own application.

A proper diversity test asks for the A- and B-side path at the level of building entrance, meet-me room, router, long-haul provider and upstream ASN. It also asks whether both paths can carry full contracted traffic during maintenance, whether route filters and RPKI authorisations are current, and whether the provider has exercised the failover under load. An Internet map with several lines is not equivalent to a maintenance record showing that one line can be removed without customer impact.

Repair windows turn support claims into outcomes

The contact page gives office hours of 10:00 to 18:30 and says a duty shift and technical support operate 24 hours a day, seven days a week. That is a relevant availability claim. It does not disclose staffing depth, languages at every hour, escalation roles, on-site presence or the response and restoration targets attached to severity levels.

Small infrastructure providers can offer excellent support because customers reach experienced engineers directly. They can also face concentration risk when a few people hold the knowledge or access needed to restore service. The accounts' lack of personnel cost makes the staffing model a legitimate diligence question, not evidence of poor service. The answer may be contracted engineers or staff employed by an associated operator. What matters is whether the customer contract secures their availability when incidents overlap or transport to a facility is constrained.

Several failure paths therefore converge on labour. A dead drive requires someone to identify the right bay and replacement. A failed router may need console access. A backup restoration may need a storage administrator. A customer migration may need both old and new platforms available at once. If those tasks rely on the same duty engineer, nominal redundancy in hardware can still meet a human bottleneck.

The service material shows useful remote mechanisms. IPMI is offered for bare metal, PXE booting was introduced for physical servers, and the panel permits some configuration changes. Remote control reduces travel time, but it does not replace hands for failed hardware, cabling or power. It also raises access-security questions: management interfaces need isolation, strong authentication, logging and a tested method of access when the main customer network is down.

For buyers, the repair commitment should be measurable. Response time is not restoration time. A ticket can be acknowledged in five minutes while a compatible controller arrives the next day. The useful contract identifies severity, acknowledgement, workaround, repair, spare-stock assumptions, maintenance notice, escalation contacts and compensation. None of those details is quantified in the public standard terms, so they must be obtained in an order-specific service schedule if they exist.

Billing is part of availability

Infrastructure can fail administratively as well as electrically. The standard terms say the first invoice constitutes acceptance of the public contract and allow up to seven business days to provide services, despite shorter times shown in some configurators. Monthly invoices are due within eight banking days. Full or partial non-payment allows the contractor to suspend services or terminate the contract.

The terms also allow customer information on contractor-provided drives to be deleted after contract termination or after 15 days from suspension for non-payment or another breach. The wording does not promise a grace period designed around the customer's recovery needs. A failed invoice delivery, bank review, disputed amount or change in accounts-payable staff can therefore become an infrastructure incident. Customers should use redundant billing contacts, monitor renewal and invoice status, and ensure that a technical escalation occurs before destructive action.

Liability is bounded sharply. The contractor accepts responsibility for electricity, climate and the operating condition of equipment it provides, subject to the terms. It disclaims responsibility for the global Internet and third-party communication channels to which it connects, as well as broad categories of customer and third-party loss. The document does not state an uptime percentage, service-credit schedule, recovery time objective, recovery point objective, planned-maintenance allowance or support severity table.

The contract also permits either party to terminate with at least 15 calendar days' notice, while the EU Data Act now sets more detailed expectations for switching between data-processing services. The Data Act has applied since 12 September 2025. Its cloud-switching provisions require written terms covering exportable data and digital assets, a maximum notice period, a transition period and post-transition retrieval, among other matters. From 12 January 2027 it also removes switching charges, subject to the regulation's terms.

This is not merely a legal drafting point. Portability is a recovery mechanism. A customer cannot exit quickly if virtual disks are available only through a proprietary interface, if snapshots cannot be exported, if egress capacity is too small, or if a large dataset takes weeks to copy. The 1 Cloud Lab backup service's standard protocols are helpful, but the public terms do not enumerate export formats for virtual machines, networks, firewall rules, snapshots, entity stores or Kubernetes state. An exit test should time the transfer of a representative workload and verify that it boots at the destination.

Data location needs a named site, not a regional toggle

The Ukraine/EU selector is commercially simple but limited public evidence for data-governance decisions. “EU” is not a facility, and it does not tell a customer whether support staff in another country can access the system, whether backups cross the border, or whether a failover moves data outside the selected location. “Ukraine” is more specific as a jurisdiction but still encompasses multiple physical and operational risks.

The standard terms contain a short data-processing section. They say the contractor accepts personal data entrusted by the customer, will keep it confidential and will implement appropriate technical, organisational and IT measures. The terms do not name subprocessors, processing locations, breach-notification timing, audit evidence, return format or a detailed deletion method. Those items normally belong in a fuller data-processing agreement and service schedule.

The General Data Protection Regulation requires a controller to use processors that provide sufficient guarantees and requires appropriate security, including the ability to restore availability and access to personal data in a timely manner after a physical or technical incident. It does not turn any particular architecture into compliant infrastructure automatically. A buyer still has to match controls to risk, obtain contractual commitments and verify where processing occurs.

The NIS2 Directive separately identifies cloud-computing and data-centre service providers in its digital-infrastructure coverage and calls for cybersecurity risk-management measures where an entity falls within scope under national implementation. That context increases the value of a clear legal-entity and facility map. A brand shared between a Slovak company and Ukrainian operations may support regional resilience, but it also requires precise responsibility for incident reporting, supply-chain controls and business continuity.

For each order, a customer should therefore obtain four location facts: where primary compute runs, where every replica and backup resides, where administrators can access it from, and which legal company supplies each component. Those facts should remain true during maintenance and emergency failover, not only during normal operation.

What happens when one dependency fails

The most plausible failure is not one dramatic event but a chain. Consider a physical server whose local NVMe device fails. The server is tied to that node, so live migration is unavailable. An engineer must diagnose the fault, find compatible stock, replace the device and restore data. If the most recent copy is in backup space at the same site, a rack or power incident may have affected both. If it is at another site, recovery speed depends on transit capacity. If the account is suspended during a billing dispute, access to the copy may become a commercial rather than technical question.

A route failure produces another chain. A customer prefix may be carried through AS206110, AS15497, AS12837 or provider-assigned space, not AS20949. The recovery path depends on which network originates the route, whether another upstream accepts it, whether a valid authorisation exists, and whether the alternative physical circuit reaches a router that is still powered. A historical policy entry is not enough; the current service attachment must be known before an incident.

A facility failure is broader. If compute and storage copies share one site, both can stop. If a second site exists but lacks reserved compute, data may be safe but the application unavailable. If compute is available but IP addresses cannot move, customers may need DNS changes and wait for caches. If the second site is in another jurisdiction, restoration may conflict with a location commitment. The phrase “geographically distributed” does not resolve any of these choices.

A support failure can lengthen every other event. Around-the-clock contact is valuable, yet restoration needs access, authority and expertise. The same engineer may be handling power alarms, route changes and hardware replacement. Customers with critical services should know whether escalation is local to each site, whether the network and facility teams are distinct, and who can act if the Slovak contracting company cannot reach an associated operator.

Finally, a provider-contract failure can outlast a component failure. The high share of purchased services in the Slovak accounts means third-party and related-party agreements are economically significant. If a facility lease, carrier account, licence or support arrangement ends, workloads may need an orderly move even though no server has broken. Contract portability and a regularly exercised customer exit are therefore part of availability engineering.

Who bears the impact

The immediate users are likely to be small and medium-sized organisations, developers, online services and institutions that want regional hosting, direct support or lower-cost hardware. They may be attracted by configurable bare metal, Ukrainian connectivity, EU placement, familiar backup protocols or the ability to speak with engineers rather than a global cloud's general support queue.

Those customers can also have less internal resilience. A small business may put its production application, backups, DNS and mail on one provider because the arrangement is convenient. A software team may assume two storage copies equal disaster recovery. An organisation choosing an EU location for regulatory reasons may not realise that the public material leaves the exact site and failover geography unstated. When the service fails, downstream users experience inaccessible websites, stalled transactions, unavailable records or delayed communications.

The impact can reach beyond the contracting customer. Hosted domains and APIs support other businesses; a backup repository may hold personal data; a Kubernetes cluster may run public services; a dedicated server may be the only copy of a legacy application. Abuse handling and route security also affect the wider Internet. This is why a provider's modest revenue does not imply modest consequence for every tenant.

Customers retain responsibilities too. The bare-metal page explicitly says users must arrange their data correctly and keep backups. The provider cannot make an application consistent if the customer never quiesces its database. Nor can a facility-level spare node rescue a customer that hard-codes one IP address or stores encryption keys only on the failed server. Resilience is shared, but the provider must disclose enough about its part for the customer to design theirs.

A credible recovery design would separate four layers

For 1 Cloud Lab's service mix, recovery should begin by separating compute, storage, network identity and management access. Putting two virtual machines on different hosts is useful, but it protects only the compute layer if both hosts depend on the same storage array, switch and power feed. Keeping two storage copies is useful, but it protects only the data layer if both copies are administered through one controller or become inaccessible with the same account. A second carrier is useful, but it protects only reachability if the application cannot start at the surviving site.

At the compute layer, the advertised extra private-infrastructure node should have a disclosed purpose. If it is a hot spare, the provider should say how quickly workloads restart and whether software licences follow them. If it is an active cluster member, the provider should state the capacity remaining after one node fails. A customer that normally consumes all nodes at 80% utilisation may have no room to absorb a failure even though every component is functioning as designed. Admission control, not the raw server count, determines usable capacity.

Bare metal requires a different promise. A spare chassis does not necessarily accept the customer's drives, controller, network card or firmware. The most credible arrangement pairs a documented replacement class with a bootable off-host copy and a tested rebuild sequence. For legacy platforms, the provider should identify which parts are held locally and when substitution becomes a migration. Customers using IPMI should also retain a separate, strongly protected route to the management network so a production routing fault does not remove the recovery console.

At the storage layer, snapshots and backups need distinct jobs. A local snapshot provides fast rollback from a bad update but may share the source array's failure domain. A replicated disk can keep an application running after a device failure but can reproduce deletion or corruption. A separately authenticated backup, retained at another site and tested by restoration, addresses a broader event. The public claim that storage holds two copies is therefore a starting point, not a complete protection design.

Transfer speed sets the physical limit on restoration. Moving 10 terabytes over a sustained 1 gigabit-per-second link takes more than 22 hours before protocol overhead, contention and verification. At 100 megabits per second it takes more than nine days. The backup configurator's selectable transmission speed is consequently an availability decision. The customer should size restore bandwidth for the recovery objective, not only backup bandwidth for the nightly copy window, and should verify whether the quoted rate is available during a site-wide incident.

At the network layer, the cleanest design avoids making one provider-originated prefix the only path to the application. Depending on scale, a customer can use provider-independent addressing, a second DNS endpoint, an external traffic manager or a preconfigured alternate site. Each option has costs and timing limits. Small customers may reasonably remain on provider-assigned addresses, but they should know the DNS time-to-live, certificate dependencies and steps required to publish a replacement endpoint.

The management layer is the final dependency. Account credentials, encryption keys, DNS control and recovery instructions must remain available when the hosted service is not. A customer whose password manager, mail and identity provider all run inside the failed environment may be unable to authenticate to support. 1 Cloud Lab's around-the-clock contact claim becomes more useful when customers have an out-of-band contact method and when the provider can verify authorised emergency requests without relying on the unavailable system.

Cross-site recovery should combine all four layers in one exercise. A representative application is stopped at the primary location, data is restored or promoted elsewhere, network access is changed, operators connect through independent management paths, and users validate the result. The test should also reverse the move, because returning to the primary site can be as risky as leaving it. This is the evidence that would turn general claims of geographic distribution into a dependable customer outcome.

Evidence that would raise confidence

The operating evidence is stronger than the thin public name initially suggests. There is a live storefront, a recent service launch, an active Slovak company, annual financial filings, tangible assets, an LIR membership and visible address space under associated network identities. This is not merely a dormant registration attached to a dead website.

Confidence stops short of strong because the evidence is not facility-specific. The decisive upgrade would be a current service schedule or assurance pack naming the European and Ukrainian sites, their operators and the legal entity responsible for each service. It should identify rack or hall failure domains, utility and generator design, carrier entrances, upstreams, reserved compute, storage replication boundaries, backup geography and remote-hands coverage. Certification claims should be tied to the named site and current scope rather than to a general tier label.

Operational proof would matter more than design prose. Useful evidence includes a recent generator and transfer-switch test, a maintenance performed without customer interruption, a sample hardware-replacement record, a route failover observed from outside the network, and a full restore of an application from the secondary copy. The result should state elapsed time, data loss, exceptions and the capacity available while degraded.

Commercial proof is equally important. A complete service agreement should add uptime and support targets, maintenance notice, escalation, service credits, subprocessor and location lists, incident notification, data-export formats, retrieval period, deletion method and assistance during exit. The customer should test those terms with a representative workload before it becomes critical.

Until then, the appropriate evidence grade is medium. 1 Cloud Lab has credible signs of current business and physical equipment, and active networks associated with its operating names are visible. But the public record does not let an outsider trace a customer service all the way from invoice to legal operator, rack, power chain, transit paths, spare part, backup copy and tested recovery. For hosted infrastructure, that trace is the difference between capacity that can be ordered and capacity that can be trusted through a repair window.