Git als lokale BackUp-Lösung



  • Nach vielen Jahren rumgefrickel mit vielen verschiedenen Backup-Tools und noch mehr selbstgeschriebenen Shell-Skripten möchte ich nun endlich meine Projekte und privaten Daten zentral Archivieren.
    Konkret habe ich einen Verzeichnisbaum, in denen alle meinen personenbezogenen Daten gespeichert sind. Dieser sieht bspw. so aus:

    \
     \ dokumente
      \ kontoauszüge
        \ datei1
        \ datei2
      \ briefe
        \ datei1
        \ datei2
      \ ...
     \ projekte
      \ projekt1
       \ datei1
       \ datei2
      \ projekt2
       \ datei1
       \ datei2
      \ ...
    

    Dieser Baum existiert nur auf meinem Rechner und muss nicht zu anderen Maschinen repliziert werden.
    Ich möchte nun in regelmäßigen Abständen (10 Tage) komplette, inkrementelle Backups machen, welche ich dann entsprechend verschlüsselt auf meinen öffentlichen Webspace schiebe. Das generieren der Backups soll möglichst einfach sein und wenig Zeit in Anspruch nehmen.
    Ich dachte nun an git, wobei ich die einzelnen, übergeordneten Ordner (dokumente, projekt1, projekt2 etc.) als Submodule [1] eines Masterrepositories in der Verzeichniswurzel anlege.
    Ist dieses vorgehen sinnvoll? Die Versionierung, die ich auf diesem Wege bekommen würde, ist sicher nett, aber nicht zwingend notwenig. Mir geht es in erster Linie nur um wirklich komplette, verlässliche Backups ohne großartige Frickelei.

    Danke!

    [1] http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html



  • Gitter schrieb:

    Ich möchte nun in regelmäßigen Abständen (10 Tage) komplette, inkrementelle Backups machen, welche ich dann entsprechend verschlüsselt auf meinen öffentlichen Webspace schiebe. Das generieren der Backups soll möglichst einfach sein und wenig Zeit in Anspruch nehmen.

    Ich rate zu rdiff-backup. Dieses Programm benutze ich seit über einem Jahr für verschiedene Backups und hatte bisher keinen Grund zur Klage (solange du keine NTFS-Partition als Zielvolume verwendest).
    Das Programm kannst du auch sehr gut als cronjob einrichten. Ein gutes Backup sollte schließlich automatisch laufen, ohne dass du manuell daran denken musst.

    rdiff-backup ist (bis auf wenige Ausnahmen) effizient und legt umgedrehte inkrementelle Backups an: Das jeweils aktuelle Backup ist komplett nicht-inkrementell vorhanden. Die weiter zurückliegenden Versionen liegen dagegen inkrementell (und komprimiert) vor. Den Backup-Ordner könntest du dann verschlüsseln und hochladen.

    Backup, Verschlüsseln und Hochladen in einem Rutsch macht duplicity. Ich kann zur aktuellen Version nichts sagen, aber als ich das vor 1-2 Jahren ausprobiert habe, war es unerträglich lahm verglichen mit rdiff-backup.

    edit: Achso, von git würde ich ganz stark abraten, und zwar aus einem einzigen Grund: Alte Versionen kannst du nie wieder löschen.
    Wenn du irgendwann mal eine 1GB-Datei in einem git-Repository hattest, bauen *alle* folgenden commits darauf auf. Ohne die komplette history neu zu schreiben ist es unmöglich, diese 1GB verschenkten Speicherplatz jemals wieder loszuwerden, egal wie viele Jahre das zurück liegt.
    "Richtige" inkrementelle Backupsysteme bieten dir immer die Möglichkeit, Versionen zu löschen, die älter sind als ein gegebener Zeitpunkt.



  • Christoph schrieb:

    Backup, Verschlüsseln und Hochladen in einem Rutsch macht duplicity. Ich kann zur aktuellen Version nichts sagen, aber als ich das vor 1-2 Jahren ausprobiert habe, war es unerträglich lahm verglichen mit rdiff-backup.

    OK, es scheint leider immer noch genauso langsam zu sein, aus diesem Grund: http://www.nongnu.org/duplicity/new_format.html
    duplicity benutzt tar als Archiv-Format, was für solche Zwecke unglaublich ineffizient ist. tar ist nicht indiziert, d.h. wenn duplicity irgendeine Datei im Archiv sucht, weiß es zwar (recht schnell durch Meta-Informationen, zumindest ich hoffe ich das), in welcher tar-Datei die liegt, aber es muss dann diese gesamte tar-Datei von vorne bis hinten durchscannen, um die gewünschte Datei zu finden.
    Das ist vielleicht OK, wenn man nur wenige Datein im Backup hat, aber bei etwas größeren Dateianzahlen macht das keinen Spaß mehr.
    Zumindest war duplicity bei mir damals unbrauchbar langsam, als ich ein paar 10000 Dateien backuppen wollte.



  • Hallo Christoph,

    vielen Dank für Deine ausführliche Antwort.
    rdiff-backup sieht in der Tat sehr gut aus. Was mich aber abschreckt ist die Tatsache, dass ich Dateien, welche nicht mitgesichert werden sollen, jedes Mal über die Komandozeile o.ä. spezifieren muss. Dies ist bei mir nicht mehr so einfach möglich, da ich ja wirklich alle meine privaten Daten und Projekte auf einmal sichern möchte, und entsprechend es viele verschiedenen Pattern zum Ausschluss gibt. Bspw. möchte ich die Unterordner build in meinen Projekt-Ordnern nicht archvieren, in meinen Briefe-Ordnern schon. Bei GIT hätte ich diese Informationen on-the-fly in meine Ordnerstruktur eingebaut (mit einer Shell-Extension wie git-cheetah oder TortoiseGit sogar dann direkt sichtbar) - dies wär für mich einfacher.

    Bzgl. Deines Einwandes mit der Dateigröße muss ich sagen, dass dies mir egal ist. Ich will nur meinen eigenen Dateien archivieren, dies sind maximal 10.000 C++ und Tex-Dateien, und maximal einige wenige Bilder sowie die Kontoauszüge. Die Tatsache, dass solche Daten nicht mehr löschbar sind, kommt mir sehr entgegen. Gerade meine Kontoauszüge verschwinden von Zeit zu Zeit einfach so, git würde mir da bei der Rekonstruktion wirklich helfen.

    Ich werde beizeiten git und rdiff-backup ausprobieren und mich hier entsprechend melden.

    Danke!



  • Gitter schrieb:

    vielen Dank für Deine ausführliche Antwort.
    rdiff-backup sieht in der Tat sehr gut aus. Was mich aber abschreckt ist die Tatsache, dass ich Dateien, welche nicht mitgesichert werden sollen, jedes Mal über die Komandozeile o.ä. spezifieren muss.

    Vielleicht hilft dir der Kommandozeilenparameter --exclude-globbing-filelist von rdiff-backup. Das ist zwar immer noch nicht so "lokal" wie .gitignore-Dateien in Unterordnern, aber du kannst damit in einer externen Datei spezifizieren, was im Backup berücksichtigt werden soll und was nicht.

    Der Schalter heißt zwar --exclude-globbing-filelist, aber man kann damit trotzdem auch includes (statt nur excludes) angeben, wenn man möchte.



  • Christoph schrieb:

    und hatte bisher keinen Grund zur Klage (solange du keine NTFS-Partition als Zielvolume verwendest).

    Was für ein Problem hat rdiff-backup denn mit NTFS?



  • audacia schrieb:

    Christoph schrieb:

    und hatte bisher keinen Grund zur Klage (solange du keine NTFS-Partition als Zielvolume verwendest).

    Was für ein Problem hat rdiff-backup denn mit NTFS?

    Das größte Problem war, dass es enorm langsam war. Ich spreche hier von ein paar 100kbyte/s auf Terabyte-Festplatten. Ich habe den Versuch nach etwa 8 Stunden abgebrochen und die Partition auf ext4 formatiert, dann lief das um Größenordnungen schneller.

    Ein anderes Problem war, dass Dateinamen für ext3/4 einfach Bytefolgen sind, sonst nichts. Für NTFS ist das nicht der Fall, da müssen Dateinamen ein korrektes Encoding besitzen (in meinem Fall war das UTF-8, wenn ich mich richtig erinnere). Jedenfalls hatte ich ein paar Dateien auf meiner ext3-Partition, die keinen gültigen UTF-8-Namen hatten (hing mit wine und fremdsprachigen Programmen zusammen). An diesen Dateien ist rdiff-backup jedesmal gescheitert.

    Es gab auch noch ein Problem mit Hardlinks, die nicht korrekt gesichert wurden, aber dafür möchte nicht meine Hand ins Feuer legen. Das könnte auch ein anderes Programm gewesen sein.

    Das bezieht sich alles auf NTFS als Ziel.
    NTFS als Quelle ist für rdiff-backup kein Problem, das mach ich regelmäßig.


Log in to reply