Zusammenfassung

  • CloudTeknoloji ist das Unternehmen hinter daha.net. Die öffentlicheSeite mit Geschäftsinformationennennt CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. als juristische Person, gibt daha.net als Marke an, listet eine Adresse in Istanbul, Telefon, MERSIS-Nummer und Handelsregisternummer auf und beschreibt Hosting-, Cloud-Server-, Domain-, SSL-, E-Mail- und damit verbundene IT-Dienstleistungen.
  • Die Aussage über die Infrastruktur ist spezifisch, aber nicht völlig unabhängig. DieÜber-uns-Seitegibt an, dass die Systeme von daha.net von Istanbul 4. Levent aus verwaltet werden und in den ICS-Rechenzentren in Istanbul gehostet werden, mit Behauptungen zu Tier III, PCI/DSS, redundanter Internetkapazität, betreiberunabhängiger Glasfaser, USV, A+B-Stromversorgung, physischer Sicherheit und Kühlung. Leser sollten diese Behauptungen als Unternehmensangaben betrachten, sofern sie nicht durch Kundenverträge oder Standortzertifikate bestätigt werden.
  • Der öffentliche Routing-Fußabdruck ist aktuell und klein. DieAS-Übersicht von RIPEstatzeigt AS202048 für CloudTeknoloji angekündigt, und dieDaten der angekündigten Präfixezeigen ein sichtbares Präfix, 46.28.232.0/24, im Zeitraum Ende Juni bis 12. Juli 2026. DieRIS-Präfixzählungenzeigen ein IPv4-Ursprungspräfix, keine Transitpräfixe und kein IPv6-Ursprungspräfix.
  • Die Hauptfrage des Kunden ist nicht, ob daha.net existiert. Es geht darum, inwieweit die Website, VPS, E-Mail, DNS, Backup und der Migrationsplan eines Kunden an einen einzigen Standort in Istanbul, einen kleinen gerouteten Adressblock, den derzeit beobachteten vorgelagerten Pfad über ICS, die Support-Reaktionsfenster und die vertraglichen Bedingungen gebunden sind, die einen Teil der Backup- und Datenverlustverantwortung auf den Kunden übertragen.

Das Unternehmen ist klarer als viele leichte Hosting-Namen

Die öffentliche Identität von CloudTeknoloji ist für einen kleinen Hosting-Betreiber ungewöhnlich gut definiert. DieGeschäftsinformationsseitevon daha.net gibt den rechtlichen Namen als CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. an, gibt daha.net als Marke an, listet das Finanzamt Maslak, die Steuernummer 5470543764, die MERSIS-Nummer 0547054376400001 und die Handelsregisternummer 759033 auf und gibt an, dass das Unternehmen 2010 gegründet wurde. Dieselbe Seite listet eine Adresse in Sultan Selim Mahallesi, NEF 09 Plaza 4. Levent B Blok No:7/121, Kagithane, Istanbul, sowie Telefon, Fax, E-Mail und KEP-Kontaktdaten auf.

Dies ist wichtig, da es sich nicht um einen anonymen Domain-Namen-Verkäufer handelt. Ein Käufer kann die Marke, das Unternehmen, die Adresse, die Registeridentität und die öffentliche Netzidentität verknüpfen. DieRIPE-Organisationsregistrierung für ORG-SBHv1-RIPElistet Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. in der Türkei, zeigt dieselbe Handelsregisternummer, identifiziert den Organisationstyp als LIR und gibt eine Adresse in Kagithane, Istanbul, und eine Telefonnummer an. DieRIPE-aut-num-Registrierung für AS202048nennt das AS CloudTeknoloji, beschreibt es als Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. und verknüpft es mit derselben RIPE-Organisation.

Die Markengeschichte vervollständigt dann das Kundenangebot. DieÜber-uns-Seitegibt an, dass daha.net seit 2010 tätig ist und Privat- und Geschäftskunden mit Hosting- und Serverdiensten bedient. Sie präsentiert die Marke als Teil von Cloud Teknoloji Bilisim Hizmetleri Ticaret Anonim Sirketi und beschreibt ein Dienstleistungspaket, das Hosting, Cloud-Server, Reseller-Hosting, Domain, SSL und Geschäfts-E-Mail umfasst. DieKontaktseitegibt die öffentliche Telefonnummer, Fax, Support-E-Mails, Adresse und KEP-Kontaktdaten an, sodass Käufer einen sichtbaren Weg für Vertrieb, Support und formelle Mitteilungen haben.

Das Unternehmen operiert also nicht hinter einer völlig undurchsichtigen Fassade. Die Beweise stützen einen echten türkischen Hosting-Anbieter, ein benanntes juristisches Unternehmen, eine Marken-Einzelhandelsplattform, eine RIPE-LIR-Identität und ein angekündigtes AS. Die Einschränkung beginnt nicht bei der Identität, sondern bei der Größe und Redundanz. Öffentliche Aufzeichnungen können das Unternehmen und ein geroutetes Netz beweisen.

Sie beweisen nicht, wie viel Hardware bereitgestellt ist, wie viele Racks direkt kontrolliert werden, wie viel Reservekapazität reserviert ist, wie oft Failover getestet wird oder ob eine Kundenwiederherstellung ohne den Hauptstandort in Istanbul möglich ist.

Der geroutete Fußabdruck ist real, aktuell und klein

Das öffentliche Netzwerkbild ist einfach. DieRIPEstat-AS-Übersicht für AS202048zeigte den Inhaber als CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. und markierte das AS am 12. Juli 2026 als angekündigt. DieRIPEstat-Daten der angekündigten Präfixezeigten ein sichtbares Präfix, 46.28.232.0/24, vom 28. Juni 2026 bis 12. Juli 2026. DieRIPEstat-RIS-Präfixzählungenzeigten zum Zeitpunkt der Anfrage am 12. Juli ein IPv4-Ursprungspräfix, null IPv4-Transitpräfixe, null IPv6-Ursprungspräfixe und null IPv6-Transitpräfixe.

Dies reicht aus, um einen laufenden öffentlichen Betrieb zu zeigen. DieRIPEstat-Präfixübersicht für 46.28.232.0/24markiert das /24 als von AS202048 angekündigt. DieRIPEstat-Routing-Statusdatenzeigten, dass 325 von 326 IPv4-Voll-Flow-Peers die Route zum abgetasteten Zeitpunkt sahen, mit einem sichtbaren IPv4-Präfix und 256 angekündigten IPv4-Adressen. Dies zeigte auch null sichtbaren IPv6-Raum und einen beobachteten Nachbarn. DieRPKI-Validierunggab einen gültigen ROA für AS202048 und 46.28.232.0/24 mit einer maximalen Länge von 24 zurück.

Dieselben Beweise begrenzen den Anspruch. Ein einzelnes /24 ist ein kleiner öffentlicher Adressraum. Es kann autoritative Nameserver, Hosting-Knoten, Mail-Relays, Management-Endpunkte, Kunden-VPS-Dienste oder Überwachungssysteme tragen, aber es ist kein Beweis für eine ausgedehnte regionale Cloud-Region. Das Fehlen einer sichtbaren IPv6-Ursprungsadresse ist besonders bemerkenswert für einen modernen Cloud- und Hosting-Anbieter.

Die reine IPv4-Sichtbarkeit macht die Dienste nicht unbrauchbar, aber sie zeigt, dass Kunden, die Dual-Stack-öffentliche Dienste benötigen, eine explizite IPv6-Verfügbarkeit erfragen sollten, anstatt anzunehmen, dass sie existiert.

Es gibt auch keinen öffentlichen PeeringDB-Netzwerkeintrag für diese ASN: DiePeeringDB-Suche nach ASN 202048gibt einen leeren Datensatz zurück. Das Fehlen von PeeringDB ist kein Beweis für technische Schwäche. Viele kleine Anbieter verlassen sich auf vorgelagerten Transit und pflegen keine öffentlichen Austauschprofile. Dennoch entfällt damit ein gängiger unabhängiger Ort, an dem Betreiber Standortpräsenz, Verkehrsaufkommen, Austauschrichtlinien, NOC-Kontakte und Austauschverbindungen veröffentlichen. Für CloudTeknoloji sagen die sichtbaren öffentlichen Daten: „Reales geroutetes AS, ein aktuelles IPv4-/24, gültige Routenautorisierung, keine sichtbare IPv6-Ursprungsadresse, kein öffentliches Austauschprofil.“

Dies ist eine mittlere Beweisqualität, nicht negativ. Das Netz ist sichtbar und aktuell, aber es lässt den Kunden private Beweise für Multi-Site-Kapazität, Transitdiversität, Reserve-Host-Kapazität und Wiederherstellungspfad-Design anfordern.

Die Rack-Grenze ist Istanbul, nicht eine Cloud ohne Standort

Die eigene Standortssprache des Unternehmens ist präzise genug, um das Risikogespräch zu gestalten. DieÜber-uns-Seitegibt an, dass die Systeme von einem Betriebszentrum in Istanbul 4. Levent aus verwaltet und in den ICS-Rechenzentren in Istanbul gehostet werden, die als PCI/DSS-zertifiziert und nach Tier-III-Standard beschrieben werden. Sie beansprucht außerdem mehr als 100 Gbps redundante Internetzugangskapazität, betreiberunabhängige Glasfaser, vollständig redundante USV- und Stromsysteme, doppelte A+B-Stromversorgung, physische Sicherheit und Kühlung. DieDienstleistungspolitikwiederholt die Standortbehauptung einfacher: Die Server von daha.net werden in den ICS-Rechenzentren in Istanbul, Tier III, gehostet.

Dies verwandelt das Marketingwort „Cloud“ in einen Ort. Der Dienst des Kunden hängt von Racks in Istanbul, einem Standortbetreiber, Stromverteilung, Kühlung, Verkabelung, Interconnections, Switch-Ports, Transit-Sessions, Speicher, Hardware-Inventar und Personen ab, die Reparaturen durchführen können. Einige dieser Elemente können direkt von CloudTeknoloji kontrolliert werden. Andere fallen unter die ICS-Rechenzentren oder vorgelagerte Betreiber.

Die öffentlichen Seiten geben nicht preis, welche Racks gemietet werden, welche Ausrüstung CloudTeknoloji besitzt, wie viel Standortkapazität für daha.net reserviert ist oder ob dieselben Produkte auf eine andere türkische Stadt oder ein anderes Land ausweichen können.

Die Unterscheidung ist wichtig für die Datenlokalität. Das Angebot von CloudTeknoloji ist für türkische Kunden unter anderem deshalb attraktiv, weil es Hosting- und Serverkapazität in der Türkei zu halten scheint. DieVDS-Seitebewirbt den Standort Istanbul, VMware ESXi-Virtualisierung und VDS-Pakete mit SSD-Speicher. DiePro-Cloud-Seitebewirbt erneut den Standort Istanbul, mit Xeon Gold 6138-Prozessoren, verwaltetem Support und NVMe-SSD-Speicher. DieHosting-Seitebewirbt Hosting am Standort Istanbul, Linux LiteSpeed, Windows IIS, kostenloses SSL und wöchentliche Backups. DieRIPEstat-Geolokalisierungsdaten für 46.28.232.0/24platzieren das öffentliche Präfix zum überprüften Zeitpunkt ebenfalls in der Türkei.

Lokalität ist jedoch nicht gleichbedeutend mit Resilienz. Ein türkischer Standort kann die Anforderungen eines Kunden an Gerichtsbarkeit, Latenz oder Sprachsupport erfüllen, während der Kunde dennoch einem Single-Site-Ausfall ausgesetzt ist. Wenn der primäre Hosting-Dienst, die Backup-Kopie, das Support-Portal und das Kunden-DNS alle vom selben Campus oder derselben Betreiberübergabe abhängen, hat der Kunde lokale Kontrolle, aber begrenzte Unabhängigkeit.

Eine stärkere Kontinuitätsbehauptung würde einen zweiten Standort, einen getesteten Wiederherstellungsort, einen separaten administrativen Bereich, ein definiertes Wiederherstellungszeitziel und einen klaren Exportpfad nennen.

Der Dienstleistungskatalog verkauft Schichten, nicht nur Server

Die Produktpalette von daha.net ist breiter als ein enger VPS-Shop. DieGeschäftsinformationsseitegibt an, dass das Unternehmen in den Bereichen Webhosting, Cloud-Server, Domain-Registrierung, SSL-Zertifikate, E-Mail und damit verbundene IT-Dienstleistungen tätig ist. Die Navigation und die Produktseiten zeigen dieselbe Breite:Standard-VDS-Cloud-Server,Managed Pro-Cloud-Server,Webhosting, WordPress-Hosting, Reseller-Hosting, Geschäftshosting, Domain-Dienste, SSL-Zertifikate, Control-Panel-Lizenzen, Microsoft 365, Massen-E-Mail und Server-Wartungsdienste.

Diese Breite ist kommerziell nützlich. Ein kleines Unternehmen kann Domain, Hosting, E-Mail, Zertifikat, VPS und Support von einem einzigen Anbieter beziehen. Eine Agentur kann Kunden-Domains und -Websites unter einem einzigen Konto verwalten. Ein türkischer E-Commerce-Shop kann eine in Istanbul gehostete Infrastruktur und türkischsprachigen Support wählen, anstatt eine Hyperscale-Konsole zu erlernen. Ein Kunde, der über Shared Hosting hinausgewachsen ist, kann auf VDS oder Managed Pro Cloud umsteigen, ohne die Marke zu wechseln.

Dieselbe Breite macht die Abhängigkeit auch schwieriger zu überprüfen. Die Domain-Registrierung hängt von Registry- und Registrar-Kanälen ab. E-Mail kann von externen Plattformen sowie lokalem DNS und Support abhängen. SSL hängt von Zertifizierungsstellen und dem Validierungs-Timing ab. VDS hängt von Hypervisoren, Speicher und Netzwerk ab. Managed Cloud hängt von Personalzugriff und Änderungsdisziplin ab. Die Serverwartung hängt von den Fähigkeiten und der Verfügbarkeit der Ingenieure ab.

Eine gebündelte Rechnung kann den Eindruck erwecken, dass all dies ein einziger Dienst ist, während die Ausfallkette dennoch über mehrere Betreiber verläuft.

Die öffentlichen Seiten von CloudTeknoloji leisten gute Arbeit, indem sie einige technische Zutaten nennen. Die VDS-Seite bewirbt VMware ESXi, SSD-Speicher, vollständigen Root-Zugriff, Intel Xeon E5-2695 V4-Prozessoren und Paketgrößen von kleineren Zwei-Kern-Maschinen bis hin zu Sechs-Kern-Stufen mit 8 GB RAM und 80 GB SSD. Die Pro-Cloud-Seite bewirbt Xeon Gold 6138, NVMe-SSD, zugewiesene Ressourcen, verwalteten Dienst, Sicherheitsupdates, Optimierung und technische Überwachung. Die Hosting-Seite bewirbt Linux LiteSpeed, Windows IIS, NVMe-SSD, cPanel oder Plesk und wöchentliche Backups. Dies sind keine leeren Schlagworte.

Sie identifizieren Produktfamilien und einige Hardwareklassen.

Dennoch enden die öffentlichen Informationen vor den schwierigsten Kapazitätsfragen. Wie viele physische Hosts unterstützen jede Planfamilie? Wie hoch ist die Überbuchungsrate? Wie viele Reserveknoten können den Ausfall eines Hosts auffangen? Sind die VDS-Speichersysteme lokal, gemeinsam genutzt, repliziert oder per Snapshot gesichert? Läuft die Pro-Cloud-Stufe auf anderen Hosts als Standard-VDS, oder nur auf einer höheren Ressourcenklasse mit verwaltetem Support? Befinden sich die Backup-Repositorien außerhalb der Produktionsspeicherschicht? Kann ein Kunde ein VM-Image exportieren oder nur Dateien und Control-Panel-Backups?

Diese Fragen entscheiden, ob ein verkaufter Plan nur an normalen Tagen komfortabel oder an Reparaturtagen nachhaltig ist.

Die Route scheint jetzt von der ICS-Seite des Standorts abzuhängen

Der öffentliche Routing-Pfad zeigt auf die Grenze zwischen Standort und Betreiber. DieRIPE-aut-num-Registrierung für AS202048enthält Import- und Export-Richtlinienzeilen für AS48678, AS42910 und AS214588. DieRIPEstat-AS-Routing-Konsistenzzeigt jedoch eine Diskrepanz zwischen der registrierten Richtlinie und dem beobachteten Routing: AS214588 ist in BGP und in den Richtliniendaten, während AS48678 und AS42910 in den Richtliniendaten erscheinen, aber zum abgetasteten Zeitpunkt nicht in BGP beobachtet wurden. DieRIPEstat-ASN-Nachbarsdatenmeldeten für die letzte verfügbare Zeit ebenfalls einen einzelnen linken Nachbarn, AS214588.

AS214588 ist kein zufälliger, nicht zusammenhängender Hop. DieRIPE-AS214588-Registrierungnennt esicsteknoloji, und dieRIPEstat-AS214588-Übersichtgibt den Inhaber als ICS Bilisim Teknolojileri Danismanlik Hizmetleri A.S. an. Die AS214588-Richtliniendaten zeigen vorgelagerte Beziehungen zu Turkcell/Superonline, Turk Telekom und Vodafone. DerBGP-Zustandsbeispiel für 46.28.232.0/24zeigt ebenfalls globale Pfade, die AS202048 über AS214588 in den abgetasteten Routen erreichen.

Dies beweist nicht, dass CloudTeknoloji keine private Backup-Leitung, keinen Glasfaser-Dark-Fiber-Pfad oder keine Out-of-Band-Wiederherstellung hat. Öffentliche BGP-Collectoren zeigen nur, was zu einem bestimmten Zeitpunkt global sichtbar ist. Aber für einen Kunden, der gehostete Kapazität kauft, ist der aktuelle öffentliche Pfad dennoch signifikant. Wenn der öffentliche Internetdienst von AS202048 derzeit über AS214588 erreicht wird, dann sind die Standort- und Betreiberkoordination mit der ICS-Seite Teil der Betriebsoberfläche von CloudTeknoloji.

Ein Routing-Fehler, ein kommerzieller Streit, ein Interconnect-Ausfall, ein DDoS-Mitigationsproblem, ein Stromereignis, ein Betreiberausfall oder eine falsch konfigurierte Übergabe auf diesem Pfad können Kunden von CloudTeknoloji betreffen, selbst wenn ihre VM gesund ist.

Die praktische Frage ist die Transitdiversität. Die eigene Unternehmensseite von CloudTeknoloji beansprucht betreiberunabhängige Glasfaser und redundante Internetkapazität von über 100 Gbps für ihre Infrastruktur. Dies ist eine starke Behauptung, aber die öffentliche AS-Ansicht zeigt einen beobachteten Nachbarn am Rand von CloudTeknoloji. Diese beiden Aussagen können koexistieren, wenn der zugrunde liegende Standort mehrere Betreiber hat, während das AS von CloudTeknoloji derzeit das ICS-Netzwerk als öffentliche Transit-Übergabe verwendet.

Sie können auch koexistieren, wenn die Backup-Optionen für die Standortnutzung, private Schaltkreise oder manuelles Failover reserviert sind, anstatt als gleichzeitige BGP-Sitzungen sichtbar zu sein. Der Kunde muss fragen, welche Interpretation zutrifft.

Bei kritischen Diensten muss die Antwort vertraglich und technisch sein. Kunden müssen wissen, ob ihre öffentlichen IPs über einen zweiten Betreiber erreichbar bleiben, wenn AS214588 ausfällt, ob es ein automatisches Route-Failover gibt, ob die DDoS-Filterung vom selben Pfad abhängt und ob DNS, Management-Panels und Support-Portale erreichbar bleiben, wenn der primäre AS202048-Pfad zurückgezogen wird. Ohne diese Antworten stützen die öffentlichen Beweise eine vorsichtige Sicht: Die aktuelle Route ist real, ordnungsgemäß autorisiert und sichtbar, aber extern konzentriert.

Die gehostete Kapazität wird als sofortig verkauft, aber die Reparatur ist es nicht

Die VDS-Seite betont die schnelle Einrichtung und einfache Ressourcenerweiterung. Sie gibt an, dass Cloud-Server die VMware ESXi-Virtualisierung, SSD-Speicher, vollständigen Root-Zugriff und isolierte Ressourcen verwenden, und preist Ressourcen-Upgrades über das Kundenpanel an. Die Pro-Cloud-Seite geht noch weiter und verkauft einen verwalteten Dienst, zugewiesene Ressourcen, Xeon-Gold-Prozessoren und NVMe-SSD-Speicher für schwerere Websites, SaaS, Agenturen, E-Commerce und stark frequentierte Projekte. Dies ist das Kundenversprechen: Einen Server nehmen, ohne einen Server zu besitzen.

Die betriebliche Realität ist langsamer. Ein virtueller Server kann in Minuten erstellt werden, aber die physische Grundlage fällt dennoch in Stunden aus. Festplatten fallen aus. RAID-Rekonstruktionen verbrauchen I/O. Hosts benötigen Firmware-Updates. Switch-Ports verhalten sich schlecht. Hypervisoren benötigen Patches. Backups verpassen ihre Fenster. Ein Speicherpool kann voll sein, selbst wenn eine Kontoseite anzeigt, dass der Plan aktiv ist. Ein öffentliches Cloud-Wort entfernt keine Ersatzteile.

DieDienstleistungspolitikist nützlich, da sie einen Teil dieser Reibung eingesteht. Sie gibt an, dass per Kreditkarte bezahlte Konten innerhalb weniger Minuten aktiviert werden können, aber Dienste über Hosting und Domain-Registrierung hinaus – einschließlich Cloud-Server, Lizenzen, SSL-Zertifikate und Massen-E-Mail – außerhalb der Bürozeiten bis zu acht Stunden für die Einrichtung oder Bereitstellung benötigen können. Sie gibt an, dass Überweisungsbestellungen eine Zahlungsbestätigung und Überprüfungen erfordern. Sie gibt an, dass unbezahlte Hosting- und Cloud-Server-Dienste nach 30 Tagen von den Servern entfernt werden. Sie gibt auch an, dass Cloud-Server einen gemeinsamen 10-Mbit/s-Pool nutzen, es sei denn, der Kunde mietet eine Leitung für ein anderes Limit.

Diese Details machen das Produkt nicht schlecht. Sie machen es endlich. „Sofort“ ist ein Verkaufserlebnis für den gemeinsamen Pfad. Die Lieferung außerhalb der Personalzeiten, Kapazitätsupgrades, kundenspezifische Softwareinstallation, Leitungsänderungen und überfällige Konten haben unterschiedliche Regeln. Ein Kunde, der eine Migration zu CloudTeknoloji plant, sollte nicht davon ausgehen, dass jede Ressourcenänderung, Lizenzhinzufügung oder Bandbreitenausnahme automatisch ist.

Er sollte fragen, ob die standardmäßige Planbandbreite ausreicht, ob die kostenpflichtige Option nur das Geschwindigkeitslimit oder auch die Routenpriorität ändert, ob eine IP-Nummerierung für Leitungsänderungen erforderlich ist und ob Ressourcenerhöhungen Einschränkungen auf Host-Ebene haben.

Die Sprache des gemeinsamen 10-Mbit/s-Pools ist besonders wichtig. Viele VDS-Käufer denken zuerst an Kerne, RAM und Festplatte. Der Netzwerkdurchsatz wird oft erst sichtbar, wenn eine Website angegriffen wird, eine Backup-Wiederherstellung läuft, eine E-Commerce-Kampagne beginnt oder eine Mediendatei verteilt werden muss. Ein gemeinsamer 10-Mbit/s-Pool kann für ruhige Geschäftswebsites ausreichen, aber er ist kein Ersatz für einen getesteten Hochgeschwindigkeits-Wiederherstellungspfad.

Wenn ein Kunde erwartet, schnell Hunderte von Gigabyte wiederherzustellen oder große Datenverkehrsspitzen zu bedienen, gehört die Netzwerkgeschwindigkeitsregel in die Design-Diskussion, bevor die Bestellung aufgegeben wird.

Die Support-Verpflichtungen sind sichtbar, aber sie sind nicht alle gleich

daha.net veröffentlicht mehrere Support-Erklärungen, und sie müssen gemeinsam und nicht selektiv gelesen werden. DieDienstleistungspolitiklistet telefonischen Support an Wochentagen von Montag bis Freitag, 09:00 bis 17:30 Uhr, Buchhaltungssupport an Wochentagen im selben Zeitfenster und technischen Support per E-Mail rund um die Uhr, sieben Tage die Woche, mit einer Antwortgarantie von 60 Minuten. Später in derselben Richtlinie gibt der Abschnitt zum Kundensupport an, dass daha.net sich verpflichtet, während der Geschäftszeiten innerhalb von 60 Minuten und außerhalb der Geschäftszeiten innerhalb von acht Stunden zu antworten. DieÜber-uns-Seiteund dieKontaktseiteverweisen ebenfalls auf telefonische Verfügbarkeit an Wochentagen und kontinuierlichen Zugang per E-Mail oder Support-Ticket.

Die Nuance zählt. Eine Antwort ist nicht dasselbe wie eine Reparatur. Eine Antwort kann den Eingang bestätigen, den betroffenen Dienst identifizieren, nach Anmeldeinformationen fragen oder mitteilen, dass ein Anbieter kontaktiert wurde. Die Reparatur kann vom Standortpersonal, vorgelagerten Ingenieuren, Hardwarebestand, einer Anbieterlizenz, dem eigenen Administrator des Kunden oder einem Domain-Register abhängen. Bei routinemäßigem Hosting-Support kann eine 60-minütige Antwort ausreichen.

Bei einer ausgefallenen E-Commerce-Zahlung, einem E-Mail-Ausfall, einem unzugänglichen ERP, einem kompromittierten Server oder einer fehlgeschlagenen Datenbankwiederherstellung benötigt der Kunde Eskalationsbedingungen, nicht nur Bedingungen für die erste Antwort.

Die Support-Geschichte von CloudTeknoloji ist stärker als bei einem kontaktlosen Billighoster, da sie Telefonnummern, Support-E-Mails, einen Ticketpfad, eine Geschäftsadresse, eine KEP-Adresse und schriftliche Bedingungen veröffentlicht. Das Risiko besteht darin, dass dieselben veröffentlichten Bedingungen auch natürliche Grenzen aufzeigen: Die Telefonabdeckung ist nicht 24 Stunden verfügbar, die Lieferung einiger nicht wesentlicher Dienste kann außerhalb der Bürozeiten warten, und die Antwortzeit außerhalb der Bürozeiten wird auf zwei Arten beschrieben.

Ein Käufer sollte fragen, welche Klausel für sein spezifisches Produkt gilt, ob Managed Pro Cloud eine andere Eskalation als unmanaged VDS erhält, ob die Notfallantwort einen Eingriff auf Standortebene beinhaltet und ob ein benanntes Schweregradsystem mit Reparaturzeitvorgaben existiert.

Das Personal überschneidet sich auch mit der Migration. Die VDS-Seite preist kostenlosen Migrationssupport an, einschließlich des Umzugs von Websites und Datenbanken ohne Datenverlust oder Dienstunterbrechung. Dies ist wertvoll, wenn es im konkreten Fall des Kunden zutrifft, aber es sollte eingerahmt werden. Das Verschieben einer cPanel-Website ist nicht dasselbe wie das Verschieben einer benutzerdefinierten Anwendung, eines Windows-Servers, einer Live-Datenbank, eines E-Mail-Archivs, einer DNS-Zone, einer DNSSEC-Konfiguration, einer Firewall-Whitelist, von Cron-Jobs und Drittanbieter-Integrationen.

Kunden sollten fragen, was die „kostenlose Migration“ abdeckt, was vom Kunden vorbereitet werden muss, ob die Migration geplant ist, ob ein Rollback enthalten ist und wie lange die alte Website online bleiben muss.

Die Wartungsfenster sind explizit und groß genug

Die Wartungsklausel ist eines der klarsten Anzeichen dafür, dass die Cloud von CloudTeknoloji immer noch eine gewöhnliche Infrastruktur ist. DieDienstleistungspolitikgibt an, dass Kunden eine Woche, drei Tage und einen Tag vor einer Unterbrechung benachrichtigt werden, wenn Serverwartung, -umzug oder Hardware-Updates erforderlich sind. Sie gibt an, dass diese Unterbrechungen insgesamt 96 Stunden pro Jahr nicht überschreiten und nach Möglichkeit nicht während der Geschäftszeiten durchgeführt werden. Sie schließt auch die Haftung für höhere Gewalt bei verspäteter, unvollständiger oder nicht erfolgter Ausführung aus.

Sechsundneunzig Stunden pro Jahr sind kein Ausfallziel; es ist eine Wartungsobergrenze, wie in der Richtlinie festgelegt. Dennoch ist es eine signifikante Zahl für die Kundenplanung. Ein Unternehmen, das nur die Verfügbarkeitssprache auf der Hosting-Seite liest, mag einen nahezu kontinuierlichen Dienst erwarten. Ein Unternehmen, das die Richtlinie liest, sieht, dass geplante Infrastrukturarbeiten eine signifikante Anzahl von Stunden pro Jahr verbrauchen können. Dies kann für risikoarme Websites, Entwicklungsumgebungen, Kleinunternehmensbroschüren oder nicht kritische lokale Anwendungen akzeptabel sein.

Es ist nicht ausreichend für einen Kunden, dessen Auftragseingang, Callcenter, Zahlungsströme oder Kliniksysteme jede Wartungsnacht durchlaufen müssen.

Die wichtige Frage ist, wie die Wartung isoliert wird. Kann ein Host geleert werden, während Arbeitslasten anderswo fortgesetzt werden? Werden VDS-Kunden live zwischen Hosts migriert? Erfordert die Speicherwartung Ausfallzeiten? Sind Netzwartungsereignisse auf Switch- oder Transitebene redundant? Können Pro-Cloud-Kunden eine höhere Verfügbarkeit als Standard-VDS kaufen? Werden Backup-Wiederherstellungen nach dem Austausch von Hardware getestet? Gilt die Vorankündigung von einer Woche, drei Tagen, einem Tag für alle Wartungsarbeiten oder nur für erwartete Ausfallzeiten?

Die Richtlinie liefert das öffentliche Alarmierungsmodell, aber der Kunde benötigt Architekturdetails.

Dies betrifft auch Agentur- und Reseller-Kunden. Wenn ein Reseller Dutzende von Kunden-Websites auf daha.net hostet, kann ein Wartungsereignis zu Dutzenden von Kunden-E-Mails werden. Wenn ein Managed Service Provider daha.net als türkische VPS-Schicht nutzt, kann eine Reparaturnacht alle nachgelagerten Kunden betreffen. Wenn ein E-Commerce-Betreiber eine geplante Kampagne hat, muss die Wartungsankündigung mit den Einfrierfenstern kompatibel sein. Die gehostete Kapazität wird zu einem gemeinsamen Kalender, nicht nur zu einem Ressourcendiagramm.

Die Backup-Sprache ist nützlich, da sie nicht zu beruhigend ist

Die Backup-Sprache von daha.net ist ehrlicher als viele Hosting-Seiten, und sie muss sorgfältig gelesen werden. Die Hosting- und VDS-Produktseiten preisen wöchentliche Backups oder periodische Backup-Funktionen an. DieDienstleistungspolitikgibt die härtere Regel vor: Hosting-Server werden wöchentlich und monatlich gesichert, Serverdienste werden nicht gesichert, es sei denn, der Kunde kauft einen Backup-Dienst, Backups können fehlerhaft oder unbrauchbar sein, es wird keine Garantie gegenüber Kunden aus diesen Backups gegeben, und die Kontosicherung liegt in der Verantwortung des Kunden. Sie gibt auch an, dass das Unternehmen, wenn ein Kunde ein von daha.net erstelltes Backup benötigt, nach eigenem Ermessen ein verfügbares Backup bereitstellen kann, abhängig vom Backup-System.

Diese Sprache sollte Kunden von magischem Denken abbringen. Ein Backup-Etikett auf einem Hosting-Plan ist nicht dasselbe wie ein garantierter Wiederherstellungsdienst. Bei Shared Hosting können wöchentliche und monatliche Backups bei versehentlichem Löschen oder Website-Ausfall helfen, aber die Richtlinie lehnt eine Wiederherstellungsgarantie ab. Bei VDS- und Serverdiensten gibt die Richtlinie an, dass Backup nicht enthalten ist, es sei denn, es wird gekauft. Bei kritischen Arbeitslasten sollte der Käufer davon ausgehen, dass er einen eigenen getesteten Backup-Plan benötigt, bis schriftliche Bedingungen das Gegenteil besagen.

Der Unterschied zwischen „Backup existiert“ und „Wiederherstellung funktioniert“ ist für dieses Unternehmen zentral. CloudTeknoloji verkauft gehostete Kapazität, aber der Kunde kann dennoch den Datenschutz besitzen. Eine WordPress-Site kann auf Anwendungsebene auf ein externes Speicherkonto gesichert werden. Ein VDS kann einen Snapshot in eine separate Region erstellen. Eine Datenbank kann Replikate oder Dumps an einen zweiten Anbieter streamen. Das DNS kann bei einem separaten Betreiber gehostet werden.

Der Kunde kann das Risiko reduzieren, indem er CloudTeknoloji zum primären Host macht, ohne CloudTeknoloji zum einzigen Ort zu machen, an dem Daten existieren.

Der Kunde sollte vor der Nutzung von daha.net für etwas Wichtiges fünf Backup-Fragen stellen. Erstens: Ist Backup für dieses genaue Produkt enthalten oder muss es separat erworben werden? Zweitens: Wo wird das Backup im Verhältnis zum primären ICS-gehosteten System gespeichert? Drittens: Wie oft wird eine Wiederherstellung getestet? Viertens: Wer hat die Verschlüsselungsschlüssel und die Administratorrechte? Fünftens: Wie lange würde eine vollständige Wiederherstellung bei der standardmäßigen Netzwerkrate dauern? Die öffentliche Richtlinie beantwortet einen Teil der ersten Frage und warnt davor, dass die anderen wichtig sind.

Die Abrechnung, Kündigung und Datenlöschung sind Teil der Verfügbarkeit

Infrastrukturartikel konzentrieren sich oft auf Routen und Racks, aber die Bedingungen von CloudTeknoloji zeigen, dass der kommerzielle Zustand ebenso wichtig sein kann. DieDienstleistungspolitikgibt an, dass seit sieben Tagen unbezahlte Bestellungen automatisch storniert werden. Sie gibt an, dass nicht verlängerte Hosting- und Cloud-Server-Dienste einen Monat nach dem Verlängerungszeitraum vollständig von den Servern entfernt werden. Sie gibt an, dass die Stornierung des Dienstes das Konto sowie die Backups löscht. Sie schränkt auch die Rückerstattungsfähigkeit für bestimmte Add-ons, Lizenzen, Domains, SSL und andere Dienste ein und gibt an, dass die Rückerstattungsfähigkeit für Cloud-Server erlöschen kann, wenn das technische Team auf Anfrage des Kunden Add-ons oder Software installiert.

Für eine öffentliche Website können diese Bedingungen routinemäßig sein. Für eine geschäftskritische Arbeitslast sind sie eine Abhängigkeit. Ein fehlgeschlagener Zahlungskartenversuch, ein Rechnungsstreit, eine verspätete Zahlung oder ein Personalwechsel kann zur Datenlöschung führen, wenn die Verlängerung nicht kontrolliert wird. Ein Kunde, der daha.net verlässt, muss Dateien, Datenbanken, DNS, Postfächer, Zertifikate, Schlüssel, Lizenzen und Server-Images vor der Kündigung oder Nichtverlängerung exportieren. Ein Kunde, der sich für Rollbacks auf Backups verlässt, muss verstehen, ob diese Backups mit dem Konto verschwinden.

Hier trifft die Hosting-Ökonomie auf das Risiko. Ein gebündelter lokaler Anbieter kann günstiger und einfacher sein, als redundante Infrastruktur von Grund auf neu aufzubauen. Aber günstigeres Hosting schiebt oft einen Teil der betrieblichen Verantwortung auf den Kunden: Verlängerungsdisziplin, Backups, Migrationsvorbereitung, Aufbewahrung von Zugangsdaten, Domain-Lock-Management, DNS-TTLs und anbieterunabhängige Wiederherstellungskopien. Der Kunde sollte ab dem ersten Tag einen Ausstiegsplan haben, nicht erst nach einem Vorfall.

Der Ausstiegsplan ist im Prinzip einfach. Halten Sie den Registrar-Zugriff nach Möglichkeit unabhängig. Halten Sie DNS-Exports bereit. Halten Sie Backups außerhalb der Plattform. Wissen Sie, welche IP-Adressen mit Whitelists verbunden sind. Führen Sie eine aktuelle Liste der SSL-Zertifikate und Verlängerungsdaten. Testen Sie die Wiederherstellung einer Website bei einem anderen Anbieter. Halten Sie die E-Mail-Kontinuität außerhalb eines einzelnen Webhosting-Kontos aufrecht, wenn E-Mail kritisch ist. Nichts davon bedeutet, CloudTeknoloji zu meiden. Es bedeutet, es als einen Anbieter zu nutzen, nicht als die einzige Kopie des Unternehmens.

Datensouveränität ist ein echtes Verkaufsargument mit einem Wiederherstellungskompromiss

Für türkische Kunden kann lokales Hosting wertvoll sein. Es kann die Latenz für Inlandsnutzer reduzieren, den Sprach- und Steuersupport vereinfachen, Verträge unter einer vertrauten Gerichtsbarkeit halten und Datenlokalitätspräferenzen unterstützen. Die offiziellen Seiten von CloudTeknoloji stützen sich auf dieses lokale Profil: Büros in Istanbul, Standort in Istanbul, türkischsprachiger Support, Annahme von Bestellungen nur in der Türkei in der Richtlinie, türkische juristische Identität, KEP-Adresse und ein Dienstleistungspaket, das auf lokales Hosting, Domains und Geschäfts-E-Mail abzielt. DieGeolokalisierungsansicht für 46.28.232.0/24ordnet das sichtbare öffentliche Präfix ebenfalls der Türkei zu.

Lokalität kann jedoch das Risiko konzentrieren, wenn sie nicht mit unabhängiger Wiederherstellung einhergeht. Ein Kunde, der Daten in der Türkei halten muss, kann dennoch einen zweiten türkischen Standort, einen zweiten Anbieter, ein zweites Backup-Konto oder zumindest separates DNS und eine Wiederherstellungsvereinbarung benötigen. Ein Kunde, der eine Wiederherstellungskopie im Ausland verwenden kann, erhält möglicherweise leichter geografische Trennung, muss jedoch rechtliche, datenschutzrechtliche und vertragliche Grenzen berücksichtigen. Die öffentlichen Seiten von CloudTeknoloji lösen diesen Kompromiss nicht.

Sie zeigen einen auf die Türkei zentrierten Anbieter. Sie veröffentlichen keine vollständige Multi-Site-Wiederherstellungsarchitektur.

Die richtige Schlussfolgerung ist nicht, dass lokales türkisches Hosting schwach ist. Es ist, dass Souveränität und Resilienz getrennte Designziele sind. Ersteres fragt, wo Daten leben und welches Gesetz gilt. Letzteres fragt, ob ein Kunde nach einem Standort-, Routen-, Speicher-, Personal- oder Kontenausfall weitermachen kann. CloudTeknoloji kann beim Ersteren helfen, indem es Dienste in Istanbul hält. Der Kunde muss dennoch das Zweite überprüfen.

Dies gilt insbesondere für Kunden mit regulierten, reputationssensiblen oder umsatzrelevanten Arbeitslasten. Eine Schule, eine Klinik, eine Agentur, ein E-Commerce-Shop oder ein professionelles Büro kann sich für daha.net entscheiden, weil das Support-Team dieselbe Sprache spricht, die juristische Person erreichbar ist und der Server in Istanbul steht. Das ist rational. Aber wenn derselbe Dienst auch der einzige DNS-Host, der einzige E-Mail-Host, der einzige Backup-Speicherort und die einzige Route zum Support ist, dann wird ein lokaler Vorteil zu einem operativen Single Point of Failure.

Die Lösung ist nicht abstrakt: separates Backup, separates DNS, dokumentiertes Failover, getestete Wiederherstellung und schriftliche Eskalation.

Wer betroffen ist, wenn dieses System ausfällt

Die erste betroffene Gruppe sind Shared-Hosting-Kunden. Dies sind die Nutzer, die am ehesten die Einschränkungen der Plattform spüren, aber am wenigsten wahrscheinlich den dahinter liegenden Standort verstehen. Ein Shared-Hosting-Ausfall kann Websites, Postfächer, Datenbanken, Control-Panels und SSL-Verlängerungspfade gleichzeitig offline nehmen. Der Kunde hat möglicherweise keinen Root-Zugriff oder keine direkte Backup-Kontrolle. Die Backup-Haftungsausschlüsse der Dienstleistungspolitik sind daher für die am wenigsten technischen Kunden am wichtigsten.

Die zweite Gruppe sind VDS- und Pro-Cloud-Kunden. Sie haben mehr Kontrolle, übernehmen aber auch mehr Verantwortung. Ein unmanaged VDS-Kunde hat Root-Zugriff und kann seinen eigenen Stack aufbauen, aber Betriebssystem-Updates, Anwendungssicherheit, Datenbank-Backups und Wiederherstellungsplanung können beim Kunden liegen. Ein verwalteter Pro-Cloud-Kunde erhält möglicherweise mehr Hilfe, sollte aber dennoch bestätigen, welche Schichten genau verwaltet werden, welche Best-Effort-Support sind und welche im Eigentum des Kunden verbleiben.

Die dritte Gruppe sind Agenturen und Reseller. Sie verwandeln einen vorgelagerten Anbieter in viele nachgelagerte Versprechen. Wenn sie Reseller-Hosting, VDS-Kapazität oder verwaltete Server von daha.net kaufen, können ihre eigenen Kunden die Agentur als Betreiber sehen. Ein daha.net-Wartungsfenster, eine Support-Warteschlange oder ein Routing-Problem wird zu einem Agenturvorfall. Diese Kunden benötigen Statusaktualisierungen, Kundenkommunikationsvorlagen, Migrations-Backups und klare Dienstgrenzen, bevor Probleme auftreten.

Die vierte Gruppe sind Domain- und E-Mail-Kunden. Domain-Ablauf, Übertragungsbeschränkungen, DNS-Fehler und E-Mail-Routing-Fehler können länger andauern als ein Web-Ausfall. Die Dienstleistungspolitik beschreibt Domain-Verlängerungshinweise, automatische Verlängerung, Wiederherstellungsfristen und Übertragungsbedingungen. Kunden, die Domain, DNS, Hosting und E-Mail unter einem einzigen Konto zusammenfassen, erhalten Komfort. Sie setzen jedoch auch Verlängerung, Zugangsdaten und Support-Eskalation an einem Ort. Die Trennung von Eigentumszugriff und Hosting-Kontrolle kann dieses Risiko verringern.

Die letzte betroffene Gruppe ist CloudTeknoloji selbst. Ein kleines öffentliches AS und eine konzentrierte Route bedeuten nicht automatisch eine betriebliche Schwäche, aber sie bedeuten, dass jeder öffentliche Vorfall ein Reputationsgewicht haben kann. Wenn Kunden die Marke als lokalen Zuverlässigkeitspartner sehen, erwarten sie klare Mitteilungen, ehrliche Statusseiten, schnelle Reparaturaktualisierungen und praktische Migrationshilfe. Die öffentliche Dienstleistungspolitik erkennt bereits Wartungshinweise und Support-Antwort an.

Das nächste Reifesignal wäre eine transparente Vorfallhistorie und produktspezifische Wiederherstellungsbedingungen.

Was die offenen Fragen klären würde

Die öffentliche Akte ist für ein vorsichtiges Profil ausreichend, aber nicht für eine hochvertrauenswürdige Resilienzbewertung. Fünf zusätzliche Offenlegungen würden die Bewertung merklich verändern.

Erstens könnte CloudTeknoloji eine Standort- und Eigentumsgrenze veröffentlichen oder vertraglich bereitstellen: welche Dienste in den ICS-Rechenzentren laufen, welche auf Hardware von CloudTeknoloji, welche auf gemieteter Kapazität und welche auf Drittanbietern basieren. Zweitens könnte es produktspezifische Backup-Bedingungen veröffentlichen: enthaltene Backups, kostenpflichtige Backups, Aufbewahrung, Off-Site-Speicherort, Wiederherstellungszeit, Wiederherstellungstest und Kundenverantwortung.

Drittens könnte es das Transit-Design für AS202048 darlegen: aktuelle Betreiber, Failover-Verhalten, DDoS-Management, IPv6-Verfügbarkeit und ob AS48678 oder AS42910 weiterhin verfügbare Backup-Optionen oder nur historische Richtlinieneinträge sind. Viertens könnte es Wartungs- und Notfallverpflichtungen nach Produktstufe bereitstellen, wobei zwischen Antwort und Reparatur zu unterscheiden ist. Fünftens könnte es die Ausstiegsrechte dokumentieren: VM-Exports, Control-Panel-Backups, DNS-Zonenexport, Domain-Transfer-Support, IP-Portabilitätsgrenzen und Kontolöschungsfrist.

Einige dieser Details können bereits in Kundenverträgen oder Geschäftsangeboten existieren. Das Problem ist die öffentliche Überprüfbarkeit. Von außen hat das Unternehmen einen stärkeren Identitätsfußabdruck als viele Hoster, eine live und autorisierte Route und eine konsistente Hosting-Geschichte in Istanbul. Es hat auch ein kleines sichtbares öffentliches Netzwerk, keine sichtbare IPv6-Ursprungsadresse, einen beobachteten vorgelagerten Pfad über ICS und Dienstbedingungen, die eine erhebliche Backup- und Verlängerungsverantwortung auf den Kunden übertragen.

Die Aufgabe des Käufers ist es, die Kritikalität der Arbeitslast auf diese Beweise abzustimmen. Eine risikoarme Visitenkarten-Website, eine kleine WordPress-Site, eine lokale geschäftliche E-Mail-Einrichtung oder eine Entwicklungs-VPS können bequem passen. Ein stark frequentierter Shop, ein regulierter Datenspeicher, ein öffentlicher Notdienst, eine zahlungskritische Anwendung oder eine Multi-Client-Reseller-Plattform sollten schriftliche Beweise für Redundanz und Wiederherstellung verlangen, bevor die Produktion verlagert wird.

Fazit

CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. verdient weder Ablehnung noch blindes Vertrauen. Das Unternehmen hinter daha.net ist identifizierbar, hat unter einer sichtbaren türkischen Geschäftsidentität operiert, veröffentlicht Kontakt- und rechtliche Informationen, verkauft einen breiten Hosting-Katalog, beansprucht Hosting in einem Istanbuler Standort und betreibt ein live öffentliches AS. Die öffentliche Route für AS202048 ist angekündigt, von Collectoren sichtbar und durch eine gültige RPKI-Autorisierung für 46.28.232.0/24 abgedeckt.

Die Vorsicht ist, dass der öffentliche Fußabdruck klein ist. Ein sichtbares IPv4 /24, keine sichtbare IPv6-Ursprungsadresse, kein öffentliches PeeringDB-Profil und ein derzeit beobachteter AS-Nachbar beweisen keine breite Redundanz. Die offiziellen Dienstbedingungen erinnern Kunden auch daran, dass Cloud-Server, Backups, Wartung, Support-Zeiten, Bandbreite und Verlängerungsstatus Grenzen haben.

Vereinfacht gesagt, CloudTeknoloji verkauft gehostete Kapazität, die für türkische Unternehmen wertvoll sein kann, aber diese Kapazität hängt immer noch von Racks, Transit, Strom, Hardware-Austausch, Personalreaktion und der eigenen Backup- und Migrationsdisziplin des Kunden ab.

Die angemessene Käuferhaltung ist pragmatisch: Nutzen Sie den lokalen Anbieter, wenn sein Hosting in Istanbul, sein türkischsprachiger Support und seine gebündelten Dienste zur Arbeitslast passen, aber lassen Sie sich den Wiederherstellungspfad zeigen. Fragen Sie, wo die Daten sind, wo das Backup ist, welche Route ausfällt, wie Reparaturen eskaliert werden, wie lange eine vollständige Wiederherstellung dauern kann, was nach der Nichtverlängerung passiert und wie der Kunde sauber aussteigt.

Bis diese Antworten schriftlich vorliegen und getestet sind, stützen die öffentlichen Beweise ein Infrastrukturprofil mit mittlerem Vertrauen: echter Betrieb, begrenzte öffentliche Netztiefe und Wiederherstellungsfragen, die mehr zählen als das Wort „Cloud“.