सवाल एक बैकअप उपकरण के रूप में जीआईटी


एक सर्वर पर, गिट स्थापित करें

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

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

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


88
2017-12-15 12:10


मूल


समान विचार का उपयोग कर sparkleshare नहीं है ?? - B14D3
@ बी 14 डी 3 मुझे लगता है कि स्पार्कलेशेयर एक प्रकार का ड्रॉपबॉक्स प्रकार चीज़ है, लेकिन मैं इसे देख लूंगा - Smudge
आप सही हैं, लेकिन यह कुछ प्रकार की बकाया चीज़ बनाने के लिए गिट का उपयोग कर रहा है (कई पीसी की प्रतिलिपि बनाना और फ़ाइलों के नियंत्रण संस्करण);) - B14D3
इसके साथ बड़ी समस्या यह है कि कोई केंद्रीय नियंत्रण नहीं है - आपको किसी भी प्रकार के रखरखाव या बैकअप सत्यापन को पूर्ववत करने के लिए मशीन पर प्रत्यक्ष (एसएसएच) पहुंच की आवश्यकता है। मुझे हमेशा बैक अप लेने के लिए बॉक्स पर एक ऐप इंस्टॉल करना पड़ता है, फिर उन्हें केंद्रीय स्थान से प्रशासित करना बहुत बड़ी जीत है। - hafichuk
@hafichuk Puppet / Chef जैसे टूल के साथ यह इतना बड़ा मुद्दा नहीं है, लेकिन मैं आपका बिंदु देखता हूं। - Smudge


जवाब:


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

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

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

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

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

etckeeper बैक अप के लिए विकसित किया गया था /etc और इन समस्याओं में से कई हल करता है।


78
2017-12-15 17:25



एसीएल / अनुमतियों का उल्लेख करने के लिए +1 - Larry Silverman
गिट भी खाली निर्देशिकाओं को स्टोर नहीं करता है। - Flimm
और यह इतिहास के माध्यम से फ़ाइल चलती / नामकरण फ़ाइल को ट्रैक करने के लिए भी बेकार है। - cregox
चूंकि गिट बाइनरी फाइलों से बहुत अच्छी तरह से निपटता नहीं है, इसलिए आप भी देखना चाहते हैं गिट एनेक्स, जो बेहतर करने में मदद करता है। यह कुछ हद तक गिट के विचार को बदलता है, हालांकि। - Wouter Verhelst
मेरी राय यह है कि आप बैकअप डेटा पर गिट का उपयोग कर सकते हैं लेकिन पूरे सर्वर नहीं - EKanadily


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


20
2017-12-15 13:27



पहले कभी बप नहीं देखा, दिलचस्प लग रहा है - Smudge
मैंने हाल ही में बूप का उपयोग करना शुरू कर दिया है, मेरी हार्ड ड्राइव दुर्घटनाग्रस्त होने से कुछ दिन पहले;) बहाल ठीक हो गया, इसलिए अनुशंसित! - André Paramés
@ AndréParamés तो आप जो कह रहे हैं वह बस आपके हार्ड ड्राइव दुर्घटनाग्रस्त होने के बाद है ... mmmmhh ... :) बस मजाक कर रहा है - hofnarwillie


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


12
2017-12-15 12:18





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

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

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

आपदा रिकवरी महत्वपूर्ण है, हालांकि बैकअप सब कुछ की तुलना में एक नए विकास बॉक्स के सेटअप को स्वचालित (स्क्रिप्ट) स्वचालित करना बेहतर है। निश्चित रूप से अपनी स्क्रिप्ट / दस्तावेज़ीकरण के लिए गिट का उपयोग करें, लेकिन कंप्यूटर पर प्रत्येक फ़ाइल के लिए नहीं।


11
2017-12-15 13:45



विकास बक्से सभी किकस्टार्ट फाइलों से आते हैं, और वास्तव में औसत बॉक्स फिर से निर्मित होने से लगभग 2 या 3 महीने तक रहता है। लेकिन लोग कॉन्फ़िगरेशन बदलते हैं और चीजें करते हैं, हम बक्से को फिर से बनाते हैं और लोग कहते हैं, "अरे, मुझे पता है कि मैंने इसे स्रोत नियंत्रण में नहीं रखा है, लेकिन मुझे उस बॉक्स पर कुछ बकवास था" और मैं उन पर बेवकूफ होने के लिए हँसता हूं। चारों ओर, अच्छे समय। बाइनरी डेटा एक कुतिया होगा, यह कुछ है जो मैंने शॉवर में पूरी तरह से अनदेखा किया था। - Smudge
मैं उन लोगों के प्रति आपके दृष्टिकोण की सराहना करता हूं जो बुनियादी प्रधानाध्यापकों का पालन करने में विफल रहते हैं। व्यक्तिगत रूप से मेरे पास आपके लिए एक समान स्थिति है, हालांकि मेरे पास एक गिट रिपोजिटरी है जो सभी कॉन्फ़िगरेशन फ़ाइलों में लिंक करती है जो सभी को पकड़ने के बजाय महत्वपूर्ण हो सकती हैं। साथ ही सेटअप चरणों के साथ एक txt दस्तावेज़। - Phil Hannent
मुझे लगता है कि गिट बाइनरी फाइलों के लिए बहुत अच्छी तरह से काम करता है, रेपो के Google एंड्रॉइड के थोक हिस्से के साथ प्रीबिल्ट एक्जिक्यूटिव के गिट रिपोजिटरीज हैं। - user377178


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

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

निचली पंक्ति: एक गिट बैकअप आपको बैकअप के तरीके को नियंत्रित करने पर नियंत्रण की अविश्वसनीय मात्रा देता है।

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

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

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

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%

इसके बाद, हमारे पास हमारे बैकअप स्क्रिप्ट रैपर हैं, जिन्हें नियमित रूप से विंडोज शेड्यूलर द्वारा बुलाया जाएगा:

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%

हमने ext-from.txt फ़ाइल को बहिष्कृत किया है, जहां हमने सभी फ़ाइलों को अनदेखा करने के लिए रखा है:

को बाहर-from.txt:

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

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


6
2018-03-21 17:10



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


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

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

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

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

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


4
2017-12-15 13:40



हम शायद रिमोट सर्वर पर .git निर्देशिका को माउंट करेंगे, हालांकि क्लासिक rm -Rf / हमें कुछ मुद्दों का कारण बनेंगे। हमारी वर्तमान बैकअप प्रणाली 2 साल या 50 संस्करणों (जो भी आखिरी बार आती है) के लिए सामान रखती है, इसलिए हमारा बैकअप लगातार बढ़ रहा है। लेकिन मुझे टैग जोड़ने का विचार पसंद है, हम "दैनिक", "साप्ताहिक" आदि टैग कर सकते हैं - Smudge
हमेशा बढ़ती अंतरिक्ष आवश्यकताओं के लिए +1 - hafichuk
@ सैम गिट हमेशा बढ़ रहा है। आप एन साल से पुराने इतिहास को छीन नहीं सकते हैं। मुझे लगता है कि आपका वर्तमान सिस्टम करता है। - rds
आकार में वृद्धि के संबंध में, कृपया नियमित रूप से 'गिट जीसी' करें या इससे पहले कि आप किसी अन्य (केंद्रीय) सर्वर पर जाएं। इसके बिना गिट रेपो बढ़ सकता है (ज्यादा) इससे बड़ा होना चाहिए। मेरे पास एक बार 346 एमबी गिट रेपो था जो 16 एमबी तक कम हो सकता है। - Hendy Irawan


मैंने इसे पूर्ण सिस्टम के साथ नहीं देखा है, लेकिन मैं इसे अपने MySQL बैकअप के लिए उपयोग कर रहा हूं (--स्किप-विस्तारित-सम्मिलित विकल्प के साथ) और यह वास्तव में मेरे लिए अच्छा काम करता है।

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


3
2017-12-15 13:23



मैं इसे MySQL बैकअप के लिए भी उपयोग कर रहा हूं, --extended-insert = false के साथ। प्रतिबद्ध होने के बाद नियमित रूप से या सही "git gc" सुनिश्चित करें। - Hendy Irawan
देख गिट में एक MySQL डेटाबेस का बैक अप लेना एक अच्छा विचार है? - Michael Hampton♦


मैंने एक बार उपversण के आधार पर बैकअप समाधान विकसित किया। हालांकि यह काफी अच्छा काम करता है (और गिट को भी बेहतर काम करना चाहिए), मुझे लगता है कि यहां बेहतर समाधान हैं।

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

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

एक और बहुत अच्छा विकल्प है rdiff-बैकअप, लेकिन जैसा कि मैं एक्सप्लोरर को \\ servername पर ले जाकर फ़ाइलों को हमेशा एक्सेस करना चाहता हूं, rsnapshot मेरे लिए एक बेहतर समाधान था।


3
2018-03-21 20:01



Rdiff-backup की अंतिम रिलीज 200 9 से है। क्या यह बेहद अच्छी तरह से डिज़ाइन किया गया है और किसी भी अपडेट की आवश्यकता नहीं है या क्या यह केवल एक त्याग दिया गया प्रोजेक्ट है? - Mateusz Konieczny
मुझे नहीं पता कि यह मातृभाषा है, लेकिन यह मूल रूप से "किया" है। - shodanshok
देखकर savannah.nongnu.org/bugs/... ऐसा लगता है कि 2015 के अंत तक कुछ गतिविधि हुई थी लेकिन कई बग रिपोर्टों को नजरअंदाज कर दिया गया है। मुझे लगता है कि मैं इसे एक त्याग के रूप में वर्गीकृत करूंगा। - Mateusz Konieczny