Resumen
- REG.RU expone una superficie operativa genuina: IANA lista al registrador como acreditado, el enrutamiento observado por RIPE muestra cientos de anuncios IPv4 e IPv6 detrás de AS197695, y el catálogo de marca vende alojamiento compartido, máquinas virtuales, bare metal, almacenamiento, bases de datos, Kubernetes y coubicación. Eso es más que un escaparate, pero no establece que la empresa registradora nombrada posea cada instalación u opere cada capa de producto por sí misma.
- La resiliencia no se hereda del tamaño del portafolio. REG.RU publica múltiples ubicaciones rusas, herramientas de copia de seguridad y migración, direcciones flotantes, redes privadas y un objetivo de servicio en la nube del 99,95 %, sin embargo, la elección del sitio, la separación de las copias de seguridad, las exclusiones de mantenimiento, la sustitución de hardware, la escalada de soporte y el diseño de aplicaciones multiplataforma determinan la recuperación que los clientes realmente reciben.
- La conclusión operativa más clara es, por tanto, condicional. La red y el inventario de productos activos respaldan tratar a REG.RU como un proveedor de infraestructura operativo. La propiedad de las instalaciones, la capacidad por servicio, la replicación entre regiones y el historial de rendimiento de incidentes siguen siendo solo parcialmente visibles, por lo que un cliente debe verificar la entidad contratante exacta, la ubicación, el objetivo de recuperación, el diseño de ruta y el procedimiento de exportación de cada servicio antes de considerar una implementación de REG.RU como redundante.
Una cuenta de registrador se convirtió en una superficie de control de infraestructura
REG.RU sigue siendo reconociblemente un registrador de dominios. Elregistro de identificadores de registradores de la IANAenumera a «Registrar of Domain Names REG.RU LLC» como acreditado bajo el identificador 1606 y apunta a su servicio RDAP. Su propiainformación de empresaidentifica a la sociedad de responsabilidad limitada rusa cuyo nombre en inglés aparece en la entrada del directorio, con el identificador fiscal 7733568767 y una dirección legal en Moscú. Estos hechos establecen el sujeto de este perfil de manera más sólida que la marca por sí sola.
Sin embargo, la propuesta para el cliente va mucho más allá del registro. Lapágina de la empresa de REG.RUdescribe una gama de nube basada en OpenStack y VMware, servidores dedicados y coubicación. El actualcatálogo de servicios de REG.Cloudenumera máquinas virtuales, servidores bare-metal físicos, bases de datos administradas, Kubernetes, almacenamiento compatible con S3, entornos privados de OpenStack y VMware, servicios de red y espacio en rack. Una pequeña organización puede, por tanto, comprar el nombre, el DNS autoritativo, el alojamiento del sitio web y la capacidad de servidor a través de superficies relacionadas de REG.RU. Un cliente más grande puede alquilar equipos físicos o combinarlos con recursos virtuales y servicios administrados.
Esa combinación es importante desde el punto de vista operativo. Una cuenta de registrador ya no es solo donde se almacena una fecha de renovación. Puede convertirse en el lugar donde se encuentran los nombres públicos, los registros de direcciones, los pedidos de computación, las políticas de copia de seguridad, los tickets de soporte y los saldos de pago. La comodidad reduce el costo de poner un servicio en línea. También concentra la autoridad administrativa.
La pérdida de acceso, un error de pago, un cambio incorrecto de DNS o un incidente de seguridad a nivel de cuenta puede afectar a varias capas incluso cuando las máquinas subyacentes permanecen en buen estado.
Esta es la primera distinción que los clientes deben preservar: la integración comercial no es redundancia técnica. Comprar un dominio y un servidor de la misma familia puede simplificar la configuración y el soporte. No crea un segundo proveedor de DNS autoritativo, una segunda nube, una copia independiente de los datos o una credencial administrativa separada. Un diseño de recuperación debe crear deliberadamente esas separaciones.
Lo contrario también es importante. El amplio catálogo no debe descartarse como una lista de etiquetas de reventa. REG.RU tiene recursos de red observables, publica ubicaciones de instalaciones específicas, anuncia configuraciones físicas en stock y documenta sus propios controles operativos. La tarea es identificar dónde esa evidencia es sólida y dónde se le está pidiendo a una declaración a nivel de marca que soporte más peso del que puede.
Una marca no significa un solo operador o un solo modelo de propiedad
El límite legal es inusualmente importante aquí porque las superficies públicas de REG.RU usan un nombre para varios tipos de servicio. Lasreglas del sitioidentifican a «REG.RU Domains Hosting» LLC como el administrador de las propiedades web e identifican a «Domain names registrar REG.RU» Ltd como un socio que proporciona servicios bajo sus propios acuerdos de cliente. Por separado, lasreglas de soportedel registrador describen el soporte proporcionado por la empresa registradora a través de servicios de registro, alojamiento y otros. Lostérminos promocionales actuales para GPU en la nubetambién han nombrado a la empresa registradora como organizadora. Los documentos muestran una estrecha integración operativa, pero no respaldan tratar a las dos personas jurídicas como intercambiables.
La misma precaución se aplica a los edificios. REG.RU dice que utiliza una mezcla de capacidad de centros de datos propios y conectados. Sus páginas de productos nombran instalaciones comerciales, así como sitios de la marca REG.RU. Lapágina de VPSidentifica ubicaciones que incluyen KIAEHOUSE en el sitio del Instituto Kurchatov, SafeData, Medvedkovo-2, DataPro, una instalación en la autopista Varshavskoye, Data Centre No. 1 en San Petersburgo y Zhiguli Valley en Toliatti. Un anuncio de junio de 2026 dice que se abrió una tercera región de nube en Moscú en la instalación Magistralny-1 de Datahouse. Esos nombres indican arrendamientos, acuerdos de alojamiento u otras dependencias de instalaciones junto con cualquier edificio que el grupo pueda poseer directamente.
Esta no es una debilidad exclusiva de REG.RU. La mayoría de los servicios de infraestructura son negocios en capas. Un proveedor puede poseer servidores, arrendar jaulas o racks, contratar energía, comprar tránsito y usar instalaciones de terceros mientras opera el servicio al cliente. Pero cada capa cambia el límite del incidente. Un operador de instalación controla la planta eléctrica y la refrigeración. Un operador controla un circuito externo. REG.RU controla su flota de servidores, virtualización, configuración de servicio y respuesta al cliente en diversos grados.
El cliente controla la aplicación, las credenciales, la ubicación de los datos y gran parte del plan de recuperación.
La pregunta práctica de adquisición es, por tanto, más precisa que “¿Es REG.RU propietaria de sus centros de datos?”. Es: para este servicio solicitado en esta ubicación seleccionada, ¿quién es el propietario del servidor, quién proporciona manos remotas, quién controla el extremo de la red, quién mantiene el hipervisor y el almacenamiento, y qué empresa debe el recurso contractual? Una máquina bare-metal anunciada como físicamente disponible es un acuerdo diferente al de una máquina virtual en un clúster compartido, y ambos difieren de un servidor propiedad del cliente colocado en coubicación.
La documentación de REG.RU es útil porque revela partes de esa división, pero no publica una matriz completa de propiedad y responsabilidad para cada producto y ubicación. Hasta que un contrato o anexo técnico proporcione esa matriz, las afirmaciones de propiedad de todo el portafolio deben tratarse como no verificadas. El servicio puede ser real y estar operando sin que cada rack sea un activo corporativo de la entidad del directorio.
La finca física es rusa, distribuida y descrita de manera desigual
Laguía de ubicación de alojamientode REG.RU da cinco direcciones principales: tres en Moscú, una en San Petersburgo y una en Toliatti. Dice que el alojamiento virtual compartido está en la ubicación de la plaza Kurchatov en Moscú. También dice que las instalaciones tienen energía de respaldo, refrigeración y seguridad por capas. Esta es una evidencia útil específica del servicio porque vincula el alojamiento compartido a un lugar con nombre en lugar de simplemente decir “Rusia”.
El catálogo más amplio del proveedor es más amplio. La página de VPS proporciona nombres de instalaciones, cifras de energía, recuentos de racks y tipos de servicio. Describe Data Centre No. 1 en la calle Predportovaya en San Petersburgo como un sitio diseñado Tier III con 2 MW y 260 racks, y Zhiguli Valley en la región de Samara como certificado según los estándares Uptime Institute Tier Design y Tier Facility. La página también incluye sitios de Moscú con diferentes combinaciones de bare metal y nube pública. Es posible una verificación independiente para al menos una de estas dependencias: lapágina de contacto propia de Data Centre No. 1da la misma dirección de la calle Predportovaya, lo que confirma que la ubicación de San Petersburgo de REG.RU corresponde a una instalación operada por separado.
La declaración de portafolio más reciente de REG.RU es más expansiva. Al anunciar instancias de NVIDIA Blackwell en junio de 2026, la empresa dijo que la nube de marca tenía diez centros de datos, 85,5 MW de capacidad agregada y 300 Gbit/s de rendimiento de canal óptico. Describió la nueva región Moscú-3 enDatahouse Magistralny-1como un contorno de infraestructura independiente con su propio clúster OpenStack e hipervisores. El anuncio atribuye 1.100 racks, hasta 15 kW por rack y un objetivo de instalación del 99,99 % a ese sitio.
Esas cifras son evidencia de la escala que REG.RU está comercializando, no una medida directa de la capacidad disponible para un cliente en particular. La alimentación total de servicios públicos de una instalación incluye espacio utilizado por otros inquilinos. Un recuento de racks no dice nada sobre cuántos racks ocupa REG.RU. Una densidad máxima de rack no muestra la carga media implementada. El rendimiento del canal óptico no es lo mismo que el tránsito de cliente no congestionado en cada ubicación. Diez sitios conectados no implican que cada servicio pueda ejecutarse en los diez, o que los datos se repliquen automáticamente entre ellos.
La evidencia más útil para la decisión aparece en la ruta de pedido. Elinventario de servidores dedicadosde REG.RU permite a los clientes filtrar máquinas físicas por varias ubicaciones con nombre en Moscú, y las listas individuales identifican un procesador, memoria, diseño de disco, opción de gestión remota, puerto de red y colocación. Esa es capacidad instalada o pedible, aunque sigue siendo un inventario cambiante en lugar de un total de flota auditado. La documentación de pedidos en la nube también indica a los clientes que elijan una región de colocación. Estas ubicaciones seleccionables importan más que una gran cifra de finca agregada porque definen dónde un cliente puede realmente colocar una carga de trabajo hoy.
El resultado es un mapa en capas. El alojamiento compartido tiene una dirección principal revelada en Moscú. El bare metal aparece en varios sitios con nombre. Los servicios gestionados en la nube exponen un conjunto más pequeño de regiones o zonas que evoluciona por producto. San Petersburgo y Toliatti amplían la elección geográfica, mientras que los nuevos sitios de Moscú amplían la capacidad metropolitana. Nada de esto por sí mismo prueba la redundancia síncrona entre ciudades, edificios o clústeres.
La capacidad instalada no es capacidad utilizable
El marketing de la nube convierte las máquinas físicas en unidades simples: vCPU, memoria y almacenamiento. La conversión oculta las decisiones de utilización y mantenimiento que determinan si una unidad solicitada está disponible cuando aumenta la demanda. El catálogo de REG.RU demuestra un rango sustancial, pero la distinción entre capacidad instalada y utilizable sigue siendo esencial.
Para el bare metal, la capacidad utilizable es visible como configuraciones en stock. Lapágina de servidores dedicadosanuncia opciones AMD EPYC, Intel Xeon, NVMe, discos duros y GPU, y dice que el equipo está en stock. Las ofertas individuales muestran una máquina específica y afirman que la entrega comienza a partir de 45 minutos para muchos servidores. Esto es más fuerte que una página de producto conceptual: sugiere un inventario activo y un mecanismo de pedido. Sin embargo, el stock cambia, y una pieza de repuesto no está garantizada simplemente porque una máquina similar aparezca en el catálogo. Los clientes con objetivos de restauración estrictos necesitan saber si las unidades, fuentes de alimentación, placas base y aceleradores defectuosos tienen repuestos in situ en la instalación seleccionada y qué sustitución está permitida.
Para las máquinas virtuales, la capacidad utilizable depende de la capacidad del clúster, el rendimiento del almacenamiento, los límites del planificador y la disponibilidad de la red. Laguía de pedidos de servidores en la nubede REG.RU muestra configuraciones estándar, de alta frecuencia y de datos regulados, además de imágenes de GPU. Un anuncio de hardware de junio de 2026 va más allá, nombrando sistemas Supermicro, procesadores AMD EPYC 9554 y aceleradores RTX 6000 Pro Blackwell Server Edition para la región Moscú-3. Esa especificidad respalda la presencia de un nuevo conjunto de hardware real. Sin embargo, no revela la sobresuscripción, la capacidad libre o el número de hosts instalados.
El almacenamiento tiene su propia brecha entre la reclamación de un producto y la capacidad recuperable. Lapágina de almacenamiento compatible con S3dice que los objetos se guardan en tres copias y que el proveedor es responsable de la infraestructura, la replicación, el escalado y la disponibilidad. Tres copias pueden proteger contra algunos fallos de dispositivos o nodos. Sin embargo, la página no dice expresamente que esas copias estén en tres edificios o zonas de fallo independientes. Tres réplicas dentro de un sitio no son una copia de recuperación ante desastres regional. Un cliente debe preguntar por la política de colocación, los límites del dominio de fallo, el comportamiento de versionado y el proceso de recuperación, en lugar de asumir que «tres copias» significa «tres regiones».
Incluso la capacidad eléctrica de una instalación es condicional. Un edificio de 36 MW puede tener una infraestructura sólida mientras que el área arrendada, la potencia contratada y los puertos de red instalados del proveedor son mucho más pequeños. Un límite de diseño de 15 kW por rack no significa que cada rack tenga esa carga aprovisionada. La unidad útil para un cliente no es la calificación del campus; es el contrato de capacidad adjunto a un servicio elegido y la capacidad del proveedor para entregar más durante un fallo en otro lugar.
Esta es la razón por la que las pruebas de conmutación por error deben incluir la escasez. Si un clúster de Moscú falla, ¿puede la segunda ubicación aceptar la carga de trabajo desplazada, no solo ejecutar una pequeña máquina de espera? Si un host GPU especializado falla, ¿se mantiene un acelerador equivalente en reserva? Si un pool de almacenamiento deja de estar disponible, ¿puede el pool superviviente servir tanto al tráfico normal como al de recuperación? Los materiales públicos no responden a esas preguntas, por lo que pertenecen a la diligencia debida técnica.
AS197695 es la señal independiente más clara de operación
El registro de red proporciona la evidencia más sólida de que la entidad del directorio nombrada opera infraestructura en lugar de solo vender el servicio de otra empresa. El registro en RIPE NCC y las observaciones de enrutamiento público asocian AS197695, AS-REGRU, con «Domain names registrar REG.RU», Ltd. Unainstantánea de BGP.Toolsdescribe la red como activa y orientada al contenido, y muestra cientos de prefijos IPv4 originados, además de anuncios IPv6. Unarespuesta de prefijos anunciados de RIPEstatobservó 477 anuncios el 12 de julio de 2026: 453 prefijos IPv4 y 24 IPv6, excluyendo rutas con muy baja visibilidad de colector.
La amplitud de esa superficie es material. Es consistente con un proveedor de alojamiento que sirve a muchos bloques de direcciones y servicios de clientes. Un prefijo de muestra,176.99.13.0/24, es originado por AS197695 y contiene direcciones utilizadas por los servidores de nombres de REG.RU. El dominio web principal de la empresa también se resuelve dentro del mismo sistema autónomo según lavista DNS de Hurricane Electric. Estas observaciones vinculan las superficies corporativas, de DNS y de alojamiento a un dominio de enrutamiento operado.
Larespuesta de vecinos ASNde RIPE NCC mostró numerosos números de AS adyacentes en rutas observadas en la misma fecha, incluyendo TransTeleCom, EDINAYA SET, Hurricane Electric, OBIT, RETN y ER-Telecom entre otros. Eso indica conectividad externa variada en la vista de enrutamiento global. No prueba que cada instalación de REG.RU tenga entradas físicamente diversas, que cada red nombrada sea un upstream de pago, o que dos circuitos no compartan un conducto. La clasificación de ruta izquierda/derecha de RIPE NCC es una observación sobre la posición de la ruta AS, no una etiqueta de relación comercial.
También hay dos advertencias. Primero, AS43146 está registrado por la misma organización, peroBGP.Tools informa queestá ausente de la tabla global actual. Un sistema autónomo registrado no es evidencia de un servicio en vivo; AS197695 es la señal operativa relevante. Segundo, una consulta alendpoint de red PeeringDBno devolvió ningún registro de red público para AS197695. La participación en PeeringDB es voluntaria, por lo que la ausencia no es evidencia de una conectividad deficiente. Sí significa que el registro público carece de una matriz de instalaciones e intercambios mantenida por el proveedor que podría ayudar a verificar dónde se interconecta REG.RU.
La escala de la red tampoco elimina la concentración. Cientos de prefijos pueden atravesar un único sistema autónomo y compartir políticas de enrutamiento, sistemas de mitigación o personal operativo. Los clientes que utilizan REG.RU para DNS autoritativo, alojamiento y origen de la aplicación pueden seguir dependiendo de la misma cuenta y red, incluso cuando las direcciones IP difieren. La verdadera diversidad de rutas requiere pruebas de ruta desde redes de usuarios relevantes y confirmación de los circuitos físicos en cada sitio seleccionado.
La promesa de nivel de servicio deja espacio para ventanas de reparación
El acuerdo de nivel de servicio en la nube de REG.RU es inusualmente revelador sobre la diferencia entre un objetivo de disponibilidad y un servicio ininterrumpido. Elacuerdo efectivo a partir del 14 de abril de 2026establece objetivos mensuales del 99,95 % para servicios de infraestructura, red y centro de datos, como energía, calor, ventilación y refrigeración. En un mes de 730 horas, el 0,05 % corresponde a aproximadamente 21,9 minutos, antes de considerar las exclusiones.
Las exclusiones importan. El acuerdo permite interrupciones por trabajos planificados por un total de hasta 48 horas al año y no más de seis horas en un mes, con al menos 24 horas de antelación. Los trabajos urgentes pueden durar lo necesario para eliminar o prevenir una emergencia, con notificación inmediatamente antes de la interrupción. El acuerdo dice que esas interrupciones de mantenimiento no cuentan como indisponibilidad normal del servicio.
También excluye varias condiciones causadas por el cliente o externas y proporciona un tratamiento de créditos de servicio para indisponibilidades que califiquen, en lugar de una compensación por las pérdidas comerciales más amplias del cliente.
Esto no hace que el objetivo carezca de sentido. Un objetivo escrito en sistemas de computación, red e instalaciones es una línea de base útil. Identifica un recurso y requiere que el proveedor mida la disponibilidad. Pero cambia la interpretación de ingeniería. Un cliente no puede convertir el 99,95 % en una promesa de que no puede ocurrir ninguna ventana de mantenimiento de seis horas. Una aplicación que no puede tolerar la ventana permitida necesita una segunda ubicación de servicio y un método probado para mover el tráfico.
Las páginas de productos a veces usan cifras diferentes. La guía de ubicación de alojamiento compartido anuncia un 99,9 % de tiempo de actividad, mientras que el anuncio de Moscú-3 atribuye un 99,99 % a la instalación. Estos porcentajes se refieren a diferentes alcances y no deben mezclarse. Un diseño o objetivo de instalación no es lo mismo que la disponibilidad de la aplicación. Un servidor puede permanecer encendido mientras falla el almacenamiento, un hipervisor, una ruta, el DNS o el software del cliente.
Por el contrario, una plataforma puede mantener una aplicación en línea durante un fallo del host si la carga de trabajo se distribuye correctamente.
La transparencia de incidentes públicos es escasa. No se encontró ningún host de estado público de REG.RU claramente resoluble durante esta revisión, y el archivo de noticias de la empresa no es un historial de incidentes estructurado. Los monitores de terceros solo proporcionan señales débiles. Por ejemplo, lapágina de tiempo de actividad de Hosters.ruinformó verificaciones contra el sitio web público de REG.RU, no contra la finca de nube del cliente, yWho.ismide igualmente el endpoint corporativo. Una sonda fallida podría reflejar filtrado, un problema de redireccionamiento o el propio sitio web; una sonda exitosa no dice nada sobre una VM de cliente en otra región. Estas observaciones no pueden validar ni refutar el rendimiento del SLA de la nube.
Un estándar de transparencia más sólido incluiría estado por servicio, etiquetas de región, tiempos de inicio y recuperación de incidentes, componentes afectados y explicaciones posteriores al incidente. En su ausencia, los clientes deben solicitar informes de disponibilidad históricos y preguntar cómo el trabajo planificado, el trabajo urgente y la degradación parcial aparecen en las mediciones del servicio.
El fallo del hardware convierte la abstracción de la nube de nuevo en inventario y mano de obra
Una máquina virtual se siente independiente de un servidor en particular hasta que falla un componente físico. Un servicio bare-metal nunca oculta esa dependencia. La documentación de REG.RU muestra tanto las ventajas como los límites de su modelo operativo de hardware.
El catálogo dedicado incluye control remoto, protección DDoS, un puerto de red, instalación del sistema operativo y «reemplazo operativo» de fallos. Suguía IPMIexplica que algunos servidores exponen gestión fuera de banda independiente y que KVM está disponible donde IPMI no lo está. Un cliente puede usar ese canal para inspeccionar problemas de arranque, reiniciar una máquina o instalar un sistema operativo incluso cuando el sistema operativo principal no está disponible. Esto reduce la dependencia del soporte para algunos fallos.
No reemplaza la intervención física. Una placa base, dispositivo de almacenamiento, fuente de alimentación o interfaz de red muerta todavía requiere una persona y un repuesto. El «reemplazo operativo» no es un objetivo de tiempo de reemplazo publicado. El proveedor puede restaurar el servicio intercambiando un componente, moviendo discos, suministrando un servidor diferente o reconstruyendo el entorno operativo, y esas opciones tienen diferentes consecuencias para la integridad de los datos y el tiempo de inactividad.
La generación del hardware también afecta la recuperación. El catálogo contiene tanto sistemas EPYC y GPU recientes como configuraciones Xeon más antiguas. Ese rango es económicamente racional: los clientes intercambian rendimiento y antigüedad por precio. Pero una política de reemplazo debe definir si el cliente recibe piezas idénticas, rendimiento equivalente o cualquier sustituto disponible. Las interfaces de memoria y disco heredadas pueden ser más difíciles de reemplazar rápidamente que el stock actual. Las GPU especializadas crean una restricción de inventario aún más ajustada.
Para la nube virtual, el proveedor puede mover o recrear un invitado en otro host solo si el clúster, el almacenamiento y el diseño de red lo admiten y existe capacidad de sobra. REG.RU describe su nube como tolerante a fallos, pero las páginas de productos públicos no revelan la política de evacuación de host o los dominios de fallo de cada servicio. La documentación de Kubernetes gestionado dice que un clúster tolerante a fallos puede cambiar a un nodo maestro de reserva, lo que protege ese componente de control.
No hace que las cargas de trabajo del cliente sean multisitio automáticamente ni garantiza que los datos con estado sobrevivan a la pérdida de una instalación.
El diseño de la aplicación del cliente sigue siendo, por tanto, decisivo. Los servicios sin estado pueden recrearse a partir de imágenes y configuración más fácilmente que una única base de datos mutable. Una base de datos bare-metal con discos locales necesita réplicas o copias de seguridad recuperables en otro lugar. Una máquina virtual con una instantánea en el mismo dominio de almacenamiento puede seguir expuesta a un fallo del dominio de almacenamiento. La marca puede suministrar componentes útiles, pero ninguna selección del catálogo convierte una sola instancia en una arquitectura de recuperación.
Las copias de seguridad son productos, no una prueba de recuperabilidad
REG.RU ofrece varios mecanismos de copia de seguridad, y las diferencias entre ellos son consecuentes. El alojamiento compartido recibe copias de seguridad diarias automáticas, según laguía de copias de seguridad de alojamiento. La guía dice que las copias se conservan durante 30 días, se realizan durante la noche y están disponibles más tarde al día siguiente. Esto es apropiado para muchos sitios web, pero implica una brecha de punto de recuperación potencialmente larga para datos que cambian con frecuencia.
La copia de seguridad del servidor en la nube se habilita y factura por separado. Laguía de copias de seguridad en la nubedice que la política predeterminada conserva tres copias, incluyendo una semanal y las dos últimas versiones, con creación diaria. Los clientes pueden cambiar las políticas de retención y restaurar un servidor desde una copia guardada. La restauración puede requerir la actualización de los registros de dominio cuando cambia una dirección. Ese último detalle es significativo desde el punto de vista operativo: la recuperación de la computación y la recuperación del tráfico pueden ser pasos separados.
Los servidores dedicados tienen más opciones. Lapágina de producto de copias de seguridadde REG.RU describe copias diarias a nivel de archivo para Linux, opciones de Veeam, almacenamiento FTP, S3 y diseños privados. Dice que las copias de seguridad se almacenan por separado del servidor, y su descripción estándar de Linux retiene los siete días anteriores. Diseños más elaborados pueden colocar copias recientes en disco y archivos más largos en cinta. «Separadamente del servidor», sin embargo, no significa necesariamente «en un edificio separado» o «fuera del proveedor». Los clientes necesitan la ubicación exacta y la separación administrativa.
El servicio S3 añade otra opción y admite una interfaz abierta. Un endpoint compatible con S3 puede facilitar la integración de aplicaciones y la transferencia de datos más que un producto de almacenamiento solo propietario. REG.RU dice que el servicio mantiene tres réplicas y permite la gestión a través de la API de S3 y Terraform. Eso respalda la portabilidad a nivel de objeto. No prueba que un gran conjunto de datos pueda exportarse en el tiempo requerido, que las versiones estén habilitadas o que las réplicas internas del proveedor protejan contra la eliminación de la cuenta o las claves de acceso comprometidas.
Una prueba de recuperación creíble tiene cuatro partes. La copia debe contener los datos requeridos. Debe estar aislada del fallo iniciador. El cliente debe poder autenticarse y recuperarla durante un incidente. El sistema restaurado debe pasar una verificación de integridad a nivel de aplicación. Los mensajes de finalización de la copia de seguridad solo establecen la primera parte de manera imperfecta.
Esto es especialmente importante cuando el dominio, el DNS, la computación y la copia de seguridad utilizan una sola cuenta. Un atacante o administrador con amplios derechos puede ser capaz de cambiar registros, eliminar máquinas y eliminar copias. Los clientes deben separar las credenciales, usar copias independientes para datos críticos, proteger la eliminación con controles de retención cuando estén disponibles y practicar la restauración en otro entorno. La presencia de un botón de copia de seguridad es valiosa, pero una restauración cronometrada es la evidencia que importa.
La elección multisitio no es un servicio multisitio automático
REG.RU ha añadido una elección de ubicación significativa. Un anuncio de 2023 describió unsitio de nube en San Petersburgojunto con tres centros de datos en Moscú. Una actualización operativa de 2024 dijo que la empresa conectó un nuevo sitio en Toliatti mientras expandía los productos en la nube. En marzo de 2026, REG.Cloud anunció unasegunda ubicación en Moscú para bases de datos gestionadas, permitiendo a los clientes implementar DBaaS en Moscú-1 o Moscú-2 y restaurar en un nuevo clúster. En junio, Moscú-3 añadió un contorno OpenStack separado.
No todos estos son el mismo tipo de redundancia. Una segunda instalación dentro de Moscú puede reducir la exposición a un fallo de edificio, mantenimiento local o un incidente de clúster. Sigue expuesta a peligros metropolitanos, controles de red regionales y algo de personal o sistemas de control compartidos. Un despliegue en Toliatti o San Petersburgo aumenta la separación geográfica, pero puede ofrecer un conjunto de productos, un pool de capacidad o un perfil de latencia diferentes. Los materiales públicos no afirman que cada servicio pueda conmutar por error automáticamente en todos estos sitios.
La actualización de DBaaS es un buen ejemplo de progreso preciso pero limitado. Dice que los clientes pueden seleccionar cualquiera de las dos ubicaciones de Moscú, restaurar una copia de seguridad en un nuevo clúster sin detener el original y usar la recuperación a un punto en el tiempo para PostgreSQL. Esas capacidades reducen el costo de probar la recuperación y moverse a una instancia limpia. El anuncio dice que una segunda ubicación mejora la distribución de carga y el diseño resiliente; no dice que las bases de datos se repliquen sincrónicamente en ambas ubicaciones por defecto.
Las direcciones públicas flotantes también tienen un alcance limitado. Laguía de IP flotantede REG.RU dice que una dirección se puede adjuntar a un dispositivo dentro de una subred privada. Eso es útil para la conmutación por error entre instancias en esa red. No es evidencia de que la misma dirección pueda moverse a otra región o sobrevivir a la pérdida de la capa de control de red. Del mismo modo, las redes privadas unen recursos, pero necesitan un diseño de ruta, dirección y seguridad por parte del cliente.
Kubernetes gestionado ofrece nodos de plano de control de reserva, y S3 proporciona replicación, pero cada uno protege un componente específico. La resiliencia surge solo cuando las dependencias de la aplicación se alinean: computación en más de un dominio de fallo, datos replicados o restaurables, enrutamiento de tráfico independiente del sitio fallido, secretos disponibles, capacidad reservada y operadores capaces de ejecutar el cambio.
Los clientes también deben preguntar si la región objetivo se puede seleccionar en el momento del pedido para cada componente. Una máquina virtual en Moscú-2 emparejada con almacenamiento disponible solo en Moscú-1 puede conservar una dependencia oculta entre sitios. Una base de datos gestionada puede admitir dos ubicaciones mientras que el repositorio de copias de seguridad permanece compartido. La documentación pública respalda la presencia de opciones; no proporciona un mapa de dependencias completo.
La diversidad de tránsito debe probarse en el extremo del servicio
Los vecinos observados de AS197695 y los cientos de prefijos hacen improbable una red de un solo operador a nivel de sistema autónomo. REG.RU también anuncia una capacidad de red privada de aproximadamente 200 Gbit/s y canales de acceso duplicados de 40 Gbit/s en su página de VPS, mientras que la declaración de portafolio más reciente cita 300 Gbit/s de canales ópticos. Estas cifras indican una red sustancial, pero no sustituyen la evidencia de ruta por sitio.
La red puede fallar en varias capas. Un conmutador de la parte superior del rack puede aislar un grupo de servidores. Un cross-connect de instalación puede fallar mientras que el sistema autónomo más amplio sigue siendo visible. Una fuga de ruta o un error de filtrado puede hacer que los prefijos seleccionados sean inalcanzables desde algunas redes. Los controles DDoS pueden proteger la capacidad al tiempo que introducen falsos positivos. Un firewall del lado del cliente o un cambio de dirección puede parecer una interrupción del proveedor.
El DNS puede seguir respondiendo con un origen inalcanzable, o el origen puede funcionar mientras que la cuenta de REG.RU utilizada para cambiar el DNS no está disponible.
Para un cliente, la prueba relevante comienza desde la dirección de la aplicación, no desde el titular del ASN del proveedor. Las observaciones de ruta deben recopilarse desde las poblaciones de usuarios y desde más de una red externa. Los traceroutes no prueban la diversidad física, pero las mediciones repetidas pueden mostrar si las rutas convergen en el mismo operador. Los documentos contractuales o los diagramas de red deben identificar cross-connects, salas de encuentro y entradas de edificios separados cuando esos detalles importen.
La falta de un registro público de PeeringDB hace que esta verificación sea más difícil. PeeringDB podría haber enumerado intercambios, instalaciones, capacidad y política, pero su naturaleza voluntaria significa que REG.RU puede simplemente usar acuerdos privados o elegir no publicar. Los datos de RIPE NCC confirman la accesibilidad a Internet y la adyacencia variada; no pueden localizar cada interconexión. El grado de evidencia correcto es, por tanto, fuerte para una red activa y considerable, y medio a débil para la diversidad de rutas específica de la instalación.
La distinción también afecta a los diseños «multisitio» dentro de un mismo proveedor. Dos regiones de REG.RU pueden usar hosts y almacenamiento separados, pero compartir AS197695, servicios de mitigación, gestión de direcciones o política de tránsito externo. Eso puede ser una compensación aceptable. Protege contra muchos fallos locales mientras preserva una baja complejidad operativa. No es equivalente a usar un proveedor de DNS independiente, un segundo sistema autónomo y una segunda nube para la ruta más crítica.
La facturación, el soporte y el control de la cuenta son dependencias de infraestructura
El fallo de la infraestructura no se limita al hardware roto. Los términos de la nube de REG.RU describen un saldo que se carga a medida que se utilizan los recursos, y el SLA excluye las interrupciones asociadas con el incumplimiento de las condiciones de pago. Un servicio puede, por tanto, dejar de estar disponible a través del estado comercial, incluso cuando el rack, la ruta y el hipervisor están en buen estado. Las organizaciones deben tratar las alertas de saldo, los derechos de renovación y los métodos de pago como controles de producción.
La cuenta tiene una importancia similar. Los servicios de alojamiento en Rusia requieren la identificación del cliente, y laguía de identificación en la nubede REG.RU aplica ese requisito a máquinas virtuales, bases de datos, Kubernetes, S3 y servidores dedicados físicos. La identificación puede fortalecer la responsabilidad, pero introduce dependencias de documentación y acceso. Un cliente corporativo debe asegurarse de que más de un empleado autorizado pueda gestionar la cuenta y que los registros de propiedad se mantengan actualizados cuando el personal cambie.
La cobertura de soporte está diferenciada. REG.RU anuncia soporte técnico las 24 horas, mientras que suguía de soporte en la nubeindica a los clientes que elijan una cola específica del servicio y enumera horas de consulta telefónica diarias. Los avisos de vacaciones han dicho que el soporte técnico para dominios, alojamiento, productos corporativos y en la nube continúa las 24 horas, mientras que algunas funciones de oficina o solicitudes generales cierran. Eso hace que el enrutamiento de tickets y los derechos de escalada sean importantes durante un incidente complejo.
El soporte también cruza los límites de responsabilidad. En un servidor bare-metal o en la nube no gestionado, el proveedor puede restaurar la energía, la red o el hardware mientras que el cliente repara el sistema operativo y la aplicación. Los servicios gestionados trasladan parte de la responsabilidad hacia arriba, pero los clientes siguen siendo dueños de la clasificación de datos, el comportamiento de la aplicación y la configuración de acceso.
La página de S3 divide explícitamente la responsabilidad: el proveedor ejecuta la replicación y la infraestructura física; el cliente gestiona los permisos, el ciclo de vida, el versionado, las integraciones y las claves.
Un plan de escalada práctico debe identificar al titular del contrato, los contactos técnicos, los contactos de facturación y la evidencia requerida en un ticket. El SLA de REG.RU solicita información detallada del servicio y de la falla, y puede requerir acceso a un servidor para su investigación. Durante un incidente, los retrasos en la búsqueda de credenciales o autorización pueden extender el tiempo de inactividad, incluso si el soporte cuenta con personal.
La concentración más peligrosa es una cuenta que controla el registro de dominios, el DNS y la infraestructura con una sola credencial y una sola ruta de pago. Un diseño más seguro separa los roles, protege las acciones de alto impacto, mantiene un registro fuera de línea de los identificadores de recursos y tiene un segundo método para comunicarse. Esta es una higiene operativa ordinaria, pero la amplitud del catálogo de REG.RU la hace especialmente consecuente.
La portabilidad existe, pero la migración tiene un costo y una secuencia
REG.RU proporciona varias interfaces abiertas o familiares que reducen la dependencia de un proveedor. Las máquinas virtuales pueden ejecutar sistemas Linux y Windows comunes. Los servidores dedicados exponen IPMI o KVM y permiten imágenes de sistema operativo del cliente. El almacenamiento de objetos utiliza una interfaz compatible con S3. Se admite Terraform para algunos aprovisionamientos en la nube. Los datos se pueden copiar con herramientas estándar, y el DNS sigue basado en registros portables.
Laguía de migración de cPanel a ispmanagerdel proveedor es valiosa porque muestra la secuencia real: identificar archivos y bases de datos, hacer un archivo y un volcado de base de datos, registrar la versión del software, crear el entorno de destino, cargar archivos, importar datos, probar antes de los cambios de DNS, actualizar registros y mover el correo por separado. Esta es una migración hacia REG.RU, pero los mismos componentes deben entenderse para una migración hacia afuera.
La portabilidad no es, por tanto, una característica de sí o no. Un sitio estático pequeño se puede copiar rápidamente. Una base de datos grande necesita replicación o un intervalo de mantenimiento. Una base de datos gestionada puede exponer herramientas de motor estándar pero aún así requerir versiones y extensiones compatibles. Un almacén de objetos a escala de terabytes puede usar una API estándar mientras tarda un tiempo significativo en transferirse a través de la conexión disponible. Las direcciones IP públicas generalmente no viajan a otro proveedor, por lo que el DNS, los certificados y las listas de permitidos deben cambiar.
La combinación de servicios de REG.RU puede ayudar a un movimiento por etapas. Un cliente puede construir un nuevo servidor, restaurar datos, probarlo a través de una entrada de archivo hosts local o un nombre temporal, y cambiar el registro público solo cuando esté listo. La guía de migración recomienda explícitamente las pruebas previas al cambio. Sin embargo, usar el DNS de REG.RU tanto para el servicio antiguo como para el nuevo significa que el cambio todavía depende de la misma superficie de control.
Las migraciones críticas pueden justificar un acuerdo de DNS secundario independiente y una reducción anticipada de los tiempos de vida de los registros.
Las copias de seguridad también deben ser exportables antes de una emergencia. Una copia de seguridad alojada por el proveedor que solo puede restaurarse en el mismo servicio es útil para errores locales, pero débil para la salida del proveedor. La compatibilidad con S3 y las copias de archivos estándar mejoran las opciones, siempre que las credenciales y el ancho de banda permanezcan disponibles. Los clientes deben cronometrar una exportación representativa y registrar dependencias como claves de cifrado, usuarios de bases de datos, certificados y archivos de licencia.
La economía de la salida pertenece a la arquitectura original. La capacidad barata y rápidamente disponible puede seguir siendo costosa de abandonar si el volumen de datos, las características propietarias gestionadas o las dependencias de direcciones se acumulan. REG.RU ofrece suficientes interfaces estándar para que la portabilidad sea plausible. La evidencia pública no cuantifica el rendimiento de exportación, los compromisos de soporte para la salida o cuánto tiempo permanecen accesibles los datos después de la terminación comercial, por lo que esos términos necesitan confirmación directa.
La localidad de los datos es clara a nivel de país y menos clara dentro de los productos
REG.RU sitúa consistentemente la infraestructura anunciada en Rusia. La guía de alojamiento nombra ciudades y direcciones rusas. El catálogo de la nube dice que sus instalaciones Tier III están en Moscú, San Petersburgo y la región de Samara. La página de S3 hace la misma afirmación a nivel de país. Para las organizaciones obligadas a mantener los datos personales de los ciudadanos rusos en Rusia, esa es una base relevante.
El proveedor también ofrece servidores en la nube diseñados para los requisitos de la Ley Federal 152-FZ. Sudocumentación de servidores reguladosidentifica una ubicación en Moscú y describe la responsabilidad del proveedor por la infraestructura, una instalación certificada y protecciones técnicas. Esto es más específico que una promesa genérica de «nube local». Sin embargo, no transfiere toda la responsabilidad de cumplimiento al proveedor; el cliente sigue siendo el operador de datos personales y debe configurar y gobernar su sistema en consecuencia.
La localidad tiene varios niveles. La localidad de país pregunta si los datos primarios permanecen en Rusia. La localidad de instalación pregunta en qué ciudad y edificio se almacenan. La localidad de replicación pregunta a dónde van las copias y las copias de seguridad. La localidad administrativa pregunta quién puede acceder a ellos. La localidad de soporte pregunta dónde operan el personal y la gestión remota. Las páginas públicas responden a la primera pregunta más claramente que a las otras.
La geografía del producto también puede cambiar. La página de marketing de S3 se refiere a Moscú, San Petersburgo y Samara, mientras que características específicas de la nube pueden estar disponibles solo en una o dos regiones. El anuncio de DBaaS describe dos ubicaciones en Moscú, y el lanzamiento de Blackwell está vinculado a Moscú-3. Un cliente no puede inferir las opciones de colocación de un producto a partir del mapa corporativo completo. La interfaz de pedido y el anexo del contrato deben identificar la región elegida.
La concentración en un país es tanto un beneficio como un riesgo. Apoya los requisitos de residencia de datos y la latencia local para los usuarios rusos. También significa que la finca anunciada está expuesta a un único entorno legal, de mercado eléctrico y de conectividad nacional. Los clientes que atienden a usuarios en otros lugares deben probar las rutas internacionales y considerar si una copia independiente fuera del proveedor está legalmente permitida y es operativamente deseable. La respuesta depende de los datos y las obligaciones del cliente, no de una etiqueta de nube genérica.
Cómo se ve el fallo para diferentes clientes
Una pequeña empresa que utiliza REG.RU para un dominio, alojamiento compartido y correo está más expuesta a fallos de cuenta, DNS y plataforma compartida. Las copias de seguridad diarias pueden restaurar el sitio, pero los cambios realizados después de la última copia pueden perderse. Si la misma cuenta controla el dominio y el alojamiento, un problema de acceso puede bloquear tanto el diagnóstico como la redirección. La mejor mejora suele ser modesta: recuperación de cuenta independiente, una copia externa de los datos del sitio y del correo, y una forma documentada de mover el DNS.
Una empresa de software en máquinas virtuales en la nube se enfrenta a fallos de clúster, almacenamiento y región. Las IP flotantes y las redes privadas pueden ayudar dentro de una ubicación. Las copias de seguridad e instantáneas pueden restaurar instancias. Ninguno de estos sustituye a una segunda ubicación en ejecución cuando los objetivos de tiempo de inactividad son cortos. La empresa necesita replicación a nivel de aplicación, monitoreo externo y suficiente capacidad de reserva en la ubicación de destino.
Un cliente en bare metal asume más responsabilidad operativa. IPMI puede restaurar el acceso a la consola, y REG.RU puede reemplazar el hardware defectuoso, pero la aplicación puede permanecer vinculada a discos locales y a una máquina específica. Los discos reflejados protegen contra algunos fallos de dispositivo, no contra la pérdida del sitio o la corrupción. Un segundo servidor y una copia de datos fuera de la máquina son las medidas de resiliencia mínimas creíbles para una carga de trabajo crítica.
Un cliente de datos regulados tiene otra restricción: el objetivo de recuperación debe satisfacer los mismos requisitos de residencia y seguridad que la producción. Una copia de seguridad en una ubicación no especificada o una nube alternativa elegida apresuradamente puede ser inutilizable desde una perspectiva de cumplimiento. Los múltiples sitios rusos de REG.RU pueden ser útiles, pero la ubicación exacta y los controles necesitan confirmación por escrito.
Los clientes de dominio se ven afectados incluso cuando no compran alojamiento. La red activa AS197695 y las direcciones DNS autoritativas muestran que los servicios de nombres también tienen dependencias físicas y de enrutamiento. La acreditación del registrador y el depósito de datos protegen aspectos de la relación de registro, pero no hacen que la arquitectura DNS elegida por el cliente esté continuamente disponible. El registro, el DNS autoritativo y el alojamiento de aplicaciones son funciones separadas y deben evaluarse por separado.
En cada caso, la ruta de fallo más importante es una cadena. La pérdida de energía puede eliminar un rack; un fallo de ruta puede aislar una máquina sana; un fallo de almacenamiento puede dejar la computación en ejecución sin datos; un problema de cuenta puede impedir un cambio de tráfico; un pago vencido puede interrumpir un servicio sano; y una escalada de soporte lenta puede prolongar cada uno de ellos. El cliente experimenta la dependencia no resuelta más larga, no el componente más fuerte del portafolio.
El veredicto operativo: red real, transparencia parcial, resiliencia construida por el cliente
REG.RU supera el umbral para un proveedor de infraestructura operativo. La empresa registradora nombrada está actualizada en el registro de IANA, posee recursos de red de RIPE NCC y origina una gran superficie de enrutamiento activo a través de AS197695. La finca de servicios de marca contiene inventario bare-metal pedible, máquinas virtuales, almacenamiento y productos gestionados. La documentación expone direcciones físicas, métodos de gestión remota, comportamiento de las copias de seguridad y un objetivo de disponibilidad contractual. Esas son señales operativas sustantivas.
La evidencia es menos completa en los límites. El material público mezcla la marca del grupo y múltiples empresas legales. Las cifras del portafolio combinan instalaciones que parecen tener diferentes propietarios y roles. Las calificaciones de las instalaciones y los megavatios agregados no revelan la capacidad ocupada o libre de REG.RU. La vista de enrutamiento global no prueba la diversidad de circuitos en cada sitio. Las páginas de productos no proporcionan un mapa común de dominios de replicación y recuperación. No se disponía de un historial de incidentes público y estructurado para compararlo con el SLA.
Esa combinación no merece ni descarte ni confianza incondicional. La evidencia de red es sólida. La evidencia del producto es sólida para la disponibilidad actual de los servicios. La evidencia de propiedad de las instalaciones y redundancia producto por producto es media a débil. La evidencia de interrupciones históricas es débil. La respuesta correcta del cliente es reducir cada afirmación al servicio solicitado.
Antes de colocar una carga de trabajo crítica, un comprador debe obtener respuestas por escrito a un breve conjunto de preguntas operativas: la empresa contratante; la instalación seleccionada y su operador; los dominios de fallo de computación, almacenamiento y red; la ubicación e inmutabilidad de las copias de seguridad; los compromisos de punto de recuperación y tiempo de recuperación; el tratamiento del trabajo planificado; los términos de reemplazo de hardware; la escalada de soporte; las reglas de saldo y suspensión; y la ruta de exportación probada.
Para diseños multisitio, el comprador también debe confirmar si la capacidad está reservada en la ubicación alternativa y si el DNS, la identidad y la gestión siguen siendo utilizables cuando falla la ubicación principal.
La propuesta de valor de REG.RU es la reducción de la fricción. Un cliente puede comenzar con un nombre y agregar formas cada vez más físicas de infraestructura sin salir del mismo entorno comercial. La realidad subyacente se mueve en la dirección opuesta: cada servicio añadido introduce servidores, discos, enlaces de red, contratos de instalaciones, equipos de soporte y decisiones de recuperación. La interfaz de nube hace que esas dependencias sean más fáciles de comprar. No las hace desaparecer.