Restic: बड़े प्रून को और अधिक प्रभावी ढंग से संभालें

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

वर्तमान में, 10gbit/sec सैद्धांतिक बैंडविड्थ के साथ हाई-एंड AWS इंस्टेंस पर AZ-स्थानीय S3 बकेट में रेपो के विरुद्ध एक खाली प्रून (एक स्नैपशॉट जो पिछले स्नैपशॉट के समान 100% था) को यहां चलाता है:

1) नई अनुक्रमणिका बनाना -- ~160 पैक्स/सेकंड
2) अभी भी उपयोग में डेटा ढूँढना -- कुल 56 सेकंड
3) पुनर्लेखन पैक -- ~3 पैक/सेकंड

160 पैक/सेकंड धीमा है, लेकिन फिर भी सहनीय है (3TB रेपो के मुकाबले ~ 80 मिनट का रन-टाइम)।

लेकिन पुनर्लेखन @ 3 पैक/सेकंड लगभग 10 घंटे तक चलेगा, यहां तक ​​कि मेरे नोप प्रून के लिए भी (0 पैक हटा देगा और 111098 पैक फिर से लिख देगा, यह 180.699 GiB को मुक्त करता है)। एक बड़े रेपो पर सार्थक छंटाई के लिए, आप 24+ घंटों के लिए नए बैकअप को फ्रीज कर देते हैं।

ऐसा लगता है कि पैक पुनर्लेखन वर्तमान में एकल-थ्रेड में होता है, इसलिए इसे कई श्रमिकों में चलाने की अनुमति देने से काफी मदद मिल सकती है, भले ही वर्तमान प्रतिलिपि फिर शुद्ध दृष्टिकोण बनाए रखा जाए।

व्यक्तिगत रूप से, मैं वर्तमान अवरुद्ध प्रून कार्यान्वयन को अनुकूलित करने में समय नहीं लगाऊंगा, मुझे लगता है कि गैर-अवरुद्ध प्रून बेहतर दीर्घकालिक समाधान है।

मैं हाल ही में इस पर काम कर रहा हूं। यहाँ मैंने क्या किया है:

• सभी पैक्स को स्कैन करने के बजाय मौजूदा इंडेक्स लोड करें (और फिर किसी भी पैक को स्कैन करें जो इंडेक्स में नहीं थे)
• प्रयुक्त ब्लॉब्स के लिए स्नैपशॉट को समानांतर में स्कैन करना
• समांतर पुनर्लेखन आंशिक रूप से प्रयुक्त पैक
• स्मृति में पहले से मौजूद अनुक्रमणिका जानकारी का उपयोग करके नई अनुक्रमणिका लिखें

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

यहां कुछ प्रदर्शन संख्याएं दी गई हैं (बैकएंड के रूप में लूपबैक रेस्ट सर्वर का उपयोग करते हुए 875 GiB डेटा, लगभग 180,000 पैक और 36 स्नैपशॉट के साथ रिपॉजिटरी का उपयोग करके):

• वर्तमान कोड:
  
  
  
  • छँटाई की शुरुआत और अंत में सूचकांक बनाने के लिए 35-40 मिनट (प्रत्येक) (कुल 70-80 मिनट)
  
  
  • प्रयुक्त बूँदें खोजने के लिए 4-5 मिनट
  
  
  • आंशिक रूप से उपयोग किए गए पैक को फिर से लिखने के लिए कुछ सेकंड
  
  
• मेरे अब तक के बदलाव:
  
  
  
  • मौजूदा इंडेक्स को लोड करने के लिए कुछ सेकंड (कुछ समय के लिए अगर इसे अनइंडेक्स किए गए पैक को स्कैन करने की आवश्यकता है)
  
  
  • इस्तेमाल किए गए बूँदें खोजने के लिए 2 मिनट से कम
  
  
  • नई अनुक्रमणिका लिखने के लिए कुछ सेकंड
  
  

मैं एक जेनरेटेड टेस्ट केस स्थापित करने की भी योजना बना रहा हूं जिसमें बहुत अधिक पैक पुनर्लेखन शामिल होगा।

कोर्टनी:

सुपर आशाजनक लगता है! पुष्टि करना चाहते हैं कि यह वह शाखा है जिसमें आप काम कर रहे हैं? मुझे परीक्षण करने में खुशी हो रही है।

https://github.com/cbane/restic/tree/prune-aggressive

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

ठीक है, मेरे पास एक ऐसा संस्करण है जिसे अन्य लोगों द्वारा आज़माने के लिए तैयार रहना चाहिए। यह इस शाखा पर है: https://github.com/cbane/restic/tree/prune-speedup

वर्तमान सीमाएँ:

• मैंने रिपैक कर्मचारियों की संख्या की कोई स्वचालित सेटिंग लागू नहीं की है। अभी के लिए, पर्यावरण चर RESTIC_REPACK_WORKERS को उन श्रमिकों की संख्या पर सेट करें जिनका आप उपयोग करना चाहते हैं। यदि यह सेट नहीं है तो यह डिफ़ॉल्ट रूप से 4 पर आ जाएगा।
• मुझे रीपैकिंग करते समय त्रुटि प्रबंधन पर काम करने की आवश्यकता है। मैंने मौजूदा सिंगल-थ्रेडेड रीपैकिंग से कोई वास्तविक परिवर्तन नहीं किया है; मुझे विभिन्न त्रुटि मामलों को देखने और यह सुनिश्चित करने की आवश्यकता है कि समानांतर में रीपैकिंग करने से कोई समस्या नहीं होती है।

उम, यह आश्चर्यजनक लग रहा है। तुम्हारे काम के लिए धन्यवाद!

मैंने Amazon S3 में 3TB+ रेपो की एक प्रति के साथ इसका थोड़ा परीक्षण किया है और अब तक यह अद्भुत लग रहा है। एक रिपैक प्रून जिसमें सप्ताह लगते थे अब एक घंटे के भीतर पूरा हो जाता है, और वह अपेक्षाकृत धीमी ईबीएस का उपयोग टीएमपी स्पेस के रूप में कर रहा है।

यहाँ एक वास्तविक गेम चेंजर! बढ़िया काम, @cbane!

ईक, मुझे एहसास हुआ कि मैं रन को गलत कर रहा हूं।

एक क्षेत्र जो अभी भी सिंगल थ्रेडेड है और ऐसा लगता है कि यह समांतरता से लाभ उठा सकता है "इंडेक्स में पैक नहीं होने की जांच" चरण है - जिसमें अभी भी मल्टी-टेराबाइट रेपो में 3-4 घंटे लग सकते हैं - लेकिन यह अभी भी एक विशाल है, बड़े पैमाने पर सुधार, धन्यवाद!

@cbane मैं आपके कांटे के खिलाफ कोई समस्या नहीं खोल पा रहा था, इसलिए मुझे बताएं कि इनके लिए कोई बेहतर जगह है या नहीं।

एक और परीक्षण चलाने के दौरान, रिपैक बहुत अंत में विफल रहा (अंतिम पैक को फिर से लिखना), 32 श्रमिकों के साथ चल रहा था:

found 1396709 of 2257203 data blobs still in use, removing 860494 blobs
will remove 0 invalid files
will delete 119301 packs and rewrite 88485 packs, this frees 896.269 GiB
using 32 repack workers
Save(<data/c136027b25>) returned error, retrying after 723.31998ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
Save(<data/09d4692900>) returned error, retrying after 538.771816ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx. Retry again.
Save(<data/23d0d4f842>) returned error, retrying after 617.601934ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
[10:02] 100.00%  88484 / 88485 packs rewritten
panic: reporting in a non-running Progress

goroutine 386596 [running]:
github.com/restic/restic/internal/restic.(*Progress).Report(0xc42011c2c0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0)
        internal/restic/progress.go:122 +0x242
github.com/restic/restic/internal/repository.Repack.func2(0x8, 0xe17f58)
        internal/repository/repack.go:66 +0x136
github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1(0xc4389246c0, 0xc56f509160)
        vendor/golang.org/x/sync/errgroup/errgroup.go:57 +0x57
created by github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go
        vendor/golang.org/x/sync/errgroup/errgroup.go:54 +0x66

मेरे पास पहले की तरह उसी शाखा में एक नया संस्करण उपलब्ध है। मैंने master के खिलाफ भी विद्रोह किया।

पिछले संस्करण से मुख्य परिवर्तन यहां दिए गए हैं:

• प्रत्येक कार्यकर्ता को एक पैक को एक पाइपलाइन में दोबारा पैक करने के सभी चरणों को करने से रीपैकिंग को परिवर्तित कर दिया।
• रिपैकिंग के अंत में रिपोर्ट की गई दुर्घटना को ठीक किया।
• सीपीयू की संख्या और बैकएंड के लिए कॉन्फ़िगर की गई कनेक्शन सीमा के आधार पर पाइपलाइन चरणों के लिए श्रमिकों की संख्या को अब ऑटो-स्केल करता है। ( RESTIC_REPACK_WORKERS पर्यावरण चर का अब उपयोग नहीं किया जाता है।)
• प्रयुक्त बूँदें खोजने के लिए मामूली बदलाव।
• अज्ञात पैक की स्कैनिंग समानांतर।

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

मैं इस मुद्दे (या इसके लिए भविष्य के पुल अनुरोध) पर चर्चा जारी रखने की ओर झुकता हूं, ताकि सब कुछ फैलने के बजाय यहां मुख्य भंडार में रहे।

अभी परीक्षण किया गया है। यह रीपैकिंग के अंत में दुर्घटना को हल करता है और वास्तव में वास्तव में अच्छी तरह से काम करता है।

एकमात्र अतिरिक्त स्थान जो बढ़ी हुई समानता से लाभान्वित हो सकता है, वह है पैक्स को हटाना, जो वर्तमान में सिंगल थ्रेडेड है।

यह रेपो के पहले प्रून के दौरान विशेष रूप से कठिन काटता है जो पहले प्रून-सक्षम नहीं था, क्योंकि ऐसे _lot_ पैक हैं जिन्हें हटाने की आवश्यकता है।

सिंगल थ्रेडेड विलोपन के साथ भी, हालांकि, 1.7TB, 356k पैक रिपॉजिटरी के खिलाफ एक दैनिक भूल / छँटाई जो 14.7k पैक को फिर से लिखता है और 33k पैक को हटाता है, अब केवल 20 मिनट से कम समय लेता है।
पहले, छंटाई करना बिल्कुल भी असंभव था।

उत्कृष्ट कार्य, धन्यवाद!

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

मैं जल्द ही इसके लिए एक पुल अनुरोध खोलने की योजना बना रहा हूं, यह मानते हुए कि कुछ भी नहीं टूटा। (हालांकि, मैं पहले इतिहास को साफ कर दूंगा।) @fd0 , क्या आप इसे पहले देखना चाहते हैं?

हमारे टेस्ट रन में बहुत अच्छा काम किया। 225 सेकंड में 30k पैक को फिर से लिखा, 50 सेकंड में 73k पैक को हटा दिया।

32 जीवित स्नैपशॉट के साथ S3 में 1.74TiB रेपो के मुकाबले कुल रनटाइम केवल 6 मिनट से अधिक था।

शानदार काम।

@cbane मैंने आपकी शाखा की कोशिश की https://github.com/cbane/restic/tree/prune-speedup

लेकिन यह वह त्रुटि है जिसे मैं प्राप्त करता हूं :(

root<strong i="9">@srv</strong> ~/restic-backups # restic --no-cache prune
repository 49b87c6a opened successfully, password is correct
listing files in repo
loading index for repo
[0:28] 1.01%  30 / 2982 index files
pack cbbebd8d already present in the index
github.com/restic/restic/internal/index.(*Index).AddPack
    internal/index/index.go:266
github.com/restic/restic/internal/index.Load.func1
    internal/index/index.go:230
github.com/restic/restic/internal/repository.(*Repository).List.func1
    internal/repository/repository.go:640
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1.1
    internal/backend/backend_retry.go:133
github.com/restic/restic/internal/backend/rest.(*Backend).listv2
    internal/backend/rest/rest.go:423
github.com/restic/restic/internal/backend/rest.(*Backend).List
    internal/backend/rest/rest.go:358
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1
    internal/backend/backend_retry.go:127
github.com/cenkalti/backoff.RetryNotify
    vendor/github.com/cenkalti/backoff/retry.go:37
github.com/restic/restic/internal/backend.(*RetryBackend).retry
    internal/backend/backend_retry.go:36
github.com/restic/restic/internal/backend.(*RetryBackend).List
    internal/backend/backend_retry.go:126
github.com/restic/restic/internal/repository.(*Repository).List
    internal/repository/repository.go:634
github.com/restic/restic/internal/index.Load
    internal/index/index.go:202
main.pruneRepository
    cmd/restic/cmd_prune.go:202
main.runPrune
    cmd/restic/cmd_prune.go:128
main.glob..func18
    cmd/restic/cmd_prune.go:28
github.com/spf13/cobra.(*Command).execute
    vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
    vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
    vendor/github.com/spf13/cobra/command.go:800
main.main
    cmd/restic/main.go:86
runtime.main
    /snap/go/3947/src/runtime/proc.go:200
runtime.goexit
    /snap/go/3947/src/runtime/asm_amd64.s:1337

@antetna ऐसा लगता है कि आपके भंडार में एकाधिक अनुक्रमणिका फ़ाइलें हैं जो समान पैक को कवर करती हैं। मुझे नहीं पता कि यह कैसे हो सकता है, लेकिन मैंने इसके लिए टेस्ट सूट में एक टेस्ट केस जोड़ा है, और मैं आपकी त्रुटि को पुन: उत्पन्न कर सकता हूं। मैं इसे ठीक करने का काम करूंगा।

@antetna ठीक है, मैंने अभी उसी शाखा में एक नया संस्करण धक्का दिया है (फास्ट-फॉरवर्ड नहीं) जो मेरे डुप्लिकेट इंडेक्स टेस्ट केस के साथ काम करता है। क्या आप इसे आजमा सकते हैं?

मैं जल्द ही इस शाखा के वर्तमान संस्करण के साथ एक पुल अनुरोध खोलने की योजना बना रहा हूं, जब तक कि किसी और को कोई समस्या न दिखे।

बहुत बहुत धन्यवाद @cbane! मेरे ~ 860GB 12000+ स्नैपशॉट रेपो को प्रून करने के लिए मानक प्रून को लगभग ~ 55 घंटे लगे। आपके अधिक आक्रामक समानांतर दृष्टिकोण के साथ इसने इसे घटाकर केवल 3 घंटे से अधिक कर दिया।

Howdy @cbane , अद्भुत काम!

इस पीआर को यहां डेबियन 9 amd64 पर चलाना, गो 1.12.1 के साथ संकलित, मेरे 30TB रेपो पर 220 मिनट चलने के बाद निम्न त्रुटि प्राप्त करना:

checking for packs not in index
[0:52] 16.45%  178 / 1082 packs
[5:23] 100.00%  1082 / 1082 packs
repository contains 3213929 packs (259446787 blobs) with 15.025 TiB
processed 259446787 blobs: 30090 duplicate blobs, 4.906 GiB duplicate
load all snapshots
find data that is still in use for 3 snapshots
[0:04] 0.00%  0 / 3 snapshots
tree 6f144a19eaae0e81518b396bfdfc9dd5c6c035bdba28c6a90d6f70e692aa1c55 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
        internal/repository/repository.go:707
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:52
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func4
        internal/restic/find.go:89
gopkg.in/tomb%2ev2.(*Tomb).run
        vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1337

मुझे इससे कैसे उबरना चाहिए?

धन्यवाद,
--दुरवल।

@DurvalMenezes ऐसा लगता है कि आपके भंडार में कुछ पैक फ़ाइलें गुम हैं। क्या आपने इसे पहले काट दिया है? क्या restic check सफल होता है? यदि ऐसा नहीं होता है, तो इससे आपको अधिक विस्तृत जानकारी मिलनी चाहिए कि क्या गलत है।

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

उत्तर के लिए धन्यवाद, @cbane। अधिक, नीचे:

क्या आपने इसे पहले काट दिया है?

नहीं, यह मेरा पहला प्रून है। लंबी कहानी छोटी: मेरे रेपो में मेरे NAS पर 3 स्थानीय गंदगी से ~ 95 स्नैपशॉट हैं; वे 3 गंदगी कुल ~ 30 टीबी और ~ 60 एम फाइलें/उप-दिशाएं, और बैकअप के लिए अधिक और अधिक समय ले रही हैं, इस बिंदु पर कि केवल 24 घंटे के नए डेटा (10 जीबी से कम) का बैकअप लेने में 24 घंटे से अधिक समय लग रहा था। मंच पर सलाह थी कि restic forget (जो मैंने किया, केवल पिछले 3 स्नैपशॉट को छोड़कर) और फिर restic prune चलाया, जिसे मैंने पहले रेस्टिक 0.9.5 का उपयोग किया था (लेकिन यह ~ के बाद निरस्त हो गया था) ओओएम के कारण 24 घंटे)। मैंने तब मशीन (Google कंप्यूट क्लाउड पर एक VM) को दो बार RAM में अपग्रेड किया, और फिर आपके PR का उपयोग किया, जिसने उपरोक्त त्रुटि दी।

क्या रेस्टिक चेक सफल होता है? यदि ऐसा नहीं होता है, तो इससे आपको अधिक विस्तृत जानकारी मिलनी चाहिए कि क्या गलत है।

मैं पिछले 90 घंटों से restic check चला रहा हूं (आपके पीआर का भी उपयोग कर रहा हूं), और इसने मुझे अब तक यह आउटपुट दिया है: रेस्टिक-चेक-PARTIAL_output.txt

जैसा कि उपरोक्त फ़ाइल के अंत में बताया गया है, restic check ने 3 दिन पहले अपना नवीनतम संदेश ("स्नैपशॉट, पेड़ और बूँद जांचें") प्रदर्शित किया है ... मुझे आश्चर्य हो रहा है कि यह अटक गया है और कभी खत्म नहीं होगा :-/ वास्तव में, प्रक्रिया पर एक "स्ट्रेस" दिखाता है कि यह एक ही स्थानीय कैश फ़ाइल को बार-बार खोल रहा है:

तारीख; strace -t -f -p 2608 -e openat 2>&1 | ग्रेप ओपनैट | egrep -v अधूरा\|फिर से शुरू | सिर
मंगल जुलाई 23 00:41:59 यूटीसी 2019
[ओफ 26508] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/tmp/restic-check-cache-370688148/abb62ab49b49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53/466248624864948649486486494864986486494864986486498649864864986 ईएक्सडी49ईबी 10d29a2/डेटा/53/53/53/5466464646464862बी949सीड49बी
[ओएफ 2608] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी1999ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486ईबीडी389ई644464647666286ईएक्सडी38डी644ए
[ओएफ 2615] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486EXD389e
[ओएफ 5482] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486EXD389e
[ओएफ 2615] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486EXD389e
[ओएफ 3688] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी1999ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486ईबीडी389ई644ए
[ओएफ 5482] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5एबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486ईबीडी49ई644464647666286ईड49ई644446बी
[ओपीआईडी ​​2608] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486EXD389e
[ओएफ 2638] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486Ebd389e
[ओएफ 2638] 00:41:59 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486Ebd389e

And then, almost 10 hours later: 

मंगल जुलाई 23 10:14:27 यूटीसी 2019
[Of 2632] 10:14:27 ओपनैट (AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486d389e146b476b
[ओएफआईडी 2639] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486d389e146b476b
[ओएफआईडी 2634] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486एफ289ई644476बी
[ओएफआईडी 2613] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी1999ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486एफ289ई644476बी
[ओएफआईडी 2634] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486एफ289ई644476बी
[ओएफआईडी 3688] 10:14:28 ओपनएट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486डीएक्सएक्सडी644446बी
[ओफ 2617] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/डेटा/53/53/53d2486d389e1b476b
[ओएफआईडी 3688] 10:14:28 ओपनएट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486डीएक्सएक्सडी644446बी
[ओएफआईडी 2634] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486एफ289ई644476बी
[ओएफ 2611] 10:14:28 ओपनैट (एटी_एफडीसीडब्ल्यूडी, "/ टीएमपी/रेस्टिक-चेक-कैश-370688148/एबीबी62एबी49बी950ई4बी2एबी5ईबी82सी4386ए9बी199ए08ईबी6एफडी93बीडीएसीसीडी0ई4डीबी10डी29ए2/डेटा/53/53/53डी2486एफ289ई644476बी
```

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

मुझे लगता है कि मैं इसे आगे कोशिश करूंगा; अगर यह restic check अगले 24 घंटों में समाप्त नहीं होता है, तो मैं इसे सिगिनट कर दूंगा और फिर restic rebuild-index । पुनर्निर्माण-सूचकांक के लिए, क्या मुझे इस पीआर का उपयोग करना चाहिए? रेस्टिक-मास्टर हेड? या कुछ और?

एक बार फिर धन्यवाद,
--दुरवल।

हाँ, यह आशाजनक नहीं लग रहा है। restic rebuild-index करने के लिए शायद सबसे अच्छी बात है, फिर अपनी तीन निर्देशिकाओं के नए बैकअप चलाएं, और फिर अन्य सभी स्नैपशॉट्स को भूल जाएं। उसके बाद, आपको सफलतापूर्वक restic prune करने में सक्षम होना चाहिए।

मैंने rebuild-index कोड को नहीं छुआ, इसलिए आप जो चाहें संस्करण के साथ ऐसा कर सकते हैं।

@cbane , बस आपको पोस्ट करने के लिए: मैंने 5 दिन पहले आपके पीआर का उपयोग करके restic rebuild-index शुरू किया था (मैं समझता हूं कि कोई भी संस्करण करेगा, लेकिन आपका उपयोग करने से चीजें आसान हो जाती हैं) और यह तब से चल रहा है। पहले कुछ निराशाजनक दिनों के बाद (जब प्रतिशत से एक्सट्रपलेशन से यह संकेत मिलता है कि यह 30 दिनों से अधिक समय तक चलेगा), ऐसा लगता है कि कुछ गति पकड़ ली है और इसे 'केवल' 10 और दिनों तक चलना चाहिए (कम से कम अपने वर्तमान में) 'रेपो में फाइलों की गिनती' चरण)।

यह मानते हुए कि यह rebuild-index ठीक है, योजना तब आपके पीआर के साथ restic prune चलाने की है। आपको बताया जाएगा कि यह कैसे चलता है।

सभी को अप-टू-डेट रखते हुए: मेरा मुफ़्त $300 GCloud क्रेडिट समाप्त हो गया, पूरी तरह से 104GB VM द्वारा खा लिया गया जिसे मुझे prune चलाने के लिए बनाना था (और, मुझे लगता है, rebuild-index भी)। मेरे पास विकल्पों से बाहर हो रहा है: -/ जब मैं इस गड़बड़ी से बाहर निकलने का रास्ता ढूंढूंगा तो अपडेट हो जाएगा।

मैंने शाखा "प्रून-स्पीडअप" की कोशिश की और परिणाम बहुत ही आशाजनक हैं!

बैकएंड: S3

# bin/restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
# bin/restic prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[1:30:34] 100.00%  319784 / 319784 packs
repository contains 319784 packs (5554019 blobs) with 1.445 TiB
processed 5554019 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 30 snapshots
[3:38:52] 100.00%  30 / 30 snapshots
found 5376708 of 5554019 data blobs still in use, removing 177311 blobs
will remove 0 invalid files
will delete 3526 packs and rewrite 4850 packs, this frees 26.925 GiB
[1:28:21] 100.00%  4850 / 4850 packs rewritten
counting files in repo
[1:20:27] 100.00%  314240 / 314240 packs
finding old index files
saved new indexes as [b7029105 797145b1 0ed8981e 7f19c455 dff4d9be a52d8e7a 0cf9f266 ab32a9e4 f34331b3 84c84cbb 563896c9 9902e35d 817ef96c 6b4dcfef 32d3e18c 1d782d96 b12554dd d4b69bcf 8ec94a43 66cbd035 8e9cb96d d74b5246 ca7d7ca3 1f209708 9fe26189 28414ee2 88ff07fb 24280466 8757a1f9 8706ff35 5fab942b 549409c3 f781a762 9417afec 4b2361aa 6b43f992 8da8dfe7 54ec498e 5be6fb8a 17411b83 270f3ce3 ba520d35 95913ad0 f8f15108 cbc67971 a419ff7c 875cfcc7 13f55ece bd488aa4 7f5b588a cddd40b4 7a79d1ce bd7e3d0f 2cdcd635 ee6e28c3 98146287 50867bde 41a056ae 836ce971 e9451c8b 0f9cc7e6 52dedc04 c4e8e7f6 2e4966f0 ba4fa5b3 ddc9a766 b995fd36 fd6b3ac8 1c12bcc3 4c98c3c9 39ac7cd5 42ebf4c1 1a48465e b5245192 73a73c5e daa6ee8d d26ce697 9f84d9b3 bc371def b141466a 6906b3c1 282ce115 d8024363 10f0b924 ad4fad64 9450aada 31378365 65d785b3 98b085d0 768f420c f22512b3 be3223ba 031d5488 f2b7fcf6 87177471 fd269664 b239b89e 6bf972ea 0d6f8f36 87362542 fff9c2cd 5c85ac76 f91daae1 dc594a83 220bdc83]
remove 1459 old index files
[2:33] 100.00%  8376 / 8376 packs deleted
done
# 

अब देव संस्करण के साथ:

# bin/restic_linux_amd64 version
restic 0.9.5-dev (compiled manually) compiled with go1.12.4 on linux/amd64
# bin/restic_linux_amd64 prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[57:21] 100.00%  314240 / 314240 packs
repository contains 314240 packs (5376708 blobs) with 1.419 TiB
processed 5376708 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 29 snapshots
[1:48:18] 100.00%  29 / 29 snapshots
found 5356653 of 5376708 data blobs still in use, removing 20055 blobs
will remove 0 invalid files
will delete 212 packs and rewrite 1427 packs, this frees 3.114 GiB
[14:16] 100.00%  1427 / 1427 packs rewritten
counting files in repo
[57:47] 100.00%  313618 / 313618 packs
finding old index files
saved new indexes as [004d6eb2 630de131 1b85faed 0fb7a978 bc500e05 34f7d187 447c3b59 ada047d2 5430430e 768f606e a5c341ea a75059c5 71d0fbec c63f5c56 ba43e69d f47699f5 d7cd2587 5826bcae 6250ec67 6af77aa4 cbf8c1f9 a7809b5f c3242748 8bb7d037 8ca69481 5a8877c3 fb30ea48 4bdb6269 eeeba466 7cdc444a bc15ddd5 c5544612 b8a5004c 2879403a c33778b7 e692013a 41ce8a1d 55b4be0a 5714b820 1adca569 b06ccd6b 16467da7 79ed066a 64c7e397 43217ede af7350a4 73c65a0f 35260990 a232ea42 c843bfa5 332aded7 0e294517 26984755 3c36a14b 68b2024e 267bf0b2 a41c4f64 aa46affb c7a6e2ac 0d34c60f 766d21f0 0d7b8b41 4fea4363 a1a3c5cd 73809a0e 56a67410 25314d47 a32ded24 68feae36 78ef5cbb b051a740 6a51f900 d2ee860f 1ad44787 c6c4358d 89de2f69 a157bd2b 77995b94 3bc58934 b905be42 0a1df2e7 ba67a98c 263b5266 7a809abc 34ff6f07 d96adc12 8f69fc74 ebb053eb 8fb68f6a 11224e7d 990f61f8 764941fc ed95513b 1c17c8aa 3226a7cb 76988c78 e4d8f156 b4d4c952 8c379d51 e968f3c9 f9cfff55 464cf3e1 f9d23c32 136957e3 02e397b1]
remove 105 old index files
[0:32] 100.00%  1639 / 1639 packs deleted
done
#

यह एक बड़े सुधार की तरह दिखता है! बधाई!
अगर मैं आने वाले हफ्तों में और मशीनों पर कोशिश करता हूं तो मैं और परिणाम पोस्ट करूंगा।

@fbarbeira आपके द्वारा पोस्ट किए गए आउटपुट से, ऐसा लगता है कि आप वास्तव में मेरे बेहतर संस्करण का उपयोग नहीं कर रहे हैं। जब मैं बैकब्लज़ बी 2 पर अपने बड़े भंडार को छीनता हूं तो मुझे यह आउटपुट मिलता है:

repository 399dfab1 opened successfully, password is correct
listing files in repo
loading index for repo
[0:02] 100.00%  71 / 71 index files
checking for packs not in index
repository contains 208840 packs (1675252 blobs) with 1006.203 GiB
processed 1675252 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 32 snapshots
[0:16] 100.00%  32 / 32 snapshots
found 1675113 of 1675252 data blobs still in use, removing 139 blobs
will remove 0 invalid files
will delete 4 packs and rewrite 24 packs, this frees 26.404 MiB
[3:31] 100.00%  24 / 24 packs rewritten
saving new index
[10:31] 70 index files
remove 71 old index files
[0:04] 100.00%  28 / 28 packs deleted
done

उसमें धीमेपन का मुख्य स्रोत मेरे केबल मॉडेम पर सीमित अपलोड गति है।

restic version से आउटपुट भी कुछ इस तरह दिखना चाहिए:

restic 0.9.5 (v0.9.5-31-g09b92d6d) compiled with go1.11.6 on linux/amd64

इस अद्यतन @ fd0 को मर्ज करने का कोई इरादा?

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

@cbane , एक आइटम जो निश्चित रूप से अवरोधक नहीं है लेकिन मुझे लगा कि मैं ध्वजांकित करूंगा: रेपो बढ़ने के साथ प्रून पैक रीराइट धीमा हो जाता है।

उदाहरण के लिए, 3,984,097 पैक रेपो के लिए पैक पुनर्लेखन चरण 110 पैक/सेकंड पर पैक को उसी AZ में S3 बाल्टी से बात करते हुए i3.8xlarge पर फिर से लिखता है।

एक ही उदाहरण + एक छोटे रेपो (450,473) के साथ बैकिंग स्टोर कॉम्बो 200 पैक/सेकंड पर फिर से लिखता है।

@pmkane , क्या वह गति असमानता है, भले ही वे समान संख्या में पैक फिर से लिख रहे हों? या यह हमेशा होता है कि कितने पैक फिर से लिखे जा रहे हैं? इसके अलावा, क्या यह सिर्फ पैक पुनर्लेखन है, या अन्य चरण भी धीमे हो जाते हैं?

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

@cbane , सुनिश्चित नहीं है कि यह पैक या रेपो आकार की संख्या का एक कार्य है। मैं अपने छोटे रेपो के डुप्लिकेट पर कुछ परीक्षण चला सकता हूं और देख सकता हूं। प्रोफाइलिंग के साथ एक संस्करण चलाने और परिणामों को साझा करने में खुशी हुई।

460k पैक रेपो के लिए कुछ नमूना समय - 3.7 मिमी समय का पालन करें:

रेपो के लिए लोडिंग इंडेक्स
[0:01] 100.00% 154/154 अनुक्रमणिका फ़ाइलें

डेटा ढूंढें जो अभी भी 36 स्नैपशॉट के लिए उपयोग में है
[0:34] 100.00% 36/36 स्नैपशॉट्स
[0:26] 100.00% 4555/4555 पैक फिर से लिखे गए (175 पैक/सेकंड)
[0:21] 151 अनुक्रमणिका फ़ाइलें
[0:01] 100.00% 11401 / 11401 पैक हटाए गए

3,752,505 पैक रेपो। यह भी ध्यान देने योग्य है कि मेमोरी उपयोग गुब्बारे ~ 1GB RSS से 8GB RSS तक "डेटा खोजें जो अभी भी 14 स्नैपशॉट के लिए उपयोग में है" चरण में है। रेस्टिक अंततः ~16GB RSS पर समाप्त होता है। शायद अपरिहार्य, बड़े रेपो आकार को देखते हुए:

रेपो के लिए लोडिंग इंडेक्स
[0:33] 100.00% 1188/1188 अनुक्रमणिका फ़ाइलें

डेटा ढूंढें जो अभी भी 14 स्नैपशॉट के लिए उपयोग में है
[2:12] 100.00% 14/14 स्नैपशॉट
[49:07] 100.00% 339187/339187 पैक फिर से लिखे गए (115 पैक/सेकंड)
नई अनुक्रमणिका सहेजा जा रहा है
[10:59] 1176 अनुक्रमणिका फ़ाइलें
1188 पुरानी अनुक्रमणिका फ़ाइलें हटाएं
[4:51] 100.00% 409728 / 409728 पैक हटाए गए

@cbane , मैं क्षमा चाहता हूँ। प्रून स्पीड पर रेड हेरिंग - जब मैं कुछ स्वतंत्र प्रोफाइलिंग कर रहा था तो मैंने देखा कि दो रेपो अलग-अलग AZ में थे, इसलिए अंतर पूरी तरह से अधिक दूर AZ के लिए अलग विलंबता के कारण था।

हमारे बड़े रेपो (20.791 टीआईबी, 40,522,693 ब्लॉब्स) में, हमें "अभी भी उपयोग में आने वाले डेटा खोजें" चरण में छंटाई करते समय निम्न त्रुटि मिल रही है:

पेड़ 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 भंडार में नहीं मिला
github.com/restic/restic/internal/repository.(Repository).LoadTreeआंतरिक/भंडार/भंडार.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3आंतरिक/रेस्टिक/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3आंतरिक/रेस्टिक/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4आंतरिक/रेस्टिक/find.go:89gopkg.in/tomb%2ev2.( Tomb).run
वेंडर/gopkg.in/tomb.v2/tomb.go:163
रनटाइम.गोएक्जिट
/usr/lib/golang/src/runtime/asm_amd64.s:1337

सभी बैकअप सफलतापूर्वक पूर्ण हो गए हैं और एक रेस्टिक चेक कोई त्रुटि नहीं लौटाता है।

यहाँ करने लायक कोई अतिरिक्त खुदाई, @cbane ?

एक पुनर्निर्माण-सूचकांक ने प्रून को सफल होने दिया। सुनिश्चित नहीं है कि प्रून को अधिक लचीला बनाने का कोई अच्छा तरीका है, इसलिए यह मूल रूप से इस मुद्दे का ध्यान रख सकता है।

हम्म, आज फिर वही त्रुटि मिली। एक पुनर्निर्माण-सूचकांक के साथ हल किया गया, लेकिन मुझे आश्चर्य हो रहा है कि क्या प्रून ही समस्या पैदा कर रहा है। एक रेस्टिक चेक हर बार साफ होकर वापस आता है।

पेड़ 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 भंडार में नहीं मिला
github.com/restic/restic/internal/repository.(Repository).LoadTreeआंतरिक/भंडार/भंडार.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3आंतरिक/रेस्टिक/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3आंतरिक/रेस्टिक/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4आंतरिक/रेस्टिक/find.go:89gopkg.in/tomb%2ev2.( Tomb).run
वेंडर/gopkg.in/tomb.v2/tomb.go:163
रनटाइम.गोएक्जिट
/usr/lib/golang/src/runtime/asm_amd64.s:1337

हम बैकअप अखंडता को सत्यापित करने के लिए, दैनिक स्पॉट फ़ाइल पुनर्स्थापना को पूरक करने के लिए सप्ताह में एक बार पूर्ण पुनर्स्थापना करते हैं।

जबकि रेस्टिक चेक ने बैकअप के साथ कोई समस्या नहीं दिखाई, एक लापता ब्लॉब के कारण पूर्ण पुनर्स्थापना विफल हो गई। तो ऐसा लगता है कि जिस तरह से नहीं होना चाहिए था, उस तरह से कुछ काट दिया गया हो सकता है।

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

दुर्भाग्य से, रेपो के आकार के कारण स्टॉक प्रून के साथ परीक्षण असंभव है।

हम अभी के लिए ईबीएस स्नैपशॉटिंग पर वापस जा रहे हैं, लेकिन इस मुद्दे और अन्य की निगरानी करना जारी रखेंगे और यह परीक्षण करने में प्रसन्न होंगे कि यह कहां समझ में आता है!

मैंने एक छोटा पीआर #2507 जोड़ा जिससे स्थिति में सुधार होना चाहिए। यदि आप में से कुछ इस पर कुछ परीक्षण चला सकें तो मैं आभारी रहूंगा...
धन्यवाद!

प्रून कोड के माध्यम से पढ़ना - रीपैकिंग बूँदें पढ़ता है और फिर नए पैक को क्रमिक रूप से सहेजता है। यदि आप उस नेटवर्क पर रीपैकिंग कर रहे हैं जो बाधा बनने जा रहा है।

@DurvalMenezes स्थानीय नेटवर्क पर या इंटरनेट पर आपका NAS है? यदि स्थानीय नेटवर्क पर आप इसे वाईफाई या ईथरनेट के माध्यम से कनेक्ट करते हैं?

ऐसा लगता है कि एक आसान जीत नेटवर्क पर पढ़ने वाले ब्लब्स/सेविंग पैक को समानांतर करना होगा।

अलग-अलग, मुझे आश्चर्य है कि इसके बजाय कोशिश करने और प्रून वृद्धिशील बनाने के लिए एक बेहतर रणनीति होगी। डुप्लीकेसी के दो चरणों वाले जीवाश्म संग्रह जैसा कुछ: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

अलग-अलग, मुझे आश्चर्य है कि इसके बजाय कोशिश करने और प्रून वृद्धिशील बनाने के लिए एक बेहतर रणनीति होगी। डुप्लीकेसी के दो चरणों वाले जीवाश्म संग्रह जैसा कुछ: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

इस विषय पर चर्चा के लिए कृपया #1141 देखें।

पीआर # 2513 से दो नए कमांड 'क्लीनअप-इंडेक्स' और 'क्लीनअप-पैक' से भी स्थिति में काफी सुधार होना चाहिए। यदि आपका रेपो समझदार है तो इन आदेशों के साथ आप बिना रीपैकिंग के एक प्रून कर सकते हैं।

इसलिए मैंने गलती से दो काम किए, मैंने 1 के बजाय एक घंटे में 11 बार एक घंटे का बैकअप चलाया, और मैंने पिछले 384 दिनों या उससे भी ज्यादा समय तक अपनी भूल नौकरी नहीं चलाई। मेरे पास 101417 स्नैपशॉट हैं। मुझे लगा कि इसे भूलना/छंटना बहुत धीमा होगा, मुझे लगता है कि मैं इसे हटाने जा रहा हूं।

आप #2718 आज़मा सकते हैं - हालांकि, स्नैपशॉट को "भूलने" के लिए कोई सुधार नहीं है।
अगर भूलने का कदम आपकी परेशानी है तो मैं आपको सलाह दूंगा:

• पता लगाएँ कि आप कौन से स्नैपशॉट रखना चाहते हैं, उदाहरण के लिए अपने पिछले बैकअप लॉग को देखकर या बस दूसरा बैकअप बनाकर।
• अपनी रिपॉजिटरी के /snapshots dir . से मैन्युअल रूप से उन सभी फाइलों को हटा दें
• उसके बाद, prune चलाएँ (यदि आप #2718 के साथ चाहते हैं)

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

मैं वास्तव में इस शाखा को आजमाना चाहता हूं (या वास्तव में, काश इसे मास्टर में खींचा जाता)। मैंने परीक्षण करने और प्राप्त करने की कोशिश की

घातक: कॉन्फ़िग फ़ाइल खोलने में असमर्थ: स्टेट: आपके द्वारा प्रदान किया गया AWS एक्सेस कुंजी आईडी हमारे रिकॉर्ड में मौजूद नहीं है।

मास्टर बिल्ड का उपयोग करके बिना किसी समस्या के काम करता है। मैं बिना किसी समस्या के https://github.com/restic/restic/pull/2340 पर शाखा का उपयोग करने में सक्षम था।

मैं इस शाखा का उपयोग एनएफएस माउंटेड रिपोजिटरी पर करने में सक्षम हूं, केवल एडब्ल्यूएस संग्रहीत रेपो गैर-कार्यात्मक है। मुझे नहीं पता कि समस्या निवारण कैसे करें ...

परवाह किए बिना सभी अच्छे काम के लिए धन्यवाद

@vtwaldo21 आपने किस शाखा को आजमाया? क्या यह #2718 था?
आपका त्रुटि संदेश इंगित करता है कि आपको अपने AWS क्रेडेंशियल में कुछ समस्या है। यह यह भी समझा सकता है कि एनएफएस ने बिना किसी समस्या के काम क्यों किया।

क्या अन्य रेस्टिक कमांड आपके साथ एडब्ल्यूएस रिपोजिटरी काम करते हैं?

@aawsome , मैं एक बेवकूफ हूँ और शाखा / अंक संख्या और वास्तव में भ्रमित चीजों को स्थानांतरित कर दिया। क्षमा मांगना।

शाखा 2718 ने ठीक काम किया (एडब्ल्यूएस और एनएफएस समर्थित रेपो दोनों पर)। मैं निश्चित रूप से नहीं कह सकता कि यह तेज़ था या नहीं क्योंकि यह अभी भी चल रहा है
शाखा 2340, इस मुद्दे के साथ एक था और मैं इस मंच सूत्र में क्यों था।

शाखा 2340 0.9.5 आधारित है इसलिए थोड़ी पुरानी है लेकिन बहुत खराब नहीं है। मैं इस तरह सरल परीक्षण कर रहा था:

रेस्टिक बाइनरी पथ है बस आरपीएम (0.9.6) के माध्यम से स्थापित किया गया है

रेस्टिक स्नैपशॉट
[काम करता है]
रेस्टिक.2718/रेस्टिक स्नैपशॉट्स
[काम करता है]
रेस्टिक.2340/रेस्टिक स्नैपशॉट्स
घातक: कॉन्फ़िग फ़ाइल खोलने में असमर्थ: स्टेट: आपके द्वारा प्रदान किया गया AWS एक्सेस कुंजी आईडी हमारे रिकॉर्ड में मौजूद नहीं है।

तो जब त्रुटि एडब्ल्यूएस क्रेडेंशियल्स के साथ कुछ का तात्पर्य है, मैं सचमुच बिना किसी परिवर्तनीय परिवर्तन के कमांड को बैक टू बैक चला रहा हूं। ऐसा लगता है कि इस शाखा में कुछ और गड़बड़ है।

मेरे आलूबुखारे को ~2टीबी रेपो के लिए कई दिन लगते हैं, इसलिए 2718 और 2340 दोनों को मास्टर में विलय करने में बहुत दिलचस्पी है

@cbane आपके सभी कार्यों के लिए बहुत-बहुत धन्यवाद! हमने अभी-अभी #2718 को मर्ज किया है, जो प्रून कोड को फिर से काम करता है, और मुझे लगता है कि यह इस मुद्दे के साथ-साथ #2340 को भी हल करता है।

मुझे इस बात का बहुत खेद है कि हमने आपके योगदान को कैसे संभाला, मुझे आशा है कि आप मेरी क्षमायाचना स्वीकार कर सकते हैं। :निराश:

मैंने @MichaelEischer से बात की है, उन्होंने उल्लेख किया है कि PR #2340 में और भी विचार शामिल हैं जिन्हें अभी तक लागू नहीं किया गया है, इसलिए मैं इस मुद्दे को फिर से खोल रहा हूं।

@cbane क्या आप इन विचारों को वर्तमान कोड में मिलाने के लिए हमारे साथ काम करने में रुचि रखते हैं? मैं पूरी तरह से समझ सकता हूं कि यदि नहीं, तो हम आपके पीआर के माध्यम से जाएंगे और उन्हें स्वयं निकालेंगे :)

हमने कल भी एक छोटी चर्चा की थी और यह पहचानने की कोशिश की थी कि क्या गलत हो सकता है, ताकि हम अगली बार बेहतर कर सकें। हमारे द्वारा पहचाने गए कुछ बिंदु थे:

• पीआर ने कोड में एक अत्यधिक संवेदनशील क्षेत्र को बदल दिया (छंटनी, जो अंततः डेटा को हटा देती है), इसलिए इसे अतिरिक्त जांच की आवश्यकता है
• @MichaelEischer और साथ ही @aawsome ने PR की समीक्षा करने की कोशिश की और कहा कि यह बहुत बड़ा है
• पीआर सिर्फ दो कमिट था, उनमें से एक ने सभी कोड को दूसरे के साथ बदल दिया, पूरी तरह से अलग कोड, इसकी समीक्षा करना बहुत कठिन है
• पीआर में कम से कम 4-5 अलग-अलग विचार और सुधार शामिल थे, जिससे समीक्षा करना और भी कठिन हो जाता है

कोई और चीज जो मुझे याद आई?

#2340 से cmd_prune.go में किए गए परिवर्तन जहां तक ​​मैं देख सकता हूं पूरी तरह से #2718 और #2842 @aawsome द्वारा प्रतिस्थापित किया गया है। #3006 भी index/index.go परिवर्तनों को प्रतिस्थापित करता है।

मैंने checker.go से अत्यधिक समानांतर ट्री वॉकिंग कार्यान्वयन निकाला है (देखें https://github.com/MichaelEischer/restic/tree/streamtrees), जो कुछ के साथ समानांतर FindUsedBlobs को लागू करने की अनुमति देता है कोड की अतिरिक्त पंक्तियाँ। यह कॉपी कमांड के लिए भी पुन: प्रयोज्य है। मेरी उल्लिखित शाखा इंडेक्स और स्नैपशॉट लोडिंग को समानांतर करने के लिए उपयोग किए गए कोड को भी एकीकृत करती है। मैं शाखा को छोटे पीआर में विभाजित करूँगा।

ऐसा लगता है कि #2340 के शेष भाग के रूप में आईओ/सीपीयू समांतरता को स्वचालित रूप से समायोजित करने के लिए बैकएंड कनेक्शन गिनती और GOMAXPROCS का उपयोग छोड़ दिया गया है।

मैंने देखा है कि न तो #2340 और न ही अन्य प्रून पीआर वर्तमान में पुनर्लेखित अनुक्रमणिका के अपलोड को समानांतर करते हैं।