شكرًا للإبلاغ عن هذه المشكلة ، أعتقد أن هذا خطأ.

من المحتمل أن يحدث ذلك عندما تحمل أدلة المستوى الأعلى نفس الاسم. لأنه لا يتم استعادة المسار الكامل ، فقط دليل المستوى الأعلى.

الحل هو إعادة بناء المسار الكامل عند الاستعادة ، واستعادة كل شجرة في المسار الكامل. لذا فإن المسار الناتج سيكون مثل /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . أعتقد أنه مقبول.

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

أنا أيضا أظن أن هذا هو الحال. في الوقت الحالي ، يعمل restic مثل هذا:

عندما يطلق عليه restic backup A/foo B/foo فإنه ينشئ هيكل شجرة في المستودع يشبه هذا:

├── foo
└── foo

لذلك يتم أخذ آخر مكون مسار فقط من الوسيطات إلى الأمر backup ، وهذا يؤدي إلى مشكلة عند استعادة هذه اللقطة.

لتصحيح هذا ، أقترح تنفيذ نفس السلوك مثل tar ، والذي سيؤدي في هذه الحالة إلى إنشاء الشجرة التالية:

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

سيتطلب هذا بعض العمل في جزء المحفوظات من restic. لا أعتقد أننا سنحتاج إلى لمس استعادة على الإطلاق.

588 أبلغت عن نفس الشيء. لكن هذا الشخص لديه حالة اختبار يمكنك استخدامها.

@ fd0 أقترح أيضًا تضمين خيار (--store-full-path) للنسخ الاحتياطي حيث يخزن بوضوح المسار "الحقيقي" الكامل لهدف النسخ الاحتياطي.

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

trbs أعتقد أن

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

+1 لـ --store-full-path

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

شكرًا @ fd0 على عملك على هذا ، أفهم أنه ليس من السهل الاسترخاء الآن.

-1 مقابل --store-full-path . أفضل كثيرًا أن أرى المسار الكامل يسير دائمًا في النسخة الاحتياطية ثم الحصول على --strip-components <N> لأخذ الأجزاء بعيدًا إذا لم تكن بحاجة إليها في وقت الاستعادة. هذا يعني أن البيانات الكاملة متاحة دائمًا في النسخة الاحتياطية ، وإذا قام المستخدم بإخراج عدد كبير جدًا من المكونات من المسار في وقت الاستعادة ، وبالتالي يجمع بين العروض الفرعية ، يصبح خطأ المستخدم قابلاً للاسترداد.

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

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

@ mholt أوافق ، أنا أعمل بالفعل على هذا. كما قلت ، هذا ناتج عن قرار تصميم سيئ في وقت مبكر ويحتاج إلى تصحيح.

يا @ fd0 - رأيت للتو أنه تم الإفراج عن 0.7. هل هذا (و # 910 و # 909) على الخريطة لـ 0.7.1؟

ربما ليس 0.7.1 ، ولكن 0.8.0 أو نحو ذلك. لقد بدأت بالفعل في العمل على الرغم من ذلك. ربما يكون هناك القليل من الخلفية: يحدث هذا بسبب كود الأرشيف ، وهو أقدم كود موجود في restic. لسوء الحظ (نظرًا لأنني بدأت للتو في تعلم Go back في 2013/2014) ، فإن كود الأرشفة معقد للغاية وقد ارتكبت الكثير من أخطاء المبتدئين (الكثير من التزامن ، العديد من القنوات) أنا قلق أيضًا بشأن الأشياء التي تبين أنها ليست مشكلة على الإطلاق ، وتجاهلت الأشياء التي أصبحت مشكلة (مثل معالجة الفهرس).

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

لحسن الحظ ، هذا هو مجرد أرشيفي يحتاج إلى لمسه ، وسيستمر باقي الكود (بفضل تصميم restic و repo) في العمل بشكل جيد.

هل سيؤثر هذا التغيير على المستودعات الحالية وإذا كان الأمر كذلك ، فكيف؟

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

لذلك ، تم دمج # 1209 وهو يعمل على تحسين الموقف عن طريق الكشف عن تعارض الأسماء وحلها (عن طريق إعادة التسمية) ، لكن هذه المشكلة لم يتم حلها بالكامل بعد. أنا أعمل على ذلك :)

@ fd0 هل من فكرة متى نتوقع لقطات تحتوي على المسار الأصلي الكامل؟ نحن نعمل حاليًا على أتمتة عمليات النسخ الاحتياطي والاستعادة باستخدام restic.

عند أتمتة الاستعادة ، من الضروري الحفاظ على مسار المصدر سليمًا.

إذا كان لدي خادم يحتوي على دليلين "بيانات" يتم نسخهما احتياطيًا (وهذا ليس نظريًا ، فلدينا عدد من الخوادم مع أدلة "بيانات" Confluence و JIRA التي تحتاج إلى نسخ احتياطي) - تحتاج عملية الاستعادة إلى معرفة أي منها دليل البيانات ينتمي إلى Confluence وأي دليل بيانات ينتمي إلى JIRA. من الواضح أن اسمًا مثل "data" و "data-1" لا يقطعها هنا.

أعتقد أن أفضل حل في الوقت الحالي هو إجراء نسخ احتياطي لأدلة البيانات في لقطات منفصلة ووضع علامات عليها بـ "JIRA" أو "Confluence"؟

لا يوجد جدول زمني ، آسف.

أعتقد أن أفضل حل في الوقت الحالي هو إجراء نسخ احتياطي لأدلة البيانات في لقطات منفصلة ووضع علامات عليها بـ "JIRA" أو "Confluence"؟

نعم ، ولكن في # 1225 لن تتمكن من دمجها بسهولة في ريبو واحد لاحقًا.

فيما يتعلق بالخيار --store-full-path : rsync له هذا الخيار: -R ، --relative .
ربما تستخدم نفس اسم الخيار ل restic؟

بالنسبة إلى النسخ الاحتياطية للنظام بالكامل ، قمت بوصف حل بديل هنا: 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

بالنسبة للطرفين الفرعيين ، يستخدم restic الاسم الأساسي للملف الفرعي باعتباره dir ذي المستوى الأعلى في الريبو ، لذلك بالنسبة إلى 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:

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

أريد فقط أن أقدم لك بعض الإحصائيات:

النسخ الاحتياطي الأول:

-------------------------------------------------------------
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) :-)