Reeve Backups
Um agente de IA apagou meus dados do Supabase. O que eu recupero?
Um agente de IA apagou dados do seu banco. O que você recupera já estava decidido antes de ele rodar, e os próximos minutos decidem o resto.
Em resumo
- Se um agente de IA apagou dados do seu banco, o que dá para recuperar é o que estava na última cópia feita antes disso. O que veio depois não foi escrito em nenhum outro lugar.
- Pare tudo o que escreve linhas novas antes de qualquer outra coisa. Uma restauração remove tudo o que entrou depois da cópia, então um cadastro que chega agora é uma linha que você mesmo vai apagar.
- O agente não consegue devolver as linhas. Ele nunca as teve, e rodar ele de novo contra um banco em produção é mais uma chance de perder outra coisa.
Você pediu para o agente limpar umas linhas de teste, ou consertar uma migração que não aplicava. Ele escreveu o SQL sozinho, rodou contra o projeto que o seu app em produção usa e avisou que estava pronto. O app continua carregando. A tabela está vazia.
Quando um agente de IA apagou dados do seu banco, o que você consegue recuperar já estava decidido antes de ele rodar. Os próximos minutos decidem quanto disso sobrevive.
Aqui está o ponto que quase toda resposta a isso erra. Elas mandam você voltar o código, ou pedir para o agente desfazer. Nenhuma das duas encosta nos seus dados, e enquanto você tenta, a única coisa que ainda está na sua mão vai piorando em silêncio: o que o seu app está escrevendo no banco agora.
O que dá para recuperar depois que uma IA apagou meus dados?
O que estava na última cópia do seu banco feita antes da exclusão, e nada do que foi criado depois dela.
Essa é a resposta inteira, e a maior parte dela foi decidida semanas atrás. Não
tem etapa de perícia aqui, nada para desapagar, nenhum log esperando no Supabase
para ser reproduzido. Uma linha removida por um DELETE ou por um DROP TABLE
sumiu do banco no instante em que a instrução foi confirmada. O que volta é uma
cópia, e uma cópia existe ou não existe.
Então você tem duas tarefas pela frente. Descobrir quais cópias existem. E impedir que o intervalo entre a mais recente e agora fique mais caro do que já está.
Antes de tudo: pare o que escreve no banco
Antes de sair procurando um backup, desligue tudo o que escreve linhas novas. Leitura não é problema.
Existem duas razões, e a segunda pega as pessoas de surpresa.
A primeira é que restaurar não é mesclar. Recolocar uma cópia substitui as tabelas que ela contém pelo que aquelas tabelas tinham na época, e tudo o que foi escrito depois vai junto. Um cliente que se cadastra na hora que você passa lendo isto é uma linha que você mesmo vai apagar, mais tarde, num passo que você já decidiu dar.
A segunda é que alguns caminhos pioram enquanto você espera. A recuperação para um momento específico do Supabase volta o projeto inteiro para um minuto que você escolhe, então quanto mais o app se afasta do erro, mais trabalho legítimo essa volta joga fora junto com o estrago.
Uma hora atrás de um aviso de manutenção sai barato. Explicar para alguém que o pedido dele foi criado e depois removido de propósito sai muito mais caro.
Posso pedir para o agente desfazer?
Não. Ele nunca teve as suas linhas.
O agente escreveu uma instrução e o seu banco executou. O que ele tem agora é a transcrição daquela conversa, que é uma coisa diferente de uma cópia da tabela. Peça para ele reverter a exclusão e você recebe uma resposta muito confiante, um SQL plausível e nenhum dado.
Vale ser específico sobre o risco, porque o pedido parece inofensivo. Rodar o agente de novo significa uma segunda sessão sem supervisão contra um banco em produção que já perdeu alguma coisa. Se ele decidir que o jeito de consertar uma tabela que sumiu é criar uma, agora tem uma tabela nova e vazia onde estava a antiga, e você deixou a perda mais difícil de descrever para quem for te ajudar depois.
Tire ele do projeto até você saber onde está pisando. O mesmo vale para o histórico de versões do seu builder: voltar o código para hoje de manhã restaura as suas páginas e deixa os seus dados exatamente onde estão, por razões que vale entender uma vez.
Onde procurar, nesta ordem
Desça esta lista e pare na primeira que existir. Ela está ordenada por quanto dos seus dados volta, que não é a mesma ordem de facilidade.
| Onde procurar | O que pode devolver | O que já precisava ser verdade |
|---|---|---|
| Recuperação do Supabase para um momento | O banco como estava em um minuto que você escolhe, inclusive o minuto antes da exclusão | Um plano pago com o adicional de PITR, contratado antes de hoje |
| Backup diário do Supabase | O banco como estava na última cópia automática | Um plano pago |
| Um serviço de backup gerenciado | O banco como estava na última cópia verificada daquele serviço | Você conectou um antes de hoje |
Um pg_dump que você mesmo rodou | Tudo o que estiver no arquivo, tão velho quanto a última vez que você lembrou | O arquivo existe e terminou de ser escrito |
| Uma tabela de exclusão suave ou auditoria no app | Só as linhas das quais o seu app já guardava registro | Você construiu assim de propósito |
| O histórico de versões do seu builder | Nada | Ele versiona o seu código, e os seus dados vivem em outro serviço. |
| Perguntar de novo para o agente | Nada | Ele nunca teve uma cópia das suas linhas. |
Todo caminho que devolve alguma coisa tem a mesma exigência, e é ela que resolve a questão: ele precisava existir antes da exclusão. Nenhum deles liga agora e alcança o passado. O plano do Supabase que você tem resolve os dois primeiros, e verificar leva uns dois minutos.
O que volta e o que cai no intervalo
A cópia, do jeito que estava, e nada do que aconteceu depois dela.
As linhas criadas entre aquela cópia e a exclusão não estão danificadas nem escondidas em algum canto. Elas nunca foram escritas em lugar nenhum além do banco de onde foram removidas. Essa é a parte difícil de aceitar diante de uma tabela vazia, porque perder alguma coisa normalmente quer dizer que ela ainda está em algum lugar.
A largura dessa faixa depende inteiramente do que estava tirando as cópias. Um backup noturno pode colocar um dia inteiro de trabalho dentro dela. A recuperação para um momento específico estreita a faixa para um minuto, e é quase todo o motivo de ela custar à parte. Um dump que você tirou no dia em que lembrou coloca dentro todo o tempo que passou desde então.
Existe uma versão disso em que o intervalo quase não pesa, num app cujos dados são principalmente conteúdo seu e mudam devagar. E existe uma em que ele pesa muito: qualquer coisa com pedidos, mensagens ou cadastros, onde um dia de linhas é um dia de pessoas que vão perceber.
O agente apagou uma parte, não tudo
Aí você tem uma escolha de verdade para fazer, e nenhuma das duas respostas é limpa.
Uma restauração não recoloca as linhas que faltam deixando o resto em paz. Ela substitui as tabelas da cópia pelo que aquelas tabelas tinham na época, por inteiro. Restaurar traz de volta o que o agente removeu e reverte cada linha boa escrita desde então. Não restaurar mantém as linhas boas e deixa o buraco.
Qual está certa depende de quanto trabalho legítimo existe depois da cópia. Se a resposta for quase nenhum, restaure e siga o seu dia. Se a resposta for três dias de cadastros de clientes, o caminho lento costuma ganhar: exportar primeiro as linhas sobreviventes, restaurar, e depois recolocar as linhas exportadas por cima. É trabalhoso, e é o único caminho que não perde nada.
É também o argumento para copiar o banco no estado quebrado em que ele está antes de encostar em qualquer coisa. Decida o que decidir, você quer conseguir voltar para o estado de onde partiu.
Como essa mesma hora corre quando já existe uma cópia
Mais curta, e mais uma decisão do que uma procura. Você escolhe uma cópia, olha o que ela guardava e aperta o botão.
É isso que o Reeve Care faz: cópias verificadas do seu banco do Supabase num calendário, criptografadas e guardadas fora da sua conta do Supabase, com uma restauração em um clique atrás delas. Antes de uma restauração começar, ela tira uma cópia nova do estado atual, para que a própria restauração possa ser desfeita.
Os limites vão na mesma frase, porque conhecer eles é como você decide se serve:
- Ele copia o seu banco de dados, e os arquivos que os seus usuários enviaram assim que você conecta os seus buckets do Storage. É opcional e pede uma segunda chave.
- Hoje ele funciona com o Supabase e com mais nada.
- Você restaura para uma cópia que existe, não para qualquer minuto que quiser citar. Na pior das hipóteses você perde um intervalo, ou seja, até uma noite no plano de entrada e menos nos dois acima dele.
- As contas de acesso nunca são tocadas. Ninguém é deslogado, apagado ou trazido de volta.
- A chave de banco que ele guarda só sabe ler, e essa foi a promessa quando você conectou. Escrever dados de volta exige uma que saiba escrever, então uma restauração pede a senha do seu banco toda vez e não guarda nenhuma. A chave opcional para os seus arquivos sabe escrever, porque o Supabase não emite nenhuma somente leitura para o Storage, e a página onde você a entrega diz isso antes.
O que cada plano cobre está na página inicial. Se você preferir não
pagar por nada disso, a versão simples da mesma proteção é um pg_dump num
calendário que você realmente cumpra, guardado em algum lugar que perder a sua
conta do Supabase não levaria junto.
Os três caminhos e o que escapa de cada um
passa por isso sem discurso de venda.
Essa hora está mostrada, cópia por cópia, na página de backups do Supabase.
O que fazer agora
O que fazer
- Pare tudo o que escreve no banco. É o único passo daqui que fica mais caro quanto mais você demora.
- Descubra quais cópias existem antes de decidir qualquer coisa: primeiro o seu plano do Supabase, depois qualquer dump que você mesmo tirou, depois se o seu app guarda registro das linhas apagadas.
- Copie o banco do jeito que ele está agora, quebrado e tudo. Faça o que fizer em seguida, você quer um caminho de volta até aqui.
- Depois de uma restauração, verifique se o app ainda consegue escrever. Um banco que lê certo e recusa um insert é uma restauração pela metade, e só um insert prova isso.
- Quando o urgente passar, monte a cópia que teria transformado tudo isso num problema de dez minutos em vez de uma manhã.
Antes de fechar esta aba, abra o seu projeto no Supabase e descubra se alguma coisa está copiando o seu banco, e anote onde essa cópia fica. A checklist de segurança de 10 minutos cobre isso junto com o resto do que vale confirmar num app recém-lançado.
Perguntas frequentes
Um agente de IA apagou linhas no meu banco do Supabase. Dá para trazer de volta?
Só a partir de uma cópia feita antes de ele rodar, então a primeira coisa é descobrir se existe alguma. Veja o que o seu plano do Supabase inclui, depois procure qualquer dump que você mesmo tenha tirado, depois veja se o seu app por acaso guarda registro das linhas apagadas. Se nada disso existir, as linhas se foram, e nenhum trabalho no app vai mudar isso. Descubra tudo isso antes de escrever qualquer coisa nova no banco.
Posso pedir para o agente devolver os dados?
Não. O agente nunca teve as suas linhas. Ele mandou uma instrução para o seu banco e o banco executou, então o que ele tem agora é a transcrição da conversa, não uma cópia da tabela. Pedir para ele desfazer a exclusão devolve uma resposta muito confiante e nenhum dado. E significa uma segunda sessão sem supervisão contra um banco que já perdeu alguma coisa.
Estou no plano gratuito do Supabase. Tem alguma coisa para recuperar?
Do Supabase, não. Os backups automáticos começam nos planos pagos, e a recuperação para um momento específico é um adicional acima disso, então um projeto gratuito não tem cópia de ontem em lugar nenhum. Sobra um dump que você mesmo tenha tirado, ou uma tabela de exclusão suave ou de auditoria que o seu app já escrevia. Verifique as duas antes de dar tudo por perdido, e verifique antes de continuar usando o app.
Devo deixar o app rodando enquanto decido o que fazer?
Desligue tudo o que escreve. Leitura não é problema. Linhas novas são problema em dobro: restaurar uma cópia remove tudo o que entrou depois dela, então um pedido que chega agora é um dado que você mesmo vai apagar mais tarde, e uma volta para um momento específico tem mais trabalho de verdade para jogar fora quanto mais você demora. Um aviso de manutenção por uma hora custa menos que a segunda perda.
O agente apagou algumas linhas, mas não todas. Restauro tudo mesmo assim?
Esse é o caso desconfortável, e não existe resposta limpa. Uma restauração substitui por inteiro as tabelas da cópia, então ela traz de volta o que você perdeu e ao mesmo tempo reverte cada linha boa escrita desde então. Qual caminho seguir depende de quanto trabalho de verdade existe depois da cópia. Se for muito, exportar antes as linhas sobreviventes e recolocá-las por cima da restauração é mais lento e não perde nada.