Vibecoding
Como fazer backup do seu projeto e não perder nada
Todo mundo faz backup depois de perder algo pela primeira vez. Faça antes.
Existem dois tipos de gente: quem faz backup e quem ainda vai perder tudo pela primeira vez.
Eu já fui o segundo tipo. Perdi um projeto de semana num HD que morreu. Aprendi na dor. Você não precisa.
Meu take: backup não é uma cópia. É várias cópias, em lugares diferentes, e pelo menos uma testada. Cópia que você nunca restaurou não é backup. É esperança.
A regra 3-2-1
É o padrão da indústria e funciona:
- 3 cópias dos dados.
- 2 mídias diferentes.
- 1 fora do local (offsite, na nuvem).
Traduzindo pra vibecoder: seu código na máquina, no GitHub e o banco exportado num storage na nuvem. Se um pega fogo, você tem os outros.
Passo 1: código no Git remoto
Git na sua máquina não é backup. É versionamento local. Se o notebook morre, morreu junto.
Suba pra um remoto:
git remote add origin https://github.com/voce/seu-projeto.git
git push -u origin main
Agora seu código existe em dois lugares. Toda vez que fizer algo importante:
git add .
git commit -m "feat: descrição clara"
git push
Repositório privado, sempre, se tiver segredo ou lógica de negócio. Falo mais nisso quando o assunto é vazamento.
Passo 2: banco de dados é outra história
Aqui mora o erro mais comum. As pessoas acham que Git salva tudo. Git salva código. Não salva os dados dos seus usuários.
Se você usa Firebase, Postgres, MySQL, o banco precisa de rotina própria. Exemplo com Postgres:
pg_dump -U usuario nome_do_banco > backup_2026_08_12.sql
Isso gera um arquivo com todos os dados. Guarde esse arquivo fora da máquina do banco. Storage na nuvem, bucket separado.
No Firebase, use o export do Firestore agendado pro Cloud Storage. Configura uma vez e esquece.
Passo 3: automatize ou vai esquecer
Backup manual é backup que você faz duas vezes e abandona. Automatize.
Um cron simples que roda todo dia às 3h:
0 3 * * * pg_dump -U usuario banco > /backups/backup_$(date +\%F).sql
Depois manda pra nuvem. Guarde os últimos 7, 30 dias, o que fizer sentido. Backup antigo demais some sozinho pra não lotar.
Passo 4: teste a restauração
Este passo é o que separa quem tem backup de quem acha que tem.
Uma vez por mês, pegue um backup e restaure num ambiente de teste. Veja se os dados voltam inteiros.
psql -U usuario banco_de_teste < backup_2026_08_12.sql
Se restaurou, você tem backup de verdade. Se nunca testou, você tem um arquivo e uma reza.
O checklist de backup
Cola na parede:
- Código no Git remoto e privado.
- Banco exportado automático, todo dia.
- Cópias em pelo menos dois lugares.
- Uma cópia na nuvem, fora do servidor.
- Restauração testada uma vez por mês.
Vibecoding com engenharia é assumir que tudo pode dar errado e estar pronto. O HD morre. A conta é suspensa. O comando errado apaga a tabela. Backup é o que te faz dormir.
Faça antes de perder. Não depois.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Git ja nao e backup?
Git versiona seu codigo, mas se so existe na sua maquina, nao e backup. Precisa estar num remoto tambem.
+E o banco de dados?
Codigo no Git nao salva seus dados. Banco precisa de rotina de dump separada, automatica e testada.
+Com que frequencia?
Depende do quanto voce aguenta perder. Se perder um dia dói, faça backup diario.
Continue lendo
Como não virar refém de uma ferramenta de IA
A ferramenta que você ama hoje pode dobrar de preço, mudar de dono ou fechar amanhã. Não construa em cima de uma só.
VibecodingO que fazer quando a IA te dá código que você não entende
A tentação é apertar aceitar e seguir. Não faça. Código que você não entende é código que você não mantém.
VibecodingPor que backup não é opcional
Existe quem faz backup e quem ainda não perdeu tudo. Você escolhe de qual lado ficar antes ou depois.