Reeve Backups
O histórico de versões não é backup. Ele não desfaz um delete.
Lovable e Bolt guardam um histórico de versões do seu código. Seu banco de dados é um serviço à parte, e voltar atrás não traz os seus dados de volta.
Em resumo
- O histórico de versões restaura o seu código. Ele nunca encosta no seu banco de dados, que é onde estão os seus usuários, o conteúdo deles e os pedidos deles.
- Ou seja: uma tabela apagada, uma linha sobrescrita ou uma migração torta sobrevivem inteirinhas a um rollback.
- Seu código já vem com um desfazer. Seus dados só têm um se você colocar um lá.
Alguma coisa quebrou, então você fez o mais sensato. Abriu o histórico de versões no Lovable ou no Bolt, achou a versão desta manhã e clicou em restaurar. O app voltou exatamente como estava.
Os dados não.
Aqui está a parte em que as pessoas tropeçam: o seu código e os seus dados são dois sistemas separados, e só um deles tem botão de desfazer. O seu builder guarda a planta do seu app. O seu banco de dados guarda o que tem dentro. O histórico de versões reconstrói a planta com perfeição, até o último detalhe, e te devolve um prédio idêntico e vazio.
O histórico de versões do meu builder faz backup do meu banco de dados?
Não. Ele salva o seu código, e os seus dados moram em outro lugar completamente diferente.
Lovable, Bolt, v0, Replit, Cursor e os demais mantêm todos um histórico dos arquivos do seu projeto: suas páginas, seus componentes, sua lógica, seu visual. Isso é a planta. Restaurar uma versão reescreve esses arquivos como estavam no dia que você escolheu.
Seu banco de dados é outro serviço, quase sempre o Supabase, numa conta só dele. Nada no histórico do seu projeto entra ali. A restauração não tem opinião nenhuma sobre os seus dados porque não consegue enxergá-los.
Por que o seu código e os seus dados ficam em lugares diferentes
Porque os seus dados precisam sobreviver ao que o seu código faz o tempo todo, que é mudar.
Seu código é reconstruído toda vez que você publica. Se os pedidos dos seus usuários morassem lá dentro, sumiriam toda vez que você consertasse um botão. Por isso os dois são mantidos separados, de propósito: o código é substituível e os dados não são, e é por isso que quem os versiona são ferramentas diferentes.
O preço dessa separação é o assunto deste artigo. Toda ferramenta que versiona um dos dois é cega para o outro. Seu builder não consegue trazer uma tabela de volta, e o seu banco não consegue trazer de volta uma página quebrada.
O que acontece de verdade quando você volta atrás
Suas telas voltam para como estavam. Seus dados não saem do lugar.
| O quê | Ao voltar o código |
|---|---|
| Páginas, componentes, visual | Restaurado |
| A lógica do seu app e as correções dela | Restaurado |
| Uma tabela que alguém apagou | Continua apagada |
| Linhas que um script sobrescreveu | Continuam sobrescritas |
| Uma coluna que uma migração removeu | Continua removida |
| Arquivos que seus usuários enviaram | Sem mudança em nenhuma direção |
A linha da migração é a que mais surpreende. Uma migração que você rodou contra o seu banco já aconteceu; ela mora no banco, não no seu repositório, e desfazer o arquivo que a descrevia não muda nada.
Onde isso morde de verdade
Nos dez minutos depois de um erro, quando você vai procurar o desfazer e descobre que não tem.
Os formatos que isso assume são bem comuns:
- Um delete no editor de tabelas do Supabase que pegou mais linhas do que você queria.
- Uma migração assistida por IA que removeu uma coluna para fazer sumir um erro de tipo.
- Um script de seed ou de reset apontado para o projeto em produção em vez de um de teste.
- Uma limpeza do que parecia dado de teste e era a conta real de alguém.
Nada disso encosta numa única linha do seu código. Cada uma dessas coisas sobrevive inteira a um rollback, e é por isso que o rollback parece não ter feito nada. Ele fez exatamente o que faz.
Para que o histórico de versões serve de verdade
Para bastante coisa, e vale dizer isso com clareza, porque a resposta não é "para nada".
Ele é um desfazer de verdade para problemas de verdade: uma mudança de design da qual você se arrependeu, uma publicação que quebrou uma página, uma edição da IA que reescreveu para pior uma tela que funcionava, uma funcionalidade que acabou deixando o app mais difícil de usar. Tudo isso mora no seu código, e para isso ele funciona exatamente como promete.
O problema é a suposição silenciosa de que o trabalho dele cobre tudo. Ninguém faz essa suposição de propósito; é a que sobra quando ninguém te contou que são dois sistemas.
Como conseguir um desfazer de verdade para os seus dados
Você tem que colocar um lá. Ou seja, uma cópia do banco, tirada num horário, guardada em algum lugar que perder a conta não levaria junto.
Existem três jeitos de fazer isso, custam quantias e atenção diferentes, e cada um deixa passar algo que os outros cobrem. Três formas de fazer backup de um banco Supabase passa pelos três, incluindo o que quase todo mundo deveria ligar primeiro e o motivo de ele não bastar sozinho.
É para isso que o Reeve Care também serve: cópias programadas do seu banco do Supabase, guardadas fora da sua conta do Supabase e conferidas antes de contarem como feitas. Conecte os seus buckets do Storage e os arquivos que os seus usuários enviaram vão junto, de modo que uma restauração devolve as linhas e as imagens para as quais elas apontam.
O que uma dessas cópias contém, e o que o botão realmente faz, está na página de backups do Supabase.
O que fazer esta semana
O que fazer
- Descubra se alguma coisa está fazendo backup do seu banco agora. Não do seu código: do seu banco. Se a resposta demorar mais de um minuto para aparecer, a resposta é não.
- Ligue o backup que o seu plano do Supabase inclui. Ele te protege dos seus próprios erros, que é exatamente a falha de que trata este artigo.
- Guarde também uma cópia em outro lugar, porque um backup que mora dentro da conta não te ajuda se você perder a conta.
- Faça backup dos arquivos enviados separadamente. Eles não estão nem no seu código nem no seu banco.
- Restaure uma cópia num projeto descartável, para que a primeira vez que você ler esse arquivo não seja o dia em que precisa dele.
Antes de fechar esta aba, abra o seu projeto no Supabase e veja se os backups estão ligados. Essa única conferida é todo o trabalho de hoje. O checklist de segurança de 10 minutos cobre isso junto com o resto do que vale confirmar num app recém-lançado, e o guia de segurança do Supabase passa pelo que mais costuma ficar aberto.
Perguntas frequentes
Apaguei uma tabela sem querer. Consigo trazer de volta?
Só de um backup feito antes do delete, então a primeira coisa é descobrir se existe algum. Voltar o seu código não resolve, e o seu builder também não. Num plano pago do Supabase existem backups diários, e recuperação para um ponto no tempo se você adicionou. No plano gratuito não há nada automático. Veja o que você tem antes de mexer em qualquer outra coisa, porque alguns caminhos de volta ficam mais difíceis assim que dados novos começam a ser escritos por cima do buraco.
O Lovable faz backup do meu banco no Supabase?
O seu builder versiona os arquivos do seu projeto. Seu banco de dados é um serviço separado na sua própria conta do Supabase, e nada no histórico do projeto entra ali. Builders ganham funcionalidades novas, então consulte a documentação do seu em vez de supor num sentido ou no outro, mas parta do princípio de que a resposta é não até ter lido que é sim.
Meu histórico do Git é um backup?
Não, exatamente pelo mesmo motivo que o histórico de versões não é. O Git acompanha os arquivos com que o seu app é construído. Ele nunca viu uma única linha dos seus dados e não consegue devolver nenhuma. Um repositório e um banco de dados são coisas diferentes que por acaso se chamam as duas "o seu projeto".
Meus dados estão todos aí. Preciso fazer alguma coisa hoje?
Hoje é o dia mais barato em que você vai montar isso, porque os dados são poucos e o que importa é o hábito existir antes de precisar dele. As perdas que doem raramente são dramáticas. São um comando digitado errado durante um conserto de madrugada, num projeto com usuários reais o suficiente para recomeçar não ser uma opção.