Como restaurar um backup do Supabase, e o que quebra depois

Alguma coisa no seu banco de dados deu errado e, pela primeira vez, você tem uma cópia. Agora você está olhando para um botão que nunca apertou, em um projeto com usuários de verdade dentro, tentando entender o que ele está prestes a fazer com eles.

Aqui está a parte que guia após guia deixa de fora. Quase todo artigo sobre como restaurar um backup do Supabase termina no momento em que a restauração acaba, e é aí que começa a maior parte do problema. O desfecho comum não é uma restauração que falha. É uma que dá certo e deixa o app quebrado assim mesmo, porque um backup do banco nunca conteve nada além do banco.

Ajuda parar de imaginar isso como recuperar seus dados. Uma restauração troca o seu banco por um mais antigo, mais parecido com trocar um arquivo inteiro do que com devolver uma pasta ao lugar. Tudo o que vem abaixo decorre disso.

Como eu restauro um backup do Supabase?

Três caminhos, e qual deles está aberto para você hoje foi decidido antes de hoje.

Os dois primeiros devolvem seus dados onde eles já estavam. O terceiro é o único que consegue colocá-los em outro lugar, que é do que você precisa no dia em que o problema é a sua conta e não os seus dados.

Se você não tem certeza de qual deles tem, o plano do Supabase em que você está resolve os dois primeiros e conferir leva uns dois minutos.

Copie o que você tem agora, antes de restaurar qualquer coisa

Tire primeiro uma cópia do banco no estado quebrado em que ele está. É um comando só, e é o que torna reversível cada decisão seguinte.

pg_dump "postgresql://…sua string de conexão…" \
  --clean --if-exists --no-owner \
  --file before-restore-2026-08-24.sql

Há dois motivos, e o segundo as pessoas costumam aprender depois.

O primeiro é que uma restauração é uma substituição. As tabelas da cópia voltam exatamente como estavam, então toda linha escrita nelas desde então vai junto. Uma cliente que se cadastrou hoje de manhã é uma linha que você está prestes a apagar de propósito.

O segundo é que o seu banco quebrado ainda é o único lugar onde parte dos seus dados existe. Se a cópia é de terça e o estrago aconteceu na quinta, tudo o que foi criado na quarta está na sua frente agora e em nenhum outro lugar. Restaure por cima e some pela segunda vez, dessa vez pela sua mão e não pelo acidente.

Enquanto você trabalha, desligue tudo o que escreve linhas novas. O raciocínio é o mesmo de depois de qualquer exclusão: a lacuna entre a cópia e agora fica mais cara quanto mais tempo o app continua enchendo ela.

Restaurando pelo painel do Supabase

Isso substitui o banco do seu projeto pela cópia que você escolher, e o projeto fica indisponível enquanto roda.

Abra o projeto com que o seu app conversa, vá em Database e depois Backups, e escolha a cópia com data. Leia os passos exatos na documentação de backups do próprio Supabase, porque o painel é reorganizado e esta página não vai perceber quando isso acontecer.

Quanto demora depende do tamanho do seu banco, que é a resposta do próprio Supabase. Coloque um aviso de manutenção antes de começar.

O point-in-time recovery é a mesma operação com um botão mais fino. Em vez de escolher ontem à noite, você indica um minuto e o projeto volta até ali. O Supabase descreve isso como destrutivo, e essa é a palavra certa. As notas de suporte deles acrescentam que uma restauração point-in-time não pode começar enquanto os slots de replicação e as assinaturas existentes não forem removidos. Ou seja, se algo no seu app acompanha mudanças do banco conforme elas acontecem, esse é um passo para fazer antes em vez de um erro para encontrar no meio do caminho.

Nenhum dos dois caminhos consegue colocar seus dados em outro projeto. Os dois agem sobre o projeto em que você está, o que significa que nenhum está disponível no dia em que o que quebrou é o seu acesso à conta.

Restaurando um arquivo de dump com o psql

Você aponta o psql para um projeto e reaplica o arquivo nele. Esse projeto pode ser o que você tinha, ou um recém-criado em uma conta que você abriu hoje de manhã.

psql -d "postgresql://…string de conexão do projeto de destino…" \
  --variable ON_ERROR_STOP=1 \
  --single-transaction \
  --file backup-2026-08-09.sql

Duas dessas opções vale a pena entender, porque o comportamento padrão do psql é o surpreendente.

ON_ERROR_STOP=1 para no primeiro erro. Sem ela, o psql lê o erro, imprime e segue para a linha seguinte, então um arquivo que falhou na linha 400 de 30.000 termina assim mesmo em um prompt com cara de sucesso, sobre um banco a que falta tudo o que vinha depois daquela linha. --single-transaction embrulha o arquivo inteiro em uma operação só, de modo que uma falha deixa o banco como estava em vez de pela metade.

Depois as credenciais, que é onde muita gente trava. Reaplicar um backup significa escrever, então precisa de algo que possa escrever. Uma chave anon não dá conta e uma somente de leitura também não. O que o psql quer é a senha de banco do projeto de destino, que fica nas configurações do seu projeto Supabase, em Database.

O que volta depende do que está no arquivo, e isso ficou decidido quando o dump foi feito. Suas contas de acesso são a parte para conferir antes de confiar nele. Elas vivem em um schema chamado auth ao lado das senhas criptografadas, e o Supabase documenta movê-las entre projetos como um trabalho com passos próprios. Se você vai restaurar em um projeto novo e quer que as pessoas entrem com a senha que já têm, leia essa página antes de começar.

E um projeto novo tem uma URL nova e chaves novas. O seu app continua apontado para o antigo até você mudar isso, que é a primeira linha da próxima seção.

Restaurou, e o app continua quebrado

Esse é o desfecho normal. É quase sempre uma de cinco coisas, e a primeira leva um minuto.

A quarta merece a atenção. Permissão de leitura e permissão de escrita são concedidas separadamente, e uma restauração pode acertar uma e errar a outra. Então as páginas se enchem com os seus dados, tudo parece recuperado, e aí a primeira pessoa que envia um formulário recebe um erro. Olhar para o app nunca vai te mostrar isso, porque olhar é ler.

Como saber se a restauração funcionou mesmo

Entre na sua conta, ache uma linha que você consiga nomear, e então escreva uma. Nessa ordem, e a última é a checagem que conta.

• Entre pelo app do jeito que um usuário entraria, em vez de abrir o editor de tabelas do Supabase. Isso testa o app, a conexão e as contas de acesso de uma vez só.
• Ache uma linha de que você se lembra. Um pedido específico, um cliente com nome, a última coisa que você adicionou antes de quebrar. "Os dados parecem estar aí" é uma sensação; uma linha que você consegue nomear é uma checagem.
• Compare uma contagem com o que você esperava. Abra a sua maior tabela no editor do Supabase e leia o número de linhas. Uma restauração que parou no meio costuma aparecer aqui como um número pequeno demais.
• E então escreva alguma coisa. Crie uma linha do jeito que um usuário faz: faça um pedido de teste, salve um perfil, publique um comentário. Essa é a checagem que falha quando as outras três passam, e é a única coisa que prova que a restauração terminou.
• Abra algo que um usuário enviou. Se o seu app tem imagens ou anexos, clique em um. Se os seus arquivos voltaram é uma pergunta separada de se as suas linhas voltaram.

O que fazer agora

Antes de fechar esta aba, descubra se você tem sequer de onde restaurar, e onde isso está. Essa única resposta decide de qual metade deste artigo você vai precisar algum dia. O checklist de segurança de 10 minutos cobre isso junto com o resto do que vale confirmar em um app recém-lançado, e o guia de segurança do Supabase passa pelo que costuma ficar aberto.

O que o Reeve Care faz no dia em que você restaura

A cópia já existe, já foi lida de volta e conferida, e fica fora da sua conta do Supabase. Isso transforma a hora descrita acima em uma escolha de qual cópia, e um botão.

Quatro coisas que isso muda neste artigo especificamente.

A cópia é verificada antes de você precisar dela. Todo backup é lido de volta e contado contra o que entrou, e a data que aparece no seu painel é a da última cópia que passou na conferência, não a da última tentativa. A restauração pela metade contra a qual este artigo avisa é um problema que nós encontramos em uma tarde qualquer, antes de ele ser seu.

A cópia de segurança não é um passo que você precisa lembrar. Apertar restaurar tira antes uma cópia fresca do estado atual, de modo que a própria restauração pode ser desfeita.

Seus arquivos enviados voltam também, assim que você conecta seus buckets do Storage. É a linha da tabela acima que de outro jeito não tem boa resposta.

A chave de banco que guardamos só consegue ler. Uma restauração precisa escrever, então ela pede a senha do seu banco toda vez e não guarda nenhuma. A chave opcional para os seus arquivos consegue escrever, porque o Supabase não emite uma chave somente de leitura para o Storage, e a página onde você a entrega diz isso antes de você entregar.

Os limites entram na mesma frase, porque é melhor conhecê-los antes de pagar do que durante uma queda:

• Funciona com o Supabase e hoje com mais nada.
• Você restaura para uma cópia que existe, não para qualquer minuto que citar. No pior caso você perde um intervalo, que é até uma noite no plano de entrada e menos nos dois acima.
• As contas de acesso nunca são tocadas. Ninguém é deslogado, apagado ou trazido de volta.

Deixe os backups do Supabase ligados de qualquer jeito. Duas cópias em dois lugares é a ideia inteira, e a mais barata das duas já está no seu plano. O que cada plano do Care cobre está na página inicial.

Se você prefere não pagar por nada disso, tudo neste artigo continua funcionando. Um pg_dump numa periodicidade que você cumpra de verdade, guardado em algum lugar que perder a sua conta do Supabase não levaria junto, mais uma restauração de treino por trimestre, leva você quase até o fim. Os três caminhos e o que cada um deixa de fora conta isso sem discurso de venda.

O ciclo inteiro está desenhado passo a passo na página de backups do Supabase: a cópia saindo do Supabase, a conferência que vem atrás dela, e o botão que a coloca de volta.