Frage GIT als Backup-Tool


Installieren Sie git auf einem Server

cd /
git init
git add .
git commit -a -m "Yes, this is server"

Dann geh /.git/ um auf ein Netzlaufwerk (SAN, NFS, Samba, was auch immer) oder auf eine andere Platte zu zeigen. Verwenden Sie einen Cron-Job jede Stunde / Tag usw., um die Änderungen zu aktualisieren. Das .git-Verzeichnis würde eine versionierte Kopie aller Server-Dateien enthalten (mit Ausnahme der nutzlosen / komplizierten wie / proc, / dev etc.)

Für einen unwichtigen Entwicklungsserver, bei dem ich nicht die Mühe / den Aufwand haben möchte, ihn auf einem geeigneten Backup-System einzurichten, und wo Backups nur der Bequemlichkeit dienen würden (I. E. wir nicht brauchen um diesen Server zu sichern, aber es würde etwas Zeit sparen, wenn etwas schief gelaufen wäre), könnte dies eine gültige Backup-Lösung sein oder wird es einfach in einem großen Stapel von Kisten umfallen?


88
2017-12-15 12:10


Ursprung


funkelt nicht ähnliche Idee? - B14D3
@ B14D3 Ich denke, Sparkleshare ist eher eine Art Dropbox-Dings, aber ich werde es untersuchen - Smudge
Du hast recht, aber es benutzt git, um eine Art Buckup-Sache zu machen (Kopieren auf mehrere PCs und Kontrollversionen von Dateien);) - B14D3
Das große Problem dabei ist, dass es keine zentrale Kontrolle gibt - Sie müssen direkten (ssh) Zugriff auf die Maschine haben, um jede Form von Wartung oder Backup-Validierung durchzuführen. Ich finde immer eine App auf den zu sichernden Boxen zu installieren, dann ist es ein viel größerer Gewinn, sie von einem zentralen Ort zu verwalten. - hafichuk
@hafichuk Mit Tools wie Puppet / Chef ist es nicht so ein großes Problem, aber ich sehe deinen Standpunkt. - Smudge


Antworten:


Du bist keine dumme Person. Verwenden git als Backup-Mechanismus kann attraktiv sein, und trotz was andere Leute gesagt haben, git funktioniert gut mit Binärdateien. Lesen diese Seite aus dem Git Book für weitere Informationen zu diesem Thema. Grundsätzlich seit git verwendet keinen Delta-Speichermechanismus, es ist nicht wirklich wichtig Was Ihre Dateien sehen aus (aber der Nutzen von git diff ist ziemlich niedrig für Binärdateien mit einer Bestandskonfiguration).

Das größte Problem bei der Verwendung git Bei der Sicherung werden die meisten Metadaten des Dateisystems nicht beibehalten. Speziell, git zeichnet nicht auf:

  • Dateigruppen
  • Dateibesitzer
  • Dateiberechtigungen (außer "ist diese ausführbare Datei")
  • erweiterte Attribute

Sie können dies lösen, indem Sie Tools schreiben, um diese Informationen explizit in Ihrem Repository aufzuzeichnen, aber es kann schwierig sein, dies richtig zu machen.

Eine Google-Suche nach Git Backup-Metadaten ergibt eine Reihe von Ergebnissen, die lesenswert erscheinen (einschließlich einiger Tools, die bereits versuchen, die hier angesprochenen Probleme zu kompensieren).

Etckeeper wurde für das Backup entwickelt /etc und löst viele dieser Probleme.


78
2017-12-15 17:25



+1 für die Erwähnung von ACLs / Berechtigungen - Larry Silverman
Git speichert auch keine leeren Verzeichnisse. - Flimm
und es saugt auch für das Verschieben / Umbenennen von Dateien im Verlauf. - cregox
Da git sich nicht sehr gut mit Binärdateien beschäftigt, möchten Sie vielleicht auch nachsehen Anhangdas hilft, das besser zu machen. Es ändert jedoch die Idee von was git ist etwas. - Wouter Verhelst
Meiner Meinung nach können Sie mit git Daten sichern, aber nicht ganze Server - EKanadily


Ich habe es nicht benutzt, aber du wirst es vielleicht sehen bup Das ist ein Backup-Tool basierend auf Git.


20
2017-12-15 13:27



Noch nie gesehen, sieht interessant aus - Smudge
Ich habe kürzlich angefangen, bup zu benutzen, nur ein paar Tage bevor meine Festplatte abgestürzt ist;) Restore ging gut, also empfehlenswert! - André Paramés
@ AndréParamés also, was du sagst, ist gerade, nachdem du installiert hast, dass deine Festplatte abgestürzt ist ... mmmmhh ... :) nur ein Scherz - hofnarwillie


Es kann eine gültige Backup-Lösung sein, Etckeeper basiert auf dieser Idee. Aber behalte das Auge im Auge .git Verzeichnis Berechtigungen sonst drängen /etc/shadow kann in der gelesen werden .git Verzeichnis.


12
2017-12-15 12:18





Während Sie das technisch tun könnten, würde ich zwei Vorbehalte dagegen sprechen:

1, Sie verwenden ein Versionskontrollsystem für Binärdaten. Sie verwenden es daher für etwas, für das es nicht bestimmt war.

2, ich mache mir Sorgen um Ihren Entwicklungsprozess, wenn Sie keinen Prozess haben (Dokumentation oder automatisiert), um eine neue Maschine zu bauen. Was ist, wenn Sie einen Bus kaufen, wer weiß, was zu tun ist und was wichtig ist?

Die Notfallwiederherstellung ist wichtig, jedoch ist es besser, das Setup einer neuen Entwicklungsumgebung zu automatisieren (script), als nur alles zu sichern. Sicher verwenden Git für Ihr Skript / Dokumentation, aber nicht für jede Datei auf einem Computer.


11
2017-12-15 13:45



Entwicklungskisten stammen alle aus KickStart-Dateien, und tatsächlich dauert die durchschnittliche Box etwa 2 oder 3 Monate, bevor sie wieder aufgebaut wird. Aber die Leute ändern die Konfigurationen und machen Dinge, wir bauen die Boxen wieder auf und die Leute sagen "Hey, ich weiß, dass ich es nicht in die Quellcodeverwaltung gelegt habe, aber ich hatte etwas Scheiß auf der Box" und ich lache über sie, weil sie dumm sind. Rundherum, gute Zeiten. Binärdaten wären eine Hündin, etwas, das ich während der Dusche völlig übersehen habe. - Smudge
Ich begrüße Ihre Einstellung gegenüber denen, die grundlegende Prinzipien nicht befolgen. Persönlich habe ich eine ähnliche Situation wie Sie, aber ich habe ein Git-Repository, das in allen Konfigurationsdateien, die wichtig sein können, anstatt einen Haken alle verbindet. Plus ein txt doc mit Setup-Schritten. - Phil Hannent
Ich denke, Git funktioniert ziemlich gut für Binärdateien, vide Google Android Bulk-Teil des Repo sind Git-Repositories von vorgefertigten ausführbaren Dateien. - user377178


Ich benutze Git als Backup für mein Windows-System, und es war unglaublich nützlich. Am Ende des Posts zeige ich die Skripts, die ich zur Konfiguration auf einem Windows-System verwende. Die Verwendung von git als Backup für jedes System bietet 2 große Vorteile:

  1. Im Gegensatz zu kommerziellen Lösungen, die häufig ihr eigenes proprietäres Format verwenden, erfolgt Ihr Backup in einem Open-Source-Format, das weitgehend unterstützt und sehr gut dokumentiert ist. Dies gibt Ihnen die volle Kontrolle über Ihre Daten. Es ist sehr einfach zu sehen, welche Dateien wann geändert wurden. Wenn Sie Ihren Verlauf kürzen möchten, können Sie das auch tun. Möchten Sie etwas aus Ihrer Geschichte ausradieren? Kein Problem. Eine Version Ihrer Datei zurück zu bekommen ist so einfach wie ein beliebiger Git-Befehl.
  2. So viele oder so wenige Spiegel, wie Sie möchten, und alle können angepasste Backup-Zeiten haben. Sie erhalten Ihren lokalen Spiegel, der durch langsamen Internetverkehr nicht belastet wird, und gibt Ihnen (1) die Möglichkeit, häufigere Backups während des Tages und (2) eine schnelle Wiederherstellungszeit durchzuführen. (Häufige Backups sind ein großes Plus, da ich die meiste Zeit finde, in der ich ein Dokument durch einen Benutzerfehler verliere. Zum Beispiel überschreibt dein Kind versehentlich ein Dokument, an dem er in den letzten 5 Stunden gearbeitet hat.) Aber du bekommst dein Remote-Spiegel, der den Vorteil des Datenschutzes im Falle einer lokalen Katastrophe oder eines Diebstahls bietet. Und angenommen, Sie möchten, dass Ihr Remote-Mirror zur angepassten Zeit gesichert wird, um Ihre Internetbandbreite zu speichern? Kein Problem.

Fazit: Ein Git-Backup gibt Ihnen unglaublich viel Kontrolle darüber, wie Ihre Backups ablaufen.

Ich habe dies auf meinem Windows-System konfiguriert. Der erste Schritt besteht darin, das lokale git-Repository zu erstellen, in das Sie alle Ihre lokalen Daten übertragen. Ich empfehle die Verwendung einer lokalen zweiten Festplatte, aber die Verwendung der gleichen Festplatte wird funktionieren (aber es wird erwartet, dass Sie dies irgendwo Remote schieben, oder sonst Ihre Schraube, wenn die Festplatte stirbt.)

Sie müssen zuerst cygwin (mit rsync) installieren und git für Windows installieren: http://git-scm.com/download/win

Als nächstes erstellen Sie Ihr lokales Git Repo (nur einmal ausgeführt):

init-repo.bat:

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

Als nächstes haben wir unseren Backup-Skript-Wrapper, der regelmäßig von Windows Scheduler aufgerufen wird:

gbackup.vbs:

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

Als nächstes haben wir das Backup-Skript selbst, das der Wrapper aufruft:

gbackup.bat:

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

Wir haben die Datei exclude-from.txt, in der wir alle zu ignorierenden Dateien speichern:

exclude-from.txt:

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

Du musst zu irgendwelchen Remote-Repos gehen und ein "Git-Init - Bare" auf ihnen machen. Sie können das Skript testen, indem Sie das Backup-Skript ausführen. Vorausgesetzt, alles funktioniert, gehen Sie zu Windows Scheduler und zeigen Sie eine stündliche Sicherung in Richtung der VBS-Datei. Danach haben Sie eine git Geschichte Ihres Computers für jede Stunde. Es ist sehr praktisch - jeder versehentlich einen Teil des Textes löschen und es verpassen? Überprüfen Sie einfach Ihr Git-Repository.


6
2018-03-21 17:10



Nur neugierig - wird es auch für langsame oder nicht standardmäßige Netzlaufwerke funktionieren, wie die von NetDrive oder Expandrive emuliert? Ich finde die meisten Backup-Software mit diesen Netzlaufwerken fehlgeschlagen. Außerdem werden die Dinge schmerzhaft langsam und neigen zu einer Auszeit, wenn ich alle Dateien im Backup auflisten und einzelne Dateien extrahieren möchte. Können diese Probleme gelöst werden? - JustAMartin
@JustAMartin Ich habe es noch nie auf Netzlaufwerken getestet, also kann ich nicht sagen. Sobald Sie die Dateien IN ein Git Repo bekommen, ist Git sehr effizient. - user64141


Nun, es ist keine schlechte Idee, aber ich denke, es gibt 2 rote Flaggen:

  • Wenn die Festplatte ausfällt, verlieren Sie alles, wenn Sie Ihre Commits nicht auf einen anderen Server / Laufwerk übertragen. (Event wenn du einen Plan dafür hast, erwähne ich lieber.)

... aber trotzdem kann es ein gutes Backup für korruptionsbezogene Dinge sein. Oder wie du gesagt hast, wenn der .git / Ordner woanders ist.

  • Diese Sicherung wird immer größer. Es gibt keine Beschneidung oder Rotation oder irgendetwas standardmäßig.

... Also müssen Sie vielleicht Ihrem Cronjob sagen, dass er Tags hinzufügen soll, und dann sicherstellen, dass Commits, die nicht markiert sind, bereinigt werden.


4
2017-12-15 13:40



Wir würden wahrscheinlich das .git-Verzeichnis auf einem Remote-Server mounten, obwohl das Clasic rm -Rf / würde uns einige Probleme verursachen. Unser aktuelles Backup-System speichert Daten für 2 Jahre oder 50 Versionen (je nachdem, was zuerst eintritt), so dass unser Backup ständig zunimmt. Aber ich mag die Idee, Tags hinzuzufügen, wir könnten "tägliche", "wöchentliche" usw. Tags haben - Smudge
+1 für immer wachsenden Platzbedarf - hafichuk
@sam Git wächst ständig. Sie können die Historie nicht älter als N Jahre beschneiden. Ich nehme an, Ihr aktuelles System tut es. - rds
In Bezug auf die Vergrößerung, bitte "git gc" regelmäßig oder bevor Sie auf einen anderen (zentralen) Server drücken. Ohne dies könnte der Git Repo (viel) größer werden als er sollte. Ich hatte einmal einen 346 MB git Repo, der auf 16 MB schrumpfen kann. - Hendy Irawan


Ich habe es nicht mit einem vollständigen System versucht, aber ich benutze es für meine MySQL-Backups (mit der Option --skip-extended-insert) und es hat wirklich gut für mich gearbeitet.

Sie werden ein Problem mit Binärdatendateien bekommen (ihr gesamter Inhalt könnte und wird sich ändern) und Sie könnten Probleme mit der .git Ordner wird wirklich groß. Ich würde empfehlen, ein .gitignore Datei und nur Backup-Dateien, die Sie wirklich wissen, dass Sie brauchen.


3
2017-12-15 13:23



Ich verwende es auch für MySQL-Backups mit --extended-insert = false. Achten Sie darauf, "git gc" regelmäßig oder direkt nach dem Festschreiben zu "git". - Hendy Irawan
Sehen Ist die Sicherung einer MySQL-Datenbank in Git eine gute Idee? - Michael Hampton♦


Ich habe einmal eine Backup-Lösung entwickelt, die auf Subversion basiert. Während es ziemlich gut funktionierte (und git sollte noch besser funktionieren), denke ich, dass es hier bessere Lösungen gibt.

Ich betrachte rsnapshot einer der besseren sein - wenn nicht das besser. Mit einem guten Gebrauch von Hard Link habe ich einen 300 GB Fileserver (mit einer halben Million Dateien) mit täglicher, wöchentlicher und monatlicher Sicherung, die bis zu einem Jahr zurückreicht. Der gesamte belegte Speicherplatz ist nur eine vollständige Kopie + der inkrementelle Teil jeder Sicherung, aber dank Hardlinks habe ich eine Komplett "Live" Verzeichnisstruktur in jedem der Backups. Mit anderen Worten, Dateien sind nicht nur direkt unter daily.0 (der letzten Sicherung), sondern auch täglich1 (gestern) oder wöchentlich2 (vor zwei Wochen) und so weiter zugänglich.

Wenn ich den Backup-Ordner mit Samba neu teile, können meine Benutzer die Datei aus Backups ziehen, indem sie einfach ihren PC auf den Backup-Server richten.

Eine weitere sehr gute Option ist rdiff-Sicherung, aber da ich gerne Dateien immer einfach durch die Überschrift Explorer auf \\ Servername haben möchte, war rsnapshot eine bessere Lösung für mich.


3
2018-03-21 20:01



Das letzte Release von rdiff-backup ist von 2009. Ist es extrem gut designed und benötigt überhaupt kein Update oder ist es einfach ein verlassenes Projekt? - Mateusz Konieczny
Ich weiß nicht ob es gepflegt wird, aber es ist im Grunde "fertig". - shodanshok
Aus dem Blick savannah.nongnu.org/bugs/... Es scheint, dass es noch im Jahr 2015 einige Aktivitäten gab, aber viele Fehlerberichte werden ignoriert. Ich denke, ich werde es als aufgegeben betrachten. - Mateusz Konieczny


Ich hatte die gleiche Idee, mit Git zu sichern, im Grunde, weil es versionierte Backups erlaubt. Dann sah ich rdiff-Sicherung, die diese Funktionalität bietet (und vieles mehr). Es hat eine wirklich nette Benutzeroberfläche (siehe die CLI-Optionen). Ich bin ziemlich glücklich damit. Das --remove-older-than 2W ist ziemlich cool. Es erlaubt Ihnen, nur Versionen älter als 2 Wochen zu löschen. rdiff-backup speichert nur Diffs von Dateien.


2
2017-12-15 18:07





Ich bin extrem neu in Git, aber sind nicht standardmäßig lokale Verzweigungen, und müssen explizit zu Remote-Repositories geschoben werden? Dies war eine unangenehme und unerwartete Überraschung. Schließlich will ich nicht alles von meinem lokalen Repo auf den Server "gesichert" werden? Das lesen Gitbuch:

Ihre lokalen Niederlassungen werden nicht automatisch mit den Fernbedienungen synchronisiert, auf die Sie schreiben - Sie müssen explizit die Zweigstellen verschieben, die Sie freigeben möchten. Auf diese Weise können Sie private Zweige für Arbeiten verwenden, die Sie nicht freigeben möchten, und nur die Zweigzweige verschieben, an denen Sie zusammenarbeiten möchten.

Für mich bedeutet dies, dass diese lokalen Zweige, wie andere Nicht-Git-Dateien auf meinem lokalen Rechner, gefährdet sind, verloren zu gehen, wenn sie nicht regelmäßig von irgendwelchen Nicht-Git-Mitteln gesichert werden. Ich tue das trotzdem, aber es hat meine Annahmen über Git ', alles in meinem Repo zu sichern' gebrochen. Ich würde es gerne klären!


2
2018-03-06 13:22



Fast alles über Git mit Ausnahme von Fernbedienungen ist lokal. Das ist Absicht. Sie können Dinge zu Fernbedienungen schieben, und sollten, insbesondere wenn für die Sicherung wie in diesem Szenario verwendet. Für Zweige, wieder, ja, müssen Sie sie explizit drücken, wenn Sie sie zu einer Fernbedienung hinzugefügt werden sollen. Für die Entwicklung ist das großartig, weil Sie oft etwas testen wollen, aber dieser Testzweig muss nicht auf unbestimmte Zeit aufbewahrt werden. Sobald Sie haben, was Sie davon brauchen, werden Sie wahrscheinlich es mit einem Dev-Zweig zusammenführen und den Testzweig delegieren. - LocalPCGuy