Resumo

  • O REG.RU expõe uma superfície operacional real: o registro de identificadores de registrador da IANA o credencia, o roteamento observado pelo RIPE mostra centenas de anúncios IPv4 e IPv6 atrás do AS197695, e o catálogo da marca oferece hospedagem compartilhada, máquinas virtuais, servidores bare metal, armazenamento, bancos de dados, Kubernetes e colocation. Isso vai além de uma mera vitrine, mas não prova que a empresa registradora nomeada possua cada instalação ou opere cada camada de produto.
  • Resiliência não é herdada do tamanho do portfólio. O REG.RU publica vários locais na Rússia, ferramentas de backup e migração, endereços flutuantes, redes privadas e um objetivo de serviço em nuvem de 99,95%, mas são a escolha do site, a separação dos backups, as exclusões de manutenção, a substituição de hardware, a escalação de suporte e o design de aplicação entre sites que determinam a recuperação efetiva para os clientes.
  • A conclusão operacional mais clara é, portanto, condicional. A rede e o inventário ativo de produtos justificam tratar o REG.RU como um provedor de infraestrutura operacional. A propriedade das instalações, a capacidade por serviço, a replicação inter-regional e o histórico de desempenho em incidentes são apenas parcialmente visíveis. Portanto, um cliente deve verificar a entidade contratante exata, o local, o objetivo de recuperação, o design de roteamento e o procedimento de exportação para cada serviço antes de considerar uma implantação REG.RU como redundante.

Uma conta de registrador se tornou uma superfície de controle de infraestrutura

O REG.RU ainda é reconhecível como um registrador de nomes de domínio. Oregistro de identificadores de registrador da IANAlista "Registrar of Domain Names REG.RU LLC" como credenciado sob o identificador 1606 e encaminha para seu serviço RDAP. Seus própriosdetalhes corporativosidentificam a sociedade limitada russa cujo nome em inglês consta na entrada do diretório, com o CNPJ 7733568767 e um endereço legal em Moscou. Esses fatos estabelecem o assunto deste perfil de forma mais segura do que apenas a marca.

No entanto, a proposta ao cliente vai muito além do registro. Apágina corporativado REG.RU descreve uma gama de nuvem baseada em OpenStack e VMware, servidores dedicados e colocation. Ocatálogo de serviços REG.Cloudatual lista máquinas virtuais, servidores bare metal físicos, bancos de dados gerenciados, Kubernetes, armazenamento compatível com S3, ambientes privados OpenStack e VMware, serviços de rede e espaço em rack. Uma pequena organização pode assim comprar o nome, o DNS autoritativo, a hospedagem do site e a capacidade do servidor através das superfícies REG.RU vinculadas. Um cliente maior pode alugar equipamento físico ou combiná-lo com recursos virtuais e serviços gerenciados.

Esse agrupamento tem consequências operacionais. Uma conta de registrador não é mais apenas o local onde uma data de renovação é armazenada. Pode se tornar o local onde se encontram os nomes públicos, registros de endereços, pedidos de computação, políticas de backup, tickets de suporte e saldos de pagamento. A conveniência reduz o custo de colocar um serviço online. Também concentra a autoridade administrativa. Uma perda de acesso, um erro de pagamento, uma alteração incorreta de DNS ou um incidente de segurança no nível da conta pode afetar várias camadas, mesmo quando as máquinas subjacentes permanecem saudáveis.

Aqui está a primeira distinção que os clientes devem preservar: a integração comercial não é redundância técnica. Comprar um domínio e um servidor da mesma família pode simplificar a configuração e o suporte. Isso não cria um segundo provedor de DNS autoritativo, uma segunda nuvem, uma cópia independente dos dados ou um identificador administrativo separado. Um design de recuperação deve criar deliberadamente essas separações.

O inverso também é importante. O amplo catálogo não deve ser considerado uma mera lista de etiquetas revendidas. O REG.RU possui recursos de rede observáveis, publica locais de instalações específicos, anuncia configurações físicas em estoque e documenta seus próprios controles operacionais. Trata-se de identificar onde essas evidências são sólidas e onde uma declaração no nível da marca deve carregar mais peso do que pode sustentar.

Uma única marca não significa um único operador nem um único modelo de propriedade

A fronteira jurídica é particularmente importante aqui, pois as superfícies públicas do REG.RU usam um único nome para vários tipos de serviços. Asregras do siteidentificam "REG.RU Domains Hosting" LLC como administradora das propriedades web e designam "Domain names registrar REG.RU" Ltda. como um parceiro que fornece serviços no âmbito de seus próprios contratos com clientes. Por sua vez, asregras de suportedo registrador descrevem o suporte fornecido pela empresa registradora para registro, hospedagem e outros serviços. Ascondições promocionais recentes para GPU em nuvemtambém designaram a empresa registradora como organizadora. Os documentos mostram uma estreita integração operacional, mas não permitem tratar as duas pessoas jurídicas como intercambiáveis.

O mesmo cuidado se aplica às edificações. O REG.RU indica usar uma mistura de capacidades de datacenters próprios e conectados. Suas páginas de produto nomeiam instalações comerciais, bem como sites sob a marca REG.RU. Apágina VPSidentifica locais incluindo KIAEHOUSE no local do Instituto Kurchatov, SafeData, Medvedkovo-2, DataPro, uma instalação na rodovia de Varsóvia, o Data Centre No. 1 em São Petersburgo e o Vale de Zhiguli em Togliatti. Um anúncio de junho de 2026 indica que uma terceira região de nuvem em Moscou foi inaugurada na instalação Magistralny-1 da Datahouse. Esses nomes indicam locações, acordos de hospedagem ou outras dependências de instalações, além de qualquer edifício que o grupo possa possuir diretamente.

Isso não é uma fraqueza específica do REG.RU. A maioria dos serviços de infraestrutura são atividades multicamadas. Um provedor pode possuir servidores, alugar gaiolas ou racks, contratar fornecimento de energia, comprar trânsito e usar instalações de terceiros, enquanto ainda opera o serviço ao cliente. Mas cada camada altera o limite do incidente. Um operador de instalação controla a energia e o resfriamento. Um operador de telecomunicações controla um circuito externo. O REG.RU controla sua frota de servidores, virtualização, configuração de serviço e resposta ao cliente em vários graus.

O cliente controla a aplicação, as credenciais, o posicionamento dos dados e grande parte do plano de recuperação.

A questão prática de suprimento é, portanto, mais precisa do que "O REG.RU possui seus datacenters?" É: para este serviço solicitado neste local escolhido, quem possui o servidor, quem fornece manutenção remota, quem controla a borda da rede, quem mantém o hipervisor e o armazenamento, e qual empresa deve a reparação contratual? Uma máquina bare metal anunciada como fisicamente disponível é um arranjo diferente de uma máquina virtual em um cluster compartilhado, e ambos diferem de um servidor de propriedade do cliente colocado em colocation.

A documentação do REG.RU é útil porque revela partes dessa divisão, mas não publica uma matriz completa de propriedade e responsabilidade para cada produto e local. Até que um contrato ou especificação técnica forneça essa matriz, as declarações de propriedade no nível do portfólio devem ser consideradas não verificadas. O serviço pode ser real e funcionar sem que cada rack seja um ativo da entidade listada.

O parque físico é russo, distribuído e descrito de forma desigual

Oguia de localização de hospedagemdo REG.RU fornece cinco endereços principais: três em Moscou, um em São Petersburgo e um em Togliatti. Ele afirma que a hospedagem compartilhada está localizada no local da Praça Kurchatov em Moscou. Também especifica que as instalações têm energia de backup, resfriamento e segurança em vários níveis. Esta é uma evidência útil específica do serviço, pois vincula a hospedagem compartilhada a um local nomeado em vez de apenas dizer "Rússia".

O catálogo mais amplo do provedor é mais extenso. A página VPS fornece nomes de instalações, números de potência, números de racks e tipos de serviço. Ela descreve o Data Centre No. 1 na Rua Predportovaya em São Petersburgo como um site de design Tier III com 2 MW e 260 racks, e o Vale de Zhiguli na região de Samara como certificado pelos padrões Uptime Institute Tier Design e Tier Facility. A página também inclui sites em Moscou com diferentes combinações de bare metal e nuvem pública. A verificação independente é possível para pelo menos uma dessas dependências: apágina de contato própria do Data Centre No. 1fornece o mesmo endereço na Rua Predportovaya, confirmando que o local do REG.RU em São Petersburgo corresponde a uma instalação operada separadamente.

A declaração mais recente sobre o portfólio do REG.RU é mais substancial. Ao anunciar as instâncias NVIDIA Blackwell em junho de 2026, a empresa afirmou que sua nuvem de marca contava com dez datacenters, 85,5 MW de capacidade agregada e 300 Gbit/s de throughput em canais ópticos. Ela descreveu a nova região Moscou-3 naDatahouse Magistralny-1como um contorno de infraestrutura independente com seu próprio cluster OpenStack e hipervisores. O anúncio atribui 1.100 racks, até 15 kW por rack e um objetivo de disponibilidade de 99,99% para este site.

Esses números atestam a escala que o REG.RU comercializa, não uma medida direta da capacidade disponível para um cliente específico. A potência total de uma instalação inclui o espaço usado por outros locatários. Um número de racks não diz quantos racks o REG.RU ocupa. Uma densidade máxima por rack não mostra a carga média implantada. O throughput em canais ópticos não é o mesmo que trânsito de cliente não congestionado em cada local. Dez sites conectados não implicam que cada serviço possa operar em todos os dez, nem que os dados sejam automaticamente replicados entre eles.

As evidências mais úteis para a decisão aparecem no processo de pedido. Oinventário de servidores dedicadosdo REG.RU permite que os clientes filtrem máquinas físicas por vários locais nomeados em Moscou, e as fichas individuais identificam um processador, memória, configuração de disco, opção de gerenciamento remoto, porta de rede e local. Trata-se de capacidade instalada ou encomendável, embora ainda seja um inventário mutável, e não um total de frota auditado. A documentação de pedido de nuvem similarmente instrui os clientes a escolher uma região de implantação. Esses locais selecionáveis importam mais do que um grande número agregado de portfólio, pois definem onde um cliente pode realmente colocar uma carga de trabalho hoje.

O resultado é um mapa multicamadas. A hospedagem compartilhada tem um endereço principal em Moscou divulgado. O bare metal aparece em vários locais nomeados. Os serviços de nuvem gerenciada expõem um conjunto menor de regiões ou zonas que evolui conforme o produto. São Petersburgo e Togliatti ampliam a escolha geográfica, enquanto os novos sites em Moscou expandem a capacidade metropolitana. Nada disso prova por si só uma redundância síncrona entre cidades, edifícios ou clusters.

Capacidade instalada não é capacidade utilizável

O marketing de nuvem converte máquinas físicas em unidades simples: vCPU, memória e armazenamento. Essa conversão esconde as decisões de utilização e manutenção que determinam se uma unidade solicitada está disponível quando a demanda aumenta. O catálogo do REG.RU mostra uma gama substancial, mas a distinção entre capacidade instalada e capacidade utilizável permanece essencial.

Para bare metal, a capacidade utilizável é visível na forma de configurações em estoque. Apágina de servidores dedicadosoferece opções AMD EPYC, Intel Xeon, NVMe, discos rígidos e GPU e indica que o hardware está em estoque. As ofertas individuais mostram uma máquina específica e especificam que a provisionamento começa a partir de 45 minutos para muitos servidores. Isso é mais sólido do que uma página de produto conceitual: sugere um inventário ativo e um mecanismo de pedido. No entanto, o estoque muda, e uma peça de reposição não é garantida simplesmente porque uma máquina similar aparece no catálogo. Clientes com objetivos de restauração rigorosos precisam saber se discos, fontes de alimentação, placas-mãe e aceleradores com falha têm peças de reposição no local na instalação selecionada e quais substituições são permitidas.

Para máquinas virtuais, a capacidade utilizável depende da margem do cluster, desempenho de armazenamento, limites do agendador e disponibilidade de rede. Oguia de pedido de servidores em nuvemdo REG.RU mostra configurações padrão, de alta frequência e para dados regulamentados, bem como imagens de GPU. Um anúncio de hardware de junho de 2026 vai mais longe, nomeando sistemas Supermicro, processadores AMD EPYC 9554 e aceleradores RTX 6000 Pro Blackwell Server Edition para a região Moscou-3. Essa especificidade apoia a existência de um novo parque de hardware real. Ela não divulga, no entanto, o overbooking, a margem livre ou o número de hosts instalados.

O armazenamento apresenta sua própria lacuna entre uma alegação de produto e a capacidade recuperável. Apágina de armazenamento compatível com S3indica que os objetos são mantidos em três cópias e que o provedor é responsável pela infraestrutura, replicação, escalabilidade e disponibilidade. Três cópias podem proteger contra certas falhas de dispositivo ou nó. No entanto, a página não afirma explicitamente que essas cópias estão em três edifícios ou zonas de falha independentes. Três réplicas no mesmo local não constituem uma cópia de recuperação de desastre regional. Um cliente deve perguntar sobre a política de posicionamento, os limites do domínio de falha, o comportamento de versionamento e o processo de recuperação, em vez de assumir que "três cópias" significa "três regiões".

Mesmo a capacidade elétrica de uma instalação é condicional. Um edifício de 36 MW pode ter infraestrutura robusta, enquanto a área alugada pelo provedor, a energia contratada e as portas de rede instaladas são muito menores. Um limite de design de 15 kW por rack não significa que cada rack tenha essa carga provisionada. A unidade útil para um cliente não é a potência nominal do campus; é o contrato de capacidade vinculado a um serviço escolhido e a capacidade do provedor de fornecer mais em caso de falha em outro lugar.

É por isso que os testes de failover devem incluir escassez. Se um cluster em Moscou falhar, o segundo local pode aceitar a carga de trabalho transferida, e não apenas executar uma máquina de backup pequena? Se um host GPU especializado falhar, um acelerador equivalente é mantido em reserva? Se um pool de armazenamento ficar indisponível, o pool sobrevivente pode atender tanto o tráfego normal quanto o tráfego de recuperação? Os documentos públicos não respondem a essas perguntas; portanto, elas pertencem à diligência técnica.

AS197695 é o sinal independente de operação mais claro

O registro de rede fornece a evidência mais sólida de que a entidade listada opera a infraestrutura, em vez de apenas revender o serviço de outra empresa. O registro RIPE e as observações públicas de roteamento associam AS197695, AS-REGRU, a "Domain names registrar REG.RU", Ltd. Uminstantâneo do BGP.Toolsdescreve a rede como ativa e orientada a conteúdo, e mostra centenas de prefixos IPv4 emitidos, bem como anúncios IPv6. Umaresposta RIPEstat sobre prefixos anunciadosobservou 477 anúncios em 12 de julho de 2026: 453 prefixos IPv4 e 24 IPv6, excluindo rotas de visibilidade muito baixa de coletor.

A extensão dessa superfície é significativa. É consistente com um provedor de hospedagem atendendo a muitos blocos de endereços e serviços de clientes. Por exemplo, o prefixo176.99.13.0/24é emitido pelo AS197695 e contém endereços usados pelos servidores de nomes do REG.RU. O domínio web principal da empresa também se resolve no mesmo sistema autônomo, de acordo com avisualização DNS do Hurricane Electric. Essas observações vinculam as superfícies corporativa, DNS e de hospedagem a um domínio de roteamento operado.

Aresposta de vizinhos ASN do RIPEmostrou muitos números AS adjacentes nos caminhos observados na mesma data, incluindo TransTeleCom, EDINAYA SET, Hurricane Electric, OBIT, RETN e ER-Telecom, entre outros. Isso indica conectividade externa variada na visão de roteamento global. Isso não prova que cada instalação do REG.RU tenha acessos fisicamente diversificados, que cada rede nomeada seja um upstream pago, ou que dois circuitos não compartilhem o mesmo conduíte. A classificação de caminho esquerda/direita do RIPE é uma observação sobre a posição no caminho AS, não um rótulo de relação comercial.

Duas ressalvas também se aplicam. Primeiro, AS43146 está registrado para a mesma organização, mas oBGP.Tools o sinalizacomo ausente da tabela global atual. Um sistema autônomo registrado não constitui prova de serviço ativo; AS197695 é o sinal operacional relevante. Segundo, uma consulta aoponto de acesso de rede PeeringDBnão retornou nenhum registro de rede público para AS197695. A participação no PeeringDB é voluntária, portanto a ausência não prova conectividade ruim. Isso significa que o registro público não contém uma matriz de instalações e trocas mantida pelo provedor, o que poderia ajudar a verificar onde o REG.RU faz peering.

A escala da rede também não elimina a concentração. Centenas de prefixos podem atravessar um mesmo sistema autônomo e compartilhar uma política de roteamento, sistemas de mitigação ou pessoal operacional. Clientes que usam o REG.RU para DNS autoritativo, hospedagem e origem de aplicação podem permanecer dependentes da mesma conta e rede, mesmo quando os endereços IP diferem. Uma verdadeira diversidade de rotas exige testes de caminho a partir das redes de usuários relevantes e a confirmação dos circuitos físicos em cada local selecionado.

A promessa de nível de serviço abre espaço para janelas de manutenção

O acordo de nível de serviço (SLA) de nuvem do REG.RU é particularmente revelador da diferença entre um objetivo de disponibilidade e um serviço ininterrupto. Oacordo em vigor a partir de 14 de abril de 2026estabelece objetivos mensais de 99,95% para serviços de infraestrutura, rede e data center, como energia, aquecimento, ventilação e resfriamento. Em um mês de 730 horas, 0,05% corresponde a cerca de 21,9 minutos, antes de considerar as exclusões.

As exclusões são importantes. O acordo permite interrupções para trabalhos planejados totalizando até 48 horas por ano e não mais que seis horas por mês, com aviso prévio de pelo menos 24 horas. Trabalhos urgentes podem durar o tempo necessário para eliminar ou prevenir uma emergência, com aviso imediato antes da interrupção. O acordo especifica que essas interrupções de manutenção não contam como indisponibilidade normal do serviço.

Também exclui várias condições atribuíveis ao cliente ou externas e prevê tratamento na forma de créditos de serviço para indisponibilidades elegíveis, em vez de indenização por perdas comerciais mais amplas do cliente.

Isso não torna o objetivo sem sentido. Um objetivo escrito cobrindo computação, rede e sistemas de instalação constitui uma referência útil. Ele identifica um recurso e obriga o provedor a medir a disponibilidade. Mas isso altera a interpretação técnica. Um cliente não pode converter 99,95% em uma promessa de que nenhuma janela de manutenção de seis horas ocorrerá. Uma aplicação que não pode tolerar a janela permitida precisa de um segundo local de serviço e um método testado para mover o tráfego.

As páginas de produto às vezes usam números diferentes. O guia de localização de hospedagem compartilhada anuncia 99,9% de disponibilidade, enquanto o anúncio Moscou-3 atribui 99,99% à instalação. Essas porcentagens se referem a escopos diferentes e não devem ser misturadas. Um design ou objetivo de instalação não é o mesmo que disponibilidade de aplicação. Um servidor pode permanecer ligado enquanto o armazenamento, um hipervisor, uma rota, o DNS ou o software do cliente falham. Inversamente, uma plataforma pode manter uma aplicação online durante uma falha de host se a carga de trabalho estiver adequadamente distribuída.

A transparência sobre incidentes públicos é escassa. Nenhum host de status público claramente identificável para o REG.RU foi encontrado durante esta revisão, e o arquivo de notícias da empresa não constitui um histórico estruturado de incidentes. Monitores de terceiros fornecem apenas sinais fracos. Por exemplo, apágina de tempo de atividade do Hosters.rurelatou verificações do site público do REG.RU, e não do parque de nuvem do cliente, e oWho.ismede igualmente o ponto de acesso corporativo. Uma sonda com falha pode refletir filtragem, um problema de redirecionamento ou o próprio site; uma sonda bem-sucedida não diz nada sobre uma VM de cliente em outra região. Essas observações não podem validar nem refutar o desempenho do SLA de nuvem.

Um padrão mais forte de transparência incluiria status por serviço, rótulos de região, horários de início e restauração de incidentes, componentes afetados e explicações pós-incidente. Na ausência disso, os clientes devem solicitar relatórios históricos de disponibilidade e perguntar como trabalhos planejados, trabalhos urgentes e degradação parcial são contabilizados nas medições de serviço.

A falha de hardware traz a abstração da nuvem de volta ao inventário e à mão de obra

Uma máquina virtual parece independente de um servidor específico até que um componente físico falhe. Um serviço bare metal nunca esconde essa dependência. A documentação do REG.RU mostra tanto os benefícios quanto os limites de seu modelo de operação de hardware.

O catálogo dedicado inclui controle remoto, proteção DDoS, uma porta de rede, instalação do sistema operacional e "substituição operacional" de falhas. Seuguia IPMIexplica que alguns servidores expõem gerenciamento fora de banda independente e que o KVM está disponível onde o IPMI não está. Um cliente pode usar esse canal para inspecionar problemas de inicialização, reiniciar uma máquina ou instalar um sistema operacional mesmo quando o sistema operacional principal está indisponível. Isso reduz a dependência do suporte para certas falhas.

Isso não substitui a intervenção física. Uma placa-mãe, um dispositivo de armazenamento, uma fonte de alimentação ou uma interface de rede com falha ainda requerem uma pessoa e uma peça de reposição. A "substituição operacional" não é um objetivo de tempo de substituição publicado. O provedor pode restaurar o serviço substituindo um componente, movendo discos, fornecendo um servidor diferente ou reconstruindo o ambiente operacional, e essas opções têm consequências diferentes para a integridade dos dados e o tempo de inatividade.

A geração do hardware também afeta a recuperação. O catálogo contém tanto sistemas EPYC e GPU recentes quanto configurações Xeon mais antigas. Essa variedade é economicamente racional: os clientes trocam desempenho e antiguidade por preço. No entanto, uma política de substituição deve definir se o cliente recebe peças idênticas, desempenho equivalente ou qualquer substituto disponível. Interfaces de memória e disco antigas podem ser mais difíceis de substituir rapidamente do que o armazenamento atual. GPUs especializados criam uma restrição de inventário ainda mais rigorosa.

Para nuvem virtual, o provedor pode mover ou recriar um convidado em outro host apenas se o cluster, o armazenamento e o design de rede permitirem e se existir capacidade de reserva. O REG.RU descreve sua nuvem como tolerante a falhas, mas as páginas de produto públicas não divulgam a política de evacuação de hosts nem os domínios de falha de cada serviço. A documentação do Kubernetes gerenciado indica que um cluster tolerante a falhas pode fazer failover para um nó mestre de backup, o que protege esse componente de controle.

Isso não torna automaticamente as cargas de trabalho do cliente multissite nem garante que dados com estado sobrevivam à perda de uma instalação.

O design da aplicação do cliente permanece, portanto, determinante. Serviços sem estado podem ser recriados a partir de imagens e configuração mais facilmente do que um banco de dados mutável único. Um banco de dados bare metal com discos locais precisa de réplicas ou backups recuperáveis em outro lugar. Uma máquina virtual com um snapshot no mesmo domínio de armazenamento ainda pode estar exposta a uma falha do domínio de armazenamento. A marca pode fornecer componentes úteis, mas nenhuma seleção de catálogo transforma uma única instância em uma arquitetura de recuperação.

Backups são produtos, não prova de recuperabilidade

O REG.RU oferece vários mecanismos de backup, e as diferenças entre eles são importantes. A hospedagem compartilhada recebe backups automáticos diários, de acordo com oguia de backup de hospedagem. O guia afirma que as cópias são mantidas por 30 dias, são feitas durante a noite e ficam disponíveis no dia seguinte. Isso é adequado para muitos sites, mas implica uma lacuna de ponto de recuperação potencialmente longa para dados que mudam com frequência.

O backup de servidor em nuvem é ativado e faturado separadamente. Oguia de backup em nuvemafirma que a política padrão mantém três cópias, incluindo uma semanal e as duas versões mais recentes, com criação diária. Os clientes podem modificar as políticas de retenção e restaurar um servidor a partir de uma cópia salva. A restauração pode exigir a atualização dos registros de domínio quando um endereço muda. Este último detalhe é operacionalmente importante: a recuperação da computação e a recuperação do tráfego podem ser etapas separadas.

Servidores dedicados oferecem mais opções. Apágina de produto de backupdo REG.RU descreve cópias diárias no nível de arquivo para Linux, opções Veeam, armazenamento FTP, S3 e designs privados. Ela afirma que os backups são armazenados separadamente do servidor, e sua descrição Linux padrão mantém os últimos sete dias. Designs mais elaborados podem colocar cópias recentes em disco e arquivos mais longos em fita. "Separadamente do servidor", no entanto, não significa necessariamente "em um edifício separado" ou "fora do provedor". Os clientes precisam da localização exata e da separação administrativa.

O serviço S3 adiciona outra opção e suporta uma interface aberta. Um ponto de extremidade compatível com S3 pode tornar a integração da aplicação e a transferência de dados mais fáceis do que um produto de armazenamento totalmente proprietário. O REG.RU afirma que o serviço mantém três réplicas e permite o gerenciamento via API S3 e Terraform. Isso favorece a portabilidade no nível do objeto. Isso não prova que um grande conjunto de dados possa ser exportado dentro do prazo necessário, que o versionamento esteja ativado ou que as réplicas internas do provedor protejam contra exclusão de conta ou chaves de acesso comprometidas.

Um teste de recuperação confiável tem quatro partes. A cópia deve conter os dados necessários. Deve estar isolada da falha que a originou. O cliente deve ser capaz de se autenticar e recuperá-la durante um incidente. O sistema restaurado deve passar por uma verificação de integridade no nível da aplicação. As mensagens de fim de backup estabelecem apenas a primeira parte, e de forma imperfeita.

Isso é particularmente importante quando o domínio, o DNS, a computação e o backup usam uma única conta. Um atacante ou administrador com direitos amplos pode ser capaz de modificar registros, excluir máquinas e apagar cópias. Os clientes devem separar credenciais, usar cópias independentes para dados críticos, proteger a exclusão com controles de retenção quando disponíveis e praticar a restauração em outro ambiente. A presença de um botão de backup é valiosa, mas uma restauração cronometrada é a prova que conta.

A escolha multissite não é um serviço multissite automático

O REG.RU adicionou uma escolha significativa de localização. Um anúncio de 2023 descrevia umsite de nuvem em São Petersburgoao lado de três datacenters em Moscou. Uma atualização operacional de 2024 indicava que a empresa havia conectado um novo site em Togliatti enquanto expandia os produtos de nuvem. Em março de 2026, o REG.Cloud anunciou umsegundo local em Moscou para bancos de dados gerenciados, permitindo que os clientes implantassem DBaaS em Moscou-1 ou Moscou-2 e restaurassem em um novo cluster. Em junho, Moscou-3 adicionou um contorno OpenStack distinto.

Nem sempre é o mesmo tipo de redundância. Uma segunda instalação em Moscou pode reduzir a exposição a uma falha de edifício, manutenção local ou incidente de cluster. Ela permanece exposta a riscos metropolitanos, controles de rede regionais e alguns funcionários ou sistemas de controle compartilhados. Uma implantação em Togliatti ou São Petersburgo aumenta a separação geográfica, mas pode oferecer um conjunto de produtos, pool de capacidade ou perfil de latência diferentes. Os documentos públicos não afirmam que cada serviço pode fazer failover automaticamente para todos esses sites.

A atualização DBaaS é um bom exemplo de progresso preciso, mas limitado. Ela indica que os clientes podem selecionar um dos dois locais em Moscou, restaurar um backup em um novo cluster sem parar o original e usar a recuperação point-in-time para PostgreSQL. Essas capacidades reduzem o custo de testar a recuperação e de mudar para uma instância limpa. O anúncio afirma que um segundo local melhora o balanceamento de carga e o design resiliente; ele não diz que os bancos de dados são replicados de forma síncrona entre os dois locais por padrão.

Os endereços públicos flutuantes também têm escopo limitado. Oguia de IPs flutuantesdo REG.RU afirma que um endereço pode ser anexado a um dispositivo dentro de uma mesma sub-rede privada. Isso é útil para failover entre instâncias nessa rede. Não constitui prova de que o mesmo endereço possa ser movido para outra região ou sobreviver à perda da camada de controle de rede. Da mesma forma, as redes privadas conectam recursos, mas exigem design de roteamento, endereçamento e segurança por parte do cliente.

O Kubernetes gerenciado oferece nós de plano de controle de backup, e o S3 fornece replicação, mas cada um protege um componente específico. A resiliência só emerge quando as dependências da aplicação estão alinhadas: computação em mais de um domínio de falha, dados replicados ou restauráveis, direcionamento de tráfego independente do site com falha, segredos disponíveis, capacidade reservada e operadores capazes de executar o failover.

Os clientes também devem perguntar se a região alvo pode ser selecionada no momento do pedido para cada componente. Uma máquina virtual em Moscou-2 associada a armazenamento disponível apenas em Moscou-1 pode manter uma dependência oculta entre sites. Um banco de dados gerenciado pode suportar dois locais enquanto o repositório de backup permanece compartilhado. A documentação pública atesta a existência de escolhas; ela não fornece um mapa de dependências completo.

A diversidade de trânsito deve ser comprovada na borda do serviço

Os vizinhos observados e as centenas de prefixos do AS197695 tornam improvável uma rede de operador único no nível do sistema autônomo. O REG.RU também anuncia capacidade de rede privada de cerca de 200 Gbit/s e canais de acesso duplicados de 40 Gbit/s em sua página VPS, enquanto a declaração de portfólio mais recente menciona 300 Gbit/s em canais ópticos. Esses números indicam uma rede substancial, mas não substituem a prova de rota por site.

A rede pode falhar em várias camadas. Um switch de topo de rack pode isolar um grupo de servidores. Uma interconexão de instalação pode falhar enquanto o sistema autônomo mais amplo permanece visível. Um vazamento de rota ou erro de filtragem pode tornar alguns prefixos inacessíveis a partir de algumas redes. Os controles de DDoS podem proteger a capacidade enquanto introduzem falsos positivos. Um firewall do lado do cliente ou uma alteração de endereço pode se assemelhar a uma falha do provedor.

O DNS pode continuar respondendo com uma origem inacessível, ou a origem pode funcionar enquanto a conta REG.RU usada para modificar o DNS estiver indisponível.

Para um cliente, o teste relevante parte do endereço da aplicação, e não do ASN de topo do provedor. As observações de rota devem ser coletadas das populações de usuários e de mais de uma rede externa. Traceroutes não provam diversidade física, mas medições repetidas podem mostrar se os caminhos convergem para o mesmo operador. Documentos contratuais ou diagramas de rede devem identificar interconexões distintas, salas de encontro e entradas de edifícios quando esses detalhes são importantes.

A ausência de registro público no PeeringDB torna essa verificação mais difícil. O PeeringDB poderia ter listado os exchanges, instalações, capacidade e política, mas sua natureza voluntária significa que o REG.RU pode simplesmente usar acordos privados ou optar por não publicar. Os dados do RIPE confirmam a alcançabilidade pela Internet e uma adjacência variada; eles não podem localizar cada interconexão. O nível de evidência correto é, portanto, forte para uma rede ativa e de tamanho significativo, e médio a baixo para diversidade de rota por instalação.

Essa distinção também afeta designs "multissite" dentro de um mesmo provedor. Duas regiões do REG.RU podem usar hosts e armazenamento distintos, mas compartilham AS197695, serviços de mitigação, gerenciamento de endereços ou política de trânsito externo. Isso pode ser uma troca aceitável. Protege contra muitas falhas locais, mantendo baixa complexidade operacional. Isso não equivale a usar um provedor de DNS independente, um segundo sistema autônomo e uma segunda nuvem para o caminho mais crítico.

Faturamento, suporte e controle de conta são dependências de infraestrutura

A falha de infraestrutura não se limita a hardware quebrado. Os termos de nuvem do REG.RU descrevem um saldo debitado à medida que os recursos são usados, e o SLA exclui interrupções relacionadas ao não cumprimento dos termos de pagamento. Um serviço pode, portanto, ficar indisponível devido a um estado comercial, mesmo quando o rack, a rota e o hipervisor estão saudáveis. As organizações devem tratar alertas de saldo, direitos de renovação e métodos de pagamento como controles de produção.

A conta tem importância semelhante. Os serviços de hospedagem na Rússia exigem identificação do cliente, e oguia de identificação em nuvemdo REG.RU aplica esse requisito a máquinas virtuais, bancos de dados, Kubernetes, S3 e servidores dedicados físicos. A identificação pode aumentar a responsabilidade, mas introduz dependências de documentação e acesso. Um cliente profissional deve garantir que mais de um funcionário autorizado possa gerenciar a conta e que os registros de propriedade permaneçam atualizados quando o pessoal mudar.

A cobertura de suporte é diferenciada. O REG.RU anuncia suporte técnico 24 horas, enquanto seuguia de suporte em nuvemconvida os clientes a escolher uma fila específica do serviço e indica horários de consulta telefônica diários. Avisos de feriados indicaram que o suporte técnico para domínios, hospedagem, produtos corporativos e nuvem continua 24 horas, enquanto algumas funções de escritório ou de solicitação geral fecham. Isso torna o encaminhamento de tickets e os direitos de escalação importantes durante um incidente complexo.

O suporte também cruza fronteiras de responsabilidade. Em um servidor bare metal ou em nuvem não gerenciado, o provedor pode restaurar energia, rede ou hardware enquanto o cliente repara o sistema operacional e a aplicação. Serviços gerenciados transferem parte da responsabilidade para cima, mas os clientes permanecem proprietários da classificação dos dados, do comportamento da aplicação e da configuração de acesso. A página S3 divide explicitamente as responsabilidades: o provedor gerencia a replicação e a infraestrutura física; o cliente gerencia permissões, ciclo de vida, versionamento, integrações e chaves.

Um plano de escalação prático deve identificar o titular do contrato, contatos técnicos, contatos de faturamento e as evidências necessárias em um ticket. O SLA do REG.RU solicita informações detalhadas sobre o serviço e a falha e pode exigir acesso a um servidor para investigação. Durante um incidente, atrasos para encontrar credenciais ou autorização podem prolongar o tempo de inatividade, mesmo com suporte disponível.

A concentração mais perigosa é uma conta que controla o registro de domínio, o DNS e a infraestrutura com um único identificador e um único método de pagamento. Um design mais seguro separa funções, protege ações de alto impacto, mantém um registro offline das credenciais de recursos e possui um segundo método de comunicação. Isso é higiene operacional comum, mas a amplitude do catálogo do REG.RU a torna particularmente consequente.

Portabilidade existe, mas a migração tem custo e sequência

O REG.RU fornece várias interfaces abertas ou familiares que reduzem a dependência. As máquinas virtuais podem executar sistemas Linux e Windows comuns. Servidores dedicados expõem IPMI ou KVM e permitem imagens de sistema operacional do cliente. O armazenamento de objetos usa uma interface compatível com S3. O Terraform é suportado para algumas provisões em nuvem. Os dados podem ser copiados com ferramentas padrão, e o DNS permanece baseado em registros portáteis.

Oguia de migração de cPanel para ispmanagerdo provedor é valioso porque mostra a sequência concreta: identificar arquivos e bancos de dados, criar um arquivo e um dump de banco de dados, anotar a versão do software, criar o ambiente de destino, carregar arquivos, dados, testar antes de alterações de DNS, atualizar registros e mover o e-mail separadamente. Trata-se de uma migração para o REG.RU, mas os mesmos componentes devem ser compreendidos para uma migração de saída.

A portabilidade não é, portanto, uma característica binária. Um pequeno site estático pode ser copiado rapidamente. Um grande banco de dados requer replicação ou uma janela de manutenção. Um banco de dados gerenciado pode expor ferramentas de mecanismo padrão, mas exigir versões e extensões compatíveis. Um armazenamento de objetos em escala de terabyte pode usar uma API padrão, mas levar um tempo considerável para transferência na conexão disponível. Endereços IP públicos geralmente não viajam para outro provedor, então DNS, certificados e listas de permissão devem ser alterados.

A combinação de serviços do REG.RU pode facilitar uma mudança em etapas. Um cliente pode construir um novo servidor, restaurar dados, testá-lo através de uma entrada de arquivo hosts local ou um nome temporário, e só alternar o registro público quando estiver pronto. O guia de migração recomenda explicitamente testes antes da troca. No entanto, usar o DNS do REG.RU tanto para o serviço antigo quanto para o novo significa que a troca ainda depende da mesma superfície de controle. Migrações críticas podem justificar um arranjo de DNS secundário independente e uma redução antecipada dos tempos de vida dos registros.

Os backups também devem ser exportáveis antes de uma emergência. Um backup hospedado pelo provedor que só pode ser restaurado no mesmo serviço é útil para erros locais, mas fraco para sair do provedor. A compatibilidade com S3 e cópias de arquivo padrão melhoram as opções, desde que as credenciais e a largura de banda permaneçam disponíveis. Os clientes devem cronometrar uma exportação representativa e registrar dependências como chaves de criptografia, usuários de banco de dados, certificados e arquivos de licença.

A economia da saída deve fazer parte da arquitetura original. Uma capacidade barata e rapidamente disponível ainda pode ser cara para sair se o volume de dados, funcionalidades gerenciadas proprietárias ou dependências de endereço se acumularem. O REG.RU oferece interfaces padrão suficientes para tornar a portabilidade plausível. As evidências públicas não quantificam a taxa de transferência de exportação, os compromissos de suporte para saída ou por quanto tempo os dados permanecem acessíveis após a rescisão comercial; portanto, esses termos devem ser confirmados diretamente.

A localização dos dados é clara no nível nacional e menos clara dentro dos produtos

O REG.RU coloca consistentemente a infraestrutura anunciada na Rússia. O guia de hospedagem nomeia cidades e endereços russos. O catálogo de nuvem afirma que suas instalações Tier III estão em Moscou, São Petersburgo e na região de Samara. A página S3 faz a mesma afirmação no nível nacional. Para organizações obrigadas a manter dados pessoais de cidadãos russos na Rússia, essa é uma base relevante.

O provedor também oferece servidores em nuvem projetados para os requisitos da Lei Federal 152-FZ. Suadocumentação sobre servidores regulamentadosidentifica um local em Moscou e descreve a responsabilidade do provedor pela infraestrutura, uma instalação certificada e proteções técnicas. Isso é mais específico do que uma promessa genérica de "nuvem local". No entanto, isso não transfere toda a responsabilidade de conformidade para o provedor; o cliente continua sendo o operador de dados pessoais e deve configurar e governar seu sistema de acordo.

A localização tem vários níveis. A localização nacional pergunta se os dados primários permanecem na Rússia. A localização da instalação pergunta em qual cidade e edifício eles estão. A localização da replicação pergunta para onde vão as cópias e backups. A localização administrativa pergunta quem pode acessá-los. A localização do suporte pergunta onde o pessoal e o gerenciamento remoto operam. As páginas públicas respondem à primeira pergunta mais claramente do que às outras.

A geografia dos produtos também pode mudar. A página de marketing do S3 menciona Moscou, São Petersburgo e Samara, enquanto funcionalidades específicas de nuvem podem estar disponíveis apenas em uma ou duas regiões. O anúncio DBaaS descreve dois locais em Moscou, e o lançamento do Blackwell está vinculado a Moscou-3. Um cliente não pode deduzir as opções de posicionamento de um produto a partir do mapa corporativo completo. A interface de pedido e a especificação contratual devem identificar a região escolhida.

A concentração nacional é tanto uma vantagem quanto um risco. Atende aos requisitos de residência de dados e latência local para usuários russos. Também significa que o parque anunciado está exposto a um único ambiente jurídico, mercado de eletricidade e conectividade nacional. Clientes atendendo usuários em outros lugares devem testar as rotas internacionais e examinar se uma cópia independente fora do provedor é legalmente permitida e operacionalmente desejável. A resposta depende dos dados e obrigações do cliente, e não de um rótulo genérico de nuvem.

Como uma falha se parece para diferentes clientes

Uma pequena empresa usando o REG.RU para um domínio, hospedagem compartilhada e e-mail está mais exposta a falhas de conta, DNS e plataforma compartilhada. Backups diários podem restaurar o site, mas alterações feitas após a última cópia podem ser perdidas. Se a mesma conta controla o domínio e a hospedagem, um problema de acesso pode bloquear tanto o diagnóstico quanto o redirecionamento. A melhor melhoria é muitas vezes modesta: uma recuperação de conta independente, uma cópia externa dos dados do site e do e-mail, e um método documentado para mover o DNS.

Uma empresa de software em máquinas virtuais em nuvem enfrenta falhas de cluster, armazenamento e região. IPs flutuantes e redes privadas podem ajudar dentro de um mesmo local. Backups e snapshots podem restaurar instâncias. Nenhum deles substitui um segundo local operacional quando os objetivos de tempo de inatividade são curtos. A empresa precisa de replicação no nível da aplicação, monitoramento externo e capacidade de reserva suficiente no local de destino.

Um cliente em bare metal assume mais responsabilidade operacional. O IPMI pode restaurar o acesso ao console, e o REG.RU pode substituir hardware com falha, mas a aplicação pode permanecer vinculada a discos locais e a uma máquina específica. Discos espelhados protegem contra certas falhas de dispositivo, não contra perda de site ou corrupção. Um segundo servidor e uma cópia de dados fora da máquina são as medidas mínimas de resiliência confiáveis para uma carga de trabalho crítica.

Um cliente com dados regulamentados tem outra restrição: o alvo de recuperação deve satisfazer os mesmos requisitos de residência e segurança que a produção. Um backup em um local não especificado ou em uma nuvem alternativa escolhida às pressas pode ser inutilizável do ponto de vista de conformidade. Os múltiplos sites russos do REG.RU podem ser úteis, mas o posicionamento exato e os controles devem ser confirmados por escrito.

Clientes de domínio são afetados mesmo quando não compram hospedagem. A rede ativa AS197695 e os endereços DNS autoritativos mostram que os serviços de nomenclatura também têm dependências físicas e de roteamento. O credenciamento do registrador e o depósito de dados protegem alguns aspectos da relação de registro, mas não tornam a arquitetura DNS escolhida pelo cliente continuamente disponível. Registro, DNS autoritativo e hospedagem de aplicação são funções distintas e devem ser avaliadas separadamente.

Em cada caso, o caminho de falha mais importante é uma cadeia. Uma perda de energia pode derrubar um rack; uma falha de rota pode isolar uma máquina saudável; uma falha de armazenamento pode deixar a computação funcionando sem dados; um problema de conta pode impedir o failover de tráfego; um pagamento vencido pode interromper um serviço saudável; e uma escalação de suporte lenta pode prolongar cada um desses problemas. O cliente sofre a dependência não resolvida mais longa, não o componente mais forte do portfólio.

O veredito operacional: uma rede real, transparência parcial, resiliência construída pelo cliente

O REG.RU ultrapassa o limiar de um provedor de infraestrutura operacional. A empresa registradora nomeada está atualizada no registro da IANA, possui recursos de rede RIPE e emite uma ampla superfície de roteamento ativa através do AS197695. O parque de serviços de marca contém um inventário de bare metal encomendável, máquinas virtuais, armazenamento e produtos gerenciados. A documentação expõe endereços físicos, métodos de gerenciamento remoto, comportamento de backup e um objetivo de disponibilidade contratual. Estes são sinais operacionais substanciais.

As evidências são menos completas nas fronteiras. Os documentos públicos misturam a marca do grupo e várias sociedades jurídicas. Os números do portfólio combinam instalações que parecem ter proprietários e funções diferentes. As certificações de instalações e os megawatts agregados não revelam a capacidade ocupada ou disponível do REG.RU. A visão de roteamento global não prova a diversidade de circuitos em cada site. As páginas de produto não fornecem um mapa comum de domínios de replicação e recuperação. Um histórico estruturado e público de incidentes não estava disponível para ser comparado ao SLA.

Essa combinação não merece rejeição nem confiança incondicional. As evidências de rede são fortes. As evidências de produto são sólidas para a disponibilidade atual de serviços. As evidências de propriedade de instalações e redundância produto a produto são médias a baixas. As evidências históricas de falhas são fracas. A resposta correta do cliente é reorientar cada afirmação para o serviço contratado.

Antes de colocar uma carga de trabalho crítica, um comprador deve obter respostas por escrito a um pequeno conjunto de perguntas operacionais: a empresa contratante; a instalação selecionada e seu operador; os domínios de falha de computação, armazenamento e rede; o local e a imutabilidade dos backups; os compromissos de ponto de recuperação e tempo de recuperação; o tratamento de trabalhos planejados; as condições de substituição de hardware; a escalação de suporte; as regras de saldo e suspensão; e a rota de exportação testada.

Para designs multissite, o comprador também deve confirmar se a capacidade está reservada no local alternativo e se o DNS, a identidade e o gerenciamento permanecem utilizáveis quando o local principal falha.

A proposta de valor do REG.RU é a redução de atrito. Um cliente pode começar com um nome e adicionar formas de infraestrutura cada vez mais físicas sem sair do ambiente comercial único. A realidade subjacente vai na direção oposta: cada serviço adicionado introduz servidores, discos, links de rede, contratos de instalação, equipes de suporte e decisões de recuperação. A interface de nuvem torna essas dependências mais fáceis de comprar. Ela não as faz desaparecer.