tsbg_hosting TSBG Hosting Ltd. vend de la capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de maintenance

Résumé

• TSBG Hosting Ltd. se présente comme un opérateur d'infrastructure bulgare fondé en 2006, avec des offres de colocation, serveur cloud, serveur dédié, hébergement mutualisé, streaming et services gérés sur son propre site.
• Les revendications opérationnelles les plus spécifiques à l'entreprise sont physiques plutôt que purement virtuelles: plusieurs centres de données bulgares neutres, quatre centres de données, conception orientée TIA-942, alimentation A/B, surveillance, assistance à distance, détection d'incendie, refroidissement et accès accompagné.
• Le signal réseau public actuel est faible.RIPE RDAPidentifie AS43112 comme tsbg_hosting et enregistre TSBG Hosting Ltd. comme titulaire, maisl'état de routage RIPEstatn'a montré aucun espace IPv4 ou IPv6 annoncé pour AS43112 le 2026-07-12.
• La ressource 193.3.63.0/24 de TSBG reste pertinente carRIPE RDAP pour le préfixeidentifie BG-TSBGHOSTING-20200902, etla validation RPKI de RIPEstata validé AS43112 comme autorisé pour ce préfixe. L'autorisation n'est pas équivalente à l'accessibilité en direct.
• L'enregistrement de l'installation TSBG Hosting sur PeeringDBajoute un indice physique à Haskovo/Svilengrad, tandis queles données net-facility de PeeringDBlient l'attachement listé à AS47288/FixNET plutôt qu'à AS43112. Cela souligne la nécessité de vérifier les limites de l'opérateur avant de se fier à toute revendication de résilience.
• La note de preuve est Faible. Le site officiel fournit des revendications de service riches, mais les preuves de routage public actuelles ne prouvent pas indépendamment le trafic client AS43112 en direct, le basculement multi-site, la diversité de transit, la capacité de réserve ou la portabilité des données.

Une facture cloud atterrit toujours dans une salle machine bulgare

TSBG Hosting Ltd. n'est pas un nom qui peut être évalué par la notoriété de la marque. Il doit être évalué en traçant le service jusqu'à l'équipement et aux personnes qui maintiendraient un client en ligne. L'entreprise vend des services qui semblent élastiques: serveurs cloud, plans VPS, serveurs dédiés, hébergement mutualisé, streaming et support géré. Mais chacun de ces services a un inventaire physique derrière lui. Un serveur virtuel a besoin de capacité hôte, de stockage, de commutation, d'alimentation et de refroidissement. Un serveur dédié a besoin d'un châssis spécifique et d'un plan de remplacement.

La colocation a besoin d'une baie, d'un budget d'alimentation, de routes de câbles, de contrôle d'accès et d'assistance à distance. Le streaming a besoin de capacité d'entrée, de transcodage ou de transfert, et d'une bande passante sortante suffisante pour porter l'audience lorsque la demande augmente.

Le fait utile à propos de TSBG est que l'entreprise ne se décrit pas seulement dans un langage cloud vague. Lapage d'accueil officiellecommercialise la colocation, les serveurs dédiés, les serveurs virtuels, le streaming et la colocation d'antennes satellites. La même page décrit quatre centres de données neutres et seize ans d'expérience, et indique que TSBG peut prendre en charge le cloud privé, les sites de reprise après sinistre, l'accès Internet dédié, les adresses IPv4, l'alimentation DC et la liaison satellite descendante. Ces affirmations donnent à l'acheteur une liste concrète à tester: bâtiments, baies, domaines d'alimentation, fibres, fournisseurs en amont, serveurs, ressources d'adresses et arrangements de support.

Le risque est que les détails marketing publics peuvent encore dépasser les preuves opérationnelles vérifiables. Un fournisseur peut posséder des baies mais externaliser certains chemins réseau. Il peut avoir un ASN valide mais ne pas l'annoncer actuellement. Il peut publier un menu de services tandis que des plans individuels dépendent du stock disponible, du support du fournisseur ou d'une installation tierce. Il peut offrir un site de reprise tandis que le contrat client laisse les objectifs de reprise vagues.

Pour TSBG, le dossier public contient exactement ce mélange: une histoire de service spécifique, une identité bulgare spécifique, un numéro AS spécifique, et un écart entre l'enregistrement des ressources numériques et l'origine de route visible à la date de publication.

Cet écart ne rend pas TSBG peu fiable. Il modifie la charge de la preuve. Un client ne doit pas traiter la liste de prix web ou l'ASN comme un rapport d'assurance. Le client doit demander quelle installation héberge la charge de travail, quelle périphérie réseau annonce le service, quel fournisseur dispose d'un transit avec capacité par défaut, quelle puissance et quel matériel de rechange sont réservés, et comment les données quittent la plateforme si le service doit être déplacé.

Ce qui peut être identifié avec certitude

L'identité de l'entreprise est plus solide que ce que la simple capture d'écran initiale de l'annuaire suggérait. Le site de TSBG indique que l'entreprise a été fondée en 2006, est constituée en vertu du droit bulgare, mentionne le numéro de TVA UE BG175059953, nomme Ivan Shishkov comme directeur général et donne une adresse de bureau à Sofia au 8 Racho Dimchev Street. Lapage de contactrépète l'adresse de Sofia, le numéro de téléphone et l'email commercial.RIPE RDAP pour AS43112identifie le nom d'objet comme tsbg_hosting et inclut TSBG Hosting Ltd. comme entité organisationnelle avec une adresse à Sofia.Les données Whois de RIPEstatenregistrent aut-num 43112, as-name tsbg_hosting, organisation ORG-THL32-RIPE, statut ASSIGNED et mainteneur mnt-bg-tsbghosting-1.

Ces enregistrements suffisent à éviter une erreur courante dans la recherche sur l'hébergement: traiter un nom de service comme une étiquette flottante sans titulaire responsable. Ici, le titulaire peut être lié à une identité d'entreprise bulgare, une surface de contact, un enregistrement de ressource numérique et un site de service visible. C'est plus utile qu'une page de revendeur sans adresse et sans enregistrement de routage.

Le périmètre des services est également spécifique. Lapage de colocationde TSBG annonce des forfaits pour une unité de baie, quart de baie, demi-baie et baie complète, avec des puissances indiquées allant de 35 W pour une unité de baie à 1500 W pour une baie complète. La page indique également que l'entreprise peut fournir une connectivité Internet, des adresses IPv4 et des services LIR. Lapage des serveurs cloudliste des plans VPS, du stockage SSD, une protection RAID10, un Internet partagé à 1 Gbit/s et des sauvegardes optionnelles. Lapage des serveurs dédiésdécrit des alimentations redondantes, du RAID 1 ou RAID 10, deux contrôleurs réseau et une redondance des commutateurs en haut de baie. Lapage d'hébergementcouvre l'hébergement mutualisé et l'hébergement VPS, y compris l'aide à la migration.

Ce mélange indique un fournisseur vendant de l'infrastructure à plusieurs niveaux d'abstraction. Les clients peuvent louer une partie d'une plateforme partagée, une machine virtuelle, un serveur physique, de l'espace en baie, de la connectivité ou du support. Le problème économique est que les produits de niveau supérieur héritent des contraintes de niveau inférieur. Si la baie perd de l'alimentation, le serveur dédié et les plans VPS attachés à ce site sont affectés.

Si la périphérie réseau perd un fournisseur ou qu'un objet de route est retiré, un plan d'hébergement apparemment séparé peut toujours échouer en même temps que le service de colocation. Si le support est assuré par la même petite équipe qui effectue le remplacement matériel, un incident chargé peut transformer une promesse d'assistance à distance gratuite en file d'attente.

L'enregistrement de ressource numérique est actif, mais la périphérie publique était silencieuse

Le fait réseau le plus important n'est pas flatteur, mais il est précis.L'aperçu AS de RIPEstat pour AS43112a identifié le titulaire comme tsbg_hosting TSBG Hosting Ltd., mais a marqué l'ASN comme non annoncé pour la requête du 2026-07-12.L'état de routage RIPEstata rapporté que la première route vue était 77.246.240.0/20 le 2007-06-14 et la dernière route vue était 193.3.63.0/24 le 2025-08-15, tandis que la visibilité actuelle était de zéro sur 325 pairs IPv4 et zéro sur 322 pairs IPv6.Les préfixes annoncés de RIPEstatn'ont renvoyé aucun préfixe actuel pour AS43112 pour la fenêtre du 2026-06-28 au 2026-07-12.

Cela n'efface pas les revendications de service de TSBG. Cela dit quelque chose de plus étroit: les collecteurs de routes publics n'ont pas vu AS43112 porter de l'espace annoncé en direct à la date de publication. Un client ne peut pas utiliser AS43112 seul comme preuve de service Internet actuel, de diversité de transit ou de trafic client. Si les services actuels sont fournis via un autre ASN, un bloc d'adresses attribué par un opérateur, un réseau de fournisseur, une interconnexion privée ou un arrangement de transit géré, cela doit être déclaré et testé directement.

La périphérie publique inactive change également la façon de lire les preuves plus anciennes.L'historique de routage RIPEstatmontre une longue activité historique pour 77.246.240.0/20, 77.246.240.0/21 et 193.3.63.0/24, avec la route 193.3.63.0/24 largement visible pendant une grande partie de 2022 à 2025 avant de tomber à une visibilité minimale après mi-août 2025. L'historique est utile pour l'identité et la continuité. Ce n'est pas une capacité actuelle. Si les mêmes clients sont toujours servis, ils peuvent maintenant l'être via une autre conception réseau. Si le préfixe a été retiré parce que les services ont été déplacés, le chemin de migration importe. S'il a été retiré parce que le service a été mis en pause, un acheteur doit le savoir avant de commander de la capacité.

RPKI ajoute une nuance supplémentaire.La validation RPKI de RIPEstat pour 193.3.63.0/24 et AS43112a renvoyé valide. C'est une preuve administrative positive: AS43112 est autorisé à annoncer le préfixe. Mais une autorisation d'origine de route valide n'est pas équivalente à une annonce. Un détecteur de fumée peut être installé dans une pièce actuellement vide; un ROA peut exister pour une route qui n'est pas visible en BGP. Le droit du plan de contrôle existe, tandis que le chemin opérationnel nécessite encore une confirmation en direct.

Le site revendique des installations solides, mais la carte est incomplète

Le récit public le plus fort de TSBG est celui de ses installations physiques. Lapage d'historique du centre de donnéesindique que l'entreprise a été fondée en 2006, a achevé son premier centre de données en septembre 2006, a achevé un deuxième projet de colocation en juillet 2007, a achevé un troisième centre de données comme site de reprise après sinistre avec le premier équipement installé en juillet 2008, et a achevé un quatrième centre de données en octobre 2008. Elle indique également que depuis 2014, TSBG se concentre sur la colocation, l'hébergement, la location de serveurs et les services gérés.

Lapage des centres de donnéesdéveloppe la revendication des installations. Elle indique que les sites de TSBG sont conçus selon TIA-942, que les emplacements sont soigneusement sélectionnés, que l'entreprise garantit une disponibilité électrique de 100 %, que l'alimentation est conçue dans une configuration A/B entièrement diversifiée, que le refroidissement est redondant par capacité nominale, et que la sécurité physique comprend des sites gardés, une surveillance vidéo et un accès accompagné. Elle indique que la surveillance couvre la charge du serveur, la mémoire, les disques, le trafic des ports, la santé des équipements, la température, l'humidité, le courant électrique, la consommation d'énergie, la climatisation et les performances du réseau optique.

Ce sont des revendications sérieuses. Elles exigent également qu'un acheteur demande des preuves spécifiques à l'installation. Quatre centres de données est un point de départ utile seulement si le client peut identifier lequel des quatre hébergera sa charge de travail, si le site de reprise est actif ou en veille, si les sites partagent le même fournisseur en amont, si le stockage de sauvegarde se trouve dans un domaine de défaillance séparé, et quel objectif de reprise contractuel s'applique lorsqu'un site est isolé. Les pages publiques décrivent des principes et des capacités.

Elles ne nomment pas chaque bâtiment, alimentation électrique, contrat de carburant, point de rencontre de transporteur, inventaire de pièces de rechange ou résultat de reprise testé.

La revendication géographique doit également être traitée avec précaution. TSBG indique que ses bâtiments sont en Bulgarie et sont géographiquement dispersés, à plus de 150 km de distance, dans des zones sélectionnées pour réduire les risques d'inondation, d'incendie, de trafic, industriels et d'activité humaine. Sonarticle de blog de 2023 sur la Bulgarie comme emplacement de centre de donnéesindique que la Bulgarie se trouve sur des routes importantes entre l'Europe, la Turquie et le Moyen-Orient, et dit que TSBG peut fournir des liaisons protégées de couche 2 et IP via des routes diverses vers Istanbul, Sofia, Bucarest et les réseaux européens. C'est une thèse régionale précieuse, en particulier pour les clients ayant des besoins de latence dans les Balkans, tournés vers la Turquie ou entre l'Europe et le Moyen-Orient. Mais l'avantage de localisation ne remplace pas une preuve de chemin en direct. Un bon corridor a encore besoin de transporteurs sous contrat, de conduits diversifiés, d'interconnexions fonctionnelles et d'une capacité suffisante après la défaillance d'un lien.

PeeringDB ajoute un indice de Haskovo et un avertissement de limite d'opérateur

PeeringDB donne au récit des installations un autre indice public.L'API d'installation PeeringDB pour l'installation 13672liste TSBG Hosting à Haskovo, Bulgarie, avec adresse1 Byalo More 3 Kapitan Andreevo, état Svilengrad, pays BG, un champ de site webtsbg.eu, un téléphone commercial et technique/email, et une tension disponible de 480 VAC. L'enregistrement a été créé le 2023-05-19 et mis à jour le 2025-09-26. C'est utile car c'est en dehors du propre site de TSBG et pointe vers une surface d'installation nommée spécifique dans le sud de la Bulgarie près du contexte de la frontière Turquie-Grèce souligné par le site de TSBG.

Mais les mêmes données PeeringDB créent un problème de limites.Les données netfac de PeeringDB pour l'installation 13672montrent une entrée réseau attachée nommée TSBG Hosting à Haskovo avec ASN local 47288.Le réseau PeeringDB 26850identifie ce réseau comme FIXNET TELEKOM LTD. STI., ASN 47288, avec une portée de trafic Europe, une politique de peering ouverte, sept installations et trois attachments d'échange.L'aperçu AS de RIPEstat pour AS47288identifie le titulaire comme FIXNET Telekomunikasyon Limited Sirketi et marque l'ASN comme annoncé.L'état de routage RIPEstat pour AS47288a vu une visibilité IPv4 et IPv6 active le 2026-07-12, avec 18 préfixes IPv4 et un préfixe IPv6 dans l'espace annoncé au niveau de l'état de routage.

Cela ne prouve pas que FixNET exploite les services clients de TSBG. Cela prouve que l'attachement d'installation PeeringDB public ne doit pas être lu comme une présence d'AS43112. Pour un acheteur, cette distinction est centrale. Si TSBG vend de la colocation dans une installation où l'ASN d'un autre opérateur est l'attachement réseau visible, le contrat doit expliquer si TSBG, FixNET, un autre transporteur ou le client fournit le service Internet par défaut.

Si TSBG vend des VPS ou des serveurs dédiés en utilisant une connectivité en amont plutôt que sa propre route AS43112 visible, le client doit savoir qui peut modifier le routage, qui ouvre les tickets en amont, et quel calendrier de maintenance affecte l'accessibilité.

La question de la limite d'opérateur n'est pas académique. Pendant un incident, le premier intervenant peut être le support de TSBG, le propriétaire de l'installation, un transporteur, un fournisseur d'assistance à distance ou le fournisseur réseau. Le client a besoin de la chaîne d'escalade avant la panne. Un enregistrement d'installation qui nomme TSBG et un enregistrement réseau qui nomme AS47288 peuvent tous deux être vrais, tout en laissant le client exposé si le contrat de service ne définit pas clairement les rôles.

L'économie des baies décide de la réalité du service

TSBG publie des prix de colocation et des forfaits de baie inhabituellement granulaires. Lapage de service de colocationliste une unité de baie simple, un quart de baie, une demi-baie et une baie complète, avec des allocations d'alimentation et des options de baie facultatives. La page indique également que TSBG peut fournir du 48 VDC en option standard, de l'alimentation A/B provenant de salles d'alimentation et de systèmes UPS séparés, des compteurs d'alimentation et des commutateurs ATS sur demande, une surveillance, un support 24/7 et un accès Internet. Cela donne aux clients un panier d'achat visible pour un service d'installation qui se cache généralement derrière des appels commerciaux.

Le danger est que le prix de baie visible n'est pas la même chose qu'une capacité résiliente utilisable. Une unité de baie simple avec 35 W est une dépendance très différente d'une baie complète avec 1500 W. Un client exploitant des équipements de télécommunications peut avoir besoin d'alimentation DC, de doubles PDU et d'un accès à distance; un client exécutant du calcul peut avoir besoin de plus d'alimentation, de refroidissement et de remplacement matériel.

Une liste de prix ne peut pas montrer si l'alimentation de réserve est réservée, si le travail d'interconnexion est rapide, si les mains à distance peuvent échanger un appareil pendant une tempête régionale, ou si le chemin réseau restant peut transporter le trafic lorsqu'un fournisseur est hors service.

L'économie du petit fournisseur compte ici. TSBG dit ouvertement sur son site qu'il n'est pas le plus grand opérateur de centre de données et n'a pas des mégawatts de puissance ou des térabits par seconde de capacité Internet. Cette honnêteté est utile. Elle dit aux acheteurs de chercher l'adéquation, pas le théâtre d'échelle. Un petit site peut être parfaitement adapté pour une entreprise locale, un projet de télécommunications de route frontalière, une armoire de reprise après sinistre ou un service à faible latence dans les Balkans.

Il peut aussi être inadapté pour une charge de travail qui suppose des pools de réserve hyperscale, des API cloud mondiales ou un remplacement matériel instantané.

L'acheteur doit donc traduire les étiquettes des forfaits en mathématiques de défaillance. Si une alimentation d'armoire tombe en panne, l'équipement client a-t-il des doubles alimentations et des doubles PDU? Si un commutateur de haut de baie tombe en panne, les deux NIC du serveur sont-elles câblées à des commutateurs indépendants? Si un fournisseur en amont est en panne, l'autre chemin a-t-il un engagement payé suffisant? Si un centre de données est perdu, les sauvegardes sont-elles utilisables sans le site perdu? Si un membre du support doit se déplacer vers un site distant, quelle est l'horloge de réparation réelle?

L'économie des baies devient une économie de risque une fois qu'une panne commence.

Les VPS et serveurs dédiés héritent de chaque couche inférieure

Les pages VPS et serveurs dédiés de TSBG sont suffisamment détaillées pour montrer d'où vient la valeur client. Lapage des serveurs cloudindique que les plans VPS sont basés sur Proxmox, utilisent du matériel redondant, du stockage RAID10, un réseau redondant et des hôtes serveurs avec alimentation, un Internet partagé à 1 Gbit/s et des sauvegardes optionnelles. Elle liste des plans allant d'un petit plan 512 MB RAM à des plans multi-cœurs plus grands. Lapage des serveurs dédiésindique que les serveurs ont des alimentations redondantes, du RAID 1 ou RAID 10, des contrôleurs RAID matériels, deux contrôleurs réseau et différents commutateurs de haut de baie. Elle mentionne également l'installation gratuite du système d'exploitation, la surveillance, un service d'assistance 24/7 et une assistance à distance.

Ces fonctionnalités sont significatives. Elles créent également un agenda de vérification. Un client louant une capacité VPS doit demander si RAID10 est local à un hôte, partagé sur un cluster de stockage, répliqué sur un autre site ou sauvegardé hors bande. Il doit demander si la sauvegarde optionnelle est stockée dans la même installation, si la vitesse de restauration est mesurée, et si les sauvegardes incluent les images système, les données au niveau fichier, les métadonnées et l'état du panneau de contrôle. Il doit demander ce qui se produit lorsque la machine hôte tombe en panne et si la migration en direct est disponible.

Il doit demander si la contention de ressources peut freiner la reprise lorsque de nombreux clients sont affectés en même temps.

Un client de serveur dédié a un problème différent. Les alimentations redondantes aident seulement si chaque alimentation atteint un chemin d'alimentation indépendant. Deux contrôleurs réseau aident seulement s'ils sont câblés à des commutateurs indépendants et routés via une capacité amont indépendante. RAID protège contre une défaillance de disque mais pas contre un bogue de contrôleur, une reconstruction erronée, un ransomware ou un événement à l'échelle du site. L'assistance à distance gratuite est utile seulement si les pièces sont en stock et que le personnel peut entrer rapidement dans l'installation.

L'écart de route publique rend ces questions plus importantes. Si AS43112 n'est pas actuellement visible, le service Internet orienté client de TSBG peut dépendre de routes attribuées par le fournisseur, d'un partenaire de transit, d'un autre ASN ou d'une conception privée non visible dans les collecteurs publics. Cet arrangement peut être parfaitement légitime. Il doit simplement être divulgué au client qui achète un accès Internet dans le cadre d'un plan de serveur. Le client doit savoir quelle périphérie échoue lorsque le transporteur échoue.

Les revendications d'alimentation, de refroidissement et de surveillance nécessitent des preuves testées

Les pages d'installations s'appuient fortement sur l'alimentation et la surveillance. TSBG indique que l'alimentation du centre de données est conçue dans une configuration A/B entièrement diversifiée, à partir de salles d'alimentation, de tableaux de distribution, de systèmes UPS et de câblage séparés jusqu'aux baies. Il indique que chaque baie a deux PDU ou plus, un pour le circuit A et un pour le circuit B. Il indique que la climatisation utilise une configuration redondante 1+1 ou n+1, et que les salles d'équipement sont maintenues autour de 22 degrés C avec une humidité relative entre 40 % et 60 %.

Il indique que la détection d'incendie utilise un système d'échantillonnage d'air et une suppression par gaz. Il indique que la surveillance couvre un large ensemble de paramètres environnementaux, de serveurs, de ports et de réseau optique.

Ce sont exactement les bons domaines à publier. La question est de savoir si les revendications sont testées au même niveau que les clients en dépendent. L'alimentation A/B n'est pas prouvée par deux câbles si les deux circuits dépendent d'un seul panneau en amont, d'un seul arrangement de carburant ou d'un seul fournisseur de maintenance. La redondance de refroidissement n'est pas prouvée par une capacité nominale si un allée chaude, une défaillance de capteur ou un changement de flux d'air peut supprimer la marge.

La surveillance n'est pas prouvée par des capteurs si la propriété des alertes, les seuils et les autorisations d'urgence ne sont pas clairs.

Le contenu du blog de TSBG donne des indices utiles sur le sérieux opérationnel. Lemessage sur la maintenance du générateur dieseldiscute de l'huile du générateur, des filtres, du liquide de refroidissement, des batteries et de la préparation hivernale. Lemessage sur la surveillance de la températurediscute de SNMP, Zabbix, des capteurs unifilaires, de la surveillance distribuée et de la conception d'alarmes. Lemessage sur l'emplacement du bâtiment du centre de donnéesdiscute de la sélection du site, des risques de catastrophe, de la construction en béton, de la conception du toit et de l'accès aux télécommunications. Ces messages ne sont pas des certifications, mais ils montrent une familiarité avec le domaine qui est plus spécifique qu'un copier-coller d'hébergement générique.

La prochaine étape pour le client devrait être la preuve, pas l'admiration. Demandez la date du dernier test du générateur, la charge testée, l'autonomie en carburant, les preuves de maintenance UPS, les preuves de maintenance du système d'incendie, le plan de réponse à une panne de refroidissement, un échantillon d'escalade de surveillance et les notes post-action de tout incident réel. Demandez si les quatre sites ont la même maturité. Demandez quel site héberge le service client spécifique. Demandez ce qui échoue ensemble. C'est ainsi que le langage large des installations devient une assurance opérationnelle.

La résilience réseau dépend des contrats en amont, pas seulement d'un ASN

Les propres pages de TSBG indiquent que l'entreprise gère son propre système autonome et a des sessions BGP avec des fournisseurs soigneusement sélectionnés. Les registres RIPE identifient AS43112, et les remarques whois de RIPE mentionnent les fournisseurs en amont et le centre de données, avec une importation de AS47964 et une exportation vers AS47964.La cohérence de routage AS de RIPEstata montré 193.3.63.0/24 dans whois RIPE mais pas en BGP le 2026-07-12, et a montré l'import/export AS47964 dans whois mais pas en BGP.Les voisins ASN de RIPEstat pour AS43112n'ont montré aucun voisin observé à la date de publication.

Cette combinaison dit à un acheteur de séparer trois choses. La première est l'intention du registre: l'ASN, l'objet de route, le ROA et les relations whois montrent ce que l'opérateur est préparé ou autorisé à faire. La seconde est le routage en direct: les collecteurs publics montrent si la route est actuellement visible et par qui. La troisième est le routage de service: une charge de travail client peut utiliser un fournisseur en amont différent ou un plan d'adresses non évident à partir du seul ASN de TSBG. La résilience dépend de la troisième, mais le dossier public éclaire principalement les deux premières.

La preuve PeeringDB AS47288 est également utile sans être surinterprétée. FixNET, le réseau AS47288 attaché à l'enregistrement d'installation TSBG Hosting, était actif dansl'état de routage RIPEstatet avait des attaches d'échange PeeringDB à NetIX, TurkIX Sofia et RegPEX. Cela montre une surface réseau active à proximité liée à l'enregistrement d'installation. Cela ne prouve pas que le trafic client de TSBG utilise cette surface, que TSBG la contrôle, ou qu'elle est suffisamment diversifiée pour un client donné.

Le test client est simple. Demandez à TSBG d'identifier les ASN, préfixes et fournisseurs en amont qui transporteront le service commandé. Demandez si ces chemins sont capables par défaut, s'ils utilisent des entrées physiques séparées, s'ils se terminent dans la même paire de routeurs, si les filtres de route sont à jour, et si la validation d'origine de route est configurée. Comparez la réponse avec des outils publics tels queBGP.tools pour AS43112,Hurricane Electric pour AS43112,Cloudflare Radar routing pour AS43112et RIPEstat. Si l'ASN public est intentionnellement silencieux, cela n'est acceptable que si le chemin de service en direct est documenté.

Le support fait partie de l'actif, pas une page d'aide

TSBG souligne à plusieurs reprises le support. Le site mentionne un support d'assistance 24/7, une assistance à distance, une messagerie email, Viber et WhatsApp, une surveillance et une aide au remplacement matériel gratuit. Dans un service d'hébergement ou de colocation, le support n'est pas un supplément logiciel. C'est le canal par lequel les dépendances invisibles deviennent des actions de réparation. Un routeur peut être redondant, mais quelqu'un doit encore identifier quel chemin est cassé. Une baie de disques peut être protégée, mais quelqu'un doit décider de reconstruire, restaurer ou basculer.

Un client peut posséder le serveur, mais les mains à distance peuvent être le seul moyen d'appuyer sur un bouton, de remettre en place une carte ou de lire une console.

La question du support est particulièrement importante pour un petit fournisseur avec plusieurs sites géographiquement dispersés. Les propres pages de TSBG disent que l'équipe est petite mais efficace, et que des partenaires sélectionnés aident pour le travail et la maintenance nécessaires. Cela peut être une force lorsque le client a besoin d'une attention directe flexible. Cela peut devenir une faiblesse si un incident touche plusieurs clients, qu'un site nécessite un accès physique, et que les mêmes personnes gèrent la surveillance, la communication, le matériel et l'escalade des fournisseurs.

Les clients doivent donc contractualiser le support comme une infrastructure. Ils doivent demander ce qui constitue une urgence, qui peut en déclarer une, quel canal de réponse fonctionne si le portail est en panne, si l'escalade téléphonique ou par messagerie est garantie, si l'assistance à distance a des limites de temps, et si les pièces sont stockées sur site. Ils doivent demander si un client en colocation peut autoriser le travail à l'avance. Ils doivent demander si un client VPS obtient de l'aide pour la restauration lors d'un incident de plateforme ou seulement un support au mieux.

Ils doivent demander si l'enregistrement de support nomme le site affecté, le fournisseur en amont, la baie ou la couche de service, plutôt que de décrire seulement une panne générique.

La facturation appartient à la même catégorie. Un service peut échouer en raison d'un compte désactivé, d'un terme de service expiré, d'un panneau de contrôle bloqué ou d'une responsabilité peu claire pour le trafic supplémentaire. Un client utilisant TSBG pour un petit site de reprise après sinistre doit s'assurer que le contact, la facturation, le renouvellement et l'accès hors bande restent disponibles pendant l'événement même qui rend le site de reprise nécessaire.

La localisation des données n'est pas résolue par une étiquette bulgare

La région d'affectation est BG, et le propre récit de TSBG est fortement bulgare. L'entreprise est constituée en Bulgarie, liste un bureau à Sofia, décrit des sites bulgares et commercialise la Bulgarie comme un emplacement stratégique de transit télécom. Pour les clients ayant des besoins de connectivité en Europe, dans les Balkans, tournés vers la Turquie ou le Moyen-Orient, c'est une revendication de positionnement significative. Cela peut réduire la latence, maintenir l'équipement sous une relation de fournisseur bulgare et fournir une alternative aux grandes régions cloud d'Europe occidentale.

Mais la souveraineté des données n'est pas seulement un code pays. Un client doit identifier où résident les données primaires, les sauvegardes, les journaux, les enregistrements du panneau de contrôle, les tickets de support, les données de surveillance et les enregistrements de facturation. Un plan VPS pourrait placer le disque virtuel dans une installation bulgare et la sauvegarde dans une autre. Un plan d'hébergement mutualisé pourrait utiliser des outils cPanel, des services de certificat tiers et un DNS externe.

Un service de streaming pourrait ingérer un signal depuis des liaisons satellites ou terrestres et le délivrer via un mélange de transit local et international. Un client de colocation pourrait posséder le matériel mais dépendre de TSBG pour l'accès à distance et le service IP.

Les pages publiques de TSBG ne publient pas une matrice de placement complète. Elles indiquent que l'entreprise exploite plusieurs centres de données en Bulgarie, que les sites sont géographiquement dispersés, et qu'elle peut fournir des liaisons protégées vers Istanbul, Sofia, Bucarest et les réseaux européens. Ce sont de bons faits de départ. Ils ne répondent pas si une sauvegarde spécifique traverse les frontières, si un fournisseur de support peut accéder aux systèmes clients, si les journaux sont conservés dans un système séparé, ou comment un client reçoit une copie utilisable des données lors d'un litige ou d'une panne.

La portabilité des données fait donc partie de l'examen de la résilience. Un acheteur doit tester comment partir. Pour l'hébergement mutualisé, le client peut-il récupérer proprement les fichiers, les boîtes aux lettres, les enregistrements DNS, les bases de données et les enregistrements TLS? Pour le VPS, peut-il exporter une image ou seulement des fichiers? Pour les serveurs dédiés, l'accès à la console à distance est-il disponible si le réseau est instable? Pour la colocation, qui contrôle le renumérotage IP, la libération des interconnexions et le retrait du matériel?

Le meilleur moment pour tester la portabilité est avant que le service ne devienne critique.

Les signaux non officiels peuvent suggérer des pistes, pas des conclusions

Les sujets d'infrastructure minces laissent souvent des traces dans les agrégateurs commerciaux, les vieilles pages BGP, les pages de prix, les résultats de recherche, les messages de forum, les profils sociaux et les répertoires d'installations. TSBG ne fait pas exception. Les agrégateurs de routage publics tels quela page AS43112 d'IPinfo,BGP.tools,Hurricane ElectricetCloudflare Radarsont utiles pour une vérification croisée rapide. PeeringDB est utile pour les indices d'installation et d'interconnexion. Le site officiel est utile pour les revendications de service et les informations de contact.

Ces signaux ne doivent pas être traités également. RIPE RDAP et RIPEstat sont solides pour l'identité des ressources numériques et l'observation des routes publiques. PeeringDB est précieux mais auto-maintenu et peut être en décalage avec la réalité. Le site officiel est faisant autorité pour ce que TSBG dit vendre, mais pas une preuve indépendante qu'une baie, un chemin de fibre ou une sauvegarde donnés existe aujourd'hui. Les pages d'agrégateurs sont bonnes pour la triangulation mais peuvent être à la traîne ou représenter les données différemment.

Les articles de blog montrent une réflexion technique, pas un certificat d'exploitation en direct.

La distinction importe le plus lorsque les preuves publiques sont en conflit. Les pages de service officielles de TSBG disent à plusieurs reprises que l'entreprise gère son propre AS avec des sessions BGP. Les registres RIPE identifient AS43112 et un ROA valide existe pour 193.3.63.0/24. Pourtant, RIPEstat n'a pas vu AS43112 annoncé à la date de publication. Ce n'est pas quelque chose à ignorer. C'est le résultat principal. Soit l'ASN public est actuellement dormant, soit les services actuels sont fournis via un autre chemin réseau, soit les collecteurs publics ont manqué une annonce limitée.

Chaque possibilité a des conséquences client différentes.

Qu'est-ce qui le réglerait? Une vue looking-glass actuelle de TSBG, une table de routage montrant les préfixes clients, une liste de fournisseurs en amont, une IP de test pour le service commandé, un traceroute et un résultat de diversité de chemin, une page de statut actuelle, une description de service spécifique à l'installation, et un langage contractuel nommant les parties responsables. Jusqu'à ce qu'ils soient disponibles, la posture éditoriale correcte est la prudence.

Comment un acheteur devrait tester TSBG avant de placer une charge de travail critique

Le premier test est l'identité et l'adéquation du service. Demandez à TSBG de confirmer quelle entité juridique signe le contrat, quel site hébergera le service, quelle couche de produit s'applique, et si le service utilise AS43112, AS47288, un bloc d'adresses de fournisseur de transit ou un autre arrangement de routage. Comparez la réponse àRIPE RDAP pour AS43112,RIPE RDAP pour 193.3.63.0/24et aux observations BGP publiques. Si la réponse est que l'ASN public n'est pas actuellement utilisé, demandez pourquoi et ce qui le remplace.

Le deuxième test est la preuve de l'installation. Pour la colocation, demandez le nom du site, la position de la baie, la conception de l'alimentation, le tirage maximal, les options d'interconnexion, les conditions d'assistance à distance, la procédure d'accès et les règles de notification de maintenance. Pour les VPS ou serveurs dédiés, demandez quelle installation héberge le matériel, si le site de reprise est actif, si les sauvegardes sont en dehors de l'hôte défaillant, et si la capacité est réservée pour le basculement. Demandez un résultat récent de test d'alimentation, de refroidissement ou de générateur. Lapage des centres de donnéesde TSBG donne une liste solide de domaines d'installation; le client a besoin de la version spécifique au site.

Le troisième test est l'indépendance réseau. Demandez les fournisseurs en amont actuels, les filtres de route, le statut RPKI, la diversité d'entrée physique, la vitesse d'interface, l'engagement payé, l'exposition DDoS et le comportement de basculement. Demandez si la revendication de connectivité Internet 99,999 % s'applique au produit client et comment les crédits sont calculés. Utilisez des outils publics pour vérifier si l'état de l'ASN et du préfixe correspond à la réponse, mais ne vous fiez pas uniquement aux outils publics si le service utilise un chemin privé ou partenaire.

Le quatrième test est la reprise. Effectuez une petite restauration. Exportez une image VPS ou reconstruisez à partir d'une sauvegarde. Demandez à l'assistance à distance d'effectuer une tâche de console ou d'inventaire non perturbatrice. Testez le contact hors bande. Confirmez qui peut autoriser les changements d'urgence. Confirmez si un verrouillage de compte, une facture impayée, un problème de domaine ou un litige de droit au support peut arrêter le travail de reprise. Le matériel public décrit un petit opérateur compétent; le travail du client est de prouver cette compétence dans son propre scénario de défaillance.

Qui est affecté lorsque le système tombe en panne

La population affectée dépend du produit TSBG qu'un client achète. Un client d'hébergement mutualisé est exposé à des pannes au niveau de la plateforme: cPanel, DNS, courrier, stockage et le chemin de support du fournisseur. Un client VPS est exposé aux domaines de l'hôte, du stockage, du réseau et de la sauvegarde. Un client de serveur dédié est exposé au stock matériel, à la périphérie réseau, aux alimentations, à l'assistance à distance et à toute couche de service géré.

Un client de colocation possède une plus grande partie de la pile, mais dépend toujours de TSBG pour l'alimentation, le refroidissement, la sécurité physique, l'accès à distance et parfois le transit Internet.

Pour une entreprise locale, une panne peut signifier un temps d'arrêt du site web ou de la messagerie. Pour un opérateur télécom ou IT utilisant de l'espace en baie, une panne peut affecter les clients en aval, la surveillance, le backhaul, un système d'antenne ou un plan de reprise après sinistre. Pour un client de médias ou de streaming, une panne peut interrompre la diffusion au public. Pour une entreprise utilisant un site bulgare comme alternative à une plus grande région cloud d'Europe occidentale, une panne peut supprimer la redondance géographique même que le client avait l'intention d'acheter.

La surface de support crée également des effets de second ordre. Si le même contact gère les ventes, le support et l'escalade technique, les clients peuvent recevoir une attention personnelle pendant les opérations normales et une réponse lente lors d'un événement large. Si un chemin de fournisseur est impliqué, TSBG peut dépendre de l'horloge de réparation d'un autre transporteur. Si le service utilise une route non visible sous AS43112, les clients peuvent surveiller la mauvaise périphérie publique et manquer le véritable domaine de défaillance.

C'est pourquoi la conclusion de l'article n'est pas évitez TSBG. C'est n'achetez pas l'abstraction sans cartographier les dépendances. Le matériel public de TSBG est exceptionnellement opérationnel pour un petit fournisseur. La preuve manquante est l'accessibilité actuelle et le basculement testé pour le chemin client spécifique.

La note de preuve

TSBG Hosting Ltd. obtient une note de preuve réseau Faible pour cet article. La note n'est pas un jugement sur la satisfaction client ou la compétence technique. C'est un jugement sur ce que les preuves publiques peuvent prouver le 2026-07-12. Le site officiel donne des revendications de service solides et spécifiques à l'entreprise: quatre centres de données, colocation, VPS, serveurs dédiés, hébergement mutualisé, alimentation A/B, surveillance, assistance à distance, sécurité, détection d'incendie, refroidissement et positionnement de transit bulgare.

Les registres RIPE donnent une véritable identité de ressource numérique TSBG: AS43112, ORG-THL32-RIPE et 193.3.63.0/24. RPKI valide l'autorisation d'origine 193.3.63.0/24 pour AS43112.

La dégradation vient de la périphérie actuelle. RIPEstat n'a pas vu AS43112 annoncé, n'a pas vu de préfixes AS43112 actuels, et n'a pas vu de voisins AS43112 actuels. L'entrée d'installation TSBG Hosting sur PeeringDB ajoute un indice physique, mais son attachement réseau visible pointe vers AS47288/FixNET plutôt que AS43112. Cela peut représenter un arrangement partenaire ou en amont valide; cela ne prouve pas indépendamment le routage client en direct de TSBG.

La conclusion pratique est étroite. TSBG semble être un véritable opérateur d'hébergement et de colocation bulgare avec des revendications d'infrastructure physique détaillées. Un acheteur doit traiter ces revendications comme testables, pas réglées.

Avant de placer des charges de travail critiques, il doit obtenir des preuves de route actuelles, des preuves d'installation spécifiques au site, des limites en amont et de support, des preuves de sauvegarde ou de migration testées, et une carte écrite de qui restaure le service lorsqu'une panne de baie, de fournisseur en amont, de stock matériel, de support, de facturation, de migration ou de contrat fournisseur se produit.