tsbg_hosting TSBG Hosting Ltd. verkauft Hosting-Kapazitäten, die weiterhin von Racks, Transit und Reparaturfenstern abhängen

Zusammenfassung

• TSBG Hosting Ltd. präsentiert sich als bulgarischer Infrastrukturbetreiber, gegründet 2006, mit Angeboten für Colocation, Cloud-Server, dedizierte Server, Shared Hosting, Streaming und Managed Services auf der eigenen Website.
• Die stärksten betrieblichen Aussagen des Unternehmens sind physischer und nicht rein virtueller Natur: mehrere carrier-neutrale bulgarische Rechenzentrumseinrichtungen, vier Rechenzentren, TIA-942-orientiertes Design, A/B-Stromversorgung, Überwachung, Remote Hands, Branderkennung, Kühlung und begleiteter Zutritt.
• Das aktuelle öffentliche Netzwerksignal ist schwach.RIPE RDAPidentifiziert AS43112 als tsbg_hosting und führt TSBG Hosting Ltd. als Registranten, aber derRIPEstat-Routing-Statuszeigte am 12.07.2026 keinen sichtbaren angekündigten IPv4- oder IPv6-Adressraum für AS43112.
• Die Ressource 193.3.63.0/24 von TSBG bleibt relevant, daRIPE RDAP für das PräfixBG-TSBGHOSTING-20200902 identifiziert und dieRIPEstat-RPKI-ValidierungAS43112 als für dieses Präfix autorisiert bestätigte. Autorisierung ist nicht gleichbedeutend mit tatsächlicher Erreichbarkeit.
• DerPeeringDB-Eintrag für die TSBG-Hosting-Einrichtungliefert einen physischen Hinweis auf Haskovo/Svilengrad, während diePeeringDB-Net-Facility-Datendie aufgeführte Anbindung mit AS47288/FixNET und nicht mit AS43112 verbinden. Das unterstreicht die Notwendigkeit, die Betreibergrenzen zu überprüfen, bevor man sich auf Ausfallsicherheitsbehauptungen verlässt.
• Die Evidenzstufe ist Schwach. Die offizielle Website liefert umfangreiche Servicebehauptungen, aber die aktuellen öffentlichen Routing-Beweise belegen nicht unabhängig den tatsächlichen Kundenverkehr über AS43112, Multi-Site-Failover, Transit-Diversität, Reservekapazitäten oder Datenportabilität.

Eine Cloud-Rechnung landet dennoch in einem bulgarischen Maschinenraum

TSBG Hosting Ltd. ist kein Name, den man anhand des Bekanntheitsgrades beurteilen kann. Man muss ihn beurteilen, indem man den Dienst bis hin zu den Geräten und Menschen zurückverfolgt, die einen Kunden online halten würden. Das Unternehmen verkauft Dienste, die elastisch klingen: Cloud-Server, VPS-Pläne, dedizierte Server, Shared Hosting, Streaming, Colocation und Managed Support. Aber jeder dieser Dienste hat einen physischen Bestand dahinter. Ein virtueller Server benötigt Host-Kapazität, Speicher, Switching, Strom und Kühlung. Ein dedizierter Server benötigt ein bestimmtes Chassis und einen Austauschplan.

Colocation benötigt ein Rack, ein Strombudget, Kabelwege, Zugangskontrolle und Remote Hands. Streaming benötigt Ingress, Transcoding- oder Übergabekapazität und genügend ausgehende Bandbreite, um das Publikum bei steigender Nachfrage zu bedienen.

Die nützliche Tatsache über TSBG ist, dass das Unternehmen sich nicht nur in vager Cloud-Sprache beschreibt. Dieoffizielle Homepagebewirbt Colocation, dedizierte Server, virtuelle Server, Streaming und Satellitenantennen-Colocation. Dieselbe Seite beschreibt vier carrier-neutrale Rechenzentren und sechzehn Jahre Erfahrung und sagt, dass TSBG Private Cloud, Disaster-Recovery-Standorte, dedizierten Internetzugang, IPv4-Adressen, DC-Stromversorgung und Satelliten-Downlink unterstützen kann. Diese Behauptungen geben einem Käufer eine konkrete Liste zum Testen: Gebäude, Racks, Strombereiche, Glasfasern, Upstreams, Server, Adressressourcen und Support-Vereinbarungen.

Das Risiko besteht darin, dass die Details des öffentlichen Marketings immer noch den überprüfbaren Betriebsnachweisen vorauseilen 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 Service-Menü veröffentlichen, während einzelne Pläne von verfügbarem Bestand, Lieferantenunterstützung oder einer Drittanbieter-Einrichtung abhängen. Er kann einen Wiederherstellungsstandort anbieten, während der Kundenvertrag die Wiederherstellungsziele vage lässt.

Für TSBG enthält die öffentliche Aufzeichnung genau diese Mischung: eine spezifische Service-Story, eine spezifische bulgarische Identität, eine spezifische AS-Nummer und eine Lücke zwischen der Registrierung der Nummernressource und der sichtbaren Routen-Origination zum Veröffentlichungsdatum.

Diese Lücke macht TSBG nicht unzuverlässig. Sie verändert die Beweislast. Ein Kunde sollte die Web-Preisliste oder die ASN nicht als Bestätigungsbericht behandeln. Der Kunde sollte fragen, welche Einrichtung die Arbeitslast beherbergt, welcher Netzwerk-Edge den Dienst ankündigt, welcher Lieferant über standardmäßigen Transit verfügt, wie viel Strom und Ersatzhardware reserviert sind und wie die Daten die Plattform verlassen, wenn der Dienst umgezogen werden muss.

Was mit Zuversicht identifiziert werden kann

Die Unternehmensidentität ist stärker, als der erste Verzeichnis-Schnappschuss allein vermuten ließ. Die Website von TSBG besagt, dass das Unternehmen 2006 gegründet wurde, nach bulgarischem Recht eingetragen ist, die EU-Umsatzsteuer-Identifikationsnummer BG175059953 führt, Ivan Shishkov als Geschäftsführer nennt und eine Büroadresse in Sofia in der 8 Racho Dimchev Street angibt. DieKontaktseitewiederholt die Adresse in Sofia, Telefonnummer und Vertriebs-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.RIPEstat-Whois-Datenverzeichnen aut-num 43112, as-name tsbg_hosting, organization ORG-THL32-RIPE, status ASSIGNED und maintainer mnt-bg-tsbghosting-1.

Diese Einträge reichen aus, um einen häufigen Fehler in der Hosting-Recherche zu vermeiden: einen Dienstnamen als frei schwebendes Etikett ohne verantwortlichen Inhaber zu behandeln. Hier kann der Inhaber mit einer bulgarischen Unternehmensidentität, einer Kontaktoberfläche, einem Nummernressourceneintrag und einer sichtbaren Service-Website verbunden werden. Das ist nützlicher als eine Reseller-Seite ohne Adresse und ohne Routing-Eintrag.

Der Service-Umfang ist ebenfalls spezifisch. DieColocation-Seitevon TSBG bewirbt Pakete für eine einzelne Rack-Einheit, ein Viertel-Rack, ein halbes Rack und ein volles Rack mit angegebenen Leistungsstufen von 35 W für eine Rack-Einheit bis zu 1500 W für ein volles Rack. Die Seite besagt auch, dass das Unternehmen Internetverbindungen, IPv4-Adressen und LIR-Dienste bereitstellen kann. DieCloud-Server-Seitelistet VPS-Pläne, SSD-Speicher, RAID10-Schutz, 1 Gbit/s gemeinsames Internet und optionale Backups auf. DieSeite für dedizierte Serverbeschreibt redundante Netzteile, RAID 1 oder RAID 10, zwei Netzwerkcontroller und Top-of-Rack-Switch-Redundanz. 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 Teil einer gemeinsamen Plattform, eine virtuelle Maschine, einen physischen Server, Rack-Platz, Konnektivität oder Support mieten. Das wirtschaftliche Problem besteht darin, dass Produkte höherer Ebene die Einschränkungen der unteren Ebenen erben. Wenn das Rack die Stromversorgung verliert, sind die dedizierten Server und VPS-Pläne, die an diesen Standort angeschlossen sind, betroffen.

Wenn der Netzwerk-Edge einen Anbieter verliert oder ein Routenobjekt zurückgezogen wird, kann ein scheinbar separater Hosting-Plan dennoch gleichzeitig mit dem Colocation-Dienst ausfallen. Wenn der Support von demselben kleinen Team durchgeführt wird, das auch Hardwareaustausch vornimmt, kann ein stark ausgelasteter Vorfall aus einem „kostenlosen Remote-Hands“-Versprechen eine Warteschlange machen.

Der Nummernressourceneintrag ist aktiv, aber der öffentliche Edge war ruhig

Die wichtigste Netzwerktatsache ist nicht schmeichelhaft, aber präzise.RIPEstat's AS-Übersicht für AS43112identifizierte den Inhaber als tsbg_hosting TSBG Hosting Ltd., markierte die ASN jedoch als nicht angekündigt für die Abfrage am 12.07.2026.RIPEstat-Routing-Statusmeldete, dass die erste gesehene Route 77.246.240.0/20 am 14.06.2007 war und die letzte gesehene Route 193.3.63.0/24 am 15.08.2025 war, während die aktuelle Sichtbarkeit null von 325 IPv4-Peers und null von 322 IPv6-Peers betrug.RIPEstat angekündigte Präfixelieferte keine aktuellen Präfixe für AS43112 für den Zeitraum 28.06.2026 bis 12.07.2026 zurück.

Das löscht die Servicebehauptungen von TSBG nicht aus. Es besagt etwas Engeres: Öffentliche Routen-Kollektoren sahen AS43112 am Veröffentlichungsdatum nicht mit aktivem angekündigtem Raum. Ein Kunde kann AS43112 nicht allein als Nachweis für aktuellen Internetdienst, Transit-Diversität oder Kundenverkehr verwenden. Wenn aktuelle Dienste über eine andere ASN, einen vom Carrier zugewiesenen Adressblock, ein Provider-Netzwerk, eine private Zusammenschaltung oder eine verwaltete Upstream-Vereinbarung bereitgestellt werden, muss dies direkt angegeben und getestet werden.

Der inaktive öffentliche Edge verändert auch, wie ältere Beweise zu lesen sind.RIPEstat-Routing-Verlaufzeigt 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 in weiten Teilen der Jahre 2022 bis 2025 weithin sichtbar war, bevor sie nach Mitte August 2025 auf minimale Sichtbarkeit zurückfiel. Der Verlauf ist nützlich für Identität und Kontinuität. Er ist nicht die aktuelle Kapazität. Wenn dieselben Kunden noch bedient werden, werden sie jetzt möglicherweise über ein anderes Netzwerkdesign bedient. Wenn das Präfix zurückgezogen wurde, weil Dienste umgezogen sind, ist der Migrationspfad von Bedeutung. Wenn es zurückgezogen wurde, weil der Dienst pausierte, muss ein Käufer dies wissen, bevor er Kapazität bestellt.

RPKI fügt eine weitere Nuance hinzu.RIPEstat-RPKI-Validierung für 193.3.63.0/24 und AS43112gab gültig zurück. Das ist ein positiver administrativer Beweis: AS43112 ist berechtigt, das Präfix zu originieren. Aber eine gültige Routen-Ursprungsautorisierung ist nicht dasselbe wie eine Ankündigung. Ein Rauchmelder kann in einem Raum installiert sein, der derzeit leer ist; eine ROA kann für eine Route existieren, die in BGP nicht sichtbar ist. Das Control-Plane-Recht existiert, während der Betriebspfad noch eine Live-Bestätigung benötigt.

Die Website beansprucht starke Einrichtungen, aber die Karte ist unvollständig

Die stärkste öffentliche Darstellung von TSBG ist die seiner physischen Einrichtungen. DieRechenzentrums-History-Seitebesagt, dass das Unternehmen 2006 gegründet wurde, sein erstes Rechenzentrum bis September 2006 fertigstellte, ein zweites Colocation-Projekt bis Juli 2007, ein drittes Rechenzentrum als Disaster-Recovery-Standort mit ersten Geräten im Juli 2008 und ein viertes Rechenzentrum bis Oktober 2008. Sie besagt auch, dass sich TSBG seit 2014 auf Colocation, Hosting, Serververmietung und Managed Services konzentriert hat.

DieRechenzentrumsseiteerweitert die Einrichtungsansprüche. Sie besagt, dass die Standorte von TSBG nach TIA-942 konzipiert sind, dass die Standorte sorgfältig ausgewählt werden, dass das Unternehmen eine 100-prozentige Stromverfügbarkeit garantiert, dass die Stromversorgung in einer vollständig diversen A/B-Konfiguration ausgelegt ist, dass die Kühlung nach Nennkapazität redundant ist und dass die physische Sicherheit bewachte Standorte, Videoüberwachung und begleiteten Zutritt umfasst. Sie besagt, dass die Überwachung Serverlast, Arbeitsspeicher, Festplatten, Port-Verkehr, Gerätezustand, Temperatur, Luftfeuchtigkeit, elektrischen Strom, Stromverbrauch, Klimaanlage und optische Netzwerkleistung abdeckt.

Das sind ernstzunehmende Behauptungen. Sie erfordern auch, dass ein Käufer einrichtungsspezifische Nachweise verlangt. „Vier Rechenzentren“ ist nur dann ein nützlicher Ausgangspunkt, wenn der Kunde identifizieren kann, welches der vier seine Arbeitslast beherbergen wird, ob der Wiederherstellungsstandort aktiv oder im Standby-Modus ist, ob die Standorte denselben Upstream teilen, ob sich der Backup-Speicher in einem separaten Fehlerbereich befindet und welches vertragliche Wiederherstellungsziel gilt, wenn ein Standort isoliert ist. Die öffentlichen Seiten beschreiben Prinzipien und Fähigkeiten.

Sie benennen nicht jedes Gebäude, jede Stromeinspeisung, jeden Treibstoffvertrag, jedes Carrier-Meet, jedes Ersatzteilinventar oder jedes getestete Wiederherstellungsergebnis.

Die geografische Angabe erfordert ebenfalls einen sorgfältigen Umgang. TSBG gibt an, dass sich seine Gebäude in Bulgarien befinden und geografisch verteilt sind, mehr als 150 km voneinander entfernt, in Zonen, die ausgewählt wurden, um das Risiko von Überschwemmungen, Bränden, Verkehr, industriellen und menschlichen Aktivitäten zu verringern. DerBlogbeitrag von 2023 über Bulgarien als Rechenzentrumsstandortbesagt, dass Bulgarien an wichtigen Routen zwischen Europa, der Türkei und dem Nahen Osten liegt und dass TSBG geschützte Layer-2- und IP-Verbindungen über diverse Routen nach Istanbul, Sofia, Bukarest und in europäische Netzwerke bereitstellen kann. Das ist eine wertvolle regionale These, insbesondere für Kunden mit Latenzanforderungen in Bezug auf den Balkan, die Türkei oder Europa-Nahost. Aber ein Standortvorteil ist kein Ersatz für Live-Pfad-Nachweise. Ein guter Korridor benötigt dennoch vertraglich gebundene Carrier, diverse Leitungswege, funktionierende Cross-Connects und ausreichende Kapazität, nachdem eine Verbindung ausgefallen ist.

PeeringDB fügt einen Hinweis auf Haskovo und eine Betreibergrenzwarnung hinzu

PeeringDB gibt der Einrichtungsgeschichte einen separaten öffentlichen Hinweis.Die PeeringDB-Einrichtungs-API für Einrichtung 13672listet „TSBG Hosting“ in Haskovo, Bulgarien, mit Adresszeile1 „Byalo More 3 Kapitan Andreevo“, Bundesland Svilengrad, Land BG, einemtsbg.eu-Website-Feld, Vertriebs- und technischen Telefon-/E-Mail-Kontakten und verfügbarem Spannungsservice 480 VAC. Der Eintrag wurde am 19.05.2023 erstellt und am 26.09.2025 aktualisiert. Das ist nützlich, weil es außerhalb der eigenen Website von TSBG liegt und auf eine bestimmte benannte Einrichtungsoberfläche in Südbulgarien nahe der türkisch-griechischen Grenze verweist, die durch die Website von TSBG betont wird.

Aber dieselben PeeringDB-Daten schaffen ein Grenzproblem. DiePeeringDB-Netfac-Daten für Einrichtung 13672zeigen einen angeschlossenen Netzwerkeintrag mit dem Namen TSBG Hosting in Haskovo mit lokaler ASN 47288.PeeringDB-Netzwerk 26850identifiziert dieses Netzwerk als FIXNET TELEKOM LTD. STI., ASN 47288, mit Verkehrsumfang Europa, offener Peering-Richtlinie, sieben Einrichtungen und drei Exchange-Anbindungen.RIPEstat's AS-Übersicht für AS47288identifiziert den Inhaber als FIXNET Telekomunikasyon Limited Sirketi und markiert die ASN als angekündigt.RIPEstat-Routing-Status 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.

Dies beweist nicht, dass FixNET die Kundendienste von TSBG betreibt. Es beweist, dass die öffentliche PeeringDB-Einrichtungsanbindung nicht beiläufig 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 die sichtbare Netzwerkanbindung ist, sollte der Vertrag erklären, ob TSBG, FixNET, ein anderer Carrier oder der Kunde den Standard-Internetdienst bereitstellt.

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

Die Frage der Betreibergrenze ist nicht akademisch. Während eines Vorfalls kann der Ersthelfer der TSBG-Support, der Einrichtungsbesitzer, ein Carrier, ein Remote-Hands-Anbieter oder der Netzwerkanbieter sein. Der Kunde benötigt die Eskalationskette vor dem Ausfall. Ein Einrichtungseintrag, der TSBG nennt, und ein Netzwerkeintrag, der AS47288 nennt, können beide wahr sein, während der Kunde dennoch exponiert bleibt, wenn der Dienstvertrag die Rollen nicht klar abbildet.

Die Rack-Ökonomie entscheidet, wie viel des Dienstes real ist

TSBG veröffentlicht ungewöhnlich detaillierte Colocation-Preise und Rack-Pakete. DieColocation-Service-Seitelistet eine einzelne Rack-Einheit, ein Viertel-Rack, ein halbes Rack und ein volles Rack auf, mit Leistungsgrenzen und optionalen Rack-Features. Die Seite besagt auch, dass TSBG 48 VDC als Standardoption, A/B-Strom aus separaten Stromräumen und USV-Systemen, Stromzähler und ATS-Schalter auf Anfrage, Überwachung, 24/7-Support und Internetzugang bereitstellen kann. Das gibt Kunden einen sichtbaren Warenkorb für einen Einrichtungsservice, der sich normalerweise hinter Vertriebsanrufen verbirgt.

Die Gefahr besteht darin, dass ein sichtbarer Rack-Preis nicht mit nutzbarer, ausfallsicherer Kapazität gleichzusetzen ist. Eine einzelne Rack-Einheit mit 35 W ist eine ganz andere Abhängigkeit als ein volles Rack mit 1500 W. Ein Kunde, der Telekommunikationsgeräte betreibt, benötigt möglicherweise Gleichstrom, doppelte PDUs und Remote-Hands-Zugang; ein Kunde, der Rechenleistung betreibt, benötigt möglicherweise mehr Strom, Kühlung und Hardwareaustausch.

Eine Preisliste kann nicht zeigen, ob Reservestrom reserviert ist, ob Cross-Connect-Arbeiten schnell sind, ob Remote Hands ein Gerät während eines regionalen Sturms austauschen können oder ob der verbleibende Netzwerkpfad Verkehr transportieren kann, wenn ein Lieferant ausfällt.

Die Ökonomie kleiner Anbieter ist hier von Bedeutung. TSBG sagt offen auf seiner Website, dass es nicht der größte Rechenzentrumsbetreiber ist und nicht über Megawatt an Strom oder Terabit pro Sekunde an Internetkapazität verfügt. Diese Ehrlichkeit ist nützlich. Sie sagt Käufern, dass sie auf Eignung achten sollten, nicht auf Größentheater. Ein kleiner Standort kann genau richtig für ein lokales Unternehmen, ein Telekommunikationsprojekt an Grenzrouten, einen Disaster-Recovery-Schrank oder einen Balkan-Dienst mit niedriger Latenz sein.

Er kann auch falsch für eine Arbeitslast sein, die hyperskalierbare Reservepools, globale Cloud-APIs oder sofortigen Hardwareaustausch voraussetzt.

Der Käufer muss daher Paketbezeichnungen in Ausfallmathematik übersetzen. Wenn eine Rack-Stromeinspeisung ausfällt, verfügen die Kundengeräte dann über doppelte Netzteile und doppelte PDUs? Wenn ein Top-of-Rack-Switch ausfällt, sind dann beide Server-NICs mit unabhängigen Switches verkabelt? Ist der andere Pfad, wenn ein Upstream ausgefallen ist, mit ausreichend bezahltem Commit ausgestattet? Wenn ein Rechenzentrum verloren geht, sind Backups ohne den verlorenen Standort verwendbar? Wenn eine Support-Person zu einem entfernten Standort reisen muss, wie sieht die tatsächliche Reparaturuhr aus?

Die Rack-Ökonomie wird zur Risikoökonomie, sobald ein Ausfall beginnt.

VPS und dedizierte Server erben jede untere Schicht

Die VPS- und dedizierten Server-Seiten von TSBG sind detailliert genug, um zu zeigen, woher der Kundenwert kommt. DieCloud-Server-Seitebesagt, dass VPS-Pläne auf Proxmox basieren, redundante Hardware, RAID10-Speicher, redundante Netzwerk- und Stromversorgungs-Server-Hosts, 1 Gbit/s gemeinsames Internet und optionale Backups verwenden. Sie listet Pläne von einem kleinen 512-MB-RAM-Plan bis zu größeren Multi-Core-Plänen auf. DieSeite für dedizierte Serverbesagt, dass 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 und Remote Hands.

Diese Merkmale sind bedeutsam. Sie schaffen auch eine Überprüfungsagenda. Ein Kunde, der VPS-Kapazität mietet, sollte fragen, ob RAID10 lokal auf einem Host ist, über einen Speichercluster gemeinsam genutzt wird, an einen anderen Standort repliziert oder Out-of-Band gesichert wird. Er sollte fragen, ob das optionale Backup in derselben Einrichtung gespeichert wird, ob die Wiederherstellungsgeschwindigkeit gemessen wird und ob Backups Systemabbilder, Dateidaten, Metadaten und Control-Panel-Status umfassen. Er sollte fragen, was passiert, wenn die Host-Maschine ausfällt und ob Live-Migration verfügbar ist.

Er sollte fragen, ob Ressourcenkonflikte die Wiederherstellung bremsen können, wenn viele Kunden gleichzeitig betroffen sind.

Ein Kunde mit dediziertem Server hat ein anderes Problem. Redundante Netzteile helfen nur, wenn jede Versorgung einen unabhängigen Strompfad erreicht. Zwei Netzwerkcontroller helfen nur, wenn sie mit unabhängigen Switches verkabelt sind und über unabhängige Upstream-Kapazität geroutet werden. RAID schützt vor einem Festplattenausfall, aber nicht vor einem Controller-Fehler, einem fehlerhaften Rebuild, Ransomware oder einem standortweiten Ereignis. Kostenlose Remote Hands sind nur nützlich, wenn Teile vorrätig sind und das Personal die Einrichtung schnell betreten kann.

Die öffentliche Routenlücke macht diese Fragen noch wichtiger. Wenn AS43112 derzeit nicht sichtbar ist, kann der kundenorientierte Internetdienst von TSBG von vom Anbieter zugewiesenen Routen, einem Transitpartner, einer anderen ASN oder einem privaten Design abhängen, das in öffentlichen Kollektoren nicht sichtbar ist. Diese Vereinbarung kann völlig legitim sein. Sie muss nur dem Kunden offengelegt werden, der „Internetzugang“ als Teil eines Serverplans kauft. Der Kunde muss wissen, welcher Edge ausfällt, wenn der Carrier ausfällt.

Strom-, Kühlungs- und Überwachungsbehauptungen benötigen getestete Nachweise

Die Einrichtungsseiten stützen sich stark auf Strom und Überwachung. TSBG gibt an, dass die Rechenzentrumsstromversorgung in einer vollständig diversen A/B-Konfiguration ausgelegt ist, beginnend mit separaten Stromräumen, Verteilertafeln, USV-Systemen und Verkabelung zu den Racks. Es besagt, dass jedes Rack zwei oder mehr PDUs hat, eine für Stromkreis A und eine für Stromkreis B. Es besagt, dass die Klimatisierung eine redundante 1+1- oder n+1-Konfiguration verwendet und dass die Geräteräume bei etwa 22 Grad Celsius mit einer relativen Luftfeuchtigkeit zwischen 40 % und 60 % gehalten werden.

Es besagt, dass die Branderkennung ein Luftansaugsystem und Gasunterdrückung verwendet. Es besagt, dass die Überwachung ein breites Spektrum an Umwelt-, Server-, Port- und optischen Netzwerkparametern abdeckt.

Das sind genau die richtigen Bereiche, um sie zu veröffentlichen. Die Frage ist, ob die Behauptungen auf dem gleichen Niveau getestet werden, auf dem die Kunden von ihnen abhängen. A/B-Strom ist nicht durch zwei Kabel bewiesen, wenn beide Stromkreise von einer vorgelagerten Tafel, einer Treibstoffregelung oder einem Wartungsanbieter abhängen. Kühlungsredundanz ist nicht durch Nennkapazität bewiesen, wenn ein Hot Aisle, Sensorausfall oder eine Änderung des Luftstroms die Reserve entfernen kann.

Überwachung ist nicht durch das Vorhandensein von Sensoren bewiesen, wenn die Zuständigkeit für Alarme, Schwellenwerte und Notfallberechtigungen unklar ist.

Die Blog-Inhalte von TSBG geben nützliche Hinweise auf die betriebliche Ernsthaftigkeit. DerBeitrag zur Wartung von Dieselgeneratorenbehandelt Generatoröl, Filter, Kühlmittel, Batterien und Winterbereitschaft. DerBeitrag zur Temperaturüberwachungbehandelt SNMP, Zabbix, One-Wire-Sensoren, verteilte Überwachung und Alarmdesign. DerBeitrag zum Standort von Rechenzentrumsgebäudenbehandelt Standortwahl, Katastrophenrisiken, Betonbauweise, Dachkonstruktion und Telekommunikationszugang. Diese Beiträge sind keine Zertifizierungen, aber sie zeigen eine Vertrautheit mit der Domäne, die spezifischer ist als generische Hosting-Texte.

Der nächste Schritt des Kunden sollten Nachweise sein, nicht Bewunderung. Fragen Sie nach dem Datum des letzten Generatortests, der getesteten Last, der Treibstofflaufzeit, USV-Wartungsnachweisen, Wartungsnachweisen für die Brandanlage, dem Reaktionsplan bei Kühlungsausfall, einer Probe von Überwachungs-Eskalationen und Nachbetrachtungen zu realen Vorfällen. Fragen Sie, ob alle vier Standorte die gleiche Reife haben. Fragen Sie, welcher Standort den spezifischen Kundendienst beherbergt. Fragen Sie, was zusammen ausfällt. So wird aus allgemeiner Einrichtungssprache betriebliche Sicherheit.

Netzwerkresilienz hängt von Upstream-Verträgen ab, nicht nur von einer ASN

Die eigenen Seiten von TSBG besagen, dass das Unternehmen ein eigenes autonomes System betreibt und BGP-Sitzungen mit sorgfältig ausgewählten Anbietern hat. RIPE-Einträge identifizieren AS43112, und RIPE-Whois-Bemerkungen erwähnen Upstreams und Rechenzentrum, mit einem Import von AS47964 und einem Export zu AS47964.RIPEstat-AS-Routing-Konsistenzzeigte 193.3.63.0/24 in RIPE-Whois, aber nicht in BGP am 12.07.2026, und zeigte den Import/Export von AS47964 in Whois, aber nicht in BGP.RIPEstat-ASN-Nachbarn für AS43112zeigten am Veröffentlichungsdatum keine beobachteten Nachbarn.

Diese Kombination sagt einem Käufer, dass er drei Dinge trennen muss. Das erste ist die Registrierungsabsicht: Die ASN, das Routenobjekt, die ROA und die Whois-Beziehungen zeigen, was der Betreiber vorbereitet oder autorisiert ist zu tun. Das zweite ist Live-Routing: Öffentliche Kollektoren zeigen, ob die Route derzeit sichtbar ist und durch wen. Das dritte ist Service-Routing: Eine Kundenarbeitslast kann einen anderen Upstream oder Adressplan verwenden, der nicht offensichtlich aus der TSBG-ASN allein hervorgeht. Die Resilienz hängt vom dritten ab, aber die öffentliche Aufzeichnung beleuchtet hauptsächlich die ersten beiden.

Die PeeringDB-Evidenz zu AS47288 ist ebenfalls nützlich, ohne überinterpretiert zu werden. FixNET, das AS47288-Netzwerk, das mit dem TSBG-Hosting-Einrichtungseintrag verbunden ist, war imRIPEstat-Routing-Statusaktiv und hatte PeeringDB-Exchange-Anbindungen bei NetIX, TurkIX Sofia und RegPEX. Das zeigt eine aktive nahe gelegene Netzwerkoberfläche, die mit dem Einrichtungseintrag verbunden ist. Es beweist nicht, dass der Kundenverkehr von TSBG diese Oberfläche nutzt, dass TSBG sie kontrolliert oder dass sie für irgendeinen gegebenen Kunden divers genug ist.

Der Kundentest ist einfach. Fragen Sie TSBG, die ASNs, Präfixe und Upstreams zu identifizieren, die den bestellten Dienst transportieren werden. Fragen Sie, ob diese Pfade standardmäßig fähig sind, ob sie separate physische Eingänge verwenden, ob sie in demselben Router-Paar enden, ob die Routenfilter aktuell sind und ob die Route Origin Validation konfiguriert ist. Vergleichen Sie die Antwort mit öffentlichen Tools wieBGP.tools für AS43112,Hurricane Electric für AS43112,Cloudflare Radar-Routing für AS43112und RIPEstat. Wenn die öffentliche ASN absichtlich ruhig ist, ist dies nur dann akzeptabel, wenn der Live-Service-Pfad dokumentiert ist.

Support ist Teil des Vermögenswerts, nicht nur eine Hilfeseite

TSBG betont wiederholt den Support. Die Website erwähnt 24/7-Helpdesk-Support, Remote Hands, E-Mail-, Viber- und WhatsApp-Nachrichten, Überwachung und kostenlose Unterstützung beim Hardwareaustausch. In einem Hosting- oder Colocation-Dienst ist Support kein weiches Extra. Es ist der Kanal, durch den unsichtbare Abhängigkeiten zu Reparaturmaßnahmen 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 ein Rebuild, ein Restore oder ein Failover durchgeführt werden soll.

Ein Kunde kann den Server besitzen, aber Remote Hands sind möglicherweise die einzige Möglichkeit, einen Knopf zu drücken, eine Karte neu zu stecken oder eine Konsole zu lesen.

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

Kunden sollten daher Support als Infrastruktur vertraglich vereinbaren. Sie sollten fragen, was als Notfall zählt, wer einen erklären kann, welcher Reaktionskanal funktioniert, wenn das Portal ausgefallen ist, ob eine telefonische oder Nachrichten-Eskalation garantiert ist, ob Remote Hands zeitliche Grenzen haben und ob Teile vor Ort gelagert sind. Sie sollten fragen, ob ein Colocation-Kunde Arbeiten im Voraus autorisieren kann. Sie sollten fragen, ob ein VPS-Kunde während eines Plattformvorfalls Wiederherstellungshilfe oder nur Best-Effort-Support erhält.

Sie sollten fragen, ob der Support-Datensatz den betroffenen Standort, Upstream, das Rack oder die Service-Ebene benennt, anstatt nur einen allgemeinen Ausfall zu beschreiben.

Die Abrechnung gehört in dieselbe Kategorie. Ein Dienst kann durch ein deaktiviertes Konto, eine abgelaufene Dienstlaufzeit, ein gesperrtes Control Panel oder eine unklare Verantwortung für zusätzlichen Datenverkehr ausfallen. Ein Kunde, der TSBG für einen kleinen Disaster-Recovery-Standort nutzt, sollte sicherstellen, dass Kontakt, Rechnungsstellung, Verlängerung und Out-of-Band-Zugang während genau des Ereignisses verfügbar bleiben, das den Wiederherstellungsstandort erforderlich macht.

Datenlokalität wird nicht durch ein bulgarisches Etikett gelöst

Die Zuweisungsregion ist BG, und die eigene Geschichte von TSBG ist stark bulgarisch. Das Unternehmen ist in Bulgarien eingetragen, listet ein Büro in Sofia, beschreibt bulgarische Standorte und bewirbt Bulgarien als strategischen Telekommunikations-Transitstandort. Für Kunden mit Konnektivitätsanforderungen in Europa, auf dem Balkan, in der Türkei oder im Nahen Osten ist das eine bedeutsame Positionierungsaussage. Sie kann die Latenz reduzieren, die Ausrüstung unter einer bulgarischen Anbieterbeziehung halten und eine Alternative zu größeren westeuropäischen Cloud-Regionen bieten.

Aber Datensouveränität ist nicht nur ein Ländercode. Ein Kunde muss identifizieren, wo sich Primärdaten, Backups, Protokolle, Control-Panel-Aufzeichnungen, Support-Tickets, Überwachungsdaten und Abrechnungsunterlagen befinden. 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 Signale von Satelliten- oder terrestrischen Pfaden aufnehmen und sie über eine Mischung aus lokalem und internationalem Transit liefern.

Ein Colocation-Kunde kann die Hardware besitzen, sich aber für Fernzugriff und IP-Dienst auf TSBG verlassen.

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

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

Inoffizielle Signale können Hinweise sein, keine Schlussfolgerungen

Wenig belegte Infrastruktur-Subjekte hinterlassen oft Spuren in kommerziellen Aggregatoren, alten BGP-Seiten, Preisseiten, Suchergebnissen, Forenbeiträgen, sozialen Profilen und Einrichtungsverzeichnissen. TSBG ist keine Ausnahme. Öffentliche Routing-Aggregatoren wie dieIPinfo-Seite für AS43112,BGP.tools,Hurricane ElectricundCloudflare Radarsind nützlich für einen schnellen Quervergleich. PeeringDB ist nützlich für Hinweise auf Einrichtungen und Zusammenschaltungen. Die offizielle Website ist nützlich für Servicebehauptungen und Kontaktinformationen.

Diese Signale sollten nicht gleich behandelt werden. RIPE RDAP und RIPEstat sind stark für die Identität von Nummernressourcen und die Beobachtung öffentlicher Routen. PeeringDB ist wertvoll, aber selbst gepflegt und kann der Realität hinterherhinken. Die offizielle Website ist maßgeblich für das, was TSBG zu verkaufen behauptet, aber kein unabhängiger Beweis dafür, dass ein bestimmtes Rack, ein Glasfaserpfad oder ein Backup heute existiert. Aggregator-Seiten sind gut zur Triangulation, können aber veraltet sein oder Daten unterschiedlich darstellen. Blogbeiträge zeigen technisches Denken, kein aktuelles Betriebszertifikat.

Die Unterscheidung ist am wichtigsten, wenn öffentliche Beweise widersprüchlich sind. Die offiziellen Service-Seiten von TSBG besagen wiederholt, dass das Unternehmen ein eigenes AS mit BGP-Sitzungen betreibt. RIPE-Einträge identifizieren AS43112 und eine gültige ROA existiert für 193.3.63.0/24. Dennoch sah RIPEstat AS43112 am Veröffentlichungsdatum nicht als angekündigt. Das ist nichts, was man glattbügeln sollte. Es ist das Hauptergebnis. Entweder ist die öffentliche ASN derzeit ruhend, oder aktuelle Dienste werden über einen anderen Netzwerkpfad bereitgestellt, oder die öffentlichen Kollektoren haben eine begrenzte Ankündigung verpasst.

Jede Möglichkeit hat unterschiedliche Kundenkonsequenzen.

Was würde es klären? Eine aktuelle Looking-Glass-Ansicht von TSBG, eine Routentabelle mit Kundenpräfixen, eine Upstream-Liste, eine Test-IP für den bestellten Dienst, ein Traceroute- und Pfad-Diversitätsergebnis, eine aktuelle Statusseite, eine einrichtungsspezifische Servicebeschreibung 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 Identität und Service-Eignung. Bitten Sie TSBG zu bestätigen, welche juristische Person den Vertrag unterzeichnet, welcher Standort den Dienst hosten wird, welche Produktebene gilt und ob der Dienst AS43112, AS47288, einen Transit-Provider-Adressblock oder eine andere Routing-Vereinbarung verwendet. Vergleichen Sie die Antwort mitRIPE RDAP für AS43112,RIPE RDAP für 193.3.63.0/24und öffentlichen BGP-Beobachtungen. Lautet die Antwort, dass die öffentliche ASN derzeit nicht verwendet wird, fragen Sie warum und was sie ersetzt.

Der zweite Test ist der Einrichtungsnachweis. Für Colocation: Fragen Sie nach dem Standortnamen, der Rack-Position, dem Stromversorgungsdesign, der maximalen Stromaufnahme, den Cross-Connect-Optionen, den Remote-Hands-Bedingungen, dem Zugangsverfahren und den Wartungsbenachrichtigungsregeln. Für VPS oder dedizierte Server: Fragen Sie, welche Einrichtung die Hardware beherbergt, ob der Wiederherstellungsstandort aktiv ist, ob Backups vom ausgefallenen Host getrennt sind und ob Kapazität für Failover reserviert ist. Fragen Sie nach einem aktuellen Strom-, Kühlungs- oder Generatortestergebnis. DieRechenzentrumsseitevon TSBG bietet eine starke Liste von Einrichtungsbereichen; der Kunde benötigt die standortspezifische Version.

Der dritte Test ist die Netzwerkunabhängigkeit. Fragen Sie nach aktuellen Upstreams, Routenfiltern, RPKI-Status, physischer Eingangsdiversität, Schnittstellengeschwindigkeit, bezahltem Commit, DDoS-Exposition und Failover-Verhalten. Fragen Sie, ob die 99,999%ige Anspruch auf Internetkonnektivität für das Kundenprodukt gilt und wie Gutschriften berechnet werden. Verwenden Sie öffentliche Tools, um zu prüfen, ob der ASN- und Präfix-Status mit der Antwort übereinstimmt, aber verlassen Sie sich nicht allein auf öffentliche Tools, wenn der Dienst einen privaten oder Partner-Pfad verwendet.

Der vierte Test ist die Wiederherstellung. Führen Sie eine kleine Wiederherstellung durch. Exportieren Sie ein VPS-Image oder stellen Sie es aus einem Backup wieder her. Bitten Sie Remote Hands, 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 Kontosperre, eine unbezahlte Rechnung, ein Domain-Problem oder ein Streit über Support-Berechtigungen die Wiederherstellungsarbeiten stoppen kann.

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

Wer ist betroffen, wenn das System ausfällt

Die betroffene Bevölkerung hängt davon ab, welches TSBG-Produkt ein Kunde kauft. Ein Shared-Hosting-Kunde ist Plattformausfällen ausgesetzt: cPanel, DNS, E-Mail, Speicher und dem Support-Pfad des Anbieters. Ein VPS-Kunde ist Host-, Speicher-, Netzwerk- und Backup-Domänen ausgesetzt. Ein Kunde mit dediziertem Server ist Hardwarebeständen, dem Netzwerk-Edge, Stromeinspeisungen, Remote Hands und etwaigen Managed-Service-Ebenen ausgesetzt. Ein Colocation-Kunde besitzt mehr vom Stack, ist aber dennoch von TSBG für Strom, Kühlung, physische Sicherheit, Fernzugriff und manchmal Internet-Transit abhängig.

Für ein lokales Unternehmen kann ein Ausfall eine Downtime der Website oder E-Mail 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 beeinträchtigen. Für einen Medien- oder Streaming-Kunden kann ein Ausfall die Publikumsauslieferung 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 beseitigen, die der Kunde kaufen wollte.

Die Support-Oberfläche erzeugt auch Effekte zweiter Ordnung. Wenn derselbe Kontakt Vertrieb, Support und technische Eskalation übernimmt, können Kunden im Normalbetrieb persönliche Aufmerksamkeit und bei einem breiten Ereignis eine langsame Reaktion erhalten. Wenn ein Lieferantenpfad beteiligt ist, kann TSBG von der Reparaturuhr eines anderen Carriers abhängig sein. Wenn der Dienst eine Route verwendet, die unter AS43112 nicht sichtbar ist, können Kunden den falschen öffentlichen Edge überwachen und den tatsächlichen Fehlerbereich verpassen.

Deshalb lautet die Schlussfolgerung des Artikels nicht „Meiden Sie TSBG“. Sie 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 das getestete Failover für den spezifischen Kundenpfad.

Die Evidenzstufe

TSBG Hosting Ltd. erhält für diesen Artikel eine Schwache Netzwerk-Evidenzstufe. Die Stufe ist keine Bewertung der Kundenzufriedenheit oder der Ingenieurskunst. Sie ist eine Bewertung dessen, was öffentliche 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-Strom, Überwachung, Remote Hands, Sicherheit, Branderkennung, Kühlung und bulgarische Transitpositionierung. RIPE-Einträge liefern eine echte TSBG-Nummernressourcen-Identität: AS43112, ORG-THL32-RIPE und 193.3.63.0/24.

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

Die Herabstufung kommt vom aktuellen Edge. RIPEstat sah AS43112 nicht als angekündigt, sah keine aktuellen AS43112-Präfixe und sah keine aktuellen AS43112-Nachbarn. Der PeeringDB-Eintrag für die TSBG-Hosting-Einrichtung fügt einen physischen Hinweis hinzu, aber seine sichtbare Netzwerkanbindung verweist auf AS47288/FixNET und nicht auf AS43112. Das mag eine gültige Partner- oder Upstream-Vereinbarung darstellen; es beweist nicht unabhängig das aktuelle Kundennrouting 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 erledigt.

Bevor kritische Arbeitslasten platziert werden, sollte er aktuelle Routenbeweise, standortspezifische Einrichtungsnachweise, Upstream- und Support-Grenzen, getestete Backup- oder Migrationsevidenz und eine schriftliche Karte darüber erhalten, wer den Dienst wiederherstellt, wenn ein Rack, ein Upstream, ein Hardwarebestand, der Support, die Abrechnung, die Migration oder ein Anbietervertragsausfall auftritt.