Inside SuperHosting.BG’s Sofia Hosting Chain: Equinix, Telepoint, Two Upstreams and the Restore Clock

Summary

• SuperHosting.BG publicly places its hosting infrastructure in Sofia and names Equinix and Telepoint as data-centre providers, but it does not disclose how customer workloads, backup copies or spare hardware are divided between those sites.
• AS201200 is visibly active with a substantial IPv4 footprint and two named upstreams, Neterra and Evolink; that is useful route diversity, but public BGP observations cannot prove physically separate fibres, entrances, routers or failure domains.
• Recovery depends on the purchased service, the age and location of a usable backup, available hardware and a human escalation path, so a customer should test restoration and migration before treating an uptime figure as a continuity plan.

The outage customers see begins below the dashboard

At 09:17 on a working morning, a small Bulgarian retailer discovers that its website is gone. The owner can still reach a phone, perhaps the client area, but the storefront itself times out. Orders stop, payment callbacks cannot reach the application, staff cannot read webmail, and an advertising campaign keeps delivering visitors to an error. To the customer, the incident appears to be one thing: “the hosting is down.” To the operator, it may be any of several very different events whose remedies and clocks have little in common.

The visible service sits at the top of a physical and organisational chain. A domain has to resolve. Packets have to cross an access network, reach one of SuperHosting.BG’s upstreams, enter AS201200 and land on the correct edge and server. The server needs live power, cooling, storage and a functioning operating environment. Shared-hosting software must know where the account resides. If a disk, host or account has failed, an intact backup must be available, recent enough to be useful and readable by a working restore system.

Finally, someone must recognise the incident, decide which layer is responsible and obtain access to the equipment or control plane needed to fix it.

SuperHosting.BG’s own help material makes the difference between the storefront and its machinery unusually clear. Its explanation of the client profile and hosting account says that the profile is used to order, renew and manage services, while files, databases and mailboxes are handled in the hosting account and, for shared hosting, through cPanel. Another article says that customers can discover the particular host assigned to them because the company uses different physical and virtual servers with different names. A green account status, therefore, is not proof that the assigned server, storage path or route is healthy.

That distinction is central to evaluating the company. SuperHosting.BG markets an accessible retail service, not bare floor space and power. Customers reasonably judge it through the panel, support response and whether their site loads. Yet the decisive assets are hidden from ordinary view: the cabinet holding the machine, the power path feeding it, the cooling plant removing its heat, the switches and fibres carrying traffic, the storage system holding live data, the backup servers holding older copies, the spare drive in inventory and the engineer authorised to replace it.

The user interface can report an outage; it cannot generate any of those resources.

The company’s public pages support the basic outline of a live Bulgarian hosting operation. Its company history and current profile say that it has operated for more than 20 years, supports more than 200,000 websites and employs more than 100 people. Those are company claims rather than audited infrastructure counts, but they indicate the potential blast radius of a platform problem. At that scale, an error in a shared layer can affect far more than one account even when most of the estate remains healthy.

The right opening question in an incident is consequently not just “Is SuperHosting.BG up?” It is “Which dependency is down for this customer?” A failed application, an account-level resource limit, a shared server failure, a storage event, an edge-routing problem and a complete facility loss can look similar from outside. They require different evidence, different people and different recovery actions. The hosting dashboard is a useful doorway into the service, but it is not the service’s foundation.

What SuperHosting.BG is—and what it does not own

The legal supplier is identifiable. The current Managed VPS terms name SuperHosting.BG Ltd., give Bulgarian company identifier 131449987 and describe the provider as delivering and maintaining the managed virtual-server service. The company’s general terms hub separates shared hosting, managed WordPress, Managed VPS, standard VPS, dedicated servers, domains and other products into distinct contractual categories. This matters because “hosting” is not a single allocation of responsibility. The customer may administer an unmanaged virtual machine, share a platform administered by the provider, or buy a managed server in which SuperHosting.BG undertakes administration, monitoring and backup maintenance.

Corporate ownership adds another layer without erasing the local supplier. In July 2020, team.blue announced that SuperHosting had joined the group. The announcement described a Sofia headquarters, an expansion into Serbia, an earlier acquisition of Host.bg and continuing leadership by the founders. SuperHosting.BG’s own present-day company page likewise identifies it as part of team.blue. Group membership may provide purchasing scale, software expertise or financial backing, but it does not by itself tell a Bulgarian customer which entity owns a particular server, signs a colocation contract, holds a spare part or commands an incident at 03:00.

The physical facilities form a separate boundary. SuperHosting.BG’s current technical and organisational measures say that the company uses data centres operated by Equinix (Bulgaria) Data Centers EAD and Telepoint Ltd. That is evidence of colocation or hosted infrastructure, not evidence that SuperHosting.BG owns either building. Facility operators are responsible for layers such as site access, base power, generators, cooling and the physical environment under their contracts. SuperHosting.BG remains responsible for the equipment and service layers it controls, and its carrier relationships add still other companies to the chain.

The retail offer therefore depends on at least four kinds of actor. SuperHosting.BG is the customer-facing hosting provider and network resource holder associated with AS201200. team.blue is the parent group. Equinix and Telepoint are named facility providers. Neterra and Evolink are named connectivity providers. Hardware makers, control-panel vendors, security services and domain registries sit beyond those visible layers, but public material does not provide a complete dependency inventory. A customer cannot safely assume that group ownership or two facility names means every product is duplicated across every layer.

Responsibility also shifts with the service chosen. SuperHosting.BG’s description of Managed VPS includes cPanel, 24-hour technical support, continuous monitoring, a regular content backup and administration by the company. A standard VPS, by contrast, gives the customer root control and much more operational responsibility. Dedicated service moves the customer onto an individually allocated machine but still depends on SuperHosting.BG’s rack, network and support arrangements. Shared hosting places many accounts behind common platform components and provider administration.

This boundary is not merely legal fine print. It determines who can act. A customer with root access may repair a broken package but cannot replace a failed drive or restore facility power. A managed customer may reasonably expect the provider to investigate the operating environment, yet still needs to maintain application knowledge and an independent copy of critical data. A facility technician can check a breaker or execute remote-hands work but may not be authorised to change a hosting cluster. An upstream can repair a circuit but cannot recover a database. Each handoff can lengthen the outage if ownership and escalation are unclear.

SuperHosting.BG advertises round-the-clock technical support and Sofia contact details. That is an important operating asset, particularly for local small businesses that cannot staff their own systems. But availability of a published contact points is not the same as a published severity matrix, a guaranteed response for every plan or a disclosed restoration target. The company’s strongest continuity claim would not be that one organisation owns everything. It would be that the boundaries are known, tested and crossed quickly when an incident spans supplier, facility, carrier and customer.

The two Sofia facilities named in the public record

The clearest physical-location document is SuperHosting.BG’s technical and organisational measures. It names two data centres: Equinix at 10 “5030” Street in Sofia’s Druzhba 1 district and Telepoint at 122 Ovtche Pole Street in Sofia. It also says those sites are ISO 27001 certified and have physical guards and controlled access. This is more specific than a generic claim that data is kept “in Europe” or “in Bulgaria.” It places at least part of the provider’s infrastructure relationship in two identifiable Sofia facilities.

Product pages reinforce one side of that picture. The company’s WordPress hosting page, VPS page and dedicated-server page all describe infrastructure located at Equinix in Sofia. The pages refer to redundant power and cooling and at least two independent internet providers; the dedicated-server page names Neterra and Evolink. These are current commercial representations about the service environment. They do not say that every plan, every server generation or every backup copy is in the same room, nor do they explain the role of the Telepoint site named in the security document.

Equinix’s own SO1 facility page matches the Druzhba 1 address. Equinix describes 1,103 square metres of colocation space, 2N UPS redundancy, N+1 generators, N+1 cooling and generator autonomy of less than 30 hours at full load. It also lists physical security and a range of certifications and interconnection services. Those specifications describe the facility as a whole. They do not disclose SuperHosting.BG’s cabinet count, contracted power, cross-connects, fuel priority or position within the building.

Telepoint’s contact page matches the Ovtche Pole address to “Sofia Center.” Its main site describes three carrier-neutral facilities, remote-hands service, multiple local and international carriers and a broader Bulgarian footprint that also includes Sofia East and Montana. Its infrastructure claims refer to combined space and power across its estate. A Telepoint facility presentation describes N+1 UPS feeds, redundant cooling, generator groups, monitoring and a large carrier population. Again, these are facility capabilities, not proof that SuperHosting.BG consumes all of them or places production and backup systems in distinct buildings.

The two named addresses create a plausible basis for site diversity, but public disclosure stops short of proving it. The documents do not map product families to sites. They do not say whether shared hosting runs in both, whether one is used mainly for backups, whether a customer’s backup is stored outside the live server’s building, or whether the two sites have independent operational teams and carrier entrances. They do not describe replication mode, failover orchestration or the recovery point expected after a site-level event.

It is therefore accurate to say that SuperHosting.BG uses two named Sofia data-centre providers. It is not accurate to say, without customer-specific confirmation, that a given site is active-active across Equinix and Telepoint. Even if two copies exist, synchronously mirrored storage can reproduce corruption; asynchronously replicated data can lose the latest writes; and a cold copy may require new hardware and manual recovery. Geography is only the first condition of resilience.

The location evidence also has a time dimension. Commercial pages can change as platforms move, while security documents may cover a wider set of services than the particular product a customer buys. A useful service description would identify the live site, backup site, replication relationship and migration path for each product class. In the absence of that detail, the two Sofia addresses should be treated as verified facility relationships but not as a complete map of workload placement.

Power, cooling and the limits of facility redundancy

Every hosting promise eventually becomes an electrical load. The server needs an energised rack, the storage array needs stable power, and the switching fabric must remain live long enough for traffic to reach the machine. Cooling is not optional capacity around that load; it is part of the load’s operating envelope. A rack can have power and still become unusable if heat cannot be removed. Likewise, a building can have generators while a particular distribution unit, bus, breaker or cabinet feed remains a single point of failure.

SuperHosting.BG’s product pages use an N+1 formulation for power and air conditioning. Equinix publishes more detailed facility-level specifications for SO1: 2N UPS, N+1 generators and N+1 cooling. Telepoint’s infrastructure page describes three 10 kV feeds from different substations on non-intersecting routes, multiple transformer and UPS groups, six diesel generators and N+1 cooling for each colocation hall. These are meaningful engineering features because they provide spare components or alternate paths within the facility design.

They are not an absolute guarantee. “N+1” says that one additional unit exists beyond the number required for the design load; it does not show the maintenance state of each unit, the configuration of downstream distribution or whether a common controller can fail. “2N” indicates two complete capacity paths at the stated layer; it does not prove that a customer server has dual power supplies connected to separate feeds, that both feeds are commissioned correctly, or that all network devices follow the same pattern.

Generator autonomy is an estimate under stated conditions and still depends on start reliability, fuel, replenishment and human response.

The customer-facing question is narrower than whether a data centre is well designed. It is whether the entire service path preserves the facility’s resilience. A single-corded server connected to one cabinet feed cannot take full advantage of two upstream power systems. A storage shelf with a failed controller can strand many otherwise healthy machines. A top-of-rack switch can concentrate reachability. A cluster control service can fail even while every physical host is powered. Redundancy must carry through the rack, server, storage and network layers, not stop at the building specification.

The public record does not disclose those lower-level arrangements. SuperHosting.BG does not publish per-platform rack diagrams, power-feed assignments, storage topology, spare-part quantities or tested component-failure scenarios. That omission is understandable from a security and commercial perspective, but it limits what customers can infer from the facility badges. The correct conclusion is that the named facilities advertise serious resilience features, while SuperHosting.BG’s actual use of those features remains largely private.

Maintenance is another source of risk. Redundant systems often become temporarily non-redundant while a UPS, generator, chiller or switch is serviced. Capacity can also be technically installed but unavailable because it is reserved for failover, awaiting commissioning, constrained by cooling or missing a compatible part. A hardware shortage does not need to empty the entire storeroom to matter; it only needs to affect the exact drive, controller, power supply or server generation required by the failed system.

Cross-site recovery would reduce some building-level risks, but only if it is engineered as an operating service. The two Sofia facilities are separated addresses, yet public documents do not establish diverse utility regions, fibre routes, storage replication or an agreed recovery order. They also do not identify whether customer DNS, authentication, support and monitoring can continue if the primary hosting environment fails. A second site that depends on the same control service or manual credentials may not be immediately usable.

Facility redundancy is therefore best understood as a set of preconditions. Equinix and Telepoint can keep the room within its power, cooling and security envelope. SuperHosting.BG must turn that envelope into resilient racks and platforms. The customer must choose a service whose recovery properties match the business. None of the three layers can substitute for the others.

AS201200: two upstreams, many prefixes, one visible edge

The internet-facing evidence is stronger than the capacity evidence. RIPEstat’s announced-prefixes response showed 21 IPv4 prefixes originated by AS201200 across the observation window ending 18 July 2026. bgp.tools also identified the autonomous system as active, listed 21 originated IPv4 prefixes and showed two upstream relationships: AS34224 Neterra and AS8262 Evolink. This aligns with SuperHosting.BG’s dedicated-server page, which names the same two connectivity providers.

Independent views broadly corroborate the network’s existence while illustrating why no single counter should be treated as immutable. IPinfo’s AS201200 page classified it as a Bulgarian hosting network, counted 9,472 IPv4 addresses and no IPv6 addresses, and listed Neterra and Evolink as the two upstreams. Cloudflare Radar also identified AS201200 as SuperHosting.BG in Bulgaria and displayed observed traffic. GIBIRNet’s BGP view reported the same two peers but a slightly different network count at its update time. Timing, aggregation and collection methods can explain modest differences; the stable finding is an active IPv4 hosting edge with two visible external relationships.

Two upstreams are better than one because the autonomous system can, in principle, announce its prefixes through either provider. If one carrier loses reachability, BGP can withdraw or de-preference the affected path and the internet can converge on the other. That reduces dependence on a single carrier’s external network and provides a basis for maintenance or failure tolerance.

But BGP shows logical reachability, not the physical route. A public route table does not reveal whether both circuits enter the same building duct, share a metro fibre, terminate on the same border router, depend on a common optical platform or cross a common upstream facility. The labels “peer” and “upstream” also describe observed or registered relationships, not a contractual service-level commitment. The fact that both providers are visible does not prove that every SuperHosting.BG prefix is accepted identically in every failure condition.

Nor does route diversity solve a server or facility outage. BGP can carry traffic perfectly to a powered network edge while the customer’s assigned host is unavailable. Conversely, a healthy server can be unreachable if a route leaks, an access-control change is wrong, a DDoS defence over-filters traffic or an internal switch fails. A useful incident diagnosis separates global route visibility, facility ingress, internal network reachability and host health.

The absence of visible IPv6 in the sources is also notable, though it should be phrased carefully. The observed sources reported no originated IPv6 allocation for AS201200 at the time checked. That does not prove that no SuperHosting.BG service can use IPv6 through another arrangement, and it says nothing about private internal addressing. It does mean that the company’s clearly visible public autonomous-system footprint remains IPv4-centred. For customers that require native dual-stack hosting, this is a point to confirm for the exact product rather than assume from the company name.

External measurements provide signals, not a service inventory. IPinfo’s hosted-domain estimate suggests a dense shared-hosting population, but it cannot identify contractual customers or the exact number of live sites. Cloudflare’s traffic view demonstrates observation of the network, but not available bandwidth or uptime. BGP collectors show advertised reachability, but not packet loss inside the platform. These sources are valuable because they test the existence and broad shape of the network independently; they cannot settle physical path diversity or recovery readiness.

The most defensible network grade is consequently strong for current AS201200 activity and the identity of its two upstreams, but only medium for redundancy. To strengthen the latter, a customer would need evidence of separate facility entrances, separate routers and power domains, tested withdrawal behaviour, per-prefix policy and packet-level measurements from several Bulgarian and international networks during an incident.

Installed capacity is not the same as usable capacity

Hosting companies sell small, legible units: gigabytes of RAM, virtual CPU cores, SSD space and monthly traffic. Physical infrastructure arrives in much larger and less interchangeable blocks: cabinets, kilowatts, servers, storage shelves, switch ports and cross-connects. The commercial catalogue can show what a customer may order without revealing how much underlying capacity is installed, how much is already committed or how much must remain unused so that failures can be absorbed.

SuperHosting.BG’s VPS catalogue provides concrete retail allocations. The VPS product page ranges from small virtual machines to configurations with dozens of cores, large RAM allocations, SSD storage and specified monthly traffic allowances. The dedicated-server offer describes individually allocated hardware, RAID and SSD options and custom configurations. These pages prove that the operator offers multiple service tiers. They do not provide host counts, storage-pool size, oversubscription ratios, rack power draw or spare inventory.

The distinction appears even in the phrase “unlimited bandwidth.” SuperHosting.BG’s help page says shared-hosting plans and Managed VPS have unlimited bandwidth. Commercially, that means usage is not billed or capped by a stated transfer quota in those products. Physically, no interface or transit link is unlimited. Throughput remains bounded by ports, switching, server performance, congestion controls and acceptable-use rules. An unlimited meter is not infinite capacity.

The company’s Acceptable Use Policy makes those shared constraints visible. It sets limits on database size, concurrent HTTP connections, running processes and some file types, and allows service limitation when an account overloads shared equipment or exceeds defined thresholds. Such controls are normal in shared hosting: they prevent one tenant from consuming resources needed by others. Economically, they also show why a plan’s disk allowance is not a complete description of usable compute and I/O under load.

Capacity must therefore be assigned a status. Design capacity is what the facility or platform was built to support. Installed capacity is the hardware actually present. Powered capacity is installed equipment that can be energised within power and cooling limits. Operational capacity is commissioned and monitored. Usable capacity is what remains after faults, maintenance and safety reserves. Saleable capacity is the share the provider is willing to commit. Public SuperHosting.BG material supplies product allocations and some facility design figures, but it does not disclose the chain from installed to saleable capacity.

This uncertainty matters most during failure. A virtual cluster can appear comfortably provisioned in normal operation but lack enough spare RAM or storage performance to restart all workloads after losing a host. A backup may exist but compete with production traffic for I/O during restoration. A dedicated server may be replaceable in principle but wait for a compatible chassis or controller. A data centre may have spare floor area yet no immediately available power at the relevant rack. None of these conditions can be inferred from advertised plan sizes.

The older platform history adds context but not a present count. SuperHosting.BG previously described migrations to an all-SSD, cloud-oriented shared platform; the current company page claims a large website population. Those statements indicate successive investment and consolidation, but they do not reveal whether all accounts now share one architecture, how generations are separated or where legacy workloads remain. A customer should avoid turning “200,000+ websites” into a server-capacity calculation because domain density, dormant accounts, caching and plan mix are unknown.

A transparent capacity statement would publish ranges rather than security-sensitive detail: number of independent clusters, minimum failover headroom, storage replication class, typical spare-hardware coverage and the conditions under which new sales pause. No such current public statement was found. The honest conclusion is not that capacity is inadequate; it is that installed, sold, reserved and failure-usable capacity cannot be quantified from public information.

Shared hosting economics concentrate risk

Shared hosting makes professional infrastructure affordable to small organisations. Many customers share server, storage, network and administration layers, so each can buy a modest plan rather than a complete machine and operations team. SuperHosting.BG adds local-language help, domain management and tools intended to reduce technical work. For a Bulgarian shop, association or professional office, that package can be far more practical than building a platform from components.

The same economics create concentration. A shared server failure can affect many accounts. A storage problem can affect several servers. A control-panel defect, configuration error or security rule can cross account boundaries even when customer data remains separated. Centralised DNS, authentication, backup management or support intake can become a common dependency. The number of websites affected by an event is therefore determined less by the retail price of each account than by how the underlying layers are grouped.

SuperHosting.BG’s server-name guidance shows that accounts are assigned to specific physical or virtual hosts. That helps support identify the relevant machine, but it does not reveal the customer population on that host or the dependencies shared with neighbouring machines. The company’s client profile separates commercial service management from cPanel account administration, which is convenient in normal use. During an outage, however, each additional control surface can fail independently or remain available while the underlying service is not.

Resource rules are part of the economic bargain. The Acceptable Use Policy’s limits on processes, queries and connections protect platform stability, while allowing the provider to constrain an account that harms others. For the customer, this means an apparent outage may be an enforcement or saturation event rather than a broken rack. The remedy could be application optimisation, a plan upgrade or movement to Managed VPS rather than hardware repair. Good incident communication should distinguish these cases quickly because they carry different responsibilities and restoration expectations.

Managed VPS reduces some forms of contention by assigning guaranteed resources not shared with other customer applications, according to the company’s help page. Yet the virtual server still resides on physical infrastructure and may still share a host, storage, network and facility with other virtual machines. “Guaranteed” at the virtual allocation layer is not the same as physically dedicated hardware. Dedicated servers remove the compute host from the shared layer but still use common racks, switches, carriers and facility systems.

Scale can improve resilience. A provider serving a large base can afford specialised staff, spares, monitoring and multiple suppliers that a single small company could not. It can standardise recovery and spread capital costs. Scale can also increase the consequence of a common error. The relevant question is not whether concentration is inherently bad, but whether the provider has divided the platform into failure domains small enough to contain incidents and has sufficient headroom to recover those domains.

Public pages do not describe those partitions. There is no current disclosure of how many shared-hosting clusters exist, the maximum accounts per server, storage-failure boundaries, management-network separation or the percentage of customers that could be moved during a site event. Marketing uptime figures aggregate away this structure. A platform could achieve high annual availability while still exposing a subset of customers to a long, rare restoration.

Customers should match architecture to consequence. A brochure site that can be rebuilt from a recent copy has different needs from a shop whose inventory and orders change every minute. A company whose mail and website share one hosting account may lose both its public presence and its ordinary support channel at once. The lowest monthly price can be rational, but only when the business has accepted the corresponding recovery point, recovery time and concentration risk.

Backups are a product, not an automatic recovery guarantee

SuperHosting.BG provides more backup detail than many retail hosts, and that detail exposes why the word “backup” is not enough. Its Bulgarian backup overview says customer data is copied to additional backup servers several times per week, with the minimum number of retained system backups depending on the service. That supports the existence of a routine backup service. It does not state where those backup servers are, whether they use a separate facility or power domain, how quickly a large account can be restored, or how often restoration is tested.

For shared Linux hosting, the Backup Manager guide says customers can restore files, directories and databases or request a downloadable system backup. It warns that restored content overwrites current content and that changes made after the chosen backup will be lost. It also notes that a requested download must be prepared and remains available for a limited period. These details make the recovery point visible: the customer returns to the state of a selected archive, not to the instant immediately before failure.

The company’s manual restoration guide explains how to unpack a system archive, upload files by FTP and import an SQL database. This is a valuable escape route if automated restoration is unsuitable, but it transfers time and technical work to the customer. A large archive, a slow connection, unfamiliar database encoding or missing credentials can turn an apparently simple copy into a long business outage.

WordPress users have a more focused interface. The current WordPress restore guide allows files, the database or both to be restored from the latest system backup, again warning that later changes will be overwritten. Convenience reduces the number of manual steps; it does not change the age of the backup or prove that the backup is complete and clean. If a compromise or application error predates the latest copy, rapid restoration may faithfully reintroduce it.

Standard VPS backup is a separate, optional product. The company’s VPS snapshots guide says snapshots can be activated for VPS plans, are generated automatically three times a week and retain up to three archives. Restoring onto the existing machine deletes and recreates the virtual server from the snapshot. The guide also describes creating a temporary clone for selective data recovery. That is useful flexibility, but it confirms two risks: data after the snapshot is lost, and a full-machine restoration is a destructive action that must be chosen carefully.

Managed VPS has another tier. The additional VIP backup description distinguishes a standard schedule of up to three archives per week from a paid option retaining up to seven daily full archives and including all files. The Managed VPS terms and Acceptable Use Policy also place obligations on users to maintain an independent backup set. This is a crucial boundary: buying provider backup reduces risk, but the provider’s own terms do not make it the customer’s only safe copy.

Backup quality has at least six dimensions. Coverage asks which files, databases, mail and configurations are included. Frequency determines potential data loss. Retention determines how far back the customer can go. Separation determines whether the copy survives the live system’s failure. Integrity determines whether it can be read. Restore capacity determines how quickly it can be returned to service. SuperHosting.BG publishes useful information on coverage, schedule and user actions for several products, but much less on separation, integrity testing and restore throughput.

The largest unresolved question is cross-facility placement. “Additional backup servers” proves separation from at least some production role; it does not prove separation from the building, storage fabric, credentials or management plane. The existence of both Equinix and Telepoint makes geographically distinct backup plausible, but the public documents do not connect a particular backup service to a particular site. That evidence would need to come from product terms, a written customer assurance or a tested failure exercise.

Restore time is equally uncertain. A single file may return quickly through Backup Manager. Reconstructing a busy server, validating databases, restoring mail, changing DNS and checking application consistency can take far longer. During a wide incident, many customers may request recovery simultaneously, competing for storage I/O and support attention. The customer’s continuity plan should therefore measure a real restoration with representative data rather than assume that archive frequency equals recovery speed.

The support queue is part of the infrastructure

A rack does not replace its own drive. A route alarm does not decide whether to move traffic. A backup system does not know whether the customer wants to overwrite the live database. Human judgement links technical signals to action, which makes support staffing and escalation a genuine infrastructure layer rather than an accessory around the hardware.

SuperHosting.BG says its support is available at all hours, and the Managed VPS description includes continuous monitoring and rapid response when a problem arises. The client profile lets customers send a query to technical support, while the contact page provides phone and email routes. This local access is a meaningful strength for Bulgarian customers, especially those without a system administrator. It can shorten the time needed to translate a business symptom into a host, account or network identifier.

Yet “24/7” describes channel availability, not necessarily the authority or response target behind it. First-line staff may resolve an account setting but need to escalate a storage event. A network engineer may see healthy BGP sessions while a facility technician investigates power. A damaged server may require a part and scheduled access to a secure hall. If the incident spans Equinix, Telepoint, Neterra or Evolink, SuperHosting.BG must coordinate companies whose own evidence and priorities differ.

Facility support can help close that gap. Telepoint advertises 24-hour monitoring and support as well as remote-hands service. Equinix lists Smart Hands among SO1 services. These capabilities can put trained people near equipment even when SuperHosting.BG staff are elsewhere. But the public record does not say which tasks SuperHosting.BG has pre-authorised, what response it purchases, whether critical spares are on site or how access is handled during a broad emergency.

The support queue becomes most important during correlated failures. One failed customer account is a normal ticket. A storage shelf, shared cluster or route event may generate hundreds of reports at once. Duplicate tickets can obscure the common cause, while customers without status information repeatedly call. The operator then needs incident grouping, clear ownership, outbound communication and a way to protect engineers from interruption while still giving customers credible updates.

Recovery priority is another hidden policy. A provider may first restore network and shared platform services, then high-impact managed customers, then individual account requests. That order can be technically rational without matching every customer’s business urgency. No public source examined here establishes a detailed restoration order across SuperHosting.BG products. Customers with strict needs should seek a written support and recovery commitment rather than infer priority from a premium plan name.

The customer also has a role in reducing escalation time. It should know its account identifier, assigned server, recent changes, affected services and whether the symptom occurs from more than one network. It should keep an alternate published contact points outside the affected hosting account. If email is hosted on the same platform as the website, the business needs another way to receive incident updates. It should also designate who may authorise a destructive restore, since waiting for approval can lengthen an otherwise ready recovery.

Good support accountability is measurable. The relevant clocks are detection, acknowledgement, technical ownership, mitigation, restoration and explanation. A fast initial reply with no owner is less useful than a slightly slower response that identifies the failed layer and next action. SuperHosting.BG’s staffing scale and local support claims suggest it can maintain specialised capability; public information does not disclose performance against those clocks. A customer can obtain its own evidence by recording real incidents and scheduled restore tests.

Data locality is clearer than workload placement

For organisations concerned with data sovereignty, SuperHosting.BG offers a relatively clear national story at the broadest level. Its commercial pages state that hosting infrastructure is in Sofia, Bulgaria. The technical and organisational measures name two Sofia data-centre addresses and describe physical security, encrypted connections, archiving capability and DDoS protection. The legal supplier is a Bulgarian company, even though it belongs to a wider European group.

That supports a reasonable statement that the service has a Bulgarian operational and facility footprint. It does not support the stronger claim that every byte of every service always remains in one named Bulgarian building. Websites depend on DNS, certificate authorities, registries, payment services, analytics and user networks that may be international. Support and security suppliers may handle metadata outside the server rack. Traffic between two Bulgarian endpoints can follow paths chosen by interconnected networks rather than a map drawn by the hosting provider.

Corporate ownership and data location are also different questions. team.blue’s acquisition changed the group boundary, but it did not automatically move SuperHosting.BG’s servers out of Sofia. Conversely, a locally incorporated supplier can use foreign services. Customers should distinguish the contracting entity, the facility location, the location of backups, the location of administrative access and the location of subprocessors. A single “EU hosted” label compresses all of those dimensions.

The two-site disclosure is valuable but not customer-specific. The security document says the provider uses Equinix and Telepoint; product pages prominently identify Equinix. That could mean different products occupy different sites, backup infrastructure is separated, or the document covers a broader estate than the current retail pages. Public evidence does not resolve which interpretation is correct. A regulated customer should obtain written placement information for the actual service and account, not generalise from the company’s overall facility list.

Network geolocation is an especially weak substitute for physical proof. IP databases associate AS201200 with Bulgaria and often locate observed routers or addresses in Sofia, but such databases can be wrong, stale or based on registration. IPinfo explicitly warns that the resource holder’s country may not match where addresses are used. The named data-centre addresses and supplier documents carry more weight for location than an automated pin on a map.

Backup locality needs separate confirmation. A production server in Equinix and a backup server in the same hall would satisfy a simple Sofia-location statement but offer limited protection against a building-wide event. A backup at Telepoint could improve facility separation while remaining in Sofia. A customer might prefer that arrangement, but it is not proven for any particular plan by the public backup pages. The same applies to logs, monitoring data and downloaded support attachments.

Migration changes locality over time. SuperHosting.BG has acquired other hosting businesses and has described platform migrations in its history. Moving an account between servers may be necessary for maintenance, capacity or recovery. The help material tells customers how to identify their current hosting server, but not the physical site behind that server name. A meaningful locality assurance should remain valid through migration or require notice when the placement class changes.

For most Bulgarian small businesses, local support and Sofia facilities may be more immediately useful than a complex sovereignty claim. They can reduce language friction, clarify the governing commercial relationship and potentially improve latency to local users. For regulated or continuity-sensitive organisations, the remaining questions are precise: which site holds production, which site holds backups, who can administer the data, what cross-border services participate, and what happens to placement during recovery.

What customers should verify before the next incident

SuperHosting.BG’s public footprint supports a more concrete continuity conversation than a generic hosting brochure. The company identifies Sofia as the infrastructure location, names Equinix and Telepoint in a security document, names Neterra and Evolink for dedicated connectivity, operates an active autonomous system and publishes product-specific backup instructions. These are useful facts. They still leave the questions that determine a customer’s real outage length unanswered.

The first question is placement. The customer should ask which data centre hosts the live service, whether that answer changes by product, and whether the backup is in a different facility and failure domain. “We use two data centres” is not equivalent to “your production and recoverable copy are separated.” The answer should cover DNS, authentication and the management plane as well as the server data.

The second question is route diversity. Two upstreams should be confirmed as physically diverse at the relevant facility, with separate entrances, edge devices and power where possible. The customer does not need confidential fibre maps, but it does need a credible statement of common risks and tested failover. Measurements from outside AS201200 during maintenance or an incident can supplement that statement.

The third question is usable capacity. A customer should ask whether the service can restart after one host, storage component or rack feed fails; how much headroom is reserved; and what happens when replacement hardware is unavailable. For dedicated servers, it should ask about compatible spares and rebuild time. For shared or virtual services, it should ask whether enough cluster capacity exists to evacuate a failed host without severe contention.

The fourth question is backup quality. The customer should document what is copied, how often, how long it is retained, what is excluded and who may initiate restoration. It should download an independent copy on a schedule suited to the business and protect that copy with separate credentials. It should restore representative files and a database into a safe environment, record the elapsed time and verify the application rather than merely checking that an archive file exists.

The fifth question is support authority. The business should know the urgent contact route, the information required to open an incident, the promised response for its plan and the point at which a ticket reaches a network, systems or facility specialist. It should keep phone numbers and account details outside the hosted mailbox. If restoration overwrites data, it should name the person authorised to approve that action before an emergency.

The sixth question is migration. A working backup does not itself provide a destination. Customers with strict recovery targets need another environment, current configuration records, DNS access and a rehearsed way to move. Shared-hosting users should confirm whether exported mail, databases and files can be restored elsewhere. VPS users should know whether a platform-specific snapshot can be converted or whether they also need application-level backups.

The provider can strengthen confidence by publishing a concise service-by-service resilience statement: facility class, backup separation, recovery-point range, tested recovery-time range, maintenance exposure and support escalation. It can publish incident reviews that explain the failed layer without exposing sensitive design. It can distinguish facility uptime from end-to-end service availability and make clear when a backup feature is optional.

Until then, the public evidence supports a balanced conclusion. SuperHosting.BG is not a weightless control panel. It is a Bulgarian hosting operator with a visible IPv4 network, two named upstreams, two named Sofia data-centre relationships, a large claimed customer footprint and several backup mechanisms. Its service promise rests on real infrastructure and real staff. But public sources do not prove per-customer facility diversity, cross-site backup placement, spare capacity or a bounded restore time.

When the next Bulgarian business site goes dark, the decisive weakness may be neither the website code nor the control panel. It may be a rack feed, a storage controller, a shared switch, the age of the last clean copy, a missing replacement part or the moment when a support request reaches the person authorised to act. The customer’s best defence is to make that chain visible before failure, test the recovery path and keep one usable route out of the platform it depends on.