سيكون ذلك رائعًا حقًا.

سيسمح أيضًا بإزالة البيانات الحساسة التي تم تضمينها عن غير قصد.

ستكون هذه ميزة رائعة!

أي ردود فعل من المطورين على هذه الفكرة؟ سيكون جميل جدا. على سبيل المثال ، اكتشفت للتو أن برنامجًا أقوم بإنشائه من عمليات التحقق من git كان ينشئ ثنائيات هائلة (حوالي 100 ميجابايت) ، وقد تم نسخها احتياطيًا في نسخ Restic الاحتياطية دون داعٍ. لم أستخدم Restic لفترة طويلة ، لأنني ما زلت في مرحلة الاختبار ، لذلك لا توجد مشكلة في حذف اللقطات القديمة المعنية. ولكن يمكن أن تحدث هذه المشكلة بسهولة تامة ، وسيكون من الجيد أن يكون لديك حلول طويلة الأجل لها ، بخلاف نسيان كل لقطة.

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

شكرا.

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

ربما لا يغير هذا فعليًا جهود التنفيذ ، ولكن من وجهة نظر UX ، قد يتم ذلك باستخدام ملف تعريف منخفض نوعًا ما عن طريق توسيع الأمر backup بدلاً من إضافة أمر جديد تمامًا:

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

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

dnnr انظر https://github.com/restic/restic/issues/1550#issuecomment -358536554

ومع ذلك ، أنا لا أتابعك هنا. تعتبر إزالة البيانات من اللقطات القديمة بالتأكيد عملية مميزة ويجب أن يكون لها أمر خاص بها. شيء مثل:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

و --snapshots ربما ينبغي قبول all الكلمة لتعمل على جميع لقطات (أو كل لقطات مع المحدد --tag ). وربما يتطلب الأمر تأكيدًا بكتابة yes .

سيكون من الجيد أيضًا أن يكون لديك خيار --patterns ، والذي من شأنه حذف المسارات المطابقة للأنماط المحددة.

purge هو أحد الاحتمالات لاسم الأمر. erase أيضًا اختيارًا جيدًا ، بالإضافة إلى delete . أيا كان الاختيار ، يجب أن يوضح أن العملية تحذف البيانات بشكل دائم . نتحدث عن هذا برنامج نسخ احتياطي ، وأي عمليات خطيرة يجب أن تكون مميزة وصريحة وتتطلب تأكيدًا.

حسنًا ، لقد تركت الخطوة التي قمت فيها بحذف لقطة المصدر بعد ذلك (باستخدام forget ، ثم ربما prune ) ، لأنني اعتقدت أن ذلك كان واضحًا.

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

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

أتفق مع alphapapa على أنه يجب أن يكون هناك أمر مميز لهذا النوع من العمليات. قد يكون purge ، هذا ليس اسمًا سيئًا ، ثم مرة أخرى قد تكون هناك عمليات أخرى مماثلة في المستقبل ، على سبيل المثال ، اقترح alvarolm بالفعل القدرة على إعادة تسمية الملفات.

لهذا السبب أعتقد أن إضافة أمر rewrite هو أفضل بديل في هذه الحالة ، وجعل هذا الأمر يحتوي على سبيل المثال --purge و --rename ، بافتراض أن الأخير مناسب لـ ينفذ. لذا فإن الأوامر النهائية ستكون على سبيل المثال restic -r foo rewrite --purge snap1,snap2 path1 path2 ... و restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

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

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

تضمين التغريدة

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

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

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

أنا لا أفهم ما تقصد. والعكس هو الصحيح. لا يتداخل أمر المسح / الحذف / إعادة الكتابة المقترح مع backup على الإطلاق - فهو يحذف البيانات من اللقطات الموجودة . ومن متعامد لأوامر القائمة.

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

مرة أخرى ، لا فكرة عما تفكر فيه هنا. purge منفصل تمامًا عن النسخ الاحتياطي والنسيان والتقليم:

• backup : إنشاء لقطة جديدة لمسارات معينة.
• forget : إزالة اللقطات الموجودة.
• prune : تجمع القمامة النقط غير المستخدمة من اللقطات المنسية.
• purge / rewrite / أيا كان: حذف الملفات من اللقطات الموجودة.

أنت تقترح جعل الأمر backup يعمل في وضعين ، أحدهما يقوم بنسخ البيانات احتياطيًا ، والآخر يحذف البيانات.

rawtaz نعم ، يُعد rewrite اقتراحًا جيدًا ، لأنه يعيد كتابة اللقطات الحالية حرفيًا. أقترح واجهة مستخدم مثل:

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

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

النسخ الاحتياطي: ينشئ لقطة جديدة لمسارات معينة.

حسنا، بمعنى من المعاني، وتعديل محتويات لقطة يخلق لقطة جديدة (لأنها ليست نفس لقطة كما في السابق). فكر في git commit --amend ، والذي ينشئ التزامًا جديدًا استنادًا إلى التزام موجود. هذا التشبيه مناسب جدًا في الواقع ، حيث يبدو أن هذه البطاقة تتحرك بسرعة نحو إعادة اختراع Git.

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

لم أقل ذلك. لماذا؟ يوجد forget و prune ، وهو أمر جيد تمامًا لإزالة الأشياء.

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

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

لم أقل ذلك. لماذا؟

حسنًا ، قلت:

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

ربما يجب أن تشرح بمزيد من التفصيل.

هناك نسيان وتقليم ، وهو أمر جيد تمامًا لإزالة الأشياء.

لنكن دقيقين. يزيل forget اللقطات ، و prune يزيل النقط . نقترح أمرًا لإزالة الملفات الموجودة في اللقطات . يجب أن يكون أمرًا مميزًا.

أود أن أضيف رأيي:

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

يجب أن يكون الأمر مستقلاً عن الأمر backup ، ليس فقط لأسباب تتعلق بالتعامد (وهو ما يشبه Go) ، ولكن أيضًا خارج الاعتبارات العملية: الأمر backup معقد بالفعل بما يكفي لذلك أنا نرغب في فصل الأمر الآخر عنه.

لا أحب الاسم purge ، بسبب تشابهه مع prune . ماذا عن change ؟ ثم لدينا restic backup و restic restore و restic change .

بالنسبة للعمليات المدعومة للأمر ، رأيت طلبات لـ:

• احذف الملفات ، مثل --delete
• إعادة تسمية الملفات ، على سبيل المثال --rename

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

أعتقد أن change يبدو أشبه بإخراج شيء ما ووضعه فيه ، بدلاً من تعديل محتويات شيء ما.

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

ربما يعرف بعض الأمريكيين / الإنجليز أيهما أكثر ملاءمة :) يتلخص ذلك في علم اللغة على ما أعتقد.

حسنًا ، modify إذن؟

modify بالتأكيد أفضل من change . لذلك إما rewrite أو modify من بين ما تم اقتراحه حتى الآن. من الغريب ما يعتقده الآخرون :)

إذا كان الأمر يتعلق فقط بحذف الملفات ، فهل من المنطقي تحسين الأمر forget للعمل مع اللقطات والملفات؟ أم أن هذا سيكون معقدًا جدًا؟

إذا كانت هذه الميزة الجديدة تتعلق بالحذف وإعادة التسمية (أو أي شيء آخر) ، فسأصوت لـ modify .

شكرا لمساهمتك dimejo 👍

أعتقد أنه عند إعادة التسمية و / أو الحذف ، فأنت لست forget ting (على الأقل ليس في الحالة السابقة).

IMHO "إعادة الكتابة" تنقل المعنى الأفضل.

الأمر forget معقد جدًا أيضًا ، فلن نضيف أي شيء إلى ذلك إذا استطعنا مساعدته ؛)

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

بالمناسبة ، أشعر أن restic ستستفيد من فئات الأوامر ، على غرار ما لدى Git بأوامر السباكة. في الوقت الحالي ، يسرد restic -h جميع الأوامر بترتيب معجمي ، مع مزج أوامر المستوى المنخفض (على سبيل المثال ، cat ، list ، والتي لن يحتاجها المستخدمون "العاديون" أبدًا) مع الأوامر الأساسية عالية المستوى.

قد تفكر أيضًا في update .

+1 مقابل rewrite ، يحتوي على خاتم Orwellian لطيف. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ؟ 😄

أود اقتراح أمر جديد edit . بناءً على جميع التعليقات المتعلقة بهذه المشكلة ، يبدو لي أننا قد ننتهي بإجراءات متعددة إلى edit واحد أو لقطات متعددة.

في الوقت الحالي يمكن أن يكون مجرد شيء مثل:

$ restic edit 40dc1520 remove dir/file

في المستقبل يمكننا تنفيذ حذف ملف واحد من لقطات متعددة (قائمة الإدخال لمعرف اللقطة أو النطاق الزمني).

قد تكون الأوامر الأخرى ضمن سياق التحرير

• rename لإعادة تسمية الملفات والمجلدات
• move لتصحيح هياكل الملف / dir التي ربما تكون قد تغيرت

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

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

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

rawtaz
أفكاري (تقريبا) بالضبط.

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

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

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

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

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

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

لا أعتقد أننا بحاجة إلى مزيد من المناقشة هنا ، شكرًا على المشاركة!

اقتراح اسم الأمر: restic purge .

أنا أتطلع إلى هذه الميزة. شكرا

@ fd0
أي تحديث على هذه الميزة؟ أحب استخدامه :)
نحن نستخدم restic في بيئة حكومية ويلزم حذف ملف واحد من نسخة احتياطية لهم. يمكننا تمويل بعض الأعمال إذا لزم الأمر!

أنا أتطلع إلى هذا أيضًا! أقترح استخدام شيء مثل البنية الأساسية لـ restic find .

restic purge [flags] PATTERN

حيث يمكنك تحديد purge إلى host (-H) snapshots (-s) or paths (--path)

ثم ربما يقوم restic prune بعد ذلك بالحذف الفعلي

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

شكرا !

لا تحديث ، آسف. سيتم إعلامك بالاشتراك في هذه المشكلة عند حدوث شيء ما.

يبدو أن معظم الأشخاص يريدون أن يكونوا قادرين على الحصول على البيانات الوصفية للنسخة الاحتياطية clone ، لكن يستبعدون الملفات المسيئة - دون الحاجة إلى استعادتها جميعًا في موقع الصفر. فكرة استنساخ نسخة احتياطية من شأنها نسخ البيانات الوصفية مع القدرة على إزالة بعض المؤشرات.

هل هذه هي حالة الاستخدام؟

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite و modify وحدات ماكرو للعملية المذكورة أعلاه.

بالنسبة لي ، سيكون هذا كافياً بالفعل nullcake

ليس سيئا جدا ،nullcake.

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

بالطبع ، حتى إذا تم تنفيذ أي نوع من التنظيف استنادًا إلى نسخة احتياطية واحدة ، كما تقترح ، فستظل خطوة رائعة إلى الأمام. نحن ، بالطبع ، نعرف كيف نكتب. ؛)

لذا ، ممتاز. :)

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

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

ستكون هذه ميزة رائعة. هل تم اضافته؟

لا.

@ fd0 هل حدث أي تقدم في هذا الشأن؟ لقد اكتشفت للتو أنني لم أستبعد ذاكرات التخزين المؤقت كما اعتقدت وأرغب في إزالتها.

اقتراح آخر لاسم الأمر: scrub (على الرغم من أنني بخير مع purge أيضًا ، فإن علامة --rename تبدو غريبة بالنسبة لي). افكاري:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

حيث --replace=clean يزيل أي لقطة تعديل، prune ينظف ويعمل prune بعد ذلك. يظهر --diff فرقًا لأي لقطات معدلة. يتجنب --dry-run أي تغييرات على الريبو.

صالحة أيضًا هي جميع أعلام --exclude من restic backup . أعتقد أن --host و --time منطقيان أيضًا (كل منهما يحل محل قيم اللقطة الموجودة مسبقًا) ؛ تحرير --tag تمت معالجته بالفعل بواسطة restic tag .

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

بما أن هذه مشكلة قديمة جدًا .. فهل هناك فرصة للحصول على هذه الميزة؟

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

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

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

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

MorgothSauron عادةً ما أزلت فقط اللقطات التي احتوتها أيضًا ، وهو الحل الوحيد الذي يبدو عليه في restic ، ولكن مرة أخرى ، يمكن لـ Duplicati القيام بذلك عبر أمر واحد لفترة من الوقت الآن ، لذلك لقد تغيرت منذ ذلك الحين ولم يكن لدي أي مشاكل.

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

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

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

يجب أن تكون هذه العلاقات العامة أساسية وتكون بمثابة نقطة انطلاق يمكن البناء عليها إذا لزم الأمر. مثال على ما أعنيه بذلك هو أنه يجب أن يكون للمبتدئين:

• فقط كن أمرًا واحدًا جديدًا (على سبيل المثال ، rewrite لأن هذا هو الأكثر تصويتًا في هذه المشكلة).
• خذ قائمة باللقطات كوسيطة (وسائط) أساسية (بما في ذلك دعم all ) ، على سبيل المثال all أو 098db9d5 أو 098db9d5 af92db33 .
• خذ قائمة واحدة أو أكثر من --exclude <pattern> لسرد المسارات التي يجب استبعادها / إزالتها من اللقطة (بمعنى آخر ، هذا هو --exclude الذي كان مفقودًا عند النسخ الاحتياطي) ، على سبيل المثال --exclude="*.o" ، --exclude=*.unwanted ، --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

الأساس المنطقي هنا هو الحصول على الحد الأدنى من البداية كدليل على المفهوم والحد الأدنى من المنتج القابل للتطبيق. بمجرد إجراء الاختبار ، يمكننا تعديله حسب الحاجة ، على سبيل المثال عن طريق إضافة الوسائط الأخرى --exclude-* من الأمر backup . إذا قمنا بعمل أمر rewrite مثل هذا ، فسيكون له نفس الواجهة إلى حد كبير مثل الأمر backup الذي من المفترض أن "يصحح":

~restic -r / some / repo أعد كتابة الكل --exclude = " .o" --exclude = .unwanted --exclude = .DS_Storerestic -r / some / repo أعد كتابة 098db9d5 af92db33 --exclude = " .o" --exclude = .unwanted --exclude = .DS_Store~

في ملاحظة ذات صلة ، ربما يمكن استخدام العمل الذي أنجزه middelink في https://github.com/restic/restic/issues/323 كمصدر إلهام أو أساس للتنفيذ ، كما يفعل بعض معالجة اللقطات الحالية. سأرى ما إذا كان بإمكاننا التحرك مع هذا في وقت قريب جدًا.

rawtaz

شكرا لردود الفعل المدروسة!

أهلا.

لقد أضفت تنفيذ مشروع rewrite بالقرب من تعليق rawtaz

إنه يعمل هنا مع اختبار الريبو ، ويمرر restic check --read-data بدون أخطاء ، لكن لم يختبره كثيرًا. لذلك أقترح بشدة عدم استخدامه مع البيانات المهمة.

لقد حاولت الحصول على بناء الجملة قريبًا جدًا من الأمر backup . لذلك يتم دعم --exclude و --iexclude و --exclude-file (لكن لم يتم اختبارها). من الناحية المثالية ، أرغب أيضًا في رؤية خيار --exclude-if-present (سير العمل المثالي بالنسبة لي هو شيء مثل "عفوًا ، ليس ضروريًا للنسخ الاحتياطي ، أضف CACHEDIR.TAG و restic rewrite '). لكنه معقد جدًا لأنه في مثل هذه الحالة سنحتاج إلى rewrite على نفس المضيف حيث تم إجراء النسخ الاحتياطي والوصول إلى نظام الملفات لجمع هذه الملفات (بالإضافة إلى الكثير من السحر مع المسارات النسبية). إذن ليس الآن ...

كما أنني لا أحب فكرة استبدال اللقطات بشكل افتراضي ، لذا فإن السلوك الافتراضي حاليًا هو إنشاء لقطة جديدة بعلامة rewrite . ولكن من الممكن أيضًا الاستبدال بـ --inplace arg.

سيكون أي ردود فعل موضع تقدير كبير.

مرحبًا دميتري ،

شكرا لهذا التنفيذ ، عمل رائع!

حتى الآن ، يعمل بشكل مثالي على نظام Linux من خلال إعادة اختبار صغيرة من 600 ملف + عدة لقطات اختبار. استعادة الأعمال ويظهر فرق المجلدات المستبعدة بشكل صحيح. سأقوم بمزيد من الاختبارات المكثفة على ريبو حقيقي "استنساخ" مع العديد من غيغابايت من البيانات مع أكثر من 100 لقطات. سأحاول أيضًا المستودعات من Windows.

اقتراح واحد: لديك خيار تحديد علامة للقطات التي تحتوي على الاستثناءات في إعادة الكتابة. (الاحتفاظ بالعلامة " rewrite " في اللقطات المنشأة حديثًا.)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

سيساعد هذا في تحديد تلك اللقطات التي لا تزال تحتوي على "_thisfileshouldberemoved.txt_". من ناحية أخرى ، يعمل --inplace الأكثر مباشرة كما هو متوقع.

مرة أخرى عمل جيد جدا.

NovacomExperts نعم ، كان دافعي الأولي هو الحفاظ على "تحرير السجل بأمان قدر الإمكان. من السهل جدًا استبعاد شيء مهم باستخدام --exclude * ولا توجد طريقة تقريبًا للتعافي من ذلك (مع النسخ الاحتياطي ، الأمر يتعلق فقط ببدء نسخ احتياطي جديد مرة أخرى). شيء من هذا القبيل --dry-run ولكن مع القدرة على الحصول على لقطة فعلية وحذف لقطة المصدر بشكل صريح بعد التحقق من أنها على ما يرام.

أوافق تمامًا على أن هذا لم يتحقق بالكامل في الوقت الحالي. من السهل "مراقبة" اللقطات الجديدة ، ولكن من الصعب جدًا حذف اللقطات القديمة. بالإضافة إلى أنني لا أحب ترميز اسم لقطة rewrite . ربما من الأفضل أن يكون لديك --inplace افتراضيًا و ---keep-source-tagged before-rewrite --tag-destination after-rewrite أو شيء من هذا القبيل. ( --add-tag غير واضح بعض الشيء ، سواء كانت لقطة قديمة أو جديدة).

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

ملاحظة. الريبو الأساسي الخاص بي هو حوالي 2 تيرابايت الآن. سنحاول ذلك لاحقًا بعد عمل لقطة LVM.

dionorgua دافعك الأولي صحيح تمامًا. سأدلي بصوتي لإبقائه على هذا النحو ، مع وجود الخيار "الخطير" --inplace بعيدًا قدر الإمكان عن المستخدم (بالتأكيد ليس افتراضيًا). أفضل خطأ وسيطة مفقود على --keep-source-tagged / --tag-destination --inplace افتراضيًا.

لكنني أوافق ، دعنا ننتظر ردود الفعل على هذا.

بالأمس ، نسيت اختبار الريبو المستنسخ (65 جيجا بايت) داخل مجلد تم نسخه احتياطيًا بواسطة restic بين عشية وضحاها. كان بإمكاني الحصول على لقطة الأمس forget لكنني دخلت "كل شيء" وحاولت التنفيذ. بعد forget + prune ، نجحت في إزالة 65 غيغابايت من الريبو سعة 400 غيغابايت. كل شيء جيد ، لم يتم العثور على خطأ.

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

هتافات

لقد استبدلت طلب السحب # 2720 الخاطئ بطلب جديد لأنه تم إنشاء الطلب القديم من الفرع الرئيسي. أضفت للتو فحص خطأ واحد مفقود. آسف للضوضاء الإضافية

حسنًا ، modify إذن؟

متأخر جدًا عن ذلك ، ولكن _rectify_ هو اقتراحي لأمر حذف ملف محدد من النسخ الاحتياطي.

2731 مثير ، شكرا حفنة!

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

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