Reeve Backups
Três formas de fazer backup de um banco Supabase, e o que falta
O painel, o pg_dump e um serviço gerenciado. O que cada um salva de verdade, o que deixa de fora sem avisar e qual sobrevive a perder a conta.
Em resumo
- Os backups do próprio Supabase são os mais fáceis de ligar e os piores para confiar: a cópia fica dentro da conta que você pode perder.
- O pg_dump é gratuito e completo, e só acontece quando você lembra. Lembrar é a parte que falha.
- Nenhum dos três faz backup dos seus arquivos do Storage. Isso é um trabalho à parte, seja qual for o caminho.
Quem constrói no Supabase acaba fazendo a mesma pergunta, normalmente uma semana depois do lançamento e quase sempre às duas da manhã: se eu quebrar alguma coisa, consigo meus dados de volta?
A resposta depende inteiramente de qual dos três caminhos você pegou, e cada um deixa passar algo que os outros dois cobrem.
Qual eu devo usar?
Ligue o que o seu plano do Supabase oferece e depois guarde uma cópia em outro lugar. São dois trabalhos diferentes, e fazer só o primeiro é exatamente o erro que este artigo existe para evitar.
O backup do painel protege você dos seus próprios erros. Uma cópia que é sua protege você de perder a conta: uma cobrança que falha, um projeto suspenso, uma senha que você não consegue recuperar. São desastres diferentes e pedem respostas diferentes.
| Painel do Supabase | pg_dump na mão | Backups gerenciados | |
|---|---|---|---|
| Roda sem você | Sim | Não | Sim |
| A cópia é sua | Não | Sim | Sim |
| Sobrevive a perder a conta | Não | Sim | Sim |
| Conferido antes de contar | Não | Não | Sim |
| Custo | Só em planos pagos | Grátis | Uma assinatura |
O que um backup contém de verdade
Suas tabelas, suas linhas, seus índices e funções e suas regras de Row Level Security, as políticas que decidem quem pode ler o quê, não só as tabelas em que elas se aplicam. É isso.
O que ele não contém é tudo aquilo que nunca esteve no banco:
| No arquivo | Fora do arquivo |
|---|---|
| A estrutura das tabelas, com cada coluna e restrição | Arquivos no Storage: uploads, avatares, anexos |
| Cada linha que seus usuários criaram | Configurações de autenticação, como seu app do Google ou GitHub |
| Índices e funções | Edge functions, que vivem no seu repositório |
| Políticas de Row Level Security |
Onde as pessoas tropeçam é no Storage. Cada avatar, cada PDF enviado, cada imagem que seus usuários adicionaram vive no armazenamento de objetos, não no banco. O banco guarda só o caminho de cada arquivo. Restaure um backup do banco em um projeto vazio e você fica com uma tabela cheia de links para arquivos que não estão lá.
Caminho 1: o painel do Supabase
O mais fácil, e o que quase todo mundo deveria ligar primeiro. O Supabase faz backups diários nos planos pagos, e a recuperação para um ponto no tempo está disponível como adicional se você precisar voltar para um minuto específico em vez de para a última meia-noite.
No que ele é bom: roda sem você, é completo, e restaurar são alguns cliques numa interface em vez de um comando que você precisa acertar sob pressão.
O que falta nele: a cópia fica dentro da conta. Se o projeto for suspenso, o cartão cadastrado falhar ou você perder o acesso ao login, os backups estão atrás da mesma porta que aquilo que eles protegiam. É uma saída de incêndio dentro do prédio.
Ele também não existe no plano gratuito, que é onde está a maior parte dos apps recém-lançados.
Em qual plano você está decide se você tem isso ou não, e conferir leva dois minutos.
Caminho 2: pg_dump na sua própria máquina
Supabase é Postgres, então a ferramenta padrão do Postgres funciona. O pg_dump
escreve o banco inteiro em um arquivo que é seu.
pg_dump "postgresql://…sua string de conexão…" \
--clean --if-exists --no-owner \
--file backup-2026-08-09.sql
No que ele é bom: é grátis, é completo, o arquivo é seu, e você pode restaurá-lo em um projeto novinho em outra conta. Dos três caminhos, esse é o único que sobrevive a perder todo o resto.
O que falta nele: só acontece quando você lembra. Isso não é um detalhe técnico, é a falha inteira. O dump no seu notebook tem a data do último dia em que você pensou nisso, e o dia em que você precisa dele nunca é um dia em que você estava pensando nisso.
Tem um segundo problema, mais silencioso: um dump não testado é um palpite. Um arquivo escrito enquanto uma migração estava pela metade, ou que foi cortado em silêncio porque a conexão caiu, é idêntico a um bom até o dia em que você tenta usar.
Caminho 3: backups gerenciados
Outra coisa tira a cópia num horário, guarda fora da sua conta e confere se a cópia é real antes de dar como feita. Essa última parte é a que realmente importa.
É isso que o Reeve Care faz: várias cópias por dia dependendo do plano, criptografadas e guardadas fora da sua conta do Supabase, cada uma verificada contando o que saiu contra o que entrou. Um backup só conta como feito depois de verificado, e é por isso que a data mostrada no painel é a da última cópia verificada e não a da última tentativa.
A troca honesta: custa dinheiro e é mais um serviço na sua stack. Se você for disciplinado o bastante para tocar o caminho 2 num horário de verdade e testar as restaurações, não precisa dele.
O ciclo inteiro está na página de backups do Supabase: a cópia saindo do Supabase, a verificação depois dela e o botão que devolve tudo.
Você já restaurou algum?
Essa pergunta decide se você tem um backup ou um arquivo que ninguém nunca abriu. Um dump que ninguém leu de volta é um palpite sobre o futuro, e o momento em que você descobre que ele estava errado é o momento em que você precisava que estivesse certo.
Um teste de restauração não precisa ser dramático. Crie um projeto novo no Supabase, carregue nele o seu backup mais recente, abra o app apontando para esse projeto e confira se tem uma linha que você reconhece. Meia hora, uma vez por trimestre. Se a restauração falhar, você descobriu numa terça à tarde em vez de no meio de uma queda.
Se você quer a lista mais ampla do que vale conferir num app recém-lançado, o checklist de segurança de 10 minutos cobre backups junto com o resto, e o guia de segurança do Supabase passa pelo que mais costuma ficar aberto.
O que fazer esta semana
O que fazer
- Ligue o backup que o seu plano do Supabase inclui. É a coisa mais barata desta lista e leva mais ou menos um minuto.
- Faça um
pg_dumphoje e coloque o arquivo em algum lugar que não seja o seu notebook. Até uma cópia velha ganha de nenhuma cópia. - Faça backup dos seus arquivos do Storage separadamente. Nenhum backup de banco nesses caminhos inclui eles.
- Faça uma restauração num projeto descartável, para que a próxima vez que você ler esse arquivo não seja a primeira.
- Decida quantos dados você aguentaria perder, e escolha a frequência a partir desse número em vez do que parece responsável.
Vale ler depois: se você achava que o desfazer do seu builder cobria os seus dados, o histórico de versões não é backup é o primeiro a ler. Depois disso, seu banco de dados é tão privado quanto as chaves que estão na frente dele, e quais chaves de API são seguras no frontend trata daquela que ignora todas as regras que você define.
Perguntas frequentes
O plano gratuito do Supabase inclui backups?
Não. Os backups diários começam no plano Pro, e a recuperação para um ponto no tempo é um adicional acima disso. No plano gratuito não existe nenhuma cópia automática dos seus dados em lugar nenhum, o que surpreende quase todo mundo na primeira vez que precisa de uma.
Backup é a mesma coisa que o histórico de versões do meu builder?
Não, e esse é o mal-entendido mais caro deste artigo. Lovable, Bolt e os outros versionam o seu CÓDIGO. Seu banco de dados é um serviço separado com os seus usuários, o conteúdo deles e os pedidos deles. Voltar o código para ontem não volta os seus dados, e apagar uma tabela no editor do Supabase deixa o seu código perfeitamente intacto.
De quanto em quanto tempo devo fazer backup?
Pergunte antes quanto você toparia redigitar. Se perder um dia de cadastros fosse apenas chato, toda noite basta. Se perder uma hora de pedidos significasse estornar gente, você precisa de algo mais perto de uma vez por hora. O teste honesto não é a frequência, é se você já restaurou algum.
Preciso fazer backup se meu app quase não tem usuários?
Esse é o momento mais barato para começar, porque os dados são poucos e o que importa é o hábito. As perdas dolorosas raramente são dramáticas. São um delete digitado errado durante um conserto de madrugada, num projeto com usuários reais o suficiente para recomeçar não ser uma opção.