GIT jako narzędzie do tworzenia kopii zapasowych


101

Na serwerze zainstaluj git

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

Następnie przejdź /.git/do dysku sieciowego (SAN, NFS, Samba cokolwiek) lub innego dysku. Użyj zadania cron co godzinę / dzień itp., Aby zaktualizować zmiany. Katalog .git zawierałby wersjonowaną kopię wszystkich plików serwera (z wyjątkiem niepotrzebnych / skomplikowanych, takich jak / proc, / dev itp.)

Dla nie-ważne serwerze rozwoju, gdzie nie chcesz kłopotów / koszty ustawienie go na odpowiednim systemie zapasowym, a gdzie kopie byłyby tylko dla wygody (IE nie potrzebują do wykonania kopii zapasowej tego serwera, ale byłoby zaoszczędzić jakiś czas, jeśli coś pójdzie nie tak), czy może to być prawidłowe rozwiązanie do tworzenia kopii zapasowych, czy może po prostu przewróci się w kupie kupy?


3
nie błyszczy się przy użyciu podobnego pomysłu?
B14D3,

@ B14D3 Myślę, że sparkleshare jest czymś w rodzaju dropboxa, ale przyjrzę się temu
Smudge

2
masz rację, ale używa git, aby zrobić coś typu buckup (kopiowanie na kilka komputerów i kontrolowanie wersji plików);)
B14D3

Dużym problemem jest to, że nie ma centralnego sterowania - musisz mieć bezpośredni dostęp (ssh) do maszyny, aby wykonać dowolną formę konserwacji lub sprawdzania poprawności kopii zapasowej. Zawsze uważam, że instalowanie aplikacji na skrzynkach, które mają być archiwizowane, a administrowanie nimi z centralnej lokalizacji to znacznie większa wygrana.
hafichuk

@hafichuk Z narzędziami takimi jak Puppet / Chef nie jest to taki duży problem, ale rozumiem, o co ci chodzi.
Smudge

Odpowiedzi:


88

Nie jesteś głupią osobą. Używanie gitjako mechanizmu tworzenia kopii zapasowych może być atrakcyjne i pomimo tego, co powiedzieli inni ludzie, gitdziała dobrze z plikami binarnymi. Przeczytaj tę stronę z Git Book, aby uzyskać więcej informacji na ten temat. Zasadniczo, ponieważ gitnie używa mechanizmu pamięci delta, tak naprawdę nie obchodzi go, jak wyglądają twoje pliki (ale użyteczność git diffjest dość niska w przypadku plików binarnych z konfiguracją standardową).

Największym problemem związanym z używaniem gitkopii zapasowej jest to, że nie zachowuje ona większości metadanych systemu plików. W szczególności gitnie rejestruje:

  • grupy plików
  • właściciele plików
  • uprawnienia do plików (inne niż „czy to plik wykonywalny”)
  • rozszerzone atrybuty

Możesz rozwiązać ten problem, pisząc narzędzia do jawnego zapisywania tych informacji w repozytorium, ale może to być trudne.

Wyszukiwanie w Google metadanych kopii zapasowej git daje szereg wyników, które wydają się warte przeczytania (w tym niektóre narzędzia, które już próbują zrekompensować problemy, które tu przedstawiłem).

etckeeper został opracowany do tworzenia kopii zapasowych /etci rozwiązuje wiele z tych problemów.


15
+1 za wzmiankę o listach ACL / uprawnieniach
Larry Silverman,

22
Git nie przechowuje również pustych katalogów.
Flimm

i jest również do bani dla śledzenia przenoszenia / zmiany nazwy pliku w historii.
cregox

1
Ponieważ git nie radzi sobie dobrze z plikami binarnymi, możesz również zajrzeć do załącznika git , który pomaga to zrobić lepiej. Zmienia to jednak nieco pojęcie git.
Wouter Verhelst

1
moim zdaniem możesz używać git do tworzenia kopii zapasowych danych, ale nie całych serwerów
EKanadily

21

Nie korzystałem z niego, ale możesz spojrzeć na bup, który jest narzędziem do tworzenia kopii zapasowych opartym na git.


Nigdy wcześniej nie widziałem bup, wygląda interesująco
Smudge

1
Ostatnio zacząłem używać BUP, zaledwie kilka dni przed awarią dysku twardego;) Przywracanie poszło dobrze, więc zalecane!
André Paramés,

1
@ AndréParamés, więc to, co mówisz, to zaraz po zainstalowaniu bup, twój dysk twardy się zawiesił ... mmmmhh ... :) tylko żartuję
hofnarwillie

12

Może to być prawidłowe rozwiązanie do tworzenia kopii zapasowych, etckeeper opiera się na tym pomyśle. Ale miej oko na .gituprawnienia do katalogu, w przeciwnym razie wypychanie /etc/shadowmoże być odczytane w .gitkatalogu.


11

Chociaż technicznie możesz to zrobić, postawiłbym dwa zastrzeżenia:

1, Używasz źródłowego systemu kontroli wersji dla danych binarnych. Dlatego używasz go do czegoś, do czego nie został zaprojektowany.

2, martwię się o twój proces programowania, jeśli nie masz procesu (dokumentacji lub automatyzacji) do budowy nowej maszyny. Co jeśli trafisz, kup autobus, kto by wiedział, co robić i co było ważne?

Odzyskiwanie po awarii jest ważne, jednak lepiej zautomatyzować (skrypty) konfigurację nowego pudełka programistycznego niż po prostu wykonać kopię zapasową wszystkiego. Oczywiście użyj git do skryptu / dokumentacji, ale nie do każdego pliku na komputerze.


4
Wszystkie pudełka programistyczne pochodzą z plików KickStart, a tak naprawdę średnie pudełko trwa około 2 lub 3 miesięcy, zanim zostanie ponownie zbudowane. Ale ludzie zmieniają konfiguracje i robią różne rzeczy, przebudowujemy pudła, a ludzie mówią: „hej, wiem, że nie poddałem go kontroli źródła, ale miałem trochę gówna na tym pudełku” i śmieję się z nich, że są głupi. Wszystko wokół, dobre czasy. Dane binarne byłyby suką, to coś, co całkowicie przeoczyłem pod prysznicem.
Smudge

Pochwalam twoje podejście do tych, którzy nie przestrzegają podstawowych zasad. Osobiście mam podobną sytuację do ciebie, ale mam repozytorium git, które łączy wszystkie pliki konfiguracyjne, które mogą być ważne, a nie łapać wszystko. Plus dokument TXT z krokami konfiguracji.
Phil Hannent,

1
Myślę, że git działa całkiem dobrze w przypadku plików binarnych, vide większość repozytorium Google Android to repozytoria git wstępnie skompilowanych plików wykonywalnych.
user377178,

6

Używam git jako kopii zapasowej dla mojego systemu Windows, i było to niezwykle przydatne. W dolnej części postu pokazuję skrypty, których używam do konfiguracji w systemie Windows. Używanie git jako kopii zapasowej dla dowolnego systemu zapewnia 2 duże zalety:

  1. W przeciwieństwie do komercyjnych rozwiązań często używających własnego zastrzeżonego formatu, twoja kopia zapasowa jest w formacie open source, który jest szeroko obsługiwany i bardzo dobrze udokumentowany. Zapewnia to pełną kontrolę nad danymi. Bardzo łatwo jest sprawdzić, które pliki uległy zmianie i kiedy. Jeśli chcesz obciąć swoją historię, możesz to zrobić. Chcesz wymazać coś ze swojej historii? Nie ma problemu. Odzyskanie wersji pliku jest tak proste, jak każde polecenie git.
  2. Tyle kopii lustrzanych, ile chcesz, i wszystkie mogą mieć niestandardowe czasy tworzenia kopii zapasowych. Otrzymasz lokalne lustro, które nie jest obciążone powolnym ruchem internetowym, a tym samym daje (1) możliwość częstszych kopii zapasowych w ciągu dnia i (2) szybki czas przywracania. (Częste kopie zapasowe to ogromny plus, ponieważ uważam, że najwięcej czasu tracę dokument z powodu błędu użytkownika. Na przykład twoje dziecko przypadkowo nadpisuje dokument, nad którym pracował przez ostatnie 5 godzin.) zdalne lustro, które zapewnia ochronę danych w przypadku lokalnej katastrofy lub kradzieży. Przypuśćmy, że chcesz tworzyć kopie zapasowe zdalnego lustra w niestandardowym czasie, aby zaoszczędzić przepustowość Internetu? Nie ma problemu.

Konkluzja: Kopia zapasowa git zapewnia niewiarygodne możliwości kontrolowania sposobu tworzenia kopii zapasowych.

Skonfigurowałem to w moim systemie Windows. Pierwszym krokiem jest utworzenie lokalnego repozytorium git, w którym będziesz zatwierdzać wszystkie swoje lokalne dane. Zalecam użycie lokalnego drugiego dysku twardego, ale korzystanie z tego samego dysku twardego będzie działało (ale spodziewane jest, że wciśniesz go gdzieś zdalnie lub inaczej wkręcisz się, jeśli dysk twardy umrze).

Najpierw musisz zainstalować cygwin (z rsync), a także zainstalować git dla Windows: http://git-scm.com/download/win

Następnie utwórz lokalne repozytorium git (uruchom tylko raz):

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%

Następnie mamy nasze opakowanie skryptu kopii zapasowej, które będzie regularnie wywoływane przez program planujący systemu Windows:

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

Następnie mamy sam skrypt kopii zapasowej wywoływany przez opakowanie:

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%

Mamy plik exclude-from.txt, w którym wszystkie pliki ignorujemy:

exclude-from.txt:

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

Musisz udać się na dowolne repozytorium i zrobić na nich „git init --bare”. Możesz przetestować skrypt, wykonując skrypt kopii zapasowej. Zakładając, że wszystko działa, przejdź do Windows Scheduler i wskaż cogodzinną kopię zapasową w kierunku pliku vbs. Następnie co godzinę będziesz mieć historię swojego komputera. Jest to niezwykle wygodne - każdy przypadkowo usuwa fragment tekstu i tęsknisz? Po prostu sprawdź swoje repozytorium git.


Ciekawe - czy będzie działać również w przypadku wolnych lub niestandardowych dysków sieciowych, takich jak emulowane przez NetDrive lub Expandrive? Uważam, że większość programów do tworzenia kopii zapasowych nie działa z tymi dyskami sieciowymi. Również rzeczy stają się boleśnie powolne i mają tendencję do przekraczania limitu czasu, jeśli chcę wyświetlić listę wszystkich plików w kopii zapasowej i wyodrębnić pojedyncze pliki. Czy git jest w stanie rozwiązać te problemy?
JustAMartin

@JustAMartin Nigdy nie testowałem tego na dyskach sieciowych, więc nie mogę powiedzieć. Gdy pliki są w repozytorium git, git jest bardzo wydajny.
user64141,

4

Nie jest to zły pomysł, ale myślę, że należy postawić 2 czerwone flagi:

  • Jeśli dysk twardy zawiedzie, stracisz wszystko, jeśli nie wypychasz swojego zatwierdzenia na inny serwer / dysk. (Wydarzenie, jeśli masz na to plan, wolę wspomnieć.)

... ale nadal może być dobrym wsparciem dla rzeczy związanych z korupcją. Lub tak jak powiedziałeś, jeśli folder .git / jest gdzieś indziej.

  • Ta kopia zapasowa zawsze będzie się powiększać. Domyślnie nie ma przycinania, rotacji ani niczego.

... Może więc być konieczne powiedzenie kronice dodawania tagów, a następnie upewnienie się, że zatwierdzone pliki, które nie są oznaczone, zostaną wyczyszczone.


Prawdopodobnie zamontowalibyśmy katalog .git na zdalnym serwerze, chociaż zwykłe rm -Rf /spowodowałoby to pewne problemy. Nasz obecny system tworzenia kopii zapasowych przechowuje dane przez 2 lata lub 50 wersji (w zależności od tego, co nastąpi wcześniej), więc nasza kopia zapasowa stale się powiększa. Ale podoba mi się pomysł dodawania tagów, moglibyśmy mieć tagi „codzienne”, „cotygodniowe” itp.
Smudge

+1 za wciąż rosnące zapotrzebowanie na miejsce
hafichuk

@sam git stale rośnie. Nie można przyciąć historii starszej niż N lat. Podejrzewam, że twój obecny system to robi.
rds

1
Jeśli chodzi o zwiększenie rozmiaru, rób git gc regularnie lub zanim przełączysz się na inny (centralny) serwer. Bez tego git repo może stać się (znacznie) większy niż powinien. Kiedyś miałem 346 MB repozytorium git, które może się zmniejszyć do 16 MB.
Hendy Irawan

3

Nie próbowałem tego z pełnym systemem, ale używam go do tworzenia kopii zapasowych MySQL (z opcją --skip-Extended-Insert) i to naprawdę działa dobrze dla mnie.

Będziesz mieć problem z plikami danych binarnych (cała ich zawartość może i będzie się zmieniać) i możesz mieć problemy z .gitpowiększeniem się folderu. Polecam utworzenie .gitignorepliku i tworzenie kopii zapasowych tylko plików tekstowych, których naprawdę potrzebujesz.


Używam go również do tworzenia kopii zapasowych MySQL z opcją --extended-insert = false. Pamiętaj, aby „git gc” regularnie lub zaraz po zatwierdzeniu.
Hendy Irawan


3

Kiedyś opracowałem rozwiązanie do tworzenia kopii zapasowych oparte na subversion. Chociaż działał całkiem dobrze (a git powinien działać jeszcze lepiej), myślę, że są tutaj lepsze rozwiązania.

Uważam rsnapshot być jeden z lepszych - jeśli nie lepiej. Przy dobrym użyciu twardego łącza mam serwer plików o pojemności 300 GB (z pół milionem plików) z codzienną, cotygodniową i miesięczną kopią zapasową sięgającą nawet jednego roku. Całkowite wykorzystane miejsce na dysku to tylko jedna pełna kopia + przyrostowa część każdej kopii zapasowej, ale dzięki linkom twardym mam pełną „katalog” na żywo w każdej z kopii zapasowych. Innymi słowy, pliki są dostępne bezpośrednio nie tylko w dzienniku. 0 (najnowsza kopia zapasowa), ale nawet w dzienniku. 1 (wczoraj) lub co tydzień. 2 (dwa tygodnie temu) i tak dalej.

Udostępniając folder kopii zapasowej Sambie, moi użytkownicy mogą pobrać plik z kopii zapasowej, po prostu wskazując swój komputer na serwer kopii zapasowej.

Inną bardzo dobrą opcją jest rdiff-backup , ale ponieważ lubię mieć dostęp do plików zawsze po prostu kierując Explorer do \\ nazwa_serwera, rsnapshot było dla mnie lepszym rozwiązaniem.


Ostatnia wersja rdiff-backup pochodzi z 2009 roku. Czy jest wyjątkowo dobrze zaprojektowana i nie wymaga żadnej aktualizacji, czy jest to po prostu opuszczony projekt?
Mateusz Konieczny

Nie wiem, czy jest to obsługiwane, ale w zasadzie jest „gotowe”.
shodanshok

Patrząc na savannah.nongnu.org/bugs/… wydaje się, że w 2015 r. Była jakaś aktywność, ale wiele zgłoszeń błędów jest ignorowanych. Myślę, że sklasyfikuję to jako porzucone.
Mateusz Konieczny

2

Miałem ten sam pomysł, aby wykonać kopię zapasową za pomocą git, głównie dlatego, że pozwala on na tworzenie kopii zapasowych w wersji. Potem zobaczyłem rdiff-backup , który zapewnia tę funkcjonalność (i wiele więcej). Ma naprawdę ładny interfejs użytkownika (spójrz na opcje CLI). Jestem z tego całkiem zadowolony. To --remove-older-than 2Wjest całkiem fajne. Pozwala tylko usunąć wersje starsze niż 2 tygodnie. rdiff-backupprzechowuje tylko różnice plików.


2

Jestem bardzo nowy w Git, ale domyślnie nie mam lokalnych oddziałów i muszę zostać jawnie przekazany do zdalnych repozytoriów? To była nieprzyjemna i nieoczekiwana niespodzianka. W końcu, czy nie chcę, aby wszystkie moje lokalne repozytoria były „archiwizowane” na serwerze? Czytanie książki git :

Twoje lokalne oddziały nie są automatycznie synchronizowane z pilotami, do których piszesz - musisz jawnie przekazać gałęzie, które chcesz udostępnić. W ten sposób możesz używać prywatnych oddziałów do pracy, której nie chcesz udostępniać, i przesuwać tylko gałęzie tematyczne, z którymi chcesz współpracować.

Dla mnie oznaczało to, że te lokalne oddziały, podobnie jak inne pliki inne niż git na moim komputerze lokalnym, są narażone na ryzyko utraty, chyba że będą regularnie tworzone kopie zapasowe za pomocą innych niż git sposobów. I tak to robię, ale złamało to moje założenia, że ​​git „tworzy kopię zapasową wszystkiego” w moim repozytorium. Chciałbym wyjaśnić na ten temat!


1
Prawie wszystko o git, z wyjątkiem pilotów, ma charakter lokalny. To jest z założenia. Możesz przekazywać rzeczy do pilotów, a powinno się to robić, szczególnie jeśli są używane do tworzenia kopii zapasowych, jak w tym scenariuszu. W przypadku gałęzi ponownie tak, musisz je jawnie wypchnąć, jeśli chcesz je dodać do pilota. W przypadku programowania jest to świetne, ponieważ często chcesz coś przetestować, ale nie ma potrzeby zachowania tej gałęzi testowej na czas nieokreślony. Gdy zdobędziesz z niego to, czego potrzebujesz, prawdopodobnie połączysz go z gałęzią programistów i usuniesz gałąź testową.
LocalPCGuy,

1

Uważam, że jest to dobra metodologia dla moich deweloperów. Zmienia je z czegoś, co wymaga kopii zapasowej, do samego punktu końcowego wdrażania.

Wszystkie manifesty konfiguracji i instalacji pakietu są przechowywane w Puppet, umożliwiając łatwe ponowne wdrożenie i aktualizacje konfiguracji. Kopia zapasowa katalogu Puppet jest wykonywana za pomocą git. Kickstart służy do pierwszego wdrożenia.

Utrzymuję również niestandardowe repozytorium YUM dla wszystkich rozwijanych pakietów. Ma to tę dodatkową zaletę, że wszystkie pakiety, z którymi pracujemy, nie są po prostu pozostawione jako nienadzorowane pliki binarne w systemie lokalnym - jeśli tak się stanie, a pliki zostaną zniszczone. Ktoś nie przestrzegał właściwej procedury.



1

Jest to podejście, które jest stosowane, ma sens.

Keepconf używa rsync i git do tego zadania, jest to opakowanie tych narzędzi, aby ułatwić sobie zadanie.

Potrzebujesz tylko centralnego serwera z kluczami ssh skonfigurowanymi do uzyskania dostępu do serwerów zapasowych i kilkoma liniami w pliku konfiguracyjnym. Na przykład jest to mój własny plik do przechowywania wszystkich / etc / i zainstalowanych pakietów debian:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

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

Dzięki temu mam kopię zapasową rsync i git commit.


0

Moim osobistym zdaniem jest to w zasadzie wszystko wstecz. Wypychasz pliki do kopii zapasowej, a nie wyciągasz je.

Znacznie lepszym rozwiązaniem byłoby scentralizowanie konfiguracji serwera, a następnie ściągnięcie go w dół, używając czegoś w rodzaju marionetki.

To powiedziawszy, może działać, po prostu nie sądzę, że byłoby tak dobrze.

Spróbuj zajrzeć do backuppc - jest dość łatwy w konfiguracji i szczerze mówiąc genialny.


0

To by działało trochę, ale dwa zastrzeżenia.

  1. Dodania plików nie będą pobierane automatycznie podczas zatwierdzania. Użyj --porcelean om git status, aby znaleźć nowe rzeczy do dodania przed wykonaniem zatwierdzenia.

  2. Dlaczego kłopot ze zdalnym montażem do .ssh? To może być kruche Bd, nie będziesz wiedział, że to się nie udało. Użyj zdalnego repozytorium na drugim końcu z normalnym loginem klucza ssh. Tak długo, jak repozytorium jest puste i działa tylko z jednego źródła, gwarantuje się, że nie zostanie wykonane połączenie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.