LIVEHOSTING DATACENTER SRL has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• LIVEHOSTING DATACENTER SRL publicly identifies itself as the operator of a data centre in Timisoara and as the holder of AS41635. Its current sales pages offer web hosting, virtual and dedicated servers, server management and 1U-3U colocation.
• The public network edge is active, not merely registered. RIPEstat observed 89.38.208.0/22 from AS41635 on 12 July 2026, visible to all 326 reporting IPv4 peers in its routing-status snapshot, with AS12302 and AS39737 as observed adjacent networks.
• The physical evidence is less current. A 2012 Romanian industry guide reported a 30-square-metre data room, two 50 kW three-phase supplies, a 100 kW diesel generator and four 40 kW UPS units. Those figures are useful history, but they do not establish the equipment, load, runtime or redundancy available in 2026.
• The colocation page lists two power supplies, UPS, generator, DDoS protection and a 1 Gbps internet port. It does not publish A/B circuit separation, generator fuel endurance, cooling redundancy, fibre entrances, carrier commits, maintenance test results or a second recovery site.
• The network evidence grade is Medium. There is convincing evidence of a current service and routed operating surface, but not enough current, independent evidence to treat marketed capacity as concurrently maintainable or demonstrably recoverable after a facility or carrier failure.

The claim is specific enough to test

LIVEHOSTING DATACENTER SRL does not hide behind a vague cloud label. Its current contact page names the Romanian legal company, gives registration number J35/815/2010 and tax code RO26963713, identifies AS41635, and says the company operates its own data centre in Timisoara. Its colocation offer places customer equipment in that facility and lists UPS and generator protection. This is more concrete than a reseller that never identifies a site or a network.

Specificity creates a useful burden of proof. If a provider says it operates the building-level infrastructure behind customer workloads, the relevant unit is not the virtual server shown on a price page. It is the complete chain from utility intake to UPS, generator, power distribution, cooling, rack, switch, edge router, carrier path and technician. Every link can reduce the capacity that customers can actually use during a fault.

The company's public estate spans several dependency types. Its home page markets Windows and Linux hosting, virtual servers, dedicated servers, colocation and server management. Shared-hosting customers depend on a platform the provider controls. Virtual-server customers depend on host and storage design they cannot inspect directly. Dedicated-server customers depend on hardware, switching and remote access. Colocation customers own more of the server but still depend on the facility and network. A failure at the common power or carrier layer can therefore affect products that look separate at the invoice layer.

The key distinction is between proof of operation and proof of resilience. AS41635 and the current product catalogue make a persuasive case that LiveHosting is operating. They do not, by themselves, show how much load survives the loss of one utility path, one UPS string, one cooling unit, one edge router or one fibre entrance. That second question determines whether a small Timisoara data centre is merely available on an ordinary day or recoverable on a difficult one.

A current service sits behind a small public footprint

The public evidence supports a real operating business. LiveHosting publishes prices for virtual servers, dedicated servers and colocation, maintains customer account and ordering pages, and exposes a network abuse contact. Its SSD virtual-server page lists six configurations, while its NVMe page lists another six. Its dedicated-server pages advertise HP ProLiant DL360 G7 and G8 systems with dual hot-swap power supplies and multiple network interfaces.

Those pages establish a sales surface, not an inventory count. They do not say how many physical hosts are installed, how many are available for immediate delivery, what proportion of CPU and memory is committed, or whether replacement systems and drives are kept on site. A configuration can remain orderable while the last suitable chassis is in use, while a spare is being repaired, or while new power cannot be allocated to a rack. Buyers should therefore treat listed configurations as marketed service classes rather than audited installed capacity.

The public corporate footprint also looks small. Termene.ro's company profile, an aggregator of Romanian company information, reports 2024 turnover of RON736,213, net profit of RON286,410 and an average of one employee. LinkedIn, by contrast, classifies the company in a two-to-ten employee band and says it has served more than 4,000 customers since 2006. Neither source proves the current number of engineers available for a night-time incident. Contractors, affiliated staff, carrier technicians and building personnel may all sit outside a statutory average or a social-media range.

That uncertainty matters without implying that a small team is incapable. Small operators can be technically disciplined and responsive. They can also depend heavily on one administrator's knowledge and on suppliers whose response times are outside the customer's contract. The relevant evidence is a current duty roster, escalation arrangement, access list and supplier support entitlement. Public headcount signals simply make those questions more important.

Timisoara is the service location, but not a complete site map

LiveHosting repeatedly says it operates its own data centre in Timisoara. Its legal contact information places the registered office in Dumbravita, just outside the city, while the colocation page states that the service location is “LiveHosting Datacenter Timisoara.” These are compatible statements, but they do not prove that the registered office, the data room and every advertised server are at the same address.

Data Center Map's facility entry describes one LiveHosting facility within two kilometres of Timisoara city centre and says the exact location is not public. Its ecosystem page reports no network or service-provider data for the site. Data Center Map is a commercial directory, not an engineering audit, but the absence of a public exact address reinforces an important boundary: the city is supported; the building identity and ownership structure are not.

“Own data centre” can describe several arrangements. The company may own the property and all mechanical and electrical plant. It may own the IT room inside a leased building. It may operate racks and switching while a landlord controls utility intake, fire systems or cooling. It may contract generator maintenance or remote security. None of those models is inherently deficient. They create different restoration rights and different pacing suppliers.

A customer evaluating colocation should ask for a responsibility matrix. It should identify who owns the building, who operates each electrical stage, who maintains cooling, who controls physical access, who holds the generator fuel contract, who owns the external fibre, and who can authorize emergency work. It should also distinguish the legal registered office from the facility address and from any backup location. Without that map, the phrase “own data centre” is useful but incomplete.

The service area is clearest at the network level. AS41635 is registered in Romania, the product is sold in Romanian, and an IPinfo traceroute reached an address in the originated block through Prime Telecom to a Timisoara-labelled destination in June 2026. That supports Romanian delivery. It does not prove that every backup, control service, monitoring probe or customer copy remains in Romania.

A detailed 2012 snapshot cannot certify the 2026 plant

The most specific public description of the physical plant appears in Market Watch's Data Center 2012 guide. The guide reported a 30-square-metre data room, two three-phase transformer supplies rated at 50 kW each, one described as coming from Electrica and the other from CET, a 100 kW diesel generator, and four UPS units rated at 40 kW each. It also listed 1 Gbps communications, Dell servers, storage and networking, monitoring through PRTG and DRAC, and ISO 9001 and ISO 27001 certifications.

That is valuable historical evidence because it gives scale and topology claims that the current website does not. It is also fourteen years old. Equipment ages, batteries are replaced, cooling is expanded, distribution is rewired, carrier contracts change, and facilities move. The guide may have captured the provider's then-current description accurately while saying little about the plant now serving customers.

The numbers also require interpretation. Two nominal 50 kW supplies do not necessarily equal 100 kW of resilient IT load. If either supply must be able to carry the whole room, the resilient utility capacity may be closer to the smaller path's usable rating after losses and non-IT loads. A 100 kW generator does not establish the IT load it can support once cooling, UPS losses, lighting, pumps and startup currents are included. Four 40 kW UPS units do not reveal whether they were configured as N, N+1, 2N, or separate systems supporting different loads.

The current website should therefore be read alongside, not merged with, the 2012 guide. Current pages prove that colocation and server products remain marketed. The old guide shows what the company once disclosed. No public document reviewed here connects the historical ratings to a current single-line electrical diagram, commissioning record, load test, battery condition report or fuel-runtime test. Until those appear, the historical figures are a baseline for questions, not a current capacity certificate.

Two server power supplies do not prove two independent power paths

The current colocation table lists “2” under power supplies for its 1U, 2U and 3U plans. The dedicated-server pages similarly advertise dual hot-swap 750 W power supplies. That is good component-level design: a server can continue after one power-supply module fails if the other module and its input remain healthy. But resilience depends on where the two cords lead.

If both server supplies connect to the same rack PDU, the PDU remains a single failure point. If two PDUs connect to the same UPS output or switchboard, the upstream electrical path remains shared. If separate UPS systems depend on one transfer switch or one generator, a failure there can remove both apparent feeds. Even physically separate utility connections may share a substation, cable route or protection scheme outside the building.

This is why the Uptime Institute's explanation of Tier topology distinguishes redundant components from concurrent maintainability and fault tolerance. A second component is not the same as a second delivery path. The article does not assign LiveHosting any Tier level; the company page reviewed here does not claim one, and the 2012 guide explicitly did not provide a Uptime classification. The framework is useful only to clarify what evidence would support stronger language.

For each rack sold as dual-fed, LiveHosting should be able to show the A and B path from utility or generator through switchgear, UPS, distribution and PDU. It should state which devices remain single-corded and whether transfer switches are used. It should publish the maximum rack draw, breaker rating, allowable steady load and metering method. The colocation page says electricity consumption is included, but it does not quantify a power allowance. That omission makes it difficult to translate 1U, 2U or 3U space into a safe and commercially enforceable power commitment.

The most important test is not a diagram alone. It is a controlled transfer at realistic load while customer equipment remains online, followed by evidence that batteries, generator, cooling and network gear behaved as intended.

Generator presence is not the same as generator endurance

The current sales page lists a generator, and the 2012 guide reported a 100 kW diesel unit. A generator can bridge a long utility interruption, but only when the whole support system works: automatic detection, starting batteries, transfer equipment, fuel, cooling, exhaust, maintenance, load acceptance and refuelling access. The word “generator” does not disclose any of those conditions.

Runtime is the first missing number. A tank may support hours at partial load but much less at design load. Fuel consumption changes with electrical demand, and the facility's demand includes more than servers. Cooling must continue during a grid loss; otherwise the generator can keep IT equipment energized while room temperature rises toward a forced shutdown. A public runtime should therefore state the supported critical load, minimum on-site fuel, refuelling contract and assumptions about cooling.

The Uptime Institute's fuel-system guidance describes a twelve-hour minimum storage expectation for Tier topologies at the facility's stated N load. That is a reference point, not evidence that LiveHosting meets it or needs to adopt that exact design. A smaller provider can choose a different risk target. What matters is that customers know the target and can compare it with their recovery needs.

Testing matters just as much as tank size. A no-load monthly start does not prove that the generator and transfer system will carry the room through a hot day. A meaningful record would include loaded transfer tests, duration, load percentage, fuel quality, alarms, unsuccessful starts and corrective actions. It would also show whether both current carrier paths and external monitoring remain available when utility power is removed.

The customer consequence is direct. A short interruption may be absorbed by UPS batteries. A longer outage becomes a generator and fuel event. If the generator fails or cannot support cooling, all products in the room can converge on the same shutdown deadline, regardless of how many virtual machines, RAID sets or server power supplies exist above it.

Cooling determines how much electrical capacity is usable

The public material reviewed here does not give a current cooling design, installed cooling capacity, redundancy level, containment layout or environmental operating range. That absence prevents a reader from converting historical electrical ratings into usable IT capacity. Nearly every watt consumed by IT equipment becomes heat that must be removed, and the room can be constrained by cooling before it reaches a nameplate electrical limit.

The 30-square-metre figure reported in 2012 also says nothing about present rack density. A small room with lightly loaded racks can be stable. The same room filled with dual-processor servers, dense storage or high-speed switching can develop hot spots even when total building power remains within a nominal limit. The dedicated-server catalogue includes systems with multiple drives and dual processors, while customer colocation equipment is less predictable. Capacity allocation must account for both average heat and local concentration.

Cooling redundancy has several layers: the cooling unit, compressor or chilled-water source, pumps and fans, control system, power supply and heat-rejection path. “N+1 cooling” can still hide common pipework, control or electrical dependencies. Maintenance can be more revealing than failure. If a cooling unit cannot be isolated and serviced on a hot day without reducing the room below its committed load, installed capacity exceeds concurrently usable capacity.

A buyer should ask for temperature and humidity ranges at server inlets, sensor placement, alarm thresholds, trend records, hot-day headroom and the result of a cooling-unit-loss test. The response should explain automatic shutdown policy and customer notice if temperature rises. It should also state whether generator capacity includes all cooling needed for the committed IT load.

The fire and water implications follow. Condensate, roof or plumbing leaks can affect a compact room quickly. Fire detection and suppression must be compatible with occupied spaces and live electrical equipment. Public material mentions historic physical security and monitoring, but does not provide current fire-compartment, leak-detection, suppression or flood-zone evidence. Customers should not infer those controls from the data-centre label alone.

Installed, sellable and recoverable capacity are different numbers

The provider can truthfully have equipment installed while having less capacity available for new customers and still less capacity available during a fault. Installed capacity is the sum of nameplates and configured resources. Sellable capacity is what commercial and engineering rules permit after reservations and oversubscription. Recoverable capacity is what remains, or can be restored in time, after a defined component fails.

LiveHosting's public pages advertise server CPU, memory, SSD or NVMe storage and “unlimited” traffic. Those specifications describe an entitlement or product configuration. They do not show host occupancy, storage replication, uplink contention or backup throughput. “Unlimited” traffic is especially easy to misread: it may mean no volume-based billing while every packet still shares a finite port, edge and transit commit.

Colocation space is similarly incomplete without power and network headroom. Three 1U customers may draw less power than one 3U customer, or much more, depending on hardware. A 1 Gbps port is an interface rate, not a guaranteed internet throughput under attack or after one carrier fails. A generator nameplate is not a customer capacity commitment. A UPS rating is not a runtime guarantee.

The operational metric that matters is the failure-state budget. How many kilowatts remain if one power path is isolated? What room temperature can be maintained after one cooling unit is lost? What internet capacity remains if Prime Telecom or Vodafone becomes unavailable? How many virtual servers can be restarted from backup at the same time? How many engineers can handle simultaneous hardware, network and customer incidents?

These numbers should be tied to customer classes. Shared hosting may tolerate a different recovery time from a public-sector website, transactional application, mail server or colocated enterprise system. A small facility does not need hyperscale capacity to be useful. It needs commitments that fit its actual redundancy and a clear refusal to sell beyond the failure-state envelope.

AS41635 is live and globally visible

The network evidence is the strongest part of the public record. RIPE RDAP lists AS41635 as active and names LIVEHOSTING-AS. The RIPEstat AS overview identifies the holder as LIVEHOSTING DATACENTER SRL and marks the ASN announced. This matches the company's own contact page.

On 12 July 2026, RIPEstat routing status showed one originated IPv4 prefix containing 1,024 addresses and no originated IPv6 prefix. The IPv4 route was visible to all 326 reporting IPv4 peers in that snapshot. RIPEstat's announced-prefix view identified 89.38.208.0/22 as the current announcement. The routing-history view traces LiveHosting-originated address space back to 2006, although the aggregate changed from a /21 to the current /22 over time.

This is meaningful operating evidence. A broadly visible route maintained over years is inconsistent with a merely decorative ASN registration. The prefix hosts the company's own website and public server names, and independent aggregators also identify it. Hurricane Electric's BGP Toolkit reported one IPv4 prefix, 1,024 originated IPv4 addresses, two observed IPv4 peers and no IPv6 origin. IPinfo classifies the ASN as hosting and shows a June 2026 path reaching the block through AS39737.

The route is also RPKI-valid. RIPEstat validation found a valid authorization for AS41635 to originate 89.38.208.0/22 with maximum length /22. As RIPE NCC explains, origin validation answers whether the legitimate resource holder has authorized a particular prefix-origin combination. It does not validate the rest of the AS path or prove physical resilience.

The conclusion should be narrow: LiveHosting has a current, valid and highly visible IPv4 origin. That is stronger than a marketing map. It still cannot show whether the routers are duplicated, whether the carriers enter through separate ducts, or whether the surviving path can carry customer demand after a failure.

The two visible carrier paths still need physical proof

RIPEstat's ASN-neighbours view observed two adjacent networks on 12 July 2026: AS12302, Vodafone Romania, and AS39737, Prime Telecom. The BGP-state snapshot showed the vast majority of sampled paths through Prime Telecom and a smaller number through Vodafone. Hurricane Electric independently listed the same two peers.

Two observed adjacencies are better than one because they provide potential route alternatives. They should not be called two proven independent carriers without contract and site evidence. A route collector observes AS paths, not fibre ownership, building entrances, cross-connects or paid capacity. One carrier may resell another. Two circuits may share a metro duct, a manhole, a street crossing, a patch panel or the same external powered equipment.

The RIPE registry entity adds another reason for caution. Its import policy, last modified in 2021, names AS6830 and AS34279, while current collectors see AS12302 and AS39737. That difference may simply reflect stale registry policy after ordinary carrier changes. It demonstrates why a registry declaration should not replace current observation or a current carrier schedule.

Capacity after failure is the next issue. If the primary path carries most traffic, the secondary must have enough committed and burst capacity to absorb it. BGP may reconverge successfully while applications become unusable because the remaining circuit is congested. DDoS protection adds another dependency: the provider should explain where filtering occurs, whether both upstreams support it, how routes are diverted, and whether a protection event reduces clean capacity.

The required evidence is practical. LiveHosting should identify the two contracted providers, port and commit sizes, physical demarcations, entrance paths, edge routers and power domains. It should show a recent test in which each upstream was withdrawn separately at busy load, record convergence and packet loss, and confirm that monitoring and customer communications remained reachable.

No PeeringDB profile narrows what can be checked publicly

A query to the PeeringDB API returned no network entity for AS41635 during this review. That is not evidence of a network fault. PeeringDB participation is voluntary, and a small hosting network can buy transit without maintaining a public interconnection profile. The absence does reduce public visibility into facilities, exchanges, traffic levels, peering policy and network contacts.

The current shape looks transit-led rather than exchange-led. Public collectors expose two adjacent networks, but no public PeeringDB record identifies an internet exchange or facility attachment. Customers should therefore avoid assuming that the network has direct peering, diverse exchange routes or a carrier-neutral meet-me room. Those features may exist; the public record reviewed here does not establish them.

This matters for fault isolation. If all external paths depend on a small set of transit handoffs in one building, the local carrier meet can be a common point of failure even when the global route table shows two upstream ASNs. If one circuit terminates off-site and reaches the data room over a shared local tail, the logical diversity can disappear at the last kilometre.

The provider can resolve much of this uncertainty without exposing sensitive detail. It can publish a facility-neutral network diagram showing separate entrances, separate edge devices, carrier identities, port capacities and failover policy. It can maintain a current PeeringDB profile if appropriate. It can offer a looking glass or externally hosted status service. None of these proves every duct, but together they make the network's operating model easier to verify.

The missing IPv6 origin deserves a direct answer

LiveHosting's colocation page says a /56 IPv6 subnet is included with each package. Yet RIPEstat and Hurricane Electric showed zero IPv6 prefixes originated by AS41635 in the July 2026 snapshots. France's telecom regulator ARCEP also listed AS41635 with zero IPv6 exposure in its 2025 hosting-provider measurements. These observations do not prove that customers receive no IPv6 service.

The advertised /56 may come from an upstream provider's address space and be routed to LiveHosting without AS41635 originating an IPv6 prefix. It may be available only on request. It may be configured inside the facility while not visible in the sampled public data. Each explanation has a different resilience consequence.

Provider-assigned IPv6 can work well, but failover may depend on the assigning upstream. If the /56 belongs to one carrier and that carrier fails, LiveHosting may not be able to announce the same customer subnet through the other path. Renumbering a server estate during an incident is not equivalent to BGP failover. DNS, firewall rules, access lists and customer software can all retain the old addresses.

The buyer should ask which aggregate contains the /56, which ASN originates it, whether it is reachable through both visible upstreams, and whether route-origin authorization covers the intended origin. It should also ask whether the 1 Gbps port and DDoS protection apply equally to IPv4 and IPv6. A dual-stack service is only as resilient as the less-tested stack when applications and DNS publish both.

The gap is important because IPv6 is not a decorative feature. The colocation page presents it as included capacity. Public route evidence makes the IPv4 operating surface clear; equivalent IPv6 evidence would turn the /56 from a sales line into a verifiable network service.

The quality pledge is narrower than a facility guarantee

LiveHosting's quality commitment applies to Standard, Business and Reseller Windows or Linux web-hosting packages. It defines uptime as the monthly proportion during which a customer's website is available over HTTP from a neutral location. The page says LiveHosting uses PRTG systems inside its data centre and in other Romanian and foreign data centres to measure availability.

The credit schedule returns 50% when uptime falls between 98% and 99.5%, 75% between 95% and 97.9%, and 100% at 94.9% or below. A service credit is commercially useful, but it is not compensation for lost sales, data or reputation. More importantly, the stated scope does not automatically cover virtual servers, dedicated servers or colocation. Buyers in those categories need their own service terms.

The exclusions are broad. The page excludes, among other things, communication interruption, fire, flood, natural disasters, viruses, attackers, third-party software, announced or critical maintenance, server upgrades, DNS outside LiveHosting's control and several access protocols. Some exclusions describe exactly the failure paths a data-centre customer most needs to understand. Excluding them from credits does not make them unlikely; it moves their economic cost toward the customer.

The measurement definition also focuses on HTTP reachability. A website may answer while email, database connections, storage, control panels, VPN access or one carrier path is degraded. Conversely, an application fault can make HTTP fail while facility power and network remain healthy. Customers need component-level measures and an incident record that separates facility, network, compute, storage and application causes.

A stronger assurance package would publish historical service performance by product, maintenance minutes, incident causes and recovery times. It would state which monitoring locations are independent of AS41635 and whether the status channel remains reachable during a total facility or route outage.

Response time is not restoration time

The quality page promises a maximum technical-support response time of 24 hours during Monday-Friday hours of 10:00-18:00. The current contact page lists technical support Monday-Friday from 10:00-17:00. Those pages may describe different channels or may simply be out of alignment. Either way, neither statement is a promise to restore service within 24 hours.

The server-management page adds a more granular commercial distinction. Basic management includes two hours per month and weekday availability. Premium includes four hours per month and states Monday-Sunday, 24-hour availability. The public service contract says management work is limited to the hours in the purchased subscription, additional work is chargeable, and application availability or performance is not guaranteed by management service.

This leaves several questions for unmanaged dedicated and colocation customers. Is facility emergency response continuous even when server management is not? Who acknowledges a power, cooling or network alarm at 03:00? Is remote hands available at all times, and what is the arrival target? The colocation page prices remote hands at EUR25 per hour but does not publish a round-the-clock response commitment.

The distinction is critical in a small operation. Detection can be automatic, but diagnosis and authorization may depend on a person. A carrier may require the customer's nominated contact. A building may restrict after-hours access. A failed server may have dual power but still need a local disk or cable replacement. Each handoff adds time before restoration begins.

Customers should ask for four separate clocks: alarm-to-acknowledgement, acknowledgement-to-qualified diagnosis, diagnosis-to-site intervention and intervention-to-restoration. They should ask who owns each clock and what happens when two incidents occur simultaneously. A telephone number and a ticket promise are useful entry points; they are not a recovery plan.

Maintenance can expose more risk than a sudden failure

Redundancy often looks strongest when everything is healthy and weakest when one component is deliberately removed for service. UPS batteries need replacement, generators need loaded tests, cooling equipment needs cleaning, switches need upgrades, and carriers need maintenance windows. During those periods, the remaining path may carry the full load with no spare.

The quality commitment excludes announced maintenance, critical work and server upgrades from its credits. That is common in hosting contracts, but the practical risk depends on how maintenance is designed. A customer needs to know whether the facility can maintain each critical component without shutting down IT load, whether multiple suppliers may work at once, and how rollback is handled.

For power, maintenance evidence should include bypass paths and procedures that do not place the whole room on raw utility. For cooling, it should state the maximum safe load with one unit isolated. For network work, it should show that customer routes remain stable through the other router and carrier. For storage or virtualization, it should quantify how much workload can move before maintenance and how long that movement takes.

Change concentration is another concern. A small provider may sensibly schedule several tasks in one window to reduce disruption, but coupling power, network and host changes removes independent recovery options. Customers should ask whether change approvals consider common dependencies and whether an externally reachable communication channel is kept outside the affected systems.

The evidence that would settle the matter is ordinary operating material: a redacted annual maintenance calendar, notices from recent windows, post-maintenance reports, failed-test actions and customer-visible impact. This is more persuasive than a general uptime target because it shows how the operator manages the periods when redundancy is intentionally reduced.

Fire, flood and utility loss converge on customer data

The quality commitment explicitly mentions fire and flood among force-majeure exclusions. That is a contractual allocation, not evidence that the facility is exposed or unprotected. The public pages reviewed here do not state the current fire detection and suppression system, compartment rating, leak detection, flood assessment or distance from water and fuel hazards.

These questions matter more when many service layers occupy one site. Shared hosting, VPS, dedicated servers, colocation, DNS, email and customer portals can all depend on the same room. If primary data, backups and control systems share the facility, a building event can remove the production service and the means to restore it.

The public service contract places significant responsibility on customers and limits warranties. It also permits service suspension or deletion for non-payment and reserves broad rights to modify or interrupt services. Those terms make independent backups and tested export procedures commercially important even in the absence of a physical incident.

A customer should identify where each copy lives, who controls its credentials, how often it is tested and how restoration works if LiveHosting's own account portal or network is unavailable. A backup on another server in the same room protects against some hardware failures but not against room-wide power, cooling, fire or flood events. A copy in another building but administered through the same inaccessible identity system may also be hard to use.

For colocation customers, the question extends to equipment recovery. Who may enter after an incident? Is customer hardware insured by the provider, the building operator or the customer? Can a customer retrieve equipment during a prolonged utility or access closure? The answers may be in individual contracts, but they are not established by the public plan page.

Failure affects different customers in different ways

Shared-hosting customers are likely to feel a common platform failure first as inaccessible websites, email or control panels. They may have little visibility into which physical server, switch or storage system failed. Resellers can amplify the impact because one account may represent many downstream sites and support obligations.

Virtual-server customers have more control over operating systems but remain dependent on hypervisor capacity, storage and the provider's local network. A host failure may be recoverable if workloads can restart elsewhere, but the public product page does not promise live migration, replicated storage or a recovery cluster. The presence of SSD or NVMe says nothing about the number and location of copies.

Dedicated-server customers avoid some shared-compute risks. They still depend on the rack, both power paths, switching, carrier transit and remote hands. Dual power supplies and RAID can absorb selected component failures, but they cannot survive a room-wide outage or a shared network edge failure. The public dedicated-server listings also show older G7 and G8 generations; that can be an economical offering, but buyers should ask about spare-system and component availability.

Colocation customers own their equipment and may announce their own address space, as the product page allows BGP announcements. Their dependence on LiveHosting is nevertheless physical. They need access, power, cooling, cross-connects, routing and repair assistance. A facility outage can stop equipment that is otherwise fully customer-managed.

Public-sector, healthcare, financial or industrial users may also face obligations beyond uptime. Location, incident notification, evidence retention and supplier continuity can matter. The article does not identify any such LiveHosting customer. It highlights why the same facility claim can have very different consequences depending on the workload placed there.

The provider should therefore resist one universal resilience statement. It should disclose which protections apply to each service, what the customer must provide, and which shared dependencies cross all product lines.

A meaningful failover demonstration has to remove real dependencies

The best way to establish current resilience is to test defined failures rather than accumulate labels. For LiveHosting, five exercises would answer most of the open questions.

First, remove normal utility power at a representative production load. Record UPS transfer, generator start, cooling continuity, fuel consumption, alarms and customer impact. Continue long enough to demonstrate the published runtime target, then restore utility without dropping load.

Second, isolate each power distribution path and UPS section in turn. Confirm that dual-corded customer devices remain online and identify single-corded equipment that requires a transfer device. A successful generator test does not replace this internal distribution test.

Third, remove one cooling unit or cooling path during a demanding ambient period. Track server-inlet temperatures and confirm how much load remains within the facility's stated environmental limit. This converts a cooling redundancy claim into usable-capacity evidence.

Fourth, withdraw Vodafone and Prime Telecom separately while the network is busy. Measure BGP convergence, packet loss, latency and surviving throughput over both IPv4 and the advertised IPv6 service. Confirm that DDoS protection, monitoring, DNS and customer communication work on the remaining path.

Fifth, restore a representative shared-hosting account, virtual server and control service from a copy outside the primary failure domain. Measure recovery time and data loss, and include the case where the normal customer portal is unavailable.

The results need not be perfect to be valuable. A disclosed weakness followed by a corrective action is stronger evidence than an untested claim of complete availability. Customers can then judge whether the demonstrated recovery matches their own tolerance and whether they need an independent second site.

Power growth and permitting should be treated as constraints, not assumptions

The European data-centre market increasingly treats power availability as a development constraint. The European Commission's energy-performance page describes rising electricity demand, cooling and water impacts, and reporting obligations for facilities above the relevant threshold. Nothing in the public evidence reviewed here establishes that LiveHosting crosses the 500 kW reporting threshold; the historical figures suggest a much smaller installation.

Small scale does not remove the need to manage power. It changes the problem. A compact site may have lower total demand but less room to add switchgear, cooling, batteries, exhaust or fuel storage. An urban or near-urban building may face noise, emissions, fire-safety and construction constraints. A utility connection may be sufficient for current load while making expansion slow or expensive.

The current site does not publish a planned expansion, new building or power application. Buyers should not infer one. If LiveHosting markets new high-density capacity, the evidence should identify whether it comes from improved efficiency, decommissioned older equipment, a larger utility allocation, new cooling, or another site. The word “available” should mean power, cooling and network are all commissioned, not merely that rack space is empty.

Permitting also affects recovery. Replacing a generator, adding fuel storage, changing electrical service or modifying fire systems may require approvals and supplier lead time. The customer does not need every permit number in public. It does need assurance that installed equipment is authorized, maintained and supported, and that planned growth will not put the existing room into a prolonged reduced-redundancy state.

The right commercial metric is capacity ready for a defined failure, not theoretical room for another server.

What would raise confidence

LiveHosting can move the evidence grade upward with a compact disclosure pack. It should begin with a current facility factsheet dated and versioned by the operator. The factsheet should state the service address at an appropriate level, operator and landlord boundaries, data-room area, commissioned IT load, current measured peak, rack power limits, cooling topology and fire controls.

The power section should show utility inputs, UPS topology, generator rating, minimum runtime at committed critical load, fuel arrangements and the date and result of the last loaded transfer test. It should distinguish total installed ratings from usable N, maintenance-state and fault-state capacity.

The network section should reconcile the current Vodafone and Prime Telecom observations with the older RIPE policy entity. It should disclose contracted port and commit capacity, edge-router diversity, physical entrance separation, DDoS arrangements and the origin of the advertised IPv6 /56. A current PeeringDB entry or looking glass would improve external visibility but would not replace physical documentation.

The operations section should state continuous alarm ownership, facility response targets, remote-hands coverage, spare holdings and supplier escalation. It should reconcile the 10:00-17:00 and 10:00-18:00 support statements and clarify what Premium 24/7 availability means for response and restoration.

Finally, the operator should publish anonymized test and incident evidence: utility transfer, cooling-unit loss, carrier failover, restore exercises, significant maintenance and lessons applied. Independent certification can strengthen the package where scope and current validity are clear. Certification names from 2012 should not be treated as current without certificates, sites, standards and expiry dates.

This level of disclosure would not expose customer data or sensitive floor plans. It would let buyers distinguish a functioning small data centre with tested limits from one whose resilience is inferred mainly from product labels.

The evidence grade is Medium

LIVEHOSTING DATACENTER SRL earns a Medium network and infrastructure evidence grade. The company-specific operating evidence is substantial: a current Romanian sales site, named legal entity, explicit Timisoara colocation offer, AS41635, a globally visible IPv4 route, two observed adjacent networks, a valid route-origin authorization and years of routing history. This is not a case where the provider's existence or basic network operation rests on a single directory listing.

The grade stops at Medium because the resilience claims are not matched by current physical proof. UPS and generator are listed, but topology and runtime are absent. Two server power supplies are listed, but A/B separation is not. A 2012 guide offers detailed ratings, but no current commissioning or load evidence connects those figures to the 2026 plant. Cooling, fire, flood, fibre entrances, carrier commits, maintenance performance, external recovery and customer failover results remain undisclosed in the sources reviewed.

The two current BGP adjacencies support logical path diversity, while the lack of physical route evidence prevents a stronger conclusion. The valid IPv4 route reduces origin risk, while the absence of an AS41635 IPv6 origin leaves the advertised /56 arrangement unresolved. The quality pledge gives customers a measurement and credit mechanism, while its product scope and exclusions limit what it says about facility-wide recovery.

This grade is not a verdict on service quality. It is a statement about the distance between what can be observed and what must still be demonstrated. LiveHosting may possess stronger current engineering records than it publishes. A buyer should ask to see them before placing a workload whose outage cost exceeds the value of service credits.

The narrow conclusion is that marketed capacity is credible as a live service, but not yet proven as failure-state capacity. The next useful evidence is not another server configuration. It is a current power, cooling and carrier test showing what stays online when one of the common dependencies is deliberately removed.