Vraag GIT als een back-uptool


Installeer git op een server

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

Pak dan /.git/ om naar een netwerkstation (SAN, NFS, Samba) of een andere schijf te wijzen. Gebruik elk uur / dag etc. een cron-taak om de wijzigingen bij te werken. De .git-map zou een versie-exemplaar van alle serverbestanden bevatten (met uitzondering van de nutteloze / gecompliceerde exemplaren zoals / proc, / dev enz.)

Voor een niet-belangrijke ontwikkelserver waar ik niet de moeite / kosten wil hebben om het in te stellen op een goed back-upsysteem, en waar back-ups alleen maar voor het gemak zijn (I.E. we doen het niet nodig hebben om een ​​back-up te maken van deze server, maar het zou wat tijd besparen als het mis zou gaan), zou dit een geldige back-upoplossing kunnen zijn of zal het gewoon vallen in een grote stapel kak?


88
2017-12-15 12:10


oorsprong


fonkelt niet met hetzelfde idee ?? - B14D3
@ B14D3 Ik denk dat sparkleshare meer een soort dropbox-achtig ding is, maar ik zal het bekijken - Smudge
je hebt gelijk, maar het gebruikt git om een ​​soort van buckup-ding te maken (kopiëren naar verschillende pc's en besturingsversies van bestanden);) - B14D3
Het grote probleem hiermee is dat er geen centrale besturing is - u moet directe (ssh) toegang tot de machine hebben om elke vorm van onderhouds- of back-upvalidatie uit te voeren. Ik vind altijd het installeren van een app op de kaders waarvan een back-up moet worden gemaakt en ze vanaf een centrale locatie beheren, is een veel grotere overwinning. - hafichuk
@hafichuk Met tools als Puppet / Chef is het niet zo'n groot probleem, maar ik begrijp wat je bedoelt. - Smudge


antwoorden:


Je bent geen dwaze persoon. Gebruik makend van git als een back-up mechanisme kan aantrekkelijk zijn, en ondanks wat andere mensen hebben gezegd, git werkt prima met binaire bestanden. Lezen deze pagina uit het Git Book voor meer informatie over dit onderwerp. Kortom, sindsdien git gebruikt geen delta-opslagmechanisme, het maakt niet echt uit wat uw bestanden zien eruit (maar het nut van git diff is vrij laag voor binaire bestanden met een voorraadconfiguratie).

Het grootste probleem met het gebruik git voor back-up is dat het de meeste metadata van het bestandssysteem niet bewaart. In het bijzonder, git neemt niet op:

  • bestandsgroepen
  • bestandseigenaren
  • bestandsrechten (anders dan "is dit uitvoerbare bestand")
  • uitgebreide attributen

Je kunt dit oplossen door gereedschap te schrijven om deze informatie expliciet in je repository op te nemen, maar het kan lastig zijn om dit goed te krijgen.

Een Google-zoekopdracht voor git backup metadata levert een aantal resultaten op die de moeite van het lezen waard lijken (inclusief enkele hulpmiddelen die al proberen om de problemen die ik hier heb opgeworpen te compenseren).

etckeeper is ontwikkeld om een ​​back-up te maken /etc en lost veel van deze problemen op.


78
2017-12-15 17:25



+1 voor het vermelden van ACL's / machtigingen - Larry Silverman
Git slaat ook geen lege mappen op. - Flimm
en het is ook heel jammer dat het bestand verplaatst / hernoemd kan worden, door de geschiedenis heen. - cregox
Omdat git niet goed omgaat met binaire bestanden, wil je misschien ook kijken git bijlage, dat helpt dat beter te doen. Het verandert echter wel het idee van wat GIT is. - Wouter Verhelst
Ik ben van mening dat je git kunt gebruiken om een ​​back-up van gegevens te maken, maar niet voor hele servers - EKanadily


Ik heb het niet gebruikt, maar je zou kunnen kijken bup wat een back-up tool is gebaseerd op git.


20
2017-12-15 13:27



Nog nooit bup gezien, ziet er interessant uit - Smudge
Ik ben onlangs begonnen met het gebruik van bup, slechts een paar dagen voordat mijn harde schijf crashte;) Herstellen ging prima, dus aanbevolen! - André Paramés
@ AndréParamés dus wat je zegt is net nadat je bup hebt geïnstalleerd je harde schijf is gecrasht ... mmmmhh ... :) grapje - hofnarwillie


Het kan een geldige back-upoplossing zijn, etckeeper is gebaseerd op dit idee. Maar houd de .git directory-permissies anders pushen /etc/shadow kan leesbaar zijn in de .git directory.


12
2017-12-15 12:18





Hoewel je technisch gezien dit zou kunnen doen, zou ik er twee kanttekeningen bij maken:

1, U gebruikt een bronversiebesturingssysteem voor binaire gegevens. Je gebruikt het daarom voor iets waarvoor het niet is ontworpen.

2, ik maak me zorgen over je ontwikkelingsproces als je geen proces (documentatie of geautomatiseerd) hebt voor het bouwen van een nieuwe machine. Wat als je geraakt bent, een bus kopen, wie weet wat te doen en wat was belangrijk?

Noodherstel is belangrijk, maar het is beter om de setup van een nieuwe ontwikkelbox te automatiseren (script) dan alleen een back-up te maken van alles. Natuurlijk gebruikt u git voor uw script / documentatie, maar niet voor elk bestand op een computer.


11
2017-12-15 13:45



Ontwikkelingsdozen zijn allemaal afkomstig van KickStart-bestanden, en in werkelijkheid duurt de gemiddelde doos ongeveer 2 of 3 maanden voordat deze opnieuw wordt gebouwd. Maar mensen veranderen van configs en doen dingen, we bouwen de dozen opnieuw op en mensen zeggen "hey, ik weet dat ik het niet in bronbeheer heb gestopt, maar ik had wat stront op die doos" en ik lach om hen omdat ik stom ben. Over het algemeen goede tijden. Binaire gegevens zouden een bitch zijn, het is iets dat ik volledig over het hoofd heb gezien terwijl ik onder de douche stond. - Smudge
Ik juich je houding toe tegenover mensen die fundamentele principes niet volgen. Persoonlijk heb ik een vergelijkbare situatie als jij, maar ik heb een git-repository die koppelingen bevat in alle configuratiebestanden die misschien belangrijk zijn in plaats van alles te vangen. Plus een txt-document met installatiestappen. - Phil Hannent
Ik denk dat Git vrij goed werkt voor binaire bestanden, zie Google Android's grootste deel van de repo zijn git-archieven van vooraf gebouwde uitvoerbare bestanden. - user377178


Ik gebruik git als back-up voor mijn Windows-systeem en het is ongelooflijk handig geweest. Onderaan de post toon ik de scripts die ik gebruik om te configureren op een Windows-systeem. Het gebruik van git als back-up voor elk systeem biedt 2 grote voordelen:

  1. In tegenstelling tot commerciële oplossingen gebruiken vaak hun eigen formaat, uw back-up is in een open source-indeling die breed ondersteund en zeer goed gedocumenteerd is. Dit geeft u volledige controle over uw gegevens. Het is heel eenvoudig om te zien welke bestanden zijn gewijzigd en wanneer. Als u uw geschiedenis wilt afkappen, kunt u dat ook doen. Wilt u iets uit uw geschiedenis wissen? Geen probleem. Een versie van uw bestand terughalen is net zo eenvoudig als elke git-opdracht.
  2. Zo veel of zo weinig mirrors als u wilt, en iedereen kan aangepaste back-uptijden hebben. U krijgt uw lokale spiegel, die niet wordt belast door traag internetverkeer, en dus (1) de mogelijkheid biedt om frequenter back-ups te maken gedurende de dag en (2) een snelle hersteltijd. (Frequente back-ups zijn een groot pluspunt, omdat ik de meeste tijd heb om een ​​document kwijt te raken door een gebruikersfout. Uw kind overschrijft bijvoorbeeld per ongeluk een document waaraan hij de afgelopen 5 uur heeft gewerkt.) Maar u krijgt uw document wel externe spiegel, die het voordeel biedt van gegevensbescherming in geval van een lokale ramp of diefstal. En stel dat u wilt dat uw externe spiegel een back-up maakt op het aangepaste tijdstip om uw internetbandbreedte te besparen? Geen probleem.

Kort gezegd: een geavanceerde back-up geeft u ongelofelijke hoeveelheden stroom bij het beheren van uw back-ups.

Ik heb dit op mijn Windows-systeem geconfigureerd. De eerste stap is om de lokale git repo aan te maken waar je al je lokale data aan commit. Ik raad het gebruik van een lokale tweede harde schijf aan, maar het gebruik van dezelfde harde schijf zal werken (maar het is de verwachting dat je dit ergens ergens anders naartoe zal duwen, anders wordt je genaaid als de harde schijf sterft).

Je moet eerst cygwin (met rsync) installeren en ook git voor Windows installeren: http://git-scm.com/download/win

Maak vervolgens je lokale git repo (slechts één keer draaien):

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%

Vervolgens hebben we onze back-up script-wrapper, die regelmatig door Windows Scheduler wordt genoemd:

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

Vervolgens hebben we het back-up script zelf dat de wrapper noemt:

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%

We hebben het bestand exclude-from.txt, waarin we alle bestanden negeren:

exclusief-from.txt:

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

Je moet naar elke remote repos gaan en een 'git init --bare' doen. U kunt het script testen door het back-up script uit te voeren. Ervan uitgaande dat alles werkt, gaat u naar Windows Scheduler en wijst u een uurlijkse back-up naar het vbs-bestand. Daarna heb je voor elk uur een git-geschiedenis van je computer. Het is uitermate handig - verwijder elke per ongeluk een stuk tekst en mis het? Controleer gewoon je git repository.


6
2018-03-21 17:10



Gewoon nieuwsgierig: werkt het ook voor langzame of niet-standaard netwerkstations, zoals die worden geëvenaard door NetDrive of Expandrive? Ik vind dat de meeste back-upsoftware niet werkt met deze netwerkstations. Ook worden dingen pijnlijk traag en hebben de neiging om een ​​time-out te geven, als ik alle bestanden in de back-up wil weergeven en individuele bestanden wil extraheren. Kan git deze problemen oplossen? - JustAMartin
@JustAMartin Ik heb het nog nooit getest op netwerkstations, dus ik kan het niet zeggen. Zodra je de bestanden IN een git repo hebt, is git zeer efficiënt. - user64141


Nou, het is geen slecht idee, maar ik denk dat er 2 rode vlaggen zijn om te verhogen:

  • Als de harde schijf niet werkt, verliest u alles als u uw commit niet naar een andere server / drive pusht. (Evenement als je een plan hebt, ik noem het liever.)

... maar toch kan het een goede back-up zijn voor zaken die met corruptie te maken hebben. Of zoals je zei, als de .git / folder ergens anders is.

  • Deze back-up neemt altijd toe in omvang. Er is standaard geen snoeien of roteren of iets anders.

... Het kan dus zijn dat u uw cronjob moet vertellen om tags toe te voegen en ervoor moet zorgen dat commit die niet zijn getagd, wordt opgeschoond.


4
2017-12-15 13:40



We zouden de .git-directory waarschijnlijk op een externe server aankoppelen, hoewel de clasic rm -Rf / zou ons wat problemen veroorzaken. Ons huidige back-upsysteem houdt spullen bij voor 2 jaar of 50 versies (wat het laatst gebeurt), dus onze back-up neemt sowieso toe. Maar ik hou van het idee om tags toe te voegen, we kunnen "dagelijkse", "wekelijkse" etc. tags hebben - Smudge
+1 voor steeds groeiende ruimtevereisten - hafichuk
@sam git groeit voortdurend. Je kunt niet de geschiedenis snoeien die ouder is dan N jaar. Ik neem aan dat je huidige systeem dat wel doet. - rds
Wat betreft het vergroten van de omvang, doe alsjeblieft regelmatig 'git gc' of voordat je naar een andere (centrale) server pusht. Zonder dit kan de git repo (veel) groter worden dan zou moeten. Ik had ooit een 346 MB git repo die kan krimpen tot 16 MB. - Hendy Irawan


Ik heb het nog niet geprobeerd met een volledig systeem, maar ik gebruik het voor mijn MySQL-back-ups (met de optie -skip-extended-insert) en het heeft echt goed gewerkt voor mij.

Je zult een probleem tegenkomen met binaire gegevensbestanden (hun volledige inhoud kan en zal veranderen) en je zou problemen kunnen hebben met de .git map wordt erg groot. Ik zou aanraden om een .gitignore bestand en maak alleen een back-up van tekstbestanden waarvan u echt weet dat u ze nodig hebt.


3
2017-12-15 13:23



Ik gebruik het ook voor MySQL-backups, met --extended-insert = false. Zorg ervoor dat je "git gc" regelmatig gebruikt of direct na commit. - Hendy Irawan
Zien Is back-up van een MySQL-database in Git een goed idee? - Michael Hampton♦


Ik heb ooit een back-upoplossing ontwikkeld op basis van subversion. Hoewel het best goed werkte (en het zou nog beter moeten werken), denk ik dat er hier betere oplossingen zijn.

ik overweeg rsnapshot om een ​​van de betere te zijn - zo niet de beter. Met een goed gebruik van de harde koppeling, heb ik een 300 GB fileserver (met een half miljoen bestanden) met dagelijkse, wekelijkse en maandelijkse back-ups tot een jaar. De totale gebruikte schijfruimte is slechts één volledige kopie + het incrementele deel van elke back-up, maar dankzij hardlinks heb ik een compleet "live" directorystructuur in elk van de back-ups. Met andere woorden, bestanden zijn niet alleen direct toegankelijk onder daily.0 (de meest recente back-up), maar zelfs in daily.1 (yestarday) of weekly.2 (twee weken geleden), enzovoort.

De back-upmap opnieuw delen met Samba, mijn gebruikers kunnen het bestand uit back-ups halen door eenvoudigweg hun pc naar de back-upserver te wijzen.

Een andere zeer goede optie is rdiff-backup, maar omdat ik bestanden altijd altijd toegankelijk wil houden door simpelweg onder de naam Explorer naar \\ servernaam te gaan, was rsnapshot een betere oplossing voor mij.


3
2018-03-21 20:01



Laatste release van rdiff-backup is van 2009. Is het extreem goed ontworpen en vereist het helemaal geen update of is het gewoon een verlaten project? - Mateusz Konieczny
Ik weet niet of het goedgemaakt is, maar het is eigenlijk "klaar". - shodanshok
Van kijken naar savannah.nongnu.org/bugs/... het lijkt erop dat er enige activiteit was in 2015, maar veel bugrapporten worden genegeerd. Ik denk dat ik het als een verlaten zal classificeren. - Mateusz Konieczny