इस मुद्दे की रिपोर्टिंग के लिए धन्यवाद, मुझे लगता है कि यह एक बग है।

शायद तब होगा जब शीर्ष स्तर की निर्देशिकाओं का नाम समान होगा। क्योंकि पूर्ण पथ को पुनर्स्थापित नहीं किया गया है, केवल शीर्ष-स्तरीय निर्देशिका।

समाधान पुनर्स्थापना पर पूर्ण पथ का पुनर्निर्माण करना है, और प्रत्येक पेड़ को पूर्ण पथ में पुनर्स्थापित करना है। इसलिए परिणामी रास्ता /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ जैसा होगा। मुझे लगता है कि यह स्वीकार्य है।

क्या पुनर्स्थापना के हिस्से के रूप में पैच को लागू करने की आवश्यकता है?
या, हो सकता है कि इसे बैकअप के दौरान एक अलग शीर्ष-स्तरीय वृक्ष बनाकर किया जाए जिसमें पूर्ण पथ घटक शामिल हों?

मुझे भी संदेह है कि यह मामला है। फिलहाल, इस तरह से काम करता है:

जब restic backup A/foo B/foo रूप में कहा जाता है तो यह इस तरह दिखने वाले भंडार में एक पेड़ की संरचना बनाता है:

├── foo
└── foo

अतः तर्कों से backup कमांड तक केवल अंतिम पथ घटक को लिया जाता है, इस तरह के स्नैपशॉट को पुनर्स्थापित करते समय समस्या आती है।

इसे ठीक करने के लिए, मैं tar के समान व्यवहार को लागू करने का प्रस्ताव करता हूं, जो इस मामले में निम्नलिखित पेड़ बनाएगा:

.
├── A
│   └── foo
└── B
    └── foo

इसके लिए रेस्टिक के आर्काइव भाग में कुछ काम करना होगा। मुझे नहीं लगता कि हमें पुनर्स्थापना को छूने की आवश्यकता होगी।

588 मैंने उसी बात की सूचना दी। लेकिन आपके पास एक परीक्षण का मामला है जिसका आप उपयोग कर सकते हैं।

@ fd0 मैं बैकअप के लिए एक विकल्प (--स्टोर-पूर्ण-पथ) को भी शामिल करने का प्रस्ताव करता हूं जहां यह बैकअप लक्ष्य के पूर्ण 'वास्तविक' पथ को स्पष्ट रूप से संग्रहीत करता है।

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

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

मैंने इस बारे में सोचा है और मुझे लगता है कि हमें बैकअप व्यवहार को बदलने की आवश्यकता है ताकि हमेशा पूर्ण पथ (जैसा कि कमांड-लाइन पर दिया गया है) सहेजा जाए। यही tar करता है, और यह बहुत अच्छी तरह से काम करता है। यह दुर्भाग्य से रेस्टिक के लिए विकास में जल्दी खराब डिजाइन के निर्णय का एक राहत है।

+1 --store-full-path

सिर्फ +1 से नफरत है, लेकिन मुझे इस बग के समाधान में भी बहुत दिलचस्पी है। रेस्टिक के कई लंबित इंस्टॉलेशन हैं, जहां यह बग दुर्भाग्य से शोस्टॉपर है।

इस पर आपके काम के लिए धन्यवाद @ fd0 , मैं समझता हूं कि अब इसे खोलना आसान नहीं है।

-1 --store-full-path । मैं बहुत अधिक पूर्ण पथ हमेशा बैकअप में जा रहा हूँ और तब भागों को दूर करने के लिए एक --strip-components <N> होने की संभावना है अगर आप उन्हें बहाल करने की आवश्यकता नहीं है। इसका मतलब है कि पूर्ण डेटा हमेशा बैकअप में उपलब्ध होता है और यदि उपयोगकर्ता समय बहाल करने के लिए पथ से बहुत सारे घटकों को हटाता है और इसलिए उप-विभाजनों को जोड़ता है, तो यह पुनर्प्राप्त करने योग्य उपयोगकर्ता त्रुटि बन जाता है।

बैकअप स्थान पर होस्टनाम को उपसर्ग करने के रूप में, ऐसा लगता है कि यह आसानी से cmdline से किया जा सकता है, क्योंकि ज्यादातर लोग जानते हैं कि वे किस मेजबान से पहले से बहाल करने जा रहे हैं :)

यह देखते हुए कि आप अभी तक 1.0 नहीं हैं, मैं वोट देता हूं कि, यदि आदर्श निर्धारण के लिए एक ब्रेकिंग परिवर्तन किया जाना है, तो आगे बढ़ें और इसे बाद में करने के बजाय जल्द ही करें।

@ मैं सहमत हूँ, मैं पहले से ही इस पर काम कर रहा हूँ। जैसा कि मैंने कहा, यह एक खराब डिजाइन निर्णय के कारण होता है, जिसे जल्दी ठीक करने की आवश्यकता होती है।

अरे @ fd0 - बस देखा कि 0.7 जारी किया गया था। क्या यह (और # 910 और # 909) 0.7.1 के नक्शे पर है?

शायद 0.7.1 के लिए नहीं, बल्कि 0.8.0 या इसके लिए। मैंने पहले ही इस पर काम करना शुरू कर दिया है। शायद थोड़ी पृष्ठभूमि: यह अभिलेखीय कोड के कारण होता है, जो रेस्टिक में मौजूद सबसे पुराना कोड है। दुर्भाग्य से (जैसा कि मैं 2013-2013 में वापस जाना सीखना शुरू कर रहा था) अभिलेखागार कोड बहुत जटिल है और मैंने बहुत सारी शुरुआती गलतियाँ की हैं (बहुत अधिक संगामिति, बहुत सारे चैनल)। मैं उन चीजों के बारे में भी चिंतित था, जो एक समस्या नहीं थी, और उन चीजों को नजरअंदाज कर दिया जो एक समस्या बन गई थी (उदाहरण सूचकांक हैंडलिंग)।

इसलिए, मैंने पहले ही पूरी तरह से संगणक कोड को फिर से लागू करना शुरू कर दिया है, केवल जब यह समझ में आता है (यानी अलग-अलग विखंडू प्रसंस्करण) और समानांतर में डिस्क से 20 फ़ाइलों को नहीं पढ़ता है। इस कोड में उचित निर्देशिका चलना भी शामिल है और रेपो में संपूर्ण पथ सम्मिलित करेगा।

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

क्या यह परिवर्तन मौजूदा रिपॉजिटरी को प्रभावित करेगा और यदि हां, तो कैसे?

"नए बैकअप के मामले में" प्रभावित "में थोड़ा अलग संरचना होगी", हाँ, लेकिन यह इसके बारे में है। कोई migrate या कुछ भी आवश्यक नहीं।

इसलिए, # 1209 को विलय कर दिया गया है और यह नाम के टकरावों का पता लगाकर और उन्हें हल करके (नाम बदलकर) स्थिति में सुधार करता है, लेकिन यह मुद्दा अभी भी पूरी तरह से हल नहीं हुआ है। मैं इस पर काम कर रहा हूँ :)

@ fd0 किसी भी विचार जब हम स्नैपशॉट की उम्मीद कर सकते हैं जिसमें पूर्ण मूल पथ शामिल है? वर्तमान में हम बैकअप का उपयोग करने और restic का उपयोग करके पुनर्स्थापित करने पर काम कर रहे हैं।

पुनर्स्थापना को स्वचालित करते समय, स्रोत पथ बरकरार रहना आवश्यक है।

अगर मेरे पास दो 'डेटा' निर्देशिकाओं के साथ एक सर्वर है, जिसका बैकअप लिया जा रहा है (और यह सैद्धांतिक नहीं है, तो हमारे पास कंफ्लुएंस और JIRA 'डेटा' निर्देशिकाओं के साथ कई सर्वर हैं) डेटा निर्देशिका कॉन्फ्लुएंस से संबंधित है और कौन सी डेटा निर्देशिका JIRA से संबंधित है। 'डेटा' और 'डेटा -1' जैसा नाम जाहिर तौर पर यहां कटौती नहीं करता है।

मुझे लगता है कि अब के लिए सबसे अच्छा समाधान अलग-अलग स्नैपशॉट में डेटा निर्देशिकाओं का समर्थन करना और उन्हें 'JIRA' या 'Confluence' के साथ टैग करना है?

कोई समयरेखा नहीं है, क्षमा करें।

मुझे लगता है कि अब के लिए सबसे अच्छा समाधान अलग-अलग स्नैपशॉट में डेटा निर्देशिकाओं का समर्थन करना और उन्हें 'JIRA' या 'Confluence' के साथ टैग करना है?

हां, लेकिन # 1225 के अनुसार आप बाद में आसानी से उन्हें एक रेपो में विलय नहीं कर पाएंगे।

विकल्प के संबंध में --store-full-path : rsync का यह विकल्प है: -R , --relative ।
शायद आराम के लिए एक ही विकल्प नाम का उपयोग करें?

पूर्ण-सिस्टम बैकअप के लिए मैंने यहां एक वर्कअराउंड वर्णित किया है: https://forum.restic.net/t/full-system-restore/126/8 यह सुंदर नहीं है, लेकिन # 1494 होने तक काम करेगा।

इस बग ने मुझे थोड़ा चिंतित किया, लेकिन मैं इसे दिए गए चरणों के साथ 0.8.3 में पुन: पेश नहीं कर सकता। क्या यह अभी भी एक खुला मुद्दा है?

हां, दुर्भाग्य से यह अभी भी एक मुद्दा है।

हम्म, मैं किसी तरह इस मुद्दे को दोहरा नहीं सकता, इसलिए मुझे यकीन नहीं है कि मैं अलग क्या कर रहा हूं। मैंने अपनी परीक्षण स्क्रिप्ट संलग्न की।

test_restic_549.zip

आप इसे इस तरह से पुन: पेश कर सकते हैं:

$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo

$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar

$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved

दो उप-विभाजनों के लिए, रेकी उप-स्तर के बेसन का उपयोग रेपो में शीर्ष-स्तरीय डायर के रूप में करता है, इसलिए dir1/subdir और dir2/subdir यह दोनों subdir , यही कारण है कि टक्कर।

नवीनतम स्नैपशॉट को सूचीबद्ध करने से पता चलता है:

$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar

आपके परीक्षण के मामले में, $TESTDIR/dir1 और $TESTDIR/dir2 अलग-अलग हैं ( dir1 बनाम dir2 ) ताकि बग उत्पन्न न हो।

संस्करण 0.9 के रिलीज नोटों से:

रेस्टिक के इस रिलीज के साथ पहले बैकअप से सभी फाइलों को स्थानीय स्तर पर फिर से पढ़ा जा सकेगा, इसलिए इसमें काफी समय लगेगा। उसके बाद अगला बैकअप फिर से तेज होगा।

मैं आपको कुछ आंकड़े देना चाहता हूं:

पहला बैकअप:

-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved

Files:         556 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved

Files:       11570 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved

Files:        2309 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved

Files:         312 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved

Files:       743172 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      84.927 MiB

processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved

Files:         441 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End:   Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------

दूसरा:

-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved

Files:           0 new,     0 changed,   556 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved

Files:           0 new,     0 changed, 11570 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved

Files:           0 new,     0 changed,  2309 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved

Files:           0 new,     0 changed,   312 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved

Files:         292 new,     0 changed, 743172 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Added:      32.790 MiB

processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved

Files:           0 new,     0 changed,   441 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End:   Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------

बहुत लंबे समय तक, बहुत लंबे समय तक इसका मतलब :-)
अच्छा काम करते रहो! 👍

@ fd0 , कमाल का काम! बहुत बहुत धन्यवाद! आपका बैकअप टूल मेरे सभी ऑफ-साइट बैकअप (b2 का उपयोग करके) मेरा पसंदीदा बन गया है :-)