git-annex - Herramienta para gestionar archivos grandes para usuarios de Git
(git-annex.branchable.com)- git-annex es una herramienta que permite gestionar archivos grandes sin poner directamente su contenido dentro del repositorio Git
- Realiza sincronización, respaldo y archivado tanto en entornos offline como online, y garantiza la seguridad con checksums y cifrado
- Aplica la naturaleza distribuida de Git a archivos grandes para simplificar el seguimiento de ubicaciones y la transferencia entre múltiples unidades, servidores y nubes
- Es adecuada para usuarios centrados en la CLI, y para usuarios generales git-annex assistant ofrece una experiencia de uso tipo sincronización de carpetas
- Es una herramienta que amplía los flujos de trabajo de archivado y traslado mediante un formato de repositorio simple para preservación a largo plazo y varios special remotes
Descripción general
- git-annex es una herramienta de gestión de archivos grandes que mantiene el contenido de los archivos fuera de Git y administra con Git solo los metadatos y la información de ubicación
- Como resultado, el historial de commits se mantiene ligero mientras el almacenamiento y traslado de binarios grandes se maneja con flexibilidad
- Garantiza integridad y confidencialidad con checksums y soporte de cifrado
- Realiza sincronización, respaldo y archivado tanto offline como online, y ofrece funciones para gestionar la cantidad de copias de un mismo archivo entre almacenes distribuidos y registrar logs
- Aunque está optimizada para usuarios de línea de comandos, también puede usarse fácilmente por usuarios generales en forma de sincronización de carpetas mediante git-annex assistant
- Ofrece la documentación walkthrough para quienes lo usan por primera vez, permitiendo aprender rápidamente la instalación y el flujo básico
Caso de uso: Archivist (usuario orientado al archivado)
- Incluso operando varias unidades de archivo offline, es posible explorar y reorganizar todos los archivos como si fueran uno solo dentro de un árbol de directorios único
- Aunque el contenido de los archivos esté en unidades offline, gracias al índice y los punteros se pueden reubicar y hacer commits sin riesgo de borrado real
- Cuando se necesita un archivo específico, indica en qué unidad existe y permite ponerlo disponible fácilmente
- Cada unidad comparte información mutua de ubicación para entender el estado general del archivo archivado
- Usa un formato de repositorio simple, por lo que incluso sin usar git-annex ni git, la accesibilidad a los archivos se mantiene a largo plazo
- Con trabajos de cron, puede archivar automáticamente nuevos archivos durante la noche y registrar copias intencionales o no intencionales para ayudar a decidir cuándo hace falta replicar
Caso de uso: Nomad (usuario orientado a la movilidad)
- Permite gestionar de forma consistente almacenes heterogéneos como laptops, unidades USB/memorias USB, servidores remotos y almacenamiento cifrado en la nube como si fueran remotos de Git
- Durante los desplazamientos, permite acumular una cola de descargas en el servidor y realizar la transferencia real en lugares con mejor conectividad mediante un flujo de transferencia diferida
- También es posible construir flujos de trabajo amigables con el uso offline, como copiar momentáneamente desde USB y consumir localmente, por ejemplo para ahorrar batería
- Tras terminar de usar archivos, se puede indicar qué mantener o borrar para recuperar espacio local, y en la siguiente sincronización sincronizar los cambios con el servidor
- Mediante special remotes y pipelines de transferencia, permite mover datos con flexibilidad en diversos backends de almacenamiento y condiciones de red
Funciones clave y beneficios
- Implementa preservación segura a largo plazo mediante garantía de integridad basada en direccionamiento por contenido y checksums, además de soporte para almacenamiento cifrado
- Con location tracking, permite identificar claramente la ubicación de almacenamiento, cantidad de copias y disponibilidad de cada archivo
- Aplica el modelo de control de versiones distribuido a archivos grandes para reducir la dependencia de almacenamiento centralizado y ganar resistencia offline
- Con el modo assistant, ofrece una experiencia de sincronización de carpetas, permitiendo incluso a quienes no dominan la CLI una usabilidad de nivel arrastrar y soltar
Resumen de ventajas
- git-annex es ideal para manejar archivos grandes sin carga, ya que solo administra con git las referencias de archivos
- Gracias a su estructura distribuida, permite mover, almacenar, sincronizar, respaldar y versionar archivos libremente entre múltiples dispositivos y ubicaciones
- Destaca especialmente por su integración y escalabilidad en escenarios offline y de preservación a largo plazo, o en gestión de datos fluida entre múltiples dispositivos y nubes
- También es adecuado para usuarios híbridos entre archivado y movilidad, y resulta útil tanto para organizaciones como para individuos gracias a la gestión de políticas de copias y la diversificación de backends
- Es una herramienta que extiende la naturaleza distribuida y la portabilidad de Git a datos de gran tamaño, reduciendo el riesgo operativo y el esfuerzo en tareas de preservación y traslado a largo plazo
1 comentarios
Comentarios en Hacker News
Yo uso git-annex para gestionar los datos de todos mis discos. Lleva automáticamente el seguimiento de en qué disco está cada archivo, mantiene suficientes copias y verifica checksums para todos los archivos. También funciona bien con discos desconectados. git-annex puede sentirse un poco difícil de entender al principio, así que recomiendo crear un repositorio temporal, seguir el walkthrough y practicar. También vale la pena revisar varios workflows
Me da curiosidad saber cuántos datos conservas. Yo gestiono entre unas 100 mil y 1 millón de archivos, con varios TB de fotos en ZFS usando git-annex. Al principio no había ningún problema, pero últimamente se ha ido poniendo cada vez más lento, hasta el punto de que cada comando tarda entre 5 y 30 minutos. No sé si es por ZFS, por git-annex o por el disco
Desde hace tiempo he pensado en gestionar datos con git-annex, pero me encontré con cierta fricción para eliminar archivos por completo y con algunos otros problemas. Si tienes tiempo, me gustaría saber si podrías compartir cómo lo usas
No aparece en la página, pero git-annex fue creado por Joey Hess. También desarrolló moreutils y etckeeper
Hace poco hubo una discusión aquí sobre la nueva funcionalidad nativa de Git para manejar objetos grandes
Lo decepcionante de git-annex es Haskell. No es que odie el lenguaje en sí, pero me sorprendió muchísimo la cantidad de dependencias que hay que instalar. Muchas de ellas no se necesitan en ningún otro lado y además suelen provocar conflictos de versiones entre distintas aplicaciones. Es especialmente pesado instalarlo con el gestor de paquetes del sistema. Con solo instalar annex y pandoc, sigo recibiendo decenas de actualizaciones diarias de paquetes de Haskell. Si usas una distribución que compila desde el código fuente, es una pesadilla. La verdad, creo que en la mayoría de los casos sería seguro enlazar todo estáticamente. Aun así, dentro del mundo Haskell dicen que esto es resultado de la modularización minuciosa de bibliotecas. Pero en administración de sistemas y otras prioridades, nunca he visto este problema en Rust, Go, Zig, C o C++. No es hostilidad hacia el ecosistema o los usuarios de Haskell, de hecho quiero aprenderlo. Pero me pregunto por qué existe este problema y cuál sería la solución
Las herramientas de Haskell ya soportan enlazado estático. Yo mantengo la pila de Haskell para Solus, y pandoc solo depende de libc; todos los paquetes de Haskell van incluidos estáticamente en el binario y se distribuyen igual que en Rust. O sea, sí se puede hacer sin problema. En Solus lo resolvemos así precisamente porque hay demasiadas dependencias. Me parece más bien una decisión del mantenedor de la distribución
Sobre la parte de “en la mayoría de los casos sería seguro enlazar todo estáticamente”, me pregunto si al final no será un tema de política del gestor de paquetes si estamos hablando de un repo de distribución
Incluso como desarrollador de Haskell de tiempo completo, me genera un rechazo parecido cualquier paquete de Haskell que no venga enlazado estáticamente. En AUR ya existen versiones enlazadas estáticamente, así que al menos imposible no es. Tampoco me he puesto a investigar por qué los empaquetadores insisten tanto en el enlazado dinámico. En general puede tener sentido para distribución interna de software, pero quizá están trasladando eso innecesariamente a las distribuciones
Me da curiosidad qué gestor de paquetes usas. En sistemas basados en apt nunca he tenido problemas por culpa de Haskell
Cada vez que corro
pacman -Syu, la mitad de las actualizaciones son paquetes de Haskell y ya me tiene harto. Supongo que la causa es pandoc o shellcheckgit-annex es una tecnología realmente genial. Pero mi impresión es que funciona mejor en repositorios de un solo usuario. Por ejemplo, cuando una persona gestiona sus propios archivos, documentos, música y otros datos personales entre distintos dispositivos. Lo he usado para sincronización en repositorios colaborativos con archivos grandes, pero el enfoque de ramas “magic” no escala bien
Yo uso forgejo self-hosted. Todavía no encuentro en qué supera git-annex a LFS, y tampoco parece fácil de configurar. Tampoco me gusta que git-annex esté escrito en Haskell, y encontré comentarios de que es como 50% más lento, aunque solo vi una fuente, así que no sé si sea información confiable. Supongo que hay razones para que los comandos sean complejos, pero no tiene la comodidad de LFS, donde con tocar
.gitattributesprácticamente entiendes todo. Tampoco sentí que git-annex tenga una transparencia equivalente a.gitattributes. Y si ni siquiera hay un tutorial que muestre el comando equivalente a 'git lfs ls-files', probablemente no me va a interesar mucho. Yo tengo la costumbre de revisar con 'git status' y 'git lfs ls-files'Que sea lento no tiene que ver con Haskell. git-annex es una herramienta de backup distribuido, así que su lentitud viene de operaciones muy enfocadas en I/O y en la preservación de datos. Por ejemplo, si usas el comando drop, tiene que comprobar en tiempo real que ese contenido exista en todos los remotes correspondientes, y por eso tarda. Con la opción --fast y similares, si confías solo en metadatos locales y te saltas la verificación, va mucho más rápido, aunque es un poco más riesgoso
LFS y git-annex sirven para casos un poco distintos. LFS va mejor cuando tienes un repositorio git de desarrollo con archivos grandes mezclados, por ejemplo en desarrollo de videojuegos. git-annex encaja mejor cuando quieres respaldar datos importantes y guardar grandes colecciones de archivos en varios lugares, como una carpeta de música. Yo lo uso de esta segunda manera
Hay un soft-fork de Forgejo con soporte para git-annex: forgejo-aneksajo
El repositorio más grande que gestiono con git-annex tiene varios TB repartidos en varios sistemas, y muchos archivos superan los 10 GB. Si lo que el autor busca es algo como git-lfs-ls-files, probablemente en git-annex el equivalente sea
git annex list --in hereMe encanta que la documentación de la línea de comandos ponga casos de uso reales hasta arriba. Muchas herramientas suelen arrancar con explicaciones de opciones crípticas que casi nadie usa, y eso siempre me ha parecido una lástima
GitHub no adoptó git-annex y en su lugar aplicó a LFS el clásico NIH (Not Invented Here) a lo Microsoft
Yo también creo que git-annex es más elegante, pero la compatibilidad multiplataforma es más débil. Como referencia, LFS salió de una colaboración entre GitHub y Bitbucket (o mejor dicho, entre algún forge, no recuerdo exactamente cuál). Un lado aportó la implementación y el otro el nombre, y lo unieron después de conocerse en una conferencia de Git. Lo que más me decepciona hoy son los límites que GitHub aplica a proyectos grandes. Además, su política de “tienes que traer todos los objetos a local para poder hacer push” hace que las comunidades de desarrollo medianamente grandes choquen muy rápido con esos límites. Referencia: contribuí a git-lfs
(Honestamente) el enfoque NIH de GitHub sale perdiendo en todos los frentes. Hay una charla de alguien que ama git-annex: Staying in Control of your Scientific Data with Git Annex by Yann Büchau
Irónicamente, el fin de semana pasado pasé un día entero construyendo mi propio sistema de versionado de archivos grandes. Así de poco me gusta git-annex. Convierte los archivos en blobs y hace crecer de más el sistema de archivos. Mi objetivo principal es sincronizar archivos distribuidos; el versionado en sí no me interesa en absoluto, de hecho no entiendo por qué querrías versionado para archivos grandes. Con IA y Python se puede hacer hash de los archivos, construir una tabla de búsqueda y crear métodos auxiliares para sincronizar las fuentes con rclone. Hay formas mucho más simples y eficientes de hacerlo
Lo usé durante varios años, y su mayor ventaja para mí era la integración con proveedores de almacenamiento en la nube y con backups. Pero esa integración siempre fue inestable y dependía de plugins de terceros poco mantenidos. Incluso hubo una vez un bug de inconsistencia de datos, así que al final lo dejé. Me pregunto si en los últimos cinco años ha mejorado en algo