Quando a Sony anunciou que vai parar de vender jogos de PlayStation em mídia física, a indústria virou o jogo do “digital vs. tangível” de novo. E aí veio o GitHub — comprado pela Microsoft — provocando com a promessa de entregar repositórios públicos em CD-ROM. É uma brincadeira? Sim. Mas por trás do meme existe um ponto sério: custódia do código, portabilidade e disponibilidade. Na minha experiência, devs subestimam isso até dar um problema bobo e caríssimo.
O que o GitHub prometeu (e por que a provocação funcionou)
Segundo o Tecnoblog.net, a provocação partiu da conta oficial do GitHub no X: “agora você pode obter seu repositório público em CD-ROM”. A mensagem era claramente irônica, cheia de tom de “guarde, empreste, passe adiante”, como se código fosse um álbum.
Porém, o “por trás” é muito técnico. Repositórios em plataforma SaaS (como GitHub/GitLab/Bitbucket) trazem conveniência. Mas também introduzem dependências: permissões, quotas, políticas de remoção, mudanças de API, incidentes de serviço e, claro, o fator humano (contas desativadas, repositórios apagados, ingestão errada).
O CD-ROM é simbólico. A ideia real é: se algo falhar no provedor, seu trabalho ainda existe.
Custódia do código: plataforma é “onde roda”, não “onde vive”
Eu gosto de resumir assim: “GitHub não é backup; é um serviço de colaboração.”
Quando você hospeda tudo no GitHub e confia só nele, você passa a depender de: credenciais, configurações de branch protection, defaults do repositório e limites de retenção. E “cópia” não é só existir — é existir com histórico completo, tags, commits e (muitas vezes) LFS.
O “CD-ROM” é meme, mas o padrão de maturidade é sério
Se você quer tratar isso como engenharia (não marketing), o que importa é: como você gera, valida e restaura artefatos. Em produção, eu aplico três camadas:
- Controle de versão (Git) com repositório clonado.
- Artefatos auxiliares (CI logs, releases, packages, modelos, seeds).
- Teste de restauração (sim, você valida se consegue recuperar).
O CD é só um “meio”. A engenharia é o processo.
Alternativas reais para “levar seu código pra qualquer lugar”
Vamos comparar com opções que devs usam de verdade — e onde cada uma acerta ou falha.
1) Clone em múltiplos remotos (mirror)
Você mantém o mesmo repositório em outro provedor, ou em storage próprio. Isso reduz risco de “um provedor cai” ou “políticas mudam”.
O porquê: Git lida bem com espelhamento e permite manter histórico. A armadilha: muita gente faz espelho uma vez e esquece de manter o espelhamento atualizado.
2) Backup de repositórios (bare + snapshots)
Crie um repositório bare e guarde com snapshots versionados. Não precisa ser caro. O ponto é ter consistência e retenção.
O porquê: você consegue restaurar exatamente o estado dos commits. A armadilha: esquecer LFS e dependências externas.
3) Artefatos de release e dependências (não só o .git)
Código sem build reprodutível vira “cópia sem utilidade”. Em IA e web, isso é ainda mais evidente por causa de modelos, weights e caches.
O porquê: seu “projeto” inclui lockfiles, container images e datasets/weights. A armadilha: achar que package-lock.json ou poetry.lock “resolve tudo” (resolve parte, mas não substitui build determinística).
Na prática: como criar um backup “restaurável” de um repositório GitHub
Vou te passar um passo a passo que eu uso para repositórios pessoais e projetos internos. A ideia é produzir uma pasta que você consegue restaurar em qualquer máquina.
- Clone bare (sem working tree): só histórico e refs.
git clone --mirror https://github.com/USUARIO/REPO.git - Empacote com versionamento (ex.: por data).
tar -czf REPO-$(date +%Y-%m-%d).tar.gz REPO.git - Se usa Git LFS, baixe o conteúdo para o backup não virar “vazio”.
cd REPO.git git lfs fetch --all cd .. - Teste de restauração em uma pasta temporária.
mkdir /tmp/restore-test cd /tmp/restore-test git clone REPO-$(date +%Y-%m-%d).tar.gz REPO-restored - Valide o estado (tags, branches e um build rápido).
cd REPO-restored git tag --list # e rode um build mínimo do seu projeto # npm ci && npm test (exemplo)
Se você quiser algo mais “corporativo”, dá para automatizar isso via cron + storage S3/Drive + retenção. Mas o ponto central é: backup que você não testa é só arquivo.
Repositório público vs. privado: o risco muda
O post do GitHub fala em repositórios públicos. Em privado, a dependência é ainda maior: acesso, permissões e políticas internas. Então, para times, espelho e backup local viram parte da rotina.
Erros Comuns: o que devs fazem e depois se arrependem
1) “Tenho no GitHub, então está salvo”
Ter no GitHub é ótimo para colaboração, mas não substitui backup. Incidentes acontecem e também acontecem exclusões acidentais.
2) Backup sem LFS (o projeto quebra na restauração)
Se o repositório usa LFS (imagens, datasets, weights, binários), seu “histórico” pode existir, mas o conteúdo fica ausente. Você restaura um ponteiro, não o dado.
3) Esquecer o reprodutível: lockfiles, toolchains e runtime
Um build que “funciona na minha máquina” geralmente não funciona após restauração. Para web, lockfiles ajudam; para IA, weights e versões de dependências são determinantes.
4) Não versionar ambiente (Docker/containers)
Se o projeto depende de versões específicas, considere contêiner ou ao menos documentação estrita. A falta disso vira um ataque ao tempo: você perde horas reconstituindo ferramentas.
5) Espelhar uma vez e nunca atualizar
Mirror manual sem automação é um “backlog de manutenção”. Depois de alguns meses, seu espelho está defasado e perde a utilidade no incidente.
Ligando com o mundo real: implicações para web, DevOps e IA
Essa discussão é especialmente relevante para quem trabalha com automação e dados.
- CI/CD: logs e configurações (GitHub Actions, por exemplo) são parte do “projeto”. Backup do repo não garante que secrets/variáveis existam do mesmo jeito ao restaurar.
- IA: modelos e pesos raramente ficam “só” no Git. Sem bucket, tracking correto e retenção, você perde o que faz o sistema funcionar.
- Web: builds dependem de Node, browsers, bundlers e configuração de environment. Backup do código sozinho não garante reprodução.
Um trecho funcional: gerar checksum do backup para detectar corrupção
Eu gosto de adicionar checagem simples. Código pode estar certo… ou o arquivo backup pode ter corrompido no transporte. Checksums te poupam da mentira silenciosa.
tar -czf REPO-$(date +%Y-%m-%d).tar.gz REPO.git
sha256sum REPO-$(date +%Y-%m-%d).tar.gz > REPO-$(date +%Y-%m-%d).sha256Depois, na restauração, você confere o hash antes de “investir tempo” reconstruindo o ambiente.
FAQ
O GitHub realmente vai me mandar um CD-ROM de verdade?
Na prática, é uma provocação. Segundo o Tecnoblog.net, foi anunciada via conta oficial do GitHub com tom irônico. Mas o valor para dev é o lembrete: não trate hospedagem como backup.
Backup de repositório basta para projetos web?
Não. Você precisa garantir também lockfiles, configuração de build e, idealmente, reprodutibilidade via containers ou documentação determinística. O código é só metade do “funciona de novo”.
Como faço backup se meu projeto usa Git LFS?
Use clone mirror e rode git lfs fetch --all antes de empacotar. Depois teste a restauração e confira se os arquivos grandes aparecem de fato.
Espelhar para outro provedor substitui backup?
Ajuda muito, mas não substitui completamente backup com snapshots e retenção. Outra plataforma pode ter incidentes/políticas. O ideal é ter mais de uma camada e testar recuperação.
Qual é o “porquê” de testar restauração?
Porque o problema real quase nunca é “o repositório sumiu”. O problema é “sumiu do jeito errado”: LFS faltando, branch esquecida, build não reprodutível, lockfile ausente. Testar revela isso cedo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.