Por que você não consegue baixar seu backup do Supabase

Você está num plano pago do Supabase, então tem backups. Você abre Database, depois Backups, e lá estão eles: uma lista de cópias diárias com data, cada uma com um botão Restore. Você procura o botão que deixa baixar seu backup do Supabase e guardar num lugar seu, e ele não existe.

Nada está quebrado. Esta é a parte que os guias mais antigos ainda contam errado: num projeto atual não existe backup diário para baixar. O Supabase passou as cópias diárias para outro tipo de backup, um que ele consegue restaurar para você e não consegue te entregar. O botão de download que esses guias descrevem pertencia ao tipo antigo. Um arquivo que fica na sua mão agora é você quem faz, e é outro tipo de arquivo.

Seu celular é o jeito mais fácil de entender a diferença. O backup que ele faz de si mesmo toda noite é completo e exato, e volta num único passo para um celular conectado à mesma conta. Você não consegue abrir esse backup num notebook e tirar suas fotos de lá. Para ter fotos que você possa guardar em qualquer lugar, você as exporta, e o que recebe é uma pasta de arquivos comuns. O backup diário do Supabase agora é do primeiro tipo. O arquivo que você pode ter é do segundo.

Posso baixar meu backup do Supabase?

O diário não, se o seu projeto roda Postgres 15.8.1.079 ou mais novo. A documentação de backups do Supabase diz que todos os projetos nessa versão e nas mais novas usam backups físicos, e as notas de solução de problemas dizem que, com os backups físicos ativados, o Supabase não gera mais o arquivo de backup para download. Você pode restaurar essas cópias quando quiser. Não pode levar nenhuma com você.

A última linha merece uma segunda leitura. O Supabase diz que, quando um projeto é excluído, ele remove todos os dados associados, incluindo os backups guardados no S3. Exclua o projeto e as cópias diárias vão junto, no mesmo passo.

Qual é a diferença entre um backup físico e um lógico?

De onde a cópia é tirada. Um backup físico copia os arquivos que o próprio Postgres grava em disco, o que o Supabase descreve como um snapshot do diretório subjacente do banco. Um backup lógico pede ao banco que se descreva em SQL, tabela por tabela e linha por linha, e grava essa descrição num arquivo de texto.

Cada um é bom numa coisa diferente. Uma cópia física é rápida de fazer e rápida de pôr de volta, e volta exatamente como estava. Só o mesmo tipo de instalação Postgres de onde ela veio consegue lê-la, o que no Supabase significa as máquinas do próprio Supabase. Uma cópia lógica demora mais para ser reaplicada e ocupa mais espaço, e qualquer Postgres da mesma versão ou mais novo consegue carregá-la. É de novo o backup do celular e a pasta exportada, e só a segunda é um arquivo que você pode ter.

O botão de download de que as pessoas lembram era do tipo lógico. A própria documentação do Supabase, em 2025, dizia que o processo diário rodava pg_dumpall, compactava o arquivo SQL e o guardava, e que os backups físicos pesam menos no banco e evitam travar suas tabelas por muito tempo. A mesma página dizia que as cópias físicas não podem ser baixadas pela seção Backups do painel.

Como sei qual deles o meu projeto tem?

Procure uma opção de download na página de Backups. Abra Database, depois Backups, no painel do Supabase. Se cada cópia com data tiver um jeito de ser baixada, seu projeto ainda está em backups lógicos. Se cada uma oferecer Restore e mais nada, está em backups físicos, e a documentação antiga do Supabase usava exatamente esse teste.

A segunda conferência é o número da versão. Ele aparece em Project Settings, depois General. Qualquer coisa a partir de 15.8.1.079 significa backups físicos. Leia da esquerda para a direita: uma versão que começa com 17 é mais nova que qualquer 15, e 15.8.1.100 é mais nova que 15.8.1.079.

Dois casos não precisam de conferência nenhuma:

• A recuperação para um ponto no tempo está ligada. Ela roda em backups físicos por definição. O Supabase também diz que, se você desligar a recuperação para um ponto no tempo, ele continua fazendo backups físicos, então o download não volta.
• Você está no plano gratuito. A página de Backups não tem nada para baixar nem para restaurar, porque o plano gratuito não te dá backups diários que você possa usar. Fazer uma cópia sem terminal é o ponto de partida.

Do que cada um me protege?

O backup diário te protege de algo que dá errado dentro do projeto. Um arquivo que fica com você cobre também a perda do próprio projeto.

O primeiro tipo de perda é o que você mesmo causa. Uma exclusão que levou mais linhas do que você queria, uma migração que um agente de IA escreveu e você aprovou, um script apontado para a tabela errada. A cópia diária é exatamente a ferramenta para isso: você escolhe ontem, aperta Restore e o projeto volta ao lugar. Até onde ela alcança depende do seu plano, e em qual plano você está se resolve em uns dois minutos.

O segundo tipo não tem nada a ver com um erro no banco. Um cartão que venceu enquanto você estava fora, um login que você não consegue recuperar, um projeto que alguém excluiu. As cópias ficam atrás da mesma porta que o projeto, e a porta é o que fechou. O backup do seu celular se comporta do mesmo jeito: ele te salva se o celular cair no mar, e não serve para nada no dia em que você não consegue mais entrar na conta onde ele está. O Supabase guarda os backups junto com a plataforma porque é isso que faz a restauração ser um botão só. Uma cópia que sobrevive à conta precisa ficar em outro lugar, o que no Supabase significa um dump lógico tirado de dentro dela.

O que restaurar significa em cada caso?

Com a cópia diária, o Supabase faz o trabalho e você escolhe onde ela vai parar. Com um arquivo que fica com você, o trabalho é seu, e ele pode ir parar em qualquer lugar.

Restaurar a cópia diária no mesmo projeto substitui o banco pela cópia que você escolher. O Supabase diz que o projeto fica inacessível enquanto isso roda e que um banco maior demora mais.

Restaurá-la num projeto novo é um recurso pago que o Supabase chama de Restore to a New Project, ainda marcado como beta. Ele cria um projeto separado na mesma região, com seus usuários e as senhas deles em hash, e é cobrado como um segundo projeto. Um aviso na mesma página passa fácil despercebido. Ele copia o banco inteiro, inclusive extensões que agem para fora, como pg_cron e pg_net, e essas tarefas começam a rodar assim que a restauração termina. Se uma tarefa agendada do seu app envia e-mails ou chama uma API de pagamento, o projeto novo também começa a fazer isso, a partir do momento em que existe.

Restaurar um arquivo que fica com você significa reaplicá-lo com psql no destino que você apontar: um projeto novo do Supabase, um em outra conta ou um Postgres no seu próprio computador. Como restaurar um backup do Supabase passa pelos comandos, e pelo que continua quebrado quando eles terminam.

Como consigo uma cópia do meu banco do Supabase em arquivo?

Faça você mesmo um dump lógico. O Supabase publica isso no guia de backup e restauração dele como três comandos, cada um gravando um arquivo:

supabase db dump --db-url "postgresql://…" -f roles.sql --role-only
supabase db dump --db-url "postgresql://…" -f schema.sql
supabase db dump --db-url "postgresql://…" -f data.sql --use-copy --data-only

A string de conexão vem do botão Connect no topo do seu projeto, com a senha do seu banco no lugar do marcador. A CLI do Supabase precisa do Docker instalado, porque roda o pg_dump dentro de um contêiner em vez de usar um do seu computador.

Guarde os três arquivos. O segundo sozinho é a forma das suas tabelas sem nenhuma linha dentro, e seus usuários só estão no terceiro.

Você também pode rodar o pg_dump direto. Duas coisas para saber antes. O Supabase diz que um pg_dump cru leva os schemas internos do Supabase junto com os seus, e que reaplicá-los causa erros de permissão na volta. E o Postgres documenta que o pg_dump não faz dump de um servidor com versão principal mais nova que a dele, então uma cópia antiga no seu computador se recusa a começar em vez de gravar um arquivo ruim.

Guarde os arquivos num lugar que não seja a sua conta do Supabase, e não só no seu notebook.

Posso restaurar um backup do Supabase no meu próprio computador?

Um lógico, sim, num Postgres da mesma versão principal ou mais novo. A cópia diária física não pode ser restaurada em lugar nenhum além do Supabase.

A regra de versões vem do próprio Postgres. A documentação dele diz que um dump deve poder ser carregado em versões mais novas e que não há garantia de que carregue numa mais antiga, nem mesmo naquela de onde veio. O guia do Supabase para levar um projeto da plataforma para o Supabase auto-hospedado mostra como isso fica. A plataforma pode rodar Postgres 17 enquanto a imagem auto-hospedada usa 15 por padrão, e aí o arquivo de dados traz uma linha, SET transaction_timeout = 0, que o Postgres 15 não reconhece.

Esses mesmos três arquivos também são o caminho para sair do Supabase de vez. Aquele guia é a rota para rodar o Supabase num servidor seu, e a diferença de versões é a primeira coisa sobre a qual ele avisa.

No seu próprio computador, a CLI do Supabase sobe uma cópia local do Supabase no Docker quando você digita supabase start. Reaplique os três arquivos nela com o comando psql do guia de backup e restauração do Supabase, apontado para postgresql://postgres:postgres@localhost:54322/postgres, e seus dados ficam legíveis no seu próprio computador, sem nenhuma conta no meio.

Há um lugar onde o Supabase ainda oferece um backup para baixar. Um projeto gratuito pausado além da janela de restauração troca o botão Restore pelo download da última cópia feita antes da pausa, e o que fazer com esse arquivo é assunto de outro artigo.

O que não está em nenhuma das duas cópias?

Seus arquivos enviados, suas Edge Functions e a maior parte das configurações do seu projeto.

O Supabase diz que os backups do banco não incluem objetos guardados pela Storage API. O banco guarda uma linha que descreve cada arquivo, e o arquivo em si mora em outro lugar, então nenhum backup do banco, em nenhum plano, contém o que seus usuários enviaram. Fazer backup do Storage é um trabalho à parte.

A lista que o Supabase dá para Restore to a New Project é um bom inventário do resto: Edge Functions, configurações de autenticação e chaves de API, configurações do Realtime, configurações de extensões e réplicas de leitura precisam ser configuradas de novo à mão.

Uma lacuna afeta só o arquivo que fica com você. Se o seu app guarda segredos no Supabase Vault ou usa colunas criptografadas, o Supabase diz que os arquivos de backup nunca contêm a chave raiz, só os dados criptografados. Um projeto novo começa com a própria chave, então esses valores chegam ilegíveis até a chave antiga ser copiada. E a chave antiga só pode ser obtida enquanto o projeto antigo ainda está ativo. Depois que esse projeto é pausado ou excluído, a chave não pode mais ser recuperada, e nada do que ela criptografava também.

O que fazer esta semana

Onde o Reeve Care entra

O Care faz a cópia lógica por você, guarda fora do Supabase, e cada cópia é um arquivo que você pode baixar.

• Baixe qualquer cópia como zip. Dentro vão schema.sql, data.sql e roles.sql, um manifesto que conta as linhas de cada tabela e uma nota sobre como carregar tudo em qualquer Postgres. É um dump padrão, então qualquer desenvolvedor consegue abrir, e qualquer outra hospedagem também.
• Guardada fora da sua conta do Supabase, criptografada, então continua lá no dia em que a conta não estiver.
• Relida antes de contar. A data no seu painel é a da última cópia que foi aberta e verificada, nunca a da última tentativa.
• Seus usuários estão dentro. O schema auth viaja com suas tabelas, e os arquivos que seus usuários enviaram vêm junto assim que você conecta uma credencial do Storage.

O Care guarda uma cópia do seu banco do Supabase. Deixe os backups diários do Supabase ligados ao lado dela: eles são o caminho mais rápido de volta de uma migração que deu errado, e o arquivo é o que sobra se você perder a conta. Como uma cópia é feita, conferida e baixada está desenhado passo a passo na página de backups do Supabase, e o que cada plano inclui está na página de preços.

Antes de fechar esta aba, abra Database, depois Backups, e olhe ao lado da sua cópia mais recente. Se ali não houver nada para baixar, o próximo arquivo que você tiver é o que você mesmo fizer, e o que deixa um dump completo é o que vale ler antes de fazê-lo.