git-annex

git-annex. Definitiv wert für zwei oder drei Blicke. Im Prinzip ist das sowas wie ein manuell betriebenes Dropbox – man kann Ordner mit anderen Ordnern verknüpfen und Sync-Beziehungen definieren. Aber man kann auch zum Beispiel Redundanzen definieren, wodurch sichergestellt ist, dass von Files genügend Kopien vorliegen – löscht man eine Datei, gibts was auf die Finger wenn es die letzte Kopie war (und sie wird wiederhergestellt). Viele Kommandos zur effizienten Verwaltung verschiedenster Szenarien kommen dazu und es gibt verschiedenste Backends für die Daten – z.B. kann man Amazon S3 integrieren und mit geeigneten Mitteln als Backup-Repository einbinden, oder URLs aus dem Web referenzieren und darüber Dateien jederzeit wieder rekonstruierbar machen (damit kann man z.B. auch einen eigenen Fileserver mit http Oberfläche integrieren). Oder sogar sowas wie Google Mail als Backend benutzen und seine Daten in Dateianhängen. Oder alle Mittel von git benutzen um z.B. temporäre Ergebnisse von Synchronisierungen auszuschließen. Im Gegensatz zu Sparkleshare – welches ja auch auf git aufbaut – werden hier aber nur die Metadaten in git versioniert, nicht die Dateien selber. Das hat natürlich den Nachteil, dass Dateiänderungen darüber nicht zurückgedreht werden können – dazu bräuchte man ein versionierendes Backend wie z.B. bup, welches dann als Datensicherung mit Versionierung und Definition der Backup-Zyklen benutzt wird. Der Vorteil der git-annex Methode ist aber, dass die Daten nicht so gigantisch wachsen wie bei Sparkleshare wenn man z.B. große Dateien wie Videos oder Digitalbilder syncen will – nur an der definierten Backup-Schnittstelle würdenm die Versionen anfallen und man kann explizit bestimmen welche Daten da hin gehen. Nix für Mäuseschubser, aber klasse für Kommandozeilenfetischisten.