Como fazer backup da base de dados da sua app (e como a restaurar de facto)

Para fazer backup da base de dados da sua app, exporte-a para um ficheiro de forma agendada (no Postgres, a ferramenta padrão é o pg_dump), guarde as cópias num local separado da base de dados e restaure regularmente uma delas numa base de dados vazia para comprovar que funciona. Faça uma cópia extra logo antes de qualquer alteração arriscada. O backup do código, seja um repositório no GitHub ou uma exportação, não inclui os seus dados.

Este guia destina-se a quem gere uma app pequena e quer deixar de se preocupar com a possibilidade de a perder. Usa o Postgres nos exemplos, porque a maioria das apps criadas com IA usa esta base de dados, mas os princípios aplicam-se a qualquer base de dados.

O que um backup tem de cobrir

Uma app é mais do que a sua base de dados. Saiba que parte cada backup protege.

O quê	Onde fica	Como fazer o backup
Código	Ficheiros do projeto, Git	Sincronização com o GitHub ou exportação do projeto
Dados (utilizadores, registos)	A base de dados	Exportação da base de dados agendada
Ficheiros carregados	Armazenamento de objetos	Copiar o bucket, ou guardar os originais noutro local
Segredos e definições	Definições do projeto, painéis dos fornecedores	Um gestor de palavras-passe, mantido atualizado

Os dados são a parte que não se pode recriar. O código pode ser reescrito e as definições podem ser introduzidas de novo; as encomendas dos seus clientes não.

Passo 1: Decida quanto pode perder

Duas perguntas definem o seu plano de backup:

Quanto dados recentes pode dar-se ao luxo de perder? Se faz backup uma vez por dia e a base de dados falha ao fim da tarde, perde as alterações desse dia. Para uma app de passatempo isto é aceitável. Para uma app que recebe encomendas, pode não ser.
Quanto tempo pode a app estar parada enquanto restaura? Uma base de dados pequena restaura-se em minutos. Uma grande pode demorar muito mais, e convém saber isso antes de precisar.

Para a maioria das apps pequenas, um backup automático diário mais um backup manual antes de alterações arriscadas é um bom ponto de partida. As apps que envolvem dinheiro ou dados de saúde merecem backups mais frequentes, ou uma base de dados gerida com recuperação para um ponto no tempo (a capacidade de restaurar para qualquer momento, e não apenas para o último backup).

Passo 2: Verifique o que o seu fornecedor já faz

Muitos fornecedores de bases de dados geridas fazem backups automáticos. Descubra:

Os backups estão ativos no seu plano, e com que frequência são feitos?
Durante quanto tempo são guardados?
Pode restaurar para um ponto no tempo, ou apenas para um instantâneo diário?
Pode descarregar um backup, ou só restaurá-lo dentro do sistema deles?

Os backups do fornecedor são úteis, mas partilham um ponto único de falha com a base de dados: a conta. Se a conta for encerrada, suspensa ou o projeto for eliminado, os backups podem desaparecer com ela. Por isso também quer uma cópia sua.

Passo 3: Faça uma exportação com o pg_dump

O pg_dump exporta uma base de dados Postgres para um ficheiro. Lê um instantâneo consistente, por isso a app pode continuar a funcionar enquanto ele trabalha.

Um comando típico, usando a string de ligação que a sua app já tem numa variável de ambiente:

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

O que fazem as opções:

--format=custom escreve um ficheiro comprimido que o pg_restore consegue ler e que permite restaurar tabelas individuais mais tarde. Use --format=plain se preferir um ficheiro .sql legível.
--no-owner deixa de fora os comandos de propriedade, o que torna a restauração numa base de dados diferente mais simples.
A data no nome do ficheiro mantém os backups separados.

A versão do pg_dump deve ser igual ou mais recente que a versão do Postgres da sua base de dados. Uma versão mais antiga pode recusar-se a funcionar.

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

Crie um backup da base de dados da app com o pg_dump em formato custom, com a data de hoje no nome do ficheiro. Não mostre a string de ligação nem qualquer segredo. Diga-me o nome do ficheiro e o tamanho quando terminar.

Passo 4: Automatize

Os backups manuais acabam por ser esquecidos. Automatize-os com o que a sua configuração permitir:

Os backups agendados do fornecedor da base de dados, se o oferecer.
Uma tarefa agendada num servidor ou serviço de CI que executa o pg_dump e carrega o ficheiro para o armazenamento.
Um serviço de backup alojado que se liga à sua base de dados.

Escolha o que escolher, faça com que lhe avise quando um backup falhar. Uma tarefa de backup que falhou em silêncio durante três meses é a clássica história de terror.

Passo 5: Guarde cópias noutro local

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

A base de dados em produção
Os backups automáticos do próprio fornecedor
As suas exportações em armazenamento separado, como um bucket de armazenamento de objetos numa conta diferente

Além disso:

Restrinja o acesso. Um backup contém os dados de todos os utilizadores. Trate-o como trataria a base de dados em produção.
Tenha uma política de retenção. Por exemplo, backups diários durante duas semanas e mensais durante um ano. Elimine os antigos de forma deliberada, e lembre-se de que a legislação de privacidade pode exigir que apague dados pessoais quando lho pedirem.
Nunca coloque backups no Git. Uma exportação num repositório é uma fuga de dados à espera de acontecer.

Passo 6: Teste uma restauração

Um backup só é tão bom como a sua última restauração bem-sucedida. Pelo menos a cada poucos meses, e depois de qualquer alteração ao processo de backup:

Crie uma base de dados nova e vazia. Nunca restaure por cima da base de dados em produção para testar.
Restaure o backup mais recente nela:

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

Para um ficheiro .sql simples, use em vez disso psql "$TEST_DATABASE_URL" -f backup.sql.

Verifique se todas as tabelas existem, compare o número de registos com a base de dados em produção e veja alguns registos recentes.
Aponte uma cópia da app para esta base de dados e inicie sessão, se for possível.
Anote quanto tempo demorou a restauração. Esse é o seu tempo real de recuperação.

Passo 7: Faça backup antes de alterações arriscadas

Faça um backup novo imediatamente antes de:

Executar uma migração da base de dados que elimine ou renomeie colunas
Importar dados em massa
Deixar um agente de IA fazer alterações grandes ao modelo de dados
Eliminar registos antigos

Numa app criada com IA, o agente pode alterar a estrutura das tabelas como parte de uma funcionalidade. Os checkpoints e o controlo de versões revertem o seu código, mas não repõem as linhas eliminadas. Um backup de trinta segundos antes de uma grande alteração é um seguro barato.

Erros comuns

Assumir que o Git ou uma exportação do código é um backup. Tem o código, não os dados.
Nunca testar uma restauração. Muitos backups revelam-se vazios, incompletos ou ilegíveis só quando são precisos.
Guardar os backups na mesma conta que a base de dados. Uma conta comprometida ou encerrada perde as duas coisas.
Esquecer os ficheiros carregados. A base de dados guarda o caminho do ficheiro; a imagem em si fica no armazenamento.
Deixar segredos nos scripts de backup. Leia a string de ligação de uma variável de ambiente, nunca do texto do script. Veja como manter as chaves de API seguras.

Backups e a Mythex

Os projetos da Mythex podem ter uma base de dados Postgres dedicada, e os respetivos detalhes de ligação são injetados no espaço de trabalho e na app publicada. A documentação da Mythex não descreve uma funcionalidade de backup ou restauro da base de dados, por isso planeie o seu próprio: peça ao agente para fazer uma exportação, descarregue-a e guarde-a em segurança, sobretudo antes de alterações grandes. Uma exportação do projeto (Pro) contém o seu código, sem os segredos nem o node_modules; não contém os registos da base de dados. Veja Base de dados e Propriedade dos dados na documentação. Para saber mais sobre a própria base de dados, leia o que é o Postgres.

Lista de verificação para backups

Decidiu quanto dados pode perder e quanto tempo pode estar parado
Verificou que backups automáticos o seu fornecedor de base de dados oferece
A sua exportação corre de forma agendada, e as falhas avisam-no
As cópias estão guardadas separadamente da base de dados, com acesso restrito
A política de retenção está escrita
Os ficheiros carregados também têm backup, além da base de dados
A restauração foi testada numa base de dados vazia, com o número de registos verificado
Foi feito um backup antes de cada alteração arriscada

Perguntas

Com que frequência devo fazer backup da base de dados da minha app?

Ajuste à quantidade de dados que pode dar-se ao luxo de perder. Para a maioria das apps pequenas, um backup automático diário é um mínimo sensato, mais um backup manual antes de qualquer alteração arriscada, como uma migração, uma importação ou uma nova funcionalidade de grande dimensão.

Exportar o 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 ficheiros da sua app, não os registos da base de dados. Os seus utilizadores, encomendas e publicações vivem na base de dados e precisam de um backup próprio.

O que é o pg_dump?

O pg_dump é a ferramenta de linha de comandos padrão que vem com o Postgres para exportar uma base de dados para um ficheiro. Pode escrever SQL simples ou um formato personalizado comprimido, e as ferramentas de restauro correspondentes são o psql para ficheiros SQL e o pg_restore para o formato personalizado.

Como sei que o meu backup funciona?

Restaure-o. Carregue o backup numa base de dados separada e vazia e confirme que as tabelas existem e que o número de registos e alguns registos recentes coincidem com os dados em produção. Um backup que nunca restaurou é uma suposição.

Onde devo guardar os backups da base de dados?

Num local separado da própria base de dados, de preferência com outro fornecedor ou outra conta, e com acesso limitado a si. Os backups contêm os dados de todos os seus utilizadores, por isso trate-os com o mesmo cuidado que a base de dados em produção.