Backups e restauração

Todo banco gerenciado da Veloz tem backup automático. A recuperação pontual (PITR) vale para PostgreSQL; MySQL e Redis têm cópia diária. Esta página diz exatamente o que é copiado, quando, por quanto tempo fica guardado e como restaurar. Os tempos são medidos, não estimados.

Resumo para agentes

Tier compartilhado (padrão)

É o tier de todo banco PostgreSQL criado por veloz db create e pelos templates. Cada cluster tem uma instância primária e uma réplica em outra zona de disponibilidade. Redis compartilhado grava snapshots em armazenamento de objetos e os recarrega ao reiniciar.

• Backup base diário às 05:00 (horário de Brasília), tirado da réplica para não pesar na primária.
• Arquivamento contínuo de transações: cada segmento do log de transações é enviado ao armazenamento de objetos assim que fecha, e no máximo a cada 5 minutos. É isso que permite restaurar para qualquer instante, não só para a hora do backup base.
• Retenção de 3 dias. Você pode voltar o banco para qualquer segundo dentro dessa janela.
• Retenção maior em planos Enterprise. Alocamos janelas mais longas de PITR (30, 90 dias ou o que o seu contrato exigir) para clientes Enterprise. Peça pelo suporte ou por contato@onveloz.com.
• Failover automático. Se a primária cair, a réplica assume sem ação sua. Backups não param durante o failover.

Tier dedicado

Uma instância exclusiva, sem réplica.

• Cópia completa diária de todos os bancos da instância (PostgreSQL, MySQL ou Redis), comprimida e enviada ao armazenamento de objetos.
• Retenção de 7 dias, uma cópia por dia da semana. Planos Enterprise podem contratar retenção mais longa.
• Restaurar significa voltar para o estado da cópia escolhida. Não há recuperação pontual entre cópias.

Como pedir uma restauração

Abra um chamado de suporte informando:

1. O banco (nome ou ID, veja veloz db list).
2. O instante para o qual quer voltar (compartilhado) ou o dia da cópia (dedicado).
3. Se quer substituir o banco atual ou restaurar ao lado em um banco novo para comparar antes de trocar. Recomendamos o segundo.

veloz support create --subject "Restaurar banco" \
  --message "Banco db_abc123, restaurar para 2026-10-22 02:55 BRT, em um banco novo ao lado."

Pelo MCP, seu agente usa support_create com o mesmo conteúdo. O chamado é classificado como urgente e começa a ser atendido imediatamente, 24/7. O agente de suporte roda em uma VM isolada com acesso só aos recursos da sua organização, e uma restauração que substitui o banco atual exige sua confirmação explícita no chamado.

Tempos medidos

Restauração de um cluster compartilhado completo, feita em 22 de outubro de 2026, para um instante escolhido (recuperação pontual):

Cópia de um único banco de 445 MB entre clusters: exportar 11 s, importar 14 s.

Bancos maiores levam proporcionalmente mais tempo na etapa de recuperação. O chamado informa a estimativa antes de começar.

O que o backup não cobre

• Volumes persistentes e Blob Storage têm armazenamento replicado, mas não têm versão anterior automática. Se o seu app apaga um arquivo, ele é apagado.
• Variáveis de ambiente e configuração do serviço ficam na plataforma e não são afetadas por restauração de banco.
• Bancos que você mesmo roda em um serviço comum (por exemplo, um Postgres subido por Dockerfile) não são gerenciados e não têm backup da Veloz.

Faça seu próprio backup também

Backup gerenciado não substitui uma cópia sua. Use o túnel local e o pg_dump:

veloz db tunnel <id> --port 5433
pg_dump -h localhost -p 5433 -U <user> -Fc <banco> > backup.dump

Agende isso onde preferir, ou peça ao seu agente para configurar.

Próximos passos

• Arquitetura e continuidade — Failover, uptime e o que acontece em cada falha
• Bancos de dados — Criar, conectar e gerenciar
• Suporte — Como o suporte funciona