NubliVault for PostgreSQL
Volte o banco a qualquer segundo.
Backup contínuo de PostgreSQL, criptografado na própria VM e enviado direto para dois destinos com retenções diferentes. O restore leva o banco ao instante que você escolher, em outro servidor.
Em produção
Restore ao segundo
O log de transações (WAL) sai continuamente da VM. O restore escolhe o ponto — “hoje às 14:32:10” — e para no último registro antes dele.
Dois destinos, duas retenções
Por exemplo, 30 dias na nuvem de origem (OCI) e 3 dias fora dela (AWS), para recuperação de desastre. Cada destino guarda uma cadeia completa e restaura sozinho.
Seguro por padrão
Criptografia AES-256 na VM, com chave exclusiva por VM. Na AWS, credencial temporária de 1 hora e bucket com Object Lock: nem a credencial da VM apaga o backup.
Como funciona
- 1
Um agente leve é instalado na VM do banco. Ele só faz conexões de saída (HTTPS) e não abre porta nenhuma.
- 2
Na matrícula, a VM gera a própria chave, que nunca sai dela, e recebe um certificado com o nome dela. É esse certificado que dá acesso ao armazenamento.
- 3
O backup completo roda de tempos em tempos e o incremental, todo dia. O incremental é por bloco: envia só as páginas do banco que mudaram.
- 4
O WAL vai para os dois destinos continuamente, em minutos. O agente acompanha a sequência e alerta se faltar um trecho.
- 5
Para restaurar, você escolhe o ponto no tempo e o servidor de destino. Ele baixa direto do armazenamento, com credencial só de leitura.
Os dados nunca passam pelo console
Cada VM envia backup e WAL direto para os destinos. O console do NubliVault só troca estado e ordens com o agente.
VM do banco
- PostgreSQL
- Motor de backup: criptografa e comprime na VM
- Agente NubliVault: agenda, limita a leitura, reporta
OCI Object Storage
retenção longa · bucket versionado
AWS S3
recuperação de desastre · Object Lock
Console NubliVaultsó estado e ordens
Segurança em todas as camadas
Criptografia
AES-256 na própria VM, antes de sair, com chave exclusiva por VM. TLS em trânsito. O armazenamento só recebe dado já criptografado.
Credenciais
Nenhuma chave fixa da AWS na VM. O certificado da VM gera uma credencial de 1 hora, renovada sozinha, que só enxerga o prefixo daquela VM.
Contra apagamento
Na AWS, bucket versionado e com Object Lock: a credencial da VM não apaga, não destrava e não encurta o bloqueio. Na OCI, bucket versionado, e a chave da VM grava mas não apaga versões.
Rede
Só conexões de saída HTTPS. Nenhuma porta nova aberta na VM do banco.
Desempenho
O agente limita a leitura de disco durante o backup, ajustada ao disco da VM, para não pesar nas transações.
Restore
Sempre em outro servidor, com credencial só de leitura. Restaurar por cima do banco de origem em uso é bloqueado.
Console
Módulo do NubliVault, ao lado do backup de arquivos. Segundo fator obrigatório, perfis de acesso e auditoria de cada ação. Ninguém vê chave de criptografia pelo console.
Integração
Integrado à AWS (IAM Roles Anywhere, S3 Object Lock). O motor de backup é um componente open source consolidado, que a Nublify integra, testa e mantém em versão fixada.
Requisitos
O que a VM do banco e o servidor de restore precisam ter.
- PostgreSQL
- Versão 16. Outras versões sob consulta.
- Sistema
- Linux x86_64 com systemd.
- Rede
- Saída HTTPS (443) para o console e para cada destino (AWS S3, OCI Object Storage). Nenhuma porta de entrada.
- Disco livre
- Folga para acumular WAL se um destino ficar fora do ar. Orientação: duas vezes o WAL de um dia.
- Ativação
- Se o arquivamento de WAL estiver desligado, uma reinicialização do PostgreSQL, sempre em janela combinada com você.
- PostgreSQL em contêiner
- O contêiner precisa rodar com um processo init (por exemplo, --init no Docker).
- Servidor de restore
- O agente instalado, o mesmo PostgreSQL (versão maior) e disco para o banco inteiro. Não precisa acessar o servidor de origem.
Perguntas técnicas
- O backup deixa o banco lento?
- O backup lê o disco do banco, então o agente limita essa leitura durante o backup, com um teto ajustado ao disco da VM. O limite fica sempre ligado. O WAL é enviado continuamente e não pesa de forma perceptível.
- O que é o incremental por bloco?
- Em vez de reenviar cada arquivo do banco que foi tocado, o backup incremental envia só as páginas que mudaram desde o anterior. Em bancos com alterações espalhadas, é a diferença entre reenviar quase o banco todo e enviar só o que mudou.
- Até que ponto dá para voltar?
- A qualquer segundo dentro da retenção de cada destino. O restore para no último registro de transação antes do instante pedido e confere a consistência do banco ao final.
- Por que dois destinos fazem dois backups?
- Cada destino guarda uma cadeia completa e independente. Se um falhar, o outro restaura sozinho. Os backups dos dois destinos são agendados em horários diferentes.
- E se a internet cair?
- O PostgreSQL continua funcionando normalmente. O WAL fica guardado na VM e é enviado quando a conexão volta, sem perda, desde que haja disco livre para acumulá-lo.
- O que acontece se um trecho do WAL se perder?
- O agente acompanha a sequência do WAL nos destinos. Se faltar um trecho, o console alerta e um novo backup completo é disparado, para que o ponto de restore volte a avançar.
- Uma VM invadida consegue apagar o backup?
- Na AWS, não: a credencial da VM dura 1 hora, só enxerga o prefixo dela e não consegue apagar, destravar o Object Lock, desligar o versionamento nem apagar o bucket. Na OCI, a chave da VM não apaga versões, então o histórico sobrevive pelo versionamento.
- Alguém da Nublify consegue ler os meus dados?
- O backup sai criptografado da sua VM. A chave de cada VM fica criptografada no cofre do NubliVault, porque é ela que permite o restore. O acesso ao cofre é restrito a poucas pessoas da Nublify, exige segundo fator e todo uso fica registrado.
Quer proteger os seus bancos?
Conte quantas VMs de banco você tem, onde estão e por quanto tempo precisa guardar. A engenharia da Nublify responde com o desenho e o roteiro de ativação.
Falar com a engenharia