← todos os posts
Manutenção 5 min de leitura

"Backup: como não perder o banco de dados do seu app"

Voltar o código não volta o banco, e backup que nunca foi restaurado é esperança. O exercício de 20 minutos que prova, hoje, que seus dados voltam.

"Banco de dados, segurança e proteção das informações dos clientes, estruturação do SaaS, que não temos a mínima ideia."

É de um brasileiro, num fórum, depois de duas semanas tentando montar um sistema com IA. Repare no primeiro item da lista: banco de dados. Não é a tela, nem o botão. É onde mora o cadastro do cliente.

E o banco é a única parte do seu app que não volta. Código se regenera: você pede de novo e a IA reescreve. Pedido de cliente, histórico de pagamento, cadastro de paciente — isso, perdido, acabou. A frase que organiza este post:

Backup que nunca foi restaurado não é backup. É esperança.

Por que você achava que estava coberto

Não é descuido seu. É que a palavra "restaurar" aparece em toda plataforma e quer dizer uma coisa diferente da que você imagina.

A documentação do Bolt escreve com todas as letras: restaurar uma versão anterior do projeto não altera o seu banco Bolt ou Supabase. O Replit é ainda mais completo: restaurar o banco não restaura o código do app, e voltar o app não restaura o banco. Eu já mostrei como isso funciona no Lovable e no Replit; hoje o ponto é outro.

O ponto é o estado que ninguém previu: código de ontem com dados de hoje. Você volta o app pra versão de terça. O banco continua no estado de quinta, com a coluna nova que a IA criou na quarta. O código de terça não sabe que aquela coluna existe. O app quebra de um jeito que não existia em dia nenhum — e você gasta uma tarde caçando um bug que é um desencontro de datas.

Então "tem ponto de restauração" não responde a pergunta. A pergunta é: você tem uma cópia dos dados, fora do lugar onde eles moram, que você já provou que abre?

O exercício: 20 minutos, hoje

Quatro passos, e o quarto é o que ninguém faz.

1. Baixe o arquivo

O caminho depende de onde o seu banco mora — e se você não sabe onde ele mora, o inventário de uma folha resolve isso antes de continuar. Pela documentação oficial de cada uma, em setembro de 2026:

Supabase (é o banco por baixo de muito app feito no Lovable e no Bolt). No plano pago, o painel guarda backup diário sozinho: Database → Backups → Scheduled, com 7 dias no Pro, 14 no Team, 30 no Enterprise. No plano grátis não há backup automático nenhum: a própria documentação recomenda exportar regularmente com a linha de comando (db dump) e guardar fora. A versão sem terminal, que serve pra hoje: abra o Table Editor, escolha a tabela mais importante — a de pedidos, a de clientes — e use a opção de exportar em CSV do menu da tabela. CSV é um arquivo de texto com uma linha por registro, que abre em qualquer planilha. Um detalhe que a documentação faz questão de dizer: o backup do banco não inclui arquivos enviados pelo Storage (foto, PDF); ele só guarda o nome deles.

Lovable Cloud (o banco do próprio Lovable). More → Cloud → Overview → Advanced settings → Export data. Você recebe um link por e-mail, e o arquivo também fica no Storage do projeto. Limite de uma exportação a cada 24 horas e arquivo de até 5 GB. Vem a estrutura e os dados; não vêm os arquivos do Storage, o código das funções nem as suas chaves. E o aviso que a documentação grifa: se você remover o Cloud, o export some junto.

Replit. Database → banco de produção → Settings → Scheduled backups, e escolha a retenção em Keep backups for — até 7 dias no Core, até 28 no Pro. Um ponto de retorno por dia; existe desde o começo do mês, então se você nunca ligou, está desligado.

Firebase. A exportação oficial do Firestore é por linha de comando (gcloud firestore export), exige o plano Blaze e um bucket de armazenamento. Não cabe em vinte minutos sem terminal; se o seu caso é esse, o passo de hoje é anotar isso no inventário.

2. Abra o arquivo

Não confie no "download concluído". Abra. CSV, na planilha. O .backup do Supabase ou do Lovable você não vai conseguir ler — tudo bem: confira o tamanho. Mil clientes não cabem em 2 KB.

3. Conte

Anote o número de registros na tabela principal, na origem, antes de qualquer coisa. Não é "uns mil". É 1.043.

4. Restaure num lugar de teste e conte de novo

Este é o passo que transforma esperança em backup. E ele não precisa de terminal: crie um segundo projeto, gratuito, com nome de teste — no Supabase isso leva um minuto. Lá dentro, Table Editor → Insert → Import Data from CSV (limite de 100 MB pelo painel), suba o arquivo que você baixou e conte os registros no destino.

origem   →  1.043 pedidos
restaura no projeto de teste
destino  →  1.043 pedidos

Bateu? Você tem backup. Não bateu? Descobriu numa terça tranquila, não no dia em que precisava.

Nunca restaure em cima do banco que o cliente usa. Ambiente de teste é outra despensa, não a mesma com outra porta.

O que isso era, na parede inteira

Você acabou de responder a pergunta 9 do checklist: existe backup, e ele já voltou uma vez. Faltam nove. Uma delas é a que eu deixei em aberto no post do inventário, e agora dá pra responder com um número em vez de "não sei":

Se a sua conta na plataforma sumisse hoje de manhã, quanto tempo até seu app estar no ar de novo, com os dados dos clientes?

Hoje você sabe que os dados voltam. O tempo até estar no ar depende do resto — código, login, publicação, os fios soltos — e da ordem de religar. É a parede seguinte, e ela também tem exercício.

Fontes