git-annex - Ferramenta de gerenciamento de arquivos grandes para usuários de Git
(git-annex.branchable.com)- git-annex é uma ferramenta que permite gerenciar arquivos grandes sem colocar seu conteúdo diretamente no repositório Git
- Realiza sincronização, backup e arquivamento em ambientes offline e online, garantindo segurança com checksums e criptografia
- Aplica a natureza distribuída do Git a arquivos grandes, simplificando o rastreamento de localização e a transferência entre vários drives, servidores e nuvens
- É adequada para usuários focados em CLI, e o git-annex assistant oferece, para usuários em geral, uma usabilidade no estilo sincronização de pastas
- É uma ferramenta que amplia fluxos de trabalho de arquivamento e movimentação por meio de um formato de repositório simples para preservação de longo prazo e vários special remotes
Visão geral
- git-annex é uma ferramenta de gerenciamento de arquivos grandes que mantém o conteúdo dos arquivos fora do Git e gerencia apenas metadados e informações de localização no Git
- Como resultado, o histórico de commits permanece leve, enquanto o armazenamento e a movimentação de binários grandes são tratados com flexibilidade
- Garante integridade e confidencialidade com checksums e suporte a criptografia
- Realiza sincronização, backup e arquivamento tanto offline quanto online e oferece funções de gerenciamento da quantidade de cópias do mesmo arquivo entre armazenamentos distribuídos, além de registro em logs
- É otimizado para usuários de linha de comando, mas também pode ser usado facilmente por usuários em geral em um formato de sincronização de pastas por meio do git-annex assistant
- Fornece a documentação walkthrough para novos usuários aprenderem rapidamente instalação, fluxo básico e mais
Caso de uso: Archivist (usuário orientado a arquivamento)
- Mesmo operando vários drives de arquivamento offline, é possível navegar e reorganizar todos os arquivos como se fossem um só dentro de uma única árvore de diretórios
- Mesmo que o conteúdo do arquivo esteja em um drive offline, é possível reposicionar e fazer commit por meio de índices e ponteiros sem risco de exclusão real
- Quando um arquivo específico é necessário, a ferramenta informa em qual drive ele está e permite torná-lo disponível com facilidade
- Cada drive compartilha informações mútuas de localização, permitindo compreender o estado geral do acervo
- Usa um formato de repositório simples, de modo que a acessibilidade aos arquivos é mantida no longo prazo mesmo sem usar git-annex ou Git
- Com tarefas cron, novos arquivos podem ser arquivados automaticamente à noite, e cópias intencionais e não intencionais são registradas para servir de base na decisão de quando é necessário replicar
Caso de uso: Nomad (usuário orientado à mobilidade)
- Gerencia de forma consistente armazenamentos heterogêneos, como notebook, drives USB/pendrives portáteis, servidores remotos e armazenamento em nuvem criptografado, como se fossem remotes do Git
- Em movimento, é possível acumular uma fila de downloads no servidor e executar a transferência real em um local com melhor qualidade de conexão, dando suporte a um fluxo de transferência adiada
- Também é possível montar workflows amigáveis ao uso offline, como copiar instantaneamente do USB e consumir localmente, por exemplo para economizar bateria
- Após o uso, ao definir o que deve ser mantido ou excluído, recupera-se espaço local e, na próxima sincronização, as alterações são sincronizadas com o servidor
- Com special remotes e pipelines de transferência, viabiliza movimentação de dados flexível em vários backends de armazenamento e condições de rede
Recursos centrais e benefícios
- Implementa preservação segura de longo prazo com garantia de integridade baseada em endereçamento por conteúdo e checksums, além de suporte a armazenamento criptografado
- Por meio de rastreamento de localização (location tracking), permite entender claramente onde cada arquivo está armazenado, quantas cópias existem e sua disponibilidade
- Aplica o modelo de controle de versão distribuído a arquivos grandes, reduzindo a dependência de armazenamento centralizado e garantindo resiliência offline
- Com o modo assistant, oferece uma experiência de sincronização de pastas, permitindo usabilidade em nível de arrastar e soltar mesmo para quem não domina CLI
Resumo das vantagens
- O git-annex gerencia apenas referências de arquivos no Git, por isso é ideal para lidar com arquivos grandes sem sobrecarga
- Sua estrutura distribuída permite mover, armazenar, sincronizar/fazer backup e versionar arquivos livremente entre vários dispositivos e locais
- Destaca-se especialmente pela integração e escalabilidade em cenários offline e de preservação de longo prazo, ou na gestão dinâmica de dados entre vários dispositivos e nuvens
- Também é adequado para usuários com perfil híbrido entre arquivamento e mobilidade, sendo útil tanto para organizações quanto para indivíduos graças ao gerenciamento de políticas de cópias e à diversificação de backends
- É uma ferramenta que estende a natureza distribuída e a portabilidade do Git para dados de grande porte, reduzindo os riscos operacionais e o esforço em tarefas de armazenamento de longo prazo e movimentação
1 comentários
Comentários no Hacker News
Eu uso o git-annex para gerenciar os dados de todos os meus drives. Ele rastreia automaticamente em qual drive cada arquivo está, mantém cópias suficientes e verifica os checksums de todos os arquivos. Também funciona muito bem com drives offline. O git-annex pode parecer um pouco difícil de entender no começo, então recomendo criar um repositório temporário, seguir o walkthrough e praticar. Também vale a pena dar uma olhada em diferentes workflows
Fico curioso sobre quanto dado você está armazenando. Eu gerencio algo entre 100 mil e 1 milhão de arquivos, com vários TB de fotos, usando ZFS com git-annex. No começo não havia problema algum, mas recentemente ficou cada vez mais lento, a ponto de cada comando levar de 5 a 30 minutos. Não sei dizer se isso é por causa do ZFS, do git-annex ou do disco
Já pensei em usar git-annex para gerenciar dados há muito tempo, mas encontrei algum atrito para apagar arquivos completamente e também esbarrei em alguns problemas. Se tiver tempo, queria saber se você poderia compartilhar como usa
Não aparece na página, mas o git-annex foi criado por Joey Hess. Ele também desenvolveu moreutils e etckeeper
Houve uma discussão aqui recentemente sobre o novo recurso nativo do Git para gerenciamento de objetos grandes
O ponto fraco do git-annex é ser em Haskell. Não é que eu odeie a linguagem em si, mas fiquei chocado com a quantidade de dependências para instalar. Muitas delas não servem para mais nada, e conflitos de versão entre aplicações são frequentes. Fica especialmente difícil ao instalar com o gerenciador de pacotes do sistema. Só de instalar annex e pandoc já aparecem dezenas de atualizações de pacotes Haskell por dia. Se você usa uma distro que compila tudo do código-fonte, é um pesadelo. Na verdade, acho que a maior parte disso poderia ser vinculada estaticamente com segurança. Ainda assim, no ecossistema Haskell isso é tratado como resultado da modularização extremamente granular de bibliotecas. Mas existem outras prioridades, como administração de sistema, e eu nunca vivi esse tipo de problema com Rust, Go, Zig, C ou C++. Não sou hostil ao ecossistema Haskell nem aos seus usuários, e até penso em aprender. Só quero entender por que esse problema existe e qual seria a solução
O tooling de Haskell já oferece suporte a linkagem estática. Eu mantenho a stack Haskell no Solus, e o pandoc depende apenas de libc; todos os pacotes Haskell ficam vinculados estaticamente ao binário e são distribuídos do mesmo jeito que em Rust. Ou seja, dá para fazer sim. No Solus usamos linkagem estática justamente por causa do excesso de dependências. Acho que isso é uma decisão do mantenedor da distribuição
Sobre a parte de “a maior parte disso poderia ser vinculada estaticamente com segurança”, se for em repositórios de distro, não seria no fim uma questão de política do gerenciador de pacotes?
Mesmo como desenvolvedor Haskell em tempo integral, eu tenho a mesma rejeição a pacotes Haskell sem linkagem estática. Já existem versões com linkagem estática no AUR, então pelo menos não é algo impossível. Nunca investiguei a fundo por que os empacotadores insistem em linkagem dinâmica. Em geral, a dinâmica pode fazer sentido para distribuição de software interno, mas talvez isso esteja sendo projetado desnecessariamente para distribuições
Fico curioso sobre qual gerenciador de pacotes você usa. Em sistemas baseados em apt, nunca tive problemas causados por Haskell
Toda vez que dou
pacman -Syu, metade das atualizações são pacotes Haskell, o que me irrita. Imagino que o motivo seja pandoc ou shellcheckO git-annex é uma tecnologia muito legal. Mas minha impressão é que ele funciona melhor em repositórios de um único usuário. Por exemplo, quando uma pessoa quer gerenciar seus próprios arquivos, documentos, músicas e outros dados pessoais em vários dispositivos. Já tentei usá-lo em um repositório colaborativo com arquivos grandes para fins de sincronização, mas o esquema de branch "magic" não escala bem
Eu uso um forgejo self-hosted. Ainda não encontrei em que o git-annex seria superior ao LFS, e imagino que a configuração também não seja simples. Também não gosto do fato de o git-annex ser escrito em Haskell, e encontrei comentários dizendo que ele é cerca de 50% mais lento (embora tenha visto isso em uma única fonte, então ainda não sei se é confiável). Deve haver um motivo para os comandos serem complexos, mas ele não tem a conveniência do LFS, em que praticamente tudo fica claro só mexendo no
.gitattributes. Também não senti no git-annex uma transparência parecida com a do.gitattributes. E, se nem existir um tutorial mostrando o equivalente a 'git lfs ls-files', provavelmente eu não vou me interessar muito. Tenho o hábito de verificar com 'git status' e 'git lfs ls-files'A lentidão não é por causa do Haskell. O git-annex é uma ferramenta de backup distribuído, então a lentidão vem do forte foco em I/O e preservação de dados. Por exemplo, ao usar o comando drop, ele precisa verificar em tempo real se aquele conteúdo existe em todos os remotes, e isso demora. Se você usar a opção --fast e afins, confiando apenas nos metadados locais e pulando a verificação, fica bem mais rápido (mas é um pouco mais arriscado)
LFS e git-annex têm finalidades um pouco diferentes. LFS serve melhor para exemplos de desenvolvimento em que arquivos grandes se misturam ao repositório git, como desenvolvimento de jogos. Já o git-annex combina mais com backup de dados importantes, quando você quer manter grandes conjuntos de arquivos, como uma pasta de músicas, em vários lugares. Eu uso mais nesse segundo formato
Existe um soft-fork do Forgejo com suporte a git-annex: forgejo-aneksajo
O maior repositório que gerencio com git-annex tem vários TB distribuídos entre vários sistemas, com muitos arquivos acima de 10 GB. Se o que o autor quer é algo como git-lfs-ls-files, no git-annex o mais parecido provavelmente é
git annex list --in hereGosto do fato de a documentação de linha de comando já começar mostrando casos de uso reais. Muitas ferramentas costumam abrir com explicações de opções obscuras e pouco usadas, e isso sempre me decepcionou
O GitHub não adotou o git-annex e aplicou ao LFS a abordagem NIH (Not Invented Here) ao estilo Microsoft
Eu também acho o git-annex mais elegante, mas ele é fraco em compatibilidade multiplataforma. Só para contexto, o LFS nasceu de uma colaboração entre GitHub e Bitbucket (ou melhor, não lembro exatamente qual forge era). Um lado forneceu a implementação, o outro o nome, e os dois se juntaram depois de se encontrarem em uma conferência de Git. O que mais me incomoda hoje são os limites aplicados pelo GitHub a projetos grandes. Além disso, a política de “você precisa trazer todos os objetos para o ambiente local antes de fazer push” faz com que comunidades de desenvolvimento maiores atinjam o limite muito rápido. Contexto: já contribuí para o git-lfs
(Sinceramente) a abordagem NIH do GitHub é pior em todos os aspectos. Houve uma apresentação de alguém que adorava o git-annex: Staying in Control of your Scientific Data with Git Annex by Yann Büchau
Ironicamente, no último fim de semana eu passei um dia inteiro criando meu próprio sistema de versionamento para arquivos grandes. É o quanto eu desgosto do git-annex. Ele transforma arquivos em blobs e incha o sistema de arquivos. Meu principal objetivo é sincronizar arquivos entre máquinas distribuídas, e não me importo com versionamento em si (aliás, nem entendo por que alguém precisaria de versionamento para arquivos grandes). Com IA e Python, dá para criar métodos auxiliares que fazem hash dos arquivos, montam uma tabela de consulta e sincronizam as fontes com rclone. Existem jeitos muito mais simples e eficientes de fazer isso
Usei por vários anos, e a maior vantagem para mim era a integração com provedores de armazenamento em nuvem e backups. Só que essa integração sempre foi instável e dependia de plugins de terceiros pouco mantidos. Em certo momento houve até um bug de inconsistência de dados, então acabei desistindo. Fico curioso se isso melhorou nos últimos 5 anos