ووفقا ل هذا ، يمكنك استخدام RESTIC_PASSWORD متغير البيئة لتحديد كلمة السر.

كما قال pvgoran بالفعل ، يمكنك استخدام متغير البيئة RESTIC_PASSWORD . تم توثيق هذا في الدليل هنا http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository. إذا كانت لديك فكرة عن كيفية توثيق ذلك بشكل أفضل ، يرجى إنشاء طلب سحب.

هناك أيضًا المشكلة رقم 278 ، وهي تتعلق بقراءة كلمة المرور من ملف.

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

أوتش ، وأعتقد أنني قد قرأت هذا القسم من خلال ....

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

شكرا pvgoran للإجابة السريعة ، راجع للشغل. :ابتسامة:

مجرد سؤال متابعة سريع في هذا الشأن. إذا لم تنته النسخة الاحتياطية بحلول الوقت الذي يُنفذ فيه cron restic مرة أخرى ، فماذا سيحدث؟

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

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

@ fd0 ربما نعم. لنفس النسخ الاحتياطي فقط. أو ، طريقة نظيفة لنسخ النسخ الاحتياطية الآلية: ستعمل بعض التعليمات ، ربما "النسخ الاحتياطي الثابت" ثم "الفتح الثابت" ثم "التقليم الثابت" على سبيل المثال. لكن عدم القلق بشأن تلك الأوامر الإضافية سيكون أمرًا رائعًا.

restic backup متبوعًا بـ restic forget و restic prune هو سير العمل المعتاد ، وهذا ينظفه. سأضيف مشكلة أخرى على أي حال ، حتى نتمكن من تتبع هذه الفكرة.

رائع شكرا لك! الآن سأستخدم هذا التدفق.

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

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

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

لسوء الحظ ، ستفشل أي وسيلة للكشف عن مثيل restic قيد التشغيل في جميع الخلفيات (SFTP ، REST ، S3 ...) باستثناء النسخة المحلية.

zcalusic يمكننا استخدام المعلومات المخزنة في ملفات القفل للقيام بذلك: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33 ، ربما إضافة قائمة الملفات للنسخ الاحتياطي أو وسائط سطر الأوامر الدقيقة أو شيء مشابه.

ما زلت لا أرى كيف يمكن للراحة على الجهاز A ، والعثور على قفل على جهاز الخادم الاحتياطي B ، والتمييز بين أ) تشغيل جلسة restic حاليًا على الجهاز C و b) قفل قديم متبقٍ بعد تعطل restic على الجهاز C؟

أم أننا بدأنا الحديث عن آليات RPC هنا؟ أو حتى أفضل ، مديري القفل الموزعة؟ 😄

zcalusic أتحدث عن # 711: الكشف عن بدء تشغيل نسخة احتياطية ثانية بنفس الدلائل على نفس الجهاز. يجب أن يكون ذلك ممكنا.

bwmarrin لا أفهم ما

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

يتم تشغيل نسخة احتياطية حتى النهاية ، أو يتم إلغاؤها / إنهاؤها. لا أعتقد أنه من الممكن بطريقة أو بأخرى تخصيص وقت لنسخة احتياطية تستغرق على الأكثر أي مدة يتم تقديمها في معلمة افتراضية --timeout . كيف يمكن ان يعمل؟

هل يمكنك وصف دلالات مثل هذه المعلمة من فضلك؟ شكر!

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

هذا يعني أنه إذا كان لديك وظيفة cron مجدولة للعمل كل ساعة ، وتمرير معلمة - timeout 50m إلى restic. سيتم إجهاض / إنهاء النسخ الاحتياطي إذا استغرق أكثر من 50 دقيقة. في هذه الحالة ، بعد 10 دقائق ، ستبدأ وظيفة cron مرة أخرى وستستأنف من حيث توقفت. سيؤدي هذا إلى منع مثيلات متعددة لنفس النسخة الاحتياطية من التشغيل بشكل متزامن.

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

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

بالإضافة إلى ذلك ، يمكنك بسهولة تنفيذ هذا السلوك باستخدام الأداة القياسية timeout (من coreutils) ، عن طريق تشغيل timeout 40m restic backup [...] . لذلك لا أعتقد أن إضافة هذا الخيار إلى restic فكرة جيدة.

أدرك أنني تأخرت عن الحفلة ولكن لا يمكن أن يكون هناك ملف قفل يجعل المثيل الثاني ينتظر حتى ينتهي الأول قبل أن يبدأ؟

@ Karl-Gustav ، يمكنك تحقيق ذلك بقليل من البرمجة النصية. https://stackoverflow.com/a/1985512/244009

كان ذلك أكثر تقدمًا من أقفالي :-) أنا فقط استخدم if file {wait 5sec and check again}

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

مرحبًا ، أنا أقرأ عن كيفية استخدام restic لجدولة النسخ الاحتياطية. في الوقت الحالي ، فكرتي هي استخدام anacron لجدولة على سبيل المثال نسخ احتياطي ليومين في الأسبوع إلى Backblaze. النقطة المهمة هي ، إذا تمت جدولة النسخة الاحتياطية الخاصة بي باستخدام anacron ، على سبيل المثال الثلاثاء والجمعة في الساعة 12 مساءً وتم إيقاف تشغيل الكمبيوتر المحمول الخاص بي يوم الثلاثاء ولا تبدأ تشغيله مرة أخرى حتى يوم الجمعة في الساعة 11:59 صباحًا ، فماذا سيحدث؟ AFAIK (وإذا لم أكن مخطئًا) يجب أن تبدأ Anacron الوظيفة المفقودة يوم الثلاثاء ؛ وبعد دقيقة (أثناء تشغيل المثيل الثابت الأول) ، هل سيتم تشغيل النسخة الاحتياطية الثانية ، مما ينتج عنه نسختان احتياطيتان متزامنتان لنفس الدليل؟

أم أنه أي نوع من ملفات القفل / tmp لمنع تشغيل المثيل الثاني؟
كيف يمكنني إدارته لجدولة النسخ الاحتياطي بشكل صحيح؟ شكرا :)

gerardbosch مرحبا! هذا السؤال مناسب بشكل أفضل للمنتدى ، يرجى مراعاة ذلك في المرة القادمة :)

تتمثل إحدى طرق التعامل معها في كتابة برنامج نصي يقوم بتشغيل restic نيابةً عنك ، وكجزء من القيام بذلك ، يتم إنشاء ملف runfile (على سبيل المثال /var/run/restic.pid يحتوي على PID الخاص بالعملية restic`) ، والذي يمكنه بعد ذلك تحقق لتحديد ما إذا كان restic يعمل بالفعل أم لا.

لن يكون الأمر harm بأي شكل من الأشكال إذا كنت ستشغل نسختين احتياطيتين متزامنتين ، لكنه بالطبع لا طائل منه إذا كانا يغطيان أكثر أو أقل من نفس الملفات ونقطة زمنية.

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

لمعلوماتك لمزيد من الأشخاص الذين وصلوا إلى هنا من عمليات بحث Google:

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

https://github.com/erikw/restic-systemd-automatic-backup

erikw برنامج جدولة رائع ،
بعض الأسئلة:

• ما هي الميزة الرئيسية لاستخدام مؤقتات systemd على cron أو anacron؟
• هل يمكن تثبيت سكربتات / إعداد systemd في homedir بدلاً من / etc؟
• هل يمكن أن تتواجد علامة التبويب anacron في مكان ما في $ HOME؟

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

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

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

• نعم ، أقوم بتشغيل عدة مؤقتات systemd للمستخدم المحلي. تحقق من ملفات dotfiles الخاصة بي بحثًا عن أجهزة ضبط الوقت والخدمات المقابلة التي --user للتحكم في عدادات المستخدم بدلاً من مؤقتات النظام:

$ systemctl --user list-timers

• يبدو أنهم في /var/spool عادة. إذا كان يمكن نقله إلى ~/ لا أعرف. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

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

colans Backupninja رائع ، لا يمكنني الانتظار حتى تتمكن من استخدامه مع restic! شكرا لك على هذا العمل.

restic backup متبوعًا بـ restic forget و restic prune هو سير العمل المعتاد ، وهذا ينظفه. سأضيف مشكلة أخرى على أي حال ، حتى نتمكن من تتبع هذه الفكرة.

إذا كنت أقوم بإعداد مهمة / وظيفة cron اليومية المجدولة دون توقع وظائف متوازية محتملة ، فهل يجب أن يستمر البرنامج النصي في تنفيذ restic backup -> restic forget -> restic prune ؟ يبدو أنه يضيف المزيد من النفقات العامة إذا قمنا بتنفيذ مثيل واحد فقط في كل مرة

هل يمكننا إعادة فتح هذا كمهمة توثيق؟ أعتقد أنه يجب علينا إضافة قسم "الجدولة" إلى الدليل لزيادة الوضوح حول هذا الموضوع. يمكننا أن نقول شيئًا مثل:

الجدولة خارج نطاق Restic. ومع ذلك ، هناك أدوات خارجية يمكن استخدامها لهذا الغرض.

• Backupninja جنبًا إلى جنب مع فرع دعم Restic
• النسخ الاحتياطي التلقائي restic باستخدام خدمات systemd وأجهزة ضبط الوقت
• تكوينات النسخ الاحتياطي Restic

أفكار؟

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

تعتمد طريقة جدولة المتوفرة لديك. أعتقد أن مثل هذه الاقتراحات خارج التوثيق للقلق العادي ، ولكنها قد تكون بالفعل مقالة مفيدة في مدونة شخص ما أو حتى في قسم الوصفات بالمنتدى. يمكن أن يكون أيضًا مرشحًا لقسم الأمثلة في موقع الويب الخاص بـ restic doc على https://restic.readthedocs.io/en/latest/080_examples.html ، ولكن يجب كتابته بطريقة تتطلب حدًا أدنى الصيانة ، نظرًا لأننا لا نريد الاحتفاظ بمجموعة من الإرشادات التفصيلية حول كيفية جدولة ذلك على عدة منصات مختلفة (لأنه موضوع معقد جدًا) بعد كل ما قيل ، هناك بالفعل العديد من المقالات والأمثلة حول هذا (على سبيل المثال مع cron و systemd) على الشبكة ، إذا بحث المرء عنها. لست متأكدًا تمامًا من وجود حاجة إلى ذلك في موقع المستندات.

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

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

على الأقل ، يمكن أن يوفر قسم المستندات وقت المستخدمين: من خلال الإشارة إلى أنهم بحاجة إلى البحث في مكان آخر / العثور على أداة مختلفة لإعداد نسخ احتياطية روتينية باستخدام restic.

يبدو لي أن امتلاك أداة نسخ احتياطي بدون مستندات بارزة حول كيفية جدولة الأمر يشبه بيع سيارة بدون عجلات

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

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

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

ومن الشرعي تمامًا أن نقول "هذه مجموعة DIY --- اذهب وابحث عن العجلات الخاصة بك!"

أتوقع أن معظم المستخدمين إذا لم يعثروا على موضوع معين في المستندات ، يقومون ببساطة باستخدام DDG / Google من أجله ، ثم يجدون الإجابات في غضون دقيقة أو دقيقتين.

في الواقع ، أتى البحث في Google عن "جدول النسخ الاحتياطي الثابت" إلى هنا المباراة الأولى: ابتسم:

2122 مرتبط لأنه يوفر بعض أجهزة ضبط وقت systemd عينة ومناقشات أخرى بخصوص الجدولة.

أعتقد أن أسلوب "أقل صيانة" هنا يبدو منطقيًا ... ربما يتضمن تلميحات حول تسجيل الإخراج ومنع عمليات التشغيل المتعددة في نفس الوقت؟

ربما تتضمن تلميحات حول تسجيل الإخراج ومنع عمليات تشغيل متعددة في نفس الوقت؟

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