tsbg_hosting TSBG Hosting Ltd. vend des capacités hébergées qui dépendent toujours des racks, du transit et des fenêtres de réparation

Résumé

• TSBG Hosting Ltd. se présente comme un opérateur d'infrastructure bulgare fondé en 2006, proposant sur son propre site des offres de colocation, de serveurs cloud, de serveurs dédiés, d'hébergement mutualisé, de streaming et de services gérés.
• Les affirmations opérationnelles les plus solides propres à l'entreprise sont physiques plutôt que purement virtuelles: plusieurs installations de centres de données bulgares neutres vis-à-vis des opérateurs, quatre centres de données, une conception orientée TIA-942, une alimentation A/B, une surveillance, une intervention à distance, une détection incendie, un refroidissement et un accès escorté.
• Le signal actuel du réseau public est faible.RIPE RDAPidentifie AS43112 comme tsbg_hosting et enregistre TSBG Hosting Ltd. comme titulaire, maisRIPEstat routing statusn'a montré aucun espace IPv4 ou IPv6 annoncé visible 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, etRIPEstat RPKI validationa validé AS43112 comme autorisé pour ce préfixe. L'autorisation n'est pas la même chose que l'accessibilité en direct.
• L'enregistrement d'installation TSBG Hosting dePeeringDBajoute un indice physique à Haskovo/Svilengrad, tandis queles données net-facility de PeeringDBlient l'attachement répertorié à AS47288/FixNET plutôt qu'à AS43112. Cela confirme la nécessité de vérifier les limites de l'opérateur avant de se fier à une quelconque affirmation de résilience.
• Le niveau de preuve est Faible. Le site officiel fournit des affirmations de service riches, mais les preuves de routage public actuelles ne prouvent pas indépendamment un trafic client AS43112 en direct, un basculement multi-site, une diversité de transit, une capacité de réserve ou une portabilité des données.

Une facture de cloud atterrit toujours dans une salle machine bulgare

TSBG Hosting Ltd. n'est pas un nom qui peut être évalué par la reconnaissance de la marque. Il doit être évalué en traçant le service jusqu'aux équipements 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, colocation 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'un rack, d'un budget d'alimentation, de chemins de câbles, de contrôle d'accès et d'intervention à distance. Le streaming a besoin de capacité d'ingestion, de transcodage ou de transfert et d'une bande passante sortante suffisante pour supporter l'audience lorsque la demande augmente.

Le fait utile concernant 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 vis-à-vis des opérateurs 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 en courant continu et la réception satellite. Ces affirmations donnent à l'acheteur une liste concrète à tester: bâtiments, racks, domaines d'alimentation, fibres, fournisseurs d'accès, serveurs, ressources d'adresses et arrangements de support.

Le risque est que les détails marketing publics peuvent encore devancer les preuves opérationnelles vérifiables. Un fournisseur peut posséder des racks 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 alors que les plans individuels dépendent du stock disponible, du support des fournisseurs ou d'une installation tierce. Il peut proposer un site de reprise alors 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'origination de route visible à la date de publication.

Cet écart ne rend pas TSBG non fiable. Il change la charge de la preuve. Un client ne doit pas considérer la liste de prix en ligne 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 capable de défaut, combien de puissance et de 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 confiance

L'identité de l'entreprise est plus solide que ne le suggérait l'instantané initial de l'annuaire. Le site de TSBG indique que l'entreprise a été fondée en 2006, est constituée en vertu de la loi bulgare, mentionne le numéro de TVA intracommunautaire BG175059953, nomme Ivan Shishkov comme directeur général, et donne une adresse de bureau à Sofia au 8, rue Racho Dimchev. 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. Lesdonnées whois de RIPEstatenregistrent l'aut-num 43112, as-name tsbg_hosting, organization ORG-THL32-RIPE, status ASSIGNED et maintainer 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.

L'étendue des services est également spécifique. Lapage de colocation de TSBGannonce des packages d'une unité de rack, d'un quart de rack, d'un demi-rack et d'un rack complet, avec des puissances indiquées allant de 35 W pour une unité de rack à 1500 W pour un rack complet. La page indique également que l'entreprise peut fournir une connectivité Internet, des adresses IPv4 et des services LIR. Lapage des serveurs cloudrépertorie des plans VPS, un stockage SSD, une protection RAID10, une connexion Internet partagée de 1 Gbit/s et des sauvegardes optionnelles. Lapage des serveurs dédiésdécrit des alimentations redondantes, RAID 1 ou RAID 10, deux contrôleurs réseau et une redondance des commutateurs de haut de rack. 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 couches d'abstraction. Les clients peuvent louer une tranche d'une plateforme partagée, une machine virtuelle, un serveur physique, un espace de rack, une connectivité ou un support. Le problème économique est que les produits de niveau supérieur héritent des contraintes de niveau inférieur. Si le rack perd l'alimentation, les plans de serveur dédié et VPS attachés à ce site sont affectés.

Si la périphérie réseau perd un fournisseur ou si un objet de route est retiré, un plan d'hébergement apparemment distinct peut également tomber en panne en même temps que le service de colocation. Si le support est géré par la même petite équipe qui effectue le remplacement du matériel, un incident chargé peut transformer une promesse d'« intervention à distance gratuite » en file d'attente.

L'enregistrement des ressources numériques 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. Lestatut de routage de 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. Lespréfixes annoncés par RIPEstatn'ont retourné 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 indique quelque chose de plus étroit: les collecteurs de routes publics n'ont pas vu AS43112 transporter de l'espace annoncé en direct à la date de publication. Un client ne peut pas utiliser AS43112 seul comme preuve du service Internet actuel, de la diversité de transit ou du trafic client. Si les services actuels sont fournis via un ASN différent, un bloc d'adresses attribué par un opérateur, un réseau de fournisseur, une interconnexion privée ou un arrangement de liaison montante géré, cela doit être indiqué et testé directement.

La périphérie publique inactive change également la façon de lire les preuves plus anciennes. L'historique de routage de RIPEstatmontre une longue activité historique pour 77.246.240.0/20, 77.246.240.0/21 et 193.3.63.0/24, la route 193.3.63.0/24 étant largement visible pendant une grande partie de 2022 à 2025 avant de tomber à une visibilité minimale après la 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 être servis via une autre conception de 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é suspendu, un acheteur doit le savoir avant de commander de la capacité.

RPKI ajoute une nuance supplémentaire. Lavalidation RPKI de RIPEstat pour 193.3.63.0/24 et AS43112a retourné valide. C'est une preuve administrative positive: AS43112 est autorisé à originer le préfixe. Mais une autorisation d'origine de route valide n'est pas la même chose qu'une annonce. Un détecteur de fumée peut être installé dans une pièce actuellement vide; une ROA peut exister pour une route qui n'est pas visible dans BGP. Le droit de plan de contrôle existe, tandis que le chemin opérationnel doit encore être confirmé en direct.

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

L'histoire publique la plus forte de TSBG est celle de ses installations physiques. Lapage d'historique des centres 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 conformément à TIA-942, que les emplacements sont soigneusement sélectionnés, que l'entreprise garantit une disponibilité de l'alimentation à 100 %, que l'alimentation est conçue dans une configuration A/B entièrement diversifiée, que le refroidissement est redondant en capacité nominale, et que la sécurité physique comprend des sites gardés, une vidéosurveillance et un accès escorté. 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 affirmations sérieuses. Elles exigent également d'un acheteur qu'il demande des preuves spécifiques à l'installation. « Quatre centres de données » n'est un point de départ utile que 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 d'accès, si le stockage de sauvegarde se trouve dans un domaine de défaillance distinct, 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, rencontre d'opérateurs, inventaire de pièces de rechange ou résultat de reprise testé.

La revendication géographique nécessite également une manipulation prudente. TSBG dit que ses bâtiments sont en Bulgarie et sont géographiquement répartis, à plus de 150 km les uns des autres, 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 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 vers les Balkans, la Turquie ou l'Europe-Moyen-Orient. Mais l'avantage de l'emplacement ne remplace pas la preuve de chemin en direct. Un bon corridor a encore besoin d'opérateurs contractés, de conduits diversifiés, d'interconnexions fonctionnelles et d'une capacité suffisante après la défaillance d'une liaison.

PeeringDB ajoute un indice sur Haskovo et un avertissement sur les limites de l'opérateur

PeeringDB donne à l'histoire des installations un indice public distinct.L'API d'installation PeeringDB pour l'installation 13672répertorie « TSBG Hosting » à Haskovo, en Bulgarie, avec l'adresse1 « Byalo More 3 Kapitan Andreevo », l'état Svilengrad, le pays BG, un champ de site Webtsbg.eu, des numéros de téléphone et email commerciaux et techniques, et un service de tension disponible 480 VAC. L'enregistrement a été créé le 2023-05-19 et mis à jour le 2025-09-26. C'est utile parce qu'il 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 limite. Lesdonnées netfac PeeringDB pour l'installation 13672montrent une entrée de réseau attaché nommée TSBG Hosting à Haskovo avec l'ASN local 47288. Leré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 attachements d'échange. L'aperçu AS de RIPEstat pour AS47288identifie le titulaire comme FIXNET Telekomunikasyon Limited Sirketi et marque l'ASN comme annoncé. Lestatut de routage de 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 la couche de statut de routage.

Cela ne prouve pas que FixNET exploite les services clients de TSBG. Cela prouve que l'attachement d'installation public PeeringDB ne doit pas être lu à la légère comme une présence 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 opérateur 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é de fournisseur d'accès plutôt que sa propre route AS43112 visible, le client doit savoir qui peut changer le routage, qui ouvre les tickets de fournisseur d'accès, et dont le calendrier de maintenance affecte l'accessibilité.

La question des limites de l'opérateur n'est pas académique. Lors d'un incident, le premier intervenant peut être le support TSBG, le propriétaire de l'installation, un opérateur, un fournisseur d'intervention à distance ou le fournisseur de 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 de 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 racks détermine la réalité du service

TSBG publie des prix de colocation et des packages de rack inhabituellement granulaires. Lapage de service de colocationrépertorie une unité de rack, un quart de rack, un demi-rack et un rack complet, avec des allocations de puissance et des fonctionnalités de rack optionnelles. La page indique également que TSBG peut fournir du 48 VDC en option standard, une alimentation A/B à partir de salles électriques et de systèmes UPS séparés, des compteurs de puissance 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 rack visible n'est pas la même chose que la capacité résiliente utilisable. Une seule unité de rack avec 35 W est une dépendance très différente d'un rack complet avec 1500 W. Un client exploitant des équipements de télécommunications peut avoir besoin d'une alimentation en courant continu, de PDU doubles et d'un accès d'intervention à distance; un client exécutant du calcul peut avoir besoin de plus de puissance, de refroidissement et de remplacement de 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 l'intervention à distance peut é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.

Les aspects économiques des petits fournisseurs importent ici. TSBG dit ouvertement sur son site qu'il n'est pas le plus grand opérateur de centres de données et qu'il n'a pas des mégawatts de puissance ou des térabits par seconde de capacité Internet. Cette honnêteté est utile. Elle indique aux acheteurs de rechercher l'adéquation, pas le spectacle de l'échelle. Un petit site peut être parfaitement adapté à une entreprise locale, à un projet de télécommunications de route frontalière, à une armoire de reprise après sinistre ou à un service balkanique à faible latence.

Il peut également être inadapté à une charge de travail qui suppose des pools de réserve à grande échelle, des API cloud mondiales ou un remplacement instantané du matériel.

L'acheteur doit donc traduire les étiquettes de package en calculs de défaillance. Si une alimentation d'armoire tombe en panne, l'équipement client a-t-il des alimentations doubles et des PDU doubles? Si un commutateur de haut de rack tombe en panne, les deux NIC du serveur sont-ils câblés à des commutateurs indépendants? Si un fournisseur d'accès 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 une personne de support doit se rendre sur un site distant, quel est le délai de réparation réel?

L'économie des racks devient une économie du risque une fois qu'une défaillance commence.

Les VPS et les 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, un stockage RAID10, un réseau redondant et des serveurs hôtes à alimentation redondante, un Internet partagé de 1 Gbit/s et des sauvegardes optionnelles. Elle répertorie des plans allant d'un petit plan de 512 Mo de RAM à des plans multicœurs plus importants. Lapage des serveurs dédiésindique que les serveurs ont des alimentations redondantes, RAID 1 ou RAID 10, des contrôleurs RAID matériels, deux contrôleurs réseau et différents commutateurs de haut de rack. Elle mentionne également une installation gratuite du système d'exploitation, une surveillance, un service d'assistance 24/7 et une intervention à distance.

Ces fonctionnalités sont significatives. Elles créent également un programme de vérification. Un client louant une capacité VPS doit demander si le 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 des images système, des données au niveau fichier, des métadonnées et l'état du panneau de contrôle. Il doit demander ce qui se passe lorsque la machine hôte tombe en panne et si la migration en direct est disponible.

Il doit demander si la contention des ressources peut limiter la récupération 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 n'aident que si chaque alimentation atteint un chemin d'alimentation indépendant. Deux contrôleurs réseau n'aident que s'ils sont câblés à des commutateurs indépendants et acheminés via une capacité de fournisseur d'accès 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'intervention à distance gratuite n'est utile que si les pièces sont en stock et que le personnel peut entrer rapidement dans l'installation.

L'écart de route public rend ces questions plus importantes. Si AS43112 n'est pas visible actuellement, le service Internet 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 tombe en panne lorsque l'opérateur tombe en panne.

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

Les pages des installations reposent fortement sur l'alimentation et la surveillance. TSBG indique que l'alimentation des centres de données est conçue dans une configuration A/B entièrement diversifiée, à partir de salles électriques, de tableaux de distribution, de systèmes UPS et de câblages séparés vers les racks. Elle indique que chaque rack a deux PDU ou plus, un pour le circuit A et un pour le circuit B. Elle 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 %.

Elle indique que la détection incendie utilise un système d'échantillonnage d'air et une suppression par gaz. Elle indique que la surveillance couvre un large éventail de paramètres environnementaux, de serveur, de port 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 celui auquel les clients en dépendent. L'alimentation A/B n'est pas prouvée par deux cordons 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 du refroidissement n'est pas prouvée par la capacité nominale si une 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 la présence de 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. L'article sur la maintenance des générateurs dieseltraite de l'huile du générateur, des filtres, du liquide de refroidissement, des batteries et de la préparation hivernale. L'article sur la surveillance de la températuretraite de SNMP, Zabbix, des capteurs one-wire, de la surveillance distribuée et de la conception des alarmes. L'article sur l'emplacement des bâtiments de centres de donnéestraite 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 télécom. Ces articles ne sont pas des certifications, mais ils montrent une familiarité avec le domaine qui est plus spécifique que le copier-coller générique de l'hébergement.

La prochaine étape du client devrait être des preuves, pas de l'admiration. Demandez la dernière date de test du générateur, la charge testée, l'autonomie en carburant, les preuves de maintenance des UPS, les preuves de maintenance du système d'incendie, le plan de réponse à une défaillance du refroidissement, un échantillon d'escalade de surveillance et des notes après 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 tombe en panne ensemble. C'est ainsi que le langage général des installations devient une assurance opérationnelle.

La résilience du réseau dépend des contrats de fournisseur d'accès, 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 enregistrements RIPE identifient AS43112, et les remarques whois RIPE mentionnent des fournisseur d'accès et des centres de données, avec un import depuis AS47964 et un export vers AS47964. Lacohérence de routage AS de RIPEstata montré 193.3.63.0/24 dans le whois RIPE mais pas dans BGP le 2026-07-12, et a montré l'import/export AS47964 dans le whois mais pas dans BGP. Lesvoisins 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 de registre: l'ASN, l'objet de route, la ROA et les relations whois montrent ce que l'opérateur est préparé ou autorisé à faire. La deuxième 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: la charge de travail d'un client peut utiliser un plan de fournisseur d'accès ou d'adressage différent non évident à partir du seul ASN TSBG. La résilience dépend de la troisième, mais le dossier public éclaire surtout 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 dans lestatut de routage de RIPEstatet avait des attachements d'échange PeeringDB à NetIX, TurkIX Sofia et RegPEX. Cela montre une surface réseau proche en direct liée à l'enregistrement de l'installation. Cela ne prouve pas que le trafic client 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, les préfixes et les fournisseur d'accès qui transporteront le service commandé. Demandez si ces chemins sont capables de défaut, s'ils utilisent des entrées physiques distinctes, 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 pour le routage 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 met à plusieurs reprises l'accent sur le support. Le site mentionne un support d'assistance 24/7, une intervention à distance, un email, une messagerie Viber et WhatsApp, une surveillance et une assistance gratuite au remplacement du matériel. Dans un service d'hébergement ou de colocation, le support n'est pas un supplément facultatif. 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 rompu. Une matrice de disques peut être protégée, mais quelqu'un doit décider s'il faut reconstruire, restaurer ou basculer.

Un client peut posséder le serveur, mais l'intervention à distance peut être le seul moyen d'appuyer sur un bouton, de réinsérer une carte ou de lire une console.

La question du support est particulièrement importante pour un petit fournisseur ayant plusieurs sites géographiquement répartis. Les propres pages de TSBG indiquent que l'équipe est petite mais efficace, et que des partenaires sélectionnés aident aux travaux 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 compte comme 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'intervention à distance a des limites de temps, et si les pièces sont stockées sur place. Ils doivent demander si un client de colocation peut autoriser des travaux à l'avance. Ils doivent demander si un client VPS obtient une aide à 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, le fournisseur d'accès, le rack ou la couche de service affectés, plutôt que de simplement décrire une panne générique.

La facturation appartient à la même catégorie. Un service peut tomber en panne en raison d'un compte désactivé, d'une durée de service expirée, 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 les contacts, la facturation, le renouvellement et l'accès hors bande restent disponibles pendant l'événement exact 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'attribution est BG, et l'histoire de TSBG est fortement bulgare. L'entreprise est constituée en Bulgarie, indique un bureau à Sofia, décrit des sites bulgares et commercialise la Bulgarie comme un emplacement stratégique de transit de télécommunications. Pour les clients ayant des besoins de connectivité européenne, balkanique, turque ou moyen-orientale, il s'agit d'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 peut placer le disque virtuel dans une installation bulgare et la sauvegarde dans une autre. Un plan d'hébergement mutualisé peut utiliser des outils cPanel, des services de certificats tiers et un DNS externe.

Un service de streaming peut ingérer le signal à partir de chemins satellites ou terrestres et le distribuer via un mélange de transit local et international. Un client de colocation peut 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 gère plusieurs centres de données en Bulgarie, que les sites sont géographiquement répartis 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 à la question de savoir si une sauvegarde spécifique franchit 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 distinct, ou comment un client reçoit une copie utilisable des données pendant un litige ou 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 les VPS, peut-il exporter une image ou seulement les 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 la renumérotation 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 mince laissent souvent des traces dans les agrégateurs commerciaux, les anciennes pages BGP, les pages de prix, les résultats de recherche, les publications de forum, les profils sociaux et les annuaires 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 de la même manière. 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 retard sur la réalité. Le site officiel fait autorité pour ce que TSBG dit vendre, mais n'est pas une preuve indépendante qu'un rack, un chemin de fibre ou une sauvegarde donnés existent aujourd'hui. Les pages d'agrégateurs sont bonnes pour la triangulation mais peuvent être en retard 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 est la plus importante lorsque les preuves publiques sont en conflit. Les pages de service officielles de TSBG indiquent à plusieurs reprises que l'entreprise gère son propre AS avec des sessions BGP. Les enregistrements RIPE identifient AS43112 et une 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 à aplanir. C'est la principale conclusion. Soit l'ASN public est actuellement inactif, 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 différentes pour le client.

Qu'est-ce qui réglerait la question? Une vue de looking-glass actuelle de TSBG, une table de routage montrant les préfixes clients, une liste de fournisseurs d'accès, une IP de test pour le service commandé, un résultat de traceroute et de diversité de chemin, une page d'état actuelle, une description de service spécifique à l'installation et un langage contractuel nommant les parties responsables. Jusqu'à ce que ceux-ci soient disponibles, la bonne posture éditoriale 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/24, et aux observations BGP publiques. Si la réponse est que l'ASN public n'est pas utilisé actuellement, 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 du rack, la conception de l'alimentation, la consommation maximale, les options d'interconnexion, les conditions d'intervention à distance, la procédure d'accès et les règles de notification de maintenance. Pour les VPS ou les serveurs dédiés, demandez quelle installation héberge le matériel, si le site de reprise est actif, si les sauvegardes sont hors 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ées de TSBGdonne 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 du réseau. Demandez les fournisseur d'accès actuels, les filtres de route, l'état RPKI, la diversité des entrées physiques, la vitesse de l'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'intervention à 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 sur le droit au support peut arrêter les travaux de reprise. Le matériel public décrit un petit opérateur compétent; le travail du client est de prouver cette capacité 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 que le client achète. Un client d'hébergement mutualisé est exposé aux défaillances au niveau de la plateforme: cPanel, DNS, messagerie, 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 de matériel, à la périphérie réseau, aux alimentations, à l'intervention à 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 une indisponibilité du site Web ou de la messagerie. Pour un opérateur télécom ou informatique utilisant de l'espace de rack, 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 média ou de streaming, une panne peut interrompre la diffusion vers le 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 général. Si un chemin de fournisseur est impliqué, TSBG peut dépendre du délai de réparation d'un autre opérateur. 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 inhabituellement opérationnel pour un petit fournisseur. La preuve manquante est l'accessibilité actuelle et le basculement testé pour le chemin client spécifique.

Le niveau de preuve

TSBG Hosting Ltd. obtient un niveau de preuve réseau Faible pour cet article. Le niveau 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 fournit de fortes revendications de service spécifiques à l'entreprise: quatre centres de données, colocation, VPS, serveurs dédiés, hébergement mutualisé, alimentation A/B, surveillance, intervention à distance, sécurité, détection incendie, refroidissement et positionnement de transit bulgare.

Les enregistrements RIPE donnent une véritable identité de ressources numériques 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 provient 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 de PeeringDB ajoute un indice physique, mais son attachement réseau visible pointe vers AS47288/FixNET plutôt qu'AS43112. Cela peut représenter un partenaire ou un arrangement de fournisseur d'accès 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 bulgare d'hébergement et de colocation avec des revendications d'infrastructure physique détaillées. Un acheteur doit traiter ces revendications comme vérifiables, pas comme 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, les limites des fournisseur d'accès et du support, des preuves de sauvegarde ou de migration testées, et une carte écrite de qui restaure le service en cas de défaillance du rack, du fournisseur d'accès, du stock de matériel, du support, de la facturation, de la migration ou du contrat de fournisseur.