LIVEHOSTING Data Center SRL precisa comprovar se a capacidade comercializada de seu data center pode sobreviver às restrições elétricas e de operadoras

Resumo

• LIVEHOSTING Data Center SRL se identifica publicamente como operador de um data center em Timisoara e como titular do AS41635. Suas páginas de vendas atuais oferecem hospedagem web, servidores virtuais e dedicados, gerenciamento de servidores e colocation 1U-3U.
• O perímetro de rede pública está ativo, não apenas registrado. RIPEstat observou 89.38.208.0/22 proveniente do AS41635 em 12 de julho de 2026, visível para os 326 peers IPv4 declarantes em seu instantâneo de status de roteamento, com AS12302 e AS39737 como redes adjacentes observadas.
• As evidências físicas são mais antigas. Um guia setorial romeno de 2012 mencionava uma sala de dados de 30 metros quadrados, duas fontes de alimentação trifásicas de 50 kW, um gerador a diesel de 100 kW e quatro no-breaks de 40 kW. Esses números constituem um histórico útil, mas não estabelecem o equipamento, a carga, a autonomia ou a redundância disponíveis em 2026.
• A página de colocation lista duas fontes de alimentação, um no-break, um gerador, proteção DDoS e uma porta de Internet de 1 Gbps. Ela não publica a separação de circuitos A/B, a autonomia de combustível do gerador, a redundância de refrigeração, as entradas de fibra, os compromissos das operadoras, os resultados de testes de manutenção ou um segundo site de recuperação.
• O nível de evidência de rede é Médio. Existem evidências convincentes de um serviço atual e de uma superfície operacional roteada, mas não evidências atuais e independentes suficientes para considerar a capacidade comercializada como mantida simultaneamente ou comprovadamente recuperável após uma falha da instalação ou de uma operadora.

A afirmação é suficientemente específica para ser testada

LIVEHOSTING Data Center SRL não se esconde atrás de um rótulo vago de nuvem. Suapágina de contato atualnomeia a empresa legal romena, fornece o número de registro J35/815/2010 e o código fiscal RO26963713, identifica AS41635 e indica que a empresa opera seu próprio data center em Timisoara. Suaoferta de colocationcoloca os equipamentos dos clientes nessa instalação e lista a proteção por no-break e gerador. Isso é mais concreto do que um revendedor que nunca identifica um site ou rede.

A especificidade cria um ônus de prova útil. Se um provedor declara operar a infraestrutura no nível do edifício por trás das cargas de trabalho dos clientes, a unidade relevante não é o servidor virtual exibido em uma página de preços. É a cadeia completa desde a chegada da rede elétrica até o no-break, o gerador, a distribuição elétrica, a refrigeração, o rack, o switch, o roteador de borda, o caminho da operadora e o técnico. Cada elo pode reduzir a capacidade que os clientes podem realmente usar em caso de falha.

O domínio público da empresa cobre vários tipos de dependências. Suapágina inicialoferece hospedagem Windows e Linux, servidores virtuais, servidores dedicados, colocation e gerenciamento de servidores. Os clientes de hospedagem compartilhada dependem de uma plataforma controlada pelo provedor. Os clientes de servidores virtuais dependem do design do host e do armazenamento que não podem inspecionar diretamente. Os clientes de servidores dedicados dependem do hardware, da comutação e do acesso remoto. Os clientes de colocation possuem mais o servidor, mas ainda dependem da instalação e da rede. Uma falha no nível comum de energia ou da transportadora pode, portanto, afetar produtos que parecem distintos no nível de faturamento.

A distinção chave é entre a evidência de operação e a evidência de resiliência. AS41635 e o catálogo de produtos atual fazem um caso convincente de que LiveHosting está em operação. Eles não mostram, por si só, qual carga sobrevive à perda de um caminho de alimentação, de uma cadeia de no-breaks, de uma unidade de refrigeração, de um roteador de borda ou de uma entrada de fibra. Esta segunda questão determina se um pequeno data center em Timisoara está simplesmente disponível em um dia comum ou recuperável em um dia difícil.

Um serviço atual por trás de uma pequena pegada pública

As evidências públicas apoiam uma atividade comercial real. LiveHosting publica preços para servidores virtuais, servidores dedicados e colocation, mantém páginas de conta de cliente e pedido, e expõe um contato para abusos de rede. Suapágina de servidores virtuais SSDlista seis configurações, enquanto suapágina NVMelista outras seis. Suas páginas de servidores dedicados anunciam sistemasHP ProLiant DL360 G7eG8com fontes de alimentação redundantes hot-swap e múltiplas interfaces de rede.

Essas páginas estabelecem uma superfície de vendas, não um inventário. Elas não dizem quantos hosts físicos estão instalados, quantos estão disponíveis para entrega imediata, qual proporção de CPU e memória está comprometida, ou se sistemas e discos de reposição são mantidos no local. Uma configuração pode permanecer encomendável enquanto o último chassi adequado está em uso, uma peça sobressalente está em reparo, ou novas fontes de alimentação não podem ser alocadas a um rack. Os compradores devem, portanto, tratar as configurações listadas como classes de serviço comercializadas, em vez de capacidade instalada auditada.

A pegada pública da empresa também parece pequena.O perfil da empresa no Termene.ro, um agregador de informações sobre empresas romenas, relata receita de 2024 de RON736.213, lucro líquido de RON286.410 e média de um funcionário. O LinkedIn, por outro lado, classifica a empresa na faixa de dois a dez funcionários e afirma ter atendido mais de 4.000 clientes desde 2006. Nenhuma dessas fontes prova o número atual de engenheiros disponíveis para um incidente noturno. Subcontratados, pessoal afiliado, técnicos das operadoras e pessoal do edifício podem todos estar fora de uma média legal ou faixa de mídia social.

Essa incerteza importa sem implicar que uma equipe pequena seja incapaz. Pequenos operadores podem ser tecnicamente disciplinados e receptivos. Eles também podem depender fortemente do conhecimento de um único administrador e de fornecedores cujos prazos de resposta fogem ao contrato do cliente. As evidências relevantes são um registro de serviço atual, um mecanismo de escalada, uma lista de acesso e um direito de suporte dos fornecedores. Os sinais públicos de efetivos apenas tornam essas questões mais importantes.

Timisoara é o local de serviço, mas não um plano de site completo

LiveHosting declara repetidamente que opera seu próprio data center em Timisoara. Seus contatos legais colocam a sede em Dumbravita, nos arredores da cidade, enquanto a página de colocation indica que o local de serviço é "LiveHosting data center Timisoara". São declarações compatíveis, mas não provam que a sede, a sala de dados e cada servidor anunciado estão no mesmo endereço.

A entrada de instalação do Data Center Mapdescreve uma instalação LiveHosting a menos de dois quilômetros do centro de Timisoara e indica que a localização exata não é pública. Sua página de ecossistema não relata dados de rede ou de provedor de serviços para o site. Data Center Map é um diretório comercial, não uma auditoria de engenharia, mas a ausência de um endereço exato público reforça uma fronteira importante: a cidade é suportada; a identidade do edifício e a estrutura de propriedade não são.

"Próprio data center" pode descrever vários arranjos. A empresa pode possuir a propriedade e todas as instalações mecânicas e elétricas. Pode possuir a sala de informática em um edifício alugado. Pode operar racks e comutação enquanto um proprietário controla a chegada elétrica, sistemas de incêndio ou refrigeração. Pode terceirizar a manutenção do gerador ou a segurança remota. Nenhum desses modelos é intrinsecamente deficiente. Eles criam diferentes direitos de recuperação e diferentes fornecedores de prazos.

Um cliente avaliando colocation deve solicitar uma matriz de responsabilidades. Ela deve identificar quem possui o edifício, quem opera cada etapa elétrica, quem mantém a refrigeração, quem controla o acesso físico, quem detém o contrato de combustível do gerador, quem possui a fibra externa e quem pode autorizar trabalho de emergência. Ela também deve distinguir a sede legal do endereço da instalação e de qualquer local de backup. Sem esse mapa, a expressão "próprio data center" é útil, mas incompleta.

A área de serviço é mais clara no nível de rede. AS41635 está registrado na Romênia, o produto é vendido em romeno, e um traceroute IPinfo alcançou um endereço no bloco de origem via Prime Telecom até um destino rotulado Timisoara em junho de 2026. Isso suporta uma entrega romena. Não prova que cada backup, serviço de monitoramento, sonda de vigilância ou cópia do cliente permanece na Romênia.

Um instantâneo detalhado de 2012 não pode certificar a instalação de 2026

A descrição pública mais específica da instalação física aparece no guiaData Center 2012da Market Watch. O guia indicava uma sala de dados de 30 metros quadrados, duas fontes de alimentação de transformador trifásico nominais de 50 kW cada, uma descrita como vindo da Electrica e a outra da CET, um gerador a diesel de 100 kW e quatro no-breaks de 40 kW cada. Ele também listava comunicações de 1 Gbps, servidores Dell, armazenamento e rede, monitoramento via PRTG e DRAC, e certificações ISO 9001 e ISO 27001.

Isso é uma evidência histórica valiosa, pois fornece escalas e topologias que o site atual não fornece. Também tem quatorze anos. O equipamento envelhece, as baterias são substituídas, a refrigeração é expandida, a cabeação é refeita, os contratos das operadoras mudam e as instalações se mudam. O guia pode ter capturado com precisão a descrição do fornecedor na época, enquanto diz pouco sobre a instalação que agora atende os clientes.

Os números também requerem interpretação. Duas fontes de alimentação nominais de 50 kW não significam necessariamente 100 kW de carga de TI resiliente. Se qualquer uma das fontes deve ser capaz de suportar toda a sala, a capacidade utilitária resiliente pode estar mais próxima da potência utilizável do caminho mais baixo após perdas e cargas não-TI. Um gerador de 100 kW não estabelece a carga de TI que ele pode suportar uma vez incluídas refrigeração, perdas do no-break, iluminação, bombas e correntes de partida. Quatro no-breaks de 40 kW não revelam se foram configurados em N, N+1, 2N ou em sistemas separados suportando cargas diferentes.

O site atual deve, portanto, ser lido em paralelo, e não fundido, com o guia de 2012. As páginas atuais provam que os produtos de colocation e servidor continuam sendo comercializados. O guia antigo mostra o que a empresa divulgou um dia. Nenhum documento público examinado aqui conecta os dados históricos a um diagrama unifilar elétrico atual, relatório de comissionamento, teste de carga, relatório de estado das baterias ou teste de autonomia de combustível. Até que apareçam, os números históricos são uma base de perguntas, não um certificado de capacidade atual.

Duas fontes de alimentação do servidor não provam dois caminhos de alimentação independentes

A tabela de colocation atual lista "2" sob fontes de alimentação para seus planos 1U, 2U e 3U. As páginas de servidores dedicados também anunciam fontes de alimentação duplas hot-swap de 750 W. Isso é um bom design no nível de componentes: um servidor pode continuar após a falha de um módulo de alimentação se o outro módulo e sua entrada permanecerem saudáveis. Mas a resiliência depende de onde os dois cabos de alimentação levam.

Se ambas as fontes de alimentação do servidor se conectam à mesma PDU do rack, a PDU permanece um ponto único de falha. Se duas PDUs se conectam à mesma saída de no-break ou ao mesmo quadro de distribuição, o caminho elétrico a montante permanece compartilhado. Se sistemas de no-break separados dependem de um único comutador de transferência ou gerador, uma falha nesse local pode derrubar ambas as alimentações aparentes. Mesmo conexões elétricas fisicamente separadas podem compartilhar uma subestação, um caminho de cabos ou um esquema de proteção fora do edifício.

É por isso que aexplicação do sistema de classificação Tier do Uptime Institutedistingue componentes redundantes da mantenabilidade simultânea e tolerância a falhas. Um segundo componente não é a mesma coisa que um segundo caminho de entrega. O artigo não atribui nenhum nível Tier ao LiveHosting; a página da empresa examinada aqui não reivindica, e o guia de 2012 explicitamente não forneceu classificação Uptime. O quadro só é útil para esclarecer quais evidências suportariam uma linguagem mais forte.

Para cada rack vendido como dupla alimentação, LiveHosting deveria poder mostrar os caminhos A e B desde a rede ou gerador através do quadro de distribuição, no-break, distribuição e PDU. Deveria indicar quais dispositivos permanecem com um único cabo e se comutadores de transferência são usados. Deveria publicar a potência máxima do rack, a capacidade do disjuntor, a carga estável permitida e o método de medição. A página de colocation indica que o consumo de eletricidade está incluído, mas não quantifica uma alocação de energia.

Essa omissão torna difícil traduzir um espaço 1U, 2U ou 3U em um compromisso elétrico seguro e comercialmente executável.

O teste mais importante não é um diagrama sozinho. É uma transferência controlada sob carga realista enquanto o equipamento do cliente permanece online, seguida de prova de que as baterias, o gerador, a refrigeração e o equipamento de rede se comportaram como esperado.

A presença de um gerador não é a mesma coisa que sua autonomia

A página de vendas atual lista um gerador, e o guia de 2012 relatava uma unidade a diesel de 100 kW. Um gerador pode cobrir uma longa interrupção da rede, mas apenas quando todo o sistema de suporte funciona: detecção automática, baterias de partida, equipamento de transferência, combustível, refrigeração, exaustão, manutenção, aceitação de carga e acesso para reabastecimento. A palavra "gerador" não divulga nenhuma dessas condições.

A autonomia é o primeiro número faltante. Um tanque pode suportar horas a carga parcial, mas muito menos a carga nominal. O consumo de combustível muda com a demanda elétrica, e a demanda da instalação inclui mais que servidores. A refrigeração deve continuar durante uma perda de rede; caso contrário, o gerador pode manter os equipamentos de TI ligados enquanto a temperatura da sala sobe para um desligamento forçado. Uma autonomia pública deve, portanto, indicar a carga crítica suportada, o combustível mínimo no local, o contrato de reabastecimento e as suposições sobre refrigeração.

Asdiretrizes sobre sistemas de combustível do Uptime Institutedescrevem uma expectativa de armazenamento mínimo de doze horas para topologias Tier na carga N declarada da instalação. Isso é um ponto de referência, não uma prova de que LiveHosting atende ou precisa adotar esse design exato. Um pequeno provedor pode escolher um objetivo de risco diferente. O que importa é que os clientes conheçam o objetivo e possam compará-lo com suas necessidades de recuperação.

Testes contam tanto quanto o tamanho do tanque. Uma partida mensal sem carga não prova que o gerador e o sistema de transferência suportarão a sala em um dia quente. Um registro significativo incluiria testes de transferência sob carga, duração, porcentagem de carga, qualidade do combustível, alarmes, partidas falhas e ações corretivas. Mostraria também se ambos os caminhos de transporte atuais e a monitoração externa permanecem disponíveis quando a energia da rede é cortada.

A consequência para o cliente é direta. Uma breve interrupção pode ser absorvida pelas baterias do no-break. Uma falha mais longa se torna um evento de gerador e combustível. Se o gerador falhar ou não puder suportar a refrigeração, todos os produtos na sala podem convergir para o mesmo prazo de desligamento, independentemente de quantas máquinas virtuais, conjuntos RAID ou fontes de alimentação de servidor existam.

A refrigeração determina quanta capacidade elétrica é utilizável

O material público examinado aqui não fornece um design de refrigeração atual, capacidade de refrigeração instalada, nível de redundância, layout de contenção ou faixa de operação ambiental. Essa ausência impede que um leitor converta os dados elétricos históricos em capacidade de TI utilizável. Quase cada watt consumido pelo equipamento de TI se torna calor que deve ser removido, e a sala pode ser limitada pela refrigeração antes de atingir um limite elétrico nominal.

O número de 30 metros quadrados relatado em 2012 também não diz nada sobre a densidade atual dos racks. Uma sala pequena com racks levemente carregados pode ser estável. A mesma sala preenchida com servidores biprocessadores, armazenamento denso ou comutação de alta velocidade pode desenvolver pontos quentes mesmo quando a potência total do edifício permanece dentro de um limite nominal. O catálogo de servidores dedicados inclui sistemas com múltiplos discos e processador duplo, enquanto o equipamento de colocation dos clientes é menos previsível. A alocação de capacidade deve considerar tanto o calor médio quanto a concentração local.

A redundância de refrigeração tem várias camadas: a unidade de refrigeração, o compressor ou fonte de água gelada, as bombas e ventiladores, o sistema de controle, a fonte de alimentação e o caminho de rejeição de calor. Uma refrigeração "N+1" ainda pode esconder tubulações comuns, dependências de controle ou elétricas. A manutenção pode ser mais reveladora que uma falha. Se uma unidade de refrigeração não pode ser isolada e mantida em um dia quente sem reduzir a sala abaixo de sua carga comprometida, a capacidade instalada excede a capacidade utilizável simultaneamente.

Um comprador deve solicitar as faixas de temperatura e umidade nas entradas do servidor, a localização dos sensores, os limites de alarme, os registros históricos, a margem em clima quente e o resultado de um teste de perda de unidade de refrigeração. A resposta deve explicar a política de desligamento automático e o aviso ao cliente se a temperatura aumentar. Também deve indicar se a capacidade do gerador inclui toda a refrigeração necessária para a carga de TI comprometida.

As implicações de incêndio e água seguem. Condensados, vazamentos de telhado ou encanamento podem afetar rapidamente uma sala compacta. A detecção e supressão de incêndio devem ser compatíveis com espaços ocupados e equipamentos elétricos energizados. O material público menciona segurança física e monitoração histórica, mas não fornece evidências atuais sobre compartimentação contra incêndio, detecção de vazamentos, supressão ou zona de inundação. Os clientes não devem deduzir esses controles apenas do rótulo de data center.

Capacidade instalada, vendável e recuperável são números diferentes

O provedor pode honestamente ter equipamento instalado enquanto tem menos capacidade disponível para novos clientes e ainda menos capacidade disponível em caso de falha. A capacidade instalada é a soma das placas de identificação e recursos configurados. A capacidade vendável é o que as regras comerciais e técnicas permitem após reservas e superprovisionamento. A capacidade recuperável é o que resta, ou pode ser restaurado dentro do prazo, após a falha de um componente definido.

As páginas públicas de LiveHosting anunciam CPU, memória, armazenamento SSD ou NVMe e tráfego "ilimitado" do servidor. Essas especificações descrevem um direito ou configuração de produto. Elas não mostram a ocupação do host, a replicação do armazenamento, a contenção do uplink ou a taxa de transferência de backup. O tráfego "ilimitado" é particularmente fácil de interpretar mal: pode significar ausência de cobrança por volume, enquanto cada pacote ainda compartilha uma porta, borda e compromisso de trânsito finitos.

O espaço de colocation também é incompleto sem potência e margem de rede. Três clientes 1U podem consumir menos energia que um cliente 3U, ou muito mais, dependendo do hardware. Uma porta de 1 Gbps é uma taxa de interface, não uma taxa de Internet garantida em caso de ataque ou após falha de uma operadora. Uma placa de identificação de gerador não é um compromisso de capacidade do cliente. Uma potência de no-break não é uma garantia de autonomia.

A medida operacional que importa é o orçamento em estado de falha. Quantos quilowatts permanecem se um caminho de alimentação é isolado? Qual temperatura da sala pode ser mantida após a perda de uma unidade de refrigeração? Qual capacidade de Internet permanece se Prime Telecom ou Vodafone ficar indisponível? Quantos servidores virtuais podem ser reiniciados a partir do backup ao mesmo tempo? Quantos engenheiros podem gerenciar simultaneamente incidentes de hardware, rede e clientes?

Esses números devem ser vinculados às classes de clientes. A hospedagem compartilhada pode tolerar um tempo de recuperação diferente de um site do setor público, uma aplicação transacional, um servidor de e-mail ou um sistema empresarial em colocation. Uma pequena instalação não precisa de capacidade hyperscale para ser útil. Ela precisa de compromissos adaptados à sua redundância real e uma recusa clara de vender além do envelope em estado de falha.

AS41635 está ativo e visível globalmente

As evidências de rede são a parte mais sólida do dossiê público.RIPE RDAPlista AS41635 como ativo e nomeia LIVEHOSTING-AS.A visão geral AS do RIPEstatidentifica o titular como LIVEHOSTING Data Center SRL e marca o ASN como anunciado. Isso corresponde à página de contato da própria empresa.

Em 12 de julho de 2026,o status de roteamento do RIPEstatmostrava um prefixo IPv4 originário contendo 1.024 endereços e nenhum prefixo IPv6 originário. A rota IPv4 era visível para os 326 peers IPv4 declarantes naquele instantâneo.A visualização de prefixos anunciados do RIPEstatidentificava 89.38.208.0/22 como o anúncio atual. A visualização do histórico de roteamento rastreia o espaço de endereçamento originário da LiveHosting desde 2006, embora o agregado tenha passado de um /21 para o /22 atual ao longo do tempo.

Isso é uma evidência operacional significativa. Uma rota amplamente visível mantida ao longo de anos é incompatível com um registro ASN puramente decorativo. O prefixo hospeda o próprio site da empresa e nomes de servidores públicos, e agregadores independentes também o identificam.O kit de ferramentas BGP da Hurricane Electricrelatava um prefixo IPv4, 1.024 endereços IPv4 originários, dois peers IPv4 observados e nenhuma origem IPv6.IPinfoclassifica o ASN como hospedagem e mostra um caminho de junho de 2026 alcançando o bloco via AS39737.

A rota também é RPKI válida.A validação RIPEstatencontrou uma autorização válida para AS41635 originar 89.38.208.0/22 com comprimento máximo /22. Comoexplica o RIPE NCC, a validação de origem responde se o detentor legítimo do recurso autorizou uma combinação prefixo-origem particular. Ela não valida o resto do caminho AS nem prova resiliência física.

A conclusão deve ser restrita: LiveHosting tem uma origem IPv4 atual, válida e altamente visível. Isso é mais forte que um cartão de marketing. Ainda não pode mostrar se os roteadores são duplicados, se as operadoras entram por dutos separados, ou se o caminho sobrevivente pode suportar a demanda do cliente após uma falha.

Os dois caminhos de operadora visíveis ainda precisam de evidências físicas

A visualização de vizinhos AS do RIPEstatobservou duas redes adjacentes em 12 de julho de 2026: AS12302, Vodafone Romênia, e AS39737, Prime Telecom. O instantâneo de estado BGP mostrava a grande maioria dos caminhos amostrados via Prime Telecom e um número menor via Vodafone. A Hurricane Electric listava independentemente os mesmos dois peers.

Duas adjacências observadas são melhores que uma, pois oferecem alternativas de rota potenciais. Elas não devem ser chamadas de duas operadoras independentes comprovadas sem contrato e evidências de site. Um coletor de rotas observa caminhos AS, não propriedade de fibras, entradas de edifício, interconexões ou capacidade paga. Uma operadora pode revender outra. Dois circuitos podem compartilhar um duto metropolitano, um poço de visita, uma passagem de rua, um painel de conexão ou o mesmo equipamento externo energizado.

O objeto de registro RIPE adiciona outra razão para cautela. Sua política de importação, última modificação em 2021, nomeia AS6830 e AS34279, enquanto os coletores atuais veem AS12302 e AS39737. Essa diferença pode simplesmente refletir uma política de registro desatualizada após mudanças ordinárias de operadoras. Demonstra por que uma declaração de registro não deve substituir uma observação atual ou um cronograma de operadora atual.

A capacidade pós-falha é o próximo problema. Se o caminho principal transporta a maior parte do tráfego, o secundário deve ter capacidade comprometida e de rajada suficiente para absorvê-lo. O BGP pode reconvergir com sucesso enquanto as aplicações se tornam inutilizáveis porque o circuito restante está congestionado. A proteção DDoS adiciona outra dependência: o provedor deve explicar onde a filtragem ocorre, se ambos os uplinks a suportam, como as rotas são desviadas e se um evento de proteção reduz a capacidade líquida.

As evidências requeridas são práticas. LiveHosting deve identificar ambas as operadoras contratadas, os tamanhos de porta e compromisso, as demarcações físicas, os caminhos de entrada, os roteadores de borda e os domínios de alimentação. Deve mostrar um teste recente onde cada uplink foi removido separadamente sob carga ocupada, registrar a convergência e perda de pacotes, e confirmar que o monitoramento e as comunicações com os clientes permaneciam acessíveis.

Ausência de perfil PeeringDB reduz o que pode ser verificado publicamente

Uma consulta àAPI do PeeringDBnão retornou nenhuma entidade de rede para AS41635 neste exame. Isso não é evidência de falha de rede. A participação no PeeringDB é voluntária, e uma pequena rede de hospedagem pode comprar trânsito sem manter um perfil de interconexão público. A ausência reduz a visibilidade pública sobre instalações, trocas, níveis de tráfego, política de peering e contatos de rede.

A forma atual parece mais orientada a trânsito do que a troca. Os coletores públicos expõem duas redes adjacentes, mas nenhum registro PeeringDB público identifica uma troca de Internet ou conexão de instalação. Os clientes devem, portanto, evitar assumir que a rede possui peering direto, rotas de troca diversificadas ou uma sala de reunião neutra. Essas características podem existir; o dossiê público examinado aqui não as estabelece.

Isso importa para o isolamento de falhas. Se todos os caminhos externos dependem de um pequeno conjunto de entregas de trânsito em um único edifício, o ponto de encontro local da operadora pode ser um ponto comum de falha mesmo quando a tabela de rota global mostra dois ASNs de upstream. Se um circuito termina fora do local e alcança a sala de dados através de uma fila local compartilhada, a diversidade lógica pode desaparecer no último quilômetro.

O provedor pode resolver grande parte dessa incerteza sem expor detalhes sensíveis. Pode publicar um diagrama de rede neutro para a instalação mostrando entradas separadas, equipamentos de borda separados, identidades das operadoras, capacidades das portas e política de failover. Pode manter um perfil PeeringDB atualizado, se apropriado. Pode oferecer um looking glass ou um serviço de status hospedado externamente. Nenhuma dessas medidas prova cada duto, mas juntas tornam o modelo operacional da rede mais fácil de verificar.

A ausência de origem IPv6 merece uma resposta direta

A página de colocation da LiveHosting indica que uma sub-rede IPv6 /56 está incluída em cada plano. No entanto, RIPEstat e Hurricane Electric mostravam zero prefixo IPv6 originado por AS41635 nos instantâneos de julho de 2026. O regulador francês de telecomunicações, ARCEP, também listava AS41635 com exposição IPv6 zero em suas medições de 2025 sobre hospedeiros. Essas observações não provam que os clientes não recebem nenhum serviço IPv6.

O /56 anunciado pode vir do espaço de endereçamento de um provedor upstream e ser roteado para LiveHosting sem que AS41635 origine um prefixo IPv6. Pode estar disponível apenas sob demanda. Pode estar configurado dentro da instalação mas não visível nos dados públicos amostrados. Cada explicação tem uma consequência de resiliência diferente.

O IPv6 atribuído pelo provedor pode funcionar bem, mas o failover pode depender do provedor atribuidor. Se o /56 pertence a uma operadora e essa operadora falha, LiveHosting pode não ser capaz de anunciar a mesma sub-rede do cliente através do outro caminho. Renumerar um parque de servidores durante um incidente não equivale a um failover BGP. Os DNS, regras de firewall, listas de acesso e software do cliente podem todos reter os endereços antigos.

O comprador deve perguntar qual agregado contém o /56, qual ASN o origina, se é acessível através de ambos os uplinks visíveis e se a autorização de origem da rota cobre a origem pretendida. Também deve perguntar se a porta de 1 Gbps e a proteção DDoS se aplicam igualmente ao IPv4 e ao IPv6. Um serviço dual-stack é tão resiliente quanto a pilha menos testada quando as aplicações e o DNS publicam ambas.

A lacuna é importante porque o IPv6 não é um recurso decorativo. A página de colocation o apresenta como capacidade incluída. As evidências de rota públicas tornam a superfície operacional IPv4 clara; evidências IPv6 equivalentes transformariam o /56 de uma linha de venda em um serviço de rede verificável.

O compromisso de qualidade é mais restrito que uma garantia de instalação

Ocompromisso de qualidadeda LiveHosting se aplica aos planos de hospedagem web Windows ou Linux Standard, Business e Reseller. Ele define disponibilidade como a proporção mensal durante a qual o site de um cliente está acessível via HTTP a partir de um local neutro. A página afirma que a LiveHosting usa sistemas PRTG em seu data center e em outros data centers romenos e estrangeiros para medir a disponibilidade.

A escala de crédito reembolsa 50% quando a disponibilidade está entre 98% e 99,5%, 75% entre 95% e 97,9% e 100% a 94,9% ou menos. Um crédito de serviço é comercialmente útil, mas não é uma compensação por vendas perdidas, dados ou reputação. Mais importante, o escopo declarado não cobre automaticamente servidores virtuais, servidores dedicados ou colocation. Os compradores dessas categorias precisam de seus próprios termos de serviço.

As exclusões são amplas. A página exclui, entre outros, interrupção de comunicação, incêndio, inundação, desastres naturais, vírus, atacantes, software de terceiros, manutenção anunciada ou crítica, upgrades de servidor, DNS fora do controle da LiveHosting e vários protocolos de acesso. Algumas exclusões descrevem exatamente os caminhos de falha que um cliente de data center mais precisa entender. Excluí-los dos créditos não os torna improváveis; isso desloca seu custo econômico para o cliente.

A definição de medição também foca na acessibilidade HTTP. Um site pode responder enquanto e-mail, conexões de banco de dados, armazenamento, painéis de controle, acesso VPN ou um caminho de operadora estão degradados. Inversamente, uma falha de aplicação pode fazer o HTTP falhar enquanto a energia e a rede da instalação permanecem saudáveis. Os clientes precisam de medições no nível de componentes e um histórico de incidentes que separe as causas de instalação, rede, computação, armazenamento e aplicação.

Um conjunto de garantia mais forte publicaria o desempenho histórico do serviço por produto, minutos de manutenção, causas de incidentes e tempos de recuperação. Indicaria quais locais de monitoramento são independentes do AS41635 e se o canal de status permanece acessível durante uma falha total da instalação ou rota.

O tempo de resposta não é o tempo de recuperação

A página de qualidade promete um tempo de resposta máximo do suporte técnico de 24 horas durante o horário de segunda a sexta, das 10h às 18h. A página de contato atual lista suporte técnico de segunda a sexta, das 10h às 17h. Essas páginas podem descrever canais diferentes ou simplesmente estar desalinhadas. De qualquer forma, nenhuma das declarações é uma promessa de restaurar o serviço em 24 horas.

Apágina de gerenciamento de servidoresadiciona uma distinção comercial mais granular. O gerenciamento básico inclui duas horas por mês e disponibilidade durante a semana. O gerenciamento Premium inclui quatro horas por mês e indica disponibilidade de segunda a domingo, 24 horas por dia. Ocontrato de serviçospúblico afirma que o trabalho de gerenciamento é limitado às horas da assinatura adquirida, que o trabalho extra é faturado e que a disponibilidade ou desempenho de aplicações não são garantidos pelo serviço de gerenciamento.

Isso deixa várias perguntas para clientes dedicados não gerenciados e de colocation. A intervenção de emergência da instalação é contínua mesmo quando o gerenciamento do servidor não é? Quem reconhece um alarme de energia, refrigeração ou rede às 3h da manhã? Mãos remotas estão disponíveis a qualquer momento, e qual é o objetivo de chegada? A página de colocation precifica mãos remotas a 25 EUR por hora, mas não publica um compromisso de resposta 24 horas.

A distinção é crítica em uma pequena operação. A detecção pode ser automática, mas o diagnóstico e a autorização podem depender de uma pessoa. Uma operadora pode exigir o contato designado do cliente. Um edifício pode restringir o acesso após o horário comercial. Um servidor com falha pode ter fonte de alimentação dupla, mas ainda exigir substituição local de disco ou cabo. Cada transferência adiciona tempo antes do início da recuperação.

Os clientes devem solicitar quatro relógios separados: alarme-reconhecimento, reconhecimento-diagnóstico qualificado, diagnóstico-intervenção no local e intervenção-recuperação. Devem perguntar quem possui cada relógio e o que acontece quando dois incidentes ocorrem simultaneamente. Um número de telefone e uma promessa de ticket são pontos de entrada úteis; não é um plano de recuperação.

A manutenção pode expor mais riscos que uma falha repentina

A redundância parece frequentemente mais forte quando tudo está saudável e mais fraca quando um componente é deliberadamente removido para manutenção. As baterias dos no-breaks precisam ser substituídas, os geradores precisam ser testados sob carga, o equipamento de refrigeração precisa ser limpo, os switches precisam ser atualizados e as operadoras precisam de janelas de manutenção. Durante esses períodos, o caminho restante pode suportar a carga total sem reserva.

O compromisso de qualidade exclui manutenção anunciada, trabalhos críticos e upgrades de servidor de seus créditos. Isso é comum em contratos de hospedagem, mas o risco prático depende de como a manutenção é projetada. Um cliente precisa saber se a instalação pode manter cada componente crítico sem interromper a carga de TI, se vários fornecedores podem trabalhar ao mesmo tempo e como o rollback é gerenciado.

Para a energia, as evidências de manutenção devem incluir caminhos de bypass e procedimentos que não coloquem toda a sala na rede bruta. Para a refrigeração, deve indicar a carga máxima segura com uma unidade isolada. Para o trabalho de rede, deve mostrar que as rotas dos clientes permanecem estáveis através do outro roteador e operadora. Para armazenamento ou virtualização, deve quantificar quanta carga de trabalho pode ser movida antes da manutenção e quanto tempo essa movimentação leva.

A concentração de mudanças é outra preocupação. Um pequeno provedor pode planejar várias tarefas na mesma janela para reduzir interrupções, mas acoplar mudanças de energia, rede e host remove opções de recuperação independentes. Os clientes devem perguntar se as aprovações de mudança consideram dependências comuns e se um canal de comunicação acessível externamente é mantido fora dos sistemas afetados.

As evidências que resolveriam a questão são documentos operacionais ordinários: um calendário de manutenção anual expurgado, avisos de janelas recentes, relatórios pós-manutenção, ações em caso de falha de teste e um impacto visível pelo cliente. Isso é mais convincente que um objetivo geral de disponibilidade porque mostra como o operador gerencia os períodos em que a redundância é intencionalmente reduzida.

Incêndio, inundação e perda de rede convergem para os dados do cliente

O compromisso de qualidade menciona explicitamente incêndio e inundação entre as exclusões de força maior. Isso é uma alocação contratual, não uma prova de que a instalação está exposta ou desprotegida. As páginas públicas examinadas aqui não especificam o sistema atual de detecção e supressão de incêndio, a classificação de compartimentos, a detecção de vazamentos, a avaliação de inundação ou a distância de riscos de água e combustível.

Isso importa mais quando muitas camadas de serviço ocupam um único local. Hospedagem compartilhada, VPS, servidores dedicados, colocation, DNS, e-mail e portais de clientes podem todos depender da mesma sala. Se os dados primários, backups e sistemas de controle compartilham a instalação, um evento no edifício pode derrubar o serviço de produção e os meios de restaurá-lo.

O contrato de serviço público coloca uma responsabilidade significativa sobre os clientes e limita as garantias. Também permite a suspensão ou remoção do serviço por falta de pagamento e reserva direitos extensos para modificar ou interromper serviços. Essas condições tornam backups independentes e procedimentos de exportação testados comercialmente importantes mesmo na ausência de um incidente físico.

Um cliente deve identificar onde cada cópia reside, quem controla suas credenciais, com que frequência é testada e como a restauração funciona se o próprio portal de conta ou rede da LiveHosting estiver indisponível. Um backup em outro servidor na mesma sala protege contra certas falhas de hardware, mas não contra eventos de energia, refrigeração, incêndio ou inundação em toda a sala. Uma cópia em outro edifício, mas administrada através do mesmo sistema de identidade inacessível, também pode ser difícil de usar.

Para clientes de colocation, a questão se estende à recuperação do equipamento. Quem pode entrar após um incidente? O hardware do cliente é segurado pelo provedor, pelo operador do edifício ou pelo cliente? Um cliente pode recuperar seu equipamento durante um fechamento prolongado de serviço ou acesso? As respostas podem estar em contratos individuais, mas não são estabelecidas pela página de planejamento público.

A falha afeta diferentes clientes de maneiras diferentes

Clientes de hospedagem compartilhada provavelmente sentirão primeiro uma falha de plataforma comum como sites, e-mail ou painéis de controle inacessíveis. Eles podem ter pouca visibilidade sobre qual servidor físico, switch ou sistema de armazenamento falhou. Revendedores podem amplificar o impacto porque uma conta pode representar muitos sites downstream e obrigações de suporte.

Clientes de servidores virtuais têm mais controle sobre os sistemas operacionais, mas permanecem dependentes da capacidade do hypervisor, armazenamento e rede local do provedor. Uma falha de host pode ser recuperável se as cargas de trabalho puderem reiniciar em outro lugar, mas a página de produto pública não promete migração ao vivo, armazenamento replicado ou cluster de recuperação. A presença de SSD ou NVMe não diz nada sobre o número e localização das cópias.

Clientes de servidores dedicados evitam alguns riscos de computação compartilhada. Eles ainda dependem do rack, dos dois caminhos de alimentação, da comutação, do trânsito da operadora e de mãos remotas. Fontes de alimentação duplas e RAID podem absorver algumas falhas de componentes selecionados, mas não podem sobreviver a uma falha em toda a sala ou a uma falha da borda de rede compartilhada. As listas de servidores dedicados públicas também mostram gerações G7 e G8 mais antigas; isso pode ser uma oferta econômica, mas os compradores devem perguntar sobre a disponibilidade de sistemas e componentes sobressalentes.

Clientes de colocation possuem seu próprio equipamento e podem anunciar seu próprio espaço de endereçamento, como a página de produto permite para anúncios BGP. Sua dependência da LiveHosting é, no entanto, física. Eles precisam de acesso, energia, refrigeração, interconexões, roteamento e ajuda para reparos. Uma falha na instalação pode derrubar um equipamento que de outra forma é totalmente gerenciado pelo cliente.

Usuários dos setores público, saúde, financeiro ou industrial também podem enfrentar obrigações além da disponibilidade. Localização, notificação de incidentes, retenção de evidências e continuidade do provedor podem contar. O artigo não identifica nenhum cliente LiveHosting desse tipo. Ele ressalta por que a mesma afirmação de instalação pode ter consequências muito diferentes dependendo da carga de trabalho colocada nela.

O provedor deve, portanto, resistir a uma declaração universal de resiliência. Deve divulgar quais proteções se aplicam a cada serviço, o que o cliente deve fornecer e quais dependências compartilhadas atravessam todas as linhas de produtos.

Uma demonstração significativa de failover deve remover dependências reais

A melhor maneira de estabelecer a resiliência atual é testar falhas definidas em vez de acumular rótulos. Para LiveHosting, cinco exercícios responderiam à maioria das perguntas em aberto.

Primeiro, remover a energia normal da rede sob uma carga de produção representativa. Registrar a transferência do no-break, a partida do gerador, a continuidade da refrigeração, o consumo de combustível, alarmes e impacto no cliente. Continuar por tempo suficiente para demonstrar o objetivo de autonomia publicado e, em seguida, restaurar a rede sem perder a carga.

Segundo, isolar cada caminho de distribuição elétrica e seção de no-break por vez. Confirmar que os dispositivos do cliente com cabo duplo permanecem online e identificar o equipamento com cabo único que requer um dispositivo de transferência. Um teste de gerador bem-sucedido não substitui este teste de distribuição interna.

Terceiro, remover uma unidade de refrigeração ou caminho de refrigeração durante um período ambiente exigente. Acompanhar as temperaturas de entrada do servidor e confirmar qual carga permanece dentro do limite ambiental declarado da instalação. Isso converte uma afirmação de redundância de refrigeração em evidência de capacidade utilizável.

Quarto, remover Vodafone e Prime Telecom separadamente enquanto a rede está ocupada. Medir a convergência BGP, perda de pacotes, latência e taxa de transferência sobrevivente tanto no IPv4 quanto no serviço IPv6 anunciado. Confirmar que a proteção DDoS, o monitoramento, o DNS e a comunicação com o cliente funcionam no caminho restante.

Quinto, restaurar uma conta de hospedagem compartilhada representativa, um servidor virtual e um serviço de controle a partir de uma cópia fora do domínio de falha principal. Medir o tempo de recuperação e a perda de dados, e incluir o caso em que o portal do cliente normal está indisponível.

Os resultados não precisam ser perfeitos para serem valiosos. Uma fraqueza divulgada seguida de ação corretiva é uma evidência mais forte do que uma afirmação não testada de disponibilidade total. Os clientes podem então julgar se a recuperação demonstrada corresponde à sua própria tolerância e se precisam de um segundo local independente.

O crescimento da energia e as licenças devem ser tratados como restrições, não suposições

O mercado europeu de data centers trata cada vez mais a disponibilidade de eletricidade como uma restrição de desenvolvimento. Apágina de desempenho energético da Comissão Europeiadescreve a crescente demanda de eletricidade, impactos na refrigeração e água, e obrigações de relatório para instalações que excedem o limite relevante. Nada nas evidências públicas examinadas aqui estabelece que LiveHosting ultrapassa o limite de relatório de 500 kW; os números históricos sugerem uma instalação muito menor.

A pequena escala não elimina a necessidade de gerenciar a energia. Ela muda o problema. Um local compacto pode ter demanda total menor, mas menos espaço para adicionar quadros de distribuição, refrigeração, baterias, exaustão ou armazenamento de combustível. Um edifício urbano ou suburbano pode enfrentar restrições de ruído, emissões, segurança contra incêndio e construção. Uma conexão elétrica pode ser suficiente para a carga atual, mas tornar a expansão lenta ou cara.

O site atual não publica expansão planejada, novo edifício ou solicitação de eletricidade. Os compradores não devem inferir uma. Se LiveHosting comercializar nova capacidade de alta densidade, as evidências devem identificar se ela vem de eficiência melhorada, equipamentos mais antigos desativados, alocação elétrica maior, nova refrigeração ou outro local. A palavra "disponível" deve significar que energia, refrigeração e rede estão todas comissionadas, não apenas que o espaço do rack está vazio.

As licenças também afetam a recuperação. Substituir um gerador, adicionar armazenamento de combustível, modificar o serviço elétrico ou alterar sistemas de incêndio pode exigir aprovações e prazos de fornecedores. O cliente não precisa de cada número de licença em público. Ele precisa da garantia de que o equipamento instalado é autorizado, mantido e suportado, e que o crescimento planejado não colocará a sala existente em um estado de redundância reduzida prolongado.

A medida comercial apropriada é a capacidade pronta para uma falha definida, não o espaço teórico para outro servidor.

O que aumentaria a confiança

LiveHosting pode mover o nível de evidência para cima com um conjunto compacto de divulgações. Deve começar com uma ficha técnica atual da instalação datada e versionada pelo operador. A ficha deve indicar o endereço de serviço em um nível apropriado, os limites do operador e proprietário, a área da sala de dados, a carga de TI comissionada, o pico medido atual, os limites de potência dos racks, a topologia de refrigeração e os controles de incêndio.

A seção de energia deve mostrar as entradas elétricas, a topologia dos no-breaks, a potência do gerador, a autonomia mínima na carga crítica comprometida, os arranjos de combustível e a data e resultado do último teste de transferência sob carga. Deve distinguir as potências nominais totais instaladas da capacidade N útil, da capacidade em estado de manutenção e em estado de falha.

A seção de rede deve reconciliar as observações atuais da Vodafone e Prime Telecom com o objeto de política RIPE mais antigo. Deve divulgar a capacidade contratada das portas e compromisso, a diversidade dos roteadores de borda, a separação das entradas físicas, os arranjos de DDoS e a origem do /56 IPv6 anunciado. Uma entrada PeeringDB ou um looking glass atual melhoraria a visibilidade externa, mas não substituiria a documentação física.

A seção de operações deve indicar a propriedade contínua dos alarmes, os objetivos de resposta da instalação, a cobertura de mãos remotas, os estoques de peças de reposição e a escalação de fornecedores. Deve reconciliar as declarações de suporte das 10h às 17h e das 10h às 18h e esclarecer o que a disponibilidade Premium 24/7 significa para resposta e recuperação.

Finalmente, o operador deve publicar evidências anonimizadas de testes e incidentes: transferência elétrica, perda de unidade de refrigeração, failover de operadora, exercícios de restauração, manutenção significativa e lições aplicadas. A certificação independente pode reforçar o conjunto quando o escopo e a validade atual são claros. Os nomes de certificação de 2012 não devem ser tratados como atuais sem certificados, locais, normas e datas de expiração.

Esse nível de divulgação não exporia dados dos clientes nem plantas baixas sensíveis. Permitiria que os compradores distinguissem um pequeno data center funcional com limites testados de um cuja resiliência é inferida principalmente de rótulos de produtos.

O nível de evidência é Médio

LIVEHOSTING Data Center SRL obtém um nível de evidência de rede e infraestrutura Médio. As evidências operacionais específicas da empresa são substanciais: um site de vendas romeno atual, uma entidade legal nomeada, uma oferta explícita de colocation em Timisoara, AS41635, uma rota IPv4 visível globalmente, duas redes adjacentes observadas, uma autorização de origem de rota válida e anos de histórico de roteamento. Não é um caso em que a existência do provedor ou a operação básica de rede dependa de uma única entrada de diretório.

O nível para em Médio porque as afirmações de resiliência não são acompanhadas de evidências físicas atuais. O no-break e o gerador estão listados, mas a topologia e autonomia estão ausentes. Duas fontes de alimentação do servidor estão listadas, mas a separação A/B não. Um guia de 2012 oferece dados detalhados, mas nenhuma evidência de comissionamento ou carga atual conecta esses números à instalação de 2026. Refrigeração, incêndio, inundação, entradas de fibra, compromissos das operadoras, desempenho de manutenção, recuperação externa e resultados de failover do cliente permanecem não divulgados nas fontes examinadas.

As duas adjacências BGP atuais suportam diversidade de caminho lógico, enquanto a ausência de evidência física de rota impede uma conclusão mais forte. A rota IPv4 válida reduz o risco de origem, enquanto a ausência de origem IPv6 do AS41635 deixa o arranjo /56 anunciado não resolvido. O compromisso de qualidade dá aos clientes um mecanismo de medição e crédito, enquanto seu escopo de produto e exclusões limitam o que ele diz sobre a recuperação em toda a instalação.

Esse nível não é um veredito sobre a qualidade do serviço. É uma declaração sobre a distância entre o que pode ser observado e o que ainda precisa ser demonstrado. LiveHosting pode possuir registros de engenharia atuais mais fortes do que publica. Um comprador deve solicitar vê-los antes de colocar uma carga de trabalho cujo custo de falha excede o valor dos créditos de serviço.

A conclusão restrita é que a capacidade comercializada é crível como serviço ao vivo, mas ainda não provada como capacidade em estado de falha. A próxima evidência útil não é outra configuração de servidor. É um teste atual de energia, refrigeração e transporte mostrando o que permanece online quando uma das dependências comuns é deliberadamente removida.