O que é o WAL-RUS

Se você roda PostgreSQL em produção, já sabe que backup não e opcional. O WAL-RUS e uma reescrita em Rust do WAL-G, uma das ferramentas de backup e restauração mais usadas no ecossistema PostgreSQL. O projeto ganhou destaque depois de ser apresentado em um artigo da ClickHouse sobre backups de Postgres em Rust.

O WAL-G original nasceu como evolução do WAL-E e e escrito em Go. Ele cuida de duas coisas ao mesmo tempo: o backup completo do banco (base backup) e o arquivamento continuo dos logs de transação (os arquivos WAL). Com isso, você consegue restaurar o banco para qualquer ponto no tempo.

A proposta do WAL-RUS e manter essa mesma lógica, mas trocar a linguagem por Rust. A ideia e aproveitar a segurança de memoria e o controle fino de recursos que o Rust oferece para deixar a ferramenta mais previsível sob carga pesada, que é exatamente quando um backup não pode falhar.

Como funciona

O nome WAL vem de Write-Ahead Log. Antes de gravar qualquer alteração nos arquivos de dados, o PostgreSQL escreve a operação em um log sequencial. Esse log e a fonte da verdade para recuperação após uma queda.

Ferramentas como WAL-G e WAL-RUS se conectam a esse mecanismo de duas formas. Primeiro, fazem um base backup, que é uma copia consistente de todo o diretório de dados. Depois, arquivam continuamente cada segmento de WAL gerado a partir daquele ponto. Para restaurar, a ferramenta restaura o base backup e reaplica os WALs até o momento desejado.

Esse modelo e o que permite o point-in-time recovery (PITR). Em vez de voltar só para o último backup da meia-noite, você pode pedir para restaurar o banco exatamente como ele estava as 14h37, segundos antes de alguém rodar um DELETE sem WHERE.

Principais recursos

O conjunto de recursos herdado do WAL-G cobre o que um time de produção espera de uma ferramenta de backup seria. Os destaques principais são:

  • Archiving continuo de WAL: cada segmento de log e enviado para o storage assim que é fechado.
  • Base backups completos e incrementais: os backups delta enviam apenas as páginas que mudaram, economizando espaço e banda.
  • Point-in-time recovery: restauração para qualquer instante coberto pelos WALs arquivados.
  • Compressão integrada: suporte a algoritmos como lz4, zstd e brotli para reduzir o tamanho dos backups.
  • Storage em nuvem: envio direto para S3, Google Cloud Storage, Azure Blob e compatíveis.

A aposta do WAL-RUS e entregar essa mesma lista, porém com o comportamento de memoria e desempenho do Rust. Em uma ferramenta que processa gigabytes de WAL por hora, vazamentos e picos de memoria importam muito.

Como começar

Como o WAL-RUS e um projeto mais novo, o caminho recomendado e começar entendendo bem o fluxo do próprio WAL-G, que é o mesmo conceito. Os passos gerais para configurar backup continuo de PostgreSQL são:

Passo 1: defina um destino de storage. Na maioria dos casos e um bucket S3 ou compatível, com chaves de acesso configuradas em variáveis de ambiente.

Passo 2: configure o archive_command no PostgreSQL.conf para chamar a ferramenta a cada segmento de WAL fechado. E essa linha que liga o PostgreSQL ao backup continuo.

Passo 3: rode o primeiro base backup com o comando de backup-push da ferramenta. A partir dai, mantenha o archiving rodando e agende base backups periódicos, por exemplo um por dia.

Exemplo prático

Imagine um cenário comum: uma API .NET ou Node usando PostgreSQL como banco principal, rodando em um servidor Linux. Você quer dormir tranquilo sabendo que pode voltar no tempo se algo der errado.

Você configura o archive_command para empurrar cada WAL para um bucket. Todo dia de madrugada, um cron dispara um base backup completo. Os arquivos vao todos comprimidos para a nuvem, sem ocupar disco local além do necessário.

Na hora do desastre, alguém apagou uma tabela inteira as 14h37. Você para a aplicação, restaura o último base backup e instruí a ferramenta a reaplicar os WALs até as 14h36. O banco volta ao estado anterior ao erro, com perda mínima de dados. Esse fluxo e idêntico em WAL-G e WAL-RUS.

Comparação com alternativas

O WAL-RUS não esta sozinho nesse espaço. As alternativas mais comuns para backup de PostgreSQL incluem o próprio WAL-G em Go, o pgBackRest escrito em C, o Barman em Python e o clássico pg_dump que vem com o PostgreSQL.

O pg_dump e ótimo para bancos pequenos e exportações lógicas, mas não faz PITR nem backup continuo. O pgBackRest e maduro, robusto e muito usado em ambientes grandes. O Barman tem foco em gestão centralizada de vários servidores.

O diferencial da dupla WAL-G e WAL-RUS sempre foi a integração nativa e eficiente com storage em nuvem e a velocidade de envio. A reescrita em Rust mira justamente em levar essa eficiência ainda mais longe, com uso de recursos mais previsível.

Pontos positivos e limitações

Do lado positivo, a escolha de Rust traz segurança de memoria sem garbage collector, o que significa pausas mais previsíveis durante operações longas. Para um processo que roda em paralelo com o banco em produção, essa previsibilidade e valiosa.

Outro ponto forte e herdar um modelo de backup já comprovado pelo WAL-G, em vez de reinventar a roda. Quem já conhece o fluxo do WAL-G encontra terreno familiar.

A principal limitação e a maturidade. Por ser uma reescrita mais recente, o WAL-RUS ainda não tem o mesmo tempo de estrada e a mesma base de usuários em produção que o WAL-G ou o pgBackRest. Para sistemas críticos, vale testar bastante antes de migrar e manter o WAL-G como referência.

Casos de uso reais

Essa abordagem de backup continuo serve para perfis bem definidos. Veja alguns cenários concretos:

  • Startups com PostgreSQL em nuvem: precisam de PITR confiável sem montar uma infraestrutura cara de backup.
  • Times de DevOps: querem padronizar o backup de vários bancos enviando tudo para o mesmo bucket S3.
  • SaaS multi-tenant: onde perder horas de dados de clientes não e uma opcao aceitável.
  • Desenvolvedores solo: que rodam um servidor próprio e querem uma rede de segurança real sem complexidade exagerada.

Em todos esses casos, o ganho e o mesmo: capacidade de voltar o banco para um instante específico, e não apenas para o último snapshot do dia.

Dicas e boas práticas

Quem já apanhou com backup aprende algumas licoes na marca. A primeira e a mais importante: backup que nunca foi restaurado não e backup, e esperança. Teste a restauração periodicamente em um ambiente separado.

Monitore o archiving. Se o archive_command começa a falhar, os WALs se acumulam no servidor e podem encher o disco, derrubando o banco. Configure alertas para falhas de envio e para o espaço em disco do diretório de WAL.

Defina uma política de retenção clara. Manter base backups e WALs para sempre custa caro em storage. Decida quantos dias de PITR você realmente precisa e configure a limpeza automática dos backups antigos.

Vale a pena?

Para quem leva PostgreSQL em produção a serio, adotar uma ferramenta de backup continuo com PITR vale muito a pena, seja WAL-G, WAL-RUS ou pgBackRest. A diferença entre perder cinco minutos ou um dia inteiro de dados costuma justificar o esforço de configuração.

O WAL-RUS em si e uma aposta interessante para quem gosta de Rust e quer um comportamento de recursos mais previsível. Mas, por ser mais novo, ainda pede cautela em ambientes críticos. Para produção pesada hoje, WAL-G e pgBackRest seguem como escolhas mais conservadoras.

O próximo passo sugerido e simples: pegue um banco de testes, configure o archive_command e o primeiro base backup, e force uma restauração com point-in-time recovery. Só depois de ver o banco voltar no tempo com seus próprios olhos você vai confiar de verdade na sua estratégia de backup.