GIT als Backup-Tool

101

Installieren Sie git auf einem Server

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

Zeigen Sie /.git/dann auf ein Netzwerklaufwerk (SAN, NFS, Samba, was auch immer) oder eine andere Festplatte. Aktualisieren Sie die Änderungen mit einem Cron-Job jede Stunde / jeden Tag usw. Das .git-Verzeichnis würde eine versionierte Kopie aller Serverdateien enthalten (mit Ausnahme der nutzlosen / komplizierten Dateien wie / proc, / dev usw.).

Für eine nicht-wichtigen Entwicklungs - Server , wo ich es nicht den Aufwand / Kosten wollen der Einstellung auf einem geeigneten Backup - System auf, und wo Backups nur der Einfachheit halber würde (IE wir nicht brauchen , um diesen Server zu sichern , aber es würde sparen Könnte dies eine gültige Backup-Lösung sein oder fällt sie einfach in einen Haufen Kacke?

Verschmieren
quelle
3
Sparkleshare nicht mit ähnlichen Idee?
B14D3
@ B14D3 Ich denke, Sparkleshare ist eher eine Art Dropbox-Ding, aber ich werde es mir ansehen
Smudge
2
du hast recht, aber es benutzt git um irgendetwas zu machen (auf mehrere PCs kopieren und Versionen von Dateien kontrollieren);)
B14D3
Das große Problem dabei ist, dass es keine zentrale Steuerung gibt - Sie müssen direkten (ssh-) Zugriff auf die Maschine haben, um Wartungs- oder Backup-Überprüfungen durchzuführen. Ich finde immer, dass die Installation einer App auf den zu sichernden Boxen ein viel größerer Gewinn ist, wenn sie dann von einem zentralen Ort aus verwaltet werden.
Hafichuk
@hafichuk Mit Tools wie Puppet / Chef ist das kein so großes Problem, aber ich verstehe deinen Standpunkt.
Fleck

Antworten:

88

Du bist keine dumme Person. Die Verwendung gitals Sicherungsmechanismus kann attraktiv sein und gitfunktioniert trotz der Aussagen anderer problemlos mit Binärdateien. Lesen Sie diese Seite aus dem Git-Buch, um weitere Informationen zu diesem Thema zu erhalten. Grundsätzlich spielt gites keine Rolle, wie Ihre Dateien aussehen , da kein Delta-Speichermechanismus verwendet wird (aber das Dienstprogramm von git diffist für Binärdateien mit einer Standardkonfiguration ziemlich niedrig).

Das größte Problem bei der Verwendung gitfür Backups ist, dass die meisten Metadaten des Dateisystems nicht erhalten bleiben. Insbesondere zeichnet gitnicht auf:

  • Dateigruppen
  • Dateibesitzer
  • Dateiberechtigungen (außer "Ist diese ausführbar?")
  • erweiterte Attribute

Sie können dieses Problem lösen, indem Sie Tools schreiben, mit denen diese Informationen explizit in Ihrem Repository aufgezeichnet werden. Es kann jedoch schwierig sein, dies zu korrigieren.

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

etckeeper wurde zum Sichern entwickelt /etcund löst viele dieser Probleme.

larsks
quelle
15
+1 für die Erwähnung von ACLs / Berechtigungen
Larry Silverman
22
Git speichert auch keine leeren Verzeichnisse.
Flimm
und es ist auch zum Verfolgen des Verschiebens / Umbenennens von Dateien in der Geschichte zum Kotzen.
Cregox
1
Da git nicht sehr gut mit Binärdateien umgehen kann, sollten Sie sich auch den git-Anhang ansehen, um dies zu verbessern . Es ändert jedoch etwas die Vorstellung, was git ist.
Wouter Verhelst
1
Meiner Meinung nach ist , dass Sie git zum Sichern von Daten verwenden können , aber nicht ganze Server
EKanadily
21

Ich habe es nicht benutzt, aber Sie könnten sich bup ansehen , ein auf git basierendes Backup-Tool.

Eintopf
quelle
Noch nie gesehen, sieht interessant aus
Smudge
1
Ich habe vor kurzem angefangen, bup zu benutzen, nur ein paar Tage bevor meine Festplatte abgestürzt ist.
André Paramés
1
@ AndréParamés Also, was du sagst, ist, kurz nachdem du bup installiert hast, ist deine Festplatte abgestürzt ... mmmmhh ... :) nur ein Scherz
hofnarwillie
12

Es kann eine gültige Backup-Lösung sein, auf dieser Idee basiert etckeeper. Behalten Sie jedoch die .gitVerzeichnisberechtigungen im Auge, da ansonsten Pushing /etc/shadowim .gitVerzeichnis lesbar sein kann .

Stein
quelle
11

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

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

2, Ich mache mir Sorgen um Ihren Entwicklungsprozess, wenn Sie keinen Prozess (Dokumentation oder automatisiert) zum Erstellen einer neuen Maschine haben. Was ist, wenn Sie einen Bus kaufen, wer weiß, was zu tun ist und was wichtig ist?

Notfallwiederherstellung ist wichtig, jedoch ist es besser, das Setup einer neuen Entwicklungsbox zu automatisieren (Skript), als nur alles zu sichern. Verwenden Sie git sicher für Ihr Skript / Ihre Dokumentation, aber nicht für jede Datei auf einem Computer.

Phil Hannent
quelle
4
Entwicklungsboxen stammen alle aus KickStart-Dateien, und tatsächlich hält die durchschnittliche Box etwa zwei bis drei Monate, bevor sie neu erstellt wird. Aber die Leute ändern die Konfiguration und machen Dinge, wir bauen die Boxen neu und die Leute sagen "Hey, ich weiß, ich habe es nicht in die Quellcodeverwaltung gesteckt, aber ich hatte etwas Scheiße auf dieser Box" und ich lache über sie, weil sie dumm sind. Rundum gute Zeiten. Binärdaten wären eine Hündin, was ich beim Duschen total übersehen habe.
Verschmieren
Ich begrüße Ihre Haltung gegenüber denen, die den Grundprinzipien nicht folgen. Persönlich habe ich eine ähnliche Situation wie Sie, aber ich habe ein Git-Repository, das in allen Konfigurationsdateien Verknüpfungen enthält, die wichtig sein könnten, anstatt alle zu fangen. Plus ein TXT-Dokument mit Setup-Schritten.
Phil Hannent
1
Ich denke, Git funktioniert ziemlich gut für Binärdateien. Der Hauptteil des Repos von Google Android sind Git-Repositories mit vorgefertigten ausführbaren Dateien.
user377178
6

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

  1. Im Gegensatz zu kommerziellen Lösungen, die häufig ein eigenes proprietäres Format verwenden, liegt Ihr Backup in einem Open-Source-Format vor, das umfassend unterstützt und sehr gut dokumentiert wird. So haben Sie die volle Kontrolle über Ihre Daten. Es ist sehr einfach zu sehen, welche Dateien wann geändert wurden. Wenn Sie Ihren Verlauf abschneiden möchten, können Sie dies ebenfalls tun. Möchten Sie etwas aus Ihrer Geschichte auslöschen? Kein Problem. Das Abrufen einer Version Ihrer Datei ist so einfach wie jeder git-Befehl.
  2. So viele oder so wenige Spiegel, wie Sie möchten, und alle können angepasste Sicherungszeiten haben. Sie erhalten Ihren lokalen Spiegel, der nicht durch langsamen Internetverkehr belastet wird, und haben somit (1) die Möglichkeit, im Laufe des Tages häufiger Backups durchzuführen, und (2) eine schnelle Wiederherstellungszeit. (Häufige Backups sind ein großer Vorteil, da ich feststelle, dass ein Dokument meistens durch einen Benutzerfehler verloren geht. Ihr Kind überschreibt beispielsweise versehentlich ein Dokument, an dem es in den letzten 5 Stunden gearbeitet hat.) Remote Mirror, der den Vorteil des Datenschutzes im Falle einer lokalen Katastrophe oder eines Diebstahls bietet. Angenommen, Sie möchten, dass Ihre Remote-Spiegelung zu einem benutzerdefinierten Zeitpunkt gesichert wird, um Ihre Internetbandbreite zu schonen? 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-Repo zu erstellen, auf das Sie alle Ihre lokalen Daten übertragen. Ich empfehle die Verwendung einer lokalen zweiten Festplatte, aber die Verwendung derselben Festplatte wird funktionieren (aber es wird erwartet, dass Sie diese an eine entfernte Stelle verschieben oder auf andere Weise verschrauben, wenn die Festplatte ausfällt.)

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

Als nächstes erstellen Sie Ihr lokales Git-Repo (nur einmal ausführen):

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-Script-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 ablegen:

exclude-from.txt:

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

Sie müssen zu einem beliebigen Remote-Repository gehen und einen Initialisierungsschritt für dieses Repository ausführen. Sie können das Skript testen, indem Sie das Sicherungsskript ausführen. Wenn alles funktioniert, rufen Sie Windows Scheduler auf und richten Sie eine stündliche Sicherung auf die vbs-Datei. Danach haben Sie für jede Stunde einen Git-Verlauf Ihres Computers. Es ist äußerst praktisch - jeder löscht versehentlich einen Textabschnitt und vermisst ihn? Überprüfe einfach dein Git-Repository.

user64141
quelle
Nur neugierig - funktioniert es auch für langsame oder nicht standardmäßige Netzwerklaufwerke, wie sie von NetDrive oder Expandrive emuliert werden? Ich finde, dass die meisten Backup-Programme mit diesen Netzlaufwerken nicht funktionieren. Auch werden die Dinge schmerzhaft langsam und tendieren zum Timeout, wenn ich alle Dateien in der Sicherung auflisten und einzelne Dateien extrahieren möchte. Kann git diese Probleme lösen?
JustAMartin
@ JustAMartin Ich habe es noch nie auf Netzwerklaufwerken getestet, kann ich also nicht sagen. Sobald Sie die Dateien in einem Git-Repo erhalten, ist Git sehr effizient.
user64141
4

Nun, es ist keine schlechte Idee, aber ich denke, es gibt zwei rote Fahnen zu hissen:

  • Wenn die Festplatte ausfällt, verlieren Sie alles, wenn Sie Ihr Commit nicht auf einen anderen Server / ein anderes Laufwerk übertragen. (Event, wenn Sie einen Plan dafür haben, möchte ich erwähnen.)

... aber dennoch kann es ein gutes Backup für korruptionsbezogene Dinge sein. Oder wie Sie sagten, wenn sich der .git / -Ordner woanders befindet.

  • Dieses Backup wird immer größer. Standardmäßig gibt es keinen Schnitt, keine Rotation oder ähnliches.

... Möglicherweise müssen Sie Ihren Cronjob anweisen, Tags hinzuzufügen, und dann sicherstellen, dass Commits, die nicht markiert sind, bereinigt werden.

FMaz008
quelle
Wir würden das .git-Verzeichnis wahrscheinlich auf einem Remote-Server mounten, obwohl der Klassiker rm -Rf /uns einige Probleme bereiten würde. Unser derzeitiges Backup-System speichert die Daten für 2 Jahre oder 50 Versionen (je nachdem, welche Version zuletzt verwendet wird), sodass unser Backup ohnehin stetig zunimmt. Aber ich mag die Idee, Tags hinzuzufügen, wir könnten "tägliche", "wöchentliche" usw. Tags haben
Smudge
+1 für ständig wachsenden Platzbedarf
Hafichuk
@sam Git wächst ständig. Sie können die Historie, die älter als N Jahre ist, nicht beschneiden. Ich nehme an, dass Ihr aktuelles System dies tut.
16.
1
In Bezug auf die Vergrößerung machen Sie bitte regelmäßig oder bevor Sie auf einen anderen (zentralen) Server pushen 'git gc'. Ohne dies kann das Git Repo (viel) größer werden als es sollte. Ich hatte einmal ein 346 MB Git Repo, das auf 16 MB verkleinert werden kann.
Hendy Irawan
3

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

Sie werden Probleme mit binären Datendateien bekommen (deren gesamter Inhalt könnte und wird sich ändern) und Sie könnten Probleme damit haben, dass der .gitOrdner wirklich groß wird. Ich würde empfehlen, eine .gitignoreDatei einzurichten und nur Textdateien zu sichern, von denen Sie wirklich wissen, dass Sie sie benötigen.

Scott Keck-Warren
quelle
Ich benutze es auch für MySQL-Backups, mit --extended-insert = false. Stellen Sie sicher, dass Sie regelmäßig oder direkt nach dem Festschreiben "git gc" ausführen.
Hendy Irawan
3

Ich habe einmal eine Backup-Lösung entwickelt, die auf Subversion basiert. Es hat zwar ganz gut funktioniert (und git sollte noch besser funktionieren), aber ich denke, es gibt hier bessere Lösungen.

Ich halte rsnapshot für eines der besseren - wenn nicht das bessere. Mit einer guten Nutzung von Hardlink habe ich einen 300-GB-Dateiserver (mit einer halben Million Dateien) mit täglichen, wöchentlichen und monatlichen Backups, die bis zu einem Jahr zurückreichen. Insgesamt belegter Speicherplatz ist nur eine vollständige Kopie + der inkrementelle Teil jeder Sicherung, aber dank Hardlinks habe ich in jeder der Sicherungen eine vollständige "Live" -Verzeichnisstruktur. Mit anderen Worten, auf Dateien kann nicht nur unter daily.0 (der neuesten Sicherung) direkt zugegriffen werden, sondern auch unter daily.1 (gestern) oder week.2 (vor zwei Wochen) und so weiter.

Durch erneutes Freigeben des Sicherungsordners mit Samba können meine Benutzer die Datei aus Sicherungen abrufen, indem sie ihren PC einfach auf den Sicherungsserver verweisen.

Eine andere sehr gute Option ist rdiff-backup , aber da ich gerne Dateien habe, auf die ich immer zugreifen kann, indem ich einfach den Explorer auf \\ Servername öffne, war rsnapshot eine bessere Lösung für mich.

Shodanshok
quelle
Die letzte Veröffentlichung von rdiff-backup ist aus dem Jahr 2009. Ist es äußerst gut gestaltet und erfordert keinerlei Aktualisierung oder handelt es sich lediglich um ein aufgegebenes Projekt?
Mateusz Konieczny
Ich weiß nicht, ob es gepflegt ist, aber es ist im Grunde genommen "erledigt".
Shodanshok
Aus dem Blick auf savannah.nongnu.org/bugs/… geht hervor, dass es noch 2015 einige Aktivitäten gab, aber viele Fehlerberichte werden ignoriert. Ich denke, ich werde es als verlassen klassifizieren.
Mateusz Konieczny
2

Ich hatte die gleiche Idee, um mit Git zu sichern, im Grunde, weil es versionierte Sicherungen ermöglicht. Dann habe ich rdiff-backup gesehen , das diese Funktionalität bietet (und vieles mehr). Es hat eine sehr schöne Benutzeroberfläche (siehe CLI-Optionen). Damit bin ich sehr zufrieden. Das --remove-older-than 2Wist ziemlich cool. Damit können Sie nur Versionen löschen, die älter als 2 Wochen sind. rdiff-backupSpeichert nur Unterschiede von Dateien.

Daniel
quelle
2

Ich bin extrem neu in Git, aber nicht standardmäßig lokal verzweigt und muss explizit auf Remote-Repositorys verschoben werden? Dies war eine unangenehme und unerwartete Überraschung. Will ich nicht, dass mein gesamtes lokales Repo auf dem Server gesichert wird? Lesen Sie das Git-Buch :

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

Für mich bedeutete dies, dass diese lokalen Zweige, wie auch andere Nicht-Git-Dateien auf meinem lokalen Computer, in Gefahr sind, verloren zu gehen, wenn sie nicht regelmäßig mit Nicht-Git-Mitteln gesichert werden. Ich mache das trotzdem, aber es hat meine Vermutungen über das Sichern von "Allem" in meinem Repo gebrochen. Ich würde es lieben, dies zu klären!

Matthew Cornell
quelle
1
Nahezu alles an Git, mit Ausnahme von Fernbedienungen, ist lokal. Das ist so gewollt. Sie können die Daten auf Remotes übertragen und sollten dies insbesondere dann tun, wenn Sie sie wie in diesem Szenario für die Sicherung verwenden. Ja, für Zweige müssen Sie diese explizit verschieben, wenn Sie möchten, dass sie zu einer Fernbedienung hinzugefügt werden. Für die Entwicklung ist dies großartig, da Sie häufig etwas testen möchten, es jedoch nicht erforderlich ist, diesen Testzweig auf unbestimmte Zeit beizubehalten. Sobald Sie haben, was Sie von ihm benötigen, werden Sie es wahrscheinlich zu einem Entwicklerzweig zusammenführen und den Testzweig löschen.
LocalPCGuy
1

Ich fand, dass dies eine gute Methode für meine Entwicklungsboxen ist. Es ändert sie von etwas, das nur auf einem Bereitstellungsendpunkt gesichert werden muss.

Alle Konfigurations- und Paketinstallationsmanifeste werden in Puppet gespeichert, was eine einfache Neuverteilung und Aktualisierung der Konfiguration ermöglicht. Das Puppet-Verzeichnis wird mit git gesichert. Kickstart wird für die Erstbereitstellung verwendet.

Ich verwalte auch ein benutzerdefiniertes YUM-Repository für alle Pakete, die zur Zeit entwickelt werden. Dies hat den zusätzlichen Vorteil, dass alle Pakete, mit denen wir arbeiten, nicht nur als unbeaufsichtigte Binärdateien auf dem lokalen System verbleiben. Jemand ist nicht richtig vorgegangen.

Tim Brigham
quelle
1

Vielleicht möchten Sie sich bei bup on github umsehen, das dazu gedacht ist, git als Backup zu verwenden.

Mcantsin
quelle
Die vorherige Antwort zeigt bereits auf dasselbe Werkzeug (bup). serverfault.com/a/341213/303467 . Irgendwelche Highlights?
Javier
1

Es ist ein Ansatz, der verwendet wird, es macht Sinn.

Keepconf benutzt rsync und git für diesen Job, es ist ein Wrapper über diese Tools, um die Sache einfach zu halten.

Sie benötigen nur einen zentralen Server mit ssh-Schlüsseln, die für den Zugriff auf die Sicherungsserver konfiguriert sind, und ein paar Zeilen in der Konfigurationsdatei. Zum Beispiel ist dies meine eigene Datei, um alle / etc / und die installierten Debian-Pakete zu behalten:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

Damit habe ich das rsync-Backup und das git-Commit.

Rfraile
quelle
0

Meine persönliche Meinung ist, dass dies grundsätzlich alles rückwärts ist. Sie verschieben die Dateien in eine Sicherungslösung, anstatt sie herauszuziehen.

Viel besser wäre es, zuerst die Konfiguration des Servers zu zentralisieren und dann mit so etwas wie einer Marionette herunterzufahren.

Das heißt, es könnte funktionieren, ich glaube nur nicht, dass es so gut wäre.

Versuchen Sie es mit backuppc - es ist ziemlich einfach einzurichten und ehrlich gesagt brillant.

Sirex
quelle
0

Es würde etwas funktionieren, aber zwei Vorbehalte.

  1. Dateizusätze werden beim Festschreiben nicht automatisch erfasst. Verwenden Sie --porcelean om git status, um neue Elemente zu finden, die vor dem Festschreiben hinzugefügt werden müssen.

  2. Warum der Aufwand eines Remote-Mount für die .ssh? Es könnte zerbrechlich sein, aber Sie werden nicht wissen, dass es fehlgeschlagen ist. Verwenden Sie ein nacktes Repository für die Gegenseite mit einem normalen SSH-Schlüssel-Login. Solange das Repository leer ist und Sie nur von einer Quelle aus pushen, funktioniert es garantiert ohne Zusammenführung.

Andrew
quelle