LIVEHOSTING Rechenzentrum SRL muss beweisen, ob die vermarktete Kapazität seines Rechenzentrums Strom- und Betreiberbeschränkungen überstehen kann

Zusammenfassung

• LIVEHOSTING Rechenzentrum SRL identifiziert sich öffentlich als Betreiber eines Rechenzentrums in Timisoara und als Inhaber von AS41635. Seine aktuellen Verkaufsseiten bieten Webhosting, virtuelle und dedizierte Server, Serververwaltung und Colocation 1U-3U an.
• Das öffentliche Netzumfang ist aktiv, nicht nur registriert. RIPEstat beobachtete 89.38.208.0/22 von AS41635 am 12. Juli 2026, sichtbar für die 326 meldenden IPv4-Peers in seinem Routing-Status-Snapshot, mit AS12302 und AS39737 als beobachteten Nachbarnetzen.
• Die physischen Beweise sind weniger aktuell. Ein rumänischer Branchenführer von 2012 berichtete von einem 30 Quadratmeter großen Datenraum, zwei dreiphasigen 50-kW-Stromversorgungen, einem 100-kW-Dieselgenerator und vier 40-kW-USV-Anlagen. Diese Zahlen sind eine nützliche historische Information, belegen aber nicht die Ausrüstung, Last, Autonomie oder Redundanz im Jahr 2026.
• Die Colocation-Seite listet zwei Stromversorgungen, eine USV, einen Generator, DDoS-Schutz und einen 1-Gbit/s-Internetzugang auf. Sie veröffentlicht nicht die Trennung der A/B-Stromkreise, die Brennstoffdauer des Generators, die Kühlungsredundanz, die Glasfaseranschlüsse, die Betreiberverpflichtungen, die Ergebnisse von Wartungstests oder einen zweiten Wiederherstellungsstandort.
• Das Netzwerk-Beweismittel ist Mittel. Es gibt überzeugende Beweise für einen aktuellen Dienst und eine geroutete Betriebsfläche, aber nicht genügend aktuelle und unabhängige Beweise, um die vermarktete Kapazität als gleichzeitig wartbar oder nach einem Ausfall der Anlage oder eines Betreibers demonstrierbar wiederherstellbar zu betrachten.

Die Behauptung ist ausreichend spezifisch, um getestet zu werden

LIVEHOSTING Rechenzentrum SRL versteckt sich nicht hinter einer vagen Cloud-Bezeichnung. Seineaktuelle Kontaktseitenennt die rumänische Rechtsgesellschaft, gibt die Registernummer J35/815/2010 und die Steuernummer RO26963713 an, identifiziert AS41635 und gibt an, dass das Unternehmen sein eigenes Rechenzentrum in Timisoara betreibt. SeinColocation-Angebotplatziert die Ausrüstung der Kunden in dieser Einrichtung und listet USV- und Generatorschutz auf. Dies ist konkreter als ein Wiederverkäufer, der nie einen Standort oder ein Netzwerk identifiziert.

Die Spezifität schafft eine nützliche Beweislast. Wenn ein Anbieter angibt, die Infrastruktur auf Gebäudeebene hinter den Arbeitslasten der Kunden zu betreiben, ist die relevante Einheit nicht der virtuelle Server, der auf einer Preisseite angezeigt wird. Es ist die gesamte Kette vom Netzanschluss über USV, Generator, Stromverteilung, Kühlung, Rack, Switch, Edge-Router, Betreiberpfad bis zum Techniker. Jedes Glied kann die Kapazität reduzieren, die Kunden bei einem Ausfall tatsächlich nutzen können.

Der öffentliche Bereich des Unternehmens umfasst mehrere Arten von Abhängigkeiten. SeineStartseitebietet Windows- und Linux-Hosting, virtuelle Server, dedizierte Server, Colocation und Serververwaltung. Kunden von Shared Hosting sind auf eine vom Anbieter kontrollierte Plattform angewiesen. Kunden von virtuellen Servern sind auf das Host-Design und den Speicher angewiesen, den sie nicht direkt überprüfen können. Kunden von dedizierten Servern sind auf die Hardware, das Switching und den Fernzugriff angewiesen. Colocation-Kunden besitzen mehr vom Server, sind aber weiterhin von der Einrichtung und dem Netzwerk abhängig. Ein Ausfall auf der gemeinsamen Ebene der Stromversorgung oder des Betreibers kann daher Produkte betreffen, die auf Abrechnungsebene unterschiedlich erscheinen.

Der entscheidende Unterschied besteht zwischen Betriebsnachweis und Resilienznachweis. AS41635 und das aktuelle Produktkatalog liefern ein überzeugendes Argument, dass LiveHosting in Betrieb ist. Sie zeigen nicht von selbst, welche Last den Verlust eines Strompfads, einer USV-Kette, einer Kühlungseinheit, eines Edge-Routers oder eines Glasfaseranschlusses überlebt. Diese zweite Frage bestimmt, ob ein kleines Rechenzentrum in Timisoara an einem normalen Tag einfach verfügbar oder an einem schwierigen Tag wiederherstellbar ist.

Ein aktueller Dienst hinter einem kleinen öffentlichen Fußabdruck

Die öffentlichen Beweise stützen eine echte Geschäftstätigkeit. LiveHosting veröffentlicht Preise für virtuelle Server, dedizierte Server und Colocation, unterhält Kundenkontoseiten und Bestellseiten und gibt einen Kontakt für Netzwerkmissbrauch an. SeineSeite für SSD-Virtuelle-Serverlistet sechs Konfigurationen auf, während seineNVMe-Seitesechs weitere auflistet. Seine Dedicated-Server-Seiten bewerben Systeme wieHP ProLiant DL360 G7undG8mit redundanten, hot-swap-fähigen Netzteilen und mehreren Netzwerkschnittstellen.

Diese Seiten belegen eine Verkaufsoberfläche, keinen Bestand. Sie sagen nicht, wie viele physische Hosts installiert sind, wie viele für die sofortige Lieferung verfügbar sind, welcher Anteil von CPU und Speicher belegt ist, oder ob Ersatzsysteme und -festplatten vor Ort gelagert werden. Eine Konfiguration kann bestellbar bleiben, während das letzte geeignete Gehäuse verwendet wird, ein Ersatzteil repariert wird oder neue Netzteile nicht in ein Rack eingebaut werden können. Käufer sollten die aufgelisteten Konfigurationen daher eher als vermarktete Serviceklassen denn als geprüfte installierte Kapazität betrachten.

Der öffentliche Fußabdruck des Unternehmens scheint ebenfalls klein.Das Firmenprofil von Termene.ro, einem Aggregator für rumänische Unternehmensinformationen, meldet einen Umsatz von RON736.213 für 2024, einen Nettogewinn von RON286.410 und durchschnittlich einen Mitarbeiter. LinkedIn hingegen ordnet das Unternehmen in eine Spanne von zwei bis zehn Mitarbeitern ein und gibt an, seit 2006 mehr als 4.000 Kunden bedient zu haben. Keine dieser Quellen belegt die aktuelle Anzahl der für einen nächtlichen Vorfall verfügbaren Ingenieure. Subunternehmer, angeschlossenes Personal, Techniker der Betreiber und Gebäudepersonal können alle außerhalb eines rechtlichen Durchschnitts oder einer Social-Media-Spanne liegen.

Diese Unsicherheit ist von Bedeutung, ohne dass eine Unfähigkeit eines kleinen Teams impliziert wird. Kleine Betreiber können technisch diszipliniert und reaktionsschnell sein. Sie können auch stark auf das Wissen eines einzigen Administrators und auf Lieferanten angewiesen sein, deren Reaktionszeiten außerhalb des Kundenvertrags liegen. Die relevanten Beweise sind ein aktuelles Serviceprotokoll, eine Eskalationsregelung, eine Zugriffsliste und ein Supportrecht der Lieferanten. Öffentliche Personalzahlen machen diese Fragen nur dringlicher.

Timisoara ist der Dienstort, aber kein vollständiger Lageplan

LiveHosting gibt wiederholt an, ein eigenes Rechenzentrum in Timisoara zu betreiben. Seine rechtlichen Kontaktdaten platzieren den Firmensitz in Dumbravita, direkt außerhalb der Stadt, während die Colocation-Seite den Dienstort als „LiveHosting Rechenzentren Timisoara“ angibt. Dies sind kompatible Aussagen, aber sie belegen nicht, dass sich Firmensitz, Datenraum und jeder beworbene Server an derselben Adresse befinden.

Der Anlageneintrag von Datacenters Mapbeschreibt eine LiveHosting-Einrichtung weniger als zwei Kilometer vom Stadtzentrum Timisoaras entfernt und gibt an, dass der genaue Standort nicht öffentlich ist. Seine Ökosystemseite meldet keine Netzwerk- oder Dienstanbieterdaten für den Standort. Datacenters Map ist ein kommerzielles Verzeichnis, kein technischer Audit, aber das Fehlen einer genauen öffentlichen Adresse verstärkt eine wichtige Grenze: Die Stadt ist belegt; die Gebäudeidentität und die Eigentumsstruktur sind es nicht.

„Eigenes Rechenzentrum“ kann mehrere Arrangements beschreiben. Das Unternehmen kann die Immobilie und alle mechanischen und elektrischen Einrichtungen besitzen. Es kann den Computerraum in einem gemieteten Gebäude besitzen. Es kann Racks und Switching betreiben, während ein Eigentümer den Netzanschluss, die Brandschutzsysteme oder die Kühlung kontrolliert. Es kann die Generatorwartung oder die Sicherheit auslagern. Keines dieser Modelle ist grundsätzlich mangelhaft. Sie schaffen unterschiedliche Wiederherstellungsrechte und unterschiedliche Lieferantenverantwortlichkeiten.

Ein Kunde, der Colocation in Betracht zieht, sollte eine Verantwortungsmatrix anfordern. Sie sollte identifizieren, wer das Gebäude besitzt, wer jede Stromstufe betreibt, wer die Kühlung wartet, wer den physischen Zugang kontrolliert, wer den Generator-Kraftstoffvertrag hält, wer die externe Glasfaser besitzt und wer Notfallarbeiten autorisieren kann. Sie sollte auch den rechtlichen Firmensitz von der Anlagenadresse und allen Ausweichstandorten unterscheiden. Ohne diese Karte ist der Ausdruck „eigenes Rechenzentrum“ nützlich, aber unvollständig.

Der Dienstbereich ist auf Netzwerkebene am klarsten. AS41635 ist in Rumänien registriert, das Produkt wird auf Rumänisch verkauft, und ein IPinfo-Traceroute erreichte im Juni 2026 eine Adresse im Ursprungsblock über Prime Telecom bis zu einem mit Timisoara gekennzeichneten Ziel. Dies unterstützt eine rumänische Zustellung. Es belegt nicht, dass jedes Backup, jeder Kontrolldienst, jede Überwachungssonde oder jede Kundenkopie in Rumänien verbleibt.

Ein detaillierter Schnappschuss von 2012 kann die Anlage von 2026 nicht bestätigen

Die spezifischste öffentliche Beschreibung der physischen Anlage erscheint im LeitfadenRechenzentrum 2012von Market Watch. Der Leitfaden berichtete von einem 30 Quadratmeter großen Datenraum, zwei dreiphasigen Transformator-Stromversorgungen mit einer Nennleistung von je 50 kW, einer von Electrica und einer von CET, einem 100-kW-Dieselgenerator und vier USV-Anlagen mit je 40 kW. Er listete auch 1-Gbit/s-Kommunikation, Dell-Server, Speicher und Netzwerk, Überwachung über PRTG und DRAC sowie ISO-9001- und ISO-27001-Zertifizierungen auf.

Dies ist ein wertvoller historischer Beleg, da er Maßstäbe und Topologien liefert, die die aktuelle Website nicht bietet. Er ist jedoch vierzehn Jahre alt. Ausrüstung altert, Batterien werden ersetzt, Kühlung wird erweitert, Verkabelung wird erneuert, Betreiberverträge ändern sich und Einrichtungen ziehen um. Der Leitfaden mag die damalige Beschreibung des Anbieters genau erfasst haben, sagt aber wenig über die Anlage aus, die heute Kunden bedient.

Die Zahlen bedürfen ebenfalls der Interpretation. Zwei Nennleistungen von 50 kW bedeuten nicht zwangsläufig 100 kW belastbare Computerlast. Wenn jede Stromversorgung den gesamten Raum versorgen können muss, liegt die belastbare Nutzkapazität möglicherweise näher an der nutzbaren Leistung des kleinsten Pfads nach Verlusten und Nicht-Computerlasten. Ein 100-kW-Generator legt nicht die Computerlast fest, die er nach Abzug von Kühlung, USV-Verlusten, Beleuchtung, Pumpen und Einschaltströmen unterstützen kann.

Vier 40-kW-USV-Anlagen zeigen nicht, ob sie in N, N+1, 2N oder als separate Systeme zur Unterstützung unterschiedlicher Lasten konfiguriert waren.

Die aktuelle Website muss daher parallel und nicht verschmolzen mit dem Leitfaden von 2012 gelesen werden. Die aktuellen Seiten belegen, dass Colocation- und Serverprodukte weiterhin vermarktet werden. Der alte Leitfaden zeigt, was das Unternehmen einst offengelegt hat. Kein hier geprüftes öffentliches Dokument verknüpft die historischen Daten mit einem aktuellen Einlinien-Schaltplan, einem Inbetriebnahmebericht, einem Lasttest, einem Batteriezustandsbericht oder einem Brennstoffdauertest. Bis diese erscheinen, sind die historischen Zahlen eine Grundlage für Fragen, kein Zertifikat für die aktuelle Kapazität.

Zwei Server-Netzteile beweisen nicht zwei unabhängige Strompfade

Die aktuelle Colocation-Tabelle listet „2“ unter Stromversorgungen für ihre 1U-, 2U- und 3U-Pläne. Die Dedicated-Server-Seiten bewerben ebenfalls doppelte 750-W-Hot-Swap-Netzteile. Dies ist ein gutes Design auf Komponentenebene: Ein Server kann nach dem Ausfall eines Netzteils weiterlaufen, wenn das andere Netzteil und sein Eingang intakt bleiben. Die Resilienz hängt jedoch davon ab, wohin die beiden Kabel führen.

Wenn beide Server-Netzteile an derselben Rack-PDU angeschlossen sind, bleibt die PDU ein Single Point of Failure. Wenn zwei PDUs am selben USV-Ausgang oder derselben Verteilerplatine angeschlossen sind, bleibt der vorgelagerte Strompfad gemeinsam. Wenn separate USV-Systeme von einem einzigen Umschalter oder einem einzigen Generator abhängen, kann ein Ausfall an dieser Stelle beide scheinbaren Stromversorgungen unterbrechen. Selbst physisch getrennte Stromanschlüsse können sich eine Umspannstation, einen Kabelweg oder einen Schutzplan außerhalb des Gebäudes teilen.

Aus diesem Grund unterscheidet dieErklärung des Tier-Klassifizierungssystems des Uptime Institutezwischen redundanten Komponenten, gleichzeitiger Wartbarkeit und Fehlertoleranz. Eine zweite Komponente ist nicht dasselbe wie ein zweiter Versorgungspfad. Der Artikel weist LiveHosting keine Tier-Stufe zu; die hier geprüfte Unternehmensseite beansprucht keine, und der Leitfaden von 2012 hat ausdrücklich keine Uptime-Klassifizierung angegeben. Der Rahmen ist nur nützlich, um zu klären, welche Beweise eine stärkere Sprache stützen würden.

Für jedes Rack, das als Doppelstromversorgung verkauft wird, sollte LiveHosting die Pfade A und B vom Netz oder Generator durch Schaltanlage, USV, Verteilung und PDU aufzeigen können. Es sollte angeben, welche Geräte mit einem einzigen Kabel auskommen und ob Umschalter verwendet werden. Es sollte die maximale Rack-Leistung, die Nennleistung des Leistungsschalters, die zulässige stationäre Last und die Messmethode veröffentlichen. Die Colocation-Seite gibt an, dass der Stromverbrauch inbegriffen ist, aber sie beziffert keine Stromzuteilung.

Diese Auslassung erschwert die Übersetzung eines 1U-, 2U- oder 3U-Raums in eine sichere und kommerziell durchsetzbare Stromzusage.

Der wichtigste Test ist kein reines. Es ist eine kontrollierte Übergabe unter realistischer Last, während die Kundenausrüstung online bleibt, gefolgt von einem Nachweis, dass sich Batterien, Generator, Kühlung und Netzwerkausrüstung wie erwartet verhalten haben.

Das Vorhandensein eines Generators ist nicht dasselbe wie seine Ausdauer

Die aktuelle Verkaufsseite listet einen Generator auf, und der Leitfaden von 2012 berichtete von einem 100-kW-Dieselaggregat. Ein Generator kann eine lange Netzunterbrechung überbrücken, aber nur, wenn das gesamte Unterstützungssystem funktioniert: automatische Erkennung, Starterbatterien, Umschalteinrichtung, Kraftstoff, Kühlung, Abgas, Wartung, Lastannahme und Zugang zum Nachfüllen. Das Wort „Generator“ gibt keine dieser Bedingungen preis.

Die Autonomie ist die erste fehlende Zahl. Ein Tank kann Stunden bei Teillast, aber viel weniger bei Nennlast überstehen. Der Kraftstoffverbrauch ändert sich mit dem Strombedarf, und der Bedarf der Anlage umfasst mehr als die Server. Die Kühlung muss während eines Netzausfalls weiterlaufen; sonst kann der Generator die Computerausrüstung mit Strom versorgen, während die Raumtemperatur auf eine erzwungene Abschaltung ansteigt. Eine öffentliche Autonomie sollte daher die unterstützte kritische Last, den Mindestkraftstoff vor Ort, den Nachfüllvertrag und die Annahmen zur Kühlung angeben.

DieRichtlinien des Uptime Institute für Kraftstoffsystemebeschreiben eine Mindestlagererwartung von zwölf Stunden für Tier-Topologien bei der angegebenen N-Last der Anlage. Dies ist ein Referenzpunkt, kein Beweis dafür, dass LiveHosting dies erfüllt oder dieses genaue Design übernehmen muss. Ein kleiner Anbieter kann ein anderes Risikoziel wählen. Wichtig ist, dass Kunden das Ziel kennen und es mit ihren Wiederherstellungsanforderungen vergleichen können.

Tests sind ebenso wichtig wie die Tankgröße. Ein monatlicher Start ohne Last belegt nicht, dass der Generator und das Umschaltsystem den Raum an einem heißen Tag unterstützen werden. Ein aussagekräftiges Protokoll würde Lastübergabetests, Dauer, Lastprozentsatz, Kraftstoffqualität, Alarme, fehlgeschlagene Starts und Korrekturmaßnahmen umfassen. Es würde auch zeigen, ob die beiden aktuellen Transportpfade und die externe Überwachung verfügbar bleiben, wenn die Netzstromversorgung unterbrochen ist.

Die Konsequenz für den Kunden ist direkt. Eine kurze Unterbrechung kann von den USV-Batterien abgefangen werden. Ein längerer Ausfall wird zu einem Generator- und Kraftstoffereignis. Wenn der Generator ausfällt oder die Kühlung nicht aufrechterhalten kann, können alle Produkte im Raum unabhängig von der Anzahl der darüber liegenden VMs, RAID-Sets oder Server-Netzteile auf denselben Stopptermin zusteuern.

Die Kühlung bestimmt, wie viel elektrische Kapazität nutzbar ist

Die hier geprüfte öffentliche Hardware gibt kein aktuelles Kühldesign, keine installierte Kühlkapazität, kein Redundanzniveau, keine Containment-Anordnung oder keinen Umweltbetriebsbereich an. Dieses Fehlen hindert einen Leser daran, die historischen elektrischen Daten in nutzbare Computerkapazität umzurechnen. Fast jedes Watt, das von der Computerausrüstung verbraucht wird, wird zu Wärme, die abgeführt werden muss, und der Raum kann durch die Kühlung begrenzt sein, bevor eine elektrische Nennleistung erreicht wird.

Die 2012 gemeldete Zahl von 30 Quadratmetern sagt auch nichts über die aktuelle Rack-Dichte aus. Ein kleiner Raum mit leicht belasteten Racks kann stabil sein. Derselbe Raum, gefüllt mit Dual-Prozessor-Servern, dichtem Speicher oder Hochgeschwindigkeits-Switching, kann Hotspots entwickeln, selbst wenn die Gesamtleistung des Gebäudes innerhalb einer Nennleistung bleibt. Der Dedicated-Server-Katalog umfasst Systeme mit mehreren Festplatten und Dual-Prozessoren, während die Colocation-Ausrüstung der Kunden weniger vorhersagbar ist. Die Kapazitätszuteilung muss sowohl die Durchschnittswärme als auch die lokale Konzentration berücksichtigen.

Die Kühlungsredundanz umfasst mehrere Ebenen: das Kühlgerät, den Kompressor oder die Kaltwasserquelle, Pumpen und Ventilatoren, das Steuerungssystem, die Stromversorgung und den Wärmeabfuhrpfad. Eine „N+1“-Kühlung kann dennoch gemeinsame Rohrleitungen, Steuerungs- oder Stromabhängigkeiten verbergen. Wartung kann aufschlussreicher sein als ein Ausfall. Wenn ein Kühlgerät an einem heißen Tag nicht isoliert und gewartet werden kann, ohne den Raum unter seine zugesagte Last zu bringen, übersteigt die installierte Kapazität die gleichzeitig nutzbare Kapazität.

Ein Käufer sollte die Temperatur- und Feuchtigkeitsbereiche an den Servereingängen, die Sensorpositionen, die Alarmschwellen, historische Aufzeichnungen, die Reserven bei heißem Wetter und das Ergebnis eines Tests zum Verlust eines Kühlgeräts anfordern. Die Antwort sollte die automatische Abschaltrichtlinie und die Kundenbenachrichtigung erläutern, wenn die Temperatur ansteigt. Sie sollte auch angeben, ob die Generatorkapazität die gesamte erforderliche Kühlung für die zugesagte Computerlast umfasst.

Die Auswirkungen auf Brand und Wasser folgen. Kondensat, Dach- oder Sanitärlecks können einen kompakten Raum schnell beeinträchtigen. Branderkennung und -löschung müssen mit belegten Räumen und unter Spannung stehender elektrischer Ausrüstung kompatibel sein. Das öffentliche Material erwähnt physische Sicherheit und historische Überwachung, liefert jedoch keine aktuellen Nachweise über Brandabschnitte, Leckageerkennung, Löschung oder Überschwemmungszone. Kunden sollten diese Kontrollen nicht allein aus dem Datencenter-Etikett ableiten.

Installierte, verkaufbare und wiederherstellbare Kapazität sind unterschiedliche Zahlen

Der Anbieter kann ehrlicherweise installierte Ausrüstung haben, während weniger Kapazität für Neukunden verfügbar ist und noch weniger Kapazität im Fehlerfall verfügbar ist. Die installierte Kapazität ist die Summe der Typenschilder und konfigurierten Ressourcen. Die verkaufbare Kapazität ist das, was die geschäftlichen und technischen Regeln nach Reservierungen und Überzeichnung zulassen. Die wiederherstellbare Kapazität ist das, was nach dem Ausfall einer definierten Komponente übrig bleibt oder innerhalb der Frist wiederhergestellt werden kann.

Die öffentlichen Seiten von LiveHosting bewerben CPU, Speicher, SSD- oder NVMe-Speicher und „unbegrenzten“ Server-Traffic. Diese Spezifikationen beschreiben ein Recht oder eine Produktkonfiguration. Sie zeigen nicht die Host-Auslastung, die Speicherreplikation, den Uplink-Konflikt oder den Backup-Durchsatz. „Unbegrenzter“ Traffic ist besonders leicht falsch zu interpretieren: Es kann bedeuten, dass keine volumenbasierte Abrechnung erfolgt, während jedes Paket weiterhin einen endlichen Port, ein Edge-Gerät und eine Transitverpflichtung teilt.

Colocation-Raum ist auch ohne Leistung und Netzwerkreserve unvollständig. Drei 1U-Kunden können weniger Strom verbrauchen als ein 3U-Kunde, oder viel mehr, je nach Hardware. Ein 1-Gbit/s-Port ist eine Schnittstellengeschwindigkeit, keine garantierte Internetbandbreite bei einem Angriff oder nach einem Betreiberausfall. Ein Generator-Typenschild ist keine Kundenkapazitätszusage. Eine USV-Leistung ist keine Garantie für Autonomie.

Die operative Kennzahl, die zählt, ist das Budget im Fehlerzustand. Wie viele Kilowatt bleiben, wenn ein Strompfad isoliert ist? Welche Raumtemperatur kann nach dem Verlust einer Kühlungseinheit aufrechterhalten werden? Welche Internetkapazität bleibt, wenn Prime Telecom oder Vodafone ausfällt? Wie viele virtuelle Server können gleichzeitig aus dem Backup neu gestartet werden? Wie viele Ingenieure können gleichzeitig Hardware-, Netzwerk- und Kundenprobleme bearbeiten?

Diese Zahlen sollten an Kundenklassen gebunden sein. Shared Hosting kann eine andere Wiederherstellungszeit tolerieren als eine öffentliche Behörden-Website, eine Transaktionsanwendung, ein Mailserver oder ein Colocation-Unternehmenssystem. Eine kleine Einrichtung muss keine Hyperscale-Kapazität haben, um nützlich zu sein. Sie benötigt Zusagen, die auf ihre tatsächliche Redundanz abgestimmt sind, und eine klare Weigerung, über das Fehlerbudget hinaus zu verkaufen.

AS41635 ist aktiv und weltweit sichtbar

Die Netzwerknachweise sind der stärkste Teil des öffentlichen Dossiers.RIPE RDAPlistet AS41635 als aktiv auf und benennt LIVEHOSTING-AS.Der RIPEstat-AS-Überblickidentifiziert den Inhaber als LIVEHOSTING Rechenzentrum SRL und markiert die ASN als angekündigt. Dies stimmt mit der eigenen Kontaktseite des Unternehmens überein.

Am 12. Juli 2026 zeigteder RIPEstat-Routing-Statuseinen ursprünglichen IPv4-Präfix mit 1.024 Adressen und keinen ursprünglichen IPv6-Präfix. Die IPv4-Route war für die 326 meldenden IPv4-Peers in diesem Snapshot sichtbar.Die RIPEstat-Ansicht der angekündigten Präfixeidentifizierte 89.38.208.0/22 als aktuelle Ankündigung. Die Routing-Verlaufsansicht verfolgt den ursprünglichen Adressraum von LiveHosting bis 2006 zurück, obwohl das Aggregat im Laufe der Zeit von einem /21 auf das aktuelle /22 geschrumpft ist.

Dies ist ein bedeutender Betriebsnachweis. Eine weitgehend sichtbare Route, die über Jahre hinweg aufrechterhalten wurde, ist mit einer rein dekorativen ASN-Registrierung unvereinbar. Das Präfix hostet die eigene Website des Unternehmens und öffentliche Servernamen, und unabhängige Aggregatoren identifizieren es ebenfalls.Hurricane Electrics BGP-Toolkitmeldete einen IPv4-Präfix, 1.024 ursprüngliche IPv4-Adressen, zwei beobachtete IPv4-Peers und keinen IPv6-Ursprung.IPinfostuft die ASN als Hosting ein und zeigt einen Pfad vom Juni 2026, der den Block über AS39737 erreicht.

Die Route ist auch RPKI-gültig.Die RIPEstat-Validierungfand eine gültige Autorisierung für AS41635, 89.38.208.0/22 mit einer maximalen Länge von /22 zu ursprüngen. WieRIPE NCC erklärt, beantwortet die Ursprungsvalidierung, ob der legitime Inhaber der Ressource eine bestimmte Präfix-Ursprung-Kombination autorisiert hat. Sie validiert nicht den Rest des AS-Pfads und belegt keine physische Resilienz.

Die Schlussfolgerung muss eng sein: LiveHosting hat einen aktuellen, gültigen und hochsichtbaren IPv4-Ursprung. Dies ist stärker als ein Marketing-Etikett. Es kann dennoch nicht zeigen, ob die Router dupliziert sind, ob die Betreiber über separate Leitungen eingehen oder ob der überlebende Pfad die Kundennachfrage nach einem Ausfall unterstützen kann.

Die beiden sichtbaren Betreiberpfade benötigen noch physische Beweise

Die RIPEstat-AS-Nachbarn-Ansichtbeobachtete am 12. Juli 2026 zwei benachbarte Netzwerke: AS12302, Vodafone Rumänien, und AS39737, Prime Telecom. Der BGP-Status-Snapshot zeigte die große Mehrheit der abgetasteten Pfade über Prime Telecom und eine kleinere Anzahl über Vodafone. Hurricane Electric listete unabhängig dieselben beiden Peers auf.

Zwei beobachtete Adjazenzen sind besser als eine, da sie potenzielle Routenalternativen bieten. Sie sollten nicht als zwei nachgewiesene unabhängige Betreiber ohne Vertrag und Standortnachweise bezeichnet werden. Ein Route-Collector beobachtet AS-Pfade, nicht die Glasfaser-Eigentumsverhältnisse, Gebäudeeingänge, Interkonnektionen oder bezahlte Kapazität. Ein Betreiber kann einen anderen weiterverkaufen. Zwei Schaltkreise können sich einen städtischen Kabelkanal, einen Schacht, eine Straßenunterführung, ein Patchpanel oder dieselbe externe Stromausrüstung teilen.

Das RIPE-Registerobjekt fügt einen weiteren Grund zur Vorsicht hinzu. Seine Importrichtlinie, zuletzt 2021 geändert, nennt AS6830 und AS34279, während die aktuellen Collectoren AS12302 und AS39737 sehen. Dieser Unterschied kann einfach eine veraltete Registerrichtlinie nach gewöhnlichen Betreiberwechseln widerspiegeln. Er demonstriert, warum eine Registererklärung nicht eine aktuelle Beobachtung oder einen aktuellen Betreiberfahrplan ersetzen sollte.

Die Kapazität nach einem Ausfall ist das nächste Problem. Wenn der Hauptpfad den größten Teil des Datenverkehrs transportiert, muss der sekundäre Pfad über ausreichende zugesagte und Burst-Kapazität verfügen, um ihn zu absorbieren. BGP kann erfolgreich neu konvergieren, während Anwendungen unbrauchbar werden, weil der verbleibende Schaltkreis überlastet ist. DDoS-Schutz fügt eine weitere Abhängigkeit hinzu: Der Anbieter sollte erklären, wo die Filterung erfolgt, ob beide Uplinks sie unterstützen, wie Routen umgeleitet werden und ob ein Schutzereignis die eigene Kapazität reduziert.

Die erforderlichen Beweise sind praktischer Natur. LiveHosting sollte die beiden vertraglich gebundenen Betreiber, die Port- und Commit-Größen, die physischen Demarkationen, die Eingangspfade, die Edge-Router und die Stromversorgungsbereiche identifizieren. Es sollte einen kürzlichen Test zeigen, bei dem jeder Uplink separat unter Last entfernt wurde, die Konvergenz und den Paketverlust aufzeichnen und bestätigen, dass Überwachung und Kundenkommunikation erreichbar blieben.

Fehlendes PeeringDB-Profil schränkt ein, was öffentlich überprüft werden kann

Eine Abfrage derPeeringDB-APIgab bei dieser Prüfung keine Netzwerk-Entität für AS41635 zurück. Dies ist kein Beweis für einen Netzwerkausfall. Die Teilnahme an PeeringDB ist freiwillig, und ein kleines Hosting-Netzwerk kann Transit kaufen, ohne ein öffentliches Interkonnektionsprofil zu pflegen. Das Fehlen verringert die öffentliche Transparenz über Einrichtungen, Austauschpunkte, Verkehrsaufkommen, Peering-Richtlinien und Netzwerkkontakte.

Die aktuelle Form scheint eher transit- als austauschorientiert. Öffentliche Collectoren exponieren zwei benachbarte Netzwerke, aber kein öffentlicher PeeringDB-Eintrag identifiziert einen Internet-Austausch oder eine Einrichtungsverbindung. Kunden sollten daher nicht annehmen, dass das Netzwerk über direktes Peering, diversifizierte Austauschrouten oder einen neutralen Treffpunkt verfügt. Diese Merkmale können existieren; das hier geprüfte öffentliche Dossier belegt sie nicht.

Dies ist für die Fehlerisolierung von Bedeutung. Wenn alle externen Pfade von einem kleinen Satz von Transitübergaben in einem einzigen Gebäude abhängen, kann der lokale Betreibertreffpunkt ein gemeinsamer Fehlerpunkt sein, selbst wenn die globale Routingtabelle zwei Upstream-ASNs zeigt. Wenn ein Schaltkreis außerhalb des Standorts endet und den Datenraum über eine gemeinsam genutzte lokale Leitung erreicht, kann die logische Diversität auf der letzten Meile verschwinden.

Der Anbieter kann einen Großteil dieser Unsicherheit auflösen, ohne vertrauliche Details preiszugeben. Er kann ein netzwerkschematisches Diagramm der Einrichtung veröffentlichen, das getrennte Eingänge, getrennte Edge-Geräte, die Betreiberidentitäten, die Port-Kapazitäten und die Failover-Richtlinie zeigt. Er kann bei Bedarf ein aktuelles PeeringDB-Profil pflegen. Er kann einen Looking Glass oder einen extern gehosteten Statusdienst anbieten. Keine dieser Maßnahmen belegt jeden Kabelkanal, aber zusammen machen sie das Betriebsmodell des Netzwerks leichter überprüfbar.

Das Fehlen eines IPv6-Ursprungs verdient eine direkte Antwort

Die Colocation-Seite von LiveHosting gibt an, dass ein /56-IPv6-Subnetz in jedem Paket enthalten ist. Dennoch zeigten RIPEstat und Hurricane Electric im Juli 2026 null ursprüngliche IPv6-Präfixe von AS41635. Die französische Telekomregulierungsbehörde ARCEP listete AS41635 in ihren Messungen von 2025 bei Hosting-Anbietern ebenfalls mit einer IPv6-Exposition von null auf. Diese Beobachtungen belegen nicht, dass Kunden keinen IPv6-Dienst erhalten.

Das beworbene /56 kann aus dem Adressraum eines Upstream-Anbieters stammen und zu LiveHosting geroutet werden, ohne dass AS41635 einen IPv6-Präfix ursprüngt. Es kann nur auf Anfrage verfügbar sein. Es kann innerhalb der Einrichtung konfiguriert sein, aber in den abgetasteten öffentlichen Daten nicht sichtbar sein. Jede Erklärung hat eine andere Resilienzkonsequenz.

Das vom Anbieter zugewiesene IPv6 kann gut funktionieren, aber der Failover kann vom zuweisenden Anbieter abhängen. Wenn das /56 einem Betreiber gehört und dieser Betreiber ausfällt, kann LiveHosting möglicherweise nicht dasselbe Kundensubnetz über den anderen Pfad ankündigen. Die Renummerierung eines Serverparks während eines Vorfalls ist kein BGP-Failover. DNS, Firewall-Regeln, Zugriffslisten und Client-Software können alle die alten Adressen behalten.

Der Käufer sollte fragen, welches Aggregat das /56 enthält, welche ASN es ursprüngt, ob es über beide sichtbaren Uplinks erreichbar ist und ob die Routenursprungsautorisierung den beabsichtigten Ursprung abdeckt. Er sollte auch fragen, ob der 1-Gbit/s-Port und der DDoS-Schutz gleichermaßen für IPv4 und IPv6 gelten. Ein Dual-Stack-Dienst ist nur so widerstandsfähig wie der am wenigsten getestete Stack, wenn Anwendungen und DNS beide veröffentlichen.

Die Lücke ist wichtig, da IPv6 keine dekorative Funktion ist. Die Colocation-Seite präsentiert es als enthaltene Fähigkeit. Die öffentlichen Routennachweise machen die IPv4-Betriebsfläche klar; gleichwertige IPv6-Nachweise würden das /56 von einer Verkaufszeile in einen überprüfbaren Netzwerkdienst verwandeln.

Die Qualitätsverpflichtung ist enger als eine Anlagengarantie

DieQualitätsverpflichtungvon LiveHosting gilt für Windows- oder Linux-Standard-, Business- und Reseller-Webhosting-Pakete. Sie definiert Verfügbarkeit als den monatlichen Anteil, in dem die Website eines Kunden von einem neutralen Standort aus über HTTP erreichbar ist. Die Seite gibt an, dass LiveHosting PRTG-Systeme in seinem Rechenzentrum und in anderen rumänischen und ausländischen Rechenzentren zur Messung der Verfügbarkeit einsetzt.

Die Gutschriftstaffel erstattet 50 %, wenn die Verfügbarkeit zwischen 98 % und 99,5 % liegt, 75 % zwischen 95 % und 97,9 % und 100 % bei 94,9 % oder weniger. Eine Servicegutschrift ist kommerziell nützlich, aber kein Ersatz für entgangene Umsätze, Daten oder Reputation. Wichtiger ist, dass der angegebene Anwendungsbereich nicht automatisch virtuelle Server, dedizierte Server oder Colocation abdeckt. Käufer dieser Kategorien benötigen eigene Servicebedingungen.

Die Ausschlüsse sind weit gefasst. Die Seite schließt unter anderem Kommunikationsunterbrechung, Brand, Überschwemmung, Naturkatastrophen, Viren, Angreifer, Drittanbieter-Software, angekündigte oder kritische Wartung, Server-Upgrades, DNS außerhalb der Kontrolle von LiveHosting und mehrere Zugriffsprotokolle aus. Einige Ausschlüsse beschreiben genau die Fehlerpfade, die ein Rechenzentrumskunde am meisten verstehen muss. Sie von Gutschriften auszuschließen, macht sie nicht unwahrscheinlich; es verlagert ihre wirtschaftlichen Kosten auf den Kunden.

Die Messdefinition konzentriert sich auch auf die HTTP-Erreichbarkeit. Eine Website kann antworten, während E-Mail, Datenbankverbindungen, Speicher, Control Panels, VPN-Zugriff oder ein Betreiberpfad beeinträchtigt sind. Umgekehrt kann ein Anwendungsfehler HTTP zum Scheitern bringen, während die Stromversorgung und das Netzwerk der Einrichtung intakt bleiben. Kunden benötigen Messungen auf Komponentenebene und eine Vorfallshistorie, die Anlagen-, Netzwerk-, Rechen-, Speicher- und Anwendungsursachen trennt.

Ein stärkeres Versicherungspaket würde historische Serviceleistungen nach Produkt, Wartungsminuten, Vorfallsursachen und Wiederherstellungszeiten veröffentlichen. Es würde angeben, welche Überwachungsstandorte von AS41635 unabhängig sind und ob der Statuskanal während eines vollständigen Anlagen- oder Routenausfalls erreichbar bleibt.

Die Reaktionszeit ist nicht die Wiederherstellungszeit

Die Qualitätsseite verspricht eine maximale Reaktionszeit des technischen Supports von 24 Stunden während der Bürozeiten Montag bis Freitag von 10 bis 18 Uhr. Die aktuelle Kontaktseite listet technischen Support von Montag bis Freitag von 10 bis 17 Uhr. Diese Seiten können verschiedene Kanäle beschreiben oder einfach nicht übereinstimmen. In jedem Fall ist keine der Aussagen ein Versprechen, den Dienst innerhalb von 24 Stunden wiederherzustellen.

DieSerververwaltungsseitefügt eine granularee kommerzielle Unterscheidung hinzu. Die Basic-Verwaltung umfasst zwei Stunden pro Monat und Verfügbarkeit an Werktagen. Die Premium-Verwaltung umfasst vier Stunden pro Monat und gibt Verfügbarkeit von Montag bis Sonntag, 24 Stunden an. Der öffentlicheDienstleistungsvertraggibt an, dass die Verwaltungsarbeit auf die gekauften Abonnementstunden beschränkt ist, zusätzliche Arbeit abrechenbar ist und die Verfügbarkeit oder Leistung von Anwendungen nicht durch den Verwaltungsdienst garantiert wird.

Dies hinterlässt mehrere Fragen für nicht verwaltete dedizierte Kunden und Colocation-Kunden. Ist der Notfalleingriff in der Einrichtung rund um die Uhr verfügbar, auch wenn die Serververwaltung es nicht ist? Wer erkennt einen Alarm für Strom, Kühlung oder Netzwerk um 3 Uhr morgens? Sind Fernhände jederzeit verfügbar, und was ist das Ziel für die Ankunft? Die Colocation-Seite berechnet Fernhände mit 25 EUR pro Stunde, veröffentlicht jedoch keine 24/7-Response-Zusage.

Die Unterscheidung ist in einem kleinen Betrieb kritisch. Die Erkennung kann automatisch sein, aber Diagnose und Autorisierung können von einer Person abhängen. Ein Betreiber kann den benannten Kundenkontakt verlangen. Ein Gebäude kann den Zugang nach Feierabend einschränken. Ein ausgefallener Server kann ein Doppelnetzteil haben, aber dennoch einen lokalen Festplatten- oder Kabelaustausch erfordern. Jede Übergabe fügt Zeit hinzu, bevor die Wiederherstellung beginnt.

Kunden sollten vier separate Uhren verlangen: Alarm-Quittung, Quittung-qualifizierte Diagnose, Diagnose-Vor-Ort-Eingriff und Eingriff-Wiederherstellung. Sie sollten fragen, wem jede Uhr gehört und was passiert, wenn zwei Vorfälle gleichzeitig auftreten. Eine Telefonnummer und ein Ticket-Versprechen sind nützliche Einstiegspunkte; sie sind kein Wiederherstellungsplan.

Wartung kann mehr Risiken aufdecken als ein plötzlicher Ausfall

Redundanz erscheint oft am stärksten, wenn alles gesund ist, und am schwächsten, wenn eine Komponente absichtlich zur Wartung entfernt wird. USV-Batterien müssen ersetzt werden, Generatoren müssen unter Last getestet werden, Kühlgeräte müssen gereinigt werden, Switches müssen aktualisiert werden und Betreiber benötigen Wartungsfenster. Während dieser Zeit kann der verbleibende Pfad die gesamte Last ohne Reserve tragen.

Die Qualitätsverpflichtung schließt angekündigte Wartung, kritische Arbeiten und Server-Upgrades von ihren Gutschriften aus. Dies ist in Hosting-Verträgen üblich, aber das praktische Risiko hängt davon ab, wie die Wartung konzipiert ist. Ein Kunde muss wissen, ob die Einrichtung jede kritische Komponente warten kann, ohne die Computerlast zu stoppen, ob mehrere Anbieter gleichzeitig arbeiten können und wie der Rollback gehandhabt wird.

Für die Stromversorgung sollten die Wartungsnachweise Bypass-Pfade und Verfahren umfassen, die nicht den gesamten Raum auf das rohe Netz legen. Für die Kühlung sollte sie die maximale sichere Last bei isolierter Einheit angeben. Für Netzwerkarbeiten sollte sie zeigen, dass die Kundenrouten über den anderen Router und Betreiber stabil bleiben. Für Speicher oder Virtualisierung sollte sie quantifizieren, wie viel Arbeitslast vor der Wartung verschoben werden kann und wie lange diese Verschiebung dauert.

Die Konzentration von Änderungen ist ein weiteres Anliegen. Ein kleiner Anbieter kann mehrere Aufgaben in dasselbe Fenster planen, um Störungen zu reduzieren, aber die Kopplung von Strom-, Netzwerk- und Host-Änderungen hebt unabhängige Wiederherstellungsoptionen auf. Kunden sollten fragen, ob Change-Approvals gemeinsame Abhängigkeiten berücksichtigen und ob ein von außen erreichbarer Kommunikationskanal außerhalb der betroffenen Systeme aufrechterhalten wird.

Die Beweise, die die Frage klären würden, sind gewöhnliche Betriebsdokumente: ein geschwärzter jährlicher Wartungsplan, Benachrichtigungen über kürzliche Fenster, Nachberichte zur Wartung, Maßnahmen bei fehlgeschlagenen Tests und eine für den Kunden sichtbare Auswirkung. Dies ist überzeugender als ein allgemeines Verfügbarkeitsziel, da es zeigt, wie der Betreiber mit Zeiten umgeht, in denen die Redundanz absichtlich reduziert ist.

Brand, Überschwemmung und Netzverlust laufen auf Kundendaten hinaus

Die Qualitätsverpflichtung erwähnt ausdrücklich Brand und Überschwemmung unter den Ausschlüssen höherer Gewalt. Dies ist eine vertragliche Zuweisung, kein Beweis dafür, dass die Einrichtung exponiert oder ungeschützt ist. Die hier geprüften öffentlichen Seiten geben keinen Aufschluss über das aktuelle Branderkennungs- und Löschsystem, die Brandabschnittsklassifizierung, die Leckageerkennung, die Hochwasserbewertung oder die Entfernung zu Wasser- und Kraftstoffrisiken.

Diese sind wichtiger, wenn viele Serviceebenen einen einzigen Standort belegen. Shared Hosting, VPS, dedizierte Server, Colocation, DNS, E-Mail und Kundenportale können alle vom selben Raum abhängen. Wenn primäre Daten, Backups und Steuerungssysteme die Einrichtung teilen, kann ein Ereignis im Gebäude den Produktionsdienst und die Mittel zu seiner Wiederherstellung beseitigen.

Der öffentliche Dienstleistungsvertrag legt eine erhebliche Verantwortung auf die Kunden und beschränkt die Garantien. Er erlaubt auch die Aussetzung oder Kündigung des Dienstes bei Nichtzahlung und behält weitreichende Rechte zur Änderung oder Unterbrechung von Diensten vor. Diese Bedingungen machen unabhängige Backups und getestete Exportverfahren kommerziell wichtig, selbst wenn kein physischer Vorfall vorliegt.

Ein Kunde sollte identifizieren, wo jede Kopie lebt, wer ihre Anmeldeinformationen kontrolliert, wie oft sie getestet wird und wie die Wiederherstellung funktioniert, wenn das eigene Kundenportal oder Netzwerk von LiveHosting nicht verfügbar ist. Ein Backup auf einem anderen Server im selben Raum schützt vor bestimmten Hardwarefehlern, aber nicht vor Strom-, Kühlungs-, Brand- oder Überschwemmungsereignissen auf Raumebene. Eine Kopie in einem anderen Gebäude, die jedoch über dasselbe unzugängliche Identitätssystem verwaltet wird, kann ebenfalls schwer zu verwenden sein.

Für Colocation-Kunden erstreckt sich die Frage auf die Wiederherstellung der Ausrüstung. Wer kann nach einem Vorfall eintreten? Ist die Kundenausrüstung durch den Anbieter, den Gebäudebetreiber oder den Kunden versichert? Kann ein Kunde seine Ausrüstung während einer längeren Stromausfalls oder Zugangssperre abholen? Die Antworten können in individuellen Verträgen stehen, aber sie werden nicht durch die öffentliche Planungsseite festgelegt.

Der Ausfall betrifft verschiedene Kunden auf unterschiedliche Weise

Kunden von Shared Hosting werden wahrscheinlich zuerst einen Ausfall der gemeinsamen Plattform erleben, da Websites, E-Mail oder Control Panels nicht erreichbar sind. Sie haben möglicherweise wenig Einblick, welcher physische Server, Switch oder Speichersystem ausgefallen ist. Reseller können die Auswirkungen verstärken, da ein Konto viele nachgelagerte Standorte und Supportverpflichtungen repräsentieren kann.

Kunden von virtuellen Servern haben mehr Kontrolle über die Betriebssysteme, bleiben aber von der Hypervisor-Kapazität, dem Speicher und dem lokalen Netzwerk des Anbieters abhängig. Ein Host-Ausfall kann wiederherstellbar sein, wenn die Arbeitslasten an anderem Ort neu gestartet werden können, aber die öffentliche Produktseite verspricht kein Live-Migration, replizierten Speicher oder Wiederherstellungscluster. Das Vorhandensein von SSD oder NVMe sagt nichts über die Anzahl und den Standort der Kopien aus.

Kunden von dedizierten Servern vermeiden einige Risiken gemeinsam genutzter Rechenleistung. Sie bleiben dennoch vom Rack, den beiden Strompfaden, dem Switching, dem Betreibertransit und den Fernhänden abhängig. Doppelte Netzteile und RAID können einige ausgewählte Komponentenfehler abfedern, aber sie können einen Ausfall auf Raumebene oder einen Ausfall der gemeinsam genutzten Netzwerkperipherie nicht überleben. Die öffentlichen Dedicated-Server-Listen zeigen auch ältere G7- und G8-Generationen; dies kann ein wirtschaftliches Angebot sein, aber Käufer sollten die Verfügbarkeit von Ersatzsystemen und -komponenten erfragen.

Colocation-Kunden besitzen ihre eigene Ausrüstung und können ihren eigenen Adressraum ankündigen, wie die Produktseite für BGP-Ankündigungen erlaubt. Ihre Abhängigkeit von LiveHosting ist dennoch physisch. Sie benötigen Zugang, Strom, Kühlung, Interkonnektionen, Routing und Reparaturhilfe. Ein Anlagenausfall kann eine ansonsten vollständig vom Kunden verwaltete Ausrüstung stoppen.

Benutzer aus dem öffentlichen Sektor, dem Gesundheitswesen, dem Finanzwesen oder der Industrie können auch über die Verfügbarkeit hinausgehenden Verpflichtungen unterliegen. Standortbestimmung, Vorfallsbenachrichtigung, Beweissicherung und Anbieterkontinuität können zählen. Der Artikel identifiziert keine solchen LiveHosting-Kunden. Er unterstreicht, warum dieselbe Anlagenbehauptung je nach Arbeitslast, die dort platziert wird, sehr unterschiedliche Konsequenzen haben kann.

Der Anbieter sollte daher einer universellen Resilienzerklärung widerstehen. Er sollte offenlegen, welche Schutzmaßnahmen für jeden Dienst gelten, was der Kunde bereitstellen muss und welche gemeinsamen Abhängigkeiten alle Produktlinien durchziehen.

Eine aussagekräftige Failover-Demonstration muss reale Abhängigkeiten entfernen

Der beste Weg, die aktuelle Resilienz festzustellen, ist das Testen definierter Fehler anstelle der Anhäufung von Etiketten. Für LiveHosting würden fünf Übungen die meisten offenen Fragen beantworten.

Erstens: Entfernen Sie die normale Netzstromversorgung bei einer repräsentativen Produktionslast. Zeichnen Sie die USV-Übergabe, den Generatorstart, die Kühlungskontinuität, den Kraftstoffverbrauch, die Alarme und die Kundenauswirkung auf. Fahren Sie lange genug fort, um das veröffentlichte Autonomieziel zu demonstrieren, und stellen Sie dann die Netzstromversorgung ohne Lastverlust wieder her.

Zweitens: Isolieren Sie jeden Stromverteilungspfad und jeden USV-Abschnitt nacheinander. Bestätigen Sie, dass die dual versorgten Kundengeräte online bleiben, und identifizieren Sie die einfach versorgte Ausrüstung, die eine Umschalteinrichtung erfordert. Ein erfolgreicher Generatortest ersetzt diesen internen Verteilungstest nicht.

Drittens: Entfernen Sie ein Kühlgerät oder einen Kühlpfad während einer anspruchsvollen Umgebungsperiode. Verfolgen Sie die Servereingangstemperaturen und bestätigen Sie, welche Last innerhalb des angegebenen Umgebungsgrenze der Einrichtung bleibt. Dies wandelt eine Behauptung der Kühlungsredundanz in einen Nachweis nutzbarer Kapazität um.

Viertens: Entfernen Sie Vodafone und Prime Telecom separat, während das Netzwerk ausgelastet ist. Messen Sie die BGP-Konvergenz, den Paketverlust, die Latenz und den überlebenden Durchsatz sowohl für IPv4 als auch für den angekündigten IPv6-Dienst. Bestätigen Sie, dass DDoS-Schutz, Überwachung, DNS und Kundenkommunikation auf dem verbleibenden Pfad funktionieren.

Fünftens: Stellen Sie ein repräsentatives Shared-Hosting-Konto, einen virtuellen Server und einen Kontrolldienst aus einer Kopie außerhalb der primären Fehlerdomäne wieder her. Messen Sie die Wiederherstellungszeit und den Datenverlust und berücksichtigen Sie den Fall, dass das normale Kundenportal nicht verfügbar ist.

Die Ergebnisse müssen nicht perfekt sein, um wertvoll zu sein. Eine offengelegte Schwäche, gefolgt von einer Korrekturmaßnahme, ist ein stärkerer Beweis als eine ungetestete Behauptung vollständiger Verfügbarkeit. Kunden können dann beurteilen, ob die demonstrierte Wiederherstellung ihrer eigenen Toleranz entspricht und ob sie einen zweiten unabhängigen Standort benötigen.

Wachstum der Stromversorgung und Genehmigungen müssen als Einschränkungen behandelt werden, nicht als Annahmen

Der europäische Rechenzentrumsmarkt behandelt die Stromverfügbarkeit zunehmend als eine Entwicklungsbeschränkung. DieSeite der Europäischen Kommission zur Energieeffizienz von Rechenzentrenbeschreibt die wachsende Stromnachfrage, die Auswirkungen auf Kühlung und Wasser sowie die Meldepflichten für Anlagen über der relevanten Schwelle. Nichts in den hier geprüften öffentlichen Beweisen belegt, dass LiveHosting die Meldeschwelle von 500 kW überschreitet; die historischen Zahlen deuten auf eine viel kleinere Anlage hin.

Der kleine Maßstab beseitigt nicht die Notwendigkeit, die Stromversorgung zu verwalten. Er verändert das Problem. Ein kompakter Standort kann eine geringere Gesamtnachfrage haben, aber weniger Platz für zusätzliche Schaltanlagen, Kühlung, Batterien, Abgase oder Kraftstofflagerung. Ein städtisches oder vorstädtisches Gebäude kann mit Lärm-, Emissions-, Brandschutz- und Bauauflagen konfrontiert sein. Ein Stromanschluss kann für die aktuelle Last ausreichend sein, aber eine Erweiterung langsam oder teuer machen.

Die aktuelle Website veröffentlicht keine geplante Erweiterung, kein neues Gebäude und keinen Stromantrag. Käufer sollten keine daraus ableiten. Wenn LiveHosting eine neue Hochdichtekapazität vermarktet, sollten die Beweise identifizieren, ob sie aus verbesserter Effizienz, stillgelegter älterer Ausrüstung, einer größeren Stromzuteilung, neuer Kühlung oder einem anderen Standort stammt. Das Wort „verfügbar“ sollte bedeuten, dass Strom, Kühlung und Netzwerk alle in Betrieb genommen sind, nicht nur, dass Rackplatz leer ist.

Genehmigungen beeinflussen auch die Wiederherstellung. Der Austausch eines Generators, die Hinzufügung von Kraftstofflagerung, die Änderung des Stromanschlusses oder die Änderung von Brandschutzsystemen können Genehmigungen und Lieferantenlieferzeiten erfordern. Der Kunde benötigt nicht jede Genehmigungsnummer in der Öffentlichkeit. Er benötigt die Zusicherung, dass die installierte Ausrüstung genehmigt, gewartet und unterstützt wird und dass geplantes Wachstum den bestehenden Raum nicht in einen längeren Zustand reduzierter Redundanz versetzt.

Die angemessene kommerzielle Kennzahl ist die fehlerbereite Kapazität, nicht der theoretische Raum für einen weiteren Server.

Was das Vertrauen stärken würde

LiveHosting kann das Beweismittel mit einem kompakten Satz von Offenlegungen nach oben verschieben. Es sollte mit einem aktuellen, datierten und vom Betreiber versionierten technischen Datenblatt der Einrichtung beginnen. Das Datenblatt sollte die Dienstadresse in angemessenem Umfang, die Grenzen von Betreiber und Eigentümer, die Grundfläche des Datenraums, die in Betrieb genommene Computerlast, den aktuellen gemessenen Spitzenwert, die Rack-Leistungsgrenzen, die Kühlungstopologie und die Brandschutzmaßnahmen angeben.

Der Stromabschnitt sollte die Stromeingänge, die USV-Topologie, die Generatorleistung, die minimale Autonomie bei der zugesagten kritischen Last, die Kraftstoffvereinbarungen sowie Datum und Ergebnis des letzten Lastübergabetests zeigen. Er sollte die installierten Gesamtnennleistungen von der nutzbaren N-Kapazität, der Wartungskapazität und der Fehlerkapazität unterscheiden.

Der Netzwerkabschnitt sollte die aktuellen Beobachtungen von Vodafone und Prime Telecom mit dem älteren RIPE-Policy-Objekt in Einklang bringen. Er sollte die vertraglich vereinbarte Port- und Commit-Kapazität, die Diversität der Edge-Router, die Trennung der physischen Eingänge, die DDoS-Vorkehrungen und den Ursprung des angekündigten /56-IPv6 offenlegen. Ein PeeringDB-Eintrag oder ein aktueller Looking Glass würde die externe Transparenz verbessern, aber die physische Dokumentation nicht ersetzen.

Der Betriebsabschnitt sollte die kontinuierliche Alarmzuständigkeit, die Reaktionsziele der Einrichtung, die Fernhände-Abdeckung, die Ersatzteilbestände und die Lieferanteneskalation angeben. Er sollte die Support-Erklärungen von 10 bis 17 Uhr und 10 bis 18 Uhr in Einklang bringen und klären, was die Premium-24/7-Verfügbarkeit für Reaktion und Wiederherstellung bedeutet.

Schließlich sollte der Betreiber anonymisierte Nachweise von Tests und Vorfällen veröffentlichen: Stromübergabe, Kühlungsausfall, Betreiber-Failover, Wiederherstellungsübungen, bedeutende Wartung und angewandte Lehren. Eine unabhängige Zertifizierung kann das Paket stärken, wenn der Umfang und die aktuelle Gültigkeit klar sind. Zertifizierungsnamen von 2012 sollten ohne aktuelle Zertifikate, Standorte, Normen und Ablaufdaten nicht als aktuell behandelt werden.

Dieses Offenlegungsniveau würde weder Kundendaten noch sensible Grundrisse preisgeben. Es würde es Käufern ermöglichen, zwischen einem funktionalen kleinen Rechenzentrum mit getesteten Grenzen und einem zu unterscheiden, dessen Resilienz hauptsächlich aus Produktkennzeichnungen abgeleitet wird.

Das Beweismittel ist Mittel

LIVEHOSTING Rechenzentrum SRL erhält ein Netzwerk- und Infrastrukturbeweismittel von Mittel. Die betriebsspezifischen Beweise sind substanziell: eine aktive rumänische Verkaufswebsite, eine benannte juristische Person, ein explizites Colocation-Angebot in Timisoara, AS41635, eine weltweit sichtbare IPv4-Route, zwei beobachtete benachbarte Netzwerke, eine gültige Routenursprungsautorisierung und Jahre an Routing-Verlauf. Dies ist kein Fall, in dem die Existenz des Anbieters oder der grundlegende Netzwerkbetrieb von einem einzigen Verzeichniseintrag abhängt.

Das Niveau stoppt bei Mittel, weil die Resilienzbehauptungen nicht mit aktuellen physischen Beweisen untermauert sind. USV und Generator sind aufgeführt, aber Topologie und Autonomie fehlen. Zwei Server-Netzteile sind aufgeführt, aber die A/B-Trennung nicht. Ein Leitfaden von 2012 bietet detaillierte Daten, aber keine Inbetriebnahme- oder Lastnachweise verbinden diese Zahlen mit der Anlage von 2026. Kühlung, Brand, Überschwemmung, Glasfasereingänge, Betreiberverpflichtungen, Wartungsleistung, externe Wiederherstellung und Kunden-Failover-Ergebnisse bleiben in den geprüften Quellen nicht offengelegt.

Die beiden aktuellen BGP-Adjazenzen unterstützen eine logische Pfaddiversität, während das Fehlen eines physischen Routennachweises eine stärkere Schlussfolgerung verhindert. Die gültige IPv4-Route reduziert das Ursprungsrisiko, während das Fehlen eines IPv6-Ursprungs von AS41635 die angekündigte /56-Vereinbarung ungelöst lässt. Die Qualitätsverpflichtung gibt Kunden einen Mess- und Gutschriftmechanismus, während ihr Produktumfang und ihre Ausschlüsse einschränken, was sie über die Wiederherstellung auf Anlagenebene aussagt.

Dieses Niveau ist kein Urteil über die Servicequalität. Es ist eine Aussage darüber, wie weit das Beobachtbare von dem entfernt ist, was noch gezeigt werden muss. LiveHosting kann aktuellere technische Aufzeichnungen besitzen, als es veröffentlicht. Ein Käufer sollte verlangen, sie zu sehen, bevor er eine Arbeitslast platziert, deren Ausfallkosten den Wert der Servicegutschriften übersteigt.

Die enge Schlussfolgerung ist, dass die vermarktete Kapazität als Live-Dienst glaubwürdig ist, aber noch nicht als Fehlerkapazität nachgewiesen ist. Der nächste nützliche Beweis ist keine weitere Serverkonfiguration. Es ist ein aktueller Test von Strom, Kühlung und Transport, der zeigt, was online bleibt, wenn eine der gemeinsamen Abhängigkeiten absichtlich entfernt wird.