Hosting-27 Hosting-27 LTD vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A Hosting-27 Hosting-27 LTD não é uma empresa visível apenas em registros de roteamento. A página inicialHosting27.comem funcionamento anuncia serviços de hospedagem e nuvem búlgaros, apágina de contatofornece um endereço em Sofia, telefone e endereços de e-mail de suporte, aárea do clienteexpõe um portal de login e faturas, e apágina de tickets de suportedescreve um departamento de suporte que trabalha todos os dias. Essa superfície de vendas pública é real, mas por si só não prova onde os servidores estão localizados ou como as interrupções são reparadas.
• A identidade de rede é concreta e compacta. O objetoAS42347do Banco de Dados RIPE nomeia Hosting-27, vincula o AS aORG-HA629-RIPE, lista Hosting-27 LTD como a organização, fornece o país BG, número de registro 204354361 e um endereço em Sofia, e registra importações e exportações com AS57344 e AS31083. Oinetnum 217.174.144.0 - 217.174.144.255e oobjeto de rota 217.174.144.0/24do RIPE vinculam o bloco IPv4 visível à Hosting-27 e AS42347.
• A visão da rota ativa é mais estreita do que o menu de marketing. Avisão geral do ASdo RIPEstat mostrou AS42347 anunciado em 12 de julho de 2026, e suavisão de status de roteamentomostrou um prefixo IPv4 visível, 256 endereços IPv4, nenhum IPv6 visível e um vizinho observado. Avisão de vizinhos ASNdo RIPEstat identificou esse vizinho como AS57344, e avisão geral do AS57344do RIPEstat identifica AS57344 como Telehouse EAD. Um segundo par, AS31083 Telepoint, aparece na política de registro do AS42347, mas não na visão atual de consistência BGP.
• O grau operacional é um médio qualificado, não forte. As páginas de produtos parahospedagem compartilhada,Cloud VPS,Cloud VPS gerenciado,nuvem privadaeKubernetesmostram uma ampla oferta de capacidade hospedada. As evidências públicas não mostram um salão de data center nomeado, contagem de racks, projeto de energia, estoque de hardware, termos de retenção de backup do cliente, trânsito duplo ativo, serviço IPv6 ou um caminho de portabilidade por escrito.

A superfície de serviço é visível, mas precisa ser lida a partir do rack

Hosting-27 Hosting-27 LTD não deve ser confundida com um registro vazio de números da internet. O site público Hosting27.com está ativo, datado por seus próprios metadados de cabeçalho e páginas visíveis, e construído como uma vitrine operacional de hospedagem. Apágina inicialapresenta a marca como provedora de serviços de hospedagem e nuvem. Ela direciona compradores para hospedagem WordPress, clusters Kubernetes, nuvem privada, Cloud VPS, Cloud VPS gerenciado, hospedagem revenda, domínios, área do cliente, faturas e tickets de suporte. A navegação não é um placeholder abandonado de uma página; é uma superfície de varejo de hospedagem com níveis de produtos, botões de pedido, uma área de conta estilo WHMCS e um portal de suporte.

Isso torna a investigação mais exigente, não menos. Quando uma empresa vende hospedagem web ou servidores em nuvem, a dependência do cliente não é a página web. A dependência é a pilha oculta por trás da fatura: um nó host, um back-end de armazenamento, switches, roteadores, estoque IPv4, trânsito upstream, energia, refrigeração, mãos remotas, estado de faturamento, tratamento de abuso e uma equipe de suporte com autoridade para agir. O material público da Hosting27 descreve vários produtos voltados ao cliente, mas não identifica a instalação ou instalações por trás deles.

Não diz se a Hosting-27 opera seus próprios racks, aluga espaço em racks, depende de outro operador de data center búlgaro ou revende capacidade montada por um provedor relacionado.

O menu de produtos importa porque diz aos clientes que tipo de sistema físico teria que existir. Apágina de hospedagem compartilhadaanuncia três tamanhos de plano com 20 GB, 50 GB e 165 GB de espaço, cPanel, sites ilimitados, caixas de correio ilimitadas, certificados SSL gratuitos, CDN, ajuda de migração, várias versões do PHP e backups de um mês. Apágina de hospedagem WordPressanuncia níveis similares de 20 GB, 50 GB e 165 GB, adiciona gerenciamento WordPress e promete ajuda para mover sites WordPress. Apágina de hospedagem revendaoferece planos de 40 GB, 75 GB e 130 GB com acesso WHM, tráfego ilimitado e contas ilimitadas. Esses não são slogans abstratos de nuvem. São alegações de que hosts físicos ou virtuais compartilhados existem, que contas podem ser criadas neles e que migrações e backups fazem parte da promessa de serviço.

O menu de nuvem aumenta as apostas. Apágina Cloud VPSanuncia instâncias de um a quatro CPUs virtuais, 1 GB a 6 GB de RAM, 30 GB a 85 GB de armazenamento all-SSD, backups diários, um painel de gerenciamento, OpenStack, KVM e Ceph. Também vende endereços IP adicionais, backups adicionais do sistema e blocos de administração do sistema de trinta minutos. Apágina Cloud VPS gerenciadoanuncia servidores gerenciados com painel de controle, suporte técnico, backups diários, monitoramento 24 horas e migração gratuita. Apágina de nuvem privadavai além, descrevendo uma oferta de data center virtual baseada em OpenStack com armazenamento definido por software, uma alegação de nível de serviço de 99,99%, uma rede duplamente segura e serviços de API como Cinder, Nova, Heat, Glance, Magnum, Neutron e Keystone. Apágina Kubernetesdescreve ajuda para instalar, configurar e manter um ambiente Kubernetes altamente disponível e diz que o serviço cobre infraestrutura, rede e balanceadores de carga como uma de suas camadas.

Essas páginas dão à Hosting27 uma superfície de vendas pública mais forte do que muitas redes de hospedagem pequenas. Elas também criam uma lacuna de evidências maior. Um vendedor de VPS de um nó pode falhar silenciosamente. Um vendedor de OpenStack, Ceph, nuvem privada e Kubernetes tem que responder mais: quantos nós físicos estão disponíveis, como a replicação de armazenamento é isolada, se os componentes do plano de controle têm domínios de falha independentes, onde os backups se encontram, qual pool de endereços atende os clientes, qual roteador carrega a rota e quem pode reparar o sistema quando a camada física falha.

O ponto de partida mais seguro é, portanto, nem a rejeição nem a confiança cega. Hosting-27 tem um site visível e um AS visível. O registro público apoia a existência de uma operação de hospedagem búlgara. Ele não apoia uma conclusão forte sobre capacidade de nuvem instalada, recuperação multi-site ou independência do provedor.

O registro RIPE dá à Hosting-27 uma borda de rede pequena, mas real

A evidência de infraestrutura mais clara está no Banco de Dados RIPE e no RIPEstat. Oregistro aut-num para AS42347nomeia o AS como "Hosting-27", lista Hosting-27 LTD através de ORG-HA629-RIPE, registra status ASSIGNED, dá criação em 24 de agosto de 2017 e última modificação em 7 de abril de 2021, e registra política de importação e exportação para AS57344 e AS31083. Oregistro de organizaçãovinculado nomeia Hosting-27 LTD, país BG, número de registro 204354361, tipo de organização OTHER, um endereço em Sofia na Todor Aleksandrov 133, e um contato de abuso em GLAC2-RIPE. Foi criado em agosto de 2017 e modificado pela última vez em maio de 2026.

A atribuição IPv4 é igualmente explícita. Oinetnum para 217.174.144.0 - 217.174.144.255do RIPE usa netname Hosting-27, país BG, organização ORG-HA629-RIPE e status ASSIGNED PA. Oobjeto de rota para 217.174.144.0/24do RIPE descreve Hosting27 e autoriza a origem AS42347. Avisão de prefixos anunciadosdo RIPEstat mostrou 217.174.144.0/24 visível na janela de duas semanas encerrada em 12 de julho de 2026. Suavisão de status de roteamentomostrou um prefixo IPv4, 256 endereços IPv4 e visibilidade IPv4 completa em 326 de 326 peers RIPE RIS no momento verificado.

Esse /24 não é apenas um registro passivo. O domínio Hosting27.com se resolve no mesmo bloco. Avisão da cadeia DNSdo RIPEstat para hosting27.com resolveu hosting27.com para 217.174.144.181, associou reversamente esse endereço a shared-11.cpaneler.com, e listou servidores de nomes autoritativos incluindo ns1-pns.hosting27.com e ns2-pns.hosting27.com. Oregistro RDAP do domínio hosting27.commostra o domínio registrado em 12 de julho de 2013, expirando em 12 de julho de 2027, com PublicDomainRegistry.com como registrador e servidores de nomes sob hosting27.com. O site visível, DNS e prefixo roteado, portanto, se alinham em torno da mesma pegada de rede pública.

O pool de endereços é pequeno. Um /24 contém 256 endereços IPv4 antes de contar interfaces de roteador, hosts de infraestrutura, servidores de nomes, IPs de hospedagem compartilhada, atribuições de clientes, endereços sobressalentes e capacidade reservada. Isso é suficiente para um negócio de hospedagem real, especialmente se muitos clientes de hospedagem compartilhada estiverem por trás de hosts virtuais baseados em nome e se planos VPS pequenos puderem compartilhar hosts sem que cada um receba vários endereços públicos. Não é suficiente para inferir grande capacidade instalada.

Uma oferta de nuvem privada, uma oferta Kubernetes, contas de revenda, VPS gerenciado e hospedagem compartilhada podem ser vendidos a partir de um pool público compacto se endereçamento interno, NAT, hospedagem virtual e atribuição cuidadosa forem usados. Eles também podem ser sobrevendidos se o planejamento for frouxo. A rota pública não distingue esses casos.

Há também um segundo objeto de rota que deve ser tratado com cuidado. Avisão de consistência de roteamento ASdo RIPEstat lista 45.151.89.0/24 como presente no whois, mas não no BGP para AS42347 no momento consultado. Umapesquisa no RIPE para 45.151.89.0/24mostra um objeto de rota para AS42347, mas o inetnum pertence a Geytit OOD, não a Hosting-27 LTD, e a rota não fazia parte do conjunto anunciado visível atual. Isso significa que é possível que a política de rota tenha sido preparada para outro pool, ou que a rota estava inativa, reservada, histórica ou não visível no momento da consulta. Não deve ser contada como capacidade da Hosting-27 disponível ao cliente, a menos que o BGP atual e evidências comerciais a apoiem.

A borda da rede é, portanto, real, mas de escopo restrito: um AS visível, um /24 IPv4 visível, um objeto de rota válido, um site ativo dentro do bloco e nenhum prefixo IPv6 visível para AS42347 na visão de rota do RIPEstat.

O escritório, o site e o nome contratual não são o mesmo que um data center verificado

O rastro de endereço público é útil, mas não identifica um data center. Apágina de contatoda Hosting27 fornece Sofia, Boulevard Todor Aleksandrov 133, 2º andar, além de um número de telefone e endereços de e-mail de suporte e vendas. O registro de organização RIPE para Hosting-27 LTD fornece um endereço correspondente na Todor Aleksandrov 133. Oregistro de organização RIPE da Geytit OODtambém usa Todor Aleksandrov 133 e aparece como a organização patrocinadora no registro AS42347. Esses registros são significativos para contato e administração de registro. Eles não provam que os servidores dos clientes estão nesse edifício, que a Hosting-27 possui racks lá, ou que a empresa tem acesso direto a energia e infraestrutura de cross-connect.

Os termos legais públicos adicionam outro limite. Apágina de termos geraisda Hosting27 incorpora um PDF, e ostermos em PDFafirmam que os termos de serviço regulam hospedagem compartilhada, certificados SSL, registro de domínio, servidores virtuais e servidores virtuais gerenciados através do site Hosting27.com. O PDF nomeia Cloud Systems OOD como o provedor nos termos búlgaros e fornece um número de registro de empresa diferente. Este artigo não trata isso como uma constatação de relacionamento corporativo. Trata como uma questão de diligência do comprador: a marca, organização RIPE, LIR patrocinador, termos do site e emissor da fatura precisam se alinhar antes que um cliente trate o serviço como um contrato de infraestrutura confiável.

Este limite importa durante a falha, não apenas durante a aquisição. Se uma VM falhar às 02:00, o cliente precisa saber qual entidade controla a fila de suporte, qual entidade possui ou aluga o hardware, quem pode autorizar mãos remotas, quem pode substituir um disco, quem controla a sessão do roteador, quem fatura o serviço e quem pode preservar os dados se o faturamento for contestado. Uma incompatibilidade entre marca, titular do AS e provedor de contrato não é inerentemente ruim; muitos grupos de hospedagem usam veículos legais separados para recursos de endereço, contratos de clientes, instalações e operações.

Mas os materiais públicos revisados aqui não explicam essa estrutura. Os clientes devem perguntar diretamente.

Os termos também deixam claro que o serviço hospedado é uma oferta limitada, não uma garantia de que cada cliente receba um ambiente totalmente independente. O PDF diz que a hospedagem compartilhada envolve clientes compartilhando recursos comuns do servidor, como velocidade, RAM e conectividade de rede com outros usuários. Sua seção de servidor virtual gerenciado descreve a administração de um servidor virtualmente separado com painel de controle, suporte 24 horas, recursos garantidos não compartilhados com outras aplicações de clientes, monitoramento, reação a problemas e backups regulares.

Essa é uma linguagem útil para entender as classes de serviço pretendidas. Ainda deixa tempo de restauração, localização do backup, retenção de snapshots, replicação fora do local, formato de exportação do cliente e créditos por interrupção pouco claros na visão pública.

O enquadramento de "data center virtual" da página de nuvem privada é especialmente importante de qualificar. Um cliente lendo essa frase pode imaginar uma zona de data center dedicada. A página em si está descrevendo uma abstração OpenStack: redes criadas pelo cliente, roteadores, balanceadores de carga e serviços de armazenamento. Essas são características virtuais do plano de controle. Elas ainda se baseiam em nós físicos, discos, placas de rede, switches de topo de rack, alimentações de energia e links de trânsito.

Sem uma instalação nomeada ou declaração de arquitetura, a alegação deve ser tratada como uma oferta de plano de controle de nuvem, não como prova de um site físico separado.

A dependência upstream visível é a Telehouse, enquanto a Telepoint é uma possibilidade de política

O quadro de rota é direto no ponto de observação atual. Avisão de vizinhos ASNdo RIPEstat para AS42347 relatou um vizinho único no momento mais recente disponível: AS57344. Avisão geral do AS para AS57344do RIPEstat identifica AS57344 como TELEHOUSE-AS Telehouse EAD. Oaut-num AS57344do RIPE mostra a Telehouse com uma ampla política upstream e de exchange, incluindo Arelion, Cogent, GTT, Level 3, Liberty Global, NTT, Orange, PCCW, RETN, Seabone, Tata, Telxius e várias malhas de exchange. Oregistro do AS57344 no PeeringDBdescreve a Telehouse como tendo escopo global, suporte IPv6, muitas presenças de exchange e entradas de instalações.

Essa amplitude da Telehouse ajuda a explicar como o /24 da Hosting-27 pode ser visível a partir de coletores globais. Não torna automaticamente a Hosting-27 multi-homed. A dependência imediata observada para AS42347 ainda é um vizinho. Se a rota AS42347 é transportada apenas através da Telehouse na borda ativa, então um problema no lado da Telehouse, problema de sessão, filtro de rota, incidente de instalação, problema de cross-connect, retenção comercial ou janela de manutenção pode afetar todos os clientes usando o prefixo visível da Hosting-27.

Coletores de rota públicos podem perder caminhos de backup privados, sessões temporariamente inativas ou arranjos que se tornam ativos apenas durante a falha. Mas o ônus é do provedor mostrar tal redundância, porque a visão BGP pública atual não mostra.

AS31083 é o segundo nome a ser tratado com precisão. O aut-num AS42347 do RIPE lista política de importação e exportação com AS31083, e avisão geral do AS31083do RIPEstat identifica AS31083 como Telepoint Ltd. Oaut-num AS31083do RIPE mostra a Telepoint conectada a vários upstreams, e oregistro da Telepoint no PeeringDBrelata um perfil de escopo europeu menor. Mas a visão de consistência de roteamento AS do RIPEstat mostra AS31083 como presente na política whois e não presente no BGP para AS42347 no momento consultado. Isso significa que a política de registro sozinha não deve ser descrita como diversidade ativa.

A ausência no PeeringDB da Hosting-27 reforça a necessidade de cautela. Umaconsulta no PeeringDB para AS42347não retornou nenhum objeto de rede público. Muitas redes pequenas operam sem perfil no PeeringDB, então a ausência não é uma falha. Significa apenas que não há lista pública de instalações, lista de exchanges, página de looking-glass, estimativa de tráfego, política de peering ou perfil NOC da Hosting-27 nesse diretório. A única trilha de interconexão pública é a política do RIPE, coletores de rota e as identidades dos upstreams observados ou registrados.

O resultado de segurança de origem de rota é positivo. Avalidação RPKI para 217.174.144.0/24relata um ROA válido para AS42347 originando o /24 exato com comprimento máximo /24. Isso ajuda redes que aplicam validação de origem de rota a aceitar a rota como autorizada. Não protege contra falha de host, falha de armazenamento, má configuração de roteador, contas upstream não pagas, comprometimento do painel de controle ou bloqueio de conta de cliente. RPKI responde quem pode originar o prefixo, não se o serviço de hospedagem pode se recuperar.

Para compradores, a pergunta de diligência de trânsito é prática: a Telehouse é o upstream ativo para todos os serviços da Hosting27, o AS31083 é uma entrada de política de espera ou histórica, algum dos caminhos pode transportar a carga de trabalho do cliente durante a manutenção, e as rotas são anunciadas a partir de handoffs fisicamente separados ou da mesma sala e cadeia de dependência?

Características de nuvem anunciadas não equivalem a capacidade instalada, utilizável ou recuperável

A economia de hospedagem recompensa o compartilhamento eficiente. A hospedagem compartilhada vende disco, correio e gerenciamento de site agrupando muitas contas de clientes em um ou mais servidores. A hospedagem VPS vende fatias virtuais de CPU, RAM e armazenamento de hosts maiores. O VPS gerenciado adiciona mão de obra de suporte, monitoramento e administração. A nuvem privada adiciona uma camada de orquestração e uma promessa mais forte de controle do cliente. Kubernetes adiciona outra camada de orquestração acima disso. Cada camada pode ser real enquanto ainda depende de um pequeno número de nós físicos.

As páginas da Hosting27 fazem alegações amplas que são plausíveis para um pequeno provedor búlgaro, mas impossíveis de dimensionar de fora. Os planos de hospedagem compartilhada anunciam sites, caixas de correio e tráfego ilimitados, mas esses são regras do plano, não capacidade infinita. O serviço ainda depende de CPU, RAM, I/O de armazenamento, limites de inode, regras de uso justo, controle de spam e tratamento de abuso.

Os planos de revenda anunciam tráfego e contas ilimitados, mas os limites de armazenamento são 40 GB, 75 GB e 130 GB; a restrição real pode ser I/O, reputação de correio de saída, densidade de contas ou desempenho do host compartilhado antes que o disco bruto seja esgotado.

As páginas VPS são mais concretas porque listam valores virtuais de CPU, RAM e SSD. Um plano Cloud VPS de 1 vCPU, 1 GB RAM, 30 GB SSD e um plano de 4 vCPU, 6 GB RAM, 85 GB SSD podem ser provisionados a partir de um cluster OpenStack modesto. Mas uma tabela de planos não mostra quantas instâncias podem ser vendidas sem contenção, quantos nós existem, se a CPU é sobreassinada, como a replicação de armazenamento é ajustada, se o Ceph abrange domínios de energia independentes ou se os backups são armazenados no mesmo sistema físico que devem proteger.

A página diz que o Ceph mantém os dados replicados em vários lugares; um cliente ainda precisa saber se esses lugares são discos separados, chassis separados, racks separados ou instalações separadas.

A linguagem de nível de serviço de 99,99% da página de nuvem privada deve ser tratada como uma alegação a ser verificada, não como prova do estado operacional alcançado. Quatro noves de disponibilidade permitem apenas uma pequena quantidade de tempo de inatividade ao longo de um ano, e requer tanto disciplina de arquitetura quanto operacional: energia redundante, caminhos de rede redundantes, armazenamento cuidadosamente gerenciado, recuperação do plano de controle testada, gerenciamento de mudanças, monitoramento e uma equipe de suporte capaz de agir rapidamente.

O site público não publica o documento SLA, cronograma de crédito, método de medição, exclusões, tratamento de manutenção planejada ou histórico de incidentes que permitiriam a um comprador avaliar essa promessa.

O estoque de endereços limita alguns casos de uso. Um cliente que precisa de muitos endereços IPv4 públicos, separação de serviço de correio, compatibilidade legada de SSL baseado em IP, isolamento antiabuso ou endpoints VPN deve perguntar quanto IPv4 está realmente disponível. Acontagem de status de roteamento do RIPEstatde 256 endereços IPv4 não é o mesmo que 256 IPs de clientes vendáveis. Alguns são consumidos por infraestrutura, DNS, hospedagem compartilhada, gerenciamento, reservas e atribuições de clientes. IPs adicionais são vendidos na página Cloud VPS, o que torna o pool operacionalmente importante. Se problemas de abuso ou lista negra afetarem uma parte do /24, o pequeno pool de endereços pode dificultar a recuperação.

IPv6 é outra lacuna. As páginas de produtos públicos da Hosting27 revisadas aqui não fazem uma promessa forte de IPv6, e o RIPEstat não mostra espaço IPv6 anunciado para AS42347 no momento verificado. Um cliente que precisa de hospedagem habilitada para IPv6 não deve inferir isso da palavra nuvem. Eles devem pedir um endereço de teste IPv6, cobertura SLA, tratamento de firewall, DNS reverso, evidência de roteamento e se o suporte IPv6 está disponível em hospedagem compartilhada, VPS, nuvem privada e Kubernetes da mesma forma que o IPv4.

A conclusão de capacidade do artigo é, portanto, conservadora: Hosting27 vende um conjunto real de produtos de hospedagem e nuvem, e AS42347 dá a esses produtos uma borda de rede pública real. Mas não há evidência pública que traduza o menu de planos em nós instalados, capacidade sobressalente disponível, design multi-site ou imagens recuperáveis pelo cliente.

Alegações de suporte e backup são úteis, mas a autoridade de reparo é a questão central

Evidência de suporte é melhor que silêncio. Apágina de contatoda Hosting27 lista endereços de suporte, incluindo caixas de correio de suporte e devops, e um endereço de vendas separado. Apágina de tickets de suportediz que os clientes que não conseguem resolver um problema na documentação podem enviar uma solicitação ao departamento apropriado. Descreve o suporte como trabalhando todos os dias sem interrupção e as consultas de vendas processadas de segunda a sexta, das 09:00 às 18:00. Abase de conhecimentotem categorias para cPanel, Virtualmin, servidores VPS, WordPress, domínios e hospedagem compartilhada. Apágina de anúncioscontém um anúncio mais antigo de 2018, que pelo menos mostra que o portal do cliente faz parte da superfície de serviço há anos.

Esses são sinais operacionais úteis. Eles não são suficientes para responder ao risco de janela de reparo. A distinção mais importante é entre um canal de suporte que recebe tickets e uma equipe de operações com autoridade sobre o componente com falha. Se a falha for uma configuração do cPanel, a helpdesk do provedor pode corrigi-la rapidamente.

Se a falha for um disco morto, um switch com falha, um problema de alimentação, um problema de quorum do cluster de armazenamento, um filtro de rota upstream ou uma conta de faturamento bloqueada, o reparo depende de quem controla o hardware, acesso à instalação, sessões de rota e permissões contratuais.

Os termos gerais também são úteis, mas incompletos para planejamento de incidentes. O PDF diz que servidores virtuais gerenciados incluem suporte técnico 24 horas, monitoramento e reação a problemas, backups regulares e a capacidade de hospedar aplicações do cliente. Diz que a hospedagem compartilhada inclui suporte técnico e deixa claro que os usuários compartilhados compartilham recursos. As páginas públicas adicionalmente anunciam backups diários no Cloud VPS e Cloud VPS gerenciado, backups de um mês na hospedagem compartilhada e migração gratuita para alguns planos. Isso é valioso.

Ainda deixa as questões práticas em aberto: os backups estão no mesmo cluster ou fora do local, quantas gerações existem, um cliente pode restaurar de forma autônoma, uma imagem de VM pode ser exportada, o que acontece após a suspensão da conta e qual é o tempo de restauração alvo?

A promessa de migração também é mais estreita do que parece. A Hosting27 diz que pode mover uma conta de hospedagem ou site WordPress gratuitamente. Isso ajuda durante a integração. Não cria necessariamente um caminho de saída. Um cliente que sai mais tarde pode precisar de um backup completo do cPanel, um dump do banco de dados, arquivos de zona DNS, caixas de correio, imagem de disco da VM, snapshot de armazenamento em bloco, dados de objeto, manifestos Kubernetes, imagens de contêiner, segredos e renumeração de IP.

O site público não descreve formatos de exportação, janelas de retenção, taxas de migração após cancelamento ou se os clientes podem retirar imagens do OpenStack.

O tratamento de abuso importa porque os provedores de hospedagem vivem e morrem pela reputação compartilhada. O registro de organização RIPE para Hosting-27 aponta abuso paraGLAC2-RIPE, um contato de abuso da GateIT. Esse é um caminho de abuso de registro, não necessariamente o mesmo que um balcão de suporte de varejo. Um cliente que executa correio, e-commerce ou APIs públicas deve perguntar quem gerencia o DNS reverso, quem lida com a remediação de listas negras, quem decide se uma conta comprometida causa suspensão mais ampla e se problemas de reputação de IP podem ser isolados dentro do /24.

A postura pública de suporte é, portanto, credível o suficiente para contar, mas não detalhada o suficiente para remover o risco operacional. Os compradores devem testar o balcão de tickets antes de mover cargas de trabalho importantes, pedir um caminho de contato para incidentes e solicitar termos escritos de backup e exportação em vez de confiar em abreviações da página de planos.

A localidade dos dados não é resolvida por um endereço búlgaro ou um IP búlgaro

A superfície búlgara da Hosting27 é relevante. O site está em búlgaro, a página de contato fornece detalhes em Sofia, a organização RIPE e o endereço são búlgaros, o ASN está na região RIPE e o bloco IPv4 visível está registrado com o país BG. Para clientes com usuários búlgaros, uma fatura búlgara, suporte no idioma local e latência para Sofia ou redes regionais podem ser razões para considerar o serviço. Para clientes com requisitos regulatórios ou contratuais de localidade de dados, esses sinais são apenas o começo.

O contexto da UE e búlgaro torna a distinção importante. A visão geral daComissão Europeia sobre o quadro jurídico de proteção de dados da UEexplica o regime de proteção de dados em toda a UE. Sua página sobrecontroladores e processadoresexplica a distinção entre a parte que decide como os dados pessoais são processados e uma parte que os processa em nome de outra. A página da Comissão sobrecláusulas contratuais padrãocobre ferramentas de transferência de dados para situações fora do Espaço Econômico Europeu. AComissão para Proteção de Dados Pessoaisda Bulgária é a autoridade de supervisão nacional. Este artigo não é aconselhamento jurídico, mas essas referências públicas mostram por que a localização da infraestrutura, acesso ao suporte e geografia de backup não são detalhes cosméticos.

Um endereço IP búlgaro não prova que todos os dados permanecem na Bulgária. Backups de hospedagem compartilhada podem ser armazenados em outra instalação. O monitoramento pode ser realizado de outro lugar. Um ticket de suporte pode incluir dados pessoais. Um painel de controle pode depender de software de terceiros ou autenticação externa. Um recurso de CDN pode intencionalmente colocar conteúdo estático em outros países. Um serviço de registro de domínio necessariamente interage com registries e registradores fora do nó de hospedagem.

Um cliente de nuvem privada pode criar redes e volumes em um console de aparência búlgara enquanto alguns componentes de gerenciamento ou backup estão em outro lugar.

As perguntas de diligência certas são, portanto, concretas. Onde está o nó de computação principal? Onde estão snapshots e backups armazenados? A equipe de suporte e administradores remotos estão dentro da UE? O provedor oferece um acordo de processamento de dados? Qual entidade legal é a processadora para serviços de hospedagem? O contrato nomeia a mesma parte que fatura o cliente? Se os dados saírem da Bulgária ou do EEE, qual mecanismo de transferência se aplica? O que acontece se o cliente solicitar exclusão ou exportação? Quais logs são mantidos e por quanto tempo?

Essas perguntas não são suspeita especial em relação à Hosting-27. São normais para qualquer pequeno provedor de nuvem ou hospedagem que comercializa localidade. A evidência pública aqui apoia uma área de serviço búlgara e uma borda roteada búlgara. Não prova uma arquitetura completa de residência de dados búlgara.

Os caminhos de falha a testar são rack, upstream, estoque de hardware, suporte, faturamento e migração

O primeiro caminho de falha é o rack. Se um servidor de hospedagem compartilhada ou host VPS falhar, quem toca na máquina? Um cliente deve perguntar onde o rack está, quem possui o hardware do host, como a energia é protegida, se há nós sobressalentes, se o armazenamento é local ou distribuído e se um nó com falha pode ser evacuado sem alterar o IP do cliente. O site público alega backups e recursos de nuvem, mas não nomeia a instalação física, gabinete, provedor de mãos remotas ou plano de hardware sobressalente.

O segundo caminho é o trânsito upstream. O RIPEstat atualmente vê AS42347 através de AS57344. O provedor deve ser capaz de dizer se a rota tem um segundo upstream ativo, se a Telepoint está ativa, em espera ou histórica, se a rota de backup é testada, se a validação de origem de rota é monitorada e se os clientes recebem aviso antes da manutenção de rede. Um resultado RPKI válido é bom. Não é o mesmo que um segundo caminho.

O terceiro caminho é o estoque de hardware e armazenamento. As ofertas de VPS e nuvem privada dependem da proporção entre planos vendidos e capacidade disponível de computação, RAM, I/O de disco e replicação de armazenamento. Um cliente deve perguntar se os recursos anunciados são garantidos, se a CPU é sobreassinada, se o Ceph abrange hosts separados ou racks separados, quantas falhas podem ser toleradas e se há capacidade sobressalente suficiente para restaurar um host durante um período movimentado.

A página pública nomeia OpenStack, KVM e Ceph, mas esses nomes podem descrever qualquer coisa, desde um pequeno cluster até um ambiente multi-rack maior.

O quarto caminho é a escalada de suporte. A Hosting27 expõe páginas de suporte, vendas, base de conhecimento e tickets. O comprador ainda deve testar a qualidade da resposta, perguntar quem está de plantão, identificar o caminho de emergência para uma VM inativa e perguntar se o suporte pode alcançar os operadores de rede e instalação diretamente. Uma resposta de vendas não é o mesmo que autoridade de incidente.

O quinto caminho é a continuidade de faturamento e legal. Os termos em PDF do site nomeiam Cloud Systems OOD como provedor, enquanto o RIPE nomeia Hosting-27 LTD como a organização de rede. Os clientes devem perguntar qual parte assina o contrato, qual parte fatura, qual parte controla a suspensão do serviço e qual parte é responsável pela exportação e exclusão após o cancelamento. Se a conta for suspensa por faturamento ou abuso, o cliente deve saber por quanto tempo os dados permanecem recuperáveis.

O sexto caminho é a migração. Para hospedagem compartilhada, o caminho de saída deve incluir backup do cPanel, DNS, caixas de correio e bancos de dados. Para WordPress, deve incluir arquivos, banco de dados, redirecionamentos e tempo de DNS. Para VPS, deve incluir exportação de imagem de disco, formato de snapshot, renumeração de IP e atualizações de firewall. Para nuvem privada e Kubernetes, deve incluir volumes, redes, balanceadores de carga, manifestos, segredos e registries de imagens. A Hosting27 comercializa migração de entrada gratuita, mas o material público não publica uma promessa completa de portabilidade de saída.

O sétimo caminho é a reputação de endereço. Um /24 compacto pode ser eficiente, mas dá menos espaço para isolar clientes comprometidos. Problemas de correio, proxy, varredura e abuso podem levar a listas de bloqueio, filtragem upstream ou suspensões internas. Clientes com cargas de trabalho de correio ou transacionais devem perguntar sobre controle de DNS reverso, procedimento de resposta a abuso, política de limpeza de listas negras e se endereços IP adicionais vêm do mesmo pool 217.174.144.0/24.

Essas não são preocupações teóricas. São os modos de falha comuns escondidos sob hospedagem de baixo custo: um rack que não pode ser alcançado, uma sessão upstream que desaparece, um cluster de armazenamento que perde quorum, um backup que existe mas não pode ser restaurado rapidamente, uma fila de tickets que não pode alcançar a instalação e um cliente que descobre tarde demais que sair significa reconstruir em torno de novos endereços IP.

O que tornaria a evidência forte

A Hosting-27 Hosting-27 LTD tem evidência pública suficiente para um perfil operacional real: o site está ativo, o portal do cliente está ativo, as páginas de produto são específicas, a rota é visível, o domínio se resolve dentro do bloco IPv4 visível da empresa, a organização RIPE está atualizada e a autorização de origem de rota é válida. Isso é materialmente mais forte do que uma empresa cujo único traço é um registro AS desatualizado.

A evidência pública não é forte o suficiente para confiança de infraestrutura de alto nível sem diligência direta.

Um perfil mais forte incluiria uma página legal atual que alinhe a marca, organização RIPE e provedor contratual; uma declaração de instalação nomeando o operador do data center ou explicando o arranjo de hospedagem; um SLA com termos de medição e crédito; uma página de status ou arquivo de incidentes; retenção explícita de backup e objetivos de restauração; disponibilidade de IPv6 se oferecido; um segundo upstream ativo ou uma explicação por escrito da política de rota da Telepoint; formatos de exportação para dados de VPS e nuvem privada; e um procedimento claro de abuso e reputação de IP.

O conjunto provável de clientes deve ser estratificado por risco. Um pequeno site búlgaro, servidor de teste, site WordPress não crítico ou VPS experimental pode avaliar a Hosting27 através de testes de serviço comuns: peça um plano pequeno, teste o suporte, verifique a latência, restaure um backup e verifique o cancelamento. Um sistema crítico para o negócio não deve confiar apenas na tabela de planos. Deve obter respostas escritas sobre instalação, backups, diversidade de trânsito, contratação legal e portabilidade de dados antes de mover a produção.

A leitura final é equilibrada. A Hosting-27 Hosting-27 LTD é visível como um vendedor búlgaro de capacidade hospedada com AS42347 e uma plataforma Hosting27.com ao vivo. Sua história operacional pública não é vazia. Mas os fatos decisivos de infraestrutura permanecem atrás da camada de vendas.

Até que esses fatos sejam divulgados ou verificados em um contrato de cliente, a Hosting27 deve ser entendida como um provedor compacto de hospedagem e serviços de nuvem búlgaro cuja promessa ao cliente ainda depende de racks invisíveis, trânsito visível da Telehouse, estoque finito de IPv4, mão de obra de suporte, contratos de provedor e janelas de reparo.