git-annex – Tool zur Verwaltung großer Dateien für Git-Nutzer

• git-annex ist ein Tool, mit dem sich große Dateien verwalten lassen, ohne ihren Inhalt direkt in ein Git-Repository zu legen
• Es führt Synchronisierung, Backup und Archivierung in Offline- und Online-Umgebungen durch und gewährleistet Sicherheit durch Prüfsummen und Verschlüsselung
• Es wendet die verteilten Eigenschaften von Git auf große Dateien an und vereinfacht die Standortverfolgung und Übertragung zwischen mehreren Laufwerken, Servern und Clouds
• Es eignet sich für CLI-orientierte Nutzer, während der git-annex assistant für allgemeine Nutzer eine Bedienung im Stil der Ordnersynchronisierung bietet
• Mit einem einfachen Repository-Format für die Langzeitaufbewahrung und verschiedenen Special Remotes erweitert es Workflows für Archivierung und Datenmigration

---

Überblick

• git-annex ist ein Tool zur Verwaltung großer Dateien, bei dem der Dateiinhalt außerhalb von Git bleibt und nur Metadaten und Standortinformationen in Git verwaltet werden
  • Dadurch bleibt die Commit-Historie leichtgewichtig, während Speicherung und Verschiebung großer Binärdateien flexibel gehandhabt werden können
  • Prüfsummen und Unterstützung für Verschlüsselung gewährleisten Integrität und Vertraulichkeit
• Es ermöglicht Synchronisierung, Backup und Archivierung sowohl offline als auch online und bietet Funktionen zur Verwaltung der Anzahl von Kopien derselben Datei über verteilte Speicherorte hinweg sowie zur Protokollierung
• Es ist für Kommandozeilen-Nutzer optimiert, kann aber über den git-annex assistant auch von allgemeinen Nutzern einfach in Form einer Ordnersynchronisierung verwendet werden
• Für Einsteiger gibt es die walkthrough-Dokumentation, um Installation und grundlegende Abläufe schnell zu erlernen

Anwendungsfall: Archivist (archivorientierte Nutzer)

• Beim Betrieb mehrerer Offline-Archivlaufwerke lassen sich dennoch alle Dateien in einem einzigen Verzeichnisbaum so durchsuchen und neu organisieren, als wären sie eins
  • Selbst wenn sich der Dateiinhalt auf Offline-Laufwerken befindet, sind Umstrukturierung und Commit über Indizes und Pointer ohne tatsächliches Löschrisiko möglich
• Wenn eine bestimmte Datei benötigt wird, zeigt das Tool an, auf welchem Laufwerk sie vorhanden ist, und kann sie leicht verfügbar machen
  • Jedes Laufwerk teilt gegenseitig Standortinformationen, um den gesamten Archivstatus nachvollziehbar zu machen
• Durch ein einfaches Repository-Format bleibt die langfristige Zugänglichkeit der Dateien erhalten, auch wenn weder git-annex noch git verwendet werden
• Mit cron-Jobs können neue Dateien nachts automatisch archiviert werden; beabsichtigte und unbeabsichtigte Kopien werden protokolliert, um zu beurteilen, wann Replikation erforderlich ist

Anwendungsfall: Nomad (mobilitätsorientierte Nutzer)

• Heterogene Speicher wie Laptops, portable USB-Laufwerke/USB-Sticks, Remote-Server und verschlüsselter Cloud-Speicher lassen sich konsistent wie Git-Remotes verwalten
  • Unterwegs kann man auf dem Server eine Download-Warteschlange aufbauen und die eigentliche Übertragung später an Orten mit besserer Verbindung ausführen; unterstützt wird also ein verzögerter Transfer-Workflow
• Für battery-schonende Nutzung lassen sich Offline-freundliche Workflows einrichten, etwa kurzzeitig von USB kopieren und dann lokal weiterverwenden
• Nach der Nutzung kann festgelegt werden, was behalten oder gelöscht werden soll, um lokalen Speicher freizugeben; bei der nächsten Synchronisierung werden Änderungen mit dem Server synchronisiert
• Über Special Remotes und Transfer-Pipelines wird flexible Datenbewegung über unterschiedliche Storage-Backends und Netzwerksituationen hinweg ermöglicht

Kernfunktionen und Vorteile

• Sichere Langzeitaufbewahrung durch content-addressing und Prüfsummen zur Integritätssicherung sowie Unterstützung für verschlüsselte Speicherung
• Mit location tracking lassen sich Speicherort, Anzahl der Kopien und Verfügbarkeit jeder Datei klar nachvollziehen
• Das Modell der verteilten Versionsverwaltung wird auf große Dateien angewendet, wodurch die Abhängigkeit von zentralisiertem Storage sinkt und Offline-Resilienz erreicht wird
• Der assistant-Modus bietet ein Ordnersynchronisierungs-Erlebnis, sodass auch CLI-Ungeübte eine Bedienbarkeit auf Drag-and-Drop-Niveau erhalten

Zusammenfassung der Vorteile

• git-annex verwaltet nur Dateireferenzen in git und eignet sich daher gut für den unkomplizierten Umgang mit großen Dateien
• Durch die verteilte Struktur sind freies Verschieben, Speichern, Synchronisieren/Backup und Versionsverwaltung von Dateien über mehrere Geräte und Orte hinweg möglich
• Es bietet besonders starke Integration und Skalierbarkeit für Offline- und Langzeitaufbewahrungsszenarien sowie für dynamisches Datenmanagement über mehrere Geräte und Clouds hinweg
• Es eignet sich auch für Nutzer mit einer Mischung aus archiv- und mobilitätsorientierten Anforderungen und ist dank Verwaltung von Kopierichtlinien und diversifizierten Backends sowohl für Organisationen als auch für Einzelpersonen nützlich
• Es erweitert die Verteiltheit und Portabilität von Git auf große Datenmengen und reduziert so Betriebsrisiken und manuellen Aufwand bei Langzeitaufbewahrung und Datentransfers

[GN⁺]

Hacker-News-Kommentare

• Ich verwende git-annex, um die Daten auf all meinen Laufwerken zu verwalten. Es verfolgt automatisch, auf welchem Laufwerk sich welche Datei befindet, hält ausreichend viele Kopien vor und prüft die Prüfsummen aller Dateien. Auch mit offline befindlichen Laufwerken funktioniert es problemlos. git-annex kann anfangs etwas schwer zu verstehen sein, deshalb empfehle ich, ein Test-Repository anzulegen, das Walkthrough nachzuvollziehen und es praktisch auszuprobieren. Auch die verschiedenen Workflows sind sehenswert

  • Wie viele Daten verwaltest du damit ungefähr? Ich nutze git-annex für etwa 100.000 bis 1.000.000 Dateien und mehrere TB an Fotodaten auf ZFS. Anfangs gab es keinerlei Probleme, aber in letzter Zeit wird es zunehmend langsamer, sodass einzelne Befehle 5 bis 30 Minuten brauchen. Ich bin unsicher, ob das an ZFS, an git-annex oder an den Festplatten liegt

  • Ich habe schon lange darüber nachgedacht, meine Daten mit git-annex zu verwalten, bin aber auf Reibung beim vollständigen Löschen von Dateien und auf einige andere Probleme gestoßen. Falls du Zeit hast, würde mich interessieren, ob du teilen könntest, wie du es verwendest

• Es steht nicht auf der Seite, aber git-annex wurde von Joey Hess entwickelt. Er hat auch moreutils und etckeeper entwickelt

  • Persönlich finde ich noch bemerkenswerter, dass er seit 1996 über Jahrzehnte hinweg ein zentraler Debian-Contributor war. Ein großer Teil dessen, was wir heute unter Linux verstehen, ist durch seine Hände gegangen

• Eine Diskussion über die neue native Verwaltung großer Objekte in Git gab es vor Kurzem hier

  • Der Vollständigkeit halber: Warum ich die Diskussion für weitgehend nicht einschlägig halte, habe ich auch in diesem Kommentar erklärt. annex ist tatsächlich ein etwas anderes Feld als das Problem „große Dateien in git“. git-annex versteht man leichter, wenn man es eher so betrachtet, dass das „serverseitige“ Speicherproblem von LFS und Ähnlichem auf native Git-Weise dezentral verteilt wird

• Das Enttäuschende an git-annex ist Haskell. Ich habe nichts gegen die Sprache selbst, aber ich war wirklich überrascht, wie viele Abhängigkeiten dafür installiert werden müssen. Ein großer Teil davon wird sonst nirgendwo gebraucht, und Versionskonflikte mit verschiedenen Anwendungen treten leicht auf. Besonders mühsam ist es bei Installation über den System-Paketmanager. Wenn man nur annex und pandoc installiert, kommen trotzdem täglich Dutzende Haskell-Paketupdates herein. Wenn man eine Distribution verwendet, die aus dem Quellcode baut, ist das ein Albtraum. Eigentlich denke ich, dass man das meiste bedenkenlos statisch linken könnte. Trotzdem heißt es im Haskell-Umfeld, das sei das Ergebnis feingranularer Bibliotheksmodularisierung. Aber bei der Systemverwaltung gibt es eben auch andere Prioritäten, und bei Rust, Go, Zig, C oder C++ habe ich solche Probleme nie erlebt. Das ist nicht feindselig gegenüber dem Haskell-Ökosystem oder seinen Nutzern gemeint, ich möchte es selbst noch lernen. Ich frage mich nur, warum dieses Problem existiert und was die Lösung wäre

  • Statisches Linken wird im Haskell-Tooling bereits unterstützt. Ich betreue den Haskell-Stack für Solus, und pandoc hängt dort nur von libc ab; alle Haskell-Pakete werden statisch in das Binary eingebunden und genauso wie bei Rust ausgeliefert. Es ist also absolut machbar. Unter Solus lösen wir das wegen der vielen Abhängigkeiten einfach per statischem Linken. Für mich ist das eher eine Entscheidung der Paketbetreuer

  • Zu „das meiste könnte man bedenkenlos statisch linken“: Ist das bei einem Distributions-Repo nicht letztlich eher eine Frage der Paketmanager-Richtlinien?

  • Selbst als Vollzeit-Haskell-Entwickler habe ich eine ähnliche Abneigung gegen nicht statisch gelinkte Haskell-Pakete. Im AUR gibt es bereits statisch gelinkte Versionen, also unmöglich ist es nicht. Warum Paketierer unbedingt auf dynamischem Linken bestehen, habe ich selbst nie tiefer untersucht. Dynamisches Linken kann für die interne Softwareverteilung sinnvoll sein, aber vermutlich wird das unnötig auf Distributionen übertragen

  • Welchen Paketmanager verwendest du? Auf apt-basierten Systemen hatte ich wegen Haskell noch nie Probleme

  • Jedes Mal, wenn ich pacman -Syu ausführe, ist die Hälfte der Updates Haskell-Kram, und das nervt. Wahrscheinlich sind pandoc oder shellcheck der Grund

• git-annex ist wirklich eine coole Technik. Mein Eindruck ist aber, dass es am besten für Repositories eines einzelnen Nutzers funktioniert. Also etwa, wenn eine Person ihre privaten Daten wie Dateien, Dokumente oder Musik über verschiedene Geräte hinweg verwalten will. Ich habe es auch zur Synchronisierung in kollaborativen Repositories mit großen Dateien ausprobiert, aber dieses „Magic“-Branch-Modell skaliert nicht gut

  • Das mag unterschiedlich sein, aber bei unserer Institution funktioniert es im Gegenteil sehr gut. Wir sind eine Institution für digitale Archivierung und verwenden git-annex seit über zehn Jahren als Backend für interne Repositories. Wir haben zwar nur 15 bis 20 Mitarbeitende, verwalten aber problemlos über 30 TB Daten und 750.000 Dateien (Binärdaten plus Metadaten) in Hunderten von Repositories

• Ich nutze ein selbst gehostetes Forgejo. Bisher habe ich noch keinen Bereich gefunden, in dem git-annex besser als LFS wäre, und das Setup scheint auch nicht gerade einfach zu sein. Dass git-annex in Haskell geschrieben ist, gefällt mir ebenfalls nicht, und ich habe Aussagen gefunden, es sei ungefähr 50 % langsamer (allerdings nur aus einer Quelle, also weiß ich nicht, wie belastbar das ist). Die Kommandos haben sicher einen Grund, aber die Bequemlichkeit von LFS, bei dem man fast alles über .gitattributes versteht, fehlt mir. Bei git-annex habe ich auch nichts gefunden, das sich so transparent anfühlt wie .gitattributes. Und wenn es kein Tutorial gibt, das mir das Äquivalent zu git lfs ls-files zeigt, werde ich vermutlich kaum Interesse entwickeln. Ich prüfe Dinge gern mit git status und git lfs ls-files

  • Dass es langsamer ist, liegt nicht an Haskell. git-annex ist ein verteiltes Backup-Werkzeug; die Langsamkeit kommt von seinem starken Fokus auf I/O und Datenerhalt. Wenn man zum Beispiel den Befehl drop verwendet, muss in Echtzeit auf allen Remotes überprüft werden, ob der Inhalt dort tatsächlich vorhanden ist, und das kostet Zeit. Mit Optionen wie --fast, bei denen nur lokalen Metadaten vertraut und die Verifikation übersprungen wird, geht es deutlich schneller, aber das ist etwas riskanter

  • LFS und git-annex sind für leicht unterschiedliche Einsatzzwecke gedacht. LFS eignet sich für Entwicklungs-Repositories, in denen große Dateien mit Git gemischt werden, etwa in der Spieleentwicklung. git-annex passt besser, wenn man wichtige Daten sichern will und große Dateisammlungen wie einen Musikordner an mehreren Orten aufbewahrt. Ich verwende es in letzterer Form

  • Es gibt einen Forgejo-Soft-Fork mit Unterstützung für git-annex: forgejo-aneksajo

  • Das größte Repository, das ich mit git-annex verwalte, umfasst mehrere TB, verteilt über verschiedene Systeme, und viele Dateien sind größer als 10 GB. Wenn der Autor nach einem Äquivalent zu git-lfs-ls-files sucht, dann erfüllt git annex list --in here bei git-annex wahrscheinlich eine ähnliche Rolle

• Ich mag daran, dass die Kommandozeilen-Dokumentation gleich zu Beginn reale Anwendungsfälle zeigt. Viele Tools fangen stattdessen mit rätselhaften Optionen an, die in der Praxis kaum jemand nutzt, und das fand ich immer schade

• GitHub hat bei LFS auf den Microsoft-Stil von NIH (Not Invented Here) gesetzt und git-annex nicht übernommen

  • Ich finde git-annex auch eleganter, aber die plattformübergreifende Kompatibilität ist schwächer. Soweit ich weiß, entstand LFS aus einer Zusammenarbeit zwischen GitHub und Bitbucket (genauer erinnere ich mich nicht mehr, welche Forge es war). Die eine Seite lieferte die Implementierung, die andere den Namen, und nach einem Treffen auf einer Git-Konferenz wurde das zusammengeführt. Was mich heute am meisten stört, sind die Grenzwerte, die GitHub für große Projekte setzt. Hinzu kommt die Richtlinie „du musst alle Objekte lokal holen, bevor du pushen darfst“, wodurch größere Entwickler-Communities sehr schnell an diese Limits stoßen. Zur Einordnung: Ich habe zu git-lfs beigetragen

  • Ehrlich gesagt ist GitHubs NIH-Ansatz in jeder Hinsicht nachteilig. Es gibt einen Vortragenden, der git-annex sehr mochte: Staying in Control of your Scientific Data with Git Annex by Yann Büchau

• Ironischerweise habe ich letztes Wochenende innerhalb eines Tages mein eigenes Versionierungssystem für große Dateien gebaut. So sehr mag ich git-annex nicht. Es verwandelt Dateien in Blobs und bläht das Dateisystem auf. Mein Hauptziel ist die Synchronisierung verteilter Dateien, an Versionierung selbst habe ich kein Interesse (ich verstehe ohnehin nicht, warum man bei großen Dateien überhaupt Versionierung braucht). Mit KI und Python kann man Dateien hashen, eine Lookup-Tabelle bauen und Hilfsmethoden schreiben, die die Quelle mit rclone synchronisieren. Es gibt viel einfachere und effizientere Wege

• Ich habe es über Jahre benutzt, und der größte Vorteil war für mich die Anbindung an Cloud-Storage-Provider und Backups. Allerdings war diese Integrationsfunktion immer instabil und von schlecht gepflegten Drittanbieter-Plugins abhängig. Es gab zeitweise sogar einen Bug mit Dateninkonsistenzen, und schließlich habe ich aufgegeben. Mich würde interessieren, ob sich in den letzten fünf Jahren etwas verbessert hat

  • Ich denke, das hängt davon ab, welche Art von Cloud-Storage-Provider man meint. Anbieter mit Unterstützung für offizielle Standardprotokolle wie S3, WebDAV oder SFTP sind im Vorteil. In letzter Zeit ist außerdem ein auf rclone basierendes special remote direkt in git-annex integriert worden. Das wird besser gepflegt als frühere Drittanbieter-Remotes und kann mit fast allen Cloud-Remotes arbeiten, die rclone unterstützt