Quando um ambiente Postgres expande sua operação e cruza a fronteira dos Terabytes, a gestão de infraestrutura sofre uma mudança de fase. O que antes era uma rotina automatizada e silenciosa passa a ser um dos indicadores mais críticos de continuidade de negócios: as métricas de RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Em cenários de alta escala, cada minuto economizado na janela de backup ou na restauração reflete diretamente na resiliência de toda a operação.
O diagnóstico de senso comum dita que, se a janela de backup está se estendendo além do aceitável, a solução imediata é investir em hardware: provisionar discos com maiores taxas de IOPS, migrar para volumes NVMe ou contratar links de rede com maior largura de banda. No entanto, em infraestruturas modernas que já contam com redes de 10Gbps ou 40Gbps, muitas equipes se deparam com um teto de vidro. Mesmo com recursos de hardware sobrando, a taxa de transferência estagna.
Existe um gargalo invisível na camada de transporte de dados. A grande maioria dos ambientes adota a combinação do utilitário pgBackRest operando sobre o protocolo SSH, devido sua simplicidade e o caminho de menor resistência na configuração inicial. Contudo, quando o volume de dados escala de forma massiva, o protocolo SSH pode impor um overhead considerável a depender do ambiente , tornando-se o principal limitador do throughput do backup.
Por que o SSH “gargala” em ambientes robustos?
Para compreender a subutilização da infraestrutura de rede durante os backups, é preciso analisar como o protocolo SSH interage com o sistema operacional sob cargas de trabalho intensas. Não se trata de uma limitação do pgBackRest, mas sim da arquitetura de software projetada para o tráfego de dados.
O Custo da Criptografia no Espaço do Usuário (User Space)
O SSH foi desenhado originalmente para garantir canais seguros para sessões interativas e transferências de arquivos genéricas. Para assegurar essa comunicação, ele executa uma rotina pesada que envolve criptografia, verificação de integridade e, frequentemente, compressão de pacotes. Todo esse processamento ocorre no espaço do usuário.
Quando o pgBackRest tenta empurrar fluxos contínuos e massivos de arquivos de WAL ou tabelas gigantescas através do canal SSH, o daemon do SSH (sshd) passa a consumir ciclos severos de processamento. Em ambientes de produção, é comum observar um núcleo inteiro de CPU travado em 100% de utilização apenas para realizar o envelopamento e a cifragem desse tráfego, criando um funil que impede o aproveitamento total da banda disponível.
Multiplexação e Controle de Fluxo Duplicado
O pgBackRest possui uma arquitetura altamente eficiente para gerenciar concorrência e paralelismo através do parâmetro process-max, distribuindo a carga de leitura do banco de dados em múltiplos processos. No entanto, ao rodar essa estrutura sobre o SSH, cria-se uma disputa oculta na pilha de rede.
O SSH tenta impor seu próprio controle de fluxo e gerenciar suas janelas de recepção de pacotes sobre uma massa de dados que o pgBackRest já está ativamente tentando otimizar. Essas camadas adicionais de controle, buffers e processos podem introduzir uma latência a mais na camada de transporte. O sistema operacional gasta tempo coordenando os dois mecanismos concorrentes, resultando na subutilização da largura de banda da rede.
O Overhead de Context Switching (Troca de Contexto)
O tráfego de dados via SSH impõe um caminho complexo dentro do servidor. Cada bloco de informação que sai do banco de dados precisa ser transferido do processo do pgBackRest para o daemon do SSH (mudança de contexto no espaço do usuário). Em seguida, o dado passa para o kernel do sistema operacional para ser entregue à placa de rede. No servidor de repositório, todo esse caminho reverso é executado.
Em volumes massivos de dados, essa constante troca de contexto no processador gera uma perda de eficiência severa. Trata-se de um desperdício invisível nos gráficos de monitoramento tradicionais, que não acusam falhas de rede ou de disco, mas subtraem a capacidade de vazão do sistema.
Por que o TLS Nativo (mTLS) desbloqueia a escala?
A virada de chave para contornar esse teto de desempenho sem comprometer a segurança da informação está na alteração do protocolo de transporte do pgBackRest, substituindo o túnel SSH pela comunicação nativa baseada em TLS mútuo (mTLS).
Comunicação Direta via Sockets TCP
Ao configurar o pgBackRest para utilizar TLS nativo (repo1-host-type=tls), elimina-se a figura do intermediário, o daemon do SSH. A aplicação passa a abrir conexões diretas via sockets TCP com o servidor de destino. A criptografia e a validação de identidade passam a ser tratadas diretamente na camada de rede da própria aplicação. Sem intermediários no espaço do usuário, o caminho do dado até a placa de rede torna-se linear e desobstruído.
Eficiência de CPU e Descarregamento por Hardware (Hardware Offloading)
Os protocolos TLS modernos (com destaque para o TLS 1.3) foram otimizados para a internet de alta velocidade. Além da evolução do software, a maioria dos processadores modernos adotados em servidores possui instruções nativas em nível de hardware (como o conjunto AES-NI) dedicadas a acelerar algoritmos criptográficos.
Ao migrar o transporte do pgBackRest para TLS, o processamento deixa de ser uma tarefa genérica de software e passa a usufruir do descarregamento por hardware (hardware offloading). Como consequência, a carga de CPU no servidor de banco de dados despenca drasticamente durante a janela de backup, preservando a capacidade computacional para o processamento de queries e transações da aplicação.
Previsibilidade e Linearidade de Performance
Com a remoção dos gargalos de concorrência e o alívio no processamento, o throughput (taxa de transferência) do backup passa a escalar de forma linear, respondendo diretamente à capacidade real dos discos e da rede. Se a infraestrutura dispõe de um link de 10Gbps, a comunicação via TLS é capaz de saturar essa banda de forma muito mais estável do que o SSH. Cenários reais de migração demonstram reduções drásticas no tempo total de execução, transformando janelas de backup que duravam horas em procedimentos concluídos em poucos minutos.
Sustentabilidade e Gestão de Capacidade
A otimização da camada de transporte de dados vai além do ganho técnico de performance; ela reflete diretamente nos indicadores de eficiência de recursos e na previsibilidade de custos operacionais de longo prazo.
- Redução de falsos positivos no monitoramento: O pico de consumo de CPU gerado pelo processamento do SSH durante a madrugada frequentemente ultrapassa os limites de alerta em plataformas de observabilidade. Esses falsos positivos geram alertas desnecessários para os times de plantão (on-call), mascarando incidentes reais e causando fadiga de alertas. A normalização do consumo de recursos trazida pelo TLS devolve a estabilidade ao monitoramento.
- Prevenção de upgrades desnecessários de hardware: É comum que equipes decidam realizar o upgrade de instâncias de banco de dados em ambientes de nuvem para classes de máquinas maiores e significativamente mais caras sob a justificativa de que a CPU atinge o limite máximo durante a madrugada. Identificar que o gargalo reside no transporte via SSH permite solucionar o problema de performance otimizando a configuração de software, gerando economia real e estendendo o ciclo de vida da infraestrutura atual com custo zero de hardware.
A Tomada de Decisão
A evolução da infraestrutura de banco de dados exige reavaliar continuamente as camadas de software que sustentam a operação. Para determinar se o seu ambiente atingiu o limite do modelo tradicional, recomendam-se duas ações práticas:
- O diagnóstico: Durante a próxima execução do backup principal pelo pgBackRest, analise os gráficos de consumo detalhado de CPU do servidor de banco de dados. Verifique se há um pico acentuado de consumo associado especificamente aos processos ssh ou sshd. Se um ou mais núcleos estiverem saturados por esses processos enquanto o throughput de rede permanece abaixo da capacidade nominal, seu ambiente atingiu o teto do SSH.
- A recomendação: Para ambientes que gerenciam bancos de dados PostgreSQL que já operam ou estão entrando na escala de Terabytes, ou onde o RTO precisa ser minimizado ao extremo, migrar o transporte do pgBackRest de SSH para TLS com certificados digitais não é apenas uma boa prática de segurança. É uma decisão de engenharia de performance indispensável para garantir a sustentabilidade e a previsibilidade da operação de dados.
Otimizar o backup em larga escala vai muito além de comprar mais hardware ou contratar links de rede mais velozes. Trata-se de remover os intermediários invisíveis da arquitetura de software para garantir que cada ciclo de processamento e cada Megabit contratado sejam convertidos em eficiência, segurança e disponibilidade real para o negócio.
Quer receber conteúdos sobre engenharia e performance de PostgreSQL?
