Zusammenfassung

  • TSBG Hosting Ltd. präsentiert sich als bulgarischer Infrastrukturbetreiber, gegründet 2006, und bietet auf seiner eigenen Website Colocation, Cloud-Server, dedizierte Server, Shared Hosting, Streaming und verwaltete Dienste an.
  • Die stärksten unternehmenseigenen Betriebsaussagen sind physischer und nicht rein virtueller Natur: mehrere betreiberneutrale bulgarische Rechenzentrumsstandorte, vier Rechenzentren, ein nach TIA-942 ausgerichtetes Design, A/B-Stromversorgung, Überwachung, Fernwartung, Branderkennung, Kühlung und begleiteter Zugang.
  • Das aktuelle öffentliche Netzsignal ist schwach.RIPE RDAPidentifiziert AS43112 als tsbg_hosting und registriert TSBG Hosting Ltd. als Inhaber, aberRIPEstat Routing-Statuszeigte am 12.07.2026 keinen sichtbaren angekündigten IPv4- oder IPv6-Raum für AS43112.
  • Die Ressource 193.3.63.0/24 von TSBG bleibt relevant, daRIPE RDAP für das PräfixBG-TSBGHOSTING-20200902 identifiziert undRIPEstat RPKI-ValidierungAS43112 als für dieses Präfix autorisiert bestätigte. Autorisierung ist nicht dasselbe wie Live-Erreichbarkeit.
  • Der TSBG Hosting-Standorteintrag vonPeeringDBfügt einen physischen Hinweis in Haskovo/Svilengrad hinzu, währendPeeringDB net-facility-Datenden gelisteten Anschluss mit AS47288/FixNET und nicht mit AS43112 verknüpfen. Dies bestätigt die Notwendigkeit, die Betreibergrenzen zu überprüfen, bevor man sich auf irgendeine Behauptung zur Resilienz verlässt.
  • Das Beweismaß ist Niedrig. Die offizielle Website liefert umfangreiche Servicebehauptungen, aber die aktuellen öffentlichen Routing-Nachweise belegen nicht unabhängig einen aktiven AS43112-Kundenverkehr, Multi-Site-Failover, Transit-Diversität, Reservekapazität oder Datenportabilität.

Eine Cloud-Rechnung landet immer noch in einem bulgarischen Maschinenraum

TSBG Hosting Ltd. ist kein Name, der durch Markenbekanntheit bewertet werden kann. Er muss bewertet werden, indem der Dienst bis zur Ausrüstung und den Personen zurückverfolgt wird, die einen Kunden online halten würden. Das Unternehmen verkauft Dienste, die elastisch erscheinen: Cloud-Server, VPS-Pläne, dedizierte Server, Shared Hosting, Streaming, Colocation und verwalteter Support. Aber jeder dieser Dienste hat eine physische Bestandsinventur dahinter. Ein virtueller Server benötigt Host-Kapazität, Speicher, Switching, Strom und Kühlung. Ein dedizierter Server benötigt ein spezifisches Chassis und einen Austauschplan.

Colocation benötigt ein Rack, ein Leistungsbudget, Kabelwege, Zugangskontrolle und Fernwartung. Streaming benötigt Erfassungs-, Transkodierungs- oder Weiterleitungskapazität und ausreichende ausgehende Bandbreite, um das Publikum bei steigender Nachfrage zu unterstützen.

Die nützliche Tatsache über TSBG ist, dass sich das Unternehmen nicht nur in vager Cloud-Sprache beschreibt. Dieoffizielle Homepagevermarktet Colocation, dedizierte Server, virtuelle Server, Streaming und Satellitenantennen-Colocation. Dieselbe Seite beschreibt vier betreiberneutrale Rechenzentren und sechzehn Jahre Erfahrung und gibt an, dass TSBG Private Cloud, Disaster-Recovery-Standorte, dedizierten Internetzugang, IPv4-Adressen, Gleichstromversorgung und Satellitenempfang unterstützen kann. Diese Behauptungen geben dem Käufer eine konkrete Checkliste zum Testen: Gebäude, Racks, Strombereiche, Glasfasern, Zugangsanbieter, Server, Adressressourcen und Support-Vereinbarungen.

Das Risiko besteht darin, dass die öffentlichen Marketingdetails dennoch vor den verifizierbaren Betriebsnachweisen hinterherhinken können. Ein Anbieter kann Racks besitzen, aber einige Netzwerkpfade auslagern. Er kann eine gültige ASN haben, sie aber derzeit nicht ankündigen. Er kann ein Dienstmenü veröffentlichen, während einzelne Pläne von verfügbarem Bestand, Lieferantensupport oder einer Drittanbieter-Einrichtung abhängen. Er kann einen Wiederherstellungsstandort anbieten, während der Kundenvertrag die Wiederherstellungsziele vage lässt.

Bei TSBG enthält die öffentliche Akte genau diese Mischung: eine spezifische Dienstgeschichte, eine spezifische bulgarische Identität, eine spezifische AS-Nummer und eine Diskrepanz zwischen der Registrierung digitaler Ressourcen und der sichtbaren Routenankündigung zum Veröffentlichungsdatum.

Diese Diskrepanz macht TSBG nicht unzuverlässig. Sie verändert die Beweislast. Ein Kunde sollte die Online-Preisliste oder die ASN nicht als Zusicherungsbericht betrachten. Der Kunde muss fragen, welche Einrichtung die Arbeitslast hostet, welcher Netzwerkrand den Dienst ankündigt, welcher Anbieter über einen ausfallfähigen Transit verfügt, wie viel Reserveleistung und Hardware reserviert sind und wie die Daten die Plattform verlassen, wenn der Dienst verlagert werden muss.

Was mit Vertrauen identifiziert werden kann

Die Identität des Unternehmens ist solider, als es der erste Verzeichnis-Schnappschuss vermuten ließ. Die Website von TSBG gibt an, dass das Unternehmen 2006 gegründet wurde, nach bulgarischem Recht eingetragen ist, die Mehrwertsteuernummer BG175059953 angibt, Ivan Shishkov als Geschäftsführer nennt und eine Büroadresse in Sofia, Racho Dimchev Straße 8, angibt. DieKontaktseitewiederholt die Sofioter Adresse, Telefonnummer und Geschäfts-E-Mail.RIPE RDAP für AS43112identifiziert den Objektnamen als tsbg_hosting und enthält TSBG Hosting Ltd. als Organisationseinheit mit einer Adresse in Sofia. DieWHOIS-Daten von RIPEstatregistrieren aut-num 43112, as-name tsbg_hosting, organization ORG-THL32-RIPE, status ASSIGNED und maintainer mnt-bg-tsbghosting-1.

Diese Registrierungen reichen aus, um einen häufigen Fehler bei der Hosting-Recherche zu vermeiden: einen Dienstnamen als schwebendes Etikett ohne verantwortlichen Inhaber zu behandeln. Hier kann der Inhaber mit einer bulgarischen Unternehmensidentität, einer Kontaktfläche, einer digitalen Ressourcenregistrierung und einer sichtbaren Dienstwebsite verknüpft werden. Das ist nützlicher als eine Reseller-Seite ohne Adresse und Routing-Registrierung.

Der Dienstumfang ist ebenfalls spezifisch. DieColocation-Seite von TSBGbewirbt Pakete von einer Rack-Einheit, einem Viertel-Rack, einem halben Rack und einem ganzen Rack, mit angegebenen Leistungen von 35 W für eine Rack-Einheit bis 1500 W für ein ganzes Rack. Die Seite gibt auch an, dass das Unternehmen Internetkonnektivität, IPv4-Adressen und LIR-Dienste bereitstellen kann. DieCloud-Server-Seitelistet VPS-Pläne, SSD-Speicher, RAID10-Schutz, gemeinsamen 1-Gbit/s-Internetanschluss und optionale Backups auf. DieSeite für dedizierte Serverbeschreibt redundante Netzteile, RAID 1 oder RAID 10, zwei Netzwerkcontroller und Redundanz der Top-of-Rack-Switches. DieHosting-Seiteumfasst Shared Hosting und VPS-Hosting, einschließlich Migrationshilfe.

Diese Mischung deutet auf einen Anbieter hin, der Infrastruktur auf mehreren Abstraktionsebenen verkauft. Kunden können einen Anteil einer gemeinsam genutzten Plattform, eine virtuelle Maschine, einen physischen Server, Rack-Platz, Konnektivität oder Support mieten. Das wirtschaftliche Problem ist, dass Produkte höherer Ebene die Einschränkungen der niedrigeren Ebenen erben. Wenn das Rack den Strom verliert, sind die an diesem Standort angeschlossenen dedizierten Server- und VPS-Pläne betroffen.

Wenn der Netzwerkrand einen Anbieter verliert oder ein Routenobjekt zurückgezogen wird, kann ein scheinbar separater Hosting-Plan gleichzeitig mit dem Colocation-Dienst ausfallen. Wenn der Support von demselben kleinen Team verwaltet wird, das auch den Hardware-Austausch durchführt, kann ein belasteter Vorfall ein Versprechen von „kostenloser Fernwartung“ in eine Warteschlange verwandeln.

Die digitale Ressourcenregistrierung ist aktiv, aber der öffentliche Rand war still

Die wichtigste Netztatsache ist nicht schmeichelhaft, aber genau. DerAS-Überblick von RIPEstat für AS43112identifizierte den Inhaber als tsbg_hosting TSBG Hosting Ltd., markierte die ASN jedoch für die Abfrage vom 12.07.2026 als nicht angekündigt. DerRouting-Status von RIPEstatmeldete, dass die erste gesehene Route 77.246.240.0/20 am 14.06.2007 und die letzte gesehene Route 193.3.63.0/24 am 15.08.2025 war, während die aktuelle Sichtbarkeit bei null von 325 IPv4-Peers und null von 322 IPv6-Peers lag. Dieangekündigten Präfixe von RIPEstatgaben für den Zeitraum 28.06.2026 bis 12.07.2026 keine aktuellen Präfixe für AS43112 zurück.

Das löscht die Servicebehauptungen von TSBG nicht aus. Es deutet auf etwas Engeres hin: Die öffentlichen Routensammler haben AS43112 zum Veröffentlichungsdatum nicht dabei gesehen, live angekündigten Raum zu transportieren. Ein Kunde kann AS43112 allein nicht als Nachweis für aktuellen Internetdienst, Transit-Diversität oder Kundenverkehr verwenden. Wenn die aktuellen Dienste über eine andere ASN, einen vom Betreiber zugewiesenen Adressblock, ein Anbieternetzwerk, eine private Zusammenschaltung oder eine verwaltete Uplink-Vereinbarung bereitgestellt werden, muss dies angegeben und direkt getestet werden.

Der inaktive öffentliche Rand ändert auch, wie ältere Beweise zu lesen sind. DerRouting-Verlauf von RIPEstatzeigt eine lange historische Aktivität für 77.246.240.0/20, 77.246.240.0/21 und 193.3.63.0/24, wobei die Route 193.3.63.0/24 von 2022 bis 2025 weitgehend sichtbar war, bevor sie nach Mitte August 2025 auf minimale Sichtbarkeit fiel. Der Verlauf ist nützlich für Identität und Kontinuität. Es ist keine aktuelle Kapazität. Wenn dieselben Kunden immer noch bedient werden, könnten sie jetzt über ein anderes Netzwerkdesign bedient werden. Wenn das Präfix zurückgezogen wurde, weil Dienste verlagert wurden, ist der Migrationspfad wichtig. Wenn es zurückgezogen wurde, weil der Dienst eingestellt wurde, muss ein Käufer das wissen, bevor er Kapazität bestellt.

RPKI fügt eine weitere Nuance hinzu. DieRPKI-Validierung von RIPEstat für 193.3.63.0/24 und AS43112gab gültig zurück. Dies ist ein positiver administrativer Nachweis: AS43112 ist berechtigt, das Präfix zu ursprüngen. Aber eine gültige Routenursprungsberechtigung ist nicht dasselbe wie eine Ankündigung. Ein Rauchmelder kann in einem derzeit leeren Raum installiert sein; eine ROA kann für eine Route existieren, die in BGP nicht sichtbar ist. Das Recht der Kontrollebene besteht, während der Betriebspfad noch live bestätigt werden muss.

Die Website behauptet solide Einrichtungen, aber die Karte ist unvollständig

Die stärkste öffentliche Geschichte von TSBG ist die seiner physischen Einrichtungen. DieSeite zur Geschichte der Rechenzentrengibt an, dass das Unternehmen 2006 gegründet wurde, im September 2006 sein erstes Rechenzentrum fertigstellte, im Juli 2007 ein zweites Colocation-Projekt abschloss, im Juli 2008 ein drittes Rechenzentrum als Disaster-Recovery-Standort mit erster installierter Ausrüstung fertigstellte und im Oktober 2008 ein viertes Rechenzentrum abschloss. Sie gibt auch an, dass sich TSBG seit 2014 auf Colocation, Hosting, Serververmietung und verwaltete Dienste konzentriert.

DieSeite zu unseren Rechenzentrenführt die Standortbehauptung weiter aus. Sie gibt an, dass die Standorte von TSBG gemäß TIA-942 entworfen sind, die Standorte sorgfältig ausgewählt werden, das Unternehmen eine 100%ige Stromverfügbarkeit garantiert, die Stromversorgung in einer vollständig diversifizierten A/B-Konfiguration ausgelegt ist, die Kühlung in Nennkapazität redundant ist und die physische Sicherheit bewachte Standorte, Videoüberwachung und begleiteten Zugang umfasst. Sie gibt an, dass die Überwachung Serverlast, Speicher, Festplatten, Portverkehr, Gerätezustand, Temperatur, Luftfeuchtigkeit, elektrischen Strom, Energieverbrauch, Klimatisierung und optische Netzwerkleistung abdeckt.

Das sind ernsthafte Behauptungen. Sie erfordern auch, dass ein Käufer standortspezifische Nachweise anfordert. „Vier Rechenzentren“ ist nur dann ein nützlicher Ausgangspunkt, wenn der Kunde identifizieren kann, welches der vier seine Arbeitslast hosten wird, ob der Wiederherstellungsstandort aktiv oder im Standby ist, ob die Standorte denselben Zugangsanbieter teilen, ob sich der Backupspeicher in einer separaten Fehlerdomäne befindet und welches vertragliche Wiederherstellungsziel gilt, wenn ein Standort isoliert ist. Die öffentlichen Seiten beschreiben Prinzipien und Fähigkeiten.

Sie nennen nicht jedes Gebäude, jede Stromversorgung, jeden Kraftstoffvertrag, jedes Betreibertreffen, jedes Ersatzteilinventar oder jedes getestete Wiederherstellungsergebnis.

Die geografische Behauptung erfordert ebenfalls eine sorgfältige Handhabung. TSBG sagt, dass seine Gebäude in Bulgarien liegen und geografisch verteilt sind, mehr als 150 km voneinander entfernt, in Gebieten, die ausgewählt wurden, um Überschwemmungs-, Brand-, Verkehrs-, Industrie- und menschliche Aktivitätsrisiken zu reduzieren. SeinBlogbeitrag von 2023 über Bulgarien als Rechenzentrumsstandortgibt an, dass Bulgarien an wichtigen Routen zwischen Europa, der Türkei und dem Nahen Osten liegt und TSBG geschützte Layer-2- und IP-Verbindungen über diverse Routen nach Istanbul, Sofia, Bukarest und in europäische Netze bereitstellen kann. Dies ist eine wertvolle regionale These, insbesondere für Kunden mit Latenzanforderungen in Bezug auf den Balkan, die Türkei oder Europa-Naher Osten. Aber der Standortvorteil ersetzt nicht den Live-Pfadnachweis. Ein guter Korridor benötigt immer noch vertraglich gebundene Betreiber, diverse Leitungswege, funktionierende Zusammenschaltungen und ausreichende Kapazität nach einem Link-Ausfall.

PeeringDB fügt einen Hinweis auf Haskovo und eine Warnung zu Betreibergrenzen hinzu

PeeringDB gibt der Einrichtungsgeschichte einen separaten öffentlichen Hinweis.Die PeeringDB-Standort-API für Standort 13672listet „TSBG Hosting“ in Haskovo, Bulgarien, mit der Adresse1 „Byalo More 3 Kapitan Andreevo“, dem Bundesland Svilengrad, dem Land BG, einem Website-Feldtsbg.eu, Geschäfts- und technischen Telefonnummern und E-Mails sowie einem verfügbaren Spannungsdienst 480 VAC. Der Eintrag wurde am 19.05.2023 erstellt und am 26.09.2025 aktualisiert. Dies ist nützlich, weil es außerhalb der eigenen Website von TSBG liegt und auf eine bestimmte benannte Standortfläche in Südbulgarien verweist, nahe dem von der TSBG-Website hervorgehobenen Grenzkontext Türkei-Griechenland.

Aber dieselben PeeringDB-Daten erzeugen ein Grenzproblem. DiePeeringDB netfac-Daten für Standort 13672zeigen einen Eintrag eines angeschlossenen Netzwerks namens TSBG Hosting in Haskovo mit der lokalen ASN 47288. DasPeeringDB-Netzwerk 26850identifiziert dieses Netzwerk als FIXNET TELEKOM LTD. STI., ASN 47288, mit einer Verkehrsreichweite Europa, einer offenen Peering-Richtlinie, sieben Standorten und drei Exchange-Anschlüssen. DerAS-Überblick von RIPEstat für AS47288identifiziert den Inhaber als FIXNET Telekomunikasyon Limited Sirketi und markiert die ASN als angekündigt. DerRouting-Status von RIPEstat für AS47288sah am 12.07.2026 aktive IPv4- und IPv6-Sichtbarkeit, mit 18 IPv4-Präfixen und einem IPv6-Präfix im angekündigten Raum auf der Routing-Status-Ebene.

Das beweist nicht, dass FixNET die Kundendienste von TSBG betreibt. Es beweist, dass der öffentliche PeeringDB-Standortanschluss nicht leichtfertig als AS43112-Präsenz gelesen werden sollte. Für einen Käufer ist diese Unterscheidung zentral. Wenn TSBG Colocation in einer Einrichtung verkauft, in der die ASN eines anderen Betreibers der sichtbare Netzwerkanschluss ist, muss der Vertrag erklären, ob TSBG, FixNET, ein anderer Betreiber oder der Kunde den Standard-Internetzugang bereitstellt.

Wenn TSBG VPS oder dedizierte Server unter Verwendung von Zugangsanbieter-Konnektivität anstelle seiner eigenen sichtbaren AS43112-Route verkauft, muss der Kunde wissen, wer das Routing ändern kann, wer die Tickets des Zugangsanbieters öffnet und wessen Wartungsplan die Erreichbarkeit beeinflusst.

Die Frage der Betreibergrenzen ist nicht akademisch. Während eines Vorfalls kann der Ersthelfer der TSBG-Support, der Eigentümer der Einrichtung, ein Betreiber, ein Fernwartungsanbieter oder der Netzwerkanbieter sein. Der Kunde benötigt die Eskalationskette vor dem Ausfall. Ein Standorteintrag, der TSBG nennt, und ein Netzwerkeintrag, der AS47288 nennt, können beide wahr sein, während der Kunde exponiert bleibt, wenn der Dienstvertrag die Rollen nicht klar definiert.

Die Ökonomie der Racks bestimmt die Dienstrealität

TSBG veröffentlicht ungewöhnlich granulare Colocation-Preise und Rack-Pakete. DieColocation-Dienstseitelistet eine Rack-Einheit, ein Viertel-Rack, ein halbes Rack und ein ganzes Rack auf, mit Leistungszuteilungen und optionalen Rack-Funktionen. Die Seite gibt auch an, dass TSBG optional 48 VDC standardmäßig, A/B-Stromversorgung aus separaten Elektroräumen und USV-Systemen, Leistungsmesser und ATS-Schalter auf Anfrage, Überwachung, 24/7-Support und Internetzugang bereitstellen kann. Dies gibt Kunden einen sichtbaren Warenkorb für einen Einrichtungsdienst, der normalerweise hinter Vertriebsgesprächen verborgen ist.

Die Gefahr besteht darin, dass der sichtbare Rack-Preis nicht dasselbe ist wie die nutzbare resiliente Kapazität. Eine einzelne Rack-Einheit mit 35 W ist eine ganz andere Abhängigkeit als ein ganzes Rack mit 1500 W. Ein Kunde, der Telekommunikationsausrüstung betreibt, benötigt möglicherweise Gleichstromversorgung, doppelte PDU und Fernzugriff; ein Kunde, der Rechenleistung ausführt, benötigt möglicherweise mehr Strom, Kühlung und Hardware-Austausch.

Eine Preisliste kann nicht zeigen, ob Reserveleistung reserviert ist, ob die Zusammenschaltungsarbeit schnell ist, ob die Fernwartung ein Gerät während eines regionalen Sturms austauschen kann oder ob der verbleibende Netzwerkpfad den Verkehr transportieren kann, wenn ein Anbieter ausfällt.

Die Ökonomie der kleinen Anbieter ist hier wichtig. TSBG sagt offen auf seiner Website, dass es nicht der größte Rechenzentrumsbetreiber ist und nicht über Megawatt Leistung oder Terabit pro Sekunde Internetkapazität verfügt. Diese Ehrlichkeit ist nützlich. Sie sagt Käufern, dass sie nach Passgenauigkeit suchen sollen, nicht nach der Show der Größe. Ein kleiner Standort kann perfekt für ein lokales Unternehmen, ein Telekommunikationsprojekt an der Grenzroute, einen Disaster-Recovery-Schrank oder einen balkanischen Dienst mit niedriger Latenz geeignet sein.

Er kann auch ungeeignet für eine Arbeitslast sein, die groß angelegte Reservepools, globale Cloud-APIs oder sofortigen Hardware-Austausch voraussetzt.

Der Käufer muss daher die Paketbezeichnungen in Ausfallberechnungen übersetzen. Wenn eine Rack-Stromversorgung ausfällt, verfügt die Kundenausrüstung über doppelte Netzteile und doppelte PDU? Wenn ein Top-of-Rack-Switch ausfällt, sind beide Server-NICs an unabhängige Switches angeschlossen? Wenn ein Zugangsanbieter ausfällt, hat der andere Pfad eine ausreichende bezahlte Verpflichtung? Wenn ein Rechenzentrum verloren geht, sind die Backups ohne den verlorenen Standort nutzbar? Wenn eine Support-Person zu einem entfernten Standort reisen muss, wie hoch ist die tatsächliche Reparaturzeit?

Die Ökonomie der Racks wird zur Ökonomie des Risikos, sobald ein Ausfall beginnt.

VPS und dedizierte Server erben jede niedrigere Schicht

Die VPS- und dedizierten Server-Seiten von TSBG sind detailliert genug, um zu zeigen, woher der Kundenwert kommt. DieCloud-Server-Seitegibt an, dass VPS-Pläne auf Proxmox basieren, redundante Hardware, RAID10-Speicher, redundantes Netzwerk und redundante Stromversorgung der Host-Server, gemeinsamen 1-Gbit/s-Internetanschluss und optionale Backups verwenden. Sie listet Pläne von einem kleinen Plan mit 512 MB RAM bis zu größeren Multi-Core-Plänen auf. DieSeite für dedizierte Servergibt an, dass die Server über redundante Netzteile, RAID 1 oder RAID 10, Hardware-RAID-Controller, zwei Netzwerkcontroller und verschiedene Top-of-Rack-Switches verfügen. Sie erwähnt auch kostenlose Betriebssysteminstallation, Überwachung, 24/7-Helpdesk-Service und Fernwartung.

Diese Funktionen sind bedeutsam. Sie erstellen auch ein Überprüfungsprogramm. Ein Kunde, der VPS-Kapazität mietet, muss fragen, ob RAID10 lokal auf einem Host, gemeinsam auf einem Speichercluster, auf einen anderen Standort repliziert oder out-of-band gesichert ist. Er muss fragen, ob das optionale Backup in derselben Einrichtung gespeichert ist, ob die Wiederherstellungsgeschwindigkeit gemessen wird und ob die Backups Systemabbilder, dateibasierte Daten, Metadaten und den Status des Bedienfelds enthalten. Er muss fragen, was passiert, wenn der Host ausfällt und ob Live-Migration verfügbar ist.

Er muss fragen, ob Ressourcenkonflikte die Wiederherstellung einschränken können, wenn viele Kunden gleichzeitig betroffen sind.

Ein Kunde eines dedizierten Servers hat ein anderes Problem. Redundante Netzteile helfen nur, wenn jedes Netzteil einen unabhängigen Strompfad erreicht. Zwei Netzwerkcontroller helfen nur, wenn sie an unabhängige Switches angeschlossen sind und über unabhängige Zugangsanbieterkapazität geroutet werden. RAID schützt vor einem Festplattenausfall, aber nicht vor einem Controller-Fehler, fehlerhafter Wiederherstellung, Ransomware oder einem standortweiten Ereignis. Kostenlose Fernwartung ist nur nützlich, wenn Teile auf Lager sind und das Personal schnell die Einrichtung betreten kann.

Die öffentliche Routenlücke macht diese Fragen noch wichtiger. Wenn AS43112 derzeit nicht sichtbar ist, kann der Internetdienst des Kunden von TSBG von zugewiesenen Anbieterrouten, einem Transitpartner, einer anderen ASN oder einem privaten Design abhängen, das in öffentlichen Sammlern nicht sichtbar ist. Diese Vereinbarung kann vollkommen legitim sein. Sie muss lediglich dem Kunden offengelegt werden, der einen „Internetzugang“ im Rahmen eines Serverplans kauft. Der Kunde muss wissen, welcher Rand ausfällt, wenn der Betreiber ausfällt.

Behauptungen zu Strom, Kühlung und Überwachung erfordern getestete Nachweise

Die Seiten der Einrichtungen stützen sich stark auf Strom und Überwachung. TSBG gibt an, dass die Stromversorgung der Rechenzentren in einer vollständig diversifizierten A/B-Konfiguration ausgelegt ist, aus separaten Elektroräumen, Verteilertafeln, USV-Systemen und Verkabelungen zu den Racks. Sie gibt an, dass jedes Rack zwei oder mehr PDU hat, eine für Schaltkreis A und eine für Schaltkreis B. Sie gibt an, dass die Klimatisierung eine redundante 1+1- oder n+1-Konfiguration verwendet und die Geräteräume bei etwa 22 Grad C mit einer relativen Luftfeuchtigkeit zwischen 40% und 60% gehalten werden.

Sie gibt an, dass die Branderkennung ein Luftprobenahmesystem und Gaslöschung verwendet. Sie gibt an, dass die Überwachung eine breite Palette von Umwelt-, Server-, Port- und optischen Netzwerkparametern abdeckt.

Das sind genau die richtigen Bereiche, die veröffentlicht werden sollten. Die Frage ist, ob die Behauptungen auf dem gleichen Niveau getestet werden, auf das sich die Kunden verlassen. A/B-Strom wird nicht durch zwei Kabel bewiesen, wenn beide Stromkreise von einer einzelnen vorgelagerten Tafel, einer einzelnen Kraftstoffvereinbarung oder einem einzelnen Wartungsanbieter abhängen. Kühlungsredundanz wird nicht durch Nennkapazität bewiesen, wenn ein heißer Gang, ein Sensorausfall oder eine Luftstromänderung den Spielraum aufheben kann.

Überwachung wird nicht durch das Vorhandensein von Sensoren bewiesen, wenn die Alarmverantwortung, Schwellenwerte und Notfallbefugnisse unklar sind.

Der Blog-Inhalt von TSBG gibt nützliche Hinweise auf die betriebliche Ernsthaftigkeit. DerArtikel zur Dieselgeneratorwartungbehandelt Generatoröl, Filter, Kühlmittel, Batterien und Wintervorbereitung. DerArtikel zur Temperaturüberwachungbehandelt SNMP, Zabbix, One-Wire-Sensoren, verteilte Überwachung und Alarmdesign. DerArtikel zur Standortwahl von Rechenzentrumsgebäudenbehandelt Standortauswahl, Katastrophenrisiken, Betonbau, Dachdesign und Telekommunikationszugang. Diese Artikel sind keine Zertifizierungen, aber sie zeigen eine Vertrautheit mit dem Bereich, die spezifischer ist als generisches Hosting-Copy-Paste.

Der nächste Schritt des Kunden sollte Beweise sein, nicht Bewunderung. Fragen Sie nach dem letzten Generator-Testdatum, der getesteten Last, der Kraftstoffautonomie, den USV-Wartungsnachweisen, den Wartungsnachweisen der Brandmeldeanlage, dem Reaktionsplan bei Kühlungsausfall, einem Beispiel für eine Überwachungseskalation und den Nachbereitungsnotizen zu tatsächlichen Vorfällen. Fragen Sie, ob alle vier Standorte den gleichen Reifegrad haben. Fragen Sie, welcher Standort den spezifischen Kundendienst hostet. Fragen Sie, was zusammen ausfällt. So wird die allgemeine Einrichtungssprache zu einer betrieblichen Zusicherung.

Netzwerkresilienz hängt von Zugangsanbieterverträgen ab, nicht nur von einer ASN

Die eigenen Seiten von TSBG geben an, dass das Unternehmen sein eigenes autonomes System betreibt und BGP-Sitzungen mit sorgfältig ausgewählten Anbietern unterhält. Die RIPE-Registrierungen identifizieren AS43112, und die RIPE-WHOIS-Bemerkungen erwähnen Zugangsanbieter und Rechenzentren, mit Import von AS47964 und Export zu AS47964. DieAS-Routing-Konsistenz von RIPEstatzeigte 193.3.63.0/24 im RIPE-WHOIS, aber nicht in BGP am 12.07.2026, und zeigte Import/Export AS47964 im WHOIS, aber nicht in BGP. DieASN-Nachbarn von RIPEstat für AS43112zeigten zum Veröffentlichungsdatum keine beobachteten Nachbarn.

Diese Kombination sagt einem Käufer, drei Dinge zu trennen. Das erste ist die Registrierungsabsicht: die ASN, das Routenobjekt, die ROA und die WHOIS-Beziehungen zeigen, was der Betreiber vorbereitet oder berechtigt ist zu tun. Das zweite ist das Live-Routing: Die öffentlichen Sammler zeigen, ob die Route derzeit sichtbar ist und von wem. Das dritte ist das Dienst-Routing: Die Arbeitslast eines Kunden kann einen anderen Zugangsanbieter- oder Adressierungsplan verwenden, der aus der TSBG-ASN allein nicht ersichtlich ist. Die Resilienz hängt vom dritten ab, aber die öffentliche Akte beleuchtet hauptsächlich die ersten beiden.

Der PeeringDB-AS47288-Nachweis ist ebenfalls nützlich, ohne überinterpretiert zu werden. FixNET, das AS47288-Netzwerk, das mit dem TSBG-Hosting-Standorteintrag verbunden ist, warim Routing-Status von RIPEstataktiv und hatte PeeringDB-Exchange-Anschlüsse bei NetIX, TurkIX Sofia und RegPEX. Dies zeigt eine nahegelegene Live-Netzwerkoberfläche, die mit dem Standorteintrag verbunden ist. Es beweist nicht, dass der TSBG-Kundenverkehr diese Oberfläche nutzt, dass TSBG sie kontrolliert oder dass sie für einen bestimmten Kunden ausreichend diversifiziert ist.

Der Kundentest ist einfach. Fragen Sie TSBG, welche ASNs, Präfixe und Zugangsanbieter den bestellten Dienst transportieren werden. Fragen Sie, ob diese Pfade ausfallfähig sind, ob sie separate physische Eingänge verwenden, ob sie im selben Router-Paar enden, ob die Routenfilter aktuell sind und ob die Routenursprungsvalidierung konfiguriert ist. Vergleichen Sie die Antwort mit öffentlichen Tools wieBGP.tools für AS43112,Hurricane Electric für AS43112,Cloudflare Radar für AS43112-Routingund RIPEstat. Wenn die öffentliche ASN absichtlich still ist, ist das nur akzeptabel, wenn der Live-Dienstpfad dokumentiert ist.

Support ist Teil des Vermögenswerts, keine Hilfeseite

TSBG betont mehrfach den Support. Die Website erwähnt 24/7-Helpdesk-Support, Fernwartung, E-Mail, Viber- und WhatsApp-Nachrichten, Überwachung und kostenlosen Hardware-Austausch-Support. In einem Hosting- oder Colocation-Dienst ist Support kein optionales Extra. Es ist der Kanal, durch den unsichtbare Abhängigkeiten zu Reparaturaktionen werden. Ein Router kann redundant sein, aber jemand muss immer noch identifizieren, welcher Pfad unterbrochen ist. Ein Festplatten-Array kann geschützt sein, aber jemand muss entscheiden, ob neu aufgebaut, wiederhergestellt oder umgeschaltet wird.

Ein Kunde kann den Server besitzen, aber die Fernwartung kann der einzige Weg sein, einen Knopf zu drücken, eine Karte wieder einzusetzen oder eine Konsole zu lesen.

Die Support-Frage ist besonders wichtig für einen kleinen Anbieter mit mehreren geografisch verteilten Standorten. Die eigenen Seiten von TSBG geben an, dass das Team klein, aber effizient ist und ausgewählte Partner bei notwendigen Arbeiten und Wartungen helfen. Dies kann eine Stärke sein, wenn der Kunde direkte flexible Aufmerksamkeit benötigt. Es kann zu einer Schwäche werden, wenn ein Vorfall mehrere Kunden betrifft, ein Standort physischen Zugang erfordert und dieselben Personen die Überwachung, Kommunikation, Hardware und Lieferanteneskalation verwalten.

Kunden sollten daher den Support als Infrastruktur vertraglich vereinbaren. Sie sollten fragen, was als Notfall gilt, wer einen ausrufen kann, welcher Antwortkanal funktioniert, wenn das Portal ausfällt, ob Telefon- oder Messaging-Eskalation garantiert ist, ob die Fernwartung zeitliche Grenzen hat und ob Teile vor Ort gelagert werden. Sie sollten fragen, ob ein Colocation-Kunde Arbeiten im Voraus autorisieren kann. Sie sollten fragen, ob ein VPS-Kunde Wiederherstellungshilfe bei einem Plattformvorfall oder nur Best-Effort-Support erhält.

Sie sollten fragen, ob die Support-Aufzeichnung den Standort, den Zugangsanbieter, das Rack oder die betroffene Dienstschicht nennt, anstatt nur einen generischen Ausfall zu beschreiben.

Die Abrechnung gehört in dieselbe Kategorie. Ein Dienst kann aufgrund eines deaktivierten Kontos, abgelaufener Dienstzeit, eines gesperrten Bedienfelds oder unklarer Verantwortung für zusätzlichen Datenverkehr ausfallen. Ein Kunde, der TSBG für einen kleinen Disaster-Recovery-Standort nutzt, muss sicherstellen, dass Kontakte, Abrechnung, Verlängerung und Out-of-Band-Zugriff während des genauen Ereignisses verfügbar bleiben, das den Wiederherstellungsstandort erforderlich macht.

Datenlokalisierung wird nicht durch ein bulgarisches Etikett gelöst

Die Zuweisungsregion ist BG, und die Geschichte von TSBG ist stark bulgarisch. Das Unternehmen ist in Bulgarien eingetragen, gibt ein Büro in Sofia an, beschreibt bulgarische Standorte und vermarktet Bulgarien als strategischen Telekommunikations-Transitstandort. Für Kunden mit Anforderungen an europäische, balkanische, türkische oder nahöstliche Konnektivität ist dies eine bedeutende Positionierungsbehauptung. Dies kann die Latenz reduzieren, die Ausrüstung unter einer bulgarischen Anbieterbeziehung halten und eine Alternative zu den großen westeuropäischen Cloud-Regionen bieten.

Aber Datensouveränität ist nicht nur ein Länderkürzel. Ein Kunde muss identifizieren, wo die Primärdaten, Backups, Protokolle, Bedienfeldaufzeichnungen, Support-Tickets, Überwachungsdaten und Abrechnungsaufzeichnungen gespeichert sind. Ein VPS-Plan kann die virtuelle Festplatte in einer bulgarischen Einrichtung und das Backup in einer anderen platzieren. Ein Shared-Hosting-Plan kann cPanel-Tools, Drittanbieter-Zertifikatsdienste und externes DNS verwenden. Ein Streaming-Dienst kann das Signal über Satelliten- oder terrestrische Pfade erfassen und über eine Mischung aus lokalem und internationalem Transit verteilen.

Ein Colocation-Kunde kann die Hardware besitzen, aber für Fernzugriff und IP-Dienst von TSBG abhängig sein.

Die öffentlichen Seiten von TSBG veröffentlichen keine vollständige Platzierungsmatrix. Sie geben an, dass das Unternehmen mehrere Rechenzentren in Bulgarien betreibt, die Standorte geografisch verteilt sind und es geschützte Verbindungen nach Istanbul, Sofia, Bukarest und in europäische Netze bereitstellen kann. Dies sind gute Ausgangstatsachen. Sie beantworten nicht die Frage, ob ein bestimmtes Backup Grenzen überschreitet, ob ein Support-Anbieter auf Kundensysteme zugreifen kann, ob Protokolle in einem separaten System aufbewahrt werden oder wie ein Kunde während eines Streits oder Ausfalls eine nutzbare Kopie der Daten erhält.

Datenportabilität ist daher Teil der Resilienzprüfung. Ein Käufer sollte testen, wie man geht. Für Shared Hosting: Kann der Kunde Dateien, Mailboxen, DNS-Einträge, Datenbanken und TLS-Zertifikate sauber abrufen? Für VPS: Kann er ein Image oder nur Dateien exportieren? Für dedizierte Server: Ist der Fernkonsolenzugriff verfügbar, wenn das Netzwerk instabil ist? Für Colocation: Wer kontrolliert die IP-Nummerierung, die Freigabe von Zusammenschaltungen und den Abtransport der Hardware? Der beste Zeitpunkt, um die Portabilität zu testen, ist, bevor der Dienst kritisch wird.

Nicht-offizielle Signale können Hinweise liefern, keine Schlussfolgerungen

Schlanke Infrastrukturthemen hinterlassen oft Spuren in kommerziellen Aggregatoren, alten BGP-Seiten, Preisvergleichsseiten, Suchergebnissen, Forenbeiträgen, sozialen Profilen und Standortverzeichnissen. TSBG ist keine Ausnahme. Öffentliche Routing-Aggregatoren wiedie IPinfo-Seite für AS43112,BGP.tools,Hurricane ElectricundCloudflare Radarsind nützlich für einen schnellen Abgleich. PeeringDB ist nützlich für Standort- und Zusammenschaltungshinweise. Die offizielle Website ist nützlich für Servicebehauptungen und Kontaktinformationen.

Diese Signale sollten nicht gleich behandelt werden. RIPE RDAP und RIPEstat sind solide für die Identität digitaler Ressourcen und die Beobachtung öffentlicher Routen. PeeringDB ist wertvoll, aber selbst gepflegt und kann der Realität hinterherhinken. Die offizielle Website ist autoritativ dafür, was TSBG zu verkaufen angibt, aber kein unabhängiger Nachweis dafür, dass ein bestimmtes Rack, ein Glasfaserpfad oder ein Backup heute existiert. Aggregator-Seiten eignen sich gut zur Triangulation, können aber veraltet sein oder Daten unterschiedlich darstellen. Blogbeiträge zeigen technisches Denken, kein Live-Betriebszertifikat.

Die Unterscheidung ist am wichtigsten, wenn öffentliche Beweise in Konflikt stehen. Die offiziellen Dienstseiten von TSBG geben wiederholt an, dass das Unternehmen sein eigenes AS mit BGP-Sitzungen betreibt. Die RIPE-Registrierungen identifizieren AS43112 und es existiert eine gültige ROA für 193.3.63.0/24. Dennoch hat RIPEstat AS43112 zum Veröffentlichungsdatum nicht als angekündigt gesehen. Dies ist nicht etwas, das man glattbügeln sollte. Es ist die wichtigste Erkenntnis.

Entweder ist die öffentliche ASN derzeit inaktiv, oder die aktuellen Dienste werden über einen anderen Netzwerkpfad bereitgestellt, oder die öffentlichen Sammler haben eine eingeschränkte Ankündigung verpasst. Jede Möglichkeit hat unterschiedliche Konsequenzen für den Kunden.

Was würde die Frage klären? Eine aktuelle Looking-Glass-Ansicht von TSBG, eine Routing-Tabelle, die Kundenpräfixe zeigt, eine Liste der Zugangsanbieter, eine Test-IP für den bestellten Dienst, ein Traceroute- und Pfaddiversitätsergebnis, eine aktuelle Statusseite, eine standortspezifische Dienstbeschreibung und eine Vertragssprache, die die verantwortlichen Parteien benennt. Bis diese verfügbar sind, ist die richtige redaktionelle Haltung Vorsicht.

Wie ein Käufer TSBG testen sollte, bevor er eine kritische Arbeitslast platziert

Der erste Test ist die Identität und Dienstpassung. Fragen Sie TSBG, welche juristische Person den Vertrag unterzeichnet, welcher Standort den Dienst hosten wird, welche Produktschicht gilt und ob der Dienst AS43112, AS47288, einen Adressblock des Transit-Anbieters oder eine andere Routing-Vereinbarung verwendet. Vergleichen Sie die Antwort mitRIPE RDAP für AS43112,RIPE RDAP für 193.3.63.0/24und den öffentlichen BGP-Beobachtungen. Wenn die Antwort lautet, dass die öffentliche ASN derzeit nicht genutzt wird, fragen Sie nach dem Warum und dem Ersatz.

Der zweite Test ist der Standortnachweis. Fragen Sie für Colocation nach dem Standortnamen, der Rack-Position, dem Stromversorgungsdesign, der maximalen Leistungsaufnahme, den Zusammenschaltungsoptionen, den Fernwartungsbedingungen, dem Zugangsverfahren und den Wartungsbenachrichtigungsregeln. Fragen Sie für VPS oder dedizierte Server, welche Einrichtung die Hardware hostet, ob der Wiederherstellungsstandort aktiv ist, ob Backups außerhalb des ausgefallenen Hosts liegen und ob Kapazität für Failover reserviert ist. Bitten Sie um ein aktuelles Ergebnis eines Strom-, Kühlungs- oder Generatortests. DieRechenzentrumsseite von TSBGgibt eine solide Liste von Einrichtungsbereichen; der Kunde benötigt die standortspezifische Version.

Der dritte Test ist die Netzwerkunabhängigkeit. Fragen Sie nach den aktuellen Zugangsanbietern, Routenfiltern, RPKI-Status, Diversität der physischen Eingänge, Schnittstellengeschwindigkeit, bezahlter Verpflichtung, DDoS-Exposition und Failover-Verhalten. Fragen Sie, ob die Behauptung von 99,999 % Internetkonnektivität für das Kundenprodukt gilt und wie Gutschriften berechnet werden. Verwenden Sie öffentliche Tools, um zu überprüfen, ob der ASN- und Präfixstatus mit der Antwort übereinstimmt, verlassen Sie sich jedoch nicht ausschließlich auf öffentliche Tools, wenn der Dienst einen privaten oder Partnerpfad verwendet.

Der vierte Test ist die Wiederherstellung. Führen Sie eine kleine Wiederherstellung durch. Exportieren Sie ein VPS-Image oder stellen Sie aus einem Backup wieder her. Bitten Sie die Fernwartung, eine nicht störende Konsolen- oder Inventaraufgabe durchzuführen. Testen Sie den Out-of-Band-Kontakt. Bestätigen Sie, wer Notfalländerungen autorisieren kann. Bestätigen Sie, ob eine Kontosperrung, eine unbezahlte Rechnung, ein Domainproblem oder ein Streit über das Recht auf Support die Wiederherstellungsarbeiten stoppen kann.

Das öffentliche Material beschreibt einen kompetenten kleinen Betreiber; die Aufgabe des Kunden ist es, diese Fähigkeit in seinem eigenen Ausfallszenario zu beweisen.

Wer ist betroffen, wenn das System ausfällt

Die betroffene Population hängt davon ab, welches TSBG-Produkt der Kunde kauft. Ein Shared-Hosting-Kunde ist Plattformausfällen ausgesetzt: cPanel, DNS, E-Mail, Speicher und der Supportpfad des Anbieters. Ein VPS-Kunde ist den Domänen Host, Speicher, Netzwerk und Backup ausgesetzt. Ein Kunde eines dedizierten Servers ist dem Hardware-Bestand, dem Netzwerkrand, den Stromversorgungen, der Fernwartung und jeder verwalteten Dienstschicht ausgesetzt. Ein Colocation-Kunde besitzt einen größeren Teil des Stapels, ist aber immer noch auf TSBG für Strom, Kühlung, physische Sicherheit, Fernzugriff und manchmal Internet-Transit angewiesen.

Für ein lokales Unternehmen kann ein Ausfall Website- oder E-Mail-Ausfall bedeuten. Für einen Telekommunikations- oder IT-Betreiber, der Rack-Platz nutzt, kann ein Ausfall nachgelagerte Kunden, Überwachung, Backhaul, ein Antennensystem oder einen Disaster-Recovery-Plan betreffen. Für einen Medien- oder Streaming-Kunden kann ein Ausfall die Ausstrahlung an die Öffentlichkeit unterbrechen. Für ein Unternehmen, das einen bulgarischen Standort als Alternative zu einer größeren westeuropäischen Cloud-Region nutzt, kann ein Ausfall genau die geografische Redundanz aufheben, die der Kunde kaufen wollte.

Die Support-Oberfläche erzeugt ebenfalls Effekte zweiter Ordnung. Wenn derselbe Kontakt Vertrieb, Support und technische Eskalation verwaltet, können Kunden während des Normalbetriebs persönliche Aufmerksamkeit und während eines allgemeinen Ereignisses eine langsame Antwort erhalten. Wenn ein Anbieterpfad beteiligt ist, kann TSBG von der Reparaturzeit eines anderen Betreibers abhängen. Wenn der Dienst eine unter AS43112 nicht sichtbare Route verwendet, können Kunden den falschen öffentlichen Rand überwachen und die wahre Fehlerdomäne verpassen.

Deshalb lautet das Fazit des Artikels nicht „Meiden Sie TSBG“. Es lautet: „Kaufen Sie nicht die Abstraktion, ohne die Abhängigkeiten zu kartieren.“ Das öffentliche Material von TSBG ist für einen kleinen Anbieter ungewöhnlich betriebsnah. Der fehlende Nachweis ist die aktuelle Erreichbarkeit und der getestete Failover für den spezifischen Kundenpfad.

Das Beweismaß

TSBG Hosting Ltd. erhält für diesen Artikel ein Netzwerk-Beweismaß von Niedrig. Das Maß ist kein Urteil über Kundenzufriedenheit oder technische Kompetenz. Es ist ein Urteil darüber, was die öffentlichen Beweise am 12.07.2026 belegen können. Die offizielle Website liefert starke unternehmensspezifische Servicebehauptungen: vier Rechenzentren, Colocation, VPS, dedizierte Server, Shared Hosting, A/B-Stromversorgung, Überwachung, Fernwartung, Sicherheit, Branderkennung, Kühlung und bulgarische Transit-Positionierung. Die RIPE-Registrierungen geben eine echte digitale Ressourcenidentität von TSBG: AS43112, ORG-THL32-RIPE und 193.3.63.0/24.

RPKI validiert die Ursprungsberechtigung von 193.3.63.0/24 für AS43112.

Die Herabstufung ergibt sich aus dem aktuellen Rand. RIPEstat hat AS43112 nicht als angekündigt gesehen, keine aktuellen AS43112-Präfixe und keine aktuellen AS43112-Nachbarn gesehen. Der TSBG Hosting-Standorteintrag von PeeringDB fügt einen physischen Hinweis hinzu, aber sein sichtbarer Netzwerkanschluss zeigt auf AS47288/FixNET und nicht auf AS43112. Dies kann eine gültige Partner- oder Zugangsanbietervereinbarung darstellen; es belegt nicht unabhängig das Live-Kunden-Routing von TSBG.

Die praktische Schlussfolgerung ist eng. TSBG scheint ein echter bulgarischer Hosting- und Colocation-Betreiber mit detaillierten physischen Infrastrukturbehauptungen zu sein. Ein Käufer sollte diese Behauptungen als überprüfbar behandeln, nicht als gegeben.

Bevor er kritische Arbeitslasten platziert, sollte er aktuelle Routennachweise, standortspezifische Einrichtungsnachweise, die Grenzen von Zugangsanbietern und Support, getestete Backup- oder Migrationsnachweise und eine schriftliche Karte darüber einholen, wer den Dienst bei Ausfall von Rack, Zugangsanbieter, Hardware-Bestand, Support, Abrechnung, Migration oder Anbietervertrag wiederherstellt.