Como fazer backup do banco de dados do seu app (e realmente conseguir restaurá-lo)

Para fazer backup do banco de dados do seu app, exporte-o para um arquivo em uma agenda (no Postgres, a ferramenta padrão é o pg_dump), guarde as cópias em um lugar separado do banco de dados e restaure uma delas regularmente em um banco de dados vazio para provar que funciona. Faça um backup extra logo antes de qualquer mudança arriscada. Seu backup do código, seja um repositório no GitHub ou uma exportação, não inclui seus dados.

Este guia é para quem mantém um app pequeno e quer parar de se preocupar com a possibilidade de perdê-lo. Ele usa Postgres nos exemplos, já que a maioria dos apps criados com IA usa esse banco, mas os princípios valem para qualquer banco de dados.

O que um backup precisa cobrir

Um app é mais do que o seu banco de dados. Saiba qual parte cada backup protege.

O quê	Onde fica	Como fazer o backup
Código	Arquivos do projeto, Git	Sincronização com o GitHub ou exportação do projeto
Dados (usuários, registros)	O banco de dados	Dump do banco de dados em uma agenda
Arquivos enviados	Armazenamento de objetos	Copiar o bucket, ou manter os originais em outro lugar
Segredos e configurações	Configurações do projeto, painéis dos provedores	Um gerenciador de senhas, sempre atualizado

Os dados são a parte que você não consegue recriar. O código pode ser reescrito e as configurações podem ser digitadas de novo; os pedidos dos seus clientes, não.

Passo 1: decida quanto você pode perder

Duas perguntas definem o seu plano de backup:

Quantos dados recentes você pode se dar ao luxo de perder? Se você faz backup uma vez por dia e o banco falha à noite, perde as mudanças daquele dia. Para um app de hobby, tudo bem. Para um app que recebe pedidos, talvez não esteja.
Por quanto tempo o app pode ficar fora do ar enquanto você restaura? Um banco pequeno é restaurado em minutos. Um banco grande pode levar bem mais tempo, e você precisa saber disso antes de precisar dele.

Para a maioria dos apps pequenos, um backup automático diário mais um backup manual antes de mudanças arriscadas é um bom começo. Apps que envolvem dinheiro ou dados de saúde merecem backups mais frequentes, ou um banco de dados gerenciado com recuperação em um ponto no tempo (a capacidade de restaurar para qualquer momento, não apenas para o último backup).

Passo 2: veja o que seu host já faz

Muitos provedores de banco de dados gerenciados fazem backups automáticos. Descubra:

Os backups estão ativados no seu plano, e com que frequência são executados?
Por quanto tempo são mantidos?
Você pode restaurar para um ponto no tempo, ou apenas para um instantâneo diário?
Você pode baixar um backup, ou só restaurá-lo dentro do sistema deles?

Os backups dos provedores são úteis, mas compartilham um único ponto de falha com o seu banco de dados: a conta. Se a conta for encerrada, suspensa ou o projeto for excluído, os backups podem ir junto. Por isso você também quer uma cópia própria.

Passo 3: faça um dump com o pg_dump

O pg_dump exporta um banco de dados Postgres para um arquivo. Ele lê um instantâneo consistente, então o app pode continuar funcionando enquanto ele trabalha.

Um comando típico, usando a string de conexão que o seu app já tem em uma variável de ambiente:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

O que as opções fazem:

--format=custom gera um arquivo compactado que o pg_restore consegue ler, e permite restaurar tabelas individuais depois. Use --format=plain se preferir um arquivo .sql legível.
--no-owner deixa de fora os comandos de propriedade, o que facilita a restauração em outro banco de dados.
A data no nome do arquivo mantém os backups separados.

A versão do pg_dump deve ser igual ou mais nova que a versão do Postgres do seu banco de dados. Um pg_dump mais antigo pode se recusar a rodar.

Se você cria apps com IA e não quer mexer na linha de comando, pode pedir:

Crie um backup do banco de dados do app usando pg_dump no formato custom, com a data de hoje no nome do arquivo. Não mostre a string de conexão nem nenhum segredo. Me diga o nome do arquivo e o tamanho quando terminar.

Passo 4: automatize

Backups manuais acabam sendo esquecidos. Automatize-os com o que a sua configuração suportar:

Os backups agendados do seu provedor de banco de dados, se ele oferecer.
Uma tarefa agendada em um servidor ou serviço de CI que roda o pg_dump e envia o arquivo para o armazenamento.
Um serviço de backup hospedado que se conecta ao seu banco de dados.

Qualquer que seja a opção, configure para que ela avise quando um backup falhar. Uma tarefa de backup que falhou em silêncio por três meses é a história de terror clássica.

Passo 5: guarde cópias em outro lugar

A regra prática é frequentemente chamada de 3-2-1: três cópias dos seus dados, em dois tipos diferentes de armazenamento, com uma cópia fora do local principal. Para um app pequeno, uma versão prática é:

O banco de dados ativo
Os backups automáticos do próprio provedor
Seus dumps em um armazenamento separado, como um bucket de armazenamento de objetos em outra conta

Além disso:

Restrinja o acesso. Um backup contém os dados de todos os usuários. Trate-o como o banco de dados ativo.
Tenha uma política de retenção. Por exemplo, backups diários por duas semanas e mensais por um ano. Apague os antigos de propósito, e lembre que as leis de privacidade podem exigir que você apague dados pessoais quando solicitado.
Nunca faça commit de backups no Git. Um dump dentro de um repositório é um vazamento de dados esperando para acontecer.

Passo 6: teste uma restauração

Um backup só vale tanto quanto a sua última restauração bem-sucedida. Pelo menos a cada poucos meses, e depois de qualquer mudança no processo de backup:

Crie um banco de dados novo e vazio. Nunca restaure por cima do banco ativo para testar.
Restaure o backup mais recente nele:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Para um arquivo .sql puro, use psql "$TEST_DATABASE_URL" -f backup.sql.

Confira se todas as tabelas existem, compare a quantidade de linhas com o banco ativo e veja alguns registros recentes.
Aponte uma cópia do app para ele e faça login, se for possível.
Anote quanto tempo a restauração levou. Esse é o seu tempo real de recuperação.

Passo 7: faça backup antes de mudanças arriscadas

Faça um backup novo logo antes de:

Rodar uma migração de banco de dados que apague ou renomeie colunas
Importar dados em massa
Deixar um agente de IA fazer grandes mudanças no modelo de dados
Apagar registros antigos

Em um app feito com IA, o agente pode mudar a estrutura das tabelas como parte de um recurso. Checkpoints e controle de versão revertem o seu código, mas não restauram linhas apagadas. Um backup de trinta segundos antes de uma grande mudança é um seguro barato.

Erros comuns

Achar que o Git ou uma exportação do código é um backup. Ele tem o código, não os dados.
Nunca testar uma restauração. Muitos backups acabam vazios, incompletos ou ilegíveis justamente quando são necessários.
Guardar os backups na mesma conta do banco de dados. Uma conta comprometida ou encerrada leva os dois.
Esquecer os arquivos enviados. O banco de dados guarda o caminho do arquivo; a imagem em si fica no armazenamento.
Deixar segredos em scripts de backup. Leia a string de conexão de uma variável de ambiente, nunca do texto do script. Veja como manter suas chaves de API seguras.

Backups e o Mythex

Projetos do Mythex podem ter um banco de dados Postgres dedicado, e os dados de conexão dele são injetados no workspace e no app publicado. A documentação do Mythex não descreve um recurso de backup ou restauração de banco de dados, então planeje o seu: peça ao agente para fazer um dump, baixe-o e guarde-o em um lugar seguro, especialmente antes de grandes mudanças. Uma exportação do projeto (Pro) contém o seu código, com segredos e node_modules deixados de fora; ela não contém linhas do banco de dados. Veja Database e Data ownership na documentação. Para saber mais sobre o próprio banco de dados, leia o que é Postgres.

Checklist de backup

Decidi quantos dados posso perder e por quanto tempo posso ficar fora do ar
Verifiquei quais backups automáticos o meu provedor de banco de dados oferece
Meu dump próprio roda em uma agenda, e falhas me avisam
Cópias guardadas separadamente do banco de dados, com acesso restrito
Política de retenção escrita
Arquivos enviados incluídos no backup, além do banco de dados
Restauração testada em um banco vazio, com a quantidade de linhas conferida
Backup feito antes de cada mudança arriscada

Perguntas

Com que frequência devo fazer backup do banco de dados do meu app?

Ajuste a frequência à quantidade de dados que você pode perder. Para a maioria dos apps pequenos, um backup automático diário é um mínimo sensato, além de um backup manual antes de qualquer mudança arriscada, como uma migração, uma importação ou um recurso novo de grande porte.

Exportar meu código é o mesmo que fazer backup dos meus dados?

Não. Uma exportação do código ou um repositório no GitHub contém os arquivos do seu app, não as linhas do banco de dados. Seus usuários, pedidos e publicações ficam no banco de dados e precisam de um backup próprio.

O que é o pg_dump?

O pg_dump é a ferramenta de linha de comando padrão que vem com o Postgres para exportar um banco de dados para um arquivo. Ele pode gerar SQL puro ou um formato personalizado compactado, e as ferramentas de restauração correspondentes são o psql para arquivos SQL e o pg_restore para o formato personalizado.

Como sei que meu backup funciona?

Restaure-o. Carregue o backup em um banco de dados separado e vazio e confira se as tabelas existem e se a quantidade de linhas e alguns registros recentes batem com os dados ao vivo. Um backup que você nunca restaurou é um palpite.

Onde devo guardar os backups do banco de dados?

Em um lugar separado do próprio banco de dados, de preferência com outro provedor ou outra conta, e com acesso restrito a você. Os backups contêm os dados de todos os seus usuários, então trate-os com o mesmo cuidado que o banco de dados ativo.