Trotz Cloud und File-Servern im Firmennetz speichern Benutzer nach wie vor wichtige Dateien auf den lokalen Festplatten ihrer Arbeitsstationen oder Notebooks. Moderne SSDs wiegen ihre Anwender dabei in einer trügerischen Sicherheit: Dank Technologien wie S.M.A.R.T. und Wear Leveling können diese Datenspeicher ihr Ableben vorhersehen und den Anwender meistens rechtzeitig vor einem Plattenausfall warnen. Doch nur selten verlieren Anwender wertvolle Daten durch einen spontanen Plattenausfall. Viel häufiger liegt die Ursache für den Datenverlust bei den Usern selbst, da sie versehentlich Files löschen oder überschreiben. Wer mit dem Notebook reist, muss auch damit rechnen, das Gerät zu verlieren oder irreparabel zu beschädigen.

Ein Gerät nebst OS und Applikation lässt sich zwar flott ersetzen, bei den Benutzerdateien sieht das jedoch anders aus. Daher braucht jeder Anwender mit wichtigen Dateien auf dem lokalen Rechner eine brauchbare Backup- und Restore-Strategie. Diese sollte folgende Funktionen enthalten:

- Mehrstufige Dateiversionierung,

- lokale Sicherung,

- Remote-Sicherung via LAN,

- optional eine Remote-Sicherung via WAN sowie

- Backup und Recovery unabhängig vom Betriebssystem.

Auf dem freien Markt gibt es Unmengen an Backupprogrammen für alle gängigen Betriebssysteme – und viele davon kommen aus unerklärlichen Gründen mit unübersichtlichen Benutzeroberflächen daher. Bei den meisten Usern endet die Sicherungskette dann auch an der USB-Festplatte. Wer seine Daten sichern möchte, sollte das allerdings besser mit einer Netzwerkfreigabe anstatt eines USB-Laufwerks bewerkstelligen. Gängige Cloudbackup-Tools wiederum sichern direkt in die angebundene Cloud und funktionieren daher nur, wenn der Nutzer auch online ist.

Git [1] ist eigentlich ein Werkzeug für Entwickler. Es erlaubt die Versionierung von Code, zeigt detailliert die Unterschiede zwischen den gesicherten Versionen und erlaubt mehreren Entwicklern, gemeinsam an einem Projekt zu arbeiten. Es funktioniert online und offline. Genau diese Features machen die beliebte Open-Source-Anwendung zu einem nahezu perfekten Backupprogramm, das es obendrein für alle gängigen Betriebssysteme gibt. Zudem ist das Sicherungsformat ebenfalls offen dokumentiert, unabhängig vom Betriebs- und Dateisystem und kein proprietäres Dateiformat.

Wer ein Git-Repository erstellt, legt zunächst einen Objektspeicher mit Kopien der ausgewählten Daten an. Dieser Objektspeicher verfolgt die Änderungen in den darin gesicherten Files. Sobald der Benutzer einen "Commit", also einen Snapshot der enthaltenen Dateien, anfertigt, merkt sich Git die Änderungen zur vorhergehenden Version. Der Anwender kann das komplette Repository oder einzelne Dateien auf frühere Versionen zurückdrehen, wenn er das möchte, und natürlich auch versehentliche gelöschte Informationen aus einem früheren Snapshot wiederherstellen.

Git sichert sein Repository aber nicht nur auf dem lokalen System. Der Anwender kann ein oder mehrere "Remotes", also entfernte Kopien des Repositories, erstellen und die Versionen dort hochladen. Das Gute daran: Remote-Repositories müssen nicht jeden einzelnen Commit sofort erhalten. Ein Nutzer kann viele aufeinanderfolgende Commits erst einmal in das lokale Repository schreiben und dann ein Update zum Remote-Repository senden. Der Differenzmechanismus von Git wird alle verpassten Commits des lokalen Repositories übermitteln, sodass das entfernte Repository am Ende alle Zwischenschritte enthält.

Auch beim Restore zeigt sich Git sehr flexibel. Der Anwender kann auf der Kommandozeile oder in einer der vielen verfügbaren Git-UIs bequem auf frühere Versionen einzelner Dateien oder ganzer Verzeichnisse zugreifen. Dabei muss er nicht zwangsweise die bestehende Version überschreiben, sondern kann eine frühere Version unter einem anderen Namen sichern. Auch bei den Git-Servern gibt es eine große Auswahl und auch hier kann der Anwender bei Bedarf einzelne Dateien über die Web-UI einsehen, ändern oder herunterladen.

Die Git-Homepage offeriert unter [2] ein Setup für Git unter Windows. Neben dem reinen CLI-Tool für den Windows-Prompt und die PowerShell liefert Git auch die nötigen OpenSSL-Bibliotheken und Tools sowie eine MinGW-Umgebung mit. Dabei handelt es sich um eine Bash-Implementierung für Windows. Administratoren können Git auf Windows dann sowohl auf der Kommandozeile oder in der PowerShell betreiben als auch im Git-Bash.

Für Windows existiert zudem eine Reihe an GUI-Tools für Git. Der populäre "Github Desktop" zielt jedoch primär auf Anwendungsentwickler ab. Gerade bei großen Repositories fehlt es diesem Tool ein wenig an der Übersicht. Zwar nicht quelloffen, aber dennoch kostenfrei stellt Atlassian mit Sourcetree [3] seinen Git-Client zur Verfügung. Dieser lässt sich sowohl für Development- als auch Backup-Repositories nutzen. Ein etwas älteres, technisch teils überfrachtetes Look and Feel bietet derweil Git Extensions [4]. Im Gegenzug läuft dieser freie Client extrem flott und enthält viele Funktionen.

Wer die Entwicklungsumgebung Eclipse nutzt, bekommt das in Java geschriebene Git-Werkzeug Jgit mitgeliefert. Im Gegensatz zum herkömmlichen Git-Client beherrscht Jgit auch das S3-Protokoll. Wer sein Repositoriy also anstelle oder zusätzlich zum regulären Git-Server ablegen will, kann dies mit Jgit direkt in einen S3-kompatiblen Objektspeicher erledigen.

Zur Versionskontrolle erstellt Git das versionierte Repository im Unterverzeichnis ".git" innerhalb des zu sichernden Ordners. Das funktioniert jedoch nicht für unser Backupszenario. Der Schlüssel zum Erfolg lautet hier schlicht "--separate-git-dir" und ist ein Parameter bei der Erstellung des Repositories. Dieser gibt an, dass Git den Objektspeicher für die Versionierung nicht innerhalb des Verzeichnisses, sondern auf einem anderen Pfad erstellt. Dann ist ".git" kein Verzeichnis mit den Dateien, sondern eine Textdatei mit dem Link zum externen Verzeichnis und dient somit als betriebs- und dateisystemunabhängiger Link.

In unserem Beispiel erstellen wir ein Git-Repository innerhalb des regulären Benutzerverzeichnisses für Dokumente und nutzen ein USB-Laufwerk auf "H:" für den Objektspeicher:

Falls Sie Git noch nicht auf dem System genutzt haben, fragt Sie das Tool nach globalen Variablen wie Benutzer und E-Mail-Adresse. Dann erstellt es das Objektverzeichnis auf dem USB-Laufwerk. Je nachdem, wie viele Daten sich im Dokumentenverzeichnis befinden, kostet dieser Schritt entsprechend Zeit. In unserem Setup schreibt Git seine Daten mit einer Rate von etwa 1,2 GByte pro Minute weg. Die Geschwindigkeit hängt auch davon ab, ob Git kleine oder große Dateien einfügt. Während des Schreibens werden Sie eine Reihe von Warnungen sehen:

Das hat mit dem alten Dilemma zu tun, dass Unix/Linux-Systeme das Zeilenende in einer Textdatei anders definieren als Windows. Da Git unabhängig vom Betriebssystem arbeitet, sichert es Textdateien innerhalb des Objektspeichers grundsätzlich im Unix/Linux-Format, lässt die Originaldatei dabei jedoch unverändert. Diese automatische Konvertierung sollte den Anwender nicht stören, es sei denn, er stellt eine im Git gespeicherte Textdatei ohne das Tool Git wieder her. Wenn Sie beispielsweise von einem Git-Server mit Web-UI eine Textdatei aus Ihrem Repository via HTTP herunterladen, findet keine CRLF-Rückkonvertierung statt.

Nachdem Git nun alle Daten in das lokale Repository kopiert hat, erstellen Sie einen Snapshot des aktuellen Zustands über den sogenannten "commit":

Nehmen Sie nun Änderungen an Dateien vor, verfolgt Git diese und sichert sie beim nächsten Commit. Jeder Commit erhält eine eindeutige ID und zur besseren Übersicht einen Namen, den Sie mit dem Parameter "-m" übergeben, in unserem Fall "Repository erstellt". In der Git-Historie erkennen Sie später genau, welche Dateien sich bei welchem Commit geändert haben. Fügen Sie neue Dateien in das Verzeichnis ein, nimmt Git diese allerdings nicht automatisch in das Repository auf. Hier müssen Sie vor dem Commit erneut ein git add -A ausführen. Um den Prozess zu automatisieren, erstellen Sie eine passende Batchdatei:

Jetzt können Sie eine Verknüpfung auf dem Desktop anlegen und per Mausklick das Backup anstoßen. Alternativ legen Sie einen automatischen Task an, der das Backup beispielsweise jede Stunde durchführt. Dabei müssen Sie allerdings berücksichtigen, dass Git, wie jedes andere Programm, aktuell geöffnete Dateien nicht im Snapshot berücksichtigen kann. Das Skript lässt sich natürlich auch noch schöner gestalten, sodass es beispielsweise zuerst prüft, ob der USB-Zieldatenträger überhaupt am System hängt, und nur dann das Backup anstößt und einmal pro Tag einen Upload zum Server initiiert.

Um nun eine einzelne Datei nach einer versehentlichen Änderung auf einen früheren Stand zurückzudrehen, nutzen Sie git restore wie im folgenden Beispiel:

Zu den populärsten selbst gehosteten Git-Servern gehört Gitlab [5], das natürlich auch auf dem Service unter "gitlab.com" läuft. Das wuchtige, in Ruby geschriebene Gitlab verlangt der Serverhardware jedoch einiges an Leistung ab. Im Gegenzug liefert Gitlab auch einen großen Funktionsumfang wie ein Wiki, einen Bugtracker oder ein integriertes Container-Image-Repository. Wer einen Git-Server nur als Backup-Target einsetzt, benötigt die vielen Funktionen nicht und ist dann mit einem simplen, flotten Git-Server wie Gitea [6] besser dran. Gitea ist die simpelste Lösung, kommt mit vielen Datenbanken zurecht und läuft mit einem geringen Ressourcenbedarf auch in Containern. Für Administratoren mit einem überwiegenden Win­dows-Background gibt es zudem mit "Bonobo" [7] einen freien Git-Server in .NET, der sich direkt in den IIS integriert.

Um eine zweite, entfernte Sicherheitskopie eines lokalen Repositories zu erstellen, brauchen Sie einen Git-Server. Auch hier gibt es eine ganze Reihe verschiedener Open-Source-Angebote. Für Einsteiger ist dabei das erwähnte Gitea die simpelste Lösung. Das in "Go" geschriebene Programm stammt von Googles hauseigenem Git-Server Gogs ab, wird jedoch von einer etwas liberaleren Entwickler-Community gepflegt als das Google-Original. Wie Git selbst gibt es auch Gitea für alle gängigen Plattformen, sodass der Serverdienst auch problemlos auf Windows läuft. Alles, was der Administrator braucht, ist eine bestehende Git-Installation und eine Datenbank. Gitea unterstützt MySQL und PostgreSQL ebenso wie MSSQL oder für simple Testsetups auch Sqlite. Natürlich lässt sich Gitea auch in einem Podman- oder Docker-Container betreiben.

Einmal gestartet, hört Gitea in der Standardeinstellung auf die Ports 3000 (HTTP) und 22 (SSH). In der simplen und übersichtlichen Web-UI legen Sie zuerst Benutzerkonten an. Damit sich die Clients nicht langwierig mit Benutzernamen und Passwort anmelden müssen, sollten sich die Benutzer mit SSH-Schlüsseln authentisieren. Die Schlüsselpaare generieren Sie in der Regel über ein zentrales Key-Management und weisen sie dann den Nutzern zu. In kleineren Umgebungen können die Nutzer auf den Client-PCs aber auch selbst Schlüsselpaare via "ssh-keygen" erstellen. Denken Sie daran, stets eine Kopie der SSH-Schlüssel außerhalb des Client-PCs aufzubewahren.

Läuft der Remote-Server, loggen sich die Anwender zunächst an der Gitea-UI mit ihrem Benutzerkonto an. Hier hinterlegen Sie den öffentlichen SSH-Schlüssel, sofern das nicht bereits anderweitig geschehen ist. Im Benutzerkonto erzeugt der Anwender dann ein leeres Repository für die Backupdaten und markiert es als "Privates Repository". Gitea liefert dem Anwender die passende SSH-URL zurück. Dem bestehenden lokalen Repository fügen Sie nun den Remote-Speicherpfad "origin" hinzu:

Jetzt kopieren Sie das lokale Repository samt allen bisherigen Commits auf den Remote-Server mit

Mit "-u" ernennen Sie dabei den Remote-Server "origin" zum standardmäßigen Upstream-Server des Repositories. Künftige Änderungen können Sie dann mit dem Kommando "git push" ohne weitere Parameter an den "origin"-Server senden. Git erlaubt es dem Anwender, mehrere Remote-Repositories anzugeben und über "git push name" die Updates an verschiedene Server zu senden.

Der Git-Server kann sowohl im LAN des Unternehmens als auch auf einem Cloudsystem oder in der DMZ mit Internetanbindung laufen. Da die Kommunikation zwischen Client und Server ohnehin mit SSH-Verschlüsselung arbeitet, funktioniert das Cloudbackup zum hauseigenen Git-Server auch ohne VPN sicher. Lediglich dem Webinterface des Gitea-Servers auf Port 3000 sollten Sie entweder einen Reverse-Proxy/Load-Balancer mit HTTPS-Terminierung voranstellen oder den Dienst selbst mit einem passenden Zertifikat auf HTTPS betreiben. Dazu modifizieren Sie die Konfiguration von Gitea in "./gitea/ conf/app.ini" und erweitern die Sektion:

Gehostete Git-Dienste wie Github oder Gitlab kommen natürlich nicht als Backup-Targets in Frage, da sie die Größe der Repositories begrenzen.

Haben Sie sich mit dem Git-Tool vertraut gemacht, können Sie die Nutzung optimieren. Arbeiten Sie beispielsweise für eine begrenzte Zeit an einem Projekt, können Sie alle zugehörigen Daten in einem eigenen Verzeichnis und damit auch in einem eigenen Git sichern. Liegt der Ordner innerhalb eines bestehenden Repositories, merkt Git dies und schließt das Projektverzeichnis als eigenes Repository vom darunter liegenden Git aus.

Der Anwender sichert dann zwei Repositories: Das Dokumentenverzeichnis selbst und das Projekt. Dank der Gruppenfunktionen von Git lassen sich die Projektdaten von Arbeitsgruppen gemeinsam nutzen und auf mehrere Clients auschecken. Endet das Projekt, können die Clients das lokale Projektverzeichnis löschen und der Git-Server behält alle Daten als Archiv, das den Nutzern jederzeit zur Verfügung steht.

Da Backup und Versionskontrolle ohnehin eng verwandte Themen sind, eignet sich Git sehr gut als Backuptool, wohlgemerkt für Benutzerdaten. Eine Sicherung des Betriebssystems, der installierten Anwendungen oder deren Konfiguration in der Regsitry übernimmt Git nicht.