Datenverwaltung mit Git-Annex

Dmitri Stalnuhhin, 123RF

Git wird groß

Git-Annex ist eine überaus nützliche Erweiterung von Git. In puncto Synchronisation und Datenverwaltung wartet es mit innovativen Konzepten auf. Datei-Inhalte brauchen nicht mehr auf jedem System vorhanden zu sein, Git-Annex holt sie bei Bedarf von anderen Repositories.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Git-Annex [1] erscheint auf den ersten Blick paradox. Es verwaltet Dateien in einem Git-Repository, ohne die Datei-Inhalte selbst ins Repository einzuspielen. Dennoch ist es möglich, neue Dateien und Änderungen an Dateien zu verfolgen und im Git-Stil zu pflegen. Da sich die Inhalte nie direkt im Repository befinden, bleiben Probleme mit großen Dateien dort aus. Joey Hess, der Entwickler von Git-Annex, führt zwei typische Anwendungsfälle an:

1. Der Archivar besitzt verschiedene Offline-Geräte, über die er seine Daten verteilt. Am Client-System verwaltet er seine Dateien mit Git-Annex, ohne dass dort alle Daten vorliegen. Git-Annex protokolliert, an welchem Ort sich welche Daten befinden und der Archivar holt sie nötigenfalls auf sein Client-System.

2. Der Nomade ist viel unterwegs und wählt als Daten-Repositories einen Online-Server und einen USB-Stick. Bei Bedarf lädt er Daten vom Server auf den USB-Stick herunter oder synchronisiert sie direkt aufs Client-System, je nachdem wo Speicherplatz verfügbar ist. Benötigt der besagte Nomade Daten nicht mehr, "droppt" er sie, auf dem Online-Server bleibt aber alles vorhanden.

Die Beispiele vom Archivar und vom Nomaden vermitteln einen ersten Eindruck, was Git-Annex ermöglicht. Offline-Archive und Synchronisation bilden jedoch nur einen kleinen Teil der möglichen Einsatzzwecke. Komplexere Setups zwischen mehreren Systemen, Servern oder Festplatten sind ebenfalls machbar.

Der Git-Annex-Entwickler beschreibt auch, was Git-Annex nicht ist: Ohne den Einsatz zusätzlicher Tools ist es kein Backup-System, auch wenn es eine Rolle in einem effizienten Archivierungs- oder Sicherheitssystem spielen kann.

Installation

Die Git-Annex-Installation bringt keine Schwierigkeiten mit sich. Die gängigsten Distributionen wie Debian, Ubuntu und Fedora stellen fertige Pakete zur Verfügung. Diese hinken der aktuellen Entwicklungsversion allerdings häufig hinterher. Debian und Ubuntu 13.04 stellen über ihre Repositories Git-Annex in Version 3.2 bereit, die aktuelle Version 4.2 ist erst seit Ubuntu-Version 13.10 an Bord.

Wer distributionsunabhängig die jeweils aktuelle Version verwenden möchte, findet für Linux ein vorkompiliertes Tar-Archiv unter [2]. Für die Installation reicht es, den entpackten Ordner »git-annex-linux« zum Pfad hinzuzufügen. Listing 1 führt alle erforderlichen Schritte für die Installation von Git-Annex auf. Für eine endgültige Installation pflegt man diese permanent ein, etwa über einen PATH-Eintrag in der Bash-Konfiguration.

Listing 1

Installation der Linux-Binaries

01 $ wget 'http://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz'
02 $ tar xzf git-annex-standalone-amd64.tar.gz
03 $ PATH="$PATH:$HOME/git-annex.linux"
04 $ git-annex version
05 git-annex version: 4.20131003-gbe0b734
06 build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP Feeds Quvi TDFA
07 key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
08 remote types: git gcrypt S3 bup directory rsync web webdav glacier hook

Interne Struktur

Git-Annex verwaltet Datei-Bäume, ohne dabei die Datei-Inhalte selbst ins Repository einzuspeisen. Ein Key-Value-Verfahren unter Zuhilfenahme symbolischer Links realisiert die Trennung von Dateinamen und -inhalten. Wird eine Datei zum Repository hinzugefügt, erstellt eine Hash-Funktion einen Key aus Datei-Inhalt und Metadaten. Der Dateiname zeigt dann über einen symbolischen Link auf diesen Key.

Der Datei-Inhalt – genannt Value – wird der Datei von nun an über den Key zugeordnet. Die Form der Key-Value-Dateiverwaltung per symbolischem Link im sogenannten indirekten Modus demonstriert Listing 2. Bevor die Datei-Inhalte synchronisiert wurden, zeigt der Link ins Leere. Die Datei- und Ordnerstruktur ist dennoch vorhanden und veränderbar – das heißt, Dateinamen werden unabhängig von ihrem Inhalt verändert.

Listing 2

Git-Annex im indirekten Modus

01 $ ls -l
02 total 8
03 lrwxrwxrwx 1 gschoenb gschoenb 198 Oct  9 12:30 debhelper-slides.pdf -> .git/annex/objects/32/64/SHA256E-[...].pdf

Einen Nachteil bringt dieses Vorgehen im indirekten Modus mit sich: Datei-Inhalte lassen sich nicht direkt bearbeiten. Zum Öffnen und Bearbeiten einer Datei wird das Kommando »git-annex unlock« verwendet. Es löst den symbolischen Link auf und stellt die Datei direkt zur Verfügung. Der darauf folgende Befehl »git commit« konvertiert sie automatisch wieder in einen Git-Annex-Link. Auf den ersten Blick wirkt diese Prozedur umständlich, sie schützt aber vor dem irrtümlichen Löschen einer Datei.

Der direkte Modus bietet zwar die komfortable Möglichkeit, Dateien direkt zu bearbeiten, aber die Git-Annex-Sicherheitsfunktionen fallen dann weg. Deshalb starten Git-Annex-Repositories normalerweise im indirekten Modus. Ausnahmen bilden Repositories unter Windows, auf allen FAT-Dateisystemen und jene, die über die Weboberfläche mit dem Git-Annex-Assistant erzeugt werden (Abbildung 2). Außerdem schaltet man mit den Kommandos »git-annex indirect« und »git-annex direct« manuell vom einen Modus in den anderen.

Abbildung 2: Die Konfiguration eines Repository auf einer USB-Festplatte mit dem Git-Annex-Assistant.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Support-Ende von SMBv1

Mit dem aktuellen Update für Windows 10 und Windows Server 2016 steht eine Änderung ins Haus, die gerade für Benutzer älterer Linux-Distributionen große Auswirkungen hat. Nachdem Microsoft es über viele Jahre schon angekündigt hat, entfernt der Konzern mit dem aktuellen Update-Release den Support für das SMB-Protokoll 1. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Linux-Backup

Welche Backup-Lösung setzen Sie für Linux im professionellen Umfeld ein?

  • keine
  • eigene Scripts
  • rsnapshot
  • rdiff-backup
  • Bacula
  • Bareos
  • Borg
  • Duplicity
  • Amanda
  • Burp
  • Clonezilla
  • Acronis
  • Arkeia
  • SEP sesam
  • Veeam
  • Redo Backup
  • Relax-and-Recover
  • andere kommerzielle Software
  • andere Open-Source-Software

Google+

Ausgabe /2017

Microsite