Restic: التعامل مع الخوخ الكبير أكثر فعالية

مع أداء عمليات الاستعادة الخاصة بوحدات repos / repos الكبيرة مع الملفات الكبيرة التي تم حلها الآن بواسطة فرعifedorenko خارج الطلب ، يبدو أن هذا هو الصخرة التالية لاستخدام restic في بيئات متعددة تيرابايت حيث لا يتوفر الريبو محليًا القرص ولا يتم الوصول إليه عبر خادم REST على واجهة الاسترجاع.

حاليًا ، يتم تقليم فارغ (تشذيب لقطة كانت متطابقة بنسبة 100٪ مع لقطة سابقة) مقابل الريبو في دلو S3 المحلي من AZ على مثيلات AWS المتطورة ذات النطاق الترددي النظري 10 جيجابت / ثانية يعمل على:

1) بناء مؤشر جديد - ~ 160 رزمة / ثانية
2) العثور على البيانات لا تزال قيد الاستخدام - إجمالي 56 ثانية
3) إعادة كتابة العبوات - حوالي 3 عبوات / ثانية

160 عبوة / ثانية بطيئة ، لكنها لا تزال مقبولة (وقت تشغيل حوالي 80 دقيقة مقابل إعادة شراء سعة 3 تيرابايت).

لكن إعادة الكتابة @ 3 حزم / ثانية ستعمل لمدة 10 ساعات تقريبًا ، حتى بالنسبة لتقليم noop الخاص بي (سيحذف 0 حزمة ويعيد كتابة 111098 حزمة ، وهذا يحرر 180.699 جيجا بايت). للحصول على تقليم مفيد على إعادة شراء كبيرة ، يمكنك تجميد النسخ الاحتياطية الجديدة لمدة تزيد عن 24 ساعة.

يبدو أن إعادة كتابة الحزمة تحدث حاليًا في مؤشر ترابط واحد ، لذا فإن السماح بتشغيله عبر عدة عمال قد يساعد قليلاً ، حتى إذا تم الحفاظ على النسخة الحالية ثم نهج التطهير.

أنا شخصياً لن أقضي الوقت في تحسين تطبيق تقليم الحجب الحالي ، أعتقد أن التقليم غير المحظور هو حل أفضل على المدى الطويل.

لقد كنت أعمل على هذا مؤخرًا. هذا ما فعلته:

• قم بتحميل الفهرس الحالي بدلاً من مسح جميع الحزم (ثم قم بفحص أي حزم لم تكن موجودة في الفهرس)
• مسح اللقطات المتوازية للنقاط المستعملة
• إعادة كتابة العبوات المستخدمة جزئيًا بشكل متوازي
• اكتب الفهرس الجديد باستخدام معلومات الفهرس الموجودة بالفعل في الذاكرة

أنا أعمل حاليًا على اكتشاف مستوى التوازي الذي يجب استخدامه لإعادة كتابة الحزم المستخدمة جزئيًا (أخطط لبناء هذا على عدد الاتصالات المكون للواجهة الخلفية). أحتاج أيضًا إلى إجراء المزيد من الاختبارات في سيناريوهات الخطأ المختلفة.

فيما يلي بعض أرقام الأداء (باستخدام مستودع به 875 جيجا بايت من البيانات ، وحوالي 180.000 حزمة ، و 36 لقطة ، باستخدام خادم استرجاع الاسترجاع كخلفية):

• الكود الحالي:
  
  
  
  • 35-40 دقيقة (كل واحدة) لإنشاء الفهرس في بداية ونهاية التقليم (70-80 دقيقة إجمالاً)
  
  
  • 4-5 دقائق للعثور على النقط المستعملة
  
  
  • بضع ثوانٍ لإعادة كتابة الحزم المستخدمة جزئيًا
  
  
• التغييرات التي أجريتها حتى الآن:
  
  
  
  • بضع ثوانٍ لتحميل الفهرس الحالي (أطول إلى حد ما إذا احتاج إلى مسح الحزم غير المفهرسة)
  
  
  • أقل من دقيقتين للعثور على النقط المستعملة
  
  
  • بضع ثوان لكتابة الفهرس الجديد
  
  

أخطط أيضًا لإعداد حالة اختبار تم إنشاؤها والتي ستتضمن الكثير من إعادة كتابة الحزمة.

كورتني:

تبدو واعدة للغاية! تريد أن تؤكد أن هذا هو الفرع الذي تعمل فيه؟ أنا سعيد للاختبار.

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

لا ، هذا الفرع هو جزء من مفترق طرق من المستودع الرئيسي. لم أدفع تغييراتي في أي مكان عام حتى الآن. من المفترض أن أتمكن من دفع إصدار عملي قيد التقدم إلى GitHub في غضون أيام قليلة حتى تتمكن من تجربته.

حسنًا ، لدي إصدار يجب أن يكون جاهزًا ليقوم الآخرون بتجربته. إنه في هذا الفرع: https://github.com/cbane/restic/tree/prune-speedup

القيود الحالية:

• لم أقم بتطبيق أي إعداد تلقائي لعدد عمال إعادة حزم. في الوقت الحالي ، قم بتعيين متغير البيئة RESTIC_REPACK_WORKERS على عدد العمال الذين تريد استخدامهم. سيكون افتراضيًا إلى 4 إذا لم يتم تعيينه.
• أحتاج إلى العمل على معالجة الأخطاء عند إعادة التعبئة. لم أجري أي تغييرات حقيقية من إعادة التعبئة الحالية ذات الخيط الواحد ؛ أحتاج إلى إلقاء نظرة على حالات الخطأ المختلفة والتأكد من أن إجراء إعادة التعبئة بالتوازي لا يسبب أي مشاكل.

اممم ، هذا يبدو مذهلا. شكرا لك على عملك!

لقد اختبرت هذا قليلاً بنسخة 3TB + repo في Amazon S3 وحتى الآن يبدو رائعًا. تكتمل الآن عملية إعادة حزم التقليم التي كان من الممكن أن تستغرق أسابيع في أقل من ساعة ، وذلك باستخدام نظام EBS البطيء نسبيًا كمساحة tmp.

تغيير حقيقي للعبة هنا! عمل رائع ،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 مستخدمًا.)
• تعديلات طفيفة للعثور على النقط المستعملة.
• بالتوازي مع مسح حزم غير معروفة.

ما زلت أرغب في القيام ببعض الأعمال الإضافية للعثور على النقط المستعملة. حاليًا ، تتم معالجة كل لقطة بواسطة عامل واحد. يمكن أن يترك هذا موارد وحدة المعالجة المركزية غير مستخدمة إذا كان هناك لقطات أقل من وحدات المعالجة المركزية ، أو إذا كانت هناك اختلافات كبيرة في الحجم بين اللقطات. أرغب في نشر معالجة الشجرة الفرعية عبر مختلف العمال ؛ أعتقد أنني أعرف كيفية القيام بذلك ، فأنا فقط بحاجة إلى تنفيذه بالفعل.

أميل إلى الاستمرار في مناقشة الأشياء حول هذه المشكلة (أو طلب السحب المستقبلي لذلك) ، بحيث يبقى كل شيء هنا في المستودع الرئيسي بدلاً من الانتشار.

اختبرت للتو. إنه يحل الانهيار في نهاية إعادة التعبئة ويعمل جيدًا حقًا.

المكان الإضافي الوحيد الذي يمكن أن يستفيد من زيادة التوازي هو حذف الحزم ، والتي هي حاليًا مترابطة واحدة.

هذا يعض بشدة أثناء التقليم الأول من الريبو الذي لم يكن قابلاً للتقليم سابقًا ، نظرًا لوجود عدد كبير من الحزم التي تحتاج إلى الحذف.

حتى مع الحذف المترابط المفرد ، فإن عملية النسيان / التقليم اليومية مقابل مستودع 1.7 تيرابايت و 356 ألف حزمة يعيد كتابة 14.7 كيلو حزم ويحذف 33 ألف حزمة يستغرق الآن أقل بقليل من 20 دقيقة.
في السابق ، كان من المستحيل التقليم على الإطلاق.

عمل ممتاز شكرا لك!

حسنًا ، لدي إصدار آخر متاح. التغيير الحقيقي الوحيد هذه المرة هو أنه يحذف الآن الحزم غير المستخدمة بالتوازي (بالإضافة إلى بعض التعديلات الطفيفة على بعض التغييرات السابقة). لقد قمت بتنفيذ مسح اللقطة المعدل ، لكنه لم يوفر تسريعًا كافيًا ولم تكن هناك طريقة جيدة لإبلاغ المستخدم بالتقدم ، لذا قمت بإزالته مرة أخرى.

أخطط لفتح طلب سحب لهذا قريبًا ، بافتراض عدم تعطل شيء. (سأقوم بتنظيف السجل أولاً ، رغم ذلك). @ fd0 ، هل تريد إلقاء نظرة على هذا أولاً؟

عملت بشكل رائع في تشغيلنا الاختباري. أعد كتابة حزم 30 ألفًا في 225 ثانية ، وحذف 73 ألف حزمة في 50 ثانية.

إجمالي وقت التشغيل مقابل 1.74TiB repo في S3 مع 32 لقطة متبقية كانت تزيد قليلاً عن 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! استغرق التقليم القياسي حوالي 55 ساعة لتقليم ~ 860 جيجابايت 12000+ لقطة. مع أسلوبك الموازي الأكثر عدوانية ، انخفض الأمر إلى ما يزيد قليلاً عن 3 ساعات.

مرحبا cbane ، عمل رائع!

تشغيل PR هنا على Debian 9 amd64 ، المترجمة مع Go 1.12.1 ، والحصول على الخطأ التالي بعد 220 دقيقة من التشغيل على الريبو الخاص بي 30 تيرابايت:

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. المزيد أدناه:

هل قمت بتقليمه من قبل؟

كلا ، هذا هو أول تقليم لي. قصة قصيرة طويلة: يحتوي الريبو الخاص بي على 95 لقطة تقريبًا من 3 شجيرات ترابية محلية على NAS الخاص بي ؛ يبلغ إجمالي هذه الأشجار الترابية الثلاثة حوالي 30 تيرابايت و 60 مليون ملف / ملفات فرعية ، وقد استغرق الأمر وقتًا أطول وأطول للنسخ الاحتياطي ، لدرجة أن النسخ الاحتياطي للبيانات الجديدة لمدة 24 ساعة فقط (أقل من 10 جيجابايت) كان يستغرق أكثر من 24 ساعة للتشغيل. كانت النصيحة في المنتدى هي تشغيل restic forget (وهو ما فعلته ، ولم يتبق سوى آخر 3 لقطات) ثم restic prune ، وهو ما فعلته أولاً باستخدام restic 0.9.5 (ولكن تم إحباطه بعد ~ ~ 24 ساعة بسبب OOM). قمت بعد ذلك بترقية الجهاز (جهاز VM على Google Compute Cloud) إلى ضعف ذاكرة الوصول العشوائي ، ثم استخدمت العلاقات العامة الخاصة بك ، والتي أعطت الخطأ أعلاه.

هل تحقق restic ينجح؟ إذا لم يحدث ذلك ، فيجب أن يمنحك فكرة أكثر تفصيلاً عن الخطأ.

أنا أقوم بتشغيل restic check لآخر 90 ساعة (باستخدام العلاقات العامة أيضًا) ، وقد أعطاني هذا الناتج حتى الآن: restic-check-PARTIAL_output.txt

كما هو مذكور في نهاية الملف أعلاه ، عرض restic check أحدث رسائله ("تحقق من اللقطات والأشجار والنقاط") منذ أكثر من 3 أيام ... بدأت أتساءل أنه عالق ولن ينتهي أبدًا : - / في الواقع ، يظهر "strace" في العملية أنه يفتح نفس ملف ذاكرة التخزين المؤقت المحلي مرارًا وتكرارًا:

التاريخ ؛ strace -t -f -p 2608 -e openat 2> & 1 | grep openat | egrep -v غير مكتمل \ | مستأنف | رأس
الثلاثاء 23 يوليو ، 00:41:59 بالتوقيت العالمي المنسق 2019
[معرف المنتج 26508] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2608] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 10
[معرف المنتج 2615] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 5482] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2615] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 3688] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 5482] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 10
[معرف المنتج 2608] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 11
[معرف المنتج 2638] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2638] 00:41:59 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

الثلاثاء 23 تموز (يوليو) 10:14:27 بالتوقيت العالمي المنسق 2019
[معرف المنتج 2632] 10:14:27 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2639] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2634] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2613] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2634] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 3688] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2617] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 3688] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2634] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
[معرف المنتج 2611] 10:14:28 openat (AT_FDCWD "/ تمة / restic إجراءات التخزين المؤقت لل370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / بيانات / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"، O_RDONLY | O_CLOEXEC) = 5
""

قد تكون قادرًا على الاسترداد إلى حد ما عن طريق تشغيل فهرس إعادة البناء restic ثم تشغيل نسخة احتياطية جديدة. إذا كان أي شيء في الحزم المفقودة لا يزال متاحًا في الموقع الذي يتم نسخه احتياطيًا ، فستضيفه نسخة احتياطية جديدة إلى المستودع مرة أخرى. هذا قد يجعل النسخ الاحتياطية الموجودة لديك تعمل مرة أخرى

أعتقد أنني سأحاول هذا بعد ذلك ؛ إذا لم ينتهِ هذا restic check خلال الـ 24 ساعة القادمة ، فسأشير إليه ثم أشغل restic rebuild-index . لمؤشر إعادة البناء ، هل يجب أن أستخدم هذا PR؟ رئيس restic-master؟ أو أي شيء آخر؟

شكرا لك مرة أخرى،
- دورفال.

نعم ، هذا لا يبدو واعدًا. من المحتمل أن يكون أفضل شيء تفعله هو عمل restic rebuild-index ، ثم تشغيل نسخ احتياطية جديدة لأدلةك الثلاثة ، ثم نسيان جميع اللقطات الأخرى. بعد ذلك ، يجب أن تكون قادرًا على إجراء restic prune بنجاح.

لم ألمس رمز rebuild-index ، لذا يمكنك فعل ذلك بأي إصدار تريده.

cbane ، فقط لإبقائك على اطلاع: لقد بدأت restic rebuild-index باستخدام PR الخاص بك قبل 5 أيام (أتفهم أن أي إصدار سيفعل ، لكن استخدامك يجعل الأمور أكثر بساطة) وهو يعمل منذ ذلك الحين. بعد الأيام القليلة الأولى من اليأس (عندما بدا أن الاستقراء من النسب المئوية يشير إلى أنه سيستمر لأكثر من 30 يومًا) ، يبدو أنه قد اكتسب بعض السرعة ويجب أن يستمر لمدة 10 أيام أخرى أو نحو ذلك (على الأقل في الوقت الحالي) طور "عد الملفات في الريبو").

بافتراض أن هذا rebuild-index ينتهي بشكل جيد ، فإن الخطة هي تشغيل restic prune مع PR الخاص بك. سوف تتيح لك معرفة كيف ستسير الامور.

إبقاء الجميع على اطلاع دائم: انتهى ائتماني المجاني على GCloud البالغ 300 دولار ، والتهمته بالكامل 104 غيغابايت 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 من الإخراج الذي نشرته ، يبدو أنك لا تستخدم نسختي المحسنة بالفعل. هذا هو الناتج الذي أحصل عليه عندما أقوم بتقليم مستودعي الكبير على Backblaze B2:

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 ؟

سأكون ممتنًا جدًا لهذا التحسين لجعله إصدارًا رسميًا أيضًا. لقد أصبح دوران النسخ الاحتياطي بطيئًا جدًا لدرجة أن restic لم يعد خيارًا حقًا ، للأسف.

cbane ، عنصر واحد بالتأكيد ليس مانعًا ولكنني أحسب أنني سأضع علامة عليه: إعادة كتابة حزمة التقليم تصبح أبطأ مع نمو عمليات إعادة الشراء.

على سبيل المثال ، تعيد خطوة إعادة كتابة الحزمة لـ 3،984،097 حزمة إعادة كتابة الحزم بسرعة 110 عبوات / ثانية على i3.8xlarge بالتحدث إلى دلو S3 في نفس AZ.

نفس المثيل + مخزن النسخ الاحتياطي مع إعادة كتابة أصغر (450،473) يعيد كتابة 200 حزمة / ثانية.

pmkane ، هل هذا التفاوت في السرعة موجود حتى لو كانوا يعيدون كتابة نفس عدد الحزم؟ أم أنه موجود دائمًا بغض النظر عن عدد الحزم التي تتم إعادة كتابتها؟ أيضا ، هل هو مجرد إعادة كتابة الحزمة ، أم أن المراحل الأخرى تتباطأ أيضًا؟

لا يوجد شيء واضح في الكود يمكن أن يبطئه مع زيادة حجم المستودع. لقد أضفت دعم التنميط إلى مرحلة إعادة كتابة الحزمة في إصداري المحلي للمساعدة في تعقب مصدر البطء. ومع ذلك ، فإن أكبر مستودع لدي هو فقط حوالي 200000 حزمة ، وهذا لا يمنحني مقارنة جيدة لما تراه. هل ستكون على استعداد لتشغيله مع تمكين التوصيف وإتاحة ملفات الإخراج؟

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 لقطة". انتهى المطاف بـ Restic في ~ 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.go: 711github.com/restic/restic/internal/restic.FindUsedBlobs.func3داخلي / restic / find.go: 52github.com/restic/restic/internal/restic.FindUsedBlobs.func3داخلي / restic / find.go: 74github.com/restic/restic/internal/restic.FindUsedBlobs.func4داخلي / restic / find.go: 89gopkg.in/tomb٪2ev2. ( قبر)
البائع / 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.go: 711github.com/restic/restic/internal/restic.FindUsedBlobs.func3داخلي / restic / find.go: 52github.com/restic/restic/internal/restic.FindUsedBlobs.func3داخلي / restic / find.go: 74github.com/restic/restic/internal/restic.FindUsedBlobs.func4داخلي / restic / find.go: 89gopkg.in/tomb٪2ev2. ( قبر)
البائع / gopkg.in / tomb.v2 / tomb.go: 163
وقت التشغيل
/usr/lib/golang/src/runtime/asm_amd64.s:1337

نقوم باستعادة كاملة مرة واحدة في الأسبوع للتحقق من سلامة النسخ الاحتياطي ، لاستكمال عمليات استعادة الملفات الموضعية اليومية.

بينما لم يُظهر فحص restic أي مشاكل في النسخة الاحتياطية ، تفشل عمليات الاستعادة الكاملة بسبب فقدان blob. لذلك يبدو أن شيئًا ما قد يكون قد تم تقليمه على طول الطريق الذي لا ينبغي أن يحدث.

من غير الواضح ما إذا كان هناك خطأ في فرع التسريع أو شيء ما في كود التقليم الأساسي أو أي شيء آخر تمامًا. ليس لدي حالة اختبار رائعة قابلة للتكرار ، للأسف ، ولكن هذه هي المرة الثانية التي نرى فيها هذا النوع من فساد إعادة الشراء مع أكبر إعادة شراء لدينا. لم تظهر عمليات إعادة الشراء الأصغر الخاصة بنا أي مشاكل.

لسوء الحظ ، فإن الاختبار باستخدام الأوراق المالية أمر مستحيل ، نظرًا لحجم المستودعات.

سنعود إلى لقطة EBS ، في الوقت الحالي ، لكننا سنواصل مراقبة هذه المشكلة وغيرها ، ويسعدنا اختبار المكان المناسب!

أضفت رقم PR صغير 2507 والذي من شأنه تحسين الوضع. سأكون ممتنًا لو تمكن بعضكم من إجراء بعض الاختبارات على هذا ...
شكرا!

القراءة من خلال كود التقليم - إعادة التعبئة يقرأ النقط ثم يحفظ الحزم الجديدة بشكل متسلسل. إذا كنت تقوم بإعادة التعبئة عبر الشبكة ، فسيكون ذلك بمثابة عنق الزجاجة.

DurvalMenezes هل NAS الخاص بك على الشبكة المحلية أو عبر الإنترنت؟ إذا كنت على الشبكة المحلية ، هل تتصل بها عبر wifi أو ethernet؟

يبدو أن الفوز السهل سيكون بموازاة قراءة النقط / حزم الحفظ على الشبكة.

بشكل منفصل ، أتساءل عما إذا كانت الإستراتيجية الأفضل هي محاولة جعل التقليم تزايديًا بدلاً من ذلك. شيء مثل مجموعة الأحافير المكونة من خطوتين للنسخ: 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 لمناقشة هذا الموضوع.

يجب أن يؤدي الأمران الجديدان "فهرس التنظيف" و "حزم التنظيف" من PR # 2513 إلى تحسين الموقف كثيرًا. باستخدام هذه الأوامر ، يمكنك إجراء تقليم دون إعادة التعبئة إذا كان الريبو الخاص بك سليمًا ..

لذلك قمت بعمل شيئين عن طريق الخطأ ، قمت بتشغيل نسخة احتياطية كل ساعة 11 مرة في الساعة بدلاً من 1 ، ولم أقم بتشغيل وظيفتي المنسية لآخر 384 يومًا أو نحو ذلك. لدي 101417 لقطة. كنت أحسب أنه سيكون بطيئًا جدًا في نسيان / تقليم هذا ، أعتقد أنني سأحذفه.

يمكنك تجربة # 2718 - ومع ذلك ، لا يوجد تحسن "لنسيان" اللقطات.
إذا كانت خطوة النسيان هي مشكلتك ، فإنني أنصحك بما يلي:

• اكتشف اللقطات التي تريد الاحتفاظ بها ، على سبيل المثال من خلال البحث في سجلات النسخ الاحتياطي الأخيرة أو مجرد عمل نسخة احتياطية أخرى.
• احذف جميع الملفات يدويًا من المستودع الخاص بك /snapshots dir
• بعد ذلك ، قم بتشغيل prune (إذا كنت تريد باستخدام # 2718)

قصدت الاحتفاظ بها لبضعة أيام فقط ، لذلك سأحذف الدليل بالكامل على S3 وأبدأ من جديد. لقد بدأت عملية النسيان واستغرقت وقتًا طويلاً ، واعتقدت أن الفرع الجديد سيساعد (لا يبدو كذلك) ، أو على الأقل قد يجدها شخصًا مسليًا.

أريد حقًا تجربة هذا الفرع (أو أتمنى حقًا أن يتم سحبه إلى درجة الماجستير). حاولت الاختبار والحصول عليها

فادح: غير قادر على فتح ملف التكوين: Stat: معرف مفتاح AWS Access الذي قدمته غير موجود في سجلاتنا.

يعمل بدون مشكلة باستخدام البناء الرئيسي. تمكنت أيضًا من استخدام الفرع على https://github.com/restic/restic/pull/2340 بدون مشكلة.

أنا قادر على استخدام هذا الفرع في مستودع NFS مُثبَّت ، فقط مستودع AWS المخزن لا يعمل. ليس لدي أي فكرة عن كيفية استكشاف الأخطاء وإصلاحها ...

شكرا على كل العمل الجيد بغض النظر

@ vtwaldo21 أي فرع جربته؟ هل كانت # 2718؟
تشير رسالة الخطأ إلى أن لديك بعض المشاكل مع بيانات اعتماد AWS الخاصة بك. قد يفسر هذا أيضًا سبب عمل NFS بدون مشكلة.

هل تعمل أوامر restic الأخرى معك في مستودع AWS؟

aawsome ، أنا أحمق وقمت بتحويل أرقام الفرع / الإصدار والأشياء المربكة حقًا. آسف.

عمل الفرع 2718 بشكل جيد (على كل من مستودعات AWS و NFS المدعومة). لا أستطيع أن أقول بشكل قاطع أنه كان أسرع أم لا لأنه لا يزال قيد التشغيل
كان الفرع 2340 هو صاحب المشكلة ولماذا كنت في موضوع المنتدى هذا.

يعتمد الفرع 2340 على 0.9.5 لذا فهو أقدم قليلاً ولكن ليس سيئًا للغاية. كنت أقوم بإجراء اختبارات بسيطة مثل هذا:

ثنائي restic هو المسار مثبت للتو عبر RPM (0.9.6)

لقطات restic
[يعمل]
restic.2718 / لقطات restic
[يعمل]
restic.2340 / لقطات restic
فادح: غير قادر على فتح ملف التكوين: Stat: معرف مفتاح AWS Access الذي قدمته غير موجود في سجلاتنا.

لذا ، بينما يشير الخطأ إلى شيء ما باستخدام بيانات اعتماد AWS ، فأنا حرفيًا أقوم بتشغيل الأوامر مرة أخرى إلى الوراء دون أي تغييرات متغيرة. يبدو أن هناك خطأ آخر في هذا الفرع.

يستغرق البرقوق الخاص بي أيامًا للحصول على ريبو بسعة 2 تيرابايت ، لذا فأنت مهتم جدًا بدمج كل من 2718 و 2340 في نسخة رئيسية

cbane شكرا جزيلا لك على كل عملك! لقد دمجنا للتو # 2718 ، والذي يعيد صياغة كود التقليم ، وأعتقد أنه يحل هذه المشكلة بالإضافة إلى # 2340.

أنا آسف جدًا للطريقة التي تعاملنا بها مع مساهمتك ، وآمل أن تقبل اعتذاري. :خائب الامل:

لقد تحدثت مع MichaelEischer ، فقد ذكر أن PR # 2340 يتضمن المزيد من الأفكار التي لم يتم تنفيذها بعد ، لذلك سأعيد فتح هذه المشكلة.

cbane ، هل أنت مهتم بالعمل معنا لدمج هذه الأفكار في الكود الحالي؟ يمكنني أن أفهم تمامًا إذا لم يكن الأمر كذلك ، فسنراجع العلاقات العامة الخاصة بك ونستخرجها بأنفسنا :)

لقد أجرينا أيضًا مناقشة قصيرة أمس وحاولنا تحديد الخطأ الذي ربما حدث ، حتى نتمكن من القيام بعمل أفضل في المرة القادمة. بعض النقاط التي حددناها كانت:

• غيرت العلاقات العامة منطقة حساسة للغاية في الكود (تقليم ، والذي يزيل البيانات في النهاية) ، لذلك يحتاج إلى مزيد من التدقيق
• MichaelEischer وكذلكaawsome حاولوا مراجعة العلاقات العامة وقالوا إنها كانت كبيرة جدًا
• كان PR عبارة عن التزامين فقط ، أحدهما استبدل كل الكود برمز آخر مختلف تمامًا ، ومن الصعب جدًا مراجعة هذا الأمر
• تضمنت العلاقات العامة ما لا يقل عن 4-5 أفكار وتحسينات مختلفة ، مما يجعل المراجعة أكثر صعوبة

هل فاتني أشياء أخرى؟

التغييرات التي تم إجراؤها على cmd_prune.go من # 2340 بعيدة بقدر ما يمكنني رؤيتها تم استبدالها تمامًا بـ # 2718 و # 2842 بواسطة aawsome . يستبدل الرقم 3006 أيضًا تغييرات index / index.go.

لقد قمت باستخراج تطبيق المشي الشجري المتوازي للغاية من checker.go (انظر https://github.com/MichaelEischer/restic/tree/streamtrees) ، والذي يسمح بتنفيذ FindUsedBlobs مع القليل سطور إضافية من التعليمات البرمجية. كما يمكن إعادة استخدامه لأمر copy. يوحّد الفرع المذكور أيضًا الكود المستخدم لموازنة الفهرس وتحميل اللقطة. سوف أقسم الفرع إلى علاقات عامة أصغر.

يبدو أن هذا يترك استخدام عدد اتصال الواجهة الخلفية و GOMAXPROCS للتكيف تلقائيًا مع IO / CPU التوازي كجزء متبقي من # 2340.

لقد لاحظت أنه لا # 2340 ولا PRUNE PR الآخر يوازي حاليًا تحميل الفهرس المعاد كتابته.