Resumen
- CloudTeknoloji es la empresa detrás de daha.net. Lapágina de información comercialnombra a CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. como la empresa legal, da daha.net como la marca, enumera la dirección en Estambul, teléfono, número MERSIS y número de registro mercantil, y describe servicios de hosting, servidor cloud, dominio, SSL, correo electrónico y servicios de TI relacionados.
- La afirmación sobre la infraestructura es específica pero no completamente independiente. Lapágina de informacióndice que los sistemas de daha.net se gestionan desde Estambul 4. Levent y están alojados en el centro de datos ICS de Estambul, con afirmaciones de Tier III, PCI/DSS, capacidad de internet redundante, fibra independiente del operador, UPS, alimentación A+B, seguridad física y refrigeración. Los lectores deben tratar estas como afirmaciones de la empresa a menos que estén corroboradas en contratos de clientes o certificados de las instalaciones.
- La huella de enrutamiento público es actual y limitada. Lavisión general de AS de RIPEstatmuestra AS202048 anunciado para CloudTeknoloji, y losdatos de prefijos anunciadosmuestran un prefijo visible, 46.28.232.0/24, en la ventana de finales de junio al 12 de julio de 2026. Losrecuentos de prefijos RISmuestran un prefijo de origen IPv4, ningún prefijo de tránsito y ningún prefijo de origen IPv6.
- La principal pregunta del cliente no es si daha.net existe. Es cuánto del sitio web, VPS, correo, DNS, copia de seguridad y plan de migración de un cliente está vinculado a una sola instalación en Estambul, un pequeño bloque de direcciones enrutadas, la ruta ascendente actual de ICS, las ventanas de respuesta de soporte y los términos contractuales que colocan cierta responsabilidad de copia de seguridad y pérdida de datos en el cliente.
La empresa es más clara que muchos nombres de hosting delgados
La identidad pública de CloudTeknoloji está inusualmente bien definida para un operador de hosting pequeño. Lapágina de información comercial de daha.netda el título legal como CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S., establece que daha.net es la marca, enumera la oficina de impuestos como Maslak, da el número de impuestos 5470543764, número MERSIS 0547054376400001 y número de registro mercantil 759033, y dice que la empresa fue fundada en 2010. La misma página enumera una dirección en Sultan Selim Mahallesi, NEF 09 Plaza 4. Levent B Blok No:7/121, Kagithane, Estambul, además de teléfono, fax, correo electrónico y KEP.
Eso importa porque esto no es meramente un dominio que vende hosting anónimo. Un comprador puede conectar la marca, la empresa, la dirección, la identidad de registro y la identidad de red pública. Elregistro de organización de RIPE para ORG-SBHv1-RIPEenumera a Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. en Turquía, muestra el mismo número de registro mercantil, identifica el tipo de organización como LIR y da una dirección en Kagithane, Estambul y número de teléfono. Elregistro aut-num de RIPE para AS202048nombra el AS como CloudTeknoloji, lo describe como Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. y lo vincula a la misma organización de RIPE.
La historia de la marca luego completa la oferta orientada al cliente. Lapágina de informacióndice que daha.net ha operado desde 2010 y ofrece servicios de hosting y servidores a clientes individuales y corporativos. Enmarca la marca como parte de Cloud Teknoloji Bilisim Hizmetleri Ticaret Anonim Sirketi, y describe un conjunto de servicios que incluye hosting, servidor cloud, hosting revendedor, dominio, SSL y correo corporativo. Lapágina de contactoda teléfono público, fax, correos electrónicos de soporte, dirección y KEP, por lo que los compradores tienen una ruta visible para ventas, soporte y notificaciones formales.
Por lo tanto, la empresa no está operando detrás de una tienda completamente opaca. La evidencia respalda un proveedor de hosting turco real, una empresa legal nombrada, un canal minorista con marca, una identidad LIR de RIPE y un AS anunciado. La degradación comienza no en la identidad, sino en la escala y redundancia. Los registros públicos pueden probar la empresa y una red enrutada.
No prueban cuánto hardware está desplegado, cuántos racks están bajo control directo, cuánta capacidad de respaldo está reservada, con qué frecuencia se prueba la conmutación por error, o si la recuperación del cliente puede completarse sin el sitio principal de Estambul.
La huella enrutada es real, actual y pequeña
La imagen de red pública es sencilla.La visión general de AS de RIPEstat para AS202048mostró al titular como CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. y marcó el AS como anunciado el 12 de julio de 2026.Los datos de prefijos anunciados de RIPEstatmostraron un prefijo visible, 46.28.232.0/24, del 28 de junio de 2026 al 12 de julio de 2026.Los recuentos de prefijos RIS de RIPEstatmostraron un prefijo IPv4 de origen, cero prefijos IPv4 de tránsito, cero prefijos IPv6 de origen y cero prefijos IPv6 de tránsito en el momento de la consulta del 12 de julio.
Eso es suficiente para mostrar operación pública en vivo.La visión general del prefijo de RIPEstat para 46.28.232.0/24marca el /24 como anunciado por AS202048.Los datos de estado de enrutamiento de RIPEstatmostraron que 325 de 326 peers de alimentación completa IPv4 veían la ruta en el momento muestreado, con un prefijo IPv4 visible y 256 direcciones de espacio IPv4 anunciado. También mostró cero espacio IPv6 visible y un vecino observado.La validación RPKIdevolvió un ROA válido para AS202048 y 46.28.232.0/24, con longitud máxima 24.
La misma evidencia limita la afirmación. Un solo /24 es una huella de direcciones públicas pequeña. Puede transportar servidores de nombres autoritativos, nodos de hosting, retransmisores de correo, puntos finales de gestión, servicios VPS del cliente o sistemas de monitoreo, pero no es evidencia de una región cloud regional amplia. La ausencia de origen IPv6 visible es especialmente notable para un vendedor moderno de cloud y hosting.
La visibilidad solo IPv4 no hace que los servicios sean inutilizables, pero indica que los clientes que necesitan servicios públicos de doble pila deben preguntar por la disponibilidad explícita de IPv6 en lugar de asumir que existe.
Tampoco hay ninguna entrada de red de PeeringDB pública para este ASN: laconsulta de PeeringDB para ASN 202048devuelve un conjunto de datos vacío. La ausencia de PeeringDB no es prueba de ingeniería débil. Muchos proveedores pequeños dependen del tránsito ascendente y no mantienen perfiles de intercambio públicos. Aún así, elimina un lugar independiente común donde los operadores publican presencia en instalaciones, niveles de tráfico, política de peering, contactos del NOC y conexiones de intercambio. Para CloudTeknoloji, los datos públicos visibles dicen "AS enrutado real, un /24 IPv4 actual, autorización de ruta válida, ningún origen IPv6 visible, ningún perfil de peering público".
Eso es un grado de evidencia medio, no negativo. La red es visible y actual, pero deja al cliente solicitar prueba privada para capacidad multisitio, diversidad de tránsito, capacidad de host de repuesto y diseño de ruta de recuperación.
El límite del rack es Estambul, no una nube sin lugar
El lenguaje de la instalación de la empresa es lo suficientemente preciso como para dar forma a la conversación sobre el riesgo. Lapágina de informacióndice que los sistemas se gestionan desde un centro de operaciones en Estambul 4. Levent y están alojados en el centro de datos ICS ubicado en Estambul, descrito como certificado PCI/DSS y estándar Tier III. También afirma más de 100 Gbps de capacidad de acceso a internet redundante, fibra independiente del operador, UPS y sistemas de energía completamente redundantes, alimentación dual A+B, seguridad física y refrigeración. Lapolítica de serviciorepite la afirmación de ubicación de manera más simple: los servidores de daha.net están alojados en el centro de datos ICS de Estambul, Tier III.
Eso convierte la palabra de marketing "nube" en un lugar. El servicio del cliente depende de racks en Estambul, un operador de instalaciones, distribución de energía, refrigeración, cableado, conexiones cruzadas, puertos de switch, sesiones de tránsito, almacenamiento, inventario de hardware y personas que puedan realizar reparaciones. Algunos de estos pueden estar controlados directamente por CloudTeknoloji. Algunos recaen en el centro de datos ICS o transportistas ascendentes.
Las páginas públicas no revelan qué racks están alquilados, qué equipo posee CloudTeknoloji, cuánta capacidad de la instalación está reservada para daha.net, o si los mismos productos pueden conmutar por error a otra ciudad turca u otro país.
La distinción es importante para la localidad de los datos. La oferta de CloudTeknoloji es atractiva para clientes turcos en parte porque parece mantener la capacidad de hosting y servidor en Turquía. Lapágina de VDSanuncia ubicación en Estambul, virtualización VMware ESXi y paquetes VDS con SSD. Lapágina de Pro Cloudanuncia nuevamente ubicación en Estambul, con procesadores Xeon Gold 6138, soporte gestionado y almacenamiento NVMe SSD. Lapágina de hostinganuncia hosting en ubicación de Estambul, Linux LiteSpeed, Windows IIS, SSL gratuito y copias de seguridad semanales.Los datos de geolocalización de RIPEstat para 46.28.232.0/24también colocan el prefijo público en Turquía en el momento verificado.
Pero la localidad no es lo mismo que la resiliencia. Una instalación turca puede cumplir con los requisitos de jurisdicción, latencia o soporte de idioma de un cliente y aún así dejar a ese cliente expuesto a una falla de un solo sitio. Si el servicio alojado principal, la copia de seguridad, el portal de soporte y el DNS del cliente dependen todos del mismo campus o del mismo handoff del transportista, el cliente tiene control local pero independencia limitada.
Una afirmación de continuidad más sólida mencionaría un segundo sitio, una ubicación de restauración probada, un dominio administrativo separado, un objetivo de tiempo de recuperación definido y una ruta de exportación clara.
El catálogo de servicios vende capas, no solo servidores
La gama de productos de daha.net es más amplia que una tienda de VPS limitada. Lapágina de información comercialdice que la empresa opera en alojamiento web, servidor cloud, registro de dominios, certificados SSL, correo electrónico y servicios de TI relacionados. La navegación y las páginas de productos muestran la misma amplitud:servidores cloud VDS estándar,servidores cloud Pro gestionados,alojamiento web, hosting WordPress, hosting revendedor, hosting corporativo, servicios de dominio, certificados SSL, licencias de panel de control, Microsoft 365, correo masivo y servicios de mantenimiento de servidores.
Esa amplitud es comercialmente útil. Una pequeña empresa puede comprar dominio, hosting, correo, certificado, VPS y soporte de un solo proveedor. Una agencia puede mantener dominios y sitios de clientes bajo una sola cuenta. Un sitio de comercio electrónico turco puede elegir infraestructura alojada en Estambul y soporte en idioma turco en lugar de aprender una consola de hiperescala. Un cliente que ha superado el hosting compartido puede migrar a VDS o Pro Cloud gestionado sin cambiar de marca.
La misma amplitud también hace que la dependencia sea más difícil de inspeccionar. El registro de dominio depende de canales de registro y registradores. El correo electrónico puede depender de plataformas externas además del DNS local y el soporte. SSL depende de autoridades de certificación y tiempos de validación. VDS depende de hipervisores, almacenamiento y red. La nube gestionada depende del acceso del personal y la disciplina de cambios. El mantenimiento del servidor depende de las habilidades y disponibilidad de los ingenieros.
Una factura combinada puede hacer que todos estos parezcan un solo servicio, mientras que la cadena de fallas aún cruza varios operadores.
Las páginas públicas de CloudTeknoloji hacen un trabajo decente al nombrar algunos ingredientes técnicos. La página de VDS anuncia virtualización VMware ESXi, almacenamiento SSD, acceso root completo, procesadores Intel Xeon E5-2695 V4 y tamaños de paquete desde máquinas de dos núcleos más pequeñas hasta niveles de seis núcleos, 8 GB de RAM y 80 GB SSD. La página de Pro Cloud anuncia Xeon Gold 6138, NVMe SSD, recursos asignados, servicio gestionado, actualizaciones de seguridad, optimización y seguimiento técnico. La página de hosting anuncia Linux LiteSpeed, Windows IIS, NVMe SSD, cPanel o Plesk y copias de seguridad semanales.
Estos no son palabras de moda vacías. Identifican familias de productos y algunas clases de hardware.
Sin embargo, la información pública se detiene antes de las preguntas más difíciles sobre capacidad. ¿Cuántos hosts físicos soportan cada familia de planes? ¿Cuál es la relación de sobresuscripción? ¿Cuántos nodos de repuesto pueden absorber una falla de host? ¿Los sistemas de almacenamiento VDS son locales, compartidos, replicados o respaldados por instantáneas? ¿El nivel Pro Cloud se ejecuta en hosts diferentes al VDS estándar, o simplemente en una clase de recurso más alta con soporte gestionado? ¿Los repositorios de copias de seguridad están fuera de la capa de almacenamiento de producción?
¿Puede un cliente exportar una imagen de VM, o solo archivos y copias de seguridad del panel de control? Esas preguntas deciden si un plan vendido es cómodo solo durante días normales o duradero durante días de reparación.
La ruta ahora parece depender del lado de ICS de la instalación
La ruta de enrutamiento público apunta al límite entre la instalación y el operador. Elregistro aut-num de la base de datos de RIPE para AS202048contiene líneas de política de importación y exportación para AS48678, AS42910 y AS214588. Sin embargo,AS-routing-consistency de RIPEstatmuestra una diferencia entre la política registrada y el enrutamiento observado: AS214588 está en BGP y en los datos de política, mientras que AS48678 y AS42910 aparecen en los datos de política pero no se observaron en BGP en el momento muestreado.Los datos de vecinos ASN de RIPEstattambién reportaron un vecino único del lado izquierdo, AS214588, para el último tiempo disponible.
AS214588 no es un salto aleatorio no relacionado. Elregistro AS214588 de RIPElo nombra comoicsteknoloji, yla visión general de AS214588 de RIPEstatda al titular como ICS Bilisim Teknolojileri Danismanlik Hizmetleri A.S. Los datos de política de AS214588 muestran relaciones ascendentes con Turkcell/Superonline, Turk Telekom y Vodafone. Lamuestra del estado BGP para 46.28.232.0/24también muestra rutas globales que alcanzan AS202048 a través de AS214588 en las rutas muestreadas.
Esto no prueba que CloudTeknoloji no tenga un enlace de respaldo privado, una ruta de fibra oscura o una recuperación fuera de banda. Los recolectores públicos de BGP solo muestran lo que es globalmente visible en un momento. Pero para un cliente que compra capacidad alojada, la ruta pública actual sigue siendo significativa. Si el servicio de internet público de AS202048 se alcanza actualmente a través de AS214588, entonces la coordinación de la instalación y el transportista ascendente con el lado de ICS es parte de la superficie operativa de CloudTeknoloji.
Un error de enrutamiento, disputa comercial, falla de conexión cruzada, problema de mitigación de DDoS, evento de energía, falla del transportista o handoff mal configurado en esa ruta puede afectar a los clientes de CloudTeknoloji incluso si su VM está sana.
La pregunta práctica es la diversidad de tránsito. La propia página de la empresa de CloudTeknoloji afirma fibra independiente del operador y capacidad de internet redundante de más de 100 Gbps para su infraestructura. Esa es una afirmación sólida, pero la vista pública del AS muestra un vecino observado en el borde de CloudTeknoloji. Estas dos declaraciones pueden coexistir si la instalación subyacente tiene múltiples transportistas mientras que el propio AS de CloudTeknoloji utiliza actualmente la red ICS como handoff de tránsito público.
También pueden coexistir si las opciones de respaldo están reservadas para uso de la instalación, circuitos privados o conmutación por error manual en lugar de ser visibles como sesiones BGP simultáneas. El cliente debe preguntar qué interpretación se aplica.
Para servicios críticos, la respuesta debe ser contractual y técnica. Los clientes necesitan saber si sus IPs públicas permanecen alcanzables a través de un segundo transportista ascendente si AS214588 está deteriorado, si hay conmutación por error de ruta automática, si el filtrado de DDoS depende de la misma ruta, y si el DNS, paneles de gestión y portales de soporte permanecen alcanzables si la ruta primaria de AS202048 se retira. Sin esas respuestas, la evidencia pública respalda una visión cautelosa: la ruta actual es real, limpiamente autorizada y visible, pero externamente concentrada.
La capacidad alojada se vende como instantánea, pero la reparación no es instantánea
La página de VDS enfatiza la configuración rápida y los aumentos de recursos fáciles. Dice que los servidores cloud utilizan virtualización VMware ESXi, almacenamiento SSD, acceso root completo y recursos aislados, y anuncia mejoras de recursos a través del panel del cliente. La página de Pro Cloud va más allá, vendiendo servicio gestionado, recursos asignados, procesadores Xeon Gold y NVMe SSD para sitios más pesados, SaaS, agencias, comercio electrónico y proyectos de alto tráfico. Esta es la promesa al cliente: tomar un servidor sin poseer un servidor.
La realidad operativa es más lenta. Un servidor virtual puede crearse en minutos, pero el sustrato físico aún falla en horas. Los discos fallan. Las reconstrucciones RAID consumen E/S. Los hosts requieren actualizaciones de firmware. Los puertos de switch se comportan mal. Los hipervisores necesitan parches. Los trabajos de copia de seguridad pierden ventanas. Un pool de almacenamiento puede estar lleno incluso cuando la página de la cuenta dice que el plan está activo. Una palabra de nube pública no elimina la realidad de los componentes.
Lapolítica de servicioes útil porque admite parte de esta fricción. Dice que las cuentas pagadas con tarjeta de crédito pueden activarse en unos minutos, pero los servicios más allá del hosting y el registro de dominio, incluidos servidores cloud, licencias, certificados SSL y correo masivo, pueden tardar hasta ocho horas en instalarse o entregarse fuera del horario laboral. Dice que las órdenes de transferencia bancaria requieren aviso de pago y verificaciones. Dice que los servicios de hosting y servidor cloud no pagados se eliminan de los servidores después de 30 días. También dice que los Servidores Cloud utilizan un pool compartido de 10 Mbit a menos que el cliente alquile una línea para un límite diferente.
Esos detalles no hacen que el producto sea malo. Lo hacen finito. "Instantáneo" es una experiencia de ventas para el camino común. La entrega fuera del horario laboral, las mejoras de capacidad, la instalación de software personalizado, los cambios de línea y las cuentas morosas tienen reglas diferentes. Un cliente que planifica una migración a CloudTeknoloji no debe asumir que cada cambio de recursos, adición de licencias o excepción de ancho de banda es automática.
Debe preguntar si el ancho de banda predeterminado del plan es suficiente, si la opción pagada cambia solo el límite de velocidad o también la prioridad de la ruta, si se requiere renumeración de IP para cambios de línea, y si los aumentos de recursos tienen restricciones a nivel de host.
El lenguaje del pool compartido de 10 Mbit es especialmente importante. Muchos compradores de VDS piensan primero en núcleos, RAM y disco. El rendimiento de la red a menudo se vuelve visible solo cuando un sitio es atacado, se ejecuta una restauración de copia de seguridad, comienza una campaña de comercio electrónico o se debe distribuir un archivo multimedia. Un pool compartido de 10 Mbit puede ser suficiente para sitios comerciales tranquilos, pero no es un sustituto de una ruta de recuperación probada de alto rendimiento.
Si un cliente espera restaurar cientos de gigabytes rápidamente o servir grandes ráfagas de tráfico, la regla de velocidad de red debe estar en la discusión de diseño antes de realizar el pedido.
Los compromisos de soporte son visibles, pero no todos son iguales
daha.net publica varias declaraciones de soporte, y deben leerse juntas en lugar de selectivamente. Lapolítica de servicioenumera soporte telefónico los días laborables de lunes a viernes, de 09:00 a 17:30, soporte contable en días laborables durante la misma ventana, y soporte técnico por correo electrónico como siete días, 24 horas, con una garantía de respuesta de 60 minutos. Más adelante en la misma política, la sección de atención al cliente dice que daha.net se compromete a responder dentro de los 60 minutos durante el horario laboral y dentro de las ocho horas fuera del horario laboral. Lapágina de informacióny lapágina de contactotambién se refieren a la disponibilidad telefónica en días laborables y al acceso continuo por correo electrónico o ticket de soporte.
El matiz importa. Una respuesta no es lo mismo que una reparación. Una respuesta puede confirmar la recepción, identificar el servicio afectado, solicitar credenciales o decir que se ha contactado al proveedor. La reparación puede depender del personal de la instalación, ingenieros ascendentes, stock de hardware, una licencia del proveedor, el propio administrador del cliente o un registro de dominio. Para el soporte rutinario de hosting, una respuesta de 60 minutos puede ser suficiente.
Para una caja de comercio electrónico caída, interrupción del correo, ERP inaccesible, servidor comprometido o restauración de base de datos fallida, el cliente necesita términos de escalamiento, no solo términos de primera respuesta.
La historia de soporte de CloudTeknoloji es más sólida que la de un host barato sin contacto porque publica números de teléfono, correos electrónicos de soporte, una ruta de tickets, dirección comercial, dirección KEP y términos escritos. El riesgo es que los mismos términos publicados también muestran límites naturales: la cobertura telefónica no es las 24 horas, la entrega de algunos servicios no principales puede esperar fuera del horario laboral, y el tiempo de respuesta fuera del horario se describe de dos maneras.
Un comprador debe preguntar qué cláusula controla su producto específico, si el Pro Cloud gestionado tiene un escalamiento diferente del VDS no gestionado, si la respuesta de emergencia incluye intervención a nivel de instalación, y si hay un sistema de severidad nombrado con objetivos de tiempo de reparación.
La dotación de personal también se cruza con la migración. La página de VDS anuncia soporte de migración gratuito, incluida la transferencia de sitios web y bases de datos sin pérdida de datos ni interrupción del servicio. Eso es valioso si es cierto en el caso de un cliente, pero debe definirse. Mover un sitio web cPanel no es lo mismo que mover una aplicación personalizada, servidor Windows, base de datos en vivo, archivo de correo, zona DNS, configuración DNSSEC, lista blanca de firewall, trabajos cron e integraciones de terceros.
Los clientes deben preguntar qué cubre la "migración gratuita", qué debe preparar el cliente, si la migración está programada, si la reversión está incluida y cuánto tiempo debe permanecer activo el sitio antiguo.
Las ventanas de mantenimiento son explícitas y lo suficientemente grandes como para importar
La cláusula de mantenimiento es una de las señales más claras de que la nube de CloudTeknoloji sigue siendo infraestructura ordinaria. Lapolítica de serviciodice que cuando se necesita mantenimiento del servidor, mudanza o actualizaciones de hardware, los clientes son advertidos una semana, tres días y un día antes de la interrupción. Dice que tales interrupciones no excederán un total de 96 horas en un año y no se realizarán durante el horario laboral a menos que sea necesario. También excluye la responsabilidad por fuerza mayor por desempeño tardío, incompleto o no realizado.
Noventa y seis horas por año no es un objetivo de tiempo de inactividad; es un techo de mantenimiento según lo escrito en la política. Aun así, es un número de planificación significativo para el cliente. Una empresa que lee solo el lenguaje de tiempo de actividad de la página de hosting puede esperar un servicio casi continuo. Una empresa que lee la política ve que el trabajo de infraestructura planificado puede consumir un número significativo de horas a lo largo de un año. Eso puede ser aceptable para sitios de bajo riesgo, entornos de desarrollo, folletos de pequeñas empresas o aplicaciones locales no críticas.
No es suficiente para un cliente cuyos pedidos, centro de llamadas, flujos de pago o sistemas clínicos deben funcionar durante cada noche de mantenimiento.
La pregunta importante es cómo se aísla el mantenimiento. ¿Puede un host drenarse mientras las cargas de trabajo continúan en otro lugar? ¿Se migran en vivo los clientes VDS entre hosts? ¿El mantenimiento del almacenamiento requiere tiempo de inactividad? ¿Los eventos de mantenimiento de red son redundantes a nivel de switch o tránsito? ¿Pueden los clientes de Pro Cloud comprar mayor disponibilidad que el VDS estándar? ¿Se prueban las restauraciones de copia de seguridad después del reemplazo de hardware? ¿Se aplica el aviso de una semana, tres días, un día a todo el mantenimiento o solo al tiempo de inactividad esperado?
La política proporciona el patrón de alerta pública, pero el cliente necesita detalles de la arquitectura.
Esto también afecta a los clientes agencia y revendedores. Si un revendedor aloja docenas de sitios de clientes en daha.net, un evento de mantenimiento puede convertirse en docenas de correos electrónicos de clientes. Si un proveedor de servicios gestionados utiliza daha.net como capa VPS turca, una noche de reparación puede afectar a todos los clientes posteriores. Si un operador de comercio electrónico tiene una campaña programada, el aviso de mantenimiento debe ser compatible con las ventanas de congelación. La capacidad alojada se convierte en un calendario compartido, no solo en un gráfico de recursos.
El lenguaje de copia de seguridad es útil porque no es excesivamente reconfortante
El lenguaje de copia de seguridad de daha.net es más honesto que muchas páginas de hosting, y debe leerse cuidadosamente. Las páginas de productos de hosting y VDS anuncian copia de seguridad semanal o copia de seguridad periódica. Lapolítica de servicioda la regla más dura: los servidores de hosting se respaldan semanalmente y mensualmente, los servicios de servidor no se respaldan a menos que el cliente compre el servicio de copia de seguridad, las copias de seguridad pueden ser defectuosas o inutilizables, no se da garantía a los clientes de esas copias de seguridad, y la copia de seguridad de la cuenta es responsabilidad del cliente. También dice que cuando un cliente necesita una copia de seguridad tomada por daha.net, la empresa puede proporcionar una copia de seguridad disponible a su discreción, dependiendo del sistema de copia de seguridad.
Ese lenguaje debería alejar a los clientes del pensamiento mágico. Una etiqueta de copia de seguridad en un plan de hosting no es lo mismo que un servicio de restauración garantizado. Para hosting compartido, las copias de seguridad semanales y mensuales pueden ayudar con la eliminación accidental o falla del sitio, pero la política rechaza la recuperación garantizada. Para servicios VDS y de servidor, la política dice que la copia de seguridad no está incluida a menos que se compre. Para cargas de trabajo críticas, el comprador debe asumir que necesita su propio plan de respaldo probado hasta que los términos escritos digan lo contrario.
La diferencia entre "la copia de seguridad existe" y "la restauración funciona" es central para esta empresa. CloudTeknoloji vende capacidad alojada, pero el cliente aún puede ser propietario de la protección de datos. Un sitio WordPress puede respaldarse a nivel de aplicación en una cuenta de almacenamiento externa. Un VDS puede tomar una instantánea en una región separada. Una base de datos puede transmitir réplicas o volcados a un segundo proveedor. El DNS puede alojarse con un operador separado.
El cliente puede reducir el riesgo al hacer de CloudTeknoloji el host principal sin hacer de CloudTeknoloji el único lugar donde existen los datos.
El cliente debe hacer cinco preguntas sobre la copia de seguridad antes de usar daha.net para algo importante. Primero, ¿está incluida la copia de seguridad para este producto exacto, o debe comprarse por separado? Segundo, ¿dónde se almacena la copia de seguridad en relación con el sistema principal alojado en ICS? Tercero, ¿con qué frecuencia se prueba una restauración? Cuarto, ¿quién tiene las claves de cifrado y los derechos de administración? Quinto, ¿cuánto tiempo tomaría una restauración completa a la velocidad de red predeterminada? La política pública responde parte de la primera pregunta y advierte que las otras importan.
La facturación, la cancelación y la eliminación de datos son parte del tiempo de actividad
Los artículos de infraestructura a menudo se centran en rutas y racks, pero los términos de CloudTeknoloji muestran que el estado comercial puede ser igual de importante. Lapolítica de serviciodice que las órdenes no pagadas durante siete días se cancelan automáticamente. Dice que los servicios de hosting y servidor cloud que no se renuevan se eliminan completamente de los servidores un mes después del período de renovación. Dice que la cancelación del servicio elimina la cuenta junto con las copias de seguridad. También restringe la elegibilidad de reembolso para algunos complementos, licencias, dominios, SSL y otros servicios, y dice que la elegibilidad de reembolso del Servidor Cloud puede desaparecer si el equipo técnico instala complementos o software a solicitud del cliente.
Para un sitio web de consumo, estos términos pueden ser rutinarios. Para una carga de trabajo empresarial, son una dependencia. Una falla de pago con tarjeta, disputa de factura, retraso en la adquisición o cambio de personal puede convertirse en eliminación de datos si la renovación no se controla. Un cliente que se aleja de daha.net debe exportar archivos, bases de datos, DNS, buzones de correo, certificados, claves, licencias e imágenes de servidor antes de la cancelación o no renovación. Un cliente que depende de copias de seguridad para la reversión debe entender si esas copias de seguridad desaparecen con la cuenta.
Aquí es donde la economía del hosting se encuentra con el riesgo. Un proveedor local combinado puede ser más barato y más fácil que construir infraestructura redundante desde cero. Pero el hosting más barato a menudo devuelve alguna responsabilidad operativa al cliente: disciplina de renovación, copias de seguridad, preparación de migración, almacenamiento de credenciales, gestión de bloqueo de dominio, TTL de DNS y copias de restauración fuera del proveedor. El cliente debe tener un plan de salida el primer día, no después de un incidente.
El plan de salida es simple en principio. Mantener acceso al registrador independiente cuando sea posible. Mantener exportaciones de DNS. Mantener copias de seguridad fuera de la plataforma. Saber qué direcciones IP están vinculadas a listas blancas. Mantener una lista actual de certificados SSL y fechas de renovación. Probar la restauración de un sitio en otro proveedor. Mantener la continuidad del correo electrónico fuera de una sola cuenta de alojamiento web si el correo es crítico. Nada de esto significa evitar CloudTeknoloji. Significa usarlo como proveedor, no como la única copia del negocio.
La soberanía de datos es un punto de venta real con una compensación de recuperación
Para los clientes turcos, el hosting local puede ser valioso. Puede reducir la latencia a los usuarios domésticos, simplificar el soporte de idioma e impuestos, mantener los contratos bajo jurisdicción familiar y respaldar las preferencias de localidad de datos. Las páginas oficiales de CloudTeknoloji se inclinan hacia ese perfil local: oficinas en Estambul, instalación en Estambul, soporte en turco, aceptación de pedidos solo en Turquía según la política, identidad legal turca, dirección KEP y un conjunto de servicios dirigidos al hosting local, dominios y correo empresarial. Lavista de geolocalización para 46.28.232.0/24también alinea el prefijo público visible con Turquía.
Sin embargo, la localidad puede concentrar el riesgo si no se combina con una recuperación independiente. Un cliente que debe mantener los datos en Turquía puede necesitar un segundo sitio turco, un segundo proveedor, una segunda cuenta de copia de seguridad o al menos un DNS separado y un acuerdo de restauración. Un cliente que puede usar una copia de recuperación en el extranjero puede obtener una separación geográfica más fácil, pero debe considerar límites legales, de privacidad y contractuales. Las páginas públicas de CloudTeknoloji no resuelven esa compensación. Muestran un proveedor centrado en Turquía.
No publican una arquitectura completa de recuperación multisitio.
La conclusión correcta no es que el hosting local turco sea débil. Es que la soberanía y la resiliencia son objetivos de diseño separados. El primero pregunta dónde viven los datos y qué ley se aplica. El segundo pregunta si un cliente puede continuar después de una falla del sitio, ruta, almacenamiento, personal o cuenta. CloudTeknoloji puede ayudar con lo primero manteniendo servicios en Estambul. El cliente aún debe verificar lo segundo.
Esto es especialmente cierto para clientes con cargas de trabajo reguladas, reputacionales o sensibles a los ingresos. Una escuela, clínica, agencia, tienda de comercio electrónico o oficina profesional puede elegir daha.net porque el escritorio de soporte habla el mismo idioma, la entidad legal es alcanzable y el servidor está en Estambul. Eso es racional. Pero si el mismo servicio es también el único host de DNS, único host de correo, única ubicación de copia de seguridad y única ruta de soporte, entonces una ventaja local se convierte en un punto único operativo.
La solución no es abstracta: copia de seguridad separada, DNS separado, conmutación por error documentada, restauración probada y escalamiento por escrito.
Quién se ve afectado cuando este sistema falla
El primer grupo afectado son los clientes de hosting compartido. Estos son los usuarios con más probabilidades de sentir los límites de la plataforma pero menos probabilidades de entender la instalación detrás de ella. Una falla del hosting compartido puede desconectar sitios web, buzones de correo, bases de datos, paneles de control y rutas de renovación SSL a la vez. El cliente puede no tener acceso root o control directo de copia de seguridad. Por lo tanto, las exenciones de responsabilidad de la política de servicio sobre copias de seguridad importan más a los clientes menos técnicos.
El segundo grupo son los clientes de VDS y Pro Cloud. Tienen más control, pero también heredan más responsabilidad. Un cliente de VDS no gestionado tiene acceso root y puede construir su propia pila, pero las actualizaciones del sistema operativo, la seguridad de la aplicación, la copia de seguridad de la base de datos y la planificación de la restauración pueden recaer en el cliente. Un cliente de Pro Cloud gestionado puede obtener más ayuda, pero debe confirmar qué capas están gestionadas, cuáles son de soporte de mejor esfuerzo y cuáles siguen siendo propiedad del cliente.
El tercer grupo son las agencias y revendedores. Convierten un proveedor ascendente en muchas promesas descendentes. Si compran hosting revendedor, capacidad VDS o servidores gestionados de daha.net, sus propios clientes pueden ver a la agencia como el operador. Una ventana de mantenimiento de daha.net, cola de soporte o problema de ruta se convierte en un incidente de la agencia. Estos clientes necesitan actualizaciones de estado, plantillas de comunicación con el cliente, copias de seguridad de migración y límites de servicio claros antes de que comiencen los problemas.
El cuarto grupo son los clientes de dominio y correo electrónico. La expiración del dominio, las limitaciones de transferencia, los errores de DNS y las fallas de enrutamiento de correo pueden durar más que una interrupción web. La política de servicio describe avisos de renovación de dominio, renovación automática, períodos de restauración y condiciones de transferencia. Los clientes que colocan dominio, DNS, hosting y correo bajo una sola cuenta obtienen conveniencia. También ponen renovación, credenciales y escalamiento de soporte en un solo lugar. Separar el acceso de propiedad del control de hosting puede reducir ese riesgo.
El último grupo afectado es el propio CloudTeknoloji. Un AS público pequeño y una ruta concentrada no significan automáticamente debilidad operativa, pero significan que cada incidente público puede tener peso reputacional. Si los clientes ven la marca como un socio de confianza local, esperarán avisos claros, páginas de estado honestas, actualizaciones rápidas de reparación y ayuda práctica de migración. La política de servicio pública ya reconoce avisos de mantenimiento y respuesta de soporte. La próxima señal de madurez sería un historial de incidentes transparente y términos de recuperación específicos del producto.
Lo que resolvería las preguntas abiertas
El registro público es suficiente para un perfil cauteloso, pero no suficiente para una evaluación de resiliencia de alta confianza. Cinco divulgaciones adicionales cambiarían materialmente la calificación.
Primero, CloudTeknoloji podría publicar o proporcionar bajo contrato un límite de instalación y propiedad: qué servicios se ejecutan en el centro de datos ICS, cuáles son hardware propio de CloudTeknoloji, cuáles son capacidad alquilada y cuáles dependen de proveedores externos. Segundo, podría publicar términos de copia de seguridad específicos del producto: copias de seguridad incluidas, copias de seguridad pagadas, retención, ubicación fuera del sitio, tiempo de restauración, prueba de restauración y responsabilidad del cliente.
Tercero, podría declarar el diseño de tránsito para AS202048: transportistas ascendentes actuales, comportamiento de conmutación por error, manejo de DDoS, disponibilidad de IPv6 y si AS48678 o AS42910 siguen siendo opciones de respaldo disponibles o solo líneas de política históricas. Cuarto, podría proporcionar compromisos de mantenimiento y emergencia por nivel de producto, distinguiendo respuesta de reparación.
Quinto, podría documentar los derechos de salida: exportaciones de VM, copias de seguridad del panel de control, exportación de zona DNS, soporte de transferencia de dominio, límites de portabilidad de IP y tiempo de eliminación de cuenta.
Algunos de estos detalles pueden ya existir en contratos de clientes o propuestas de ventas. El problema es la verificabilidad pública. Desde el exterior, la empresa tiene una huella de identidad más sólida que muchos hosts, una ruta viva y autorizada, y una historia coherente de hosting en Estambul. También tiene una red pública visible pequeña, ningún origen IPv6 visible, una ruta ascendente observada a través de ICS y términos de servicio que colocan una responsabilidad significativa de copia de seguridad y renovación en el cliente.
El trabajo del comprador es hacer coincidir la criticidad de la carga de trabajo con esa evidencia. Un sitio de folleto de bajo riesgo, sitio pequeño de WordPress, configuración de correo empresarial local o VPS de desarrollo puede encajar cómodamente. Una tienda de alto tráfico, almacén de datos regulados, servicio de emergencia pública, aplicación crítica de pagos o plataforma de revendedor multicliente debe requerir redundancia por escrito y evidencia de restauración antes de migrar la producción.
Conclusión final
CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. no merece ni el rechazo ni la confianza ciega. La empresa detrás de daha.net es identificable, ha operado bajo una identidad comercial turca visible, publica información de contacto y legal, vende un amplio catálogo de hosting, afirma alojamiento en instalaciones de Estambul y tiene un AS público vivo. La ruta pública para AS202048 está anunciada, visible para los recolectores y cubierta por una autorización RPKI válida para 46.28.232.0/24.
La precaución es que la huella pública es estrecha. Un /24 IPv4 visible, ningún origen IPv6 visible, ningún perfil público de PeeringDB y un vecino AS actualmente observado no prueban una redundancia amplia. Los términos oficiales del servicio también recuerdan a los clientes que los servidores cloud, las copias de seguridad, el mantenimiento, las horas de soporte, el ancho de banda y el estado de renovación tienen límites.
En términos simples, CloudTeknoloji vende capacidad alojada que puede ser valiosa para empresas turcas, pero esa capacidad aún depende de racks, tránsito, energía, reemplazo de hardware, respuesta del personal y la propia disciplina de copia de seguridad y migración del cliente.
La postura correcta del comprador es práctica: usar el proveedor local cuando su hosting en Estambul, soporte en turco y servicios combinados se ajusten a la carga de trabajo, pero hacer que el proveedor muestre la ruta de recuperación. Preguntar dónde están los datos, dónde está la copia de seguridad, qué ruta falla, cómo se escalan las reparaciones, qué tan rápido puede ejecutarse una restauración completa, qué sucede después de la no renovación y cómo el cliente sale limpiamente.
Hasta que esas respuestas estén escritas y probadas, la evidencia pública respalda un perfil de infraestructura de confianza media: operación real, profundidad de red pública limitada y preguntas de recuperación que importan más que la palabra "nube".