tsbg_hosting TSBG Hosting Ltd. vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A TSBG Hosting Ltd. apresenta-se como uma operadora de infraestrutura búlgara fundada em 2006, oferecendo colocation, servidores cloud, servidores dedicados, hospedagem compartilhada, streaming e serviços gerenciados em seu próprio site.
• As afirmações operacionais mais fortes da empresa são físicas, não puramente virtuais: várias instalações de data center neutras em relação a operadoras na Bulgária, quatro datacenters, design orientado pela TIA-942, energia A/B, monitoramento, mãos remotas, detecção de incêndio, refrigeração e acesso escoltado.
• O sinal público de rede atual é fraco.RIPE RDAPidentifica AS43112 como tsbg_hosting e registra TSBG Hosting Ltd. como registrante, masstatus de roteamento do RIPEstatmostrou zero espaço anunciado IPv4 ou IPv6 para AS43112 em 12 de julho de 2026.
• O recurso 193.3.63.0/24 da TSBG permanece relevante porqueo RIPE RDAP para o prefixoidentifica BG-TSBGHOSTING-20200902, ea validação RPKI do RIPEstatvalidou AS43112 como autorizado para esse prefixo. Autorização não é o mesmo que alcance ao vivo.
• O registro da instalação TSBG Hosting no PeeringDBadiciona uma pista física em Haskovo/Svilengrad, enquantoos dados de rede-instalação do PeeringDBvinculam o attachment listado ao AS47288/FixNET em vez de AS43112. Isso reforça a necessidade de verificar os limites da operadora antes de confiar em qualquer alegação de resiliência.
• O grau de evidência é Fraco. O site oficial fornece ricas alegações de serviço, mas as evidências públicas de roteamento atuais não provam de forma independente tráfego de clientes ao vivo no AS43112, failover multi-site, diversidade de trânsito, capacidade ociosa ou portabilidade de dados.

Uma fatura de nuvem ainda chega a uma sala de máquinas búlgara

A TSBG Hosting Ltd. não é um nome que possa ser avaliado pelo reconhecimento da marca. Tem que ser avaliado rastreando o serviço até o equipamento e as pessoas que manteriam um cliente online. A empresa vende serviços que parecem elásticos: servidores cloud, planos VPS, servidores dedicados, hospedagem compartilhada, streaming, colocation e suporte gerenciado. Mas cada um desses serviços tem um inventário físico por trás. Um servidor virtual precisa de capacidade do host, armazenamento, comutação, energia e refrigeração. Um servidor dedicado precisa de um chassi específico e um plano de substituição.

Colocation precisa de um rack, um orçamento de energia, rotas de cabos, controle de acesso e mãos remotas. Streaming precisa de capacidade de entrada, transcodificação ou handoff e largura de banda de saída suficiente para carregar o público quando a demanda aumenta.

O fato útil sobre a TSBG é que a empresa não se descreve apenas em linguagem vaga de nuvem. Apágina inicial oficialcomercializa colocation, servidores dedicados, servidores virtuais, streaming e colocation de antena de satélite. A mesma página descreve quatro datacenters neutros em relação a operadoras e dezesseis anos de experiência, e diz que a TSBG pode suportar nuvem privada, sites de recuperação de desastres, acesso dedicado à Internet, endereços IPv4, fonte de alimentação DC e downlink de satélite. Essas afirmações dão ao comprador uma lista concreta para testar: edifícios, racks, domínios de energia, fibras, upstreams, servidores, recursos de endereço e arranjos de suporte.

O risco é que os detalhes de marketing público ainda podem ultrapassar as evidências operacionais verificáveis. Um provedor pode possuir racks, mas terceirizar alguns caminhos de rede. Pode ter um ASN válido, mas não anunciá-lo atualmente. Pode publicar um menu de serviços enquanto planos individuais dependem de estoque disponível, suporte do fornecedor ou uma instalação de terceiros. Pode oferecer um site de recuperação enquanto o contrato do cliente deixa os objetivos de recuperação vagos.

Para a TSBG, o registro público contém exatamente essa mistura: uma história de serviço específica, uma identidade búlgara específica, um número AS específico e uma lacuna entre o registro de recursos numéricos e a origem de rota visível na data de publicação.

Essa lacuna não torna a TSBG não confiável. Ela muda o ônus da prova. Um cliente não deve tratar a lista de preços do site ou o ASN como um relatório de garantia. O cliente deve perguntar qual instalação abriga a carga de trabalho, qual borda de rede anuncia o serviço, qual fornecedor tem trânsito com capacidade padrão, quanta energia e hardware sobressalente estão reservados e como os dados saem da plataforma se o serviço precisar ser movido.

O que pode ser identificado com confiança

A identidade da empresa é mais forte do que o instantâneo inicial do diretório sugeria. O site da TSBG diz que a empresa foi fundada em 2006, é incorporada sob a lei búlgara, lista o número de IVA da UE BG175059953, nomeia Ivan Shishkov como diretor administrativo e dá um endereço de escritório em Sofia na Rua Racho Dimchev, 8. Apágina de contatorepete o endereço de Sofia, número de telefone e e-mail de vendas.RIPE RDAP para AS43112identifica o nome do objeto como tsbg_hosting e inclui TSBG Hosting Ltd. como uma entidade organizacional com um endereço em Sofia.Dados whois do RIPEstatregistram aut-num 43112, as-name tsbg_hosting, organização ORG-THL32-RIPE, status ASSIGNED e maintainer mnt-bg-tsbghosting-1.

Esses registros são suficientes para evitar um erro comum na pesquisa de hospedagem: tratar um nome de serviço como um rótulo flutuante sem titular responsável. Aqui, o titular pode ser vinculado a uma identidade de empresa búlgara, uma superfície de contato, um registro de recurso numérico e um site de serviço visível. Isso é mais útil do que uma página de revendedor sem endereço e sem registro de roteamento.

O escopo do serviço também é específico. Apágina de colocationda TSBG anuncia pacotes de unidade de rack única, quarto de rack, meio rack e rack completo, com quantidades de energia declaradas variando de 35 W para uma unidade de rack a 1500 W para um rack completo. A página também diz que a empresa pode fornecer conectividade à Internet, endereços IPv4 e serviços LIR. Apágina de servidores cloudlista planos VPS, armazenamento SSD, proteção RAID10, Internet compartilhada de 1 Gbit/s e backups opcionais. Apágina de servidores dedicadosdescreve fontes de alimentação redundantes, RAID 1 ou RAID 10, dois controladores de rede e redundância de switch top-of-rack. Apágina de hospedagemcobre hospedagem compartilhada e hospedagem VPS, incluindo ajuda de migração.

Essa mistura indica um provedor vendendo infraestrutura em várias camadas de abstração. Os clientes podem alugar uma fatia de uma plataforma compartilhada, uma máquina virtual, um servidor físico, espaço em rack, conectividade ou suporte. A questão econômica é que produtos de nível mais alto herdam as restrições de nível mais baixo. Se o rack perder energia, o servidor dedicado e os planos VPS ligados a esse site são afetados. Se a borda da rede perder um provedor ou um objeto de rota for retirado, um plano de hospedagem aparentemente separado ainda pode falhar ao mesmo tempo que o serviço de colocation.

Se o suporte for tratado pela mesma equipe pequena que realiza a substituição de hardware, um incidente movimentado pode transformar uma promessa de "mãos remotas gratuitas" em uma fila.

O registro de recurso numérico está ativo, mas a borda pública estava quieta

O fato de rede mais importante não é lisonjeiro, mas é preciso.A visão geral AS do RIPEstat para AS43112identificou o titular como tsbg_hosting TSBG Hosting Ltd., mas marcou o ASN como não anunciado para a consulta de 12 de julho de 2026.O status de roteamento do RIPEstatrelatou que a primeira rota vista foi 77.246.240.0/20 em 14 de junho de 2007 e a última rota vista foi 193.3.63.0/24 em 15 de agosto de 2025, enquanto a visibilidade atual era zero de 325 peers IPv4 e zero de 322 peers IPv6.Os prefixos anunciados do RIPEstatnão retornaram prefixos atuais para AS43112 para a janela de 28 de junho a 12 de julho de 2026.

Isso não apaga as alegações de serviço da TSBG. Diz algo mais restrito: os coletores de rota pública não viram o AS43112 carregando espaço anunciado ao vivo na data de publicação. Um cliente não pode usar o AS43112 sozinho como prova de serviço atual de Internet, diversidade de trânsito ou tráfego de cliente. Se os serviços atuais forem entregues através de um ASN diferente, um bloco de endereços atribuído pela operadora, uma rede de provedor, um interconecte privado ou um arranjo upstream gerenciado, isso precisa ser declarado e testado diretamente.

A borda pública inativa também muda como ler evidências mais antigas.O histórico de roteamento do RIPEstatmostra longa atividade histórica para 77.246.240.0/20, 77.246.240.0/21 e 193.3.63.0/24, com a rota 193.3.63.0/24 amplamente visível durante grande parte de 2022 a 2025 antes de cair para visibilidade mínima após meados de agosto de 2025. A história é útil para identidade e continuidade. Não é capacidade atual. Se os mesmos clientes ainda são atendidos, eles podem agora ser atendidos através de outro design de rede. Se o prefixo foi retirado porque os serviços foram movidos, o caminho de migração é importante. Se foi retirado porque o serviço pausou, um comprador precisa saber antes de pedir capacidade.

RPKI adiciona mais uma nuance.A validação RPKI do RIPEstat para 193.3.63.0/24 e AS43112retornou válido. Isso é evidência administrativa positiva: AS43112 está autorizado a originar o prefixo. Mas autorização de origem de rota válida não é o mesmo que anúncio. Um detector de fumaça pode ser instalado em uma sala que está atualmente vazia; um ROA pode existir para uma rota que não é visível em BGP. O direito do plano de controle existe, enquanto o caminho operacional ainda precisa de confirmação ao vivo.

O site alega instalações fortes, mas o mapa está incompleto

A história pública mais forte da TSBG é sua história de instalações físicas. Apágina de histórico do data centerdiz que a empresa foi fundada em 2006, concluiu seu primeiro data center em setembro de 2006, concluiu um segundo projeto de colocation em julho de 2007, concluiu um terceiro data center como site de recuperação de desastres com o primeiro equipamento instalado em julho de 2008, e concluiu um quarto data center em outubro de 2008. Também diz que desde 2014 a TSBG tem focado em colocation, hospedagem, aluguel de servidores e serviços gerenciados.

Apágina de datacentersexpande a alegação de instalação. Diz que os sites da TSBG são projetados de acordo com a TIA-942, que os locais são cuidadosamente selecionados, que a empresa garante 100% de disponibilidade de energia, que a energia é projetada em uma configuração totalmente diversa A/B, que a refrigeração é redundante por capacidade nominal, e que a segurança física inclui sites guardados, vigilância por vídeo e acesso escoltado. Diz que o monitoramento cobre carga do servidor, memória, discos, tráfego de porta, saúde do equipamento, temperatura, umidade, corrente elétrica, consumo de energia, ar condicionado e desempenho da rede óptica.

Essas são alegações sérias. Elas também exigem que um comprador peça evidências específicas da instalação. "Quatro datacenters" é um ponto de partida útil apenas se o cliente puder identificar qual dos quatro hospedará sua carga de trabalho, se o site de recuperação está ativo ou em espera, se os sites compartilham o mesmo upstream, se o armazenamento de backup está em um domínio de falha separado e qual alvo de recuperação contratual se aplica quando um site é isolado. As páginas públicas descrevem princípios e capacidades.

Elas não nomeiam cada edifício, alimentação de energia, contrato de combustível, encontro de operadoras, inventário de peças sobressalentes ou resultado de recuperação testado.

A alegação geográfica também precisa de manuseio cuidadoso. A TSBG diz que seus edifícios estão na Bulgária e são geograficamente dispersos, a mais de 150 km de distância, em zonas selecionadas para reduzir riscos de inundação, incêndio, tráfego, industriais e de atividade humana. Seupost de blog de 2023 sobre a Bulgária como localização de data centerdiz que a Bulgária está em rotas importantes entre a Europa, Turquia e Oriente Médio, e diz que a TSBG pode fornecer links protegidos de Camada 2 e IP via rotas diversas para Istambul, Sofia, Bucareste e redes europeias. Essa é uma tese regional valiosa, especialmente para clientes com necessidades de latência nos Bálcãs, Turquia ou Europa-Oriente Médio. Mas vantagem de localização não é um substituto para evidência de caminho ao vivo. Um bom corredor ainda precisa de operadoras contratadas, dutos diversos, cross-connects funcionando e capacidade suficiente depois que um link falha.

PeeringDB adiciona uma pista Haskovo e um aviso de limite de operadora

PeeringDB dá à história da instalação uma pista pública separada.A API de instalação do PeeringDB para a instalação 13672lista "TSBG Hosting" em Haskovo, Bulgária, com endereço1 "Byalo More 3 Kapitan Andreevo," estado Svilengrad, país BG, um campo de sitetsbg.eu, telefone/e-mail de vendas e técnico, e tensão disponível de 480 VAC. O registro foi criado em 19 de maio de 2023 e atualizado em 26 de setembro de 2025. Isso é útil porque está fora do próprio site da TSBG e aponta para uma superfície de instalação específica nomeada no sul da Bulgária, perto da fronteira com a Turquia e Grécia, contexto enfatizado pelo site da TSBG.

Mas os mesmos dados do PeeringDB criam um problema de limite.Os dados netfac do PeeringDB para a instalação 13672mostram uma entrada de rede anexada chamada TSBG Hosting em Haskovo com ASN local 47288.A rede 26850 do PeeringDBidentifica essa rede como FIXNET TELEKOM LTD. STI., ASN 47288, com escopo de tráfego Europa, política de peering aberta, sete instalações e três anexos de exchange.A visão geral AS do RIPEstat para AS47288identifica o titular como FIXNET Telekomunikasyon Limited Sirketi e marca o ASN como anunciado.O status de roteamento do RIPEstat para AS47288viu visibilidade ativa de IPv4 e IPv6 em 12 de julho de 2026, com 18 prefixos IPv4 e um prefixo IPv6 no espaço anunciado na camada de status de roteamento.

Isso não prova que a FixNET opera os serviços de cliente da TSBG. Mas prova que o anexo de instalação público do PeeringDB não deve ser lido casualmente como presença do AS43112. Para um comprador, essa distinção é central. Se a TSBG vende colocation em uma instalação onde o ASN de outra operadora é o anexo de rede visível, o contrato deve explicar se a TSBG, a FixNET, outra operadora ou o cliente fornece o serviço padrão de Internet.

Se a TSBG vende VPS ou servidores dedicados usando conectividade upstream em vez de sua própria rota AS43112 visível, o cliente deve saber quem pode mudar o roteamento, quem abre tickets upstream e cujo calendário de manutenção afeta a alcançabilidade.

A questão do limite da operadora não é acadêmica. Durante um incidente, o primeiro respondente pode ser o suporte da TSBG, o proprietário da instalação, uma operadora, um fornecedor de mãos remotas ou o provedor de rede. O cliente precisa da cadeia de escalação antes da falha. Um registro de instalação que nomeia TSBG e um registro de rede que nomeia AS47288 podem ambos ser verdadeiros, ainda assim deixando o cliente exposto se o contrato de serviço não mapear papéis claramente.

A economia do rack decide quanto do serviço é real

A TSBG publica preços de colocation e pacotes de rack excepcionalmente granulares. Apágina de serviço de colocationlista uma unidade de rack única, quarto de rack, meio rack e rack completo, com concessões de energia e recursos opcionais de rack. A página também diz que a TSBG pode fornecer 48 VDC como uma opção padrão, energia A/B de salas de energia separadas e sistemas UPS, medidores de energia e switches ATS sob solicitação, monitoramento, suporte 24/7 e acesso à Internet. Isso dá aos clientes um carrinho de compras visível para um serviço de instalação que normalmente se esconde por trás de ligações de vendas.

O perigo é que o preço visível do rack não é o mesmo que capacidade resiliente utilizável. Uma unidade de rack única com 35 W é uma dependência muito diferente de um rack completo com 1500 W. Um cliente executando equipamentos de telecomunicações pode precisar de energia DC, PDUs duplos e acesso de mãos remotas; um cliente executando computação pode precisar de mais energia, refrigeração e substituição de hardware.

Uma lista de preços não pode mostrar se a energia sobressalente está reservada, se o trabalho de cross-connect é rápido, se as mãos remotas podem trocar um dispositivo durante uma tempestade regional, ou se o caminho de rede restante pode carregar tráfego quando um fornecedor está fora.

A economia do pequeno provedor importa aqui. A TSBG diz abertamente em seu site que não é o maior operador de data center e não tem megawatts de energia ou terabits por segundo de capacidade de Internet. Essa honestidade é útil. Diz aos compradores para procurar adequação, não teatro de escala. Um site pequeno pode ser exatamente certo para um negócio local, projeto de telecomunicações de rota de fronteira, gabinete de recuperação de desastres ou serviço de baixa latência nos Bálcãs. Também pode ser errado para uma carga de trabalho que assume pools sobressalentes de hiperescala, APIs globais de nuvem ou substituição instantânea de hardware.

O comprador, portanto, tem que traduzir rótulos de pacotes em matemática de falha. Se uma alimentação de energia do gabinete falhar, o equipamento do cliente tem fontes duplas e PDUs duplos? Se um switch top-of-rack falhar, ambas as NICs do servidor estão cabeadas para switches independentes? Se um upstream estiver inativo, o outro caminho tem commit pago suficiente? Se um data center for perdido, os backups são utilizáveis sem o site perdido? Se uma pessoa de suporte deve viajar para um site remoto, qual é o relógio real de reparo? A economia do rack se torna economia de risco uma vez que uma falha começa.

VPS e servidores dedicados herdam cada camada inferior

As páginas de VPS e servidores dedicados da TSBG são detalhadas o suficiente para mostrar de onde vem o valor do cliente. Apágina de servidores clouddiz que os planos VPS são baseados em Proxmox, usam hardware redundante, armazenamento RAID10, servidores host com rede e fonte de alimentação redundantes, Internet compartilhada de 1 Gbit/s e backups opcionais. Lista planos desde um pequeno plano de 512 MB de RAM até planos maiores multi-core. Apágina de servidores dedicadosdiz que os servidores têm fontes de alimentação redundantes, RAID 1 ou RAID 10, controladores RAID de hardware, dois controladores de rede e switches top-of-rack diferentes. Também menciona instalação gratuita de SO, monitoramento, helpdesk 24/7 e mãos remotas.

Esses recursos são significativos. Eles também criam uma agenda de verificação. Um cliente alugando capacidade VPS deve perguntar se o RAID10 é local a um host, compartilhado em um cluster de armazenamento, replicado para outro site ou backup fora de banda. Deve perguntar se o backup opcional é armazenado na mesma instalação, se a velocidade de restauração é medida e se os backups incluem imagens de sistema, dados de nível de arquivo, metadados e estado do painel de controle. Deve perguntar o que acontece quando a máquina host falha e se a migração ao vivo está disponível.

Deve perguntar se a contenção de recursos pode limitar a recuperação quando muitos clientes são afetados ao mesmo tempo.

Um cliente de servidor dedicado tem um problema diferente. Fontes de alimentação redundantes ajudam apenas se cada fonte alcançar um caminho de energia independente. Dois controladores de rede ajudam apenas se estiverem cabeados para switches independentes e roteados através de capacidade upstream independente. RAID protege contra uma falha de disco, mas não contra um bug de controlador, uma reconstrução equivocada, ransomware ou um evento de site completo. Mãos remotas gratuitas são úteis apenas se as peças estiverem estocadas e a equipe puder entrar na instalação rapidamente.

A lacuna de rota pública torna essas perguntas mais importantes. Se o AS43112 não está atualmente visível, o serviço de Internet voltado para o cliente da TSBG pode depender de rotas atribuídas pelo provedor, um parceiro de trânsito, outro ASN ou um design privado não visível nos coletores públicos. Esse arranjo pode ser perfeitamente legítimo. Só precisa ser divulgado ao cliente que está comprando "acesso à Internet" como parte de um plano de servidor. O cliente precisa saber qual borda falha quando a operadora falha.

Alegações de energia, refrigeração e monitoramento precisam de evidência testada

As páginas de instalação dependem fortemente de energia e monitoramento. A TSBG diz que a energia do data center é projetada em configuração totalmente diversa A/B, começando de salas de energia separadas, painéis de distribuição, sistemas UPS e cabeamento até os racks. Diz que cada rack tem dois ou mais PDUs, um para o circuito A e um para o circuito B. Diz que o ar condicionado usa configuração redundante 1+1 ou n+1, e que as salas de equipamentos são mantidas em torno de 22 graus C com umidade relativa entre 40% e 60%. Diz que a detecção de incêndio usa um sistema de amostragem de ar e supressão a gás.

Diz que o monitoramento cobre um amplo conjunto de parâmetros ambientais, de servidor, de porta e de rede óptica.

Esses são exatamente os domínios certos para publicar. A questão é se as alegações são testadas no mesmo nível em que os clientes dependem delas. Energia A/B não é comprovada por dois cabos se ambos os circuitos dependem de um painel upstream, um arranjo de combustível ou um fornecedor de manutenção. Redundância de refrigeração não é comprovada por capacidade nominal se um corredor quente, falha de sensor ou mudança de fluxo de ar pode remover a margem. Monitoramento não é comprovado por ter sensores se a propriedade do alerta, limites e permissões de emergência não são claros.

O conteúdo do blog da TSBG dá dicas úteis sobre seriedade operacional. Opost de manutenção de gerador a dieseldiscute óleo do gerador, filtros, líquido de arrefecimento, baterias e preparação para o inverno. Opost de monitoramento de temperaturadiscute SNMP, Zabbix, sensores one-wire, monitoramento distribuído e design de alarme. Opost de localização de edifício de data centerdiscute seleção de site, riscos de desastre, construção de concreto, design de telhado e acesso de telecomunicações. Esses posts não são certificações, mas mostram familiaridade com o domínio que é mais específica do que cópia genérica de hospedagem.

O próximo passo do cliente deve ser evidência, não admiração. Pergunte pela última data de teste do gerador, a carga testada, tempo de funcionamento do combustível, evidência de manutenção do UPS, evidência de manutenção do sistema de incêndio, plano de resposta a falha de refrigeração, amostra de escalação de monitoramento e notas pós-ação de qualquer incidente real. Pergunte se todos os quatro sites têm a mesma maturidade. Pergunte qual site abriga o serviço específico do cliente. Pergunte o que falha junto. É assim que a linguagem ampla de instalação se torna garantia operacional.

A resiliência de rede depende de contratos upstream, não apenas de um ASN

As próprias páginas da TSBG dizem que a empresa opera seu próprio sistema autônomo e tem sessões BGP com provedores cuidadosamente selecionados. Os registros RIPE identificam AS43112, e as observações whois do RIPE mencionam upstreams e data center, com um import de AS47964 e um export para AS47964.A consistência de roteamento AS do RIPEstatmostrou 193.3.63.0/24 no whois do RIPE, mas não em BGP em 12 de julho de 2026, e mostrou o import/export de AS47964 no whois, mas não em BGP.Os vizinhos ASN do RIPEstat para AS43112não mostraram vizinhos observados na data de publicação.

Essa combinação diz a um comprador para separar três coisas. A primeira é a intenção do registro: o ASN, o objeto de rota, o ROA e as relações whois mostram o que a operadora está preparada ou autorizada a fazer. A segunda é o roteamento ao vivo: os coletores públicos mostram se a rota está atualmente visível e através de quem. A terceira é o roteamento de serviço: uma carga de trabalho do cliente pode usar um upstream ou plano de endereçamento diferente não óbvio a partir do ASN da TSBG sozinho. A resiliência depende da terceira, mas o registro público ilumina principalmente as duas primeiras.

A evidência do PeeringDB AS47288 também é útil sem ser superinterpretada. A FixNET, a rede AS47288 anexada ao registro de instalação da TSBG Hosting, estava ativa nostatus de roteamento do RIPEstate tinha anexos de exchange no PeeringDB no NetIX, TurkIX Sofia e RegPEX. Isso mostra uma superfície de rede próxima ativa vinculada ao registro de instalação. Não prova que o tráfego de cliente da TSBG usa essa superfície, que a TSBG a controla, ou que é diversa o suficiente para qualquer cliente dado.

O teste do cliente é direto. Peça à TSBG para identificar os ASNs, prefixos e upstreams que carregarão o serviço pedido. Pergunte se esses caminhos têm capacidade padrão, se usam entradas físicas separadas, se terminam no mesmo par de roteadores, se os filtros de rota estão atualizados e se a Validação de Origem de Rota está configurada. Compare a resposta com ferramentas públicas comoBGP.tools para AS43112,Hurricane Electric para AS43112,Roteamento Cloudflare Radar para AS43112e RIPEstat. Se o ASN público está intencionalmente quieto, isso é aceitável apenas se o caminho de serviço ao vivo estiver documentado.

Suporte é parte do ativo, não uma página de ajuda

A TSBG destaca repetidamente o suporte. O site menciona suporte helpdesk 24/7, mãos remotas, e-mail, mensagens por Viber e WhatsApp, monitoramento e assistência gratuita para substituição de hardware. Em um serviço de hospedagem ou colocation, o suporte não é um extra soft. É o canal através do qual dependências invisíveis se tornam ações de reparo. Um roteador pode ser redundante, mas alguém ainda precisa identificar qual caminho está quebrado. Um array de discos pode ser protegido, mas alguém precisa decidir se deve reconstruir, restaurar ou fazer failover.

Um cliente pode possuir o servidor, mas as mãos remotas podem ser a única maneira de pressionar um botão, recolocar uma placa ou ler um console.

A questão do suporte é particularmente importante para um provedor menor com vários sites geograficamente dispersos. As próprias páginas da TSBG dizem que a equipe é pequena, mas eficiente, e que parceiros selecionados ajudam com o trabalho e manutenção necessários. Isso pode ser uma força quando o cliente precisa de atenção direta flexível. Pode se tornar uma fraqueza se um incidente atingir vários clientes, um site exigir acesso físico e as mesmas pessoas lidarem com monitoramento, comunicação, hardware e escalação de fornecedores.

Os clientes devem, portanto, contratar suporte como infraestrutura. Eles devem perguntar o que conta como emergência, quem pode declarar uma, qual canal de resposta funciona se o portal estiver inativo, se a escalação por telefone ou mensagem é garantida, se as mãos remotas têm limites de tempo e se as peças são estocadas no local. Eles devem perguntar se um cliente de colocation pode autorizar trabalho antecipadamente. Eles devem perguntar se um cliente VPS recebe ajuda de restauração durante um incidente de plataforma ou apenas suporte de melhor esforço.

Eles devem perguntar se o registro de suporte nomeia o site, upstream, rack ou camada de serviço afetado, em vez de apenas descrever uma interrupção genérica.

O faturamento pertence à mesma categoria. Um serviço pode falhar através de uma conta desativada, prazo de serviço expirado, painel de controle bloqueado ou responsabilidade pouco clara por tráfego adicional. Um cliente usando a TSBG para um pequeno site de recuperação de desastres deve garantir que contato, faturamento, renovação e acesso fora de banda permaneçam disponíveis durante o exato evento que torna o site de recuperação necessário.

A localidade dos dados não é resolvida por um rótulo búlgaro

A região de atribuição é BG, e a própria história da TSBG é fortemente búlgara. A empresa é incorporada na Bulgária, lista um escritório em Sofia, descreve sites búlgaros e comercializa a Bulgária como uma localização estratégica de trânsito de telecomunicações. Para clientes com necessidades de conectividade na Europa, Bálcãs, Turquia ou Oriente Médio, isso é uma alegação de posicionamento significativa. Pode reduzir latência, manter equipamentos sob um relacionamento de provedor búlgaro e fornecer uma alternativa a regiões maiores de nuvem da Europa Ocidental.

Mas a soberania de dados não é apenas um código de país. Um cliente deve identificar onde os dados primários, backups, logs, registros do painel de controle, tickets de suporte, dados de monitoramento e registros de faturamento residem. Um plano VPS pode colocar o disco virtual em uma instalação búlgara e o backup em outra. Um plano de hospedagem compartilhada pode usar ferramentas cPanel, serviços de certificado de terceiros e DNS externo. Um serviço de streaming pode ingerir sinal de satélite ou caminhos terrestres e entregá-lo sobre uma mistura de trânsito local e internacional.

Um cliente de colocation pode possuir o hardware, mas depender da TSBG para acesso remoto e serviço IP.

As páginas públicas da TSBG não publicam uma matriz de posicionamento completa. Elas dizem que a empresa opera vários datacenters na Bulgária, que os sites são geograficamente dispersos e que pode fornecer links protegidos para Istambul, Sofia, Bucareste e redes europeias. Esses são bons fatos iniciais. Eles não respondem se um backup específico cruza fronteiras, se um fornecedor de suporte pode acessar sistemas do cliente, se os logs são retidos em um sistema separado ou como um cliente recebe uma cópia utilizável dos dados durante uma disputa ou interrupção.

A portabilidade de dados é, portanto, parte da revisão de resiliência. Um comprador deve testar como sair. Para hospedagem compartilhada, o cliente pode recuperar arquivos, caixas de correio, registros DNS, bancos de dados e registros TLS de forma limpa? Para VPS, pode exportar uma imagem ou apenas arquivos? Para servidores dedicados, o acesso ao console remoto está disponível se a rede estiver instável? Para colocation, quem controla a renumeração IP, liberação de cross-connect e remoção de hardware? A melhor hora para testar a portabilidade é antes do serviço se tornar crítico.

Sinais não oficiais podem sugerir leads, não conclusões

Assuntos de infraestrutura fina muitas vezes deixam rastros em agregadores comerciais, páginas BGP antigas, páginas de preços, resultados de pesquisa, posts de fórum, perfis sociais e diretórios de instalações. A TSBG não é exceção. Agregadores públicos de roteamento comopágina AS43112 do IPinfo,BGP.tools,Hurricane ElectriceCloudflare Radarsão úteis para verificação cruzada rápida. PeeringDB é útil para pistas de instalação e interconexão. O site oficial é útil para alegações de serviço e informações de contato.

Esses sinais não devem ser tratados igualmente. RIPE RDAP e RIPEstat são fortes para identidade de recurso numérico e observação de rota pública. PeeringDB é valioso, mas automantido e pode ficar atrás da realidade. O site oficial é autoritativo para o que a TSBG diz que vende, mas não é prova independente de que um determinado rack, caminho de fibra ou backup existe hoje. Páginas de agregadores são boas para triangulação, mas podem ficar atrasadas ou representar dados de forma diferente. Posts de blog mostram pensamento técnico, não um certificado operacional ao vivo.

A distinção é mais importante quando as evidências públicas entram em conflito. As páginas oficiais de serviço da TSBG repetidamente dizem que a empresa opera seu próprio AS com sessões BGP. Os registros RIPE identificam AS43112 e um ROA válido existe para 193.3.63.0/24. No entanto, o RIPEstat não viu AS43112 anunciado na data de publicação. Isso não é algo para suavizar. É a principal descoberta. Ou o ASN público está atualmente dormente, ou os serviços atuais são entregues através de outro caminho de rede, ou os coletores públicos perderam um anúncio limitado. Cada possibilidade tem consequências diferentes para o cliente.

O que resolveria? Uma visão atual de looking-glass da TSBG, uma tabela de roteamento mostrando prefixos de cliente, uma lista de upstreams, um IP de teste para o serviço pedido, um traceroute e resultado de diversidade de caminho, uma página de status atual, uma descrição de serviço específica da instalação e linguagem contratual nomeando as partes responsáveis. Até que esses estejam disponíveis, a postura editorial correta é cautela.

Como um comprador deve testar a TSBG antes de colocar uma carga de trabalho crítica

O primeiro teste é identidade e adequação do serviço. Peça à TSBG para confirmar qual entidade legal assina o contrato, qual site hospedará o serviço, qual camada de produto se aplica e se o serviço usa AS43112, AS47288, um bloco de endereços do provedor de trânsito ou outro arranjo de roteamento. Compare a resposta comRIPE RDAP para AS43112,RIPE RDAP para 193.3.63.0/24e observações BGP públicas. Se a resposta for que o ASN público não está atualmente em uso, pergunte por que e o que o substitui.

O segundo teste é prova de instalação. Para colocation, peça o nome do site, posição do rack, design da alimentação de energia, consumo máximo, opções de cross-connect, termos de mãos remotas, procedimento de acesso e regras de notificação de manutenção. Para VPS ou servidores dedicados, pergunte qual instalação hospeda o hardware, se o site de recuperação está ativo, se os backups estão fora do host com falha e se a capacidade está reservada para failover. Peça um resultado recente de teste de energia, refrigeração ou gerador. Apágina de datacentersda TSBG dá uma forte lista de domínios de instalação; o cliente precisa da versão específica do site.

O terceiro teste é independência de rede. Peça upstreams atuais, filtros de rota, status RPKI, diversidade de entrada física, velocidade de interface, commit pago, exposição a DDoS e comportamento de failover. Pergunte se a alegação de 99,999% de conectividade à Internet se aplica ao produto do cliente e como os créditos são calculados. Use ferramentas públicas para verificar se o estado do ASN e prefixo corresponde à resposta, mas não confie apenas em ferramentas públicas se o serviço usar um caminho privado ou de parceiro.

O quarto teste é recuperação. Execute uma restauração pequena. Exporte uma imagem VPS ou reconstrua a partir do backup. Peça às mãos remotas para realizar uma tarefa de console ou inventário não disruptiva. Teste o contato fora de banda. Confirme quem pode autorizar mudanças de emergência. Confirme se um bloqueio de conta, fatura não paga, problema de domínio ou disputa de direito de suporte pode parar o trabalho de recuperação. O material público descreve um pequeno operador capaz; o trabalho do cliente é provar essa capacidade sob seu próprio cenário de falha.

Quem é afetado quando o sistema falha

A população afetada depende de qual produto da TSBG um cliente compra. Um cliente de hospedagem compartilhada está exposto a falhas de nível de plataforma: cPanel, DNS, correio, armazenamento e o caminho de suporte do provedor. Um cliente VPS está exposto a domínios de host, armazenamento, rede e backup. Um cliente de servidor dedicado está exposto a estoque de hardware, borda de rede, alimentações de energia, mãos remotas e qualquer camada de serviço gerenciado. Um cliente de colocation possui mais da pilha, mas ainda depende da TSBG para energia, refrigeração, segurança física, acesso remoto e às vezes trânsito de Internet.

Para um negócio local, a falha pode significar inatividade do site ou e-mail. Para uma operadora de telecomunicações ou TI usando espaço em rack, a falha pode afetar clientes downstream, monitoramento, backhaul, um sistema de antena ou um plano de recuperação de desastres. Para um cliente de mídia ou streaming, a falha pode interromper a entrega ao público. Para uma empresa usando um site búlgaro como alternativa a uma região maior de nuvem da Europa Ocidental, a falha pode remover a própria redundância geográfica que o cliente pretendia comprar.

A superfície de suporte também cria efeitos de segunda ordem. Se o mesmo contato lida com vendas, suporte e escalação técnica, os clientes podem receber atenção pessoal durante operações normais e resposta lenta durante um evento amplo. Se um caminho de fornecedor estiver envolvido, a TSBG pode depender do relógio de reparo de outra operadora. Se o serviço usar uma rota não visível sob o AS43112, os clientes podem monitorar a borda pública errada e perder o domínio de falha real.

É por isso que a conclusão do artigo não é "evite a TSBG". É "não compre a abstração sem mapear as dependências." O material público da TSBG é excepcionalmente operacional para um pequeno provedor. A prova que falta é alcançabilidade atual e failover testado para o caminho específico do cliente.

O grau de evidência

A TSBG Hosting Ltd. ganha um grau de evidência de rede Fraco para este artigo. O grau não é um julgamento de satisfação do cliente ou habilidade de engenharia. É um julgamento do que a evidência pública pode provar em 12 de julho de 2026. O site oficial dá fortes alegações de serviço específicas da empresa: quatro datacenters, colocation, VPS, servidores dedicados, hospedagem compartilhada, energia A/B, monitoramento, mãos remotas, segurança, detecção de incêndio, refrigeração e posicionamento de trânsito búlgaro. Os registros RIPE dão uma identidade real de recurso numérico da TSBG: AS43112, ORG-THL32-RIPE e 193.3.63.0/24.

RPKI valida a autorização de origem de 193.3.63.0/24 para AS43112.

O rebaixamento vem da borda atual. O RIPEstat não viu AS43112 anunciado, não viu prefixos atuais do AS43112 e não viu vizinhos atuais do AS43112. A entrada de instalação do PeeringDB TSBG Hosting adiciona uma pista física, mas seu anexo de rede visível aponta para AS47288/FixNET em vez de AS43112. Isso pode representar um parceiro válido ou arranjo upstream; não prova de forma independente o roteamento ao vivo do cliente da TSBG.

A conclusão prática é restrita. A TSBG parece ser um operador real de hospedagem e colocation búlgaro com alegações detalhadas de infraestrutura física. Um comprador deve tratar essas alegações como testáveis, não resolvidas. Antes de colocar cargas de trabalho críticas, deve obter evidências de rota atuais, evidências de instalação específicas do site, limites de upstream e suporte, evidências de backup ou migração testadas e um mapa escrito de quem restaura o serviço quando ocorre falha de rack, upstream, estoque de hardware, suporte, faturamento, migração ou contrato de provedor.