tsbg_hosting TSBG Hosting Ltd. vende capacidade hospedada que ainda depende de racks, trânsito e janelas de manutenção

Resumo

• TSBG Hosting Ltd. se apresenta como um operador de infraestrutura búlgaro fundado em 2006, oferecendo em seu próprio site colocation, servidores em nuvem, servidores dedicados, hospedagem compartilhada, streaming e serviços gerenciados.
• As afirmações operacionais mais sólidas próprias da empresa são físicas em vez de puramente virtuais: várias instalações de data centers búlgaros neutras em relação aos operadores, quatro data centers, design orientado pela TIA-942, alimentação A/B, monitoramento, intervenção remota, detecção de incêndio, resfriamento e acesso escoltado.
• O sinal atual da rede pública é baixo.RIPE RDAPidentifica AS43112 como tsbg_hosting e registra TSBG Hosting Ltd. como titular, masRIPEstat routing statusnão mostrou nenhum espaço IPv4 ou IPv6 anunciado visível para AS43112 em 2026-07-12.
• O recurso 193.3.63.0/24 da TSBG permanece relevante porqueRIPE RDAP para o prefixoidentifica BG-TSBGHOSTING-20200902, eRIPEstat RPKI validationvalidou AS43112 como autorizado para este prefixo. Autorização não é o mesmo que acessibilidade ao vivo.
• O registro de instalação TSBG Hosting doPeeringDBadiciona uma pista física em Haskovo/Svilengrad, enquantoos dados net-facility do PeeringDBligam o attachment listado a AS47288/FixNET em vez de AS43112. Isso confirma a necessidade de verificar os limites do operador antes de confiar em qualquer alegação de resiliência.
• O nível de evidência é Baixo. O site oficial fornece alegações de serviço ricas, mas as evidências de roteamento público atuais não provam independentemente tráfego de cliente AS43112 ao vivo, failover multi-site, diversidade de trânsito, capacidade de reserva ou portabilidade de dados.

Uma fatura de nuvem ainda aterrissa em uma sala de máquinas búlgara

TSBG Hosting Ltd. não é um nome que pode ser avaliado pelo reconhecimento da marca. Deve ser avaliado traçando o serviço até os equipamentos e as pessoas que manteriam um cliente online. A empresa vende serviços que parecem elásticos: servidores em nuvem, 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, alimentação e resfriamento. Um servidor dedicado precisa de um chassi específico e um plano de substituição.

Colocation precisa de um rack, orçamento de energia, caminhos de cabos, controle de acesso e intervenção remota. Streaming precisa de capacidade de ingestão, transcodificação ou encaminhamento e largura de banda de saída suficiente para suportar a audiência quando a demanda aumenta.

O fato útil sobre a TSBG é que a empresa não se descreve apenas em uma linguagem vaga de nuvem. Apágina inicial oficialcomercializa colocation, servidores dedicados, servidores virtuais, streaming e colocation de antenas de satélite. A mesma página descreve quatro data centers neutros em relação aos operadores e dezesseis anos de experiência, e indica que a TSBG pode suportar nuvem privada, sites de recuperação de desastres, acesso à Internet dedicado, endereços IPv4, alimentação em corrente contínua e recepção de satélite. Essas alegações dão ao comprador uma lista concreta para testar: edifícios, racks, domínios de alimentação, fibras, provedores de acesso, servidores, recursos de endereços e arranjos de suporte.

O risco é que os detalhes de marketing público ainda podem superar 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 os planos individuais dependem de estoque disponível, suporte de provedores ou 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 digitais e a originação 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 considerar a lista de preços online ou o ASN como um relatório de garantia. O cliente deve perguntar qual instalação hospeda a carga de trabalho, qual borda de rede anuncia o serviço, qual provedor possui trânsito capaz de falha, quanta energia e hardware de reposição 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 sólida do que o instantâneo inicial do diretório sugeria. O site da TSBG indica que a empresa foi fundada em 2006, é constituída sob a lei búlgara, menciona o número de IVA intracomunitário BG175059953, nomeia Ivan Shishkov como diretor geral, e fornece um endereço de escritório em Sofia na rua Racho Dimchev, 8. Apágina de contatorepete o endereço de Sofia, o número de telefone e o e-mail comercial.RIPE RDAP para AS43112identifica o nome do objeto como tsbg_hosting e inclui TSBG Hosting Ltd. como entidade organizacional com um endereço em Sofia. Osdados whois do RIPEstatregistram aut-num 43112, as-name tsbg_hosting, organization 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 uma etiqueta flutuante sem titular responsável. Aqui, o titular pode ser vinculado a uma identidade empresarial búlgara, uma superfície de contato, um registro de recurso digital 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.

A amplitude dos serviços também é específica. Apágina de colocation da TSBGanuncia pacotes de uma unidade de rack, um quarto de rack, meio rack e rack completo, com potências indicadas variando de 35 W para uma unidade de rack a 1500 W para um rack completo. A página também indica que a empresa pode fornecer conectividade à Internet, endereços IPv4 e serviços LIR. Apágina de servidores em nuvemlista planos VPS, armazenamento SSD, proteção RAID10, conexão à 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 switches de topo de rack. Apágina de hospedagemcobre hospedagem compartilhada e hospedagem VPS, incluindo ajuda na 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 de rack, conectividade ou suporte. O problema econômico é que os produtos de nível superior herdam as restrições de nível inferior. Se o rack perder energia, os planos de servidor dedicado e VPS ligados a esse local são afetados. Se a borda da rede perder um provedor ou se um objeto de rota for retirado, um plano de hospedagem aparentemente distinto também pode falhar ao mesmo tempo que o serviço de colocation.

Se o suporte for gerenciado pela mesma pequena equipe que realiza a substituição de hardware, um incidente carregado pode transformar uma promessa de "intervenção remota gratuita" em fila de espera.

O registro de recursos digitais está ativo, mas a borda pública estava silenciosa

O fato de rede mais importante não é lisonjeiro, mas é preciso. Avisã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 2026-07-12. Ostatus de roteamento do RIPEstatreportou que a primeira rota vista foi 77.246.240.0/20 em 2007-06-14 e a última rota vista foi 193.3.63.0/24 em 2025-08-15, enquanto a visibilidade atual era zero em 325 pares IPv4 e zero em 322 pares IPv6. Osprefixos anunciados do RIPEstatnão retornaram nenhum prefixo atual para AS43112 na janela de 2026-06-28 a 2026-07-12.

Isso não apaga as alegações de serviço da TSBG. Indica algo mais restrito: os coletores de rotas públicos não viram AS43112 transportar espaço anunciado ao vivo na data de publicação. Um cliente não pode usar AS43112 sozinho como prova do serviço de Internet atual, diversidade de trânsito ou tráfego de cliente. Se os serviços atuais são fornecidos via um ASN diferente, um bloco de endereços atribuído por um operador, uma rede de provedor, uma interconexão privada ou um acordo de uplink gerenciado, isso deve ser indicado e testado diretamente.

A borda pública inativa também muda a forma de ler as evidências mais antigas. Ohistórico de roteamento do RIPEstatmostra uma 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. O histórico é útil para identidade e continuidade. Não é capacidade atual. Se os mesmos clientes ainda são atendidos, podem agora estar sendo atendidos através de outro design de rede. Se o prefixo foi retirado porque os serviços foram movidos, o caminho de migração importa. Se foi retirado porque o serviço foi suspenso, um comprador deve saber disso antes de pedir capacidade.

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

O site alega instalações sólidas, mas o mapa está incompleto

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

Apágina dos data centersdesenvolve a alegação das instalações. Indica que os sites da TSBG são projetados conforme TIA-942, que os locais são cuidadosamente selecionados, que a empresa garante disponibilidade de energia de 100%, que a energia é projetada em configuração A/B totalmente diversificada, que o resfriamento é redundante em capacidade nominal, e que a segurança física inclui sites vigiados, videomonitoramento e acesso escoltado. Indica que o monitoramento cobre carga do servidor, memória, discos, tráfego de portas, saúde dos equipamentos, temperatura, umidade, corrente elétrica, consumo de energia, ar condicionado e desempenho da rede óptica.

Essas são alegações sérias. Também exigem que um comprador peça evidências específicas da instalação. "Quatro data centers" é 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 provedor de acesso, se o armazenamento de backup está em um domínio de falha separado, e qual objetivo de recuperação contratual se aplica quando um site fica isolado. As páginas públicas descrevem princípios e capacidades.

Elas não nomeiam cada edifício, alimentação elétrica, contrato de combustível, encontro de operadores, inventário de peças de reposição ou resultado de recuperação testado.

A alegação geográfica também requer manuseio cuidadoso. A TSBG diz que seus edifícios estão na Bulgária e estão geograficamente distribuídos, a mais de 150 km um do outro, em áreas selecionadas para reduzir riscos de inundação, incêndio, tráfego, industriais e de atividade humana. Seuartigo de blog de 2023 sobre a Bulgária como local de data centerindica que a Bulgária está em rotas importantes entre a Europa, Turquia e Oriente Médio, e que a TSBG pode fornecer links protegidos de camada 2 e IP através de rotas diversas para Istambul, Sofia, Bucareste e redes europeias. Esta é uma tese regional valiosa, particularmente para clientes com necessidades de latência para os Bálcãs, Turquia ou Europa-Oriente Médio. Mas a vantagem da localização não substitui a evidência de caminho ao vivo. Um bom corredor ainda precisa de operadores contratados, dutos diversificados, interconexões funcionais e capacidade suficiente após a falha de um link.

PeeringDB adiciona uma pista sobre Haskovo e um aviso sobre limites do operador

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

Mas os mesmos dados do PeeringDB criam um problema de limite. Osdados netfac do PeeringDB para instalação 13672mostram uma entrada de rede anexada chamada TSBG Hosting em Haskovo com ASN local 47288. Arede PeeringDB 26850identifica 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 attachments de exchange. Avisão geral AS do RIPEstat para AS47288identifica o titular como FIXNET Telekomunikasyon Limited Sirketi e marca o ASN como anunciado. Ostatus de roteamento do RIPEstat para AS47288viu visibilidade IPv4 e IPv6 ativa em 2026-07-12, 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. Isso prova que o attachment de instalação pública PeeringDB não deve ser lido levianamente como uma presença AS43112. Para um comprador, esta distinção é central. Se a TSBG vende colocation em uma instalação onde o ASN de outro operador é o attachment de rede visível, o contrato deve explicar se a TSBG, FixNET, outro operador ou o cliente fornece o serviço de Internet padrão.

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

A questão dos limites do operador não é acadêmica. Durante um incidente, o primeiro respondedor pode ser o suporte TSBG, o proprietário da instalação, um operador, um provedor de intervenção remota ou o provedor de rede. O cliente precisa da cadeia de escalada antes da falha. Um registro de instalação que nomeia TSBG e um registro de rede que nomeia AS47288 podem ambos ser verdadeiros, enquanto deixam o cliente exposto se o contrato de serviço não define claramente os papéis.

A economia dos racks determina a realidade do serviço

TSBG publica preços de colocation e pacotes de rack excepcionalmente granulares. Apágina de serviço de colocationlista uma unidade de rack, um quarto de rack, meio rack e rack completo, com alocações de energia e funcionalidades de rack opcionais. A página também indica que a TSBG pode fornecer 48 VDC opcional padrão, alimentação A/B de salas elétricas e sistemas UPS separados, medidores de energia e switches ATS sob demanda, monitoramento, suporte 24/7 e acesso à Internet. Isso dá aos clientes uma cesta de compras visível para um serviço de instalação que geralmente se esconde por trás de chamadas comerciais.

O perigo é que o preço do rack visível não é a mesma coisa que capacidade resiliente utilizável. Uma única unidade de rack com 35 W é uma dependência muito diferente de um rack completo com 1500 W. Um cliente operando equipamentos de telecomunicações pode precisar de alimentação DC, PDU duplos e acesso de intervenção remota; um cliente executando computação pode precisar de mais energia, resfriamento e substituição de hardware.

Uma lista de preços não pode mostrar se a energia de reserva está reservada, se o trabalho de interconexão é rápido, se a intervenção remota pode trocar um dispositivo durante uma tempestade regional, ou se o caminho de rede restante pode transportar o tráfego quando um provedor está fora de serviço.

A economia de pequenos provedores importa aqui. TSBG diz abertamente em seu site que não é o maior operador de data centers 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 o espetáculo de escala. Um pequeno site pode ser perfeitamente adequado para um negócio local, um projeto de telecomunicações de rota de fronteira, um armário de recuperação de desastres ou um serviço balcânico de baixa latência.

Também pode ser inadequado para uma carga de trabalho que assume pools de reserva em grande escala, APIs de nuvem globais ou substituição instantânea de hardware.

O comprador deve, portanto, traduzir os rótulos dos pacotes em cálculos de falha. Se uma alimentação de armário falha, o equipamento do cliente tem fontes de alimentação duplas e PDU duplos? Se um switch de topo de rack falha, as duas NICs do servidor estão cabeadas a switches independentes? Se um provedor de acesso está fora de serviço, o outro caminho tem um compromisso pago suficiente? Se um data center é perdido, os backups são utilizáveis sem o site perdido? Se uma pessoa de suporte precisa ir a um site remoto, qual é o tempo real de reparo? A economia dos racks torna-se uma economia de risco assim 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 em nuvemindica que os planos VPS são baseados em Proxmox, usam hardware redundante, armazenamento RAID10, rede redundante e servidores host com alimentação redundante, Internet compartilhada de 1 Gbit/s e backups opcionais. Lista planos variando de um pequeno plano de 512 MB de RAM a planos multicore maiores. Apágina de servidores dedicadosindica que os servidores têm fontes de alimentação redundantes, RAID 1 ou RAID 10, controladores RAID de hardware, dois controladores de rede e diferentes switches de topo de rack. Também menciona instalação gratuita do sistema operacional, monitoramento, serviço de suporte 24/7 e intervenção remota.

Essas funcionalidades são significativas. Também criam um programa de verificação. Um cliente alugando capacidade VPS deve perguntar se o RAID10 é local a um host, compartilhado em um cluster de armazenamento, replicado em outro site ou salvo offline. Deve perguntar se o backup opcional está armazenado na mesma instalação, se a velocidade de restauração é medida, e se os backups incluem imagens do sistema, dados em 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 só ajudam se cada alimentação alcançar um caminho de energia independente. Dois controladores de rede só ajudam se estiverem cabeados a switches independentes e roteados através de capacidade de provedor de acesso independente. RAID protege contra falha de disco, mas não contra um bug de controlador, reconstrução corrompida, ransomware ou evento em escala de site. Intervenção remota gratuita só é útil se as peças estiverem em estoque e a equipe puder entrar rapidamente na instalação.

A lacuna de rota pública torna essas questões mais importantes. Se AS43112 não está visível atualmente, o serviço de Internet do cliente 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. Simplesmente precisa ser divulgado ao cliente que compra "acesso à Internet" como parte de um plano de servidor. O cliente deve saber qual borda falha quando o operador falha.

Alegações de energia, resfriamento e monitoramento exigem evidências testadas

As páginas das instalações dependem fortemente de energia e monitoramento. A TSBG indica que a energia dos data centers é projetada em configuração A/B totalmente diversificada, a partir de salas elétricas, quadros de distribuição, sistemas UPS e cabeamento separados para os racks. Indica que cada rack tem dois ou mais PDU, um para o circuito A e um para o circuito B. Indica 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%. Indica que a detecção de incêndio usa um sistema de amostragem de ar e supressão por gás.

Indica que o monitoramento cobre uma ampla gama de parâmetros ambientais, de servidor, de porta e de rede óptica.

Esses são exatamente os domínios certos a publicar. A questão é se as alegações são testadas no mesmo nível em que os clientes dependem. Alimentação A/B não é provada por dois cabos se ambos os circuitos dependem de um único painel upstream, um único arranjo de combustível ou um único fornecedor de manutenção. Redundância de resfriamento não é provada pela capacidade nominal se um corredor quente, falha de sensor ou mudança de fluxo de ar pode remover a margem. Monitoramento não é provado pela presença de sensores se a propriedade dos alertas, limites e autorizações de emergência não são claros.

O conteúdo do blog da TSBG dá pistas úteis sobre seriedade operacional. Oartigo sobre manutenção de geradores a dieseltrata de óleo do gerador, filtros, refrigerante, baterias e preparação para o inverno. Oartigo sobre monitoramento de temperaturatrata de SNMP, Zabbix, sensores one-wire, monitoramento distribuído e design de alarmes. Oartigo sobre localização de edifícios de data centerstrata de seleção de local, riscos de desastre, construção de concreto, design de telhado e acesso de telecomunicações. Esses artigos não são certificações, mas mostram familiaridade com o domínio que é mais específica do que o copiar-colar genérico de hospedagem.

O próximo passo do cliente deve ser evidências, não admiração. Peça a última data de teste do gerador, carga testada, autonomia de combustível, evidências de manutenção dos UPS, evidências de manutenção do sistema de incêndio, plano de resposta a falha de resfriamento, uma amostra de escalada de monitoramento e notas pós-ação de qualquer incidente real. Peça se os quatro sites têm a mesma maturidade. Peça qual site hospeda o serviço específico do cliente. Peça o que falha junto. É assim que a linguagem geral das instalações se torna garantia operacional.

A resiliência da rede depende de contratos de provedor de acesso, não apenas de um ASN

As próprias páginas da TSBG indicam que a empresa gerencia seu próprio sistema autônomo e tem sessões BGP com provedores cuidadosamente selecionados. Os registros RIPE identificam AS43112, e os comentários whois RIPE mencionam provedor de acesso e data centers, com uma importação de AS47964 e uma exportação para AS47964. Aconsistência de roteamento AS do RIPEstatmostrou 193.3.63.0/24 no whois RIPE mas não no BGP em 2026-07-12, e mostrou a importação/exportação AS47964 no whois mas não no BGP. Osvizinhos ASN do RIPEstat para AS43112não mostraram nenhum vizinho observado na data de publicação.

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

A evidência PeeringDB AS47288 também é útil sem ser superinterpretada. FixNET, a rede AS47288 anexada ao registro de instalação TSBG Hosting, estava ativa nostatus de roteamento do RIPEstate tinha attachments de exchange PeeringDB na NetIX, TurkIX Sofia e RegPEX. Isso mostra uma superfície de rede ao vivo próxima relacionada ao registro da instalação. Isso não prova que o tráfego de cliente TSBG use essa superfície, que a TSBG a controle, ou que seja suficientemente diversificada para um cliente dado.

O teste do cliente é simples. Peça à TSBG para identificar os ASNs, prefixos e provedores de acesso que transportarão o serviço contratado. Peça se esses caminhos são à prova de falhas, 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,Cloudflare Radar para roteamento AS43112e RIPEstat. Se o ASN público está intencionalmente silencioso, isso só é aceitável se o caminho de serviço ao vivo for documentado.

O suporte faz parte do ativo, não uma página de ajuda

TSBG enfatiza repetidamente o suporte. O site menciona suporte 24/7, intervenção remota, e-mail, mensagens Viber e WhatsApp, monitoramento e assistência gratuita na substituição de hardware. Em um serviço de hospedagem ou colocation, o suporte não é um extra opcional. É o canal pelo qual as 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. Uma matriz de discos pode ser protegida, mas alguém precisa decidir se reconstruir, restaurar ou fazer failover.

Um cliente pode possuir o servidor, mas a intervenção remota pode ser o único meio de pressionar um botão, reinserir uma placa ou ler um console.

A questão do suporte é particularmente importante para um pequeno provedor com múltiplos sites geograficamente distribuídos. As próprias páginas da TSBG indicam que a equipe é pequena mas eficiente, e que parceiros selecionados ajudam nos trabalhos e na 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 afeta vários clientes, um site requer acesso físico e as mesmas pessoas gerenciam monitoramento, comunicação, hardware e escalada de provedores.

Os clientes devem, portanto, contratualizar o suporte como infraestrutura. Devem perguntar o que conta como emergência, quem pode declarar uma, qual canal de resposta funciona se o portal estiver offline, se a escalada por telefone ou mensagem é garantida, se a intervenção remota tem limites de tempo, e se as peças são armazenadas no local. Devem perguntar se um cliente de colocation pode autorizar trabalhos com antecedência. Devem perguntar se um cliente VPS obtém ajuda na restauração durante um incidente de plataforma ou apenas suporte no melhor esforço.

Devem perguntar se o registro de suporte nomeia o site, provedor de acesso, rack ou camada de serviço afetados, em vez de apenas descrever uma falha genérica.

A faturamento pertence à mesma categoria. Um serviço pode falhar devido a conta desativada, prazo de serviço expirado, painel de controle bloqueado ou responsabilidade pouco clara por tráfego extra. Um cliente usando TSBG para um pequeno site de recuperação de desastres deve garantir que contatos, 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.

Localização de dados não é resolvida por um rótulo búlgaro

A região de atribuição é BG, e a história da TSBG é fortemente búlgara. A empresa é constituída na Bulgária, indica um escritório em Sofia, descreve sites búlgaros e comercializa a Bulgária como um local estratégico de trânsito de telecomunicações. Para clientes com necessidades de conectividade europeia, balcânica, turca ou do Oriente Médio, esta é uma alegação de posicionamento significativa. Pode reduzir latência, manter o equipamento sob uma relação de provedor búlgaro e fornecer uma alternativa às grandes regiões de nuvem da Europa Ocidental.

Mas a soberania de dados não é apenas um código de país. Um cliente deve identificar onde residem os dados primários, backups, logs, registros do painel de controle, tickets de suporte, dados de monitoramento e registros de faturamento. 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 certificados de terceiros e DNS externo. Um serviço de streaming pode ingerir o sinal a partir de caminhos de satélite ou terrestres e distribuí-lo através de 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 colocação completa. Indicam que a empresa gerencia múltiplos data centers na Bulgária, que os sites estão geograficamente distribuídos e que pode fornecer links protegidos para Istambul, Sofia, Bucareste e redes europeias. Esses são bons fatos de partida. Eles não respondem à pergunta se um backup específico cruza fronteiras, se um provedor de suporte pode acessar sistemas do cliente, se os logs são mantidos em um sistema separado, ou como um cliente recebe uma cópia utilizável dos dados durante uma disputa ou falha.

A portabilidade de dados faz parte, portanto, do exame de resiliência. Um comprador deve testar como sair. Para hospedagem compartilhada, o cliente pode recuperar de forma limpa arquivos, caixas de correio, registros DNS, bancos de dados e registros TLS? Para VPS, pode exportar uma imagem ou apenas os 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 de IP, liberação de interconexões e remoção de hardware? O melhor momento para testar a portabilidade é antes de o serviço se tornar crítico.

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

Tópicos de infraestrutura fina frequentemente deixam rastros em agregadores comerciais, páginas BGP antigas, páginas de preços, resultados de pesquisa, postagens em fóruns, perfis sociais e diretórios de instalações. TSBG não é exceção. Agregadores de roteamento públicos 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 da mesma forma. RIPE RDAP e RIPEstat são sólidos para identidade de recursos digitais e observação de rotas públicas. PeeringDB é valioso mas automantido e pode estar atrasado em relação à realidade. O site oficial é autoritativo para o que TSBG diz vender, mas não é evidência independente de que um rack, caminho de fibra ou backup específico existe hoje. Páginas de agregadores são boas para triangulação mas podem estar desatualizadas ou representar os dados de forma diferente. Artigos de blog mostram reflexão técnica, não um certificado de operação ao vivo.

A distinção é mais importante quando as evidências públicas estão em conflito. As páginas de serviço oficiais da TSBG indicam repetidamente que a empresa gerencia seu próprio AS com sessões BGP. Os registros RIPE identificam AS43112 e uma ROA válida existe para 193.3.63.0/24. No entanto, RIPEstat não viu AS43112 anunciado na data de publicação. Isso não é algo para suavizar. É a principal conclusão. Ou o ASN público está atualmente inativo, ou os serviços atuais são fornecidos 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 a questão? Uma visão atual de looking-glass da TSBG, uma tabela de roteamento mostrando prefixos de clientes, uma lista de provedores de acesso, um IP de teste para o serviço contratado, um resultado de traceroute e 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 é a 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 de provedor de trânsito ou outro arranjo de roteamento. Compare a resposta comRIPE RDAP para AS43112,RIPE RDAP para 193.3.63.0/24, e com observações BGP públicas. Se a resposta é que o ASN público não está sendo usado atualmente, pergunte por que e o que o substitui.

O segundo teste é evidência da instalação. Para colocation, peça o nome do site, posição do rack, design de energia, consumo máximo, opções de interconexão, condições de intervenção remota, procedimento de acesso e regras de notificação de manutenção. Para VPS ou servidores dedicados, peça 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, resfriamento ou gerador. Apágina de data centers da TSBGdá uma lista sólida 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 os provedores de acesso atuais, filtros de rota, status RPKI, diversidade de entradas físicas, velocidade de interface, compromisso pago, exposição a DDoS e comportamento de failover. Peça se a alegação de conectividade à Internet de 99,999% se aplica ao produto do cliente e como os créditos são calculados. Use ferramentas públicas para verificar se o status 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 de um backup. Peça à intervenção remota para realizar uma tarefa de console ou inventário não intrusiva. 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 sobre direito a suporte pode interromper os trabalhos de recuperação. O material público descreve um pequeno operador competente; o trabalho do cliente é provar essa capacidade em seu próprio cenário de falha.

Quem é afetado quando o sistema falha

A população afetada depende do produto TSBG que o cliente compra. Um cliente de hospedagem compartilhada está exposto a falhas no nível da plataforma: cPanel, DNS, e-mail, armazenamento e o caminho de suporte do provedor. Um cliente VPS está exposto aos domínios do host, armazenamento, rede e backup. Um cliente de servidor dedicado está exposto ao estoque de hardware, borda de rede, alimentações, intervenção remota e qualquer camada de serviço gerenciado. Um cliente de colocation possui uma parte maior da pilha, mas ainda depende da TSBG para energia, resfriamento, segurança física, acesso remoto e, às vezes, trânsito de Internet.

Para um negócio local, uma falha pode significar indisponibilidade do site ou e-mail. Para um operador de telecom ou TI usando espaço de rack, uma 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, uma falha pode interromper a transmissão para o público. Para uma empresa usando um site búlgaro como alternativa a uma maior região de nuvem da Europa Ocidental, uma falha pode remover a 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 gerencia vendas, suporte e escalada técnica, os clientes podem receber atenção pessoal durante operações normais e resposta lenta durante um evento geral. Se um caminho de provedor está envolvido, a TSBG pode depender do tempo de reparo de outro operador. Se o serviço usa uma rota não visível sob AS43112, os clientes podem monitorar a borda pública errada e perder o verdadeiro domínio de falha.

É por isso que a conclusão do artigo não é "evite 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 evidência ausente é a acessibilidade atual e o failover testado para o caminho específico do cliente.

O nível de evidência

TSBG Hosting Ltd. obtém um nível de evidência de rede Baixo para este artigo. O nível não é um julgamento sobre satisfação do cliente ou competência técnica. É um julgamento sobre o que as evidências públicas podem provar em 2026-07-12. O site oficial fornece fortes alegações de serviço específicas da empresa: quatro data centers, colocation, VPS, servidores dedicados, hospedagem compartilhada, energia A/B, monitoramento, intervenção remota, segurança, detecção de incêndio, resfriamento e posicionamento de trânsito búlgaro. Os registros RIPE dão uma verdadeira identidade de recursos digitais TSBG: AS43112, ORG-THL32-RIPE e 193.3.63.0/24.

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

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

A conclusão prática é estreita. TSBG parece ser um verdadeiro operador búlgaro de hospedagem e colocation com alegações de infraestrutura física detalhadas. Um comprador deve tratar essas alegações como verificáveis, não como liquidadas. Antes de colocar cargas de trabalho críticas, deve obter evidência de rota atual, evidência de instalação específica do site, limites de provedor de acesso e suporte, evidência de backup ou migração testada, e um mapa escrito de quem restaura o serviço em caso de falha de rack, provedor de acesso, estoque de hardware, suporte, faturamento, migração ou contrato de provedor.