एक बैकअप टूल के रूप में जीआईटी


101

सर्वर पर, git इंस्टॉल करें

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

फिर /.git/एक नेटवर्क ड्राइव (सैन, एनएफएस, सांबा जो भी हो) या अलग-अलग डिस्क पर इंगित करें। परिवर्तनों को अपडेट करने के लिए हर घंटे / दिन आदि में क्रॉन जॉब का उपयोग करें। .It निर्देशिका में सभी सर्वर फ़ाइलों की एक प्रतिलिपि प्रतिलिपि होगी (बेकार / जटिल लोगों जैसे / प्रोक, / देव आदि को छोड़कर)।

एक गैर-महत्वपूर्ण विकास सर्वर के लिए जहां मैं इसे उचित बैकअप सिस्टम पर स्थापित करने की परेशानी / लागत नहीं चाहता हूं, और जहां बैकअप केवल सुविधा के लिए होगा (IE हमें इस सर्वर का बैकअप लेने की आवश्यकता नहीं है लेकिन यह बचाएगा कुछ समय अगर चीजें गलत हो गईं), क्या यह एक वैध बैकअप समाधान हो सकता है या क्या यह सिर्फ शिकार के बड़े ढेर में गिर जाएगा?


3
स्पार्कलेश समान विचार का उपयोग नहीं करता है ??
14:14 बजे B14D3

@ B14D3 मुझे लगता है कि sparkleshare ड्रॉपबॉक्स प्रकार thingy का एक प्रकार के और अधिक है, लेकिन मैं इस पर गौर करेंगे
धब्बा

2
आप सही कह रहे हैं, लेकिन यह कुछ प्रकार की बकलप चीज़ बनाने के लिए (कई पीसी और फ़ाइलों के नियंत्रण संस्करणों की नकल करने के लिए) का उपयोग कर रहा है;)
B14D3

इसके साथ बड़ी समस्या यह है कि कोई केंद्रीय नियंत्रण नहीं है - आपको किसी भी प्रकार के रखरखाव या बैकअप सत्यापन के लिए मशीन के प्रत्यक्ष (ssh) उपयोग की आवश्यकता है। मुझे हमेशा बॉक्स पर एक ऐप इंस्टॉल करने की सुविधा मिलती है, फिर उन्हें केंद्रीय स्थान से प्रबंधित करना एक बहुत बड़ी जीत है।
हैफिकुक

@hafichuk कठपुतली / रसोइये जैसे उपकरणों के साथ यह इतना बड़ा मुद्दा नहीं है, लेकिन मैं आपकी बात देखता हूं।
स्मज करेंगे

जवाबों:


88

तुम एक मूर्ख व्यक्ति नहीं हो। gitबैकअप तंत्र के रूप में उपयोग करना आकर्षक हो सकता है, और अन्य लोगों ने जो भी कहा है, उसके बावजूद gitबाइनरी फ़ाइलों के साथ ठीक काम करता है। इस विषय पर अधिक जानकारी के लिए Git Book से इस पृष्ठ को पढ़ें । असल में, चूंकि gitडेल्टा भंडारण तंत्र का उपयोग नहीं कर रहा है, यह वास्तव में परवाह नहीं करता है कि आपकी फाइलें कैसी दिखती हैं (लेकिन git diffस्टॉक कॉन्फ़िगरेशन के साथ बाइनरी फ़ाइलों के लिए उपयोगिता बहुत कम है)।

gitबैकअप के लिए उपयोग करने के साथ सबसे बड़ा मुद्दा यह है कि यह अधिकांश फाइल सिस्टम मेटाडेटा को संरक्षित नहीं करता है। विशेष रूप से, gitरिकॉर्ड नहीं करता है:

  • फ़ाइल समूह
  • फ़ाइल मालिकों
  • फ़ाइल अनुमति ("यह निष्पादन योग्य है" के अलावा)
  • विस्तारित विशेषताएँ

आप इस जानकारी को अपनी रिपॉजिटरी में स्पष्ट रूप से दर्ज करने के लिए टूल लिखकर इसे हल कर सकते हैं, लेकिन यह अधिकार प्राप्त करने के लिए मुश्किल हो सकता है।

गिट बैकअप मेटाडेटा के लिए एक Google खोज कई परिणाम देती है जो पढ़ने लायक प्रतीत होती हैं (कुछ उपकरण जिनमें पहले से ही यहां उठाए गए मुद्दों की भरपाई करने का प्रयास है)।

एटकीपर को /etcइन समस्याओं में से कई के समाधान के लिए विकसित किया गया था ।


15
एसीएल / अनुमतियों का उल्लेख करने के लिए +1
लैरी सिल्वरमैन

22
Git भी खाली निर्देशिकाओं को संग्रहीत नहीं करता है।
फ्लिम्ड

और यह इतिहास के माध्यम से फ़ाइल को स्थानांतरित / नाम बदलने के लिए भी चूसता है।
क्रैगॉक्स

1
चूँकि git बहुत अच्छी तरह से बाइनरी फाइलों से निपटता नहीं है, इसलिए आप git annex में भी देखना चाह सकते हैं , जो इसे बेहतर करने में मदद करता है। हालांकि यह विचार कुछ हद तक बदल जाता है।
राउटर वेरहेल्ट

1
मेरी राय है कि आप डेटा बैकअप के लिए git का उपयोग कर सकते हैं लेकिन संपूर्ण सर्वरों का नहीं
EKanadily

21

मैंने इसका उपयोग नहीं किया है, लेकिन आप bup को देख सकते हैं जो git पर आधारित एक बैकअप टूल है।


पहले कभी नहीं देखा गया, दिलचस्प लग रहा है
Smudge

1
मैंने हाल ही में अपने हार्ड ड्राइव के दुर्घटनाग्रस्त होने से कुछ दिन पहले ही bup का उपयोग करना शुरू किया है;) पुनर्स्थापना ठीक हुई, इसलिए सिफारिश की गई!
एंड्रे परमेस

1
@ AndréParamés तो क्या आप कह रहे हैं कि बस के बाद आप अपने हार्ड ड्राइव दुर्घटनाग्रस्त हो गया स्थापित ... mmmmhh ... :) बस मजाक कर रहा हूँ
hofnarwillie

12

यह एक वैध बैकअप समाधान हो सकता है, एटकीपर इस विचार पर आधारित है। लेकिन .gitनिर्देशिका अनुमतियों पर नज़र रखें अन्यथा धक्का निर्देशिका /etc/shadowमें पठनीय हो सकता है .git


11

जबकि तकनीकी रूप से आप ऐसा कर सकते थे, मैं इसके खिलाफ दो प्रस्ताव रखूंगा:

1, आप बाइनरी डेटा के लिए एक स्रोत संस्करण नियंत्रण प्रणाली का उपयोग कर रहे हैं। इसलिए आप इसे किसी ऐसी चीज़ के लिए उपयोग कर रहे हैं जिसे इसके लिए डिज़ाइन नहीं किया गया था।

2, मुझे आपकी विकास प्रक्रिया के बारे में चिंता है अगर आपके पास एक नई मशीन बनाने के लिए एक प्रक्रिया (प्रलेखन या स्वचालित) नहीं है। क्या होगा अगर आप एक बस खरीदने के लिए तैयार हो जाते हैं, जो जानते हैं कि क्या करना है और क्या महत्वपूर्ण था?

डिजास्टर रिकवरी महत्वपूर्ण है, हालाँकि इसके लिए बेहतर है कि आप एक नया डेवलपमेंट बॉक्स तैयार कर लें। अपनी स्क्रिप्ट / डॉक्यूमेंट के लिए git का उपयोग करें लेकिन कंप्यूटर की हर फाइल के लिए नहीं।


4
विकास बक्से सभी किकस्टार्ट फाइलों से आते हैं, और वास्तव में औसत बॉक्स के दोबारा बनने से पहले लगभग 2 या 3 महीने तक रहता है। लेकिन लोग कॉन्फ़िगरेशन बदलते हैं और चीजें करते हैं, हम बक्से को फिर से बनाते हैं और लोग कहते हैं "हे, मुझे पता है कि मैंने इसे स्रोत नियंत्रण में नहीं रखा था, लेकिन मुझे उस बॉक्स पर कुछ गंदगी थी" और मैं बेवकूफ होने के लिए उन पर हंसता हूं। चारों ओर, अच्छा समय। बाइनरी डेटा एक कुतिया होगा, यह कुछ ऐसा है जिसे मैंने स्नान के दौरान पूरी तरह से अनदेखा कर दिया था।
स्मज करें

मैं उन लोगों के लिए आपके दृष्टिकोण की सराहना करता हूं जो मूल प्रिंसिपलों का पालन करने में विफल रहते हैं। व्यक्तिगत रूप से मेरे पास एक समान स्थिति है, हालांकि मेरे पास एक गिट रिपॉजिटरी है जो सभी कॉन्फिग फाइलों में लिंक करता है जो सभी को पकड़ने के बजाय महत्वपूर्ण हो सकता है। इसके अलावा सेटअप चरणों के साथ एक txt डॉक्टर।
फिल Hannent

1
मुझे लगता है कि जीआईटी बाइनरी फाइलों के लिए बहुत अच्छी तरह से काम करता है, Google Android के रेपो के थोक हिस्से में प्रीब्यूबल एक्जीक्यूटिव के गिट रिपॉजिटरी हैं।
user377178

6

मैं अपने विंडोज सिस्टम के लिए बैकअप के रूप में git का उपयोग करता हूं, और यह अविश्वसनीय रूप से उपयोगी है। पोस्ट के निचले भाग में, मैं उन लिपियों को दिखाता हूं जिनका उपयोग मैं विंडोज सिस्टम पर कॉन्फ़िगर करने के लिए करता हूं। किसी भी सिस्टम के लिए बैकअप के रूप में git का उपयोग करने से 2 बड़े लाभ मिलते हैं:

  1. व्यावसायिक समाधानों के विपरीत अक्सर अपने स्वयं के स्वामित्व प्रारूप का उपयोग करते हैं, आपका बैकअप एक खुले स्रोत प्रारूप में होता है जो व्यापक रूप से समर्थित होता है और बहुत अच्छी तरह से प्रलेखित होता है। इससे आपको अपने डेटा का पूरा नियंत्रण मिल जाता है। यह देखना बहुत आसान है कि कौन सी फाइलें बदलीं और कब। यदि आप अपने इतिहास को तोड़ना चाहते हैं, तो आप ऐसा भी कर सकते हैं। अपने इतिहास से कुछ करना चाहते हैं? कोई दिक्कत नहीं है। आपकी फ़ाइल का एक संस्करण प्राप्त करना किसी भी git कमांड की तरह सरल है।
  2. जितने चाहें उतने या कुछ दर्पण, और सभी में अनुकूलित बैकअप समय हो सकता है। आपको अपना स्थानीय दर्पण मिलेगा, जो धीमी गति से इंटरनेट ट्रैफ़िक द्वारा बसा हुआ है, और इस तरह आपको (1) पूरे दिन और अधिक बैकअप करने की क्षमता देता है (2) एक त्वरित बहाली का समय। (बार-बार बैकअप एक बहुत बड़ा प्लस है, क्योंकि मुझे सबसे अधिक समय लगता है कि मैं एक दस्तावेज खो देता हूं उपयोगकर्ता-त्रुटि से। उदाहरण के लिए, आपका बच्चा गलती से एक दस्तावेज़ को ओवरराइट कर देता है जो वह पिछले 5 घंटों से काम कर रहा है।) लेकिन आप अपना प्राप्त करेंगे। रिमोट मिरर, जो स्थानीय आपदा या चोरी के मामले में डेटा सुरक्षा का लाभ देता है। और मान लें कि आप अपने दूरस्थ दर्पण को अपने इंटरनेट बैंडविड्थ को बचाने के लिए अनुकूलित समय पर बैकअप लेना चाहते हैं? कोई दिक्कत नहीं है।

नीचे पंक्ति: एक git बैकअप आपको यह नियंत्रित करने की शक्ति देता है कि आपके बैकअप कैसे होते हैं।

मैंने इसे अपने विंडोज सिस्टम पर कॉन्फ़िगर किया है। पहला कदम स्थानीय git रेपो बनाना है जहां आप अपने सभी स्थानीय डेटा के लिए प्रतिबद्ध होंगे। मैं एक स्थानीय दूसरी हार्ड ड्राइव का उपयोग करने की सलाह देता हूं, लेकिन उसी हार्डड्राइव का उपयोग करने से काम चलेगा (लेकिन यह उम्मीद है कि आप इसे कहीं दूर धकेल देंगे, या अन्यथा हार्डड्राइव से आपकी मृत्यु हो जाएगी।)

आपको सबसे पहले cygwin (rsync के साथ) इंस्टॉल करना होगा, और Windows के लिए git भी स्थापित करना होगा: http://git-scm.com/bownload/win

अगला, अपना स्थानीय git रेपो बनाएं (केवल एक बार चलाएं):

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%

अगला, हमारे पास हमारी बैकअप स्क्रिप्ट आवरण है, जिसे नियमित रूप से 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

अगला, हमारे पास बैकअप स्क्रिप्ट ही है जिसे रैपर कॉल करता है:

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%

हमारे पास बाहर से आने वाली फ़ाइल है, जहाँ हमने सभी फ़ाइलों को अनदेखा करने के लिए रखा है:

को बाहर-from.txt:

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

आपको किसी भी दूरस्थ रेपो में जाने और उन पर 'गिट इनिट - बेयर' करने की आवश्यकता होगी। आप बैकअप स्क्रिप्ट को निष्पादित करके स्क्रिप्ट का परीक्षण कर सकते हैं। सब कुछ काम करता है, विंडोज शेड्यूलर पर जाएं और vbs फ़ाइल की ओर एक घंटे का बैकअप इंगित करें। उसके बाद, आपके पास हर घंटे के लिए आपके कंप्यूटर का एक इतिहास होगा। यह बहुत सुविधाजनक है - हर गलती से पाठ के एक हिस्से को हटा दें और इसे याद करें? बस अपने गिट रिपॉजिटरी की जाँच करें।


बस जिज्ञासु - क्या यह धीमे या गैर-मानक नेटवर्क ड्राइव के लिए भी काम करेगा, जैसे कि नेटड्राइव या एक्सपैंड्रिव द्वारा अनुकरण किए गए हैं? मुझे इन नेटवर्क ड्राइव के साथ सबसे अधिक बैकअप सॉफ़्टवेयर विफल हुए हैं। इसके अलावा चीजें बहुत धीमी गति से चलती हैं और टाइम-आउट हो जाती हैं, अगर मैं बैकअप की सभी फाइलों को सूचीबद्ध करना चाहता हूं और व्यक्तिगत फाइलें निकालना चाहता हूं। क्या इन मुद्दों को हल करने में सक्षम है?
जस्टमार्टिन

@JustAMartin मैंने कभी नेटवर्क ड्राइव पर इसका परीक्षण नहीं किया है, इसलिए मैं नहीं कह सकता। एक बार जब आप फ़ाइलों को एक git रेपो में प्राप्त कर लेते हैं, तो git बहुत कुशल होता है।
user64141

4

वैसे यह बुरा विचार नहीं है, लेकिन मुझे लगता है कि 2 लाल झंडे उठाए जाने हैं:

  • यदि हार्डडिस्क विफल हो जाता है, तो आप सब कुछ खो देंगे यदि आप किसी अन्य सर्वर / ड्राइव पर अपनी प्रतिबद्धता को आगे नहीं बढ़ा रहे हैं। (घटना यदि आपके पास इसके लिए एक योजना है, तो मैं उल्लेख करना पसंद करता हूं।)

... लेकिन फिर भी, यह भ्रष्टाचार से संबंधित चीजों के लिए एक अच्छा बैकअप हो सकता है। या जैसा आपने कहा, अगर .git / फ़ोल्डर कहीं और है।

  • यह बैकअप हमेशा आकार में बढ़ेगा। डिफ़ॉल्ट रूप से कोई प्रूनिंग या रोटेशन या कुछ भी नहीं है।

... तो आपको टैग जोड़ने के लिए अपने क्रोनजॉब को बताने की आवश्यकता हो सकती है, और फिर सुनिश्चित करें कि टैग नहीं किए गए हैं, उन्हें साफ किया जाएगा।


हम शायद एक दूरस्थ सर्वर पर .IT निर्देशिका को माउंट करेंगे, हालांकि क्लैसिक rm -Rf /हमें कुछ मुद्दों का कारण बनेगा। हमारा वर्तमान बैकअप सिस्टम 2 साल या 50 संस्करणों के लिए सामान रखता है (जो भी अंतिम हो) इसलिए हमारा बैकअप लगातार बढ़ रहा है। लेकिन मैं टैग जोड़ने का विचार पसंद है, हम "दैनिक" हो सकता था, "साप्ताहिक" आदि टैग
धब्बा

कभी बढ़ रही है अंतरिक्ष आवश्यकताओं के लिए +1
hafichuk

@sam गिट कभी बढ़ रहा है। आप इतिहास को N वर्षों से पुराने नहीं कर सकते। मुझे लगता है कि आपका वर्तमान सिस्टम करता है।
आरडीएस

1
आकार में वृद्धि के बारे में, कृपया 'git gc' नियमित रूप से या दूसरे (केंद्रीय) सर्वर पर धकेलने से पहले करें। इसके बिना git रेपो को जितना हो सकता है उससे अधिक (बहुत) बड़ा हो सकता है। मेरे पास एक बार 346 एमबी की गिट रेपो थी जो 16 एमबी तक सिकुड़ सकती है।
हेन्डी इरावन

3

मैंने इसे एक पूर्ण प्रणाली के साथ आज़माया नहीं है, लेकिन मैं अपने MySQL बैकअप के लिए (--skip-Extended-Insert विकल्प के साथ) इसका उपयोग कर रहा हूँ और इसने वास्तव में मेरे लिए अच्छा काम किया है।

आप द्विआधारी डेटा फ़ाइलों के साथ समस्या में चलाने जा रहे हैं (उनकी संपूर्ण सामग्री बदल सकती है और बदल जाएगी) और आपको .gitफ़ोल्डर को वास्तव में बड़ी होने की समस्या हो सकती है । मैं एक .gitignoreफ़ाइल स्थापित करने और केवल उन पाठ फ़ाइलों का बैकअप लेने की सलाह दूंगा जो आपको वास्तव में आवश्यक हैं।


मैं इसे MySQL बैकअप के लिए भी उपयोग कर रहा हूँ, - - मिश्रित-असत्य = के साथ। नियमित रूप से या कमिट करने के बाद "gc gc" ज़रूर करें।
हेंडी इरावन


3

मैंने एक बार तोड़फोड़ पर आधारित एक बैकअप समाधान विकसित किया था। जबकि इसने काफी अच्छा काम किया (और git को और भी बेहतर काम करना चाहिए), मुझे लगता है कि यहां से बेहतर समाधान हैं।

मैं विचार rsnapshot बेहतर में से एक है - नहीं तो बेहतर। हार्ड लिंक के अच्छे उपयोग के साथ, मेरे पास एक दैनिक, साप्ताहिक और असंतुष्ट बैकअप के साथ 300 जीबी फाइलसेवर (आधा मिलियन फाइलों के साथ) है, जहां तक ​​एक साल बाद वापस जाना है। टोटल यूज्ड डिस्क स्पेस प्रत्येक बैकअप का केवल एक पूर्ण कॉपी + वृद्धिशील हिस्सा है, लेकिन हार्डलिंक के लिए धन्यवाद, मेरे पास प्रत्येक बैकअप में एक पूर्ण "लाइव" निर्देशिका संरचना है। दूसरे शब्दों में, फ़ाइलें न केवल daily.0 (सबसे हाल ही में बैकअप) के तहत, बल्कि दैनिक.1 (yestarday) या साप्ताहिक.2 (दो सप्ताह पहले), और इसी तरह सीधे पहुंच योग्य हैं।

सांबा के साथ बैकअप फ़ोल्डर को फिर से चालू करने पर, मेरे उपयोगकर्ता बैकअप सर्वर से अपने पीसी को इंगित करके बैकअप से फ़ाइल खींचने में सक्षम हैं।

एक और बहुत अच्छा विकल्प rdiff- बैकअप है , लेकिन जैसा कि मैं हमेशा एक्सप्लोरर बस to \\ servername करने के लिए शीर्षक के द्वारा सुलभ है, rsnapshot मेरे लिए एक बेहतर समाधान था।


Rdiff-backup की अंतिम रिलीज़ 2009 से है। क्या यह बहुत अच्छी तरह से डिज़ाइन किया गया है और इसे किसी भी अद्यतन की आवश्यकता नहीं है या यह केवल एक परित्यक्त परियोजना है?
माटुस्ज़ कोनीक्ज़नी

मुझे नहीं पता कि क्या यह निपटाया गया है, लेकिन यह मूल रूप से "किया गया" है।
षोडशशोक

पर देख से savannah.nongnu.org/bugs/... ऐसा लगता है कि कुछ गतिविधि के रूप में 2015 के अंत के रूप में था, लेकिन कई बग रिपोर्ट अनदेखी कर रहे हैं कि। मुझे लगता है कि मैं इसे एक परित्यक्त के रूप में वर्गीकृत करूंगा।
माटुस्ज़ कोनीक्ज़नी

2

मैं git के साथ बैकअप करने के लिए एक ही विचार था, मूल रूप से क्योंकि यह बैकअप बैकअप की अनुमति देता है। तब मैंने rdiff- बैकअप देखा , जो कि कार्यक्षमता प्रदान करता है (और भी बहुत कुछ)। यह वास्तव में एक अच्छा उपयोगकर्ता इंटरफ़ेस है (सीएलआई विकल्पों को देखें)। मैं इससे काफी खुश हूं। --remove-older-than 2Wबहुत अच्छा है। यह आपको केवल 2 सप्ताह से पुराने संस्करणों को हटाने की अनुमति देता है। rdiff-backupस्टोर केवल फाइलों के अलग-अलग होते हैं।


2

मैं बहुत नया हूं, लेकिन डिफ़ॉल्ट रूप से शाखाएं स्थानीय नहीं हैं, और दूरस्थ रिपॉजिटरी में स्पष्ट रूप से धकेल दी जानी चाहिए। यह एक अप्रिय और अप्रत्याशित आश्चर्य था। आखिरकार, क्या मैं नहीं चाहता कि मेरे सभी स्थानीय प्रतिनिधि सर्वर पर 'बैकअप' बनें? Git book पढ़ना :

आपकी स्थानीय शाखाएँ आपके द्वारा लिखे गए रीमोट के लिए स्वचालित रूप से सिंक्रनाइज़ नहीं हैं - आपको उन शाखाओं को स्पष्ट रूप से पुश करना होगा जिन्हें आप साझा करना चाहते हैं। इस तरह, आप जिस काम को साझा नहीं करना चाहते हैं, उसके लिए आप निजी शाखाओं का उपयोग कर सकते हैं और केवल उन विषय शाखाओं को पुश कर सकते हैं जिन पर आप सहयोग करना चाहते हैं।

मेरे लिए इसका मतलब यह था कि मेरी स्थानीय मशीन की अन्य गैर-गिट फाइलों की तरह उन स्थानीय शाखाओं को भी खो जाने का खतरा है, जब तक कि कुछ गैर-जीआईटी साधनों द्वारा नियमित रूप से बैकअप नहीं लिया जाता। मैं यह वैसे भी करता हूं, लेकिन इसने मेरे रेपो में 'सब कुछ वापस करने' के बारे में मेरी धारणाओं को तोड़ दिया। मुझे इस पर स्पष्टीकरण पसंद आएगा!


1
रीमोट के अपवाद के साथ गिट के बारे में बहुत कुछ स्थानीय है। यह डिजाइन द्वारा है। आप चीजों को हटाने के लिए धक्का दे सकते हैं, और चाहिए, खासकर अगर इस परिदृश्य में बैकअप के लिए उपयोग किया जाता है। शाखाओं के लिए, फिर से, हाँ, आपको स्पष्ट रूप से उन्हें धक्का देने की आवश्यकता है यदि आप उन्हें रिमोट में जोड़ना चाहते हैं। विकास के लिए, यह बहुत अच्छा है क्योंकि अक्सर आप किसी चीज़ का परीक्षण करना चाहते हैं, लेकिन उस परीक्षण शाखा को अनिश्चित काल तक संरक्षित रखने की कोई आवश्यकता नहीं है। एक बार जब आपके पास इसकी आवश्यकता होती है, तो आप इसे एक देव शाखा में विलय करने और परीक्षण शाखा को डिलीट करने की संभावना रखते हैं।
लोकलपीसीग्युय

1

मुझे यह मेरे देव बक्सों के लिए एक अच्छी पद्धति प्रतीत हुई। यह उन्हें कुछ ऐसी चीज़ों से बदल देता है जिन्हें केवल परिनियोजन समापन बिंदु तक समर्थित होने की आवश्यकता होती है।

सभी कॉन्फ़िगरेशन और पैकेज इंस्टॉलेशन मैनिफ़ेस्ट पुपेट में संग्रहीत किए जाते हैं, जो आसान पुनर्विकास और कॉन्फ़िगरेशन अपडेट की अनुमति देता है। कठपुतली निर्देशिका git के साथ समर्थित है। किकस्टार्ट का उपयोग प्रारंभिक तैनाती करने के लिए किया जाता है।

मैं उस समय जो भी पैकेज विकसित कर रहा हूं उसके लिए एक कस्टम YUM रिपॉजिटरी भी रखता हूं। इसका अतिरिक्त लाभ यह है कि जो भी पैकेज हम काम कर रहे हैं, वे स्थानीय सिस्टम पर अनअटेंडेड बायनेरिज़ के रूप में बस नहीं रह गए हैं - अगर ऐसा होता है और फाइलें अच्छी तरह से ओह हो जाती हैं। किसी ने उचित प्रक्रिया का पालन नहीं किया।


1

आप github पर bup की जाँच कर सकते हैं जिसे बैकअप के लिए git का उपयोग करने के उद्देश्य से बनाया गया था।


पिछला उत्तर पहले से ही उसी टूल (bup) की ओर इशारा करता है। serverfault.com/a/341213/303467 । इस पर कोई प्रकाश डाला?
जेवियर

1

यह एक दृष्टिकोण है जिसका उपयोग किया जाता है, यह समझ में आता है।

Keepconf इस काम के लिए rsync और git का उपयोग करें, यह चीज़ को आसान बनाए रखने के लिए इस टूल पर एक आवरण है।

आपको केवल बैकअप सर्वर के लिए कॉन्फ़िगर किए गए ssh-keys और कॉन्फ़िगरेशन फ़ाइल में कुछ पंक्तियों के साथ एक केंद्रीय सर्वर की आवश्यकता है। उदाहरण के लिए, यह सभी रखने के लिए मेरी अपनी फ़ाइल है / आदि / और डेबियन संकुल स्थापित:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

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

इसके साथ, मेरे पास rsync बैकअप और git कमिट है।


0

मेरी व्यक्तिगत राय है कि यह मूल रूप से सभी पीछे की ओर है। आप फ़ाइलों को एक बैकअप समाधान में धकेल रहे हैं, बजाय उन्हें बाहर खींचने के।

बहुत बेहतर होगा कि पहली बार में सर्वर के कॉन्फ़िगरेशन को केंद्रीकृत किया जाए, और फिर कठपुतली जैसी किसी चीज़ का उपयोग करके इसे नीचे खींचें।

उस ने कहा, यह काम कर सकता है, मुझे नहीं लगता कि यह अच्छा होगा।

बैकपेक में देखने की कोशिश करें - इसकी स्थापना करना बहुत आसान है और स्पष्ट रूप से शानदार है।


0

यह कुछ हद तक काम करेगा, लेकिन दो caveats।

  1. जब आप कमिट करेंगे तो फ़ाइल जोड़ स्वचालित रूप से नहीं उठाए जाएंगे। प्रतिबद्ध करने से पहले जोड़ने के लिए नया सामान खोजने के लिए --स्प्रेसिन ओम गिट स्थिति का उपयोग करें।

  2. रिमोट का झंझट क्यों .ssh के लिए? यह कमजोर है Bd आप नहीं जानते कि यह विफल हो जाएगा। सामान्य ssh कुंजी लॉगिन के साथ दूर के अंत के लिए एक नंगे भंडार का उपयोग करें। जब तक रिपॉजिटरी नंगे है और आप केवल एक स्रोत से धक्का देते हैं, यह मर्ज के काम करने की गारंटी है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.