Résumé
- SuperHosting.BG place publiquement son infrastructure d'hébergement à Sofia et nomme Equinix et Telepoint comme fournisseurs de centres de données, mais il ne divulgue pas comment les charges de travail des clients, les copies de sauvegarde ou les pièces de rechange sont réparties entre ces sites.
- AS201200 est visiblement actif avec une empreinte IPv4 substantielle et deux fournisseurs d'accès nommés, Neterra et Evolink; c'est une diversité de routage utile, mais les observations publiques BGP ne peuvent pas prouver des fibres, des entrées, des routeurs ou des domaines de défaillance physiquement séparés.
- La récupération dépend du service acheté, de l'âge et de l'emplacement d'une sauvegarde utilisable, du matériel disponible et d'une voie d'escalade humaine, donc un client doit tester la restauration et la migration avant de considérer un chiffre de disponibilité comme un plan de continuité.
La panne que les clients voient commence sous le tableau de bord
À 09h17 un matin de travail, un petit détaillant bulgare découvre que son site Web a disparu. Le propriétaire peut encore joindre un téléphone, peut-être l'espace client, mais la vitrine elle-même expire. Les commandes s'arrêtent, les rappels de paiement ne peuvent pas atteindre l'application, le personnel ne peut pas lire la messagerie Web, et une campagne publicitaire continue d'envoyer des visiteurs vers une erreur. Pour le client, l'incident semble être une chose: « l'hébergement est en panne ». Pour l'opérateur, il peut s'agir de plusieurs événements très différents dont les remèdes et les horloges ont peu en commun.
Le service visible se trouve au sommet d'une chaîne physique et organisationnelle. Un domaine doit résoudre. Des paquets doivent traverser un réseau d'accès, atteindre l'un des fournisseurs d'accès de SuperHosting.BG, entrer dans AS201200 et atterrir sur la bonne périphérie et le bon serveur. Le serveur a besoin d'alimentation en direct, de refroidissement, de stockage et d'un environnement d'exploitation fonctionnel. Le logiciel d'hébergement partagé doit savoir où se trouve le compte.
Si un disque, un hôte ou un compte a échoué, une sauvegarde intacte doit être disponible, suffisamment récente pour être utile et lisible par un système de restauration fonctionnel. Enfin, quelqu'un doit reconnaître l'incident, décider quelle couche est responsable et obtenir l'accès à l'équipement ou au plan de contrôle nécessaire pour le réparer.
Le matériel d'aide de SuperHosting.BG lui-même rend la différence entre la vitrine et ses machines inhabituellement claire. Son explication duprofil client et du compte d'hébergementindique que le profil est utilisé pour commander, renouveler et gérer les services, tandis que les fichiers, les bases de données et les boîtes aux lettres sont gérés dans le compte d'hébergement et, pour l'hébergement partagé, via cPanel. Un autre article indique que les clients peuvent découvrir l'hôte particulier qui leur est attribué car l'entreprise utilisedifférents serveurs physiques et virtuels avec des noms différents. Un statut de compte vert n'est donc pas la preuve que le serveur, le chemin de stockage ou la route attribué est en bonne santé.
Cette distinction est centrale pour évaluer l'entreprise. SuperHosting.BG commercialise un service de détail accessible, pas un espace au sol nu et de l'électricité. Les clients le jugent raisonnablement via le panneau, la réponse du support et si leur site se charge.
Pourtant, les actifs décisifs sont cachés à la vue ordinaire: l'armoire contenant la machine, le chemin d'alimentation qui l'alimente, l'installation de refroidissement qui évacue sa chaleur, les commutateurs et les fibres qui transportent le trafic, le système de stockage contenant les données en direct, les serveurs de sauvegarde contenant les copies plus anciennes, le disque de rechange dans l'inventaire et l'ingénieur autorisé à le remplacer. L'interface utilisateur peut signaler une panne; elle ne peut générer aucune de ces ressources.
Les pages publiques de l'entreprise soutiennent les grandes lignes d'une opération d'hébergement bulgare active. Sonhistorique et profil actuelindique qu'elle opère depuis plus de 20 ans, prend en charge plus de 200 000 sites Web et emploie plus de 100 personnes. Ce sont des affirmations de l'entreprise plutôt que des décomptes d'infrastructure audités, mais ils indiquent le rayon d'explosion potentiel d'un problème de plateforme. À cette échelle, une erreur dans une couche partagée peut affecter bien plus qu'un seul compte même lorsque la majeure partie du parc reste en bonne santé.
La bonne question d'ouverture dans un incident n'est donc pas seulement « SuperHosting.BG est-il en ligne? » C'est « Quelle dépendance est en panne pour ce client? » Une application défaillante, une limite de ressources au niveau du compte, une défaillance de serveur partagé, un événement de stockage, un problème de routage périphérique et une perte complète d'installation peuvent sembler similaires de l'extérieur. Ils nécessitent des preuves différentes, des personnes différentes et des actions de récupération différentes.
Le tableau de bord d'hébergement est une porte d'entrée utile dans le service, mais ce n'est pas la fondation du service.
Ce qu'est SuperHosting.BG—et ce qu'il ne possède pas
Le fournisseur légal est identifiable. Lesconditions actuelles du VPS gérénomment SuperHosting.BG Ltd., donnent l'identifiant d'entreprise bulgare 131449987 et décrivent le fournisseur comme délivrant et maintenant le service de serveur virtuel géré. Lehub des conditions généralesde l'entreprise sépare l'hébergement partagé, WordPress géré, le VPS géré, le VPS standard, les serveurs dédiés, les domaines et autres produits en catégories contractuelles distinctes. Cela importe car « hébergement » n'est pas une seule allocation de responsabilité. Le client peut administrer une machine virtuelle non gérée, partager une plateforme administrée par le fournisseur, ou acheter un serveur géré dans lequel SuperHosting.BG entreprend l'administration, la surveillance et la maintenance des sauvegardes.
La propriété d'entreprise ajoute une autre couche sans effacer le fournisseur local. En juillet 2020, team.blue a annoncé queSuperHosting avait rejoint le groupe. L'annonce décrivait un siège à Sofia, une expansion en Serbie, une acquisition antérieure de Host.bg et la direction continue des fondateurs. La page d'entreprise actuelle de SuperHosting.BG l'identifie également comme faisant partie de team.blue. L'appartenance à un groupe peut fournir une échelle d'achat, une expertise logicielle ou un soutien financier, mais elle ne dit pas en soi à un client bulgare quelle entité possède un serveur particulier, signe un contrat de colocation, détient une pièce de rechange ou commande un incident à 03h00.
Les installations physiques forment une frontière distincte. Les mesures techniques et organisationnelles actuelles de SuperHosting.BG indiquent que l'entreprise utilise des centres de données exploités par Equinix (Bulgaria) Data Centers EAD et Telepoint Ltd. C'est une preuve d'infrastructure en colocation ou hébergée, pas une preuve que SuperHosting.BG possède l'un ou l'autre bâtiment. Les opérateurs d'installations sont responsables de couches telles que l'accès au site, l'alimentation de base, les générateurs, le refroidissement et l'environnement physique en vertu de leurs contrats.
SuperHosting.BG reste responsable de l'équipement et des couches de service qu'il contrôle, et ses relations avec les opérateurs ajoutent encore d'autres entreprises à la chaîne.
L'offre de détail dépend donc d'au moins quatre types d'acteurs. SuperHosting.BG est le fournisseur d'hébergement orienté client et le détenteur de ressources réseau associé à AS201200. team.blue est le groupe parent. Equinix et Telepoint sont les fournisseurs d'installations nommés. Neterra et Evolink sont les fournisseurs de connectivité nommés. Les fabricants de matériel, les fournisseurs de panneaux de contrôle, les services de sécurité et les registres de domaine se situent au-delà de ces couches visibles, mais le matériel public ne fournit pas un inventaire complet des dépendances.
Un client ne peut pas supposer en toute sécurité que la propriété du groupe ou deux noms d'installation signifient que chaque produit est dupliqué à travers chaque couche.
La responsabilité change également avec le service choisi. La description duVPS gérépar SuperHosting.BG inclut cPanel, un support technique 24 heures sur 24, une surveillance continue, une sauvegarde de contenu régulière et une administration par l'entreprise. Un VPS standard, en revanche, donne au client le contrôle root et beaucoup plus de responsabilité opérationnelle. Le service dédié déplace le client sur une machine individuellement allouée mais dépend toujours du rack, du réseau et des dispositions de support de SuperHosting.BG. L'hébergement partagé place de nombreux comptes derrière des composants de plateforme communs et une administration du fournisseur.
Cette frontière n'est pas simplement des petits caractères juridiques. Elle détermine qui peut agir. Un client avec un accès root peut réparer un paquet cassé mais ne peut pas remplacer un disque défaillant ou rétablir l'alimentation de l'installation. Un client géré peut raisonnablement s'attendre à ce que le fournisseur enquête sur l'environnement d'exploitation, mais a toujours besoin de maintenir une connaissance de l'application et une copie indépendante des données critiques. Un technicien d'installation peut vérifier un disjoncteur ou exécuter un travail à distance mais peut ne pas être autorisé à modifier un cluster d'hébergement.
Un fournisseur d'accès peut réparer un circuit mais ne peut pas récupérer une base de données. Chaque transfert peut allonger la panne si la propriété et l'escalade ne sont pas claires.
SuperHosting.BG annonce unsupport technique 24 heures sur 24 et des coordonnées à Sofia. C'est un atout opérationnel important, en particulier pour les petites entreprises locales qui ne peuvent pas gérer leurs propres systèmes. Mais la disponibilité d'un canal de contact n'est pas la même chose qu'une matrice de sévérité publiée, une réponse garantie pour chaque plan ou un objectif de restauration divulgué. La revendication de continuité la plus forte de l'entreprise ne serait pas qu'une organisation possède tout. Ce serait que les frontières sont connues, testées et franchies rapidement lorsqu'un incident s'étend sur le fournisseur, l'installation, le transporteur et le client.
Les deux installations de Sofia nommées dans les documents publics
Le document le plus clair sur l'emplacement physique est lesmesures techniques et organisationnellesde SuperHosting.BG. Il nomme deux centres de données: Equinix au 10 rue « 5030 » dans le quartier Druzhba 1 de Sofia et Telepoint au 122 rue Ovtche Pole à Sofia. Il indique également que ces sites sont certifiés ISO 27001 et disposent de gardes physiques et d'un accès contrôlé. C'est plus spécifique qu'une affirmation générique selon laquelle les données sont conservées « en Europe » ou « en Bulgarie ». Cela place au moins une partie de la relation d'infrastructure du fournisseur dans deux installations identifiables de Sofia.
Les pages produits renforcent un côté de cette image. Lapage d'hébergement WordPress, lapage VPSet lapage serveur dédiéde l'entreprise décrivent toutes l'infrastructure située chez Equinix à Sofia. Les pages font référence à une alimentation et un refroidissement redondants et à au moins deux fournisseurs Internet indépendants; la page serveur dédié nomme Neterra et Evolink. Ce sont des représentations commerciales actuelles sur l'environnement de service. Elles ne disent pas que chaque plan, chaque génération de serveur ou chaque copie de sauvegarde est dans la même salle, ni n'expliquent le rôle du site Telepoint nommé dans le document de sécurité.
La proprepage d'installation SO1d'Equinix correspond à l'adresse de Druzhba 1. Equinix décrit 1 103 mètres carrés d'espace de colocation, une redondance UPS 2N, des générateurs N+1, un refroidissement N+1 et une autonomie du générateur de moins de 30 heures à pleine charge. Il liste également la sécurité physique et une gamme de certifications et de services d'interconnexion. Ces spécifications décrivent l'installation dans son ensemble. Elles ne divulguent pas le nombre d'armoires, la puissance contractée, les interconnexions, la priorité de carburant ou la position de SuperHosting.BG dans le bâtiment.
Lapage de contactde Telepoint correspond à l'adresse de Ovtche Pole avec « Sofia Center ». Sonsite principaldécrit trois installations neutres en termes d'opérateurs, un service de main à distance, de multiples transporteurs locaux et internationaux et une empreinte bulgare plus large qui inclut également Sofia Est et Montana. Ses affirmations d'infrastructure se réfèrent à l'espace et à la puissance combinés sur l'ensemble de son parc. Uneprésentation d'installation Telepointdécrit des alimentations UPS N+1, un refroidissement redondant, des groupes électrogènes, une surveillance et une grande population de transporteurs. Encore une fois, ce sont des capacités d'installation, pas la preuve que SuperHosting.BG les consomme toutes ou place les systèmes de production et de sauvegarde dans des bâtiments distincts.
Les deux adresses nommées créent une base plausible pour la diversité des sites, mais la divulgation publique s'arrête avant de la prouver. Les documents ne font pas correspondre les familles de produits aux sites. Ils ne disent pas si l'hébergement partagé fonctionne dans les deux, si l'un est principalement utilisé pour les sauvegardes, si la sauvegarde d'un client est stockée en dehors du bâtiment du serveur en direct, ou si les deux sites ont des équipes opérationnelles et des entrées de transporteur indépendantes.
Ils ne décrivent pas le mode de réplication, l'orchestration du basculement ou le point de récupération attendu après un événement au niveau du site.
Il est donc exact de dire que SuperHosting.BG utilise deux fournisseurs de centres de données nommés à Sofia. Il n'est pas exact de dire, sans confirmation spécifique au client, qu'un site donné est actif-actif entre Equinix et Telepoint. Même si deux copies existent, un stockage synchronisé en miroir peut reproduire la corruption; des données répliquées de manière asynchrone peuvent perdre les dernières écritures; et une copie froide peut nécessiter un nouveau matériel et une récupération manuelle. La géographie n'est que la première condition de la résilience.
Les preuves de localisation ont également une dimension temporelle. Les pages commerciales peuvent changer à mesure que les plateformes évoluent, tandis que les documents de sécurité peuvent couvrir un ensemble de services plus large que le produit particulier qu'un client achète. Une description de service utile identifierait le site en direct, le site de sauvegarde, la relation de réplication et le chemin de migration pour chaque classe de produit. En l'absence de ce détail, les deux adresses de Sofia doivent être traitées comme des relations d'installation vérifiées mais pas comme une carte complète du placement des charges de travail.
Alimentation, refroidissement et limites de la redondance des installations
Chaque promesse d'hébergement devient finalement une charge électrique. Le serveur a besoin d'une armoire alimentée, le réseau de stockage a besoin d'une alimentation stable, et la structure de commutation doit rester active suffisamment longtemps pour que le trafic atteigne la machine. Le refroidissement n'est pas une capacité optionnelle autour de cette charge; il fait partie de l'enveloppe de fonctionnement de la charge. Une armoire peut avoir de l'alimentation et devenir encore inutilisable si la chaleur ne peut pas être évacuée.
De même, un bâtiment peut avoir des générateurs tandis qu'une unité de distribution, un bus, un disjoncteur ou une alimentation d'armoire particulière reste un point de défaillance unique.
Les pages produits de SuperHosting.BG utilisent une formulation N+1 pour l'alimentation et la climatisation. Equinix publie des spécifications plus détaillées au niveau de l'installation pour SO1: UPS 2N, générateurs N+1 et refroidissement N+1. Lapage d'infrastructurede Telepoint décrit trois alimentations 10 kV provenant de sous-stations différentes sur des itinéraires non intersectants, plusieurs groupes de transformateurs et UPS, six générateurs diesel et un refroidissement N+1 pour chaque salle de colocation. Ce sont des caractéristiques techniques significatives car elles fournissent des composants de rechange ou des chemins alternatifs dans la conception de l'installation.
Elles ne sont pas une garantie absolue. « N+1 » indique qu'une unité supplémentaire existe au-delà du nombre requis pour la charge de conception; il ne montre pas l'état de maintenance de chaque unité, la configuration de la distribution en aval ou si un contrôleur commun peut tomber en panne. « 2N » indique deux chemins de capacité complets au niveau indiqué; il ne prouve pas qu'un serveur client a des alimentations doubles connectées à des alimentations séparées, que les deux alimentations sont correctement mises en service, ou que tous les périphériques réseau suivent le même modèle.
L'autonomie du générateur est une estimation dans des conditions déclarées et dépend toujours de la fiabilité du démarrage, du carburant, du réapprovisionnement et de la réponse humaine.
La question orientée client est plus étroite que de savoir si un centre de données est bien conçu. C'est de savoir si l'ensemble du chemin de service préserve la résilience de l'installation. Un serveur à un seul cordon connecté à une alimentation d'armoire ne peut pas tirer pleinement parti de deux systèmes d'alimentation en amont. Une étagère de stockage avec un contrôleur défaillant peut bloquer de nombreuses machines par ailleurs saines. Un commutateur de haut de rack peut concentrer la joignabilité. Un service de contrôle de cluster peut échouer même si chaque hôte physique est alimenté.
La redondance doit se prolonger à travers les couches rack, serveur, stockage et réseau, et ne pas s'arrêter à la spécification du bâtiment.
Les documents publics ne divulguent pas ces arrangements de niveau inférieur. SuperHosting.BG ne publie pas de diagrammes de rack par plateforme, d'affectations d'alimentation, de topologie de stockage, de quantités de pièces de rechange ou de scénarios de défaillance de composants testés. Cette omission est compréhensible d'un point de vue sécuritaire et commercial, mais elle limite ce que les clients peuvent déduire des badges d'installation.
La conclusion correcte est que les installations nommées annoncent des caractéristiques de résilience sérieuses, tandis que l'utilisation réelle de ces caractéristiques par SuperHosting.BG reste largement privée.
La maintenance est une autre source de risque. Les systèmes redondants deviennent souvent temporairement non redondants pendant qu'un UPS, un générateur, un refroidisseur ou un commutateur est entretenu. La capacité peut également être techniquement installée mais indisponible car elle est réservée au basculement, en attente de mise en service, contrainte par le refroidissement ou manquant d'une pièce compatible. Une pénurie de matériel n'a pas besoin de vider tout l'entrepôt pour avoir de l'importance; elle doit seulement affecter le disque, le contrôleur, l'alimentation ou la génération de serveur exact requis par le système défaillant.
La récupération intersite réduirait certains risques au niveau du bâtiment, mais seulement si elle est conçue comme un service opérationnel. Les deux installations de Sofia sont des adresses séparées, mais les documents publics n'établissent pas de régions de services publics diverses, d'itinéraires de fibre, de réplication de stockage ou d'un ordre de récupération convenu. Ils n'identifient pas non plus si le DNS client, l'authentification, le support et la surveillance peuvent continuer si l'environnement d'hébergement principal échoue.
Un deuxième site qui dépend du même service de contrôle ou des mêmes identifiants manuels peut ne pas être immédiatement utilisable.
La redondance des installations est donc mieux comprise comme un ensemble de conditions préalables. Equinix et Telepoint peuvent maintenir la salle dans son enveloppe d'alimentation, de refroidissement et de sécurité. SuperHosting.BG doit transformer cette enveloppe en racks et plateformes résilients. Le client doit choisir un service dont les propriétés de récupération correspondent à son activité. Aucune des trois couches ne peut se substituer aux autres.
AS201200: deux fournisseurs d'accès, de nombreux préfixes, un seul bord visible
Les preuves visibles sur Internet sont plus solides que les preuves de capacité. Laréponse des préfixes annoncés de RIPEstata montré 21 préfixes IPv4 originaires d'AS201200 sur la fenêtre d'observation se terminant le 18 juillet 2026.bgp.toolsa également identifié le système autonome comme actif, a listé 21 préfixes IPv4 originaires et a montré deux relations en amont: AS34224 Neterra et AS8262 Evolink. Cela correspond à la page serveur dédié de SuperHosting.BG, qui nomme les deux mêmes fournisseurs de connectivité.
Des vues indépendantes corroborent largement l'existence du réseau tout en illustrant pourquoi aucun compteur unique ne doit être traité comme immuable. Lapage AS201200 d'IPinfol'a classé comme un réseau d'hébergement bulgare, a compté 9 472 adresses IPv4 et aucune adresse IPv6, et a listé Neterra et Evolink comme les deux fournisseurs d'accès.Cloudflare Radara également identifié AS201200 comme SuperHosting.BG en Bulgarie et a affiché le trafic observé.La vue BGP de GIBIRNeta signalé les mêmes deux pairs mais un nombre de réseaux légèrement différent à son heure de mise à jour. Le timing, l'agrégation et les méthodes de collecte peuvent expliquer des différences modestes; la constatation stable est un bord d'hébergement IPv4 actif avec deux relations externes visibles.
Deux fournisseurs d'accès valent mieux qu'un car le système autonome peut, en principe, annoncer ses préfixes via l'un ou l'autre fournisseur. Si un opérateur perd la joignabilité, BGP peut retirer ou dé-préférer le chemin affecté et l'Internet peut converger sur l'autre. Cela réduit la dépendance vis-à-vis du réseau externe d'un seul opérateur et fournit une base pour la maintenance ou la tolérance aux pannes.
Mais BGP montre une joignabilité logique, pas le chemin physique. Une table de route publique ne révèle pas si les deux circuits entrent dans le même conduit de bâtiment, partagent une fibre métropolitaine, se terminent sur le même routeur de bordure, dépendent d'une plateforme optique commune ou traversent une installation en amont commune. Les étiquettes « pair » et « upstream » décrivent également des relations observées ou enregistrées, pas un engagement de niveau de service contractuel.
Le fait que les deux fournisseurs soient visibles ne prouve pas que chaque préfixe SuperHosting.BG est accepté de manière identique dans toutes les conditions de défaillance.
La diversité des routes ne résout pas non plus une panne de serveur ou d'installation. BGP peut transporter parfaitement le trafic vers une périphérie réseau alimentée alors que l'hôte attribué au client est indisponible. Inversement, un serveur en bonne santé peut être injoignable si une route fuit, si un changement de contrôle d'accès est incorrect, si une défense DDoS filtre trop de trafic ou si un commutateur interne échoue. Un diagnostic d'incident utile sépare la visibilité globale de la route, l'entrée de l'installation, la joignabilité du réseau interne et la santé de l'hôte.
L'absence d'IPv6 visible dans les sources est également notable, bien qu'elle doive être formulée avec soin. Les sources observées n'ont signalé aucune allocation IPv6 originaire pour AS201200 au moment de la vérification. Cela ne prouve pas qu'aucun service SuperHosting.BG ne peut utiliser IPv6 via un autre arrangement, et cela ne dit rien sur l'adressage interne privé. Cela signifie que l'empreinte du système autonome public clairement visible de l'entreprise reste centrée sur IPv4.
Pour les clients qui nécessitent un hébergement natif double pile, c'est un point à confirmer pour le produit exact plutôt qu'à supposer à partir du nom de l'entreprise.
Les mesures externes fournissent des signaux, pas un inventaire de service. L'estimation des domaines hébergés d'IPinfo suggère une population d'hébergement partagé dense, mais elle ne peut pas identifier les clients contractuels ou le nombre exact de sites en direct. La vue du trafic de Cloudflare démontre l'observation du réseau, mais pas la bande passante disponible ou la disponibilité. Les collecteurs BGP montrent la joignabilité annoncée, mais pas la perte de paquets à l'intérieur de la plateforme.
Ces sources sont précieuses car elles testent l'existence et la forme générale du réseau de manière indépendante; elles ne peuvent pas régler la diversité des chemins physiques ou la préparation à la récupération.
La note réseau la plus défendable est donc forte pour l'activité actuelle d'AS201200 et l'identité de ses deux fournisseurs d'accès, mais seulement moyenne pour la redondance. Pour renforcer cette dernière, un client aurait besoin de preuves d'entrées d'installation séparées, de routeurs et de domaines d'alimentation distincts, d'un comportement de retrait testé, d'une politique par préfixe et de mesures au niveau des paquets à partir de plusieurs réseaux bulgares et internationaux pendant un incident.
La capacité installée n'est pas la même que la capacité utilisable
Les sociétés d'hébergement vendent de petites unités lisibles: gigaoctets de RAM, cœurs de CPU virtuels, espace SSD et trafic mensuel. L'infrastructure physique arrive en blocs beaucoup plus grands et moins interchangeables: armoires, kilowatts, serveurs, étagères de stockage, ports de commutation et interconnexions. Le catalogue commercial peut montrer ce qu'un client peut commander sans révéler la quantité de capacité sous-jacente installée, déjà engagée ou qui doit rester inutilisée pour absorber les pannes.
Le catalogue VPS de SuperHosting.BG fournit des allocations de détail concrètes. Lapage produit VPSva des petites machines virtuelles à des configurations avec des dizaines de cœurs, de grandes allocations de RAM, un stockage SSD et des allocations de trafic mensuel spécifiées. L'offre deserveur dédiédécrit du matériel individuellement alloué, des options RAID et SSD et des configurations personnalisées. Ces pages prouvent que l'opérateur propose plusieurs niveaux de service. Elles ne fournissent pas de décomptes d'hôtes, de taille de pool de stockage, de ratios de surallocation, de consommation électrique des racks ou d'inventaire de rechange.
La distinction apparaît même dans l'expression « bande passante illimitée ». La page d'aide de SuperHosting.BG indique queles plans d'hébergement partagé et les VPS gérés ont une bande passante illimitée. Commercialement, cela signifie que l'utilisation n'est pas facturée ou plafonnée par un quota de transfert déclaré dans ces produits. Physiquement, aucune interface ou liaison de transit n'est illimitée. Le débit reste limité par les ports, la commutation, les performances du serveur, les contrôles de congestion et les règles d'utilisation acceptable. Un compteur illimité n'est pas une capacité infinie.
LaPolitique d'utilisation acceptablede l'entreprise rend ces contraintes partagées visibles. Elle fixe des limites sur la taille de la base de données, les connexions HTTP simultanées, les processus en cours d'exécution et certains types de fichiers, et permet la limitation du service lorsqu'un compte surcharge l'équipement partagé ou dépasse les seuils définis. De tels contrôles sont normaux dans l'hébergement partagé: ils empêchent un locataire de consommer les ressources nécessaires aux autres. Économiquement, ils montrent aussi pourquoi l'allocation de disque d'un plan n'est pas une description complète du calcul et des E/S utilisables sous charge.
La capacité doit donc se voir attribuer un statut. La capacité de conception est ce que l'installation ou la plateforme a été conçue pour supporter. La capacité installée est le matériel réellement présent. La capacité alimentée est l'équipement installé qui peut être sous tension dans les limites d'alimentation et de refroidissement. La capacité opérationnelle est mise en service et surveillée. La capacité utilisable est ce qui reste après les pannes, la maintenance et les réserves de sécurité. La capacité vendable est la part que le fournisseur est prêt à engager.
Le matériel public de SuperHosting.BG fournit des allocations de produits et quelques chiffres de conception d'installation, mais il ne divulgue pas la chaîne de la capacité installée à la capacité vendable.
Cette incertitude importe le plus en cas de panne. Un cluster virtuel peut sembler confortablement provisionné en fonctionnement normal mais manquer de suffisamment de RAM ou de performances de stockage de rechange pour redémarrer toutes les charges de travail après la perte d'un hôte. Une sauvegarde peut exister mais rivaliser avec le trafic de production pour les E/S pendant la restauration. Un serveur dédié peut être remplaçable en principe mais attendre un châssis ou un contrôleur compatible. Un centre de données peut avoir de la surface au sol de rechange mais aucune puissance disponible immédiatement au rack concerné.
Aucune de ces conditions ne peut être déduite des tailles de plan annoncées.
L'historique plus ancien de la plateforme ajoute du contexte mais pas un décompte actuel. SuperHosting.BG a précédemment décrit des migrations vers une plateforme partagée tout SSD orientée cloud; la page d'entreprise actuelle revendique une grande population de sites Web. Ces déclarations indiquent des investissements et des consolidations successifs, mais elles ne révèlent pas si tous les comptes partagent désormais une architecture, comment les générations sont séparées ou où les charges de travail héritées restent.
Un client devrait éviter de transformer « 200 000+ sites Web » en un calcul de capacité de serveur car la densité de domaines, les comptes inactifs, la mise en cache et la combinaison de plans sont inconnus.
Une déclaration de capacité transparente publierait des plages plutôt que des détails sensibles à la sécurité: nombre de clusters indépendants, marge de basculement minimale, classe de réplication de stockage, couverture typique des pièces de rechange et conditions dans lesquelles les nouvelles ventes sont suspendues. Aucune déclaration publique actuelle de ce type n'a été trouvée. La conclusion honnête n'est pas que la capacité est inadéquate; c'est que la capacité installée, vendue, réservée et utilisable en cas de panne ne peut pas être quantifiée à partir des informations publiques.
L'économie de l'hébergement partagé concentre le risque
L'hébergement partagé rend l'infrastructure professionnelle abordable pour les petites organisations. De nombreux clients partagent les couches serveur, stockage, réseau et administration, donc chacun peut acheter un plan modeste plutôt qu'une machine complète et une équipe d'exploitation. SuperHosting.BG ajoute une aide en langue locale, une gestion de domaine et des outils destinés à réduire le travail technique. Pour une boutique, une association ou un cabinet professionnel bulgare, cet ensemble peut être bien plus pratique que de construire une plateforme à partir de composants.
La même économie crée une concentration. Une panne de serveur partagé peut affecter de nombreux comptes. Un problème de stockage peut affecter plusieurs serveurs. Un défaut du panneau de contrôle, une erreur de configuration ou une règle de sécurité peut traverser les limites des comptes même lorsque les données des clients restent séparées. Le DNS centralisé, l'authentification, la gestion des sauvegardes ou l'accueil du support peuvent devenir une dépendance commune.
Le nombre de sites Web affectés par un événement est donc déterminé moins par le prix de détail de chaque compte que par la manière dont les couches sous-jacentes sont regroupées.
Les conseils sur les noms de serveur de SuperHosting.BG montrent que les comptes sont attribués à des hôtes physiques ou virtuels spécifiques. Cela aide le support à identifier la machine concernée, mais cela ne révèle pas la population de clients sur cet hôte ou les dépendances partagées avec les machines voisines. Le profil client de l'entreprise sépare la gestion commerciale des services de l'administration du compte cPanel, ce qui est pratique en utilisation normale. Pendant une panne, cependant, chaque surface de contrôle supplémentaire peut échouer indépendamment ou rester disponible alors que le service sous-jacent ne l'est pas.
Les règles de ressources font partie du compromis économique. Les limites de la politique d'utilisation acceptable sur les processus, les requêtes et les connexions protègent la stabilité de la plateforme, tout en permettant au fournisseur de contraindre un compte qui nuit aux autres. Pour le client, cela signifie qu'une panne apparente peut être un événement d'application ou de saturation plutôt qu'un rack cassé. Le remède pourrait être une optimisation de l'application, une mise à niveau du plan ou un passage au VPS géré plutôt qu'une réparation matérielle.
Une bonne communication sur les incidents devrait distinguer ces cas rapidement car ils entraînent des responsabilités et des attentes de restauration différentes.
Le VPS géré réduit certaines formes de contention en attribuant des ressources garanties non partagées avec d'autres applications client, selon la page d'aide de l'entreprise. Pourtant, le serveur virtuel réside toujours sur une infrastructure physique et peut toujours partager un hôte, un stockage, un réseau et une installation avec d'autres machines virtuelles. « Garanti » au niveau de l'allocation virtuelle n'est pas la même chose qu'un matériel physiquement dédié.
Les serveurs dédiés retirent l'hôte de calcul de la couche partagée mais utilisent toujours des racks, des commutateurs, des transporteurs et des systèmes d'installation communs.
L'échelle peut améliorer la résilience. Un fournisseur desservant une large base peut se permettre du personnel spécialisé, des pièces de rechange, une surveillance et plusieurs fournisseurs qu'une seule petite entreprise ne pourrait pas. Il peut standardiser la récupération et répartir les coûts d'investissement. L'échelle peut également augmenter la conséquence d'une erreur courante.
La question pertinente n'est pas de savoir si la concentration est intrinsèquement mauvaise, mais si le fournisseur a divisé la plateforme en domaines de défaillance suffisamment petits pour contenir les incidents et dispose d'une marge suffisante pour récupérer ces domaines.
Les pages publiques ne décrivent pas ces partitions. Il n'y a aucune divulgation actuelle du nombre de clusters d'hébergement partagé, du nombre maximum de comptes par serveur, des limites de défaillance du stockage, de la séparation du réseau de gestion ou du pourcentage de clients qui pourraient être déplacés lors d'un événement de site. Les chiffres de disponibilité marketing agrègent cette structure. Une plateforme pourrait atteindre une disponibilité annuelle élevée tout en exposant un sous-ensemble de clients à une restauration longue et rare.
Les clients devraient faire correspondre l'architecture aux conséquences. Un site vitrine qui peut être reconstruit à partir d'une copie récente a des besoins différents d'une boutique dont l'inventaire et les commandes changent chaque minute. Une entreprise dont le courrier et le site Web partagent un seul compte d'hébergement peut perdre à la fois sa présence publique et son canal de support ordinaire en même temps. Le prix mensuel le plus bas peut être rationnel, mais seulement lorsque l'entreprise a accepté le point de récupération, le temps de récupération et le risque de concentration correspondants.
Les sauvegardes sont un produit, pas une garantie de récupération automatique
SuperHosting.BG fournit plus de détails sur les sauvegardes que de nombreux hébergeurs de détail, et ces détails exposent pourquoi le mot « sauvegarde » ne suffit pas. Sonaperçu des sauvegardesen bulgare indique que les données des clients sont copiées sur des serveurs de sauvegarde supplémentaires plusieurs fois par semaine, avec le nombre minimum de sauvegardes système conservées dépendant du service. Cela soutient l'existence d'un service de sauvegarde de routine. Cela ne précise pas où se trouvent ces serveurs de sauvegarde, s'ils utilisent une installation ou un domaine d'alimentation séparé, la rapidité avec laquelle un grand compte peut être restauré, ou la fréquence à laquelle la restauration est testée.
Pour l'hébergement Linux partagé, leguide du gestionnaire de sauvegardesindique que les clients peuvent restaurer des fichiers, des répertoires et des bases de données ou demander une sauvegarde système téléchargeable. Il prévient que le contenu restauré écrase le contenu actuel et que les modifications apportées après la sauvegarde choisie seront perdues. Il note également qu'un téléchargement demandé doit être préparé et reste disponible pour une période limitée. Ces détails rendent le point de récupération visible: le client revient à l'état d'une archive sélectionnée, pas à l'instant précédant immédiatement la panne.
Leguide de restauration manuellede l'entreprise explique comment décompresser une archive système, télécharger des fichiers par FTP et une base de données SQL. C'est une voie d'évacuation précieuse si la restauration automatisée est inappropriée, mais elle transfère le temps et le travail technique au client. Une grande archive, une connexion lente, un encodage de base de données inconnu ou des identifiants manquants peuvent transformer une copie apparemment simple en une longue interruption d'activité.
Les utilisateurs de WordPress ont une interface plus ciblée. Leguide de restauration WordPress actuelpermet de restaurer les fichiers, la base de données ou les deux à partir de la dernière sauvegarde système, avertissant à nouveau que les modifications ultérieures seront écrasées. La commodité réduit le nombre d'étapes manuelles; elle ne change pas l'âge de la sauvegarde ni ne prouve que la sauvegarde est complète et propre. Si un compromis ou une erreur d'application précède la dernière copie, une restauration rapide peut le réintroduire fidèlement.
La sauvegarde VPS standard est un produit séparé et optionnel. Leguide des instantanés VPSde l'entreprise indique que les instantanés peuvent être activés pour les plans VPS, sont générés automatiquement trois fois par semaine et conservent jusqu'à trois archives. La restauration sur la machine existante supprime et recrée le serveur virtuel à partir de l'instantané. Le guide décrit également la création d'un clone temporaire pour une récupération sélective des données. C'est une flexibilité utile, mais cela confirme deux risques: les données après l'instantané sont perdues, et une restauration complète de la machine est une action destructive qui doit être choisie avec soin.
Le VPS géré a un autre niveau. Ladescription supplémentaire de la sauvegarde VIPdistingue une planification standard allant jusqu'à trois archives par semaine d'une option payante conservant jusqu'à sept archives complètes quotidiennes et incluant tous les fichiers. Les conditions du VPS géré et la politique d'utilisation acceptable imposent également aux utilisateurs de maintenir un ensemble de sauvegarde indépendant. C'est une frontière cruciale: l'achat de la sauvegarde du fournisseur réduit le risque, mais les propres conditions du fournisseur n'en font pas la seule copie sécurisée du client.
La qualité de la sauvegarde a au moins six dimensions. La couverture demande quels fichiers, bases de données, courriers et configurations sont inclus. La fréquence détermine la perte de données potentielle. La rétention détermine jusqu'où le client peut remonter. La séparation détermine si la copie survit à la panne du système en direct. L'intégrité détermine si elle peut être lue. La capacité de restauration détermine la rapidité avec laquelle elle peut être remise en service.
SuperHosting.BG publie des informations utiles sur la couverture, le calendrier et les actions de l'utilisateur pour plusieurs produits, mais beaucoup moins sur la séparation, les tests d'intégrité et le débit de restauration.
La plus grande question non résolue est le placement entre installations. « Serveurs de sauvegarde supplémentaires » prouve la séparation d'au moins un rôle de production; cela ne prouve pas la séparation du bâtiment, de la structure de stockage, des identifiants ou du plan de gestion. L'existence à la fois d'Equinix et de Telepoint rend une sauvegarde géographiquement distincte plausible, mais les documents publics ne relient pas un service de sauvegarde particulier à un site particulier. Cette preuve devrait provenir des conditions du produit, d'une assurance écrite du client ou d'un exercice de défaillance testé.
Le temps de restauration est également incertain. Un seul fichier peut revenir rapidement via le gestionnaire de sauvegardes. La reconstruction d'un serveur chargé, la validation des bases de données, la restauration du courrier, le changement de DNS et la vérification de la cohérence de l'application peuvent prendre beaucoup plus de temps. Lors d'un incident étendu, de nombreux clients peuvent demander une récupération simultanément, en compétition pour les E/S de stockage et l'attention du support.
Le plan de continuité du client devrait donc mesurer une restauration réelle avec des données représentatives plutôt que de supposer que la fréquence des archives équivaut à la vitesse de récupération.
La file d'attente du support fait partie de l'infrastructure
Un rack ne remplace pas son propre disque. Une alarme de route ne décide pas de déplacer le trafic. Un système de sauvegarde ne sait pas si le client veut écraser la base de données en direct. Le jugement humain relie les signaux techniques à l'action, ce qui fait du personnel de support et de l'escalade une véritable couche d'infrastructure plutôt qu'un accessoire autour du matériel.
SuperHosting.BG indique que son support est disponible à toute heure, et la description du VPS géré inclut une surveillance continue et une réponse rapide lorsqu'un problème survient. Le profil client permet aux clients d'envoyer une requête au support technique, tandis que la page de contact fournit des numéros de téléphone et des adresses e-mail. Cet accès local est une force significative pour les clients bulgares, en particulier ceux sans administrateur système. Il peut réduire le temps nécessaire pour traduire un symptôme commercial en un identifiant d'hôte, de compte ou de réseau.
Pourtant, « 24/7 » décrit la disponibilité du canal, pas nécessairement l'autorité ou l'objectif de réponse derrière elle. Le personnel de première ligne peut résoudre un paramètre de compte mais doit escalader un événement de stockage. Un ingénieur réseau peut voir des sessions BGP saines tandis qu'un technicien d'installation enquête sur l'alimentation. Un serveur endommagé peut nécessiter une pièce et un accès programmé à une salle sécurisée. Si l'incident s'étend sur Equinix, Telepoint, Neterra ou Evolink, SuperHosting.BG doit coordonner des entreprises dont les propres preuves et priorités diffèrent.
Le support d'installation peut aider à combler cet écart. Telepoint annonce une surveillance et un support 24 heures sur 24 ainsi qu'un service de main à distance. Equinix liste les Smart Hands parmi les services SO1. Ces capacités peuvent mettre des personnes formées à proximité de l'équipement même lorsque le personnel de SuperHosting.BG est ailleurs. Mais les documents publics ne disent pas quelles tâches SuperHosting.BG a pré-autorisées, quelle réponse il achète, si des pièces de rechange critiques sont sur site ou comment l'accès est géré lors d'une urgence étendue.
La file d'attente du support devient la plus importante lors de défaillances corrélées. Un compte client défaillant est un ticket normal. Une étagère de stockage, un cluster partagé ou un événement de route peut générer des centaines de rapports à la fois. Les tickets en double peuvent obscurcir la cause commune, tandis que les clients sans information d'état appellent à plusieurs reprises. L'opérateur a alors besoin d'un regroupement des incidents, d'une propriété claire, d'une communication sortante et d'un moyen de protéger les ingénieurs des interruptions tout en donnant aux clients des mises à jour crédibles.
La priorité de récupération est une autre politique cachée. Un fournisseur peut d'abord restaurer le réseau et les services de plateforme partagée, puis les clients gérés à fort impact, puis les demandes de comptes individuels. Cet ordre peut être techniquement rationnel sans correspondre à l'urgence commerciale de chaque client. Aucune source publique examinée ici n'établit un ordre de restauration détaillé pour les produits SuperHosting.BG. Les clients ayant des besoins stricts devraient demander un engagement écrit de support et de récupération plutôt que de déduire une priorité d'un nom de plan premium.
Le client a également un rôle dans la réduction du temps d'escalade. Il doit connaître son identifiant de compte, son serveur attribué, ses modifications récentes, ses services affectés et si le symptôme se produit depuis plus d'un réseau. Il doit conserver un canal de contact alternatif en dehors du compte d'hébergement affecté. Si le courrier électronique est hébergé sur la même plateforme que le site Web, l'entreprise a besoin d'un autre moyen de recevoir les mises à jour d'incident. Elle doit également désigner qui peut autoriser une restauration destructive, car attendre l'approbation peut allonger une récupération par ailleurs prête.
Une bonne responsabilité du support est mesurable. Les horloges pertinentes sont la détection, l'accusé de réception, la propriété technique, l'atténuation, la restauration et l'explication. Une réponse initiale rapide sans propriétaire est moins utile qu'une réponse légèrement plus lente qui identifie la couche défaillante et la prochaine action. L'échelle de personnel de SuperHosting.BG et ses affirmations de support local suggèrent qu'il peut maintenir une capacité spécialisée; les informations publiques ne divulguent pas les performances par rapport à ces horloges.
Un client peut obtenir ses propres preuves en enregistrant les incidents réels et les tests de restauration programmés.
La localisation des données est plus claire que le placement des charges de travail
Pour les organisations préoccupées par la souveraineté des données, SuperHosting.BG offre une histoire nationale relativement claire au niveau le plus large. Ses pages commerciales indiquent que l'infrastructure d'hébergement se trouve à Sofia, en Bulgarie. Les mesures techniques et organisationnelles nomment deux adresses de centres de données à Sofia et décrivent la sécurité physique, les connexions cryptées, la capacité d'archivage et la protection DDoS. Le fournisseur légal est une entreprise bulgare, même si elle appartient à un groupe européen plus large.
Cela soutient une déclaration raisonnable selon laquelle le service a une empreinte opérationnelle et d'installation bulgare. Cela ne soutient pas l'affirmation plus forte selon laquelle chaque octet de chaque service reste toujours dans un bâtiment bulgare nommé. Les sites Web dépendent du DNS, des autorités de certification, des registres, des services de paiement, des analyses et des réseaux d'utilisateurs qui peuvent être internationaux. Les fournisseurs de support et de sécurité peuvent traiter des métadonnées en dehors du rack du serveur.
Le trafic entre deux points finaux bulgares peut suivre des chemins choisis par des réseaux interconnectés plutôt qu'une carte dessinée par le fournisseur d'hébergement.
La propriété d'entreprise et la localisation des données sont également des questions différentes. L'acquisition par team.blue a changé la limite du groupe, mais elle n'a pas automatiquement déplacé les serveurs de SuperHosting.BG hors de Sofia. Inversement, un fournisseur constitué localement peut utiliser des services étrangers. Les clients doivent distinguer l'entité contractante, l'emplacement de l'installation, l'emplacement des sauvegardes, l'emplacement de l'accès administratif et l'emplacement des sous-traitants. Une seule étiquette « hébergé dans l'UE » condense toutes ces dimensions.
La divulgation de deux sites est précieuse mais pas spécifique au client. Le document de sécurité indique que le fournisseur utilise Equinix et Telepoint; les pages produits identifient principalement Equinix. Cela pourrait signifier que différents produits occupent différents sites, que l'infrastructure de sauvegarde est séparée, ou que le document couvre un parc plus large que les pages de détail actuelles. Les preuves publiques ne résolvent pas quelle interprétation est correcte.
Un client réglementé devrait obtenir des informations écrites sur le placement pour le service et le compte réels, et non généraliser à partir de la liste globale des installations de l'entreprise.
La géolocalisation réseau est un substitut particulièrement faible à la preuve physique. Les bases de données IP associent AS201200 à la Bulgarie et localisent souvent les routeurs ou adresses observés à Sofia, mais ces bases de données peuvent être erronées, obsolètes ou basées sur l'enregistrement. IPinfo prévient explicitement que le pays du détenteur de la ressource peut ne pas correspondre à l'endroit où les adresses sont utilisées. Les adresses de centres de données nommés et les documents du fournisseur ont plus de poids pour la localisation qu'une épingle automatique sur une carte.
La localité des sauvegardes nécessite une confirmation séparée. Un serveur de production chez Equinix et un serveur de sauvegarde dans la même salle satisferaient une simple déclaration de localisation à Sofia mais offriraient une protection limitée contre un événement à l'échelle du bâtiment. Une sauvegarde chez Telepoint pourrait améliorer la séparation des installations tout en restant à Sofia. Un client pourrait préférer cet arrangement, mais il n'est pas prouvé pour un plan particulier par les pages de sauvegarde publiques. Il en va de même pour les journaux, les données de surveillance et les pièces jointes de support téléchargées.
La migration change la localité au fil du temps. SuperHosting.BG a acquis d'autres entreprises d'hébergement et a décrit des migrations de plateforme dans son historique. Déplacer un compte entre serveurs peut être nécessaire pour la maintenance, la capacité ou la récupération. Le matériel d'aide indique aux clients comment identifier leur serveur d'hébergement actuel, mais pas le site physique derrière ce nom de serveur. Une assurance de localité significative devrait rester valide pendant la migration ou nécessiter un préavis lorsque la classe de placement change.
Pour la plupart des petites entreprises bulgares, le support local et les installations de Sofia peuvent être plus immédiatement utiles qu'une revendication complexe de souveraineté. Ils peuvent réduire les frictions linguistiques, clarifier la relation commerciale régissante et potentiellement améliorer la latence pour les utilisateurs locaux.
Pour les organisations réglementées ou sensibles à la continuité, les questions restantes sont précises: quel site détient la production, quel site détient les sauvegardes, qui peut administrer les données, quels services transfrontaliers participent, et ce qu'il advient du placement pendant la récupération.
Ce que les clients devraient vérifier avant le prochain incident
L'empreinte publique de SuperHosting.BG soutient une conversation sur la continuité plus concrète qu'une brochure d'hébergement générique. L'entreprise identifie Sofia comme l'emplacement de l'infrastructure, nomme Equinix et Telepoint dans un document de sécurité, nomme Neterra et Evolink pour la connectivité dédiée, exploite un système autonome actif et publie des instructions de sauvegarde spécifiques au produit. Ce sont des faits utiles. Ils laissent encore sans réponse les questions qui déterminent la durée réelle de la panne d'un client.
La première question est le placement. Le client devrait demander quel centre de données héberge le service en direct, si cette réponse change selon le produit, et si la sauvegarde se trouve dans une installation et un domaine de défaillance différents. « Nous utilisons deux centres de données » n'est pas équivalent à « votre copie de production et votre copie récupérable sont séparées ». La réponse devrait couvrir le DNS, l'authentification et le plan de gestion ainsi que les données du serveur.
La deuxième question est la diversité des routes. Deux fournisseurs d'accès devraient être confirmés comme physiquement diversifiés dans l'installation concernée, avec des entrées, des périphériques de bordure et des alimentations séparés dans la mesure du possible. Le client n'a pas besoin de cartes de fibre confidentielles, mais il a besoin d'une déclaration crédible des risques communs et d'un basculement testé. Des mesures provenant de l'extérieur d'AS201200 pendant la maintenance ou un incident peuvent compléter cette déclaration.
La troisième question est la capacité utilisable. Un client devrait demander si le service peut redémarrer après la défaillance d'un hôte, d'un composant de stockage ou d'une alimentation de rack; quelle marge est réservée; et ce qui se passe lorsque le matériel de remplacement est indisponible. Pour les serveurs dédiés, il devrait demander les pièces de rechange compatibles et le temps de reconstruction. Pour les services partagés ou virtuels, il devrait demander s'il existe suffisamment de capacité de cluster pour évacuer un hôte défaillant sans contention sévère.
La quatrième question est la qualité de la sauvegarde. Le client devrait documenter ce qui est copié, à quelle fréquence, combien de temps il est conservé, ce qui est exclu et qui peut initier la restauration. Il devrait télécharger une copie indépendante selon un calendrier adapté à l'entreprise et protéger cette copie avec des identifiants séparés. Il devrait restaurer des fichiers représentatifs et une base de données dans un environnement sûr, enregistrer le temps écoulé et vérifier l'application plutôt que de simplement vérifier qu'un fichier d'archive existe.
La cinquième question est l'autorité de support. L'entreprise devrait connaître le contact d'urgence, les informations nécessaires pour ouvrir un incident, la réponse promise pour son plan et le point auquel un ticket atteint un spécialiste réseau, systèmes ou installation. Elle devrait conserver les numéros de téléphone et les détails du compte en dehors de la boîte aux lettres hébergée. Si la restauration écrase les données, elle devrait nommer la personne autorisée à approuver cette action avant une urgence.
La sixième question est la migration. Une sauvegarde fonctionnelle ne fournit pas en elle-même une destination. Les clients avec des objectifs de récupération stricts ont besoin d'un autre environnement, des enregistrements de configuration actuels, un accès DNS et un moyen répété de se déplacer. Les utilisateurs d'hébergement partagé devraient confirmer si les courriels, bases de données et fichiers exportés peuvent être restaurés ailleurs. Les utilisateurs de VPS devraient savoir si un instantané spécifique à la plateforme peut être converti ou s'ils ont également besoin de sauvegardes au niveau de l'application.
Le fournisseur peut renforcer la confiance en publiant une déclaration de résilience concise service par service: classe d'installation, séparation des sauvegardes, plage de points de récupération, plage de temps de récupération testée, exposition à la maintenance et escalade du support. Il peut publier des comptes rendus d'incidents qui expliquent la couche défaillante sans exposer la conception sensible. Il peut distinguer la disponibilité de l'installation de la disponibilité de service de bout en bout et clarifier quand une fonctionnalité de sauvegarde est optionnelle.
Jusque-là, les preuves publiques soutiennent une conclusion équilibrée. SuperHosting.BG n'est pas un panneau de contrôle sans substance. C'est un opérateur d'hébergement bulgare avec un réseau IPv4 visible, deux fournisseurs d'accès nommés, deux relations de centres de données nommés à Sofia, une grande base de clients revendiquée et plusieurs mécanismes de sauvegarde. Sa promesse de service repose sur une infrastructure réelle et un personnel réel. Mais les sources publiques ne prouvent pas la diversité des installations par client, le placement des sauvegardes intersites, la capacité de rechange ou un temps de restauration limité.
Lorsque le prochain site Web d'entreprise bulgare s'éteindra, la faiblesse décisive pourrait n'être ni le code du site Web ni le panneau de contrôle. Cela pourrait être une alimentation de rack, un contrôleur de stockage, un commutateur partagé, l'âge de la dernière copie propre, une pièce de rechange manquante ou le moment où une demande de support atteint la personne autorisée à agir. La meilleure défense du client est de rendre cette chaîne visible avant la panne, de tester le chemin de récupération et de conserver une voie utilisable hors de la plateforme dont il dépend.