البحث في الموقع

تحذير: ستؤثر عملية التحديث والتّرقية على كلّ الملفّات والمجلّدات الموجودة في تثبيت ووردبريس الرئيسيّ، وهذا يشمل جميع الملفات الأساسيّة المستخدمة لتشغيل ووردبريس، وإجراء أيّ تعديلات على هذه الملفّات سيساهم في فقدان التغييرات. يتوجّب تحديث ووردبريس إلى أحدث إصدار. ستظهر رسالة تحديث في شاشات الإشراف عندما يتوفر إصدارٌ جديدٌ من ووردبريس. ننقر على الرّابط الموجود في هذه الرّسالة للتّحديث. هناك طريقتان للتّحديث هما: (التّحديث بضغطة زرٍّ واحدةٍ One-click Update) وهي الأسهل وتعمل مع معظم المستخدمين، و(التّحديث اليدويّ Manual Update) والتي تستخدم عندما لا تعمل الطّريقة الأولى أو عندما يريد المستخدم أن يعمل بشكل مناب. يجب اتباع خطوات ترقية ووردبريس -تعليمات موسّعة عندما نريد التحديث عبر إصدارات متعددة. النسخ الاحتياطي لووردبريس Back up إن وضع نسخة احتياطيّة من الموقع على الويب فكرةٌ جيّدةٌ، إذ يمكن استعادة الموقع عند حدوث أيّ مشكلة. توجد التعليمات الكاملة للنّسخ الاحتياطيّ ضمن النسخ الاحتياطي لووردبريس. التحديثات التلقائية الخفية في نسخة ووردبريس 3.7، لم يكن هناك حاجة لبذل أيّ جهد لتطبيق التّحديثات الثانويّة والأمنيّة. معظم المواقع حاليًّا قادرةٌ على تطبيق هذه التحديثات بشكل تلقائيٍّ في الخلفيّة. إذا كان الموقع قادرًا على إجراء التحديث بنقرة واحدة -دون إدخال بيانات اعتماد بروتوكول نقل الملفات FTP- يجب أن يكون قادرًا على التحديث من 3.7 إلى 3.7.1 أو 3.7.2 وما بعدها. (لا زلنا بحاجة للنقر على تحديث الآن Update Now للحصول على الميّزات الأساسيّة للإصدارات). التحديث بنقرة واحدة One-click Update يتيح ووردبريس التحديث بنقرةٍ واحدةٍ والذي يمكن تشغيله بالنّقر على الرّابط الموجود في شعار الإصدار الجديد -إذا كان موجودًا- أو بالانتقال إلى (لوحة التّحكم Dashboard > شاشة التّحديثات Updates screen)، بمجرّد التواجد في صفحة "تحديث ووردبريس" (نقوم بالنّقر على " تحديث الآن Update Now" لبدء العملية، لا حاجة للقيام بأيّ شيء آخر وعند الانتهاء سنكون على اطّلاع دائم بالتّحديثات. يعمل هذا التحديث بنقرة على معظم المخدّمات، من الممكن أن تكون المشاكل التي تحدث متعلّقةً بالصّلاحيات المطبّقة على نظام الملفّات. ملكية الملف تحدَّد الطريقة المستخدمة للاتصال بنظام ملفّات المخدّم بالاعتماد على ملكيّة الملفّات (File Ownership) في ووردبريس. إذا كان مالك العمليّة الحاليّة (أي المستخدم الذي يعمل على مخدّم الويب) هو الذي يملك الملفّات، وكانت الملفّات الجديدة التي سيتمّ إنشاؤها بواسطة ووردبريس مملوكة من قبل المستخدم نفسه فسيقوم ووردبريس بتعديل الملفّات كلّها بنفسه مباشرةً دون أن يطلب تزويده ببيانات اعتماد الاتصال (credentials). لن يحاول ووردبريس إنشاء الملفّات الجديدة مباشرةً إذا لم يكن لها ملكيّة صحيحة، بدلًا من ذلك سيظهر صندوق حوار يطلب إدخال بيانات اعتماد الاتصال. من المعتاد أن تكون ملكيّة الملفّات لحساب نظام نقل الملفّات FTP الذي قام بتحميلها، لتطبيق التحديث علينا فقط تعبئة بيانات اعتماد اتّصال هذا الحساب). يعتمد كون الملفات مملوكة من قبل مستخدم مخدّم الويب (Web Server User) أو لا على طريقة تثبيت ووردبريس وكيفيّة إعداد المخدّم. يعدّ جعل الملفات مملوكة من قبل مستخدم خادم الويب وليس من قبل مستخدم FTP في بعض منصّات الاستضافة المشتركة تهديدًا أمنيًّا. يمكن مراجعة تغيير صلاحيات الملف لمزيد من المعلومات، بما في ذلك كيفيّة ضبط الصّلاحيّات للسّماح لعدّة مستخدمي FTP بتّعديل الملفّات. فشل التحديثات عند ظهور الرسالة المزعجة (فشل التحديث Failed Updates) يجب حذف ملف الصّيانة maintenance من مجلد ووردبريس باستخدام بروتوكول نقل الملفّات FTP مما سيؤدّي إلى اختفاء هذه الرسالة. إذا لم تعمل الترقية بنقرةٍ واحدةٍ فلا داعي للذعر! يجب تجربة التّحديث اليدويّ. التحديث اليدوي سنعرض هنا التّعليمات القصيرة، لمزيدٍ من المعلومات يمكن مراجعة التّرقية الموسّعة. في حال حدوث مشاكل في خطوات التّحديث الثّلاث اللّاحقة يمكن مراجعة تفاصيل أكثرعن تعليمات التّرقية . سنعرض تاليًا تعليمات التحديث اليدويّ بافتراض عنوان مسار المدوّنة هو http://example.com/wordpress الخطوة 1: استبدال ملفّات ووردبريس الحصول على أحدث نسخة ووردبريس مضغوطة أو ملف (tar.gz). فكّ ضغط الملفّ المُحمَّل. إلغاء تفعيل الإضافات. حذف المجلّدين wp-includes و wp-admin القديمين على مضيف الويب (من خلال بروتوكول نقل الملفّات FTP أو بروتوكول Shell) رفع المجلّدين wp-includes و wp-admin الجديدين -باستخدام بروتوكول FTP أو Shell- على مضيف الويب بدلًا من المحذوفة مسبقًا في الخطوة السّابقة. تحميل الملفّات الفرديّة من المجلّد الجديد wp-content إلى المجلّد الحالي wp-content، ليقوم بالكتابة فوق الملفات الموجودة. يجب عدم حذف مجلد wp-content الموجود لدينا وكذلك الملفّات أو المجلّدات الموجودة ضمنه (باستثناء الملفات التي تمّ استبدالها بملفّات جديدة). رفع جميع الملفات المفقودة من مجلّد الجذر (root directory) في النّسخة الجديدة إلى مجلّد الجذر الموجود حاليًا. ملاحظة: يجب استبدال جميع ملفات ووردبريس القديمة بالملفات الجديدة في المجلّدين wp-includes و wp-admin وكذلك المجلّدات الفرعيّة ومجلّد الجذر (مثل الملفّات index.php - wp-login.php …الخ)، لا داعي للقلق إذ سيكون الملف wp-config.ph في أمان. يجب الحذر عند نسخ المجلّد wp-content، والتأكّد من القيام بنسخ الملفات الموجودة فيه فقط، بدلاً من استبدال المجلّد بأكمله، لأنّه المكان الذي تخزّن فيه السّمات والإضافات الخاصّة بالموقع، لذا سنحتاج إلى الاحتفاظ بها. يجب تجنّب الكتابة فوق هذه الملفّات عند القيام بتخصيص السمّات الافتراضيّة أو التّقليديّة دون إعادة تسميتها، وإلا سنفقد هذه التّغييرات (مع أننا قد نرغب بمقارنتها مع ميّزات أو إصلاحات جديدة). وأخيرا يجب أن نلقي نظرة على الملف wp-config-sample.php لنتعرف على أي إعدادات جديدة يمكن أن نضيفها إلى ملف wp-config.php الخاصّ بنا. الخطوة 1.5: حذف ملف الصّيانة للقيام بالتّرقية يدويّاً بعد فشل الترقية التلقائيّة، يجب حذف ملف الصّيانة (maintenance file) من مجلّد ووردبريس باستخدام بروتوكول FTP، مما سيؤدي إلى إزالة الرسالة المزعجة (فشل التّحديث failed update). الخطوة 2: تحديث التثبيت وذلك بزيارة صفحة إدارة ووردبريس الرّئيسيّة على ‎/wp-admin -ربما يطلب تسجيل الدخول مرة أخرى- عند وجود حاجة لترقية قاعدة البيانات في هذه المرحلة سيكشف ووردبريس ذلك، وسيعطي رابطًا إلى عنوان المسار مثل http://example.com/wordpress/wp-admin/upgrade.php سيؤدّي اتّباع هذا الرابط وتنفيذ التعليمات إلى تحديث قاعدة البيانات لتكون متوافقة مع أحدث التعليمات البرمجية، يجب القيام بهذه الخطوة مباشرة بعد الخطوة الأولى. يجب ألا ننسى إعادة تنشيط الإضافات (plugins)! الخطوة 3: افعل شيئًا لطيفًا! إذا كان التّخزين المؤقّت (caching) مفعّلًا فيجب مسح ذاكرة التخزين المؤقت في هذه المرحلة لِتطبَّق التغييرات على الفور. وإلّا فإن زوّار الموقع (بما في ذلك أنت) سيستمرّون في رؤية الإصدار القديم (إلى أن يتمّ تحديث ذاكرة التّخزين المؤقّت). يتم تحديث تثبيت ووردبريس بنجاح، هذا بسيط إلى درجة أنّه يمكننا القيام به دون تحديث ووردبريس باستخدام النسخ الجزئية. فكر في مكافأة نفسك بنشر مدوّنة حول التحديث أو قراءة هذا المقال الذي طالما كنت تؤجّله أو بمجرد الاسترخاء لبضع لحظات وترك العالم يمر من حولك. الخطوات النهائية لقد اكتمل التّحديث، لذا يمكننا الدخول وتفعيل الإضافات الخاصّة مرة أخرى، في حال حدوث مشاكل في تسجيل الدخول يجب مسح ملفات تعريف الارتباط (cookies) في المتصفّح. استكشاف الأخطاء وإصلاحها أول ما يجب فعله -عند حدوث أيّ خطأ- القيام بالمرور على جميع الخطوات الموجودة في إرشادات الترقية الموسعة التي تحوي معلومات حول بعض المشاكل الأكثر شيوعًا. إذا واجهت طلبًا للحصول على بيانات اعتماد FTP مع محاولة تحديث ووردبريس على خادم معلومات إنترنت (تختصر إلى IIS) تلقائيًا فقد يكون الأمر متعلّقًا بالحقوق، عندها يجب الانتقال إلى وحدة إدارة IIS ومن ثمّ إلى تجمع التطبيقات الخاص بالمدونة، من إعداداته المتقدمة نقوم بتغيير المعرّف الخاص بنموذج الإجرائية إلى LocalSystem ثم على الموقع يتم اختيار المدوّنة بالنّقر بزر الماوس الأيمن واختيار تعديل الصلاحيات (Edit permissions) ثمّ على علامة التبويب أمان (security) ثمّ نقوم بإضافة المستخدمين الموثوقين، فهذا سيحلّ المشكلة. إذا واجهتنا أيّ مشاكل بعد التّرقية يمكننا استعادة النّسخ الاحتياطي واستبدال الملفات بأخرى من الإصدار السابق من أرشيف الإصدار. خيارات أخرى إذا كان هناك معرفة مسبقة بصدفة يونكس يجب زيارة wp-cli. ترجمة -وبتصرّف- للمقال Updating WordPress من موقع wordpress.org

يحتوي هذا الدّليل على إرشادات مفصّلة لكيفية تحديث ووردبريس وترقية إصدارها. الإرشادات نظرة على عملية التحديث أنشئ نسخةً احتياطيّةً لقاعدة بياناتك. نزِّل نسخةً احتياطيّةً لجميع ملفّات ووردبريس من مجلد ووردبريس على الخادم، بما فيها ملف htacces. تحقّق من صلاحيّة النّسخ الاحتياطيّة التي أنشأتها سابقًا قبل الاستمرار في عمليّة التّحديث. ألغِ تفعيل جميع الإضافات النّشطة. تأكّد مجدّدًا من إكمال الخطوات السّابقة، ولا تحاول تخطّي أيّ منها قبل البدء بتحديث ووردبريس. حمِّل نسخة ووردبريس مُحدثّة من wordpress.org/download وفُك ضغط حزمة الملفات المُحمَّلة. احذف ملفّات ووردبريس القديمة من خادمك، مع تفادى حذف الملفات التالية: ملفّ wp-config.php مجلّد wp-content مع استثناء مجلّدات wp-content/cache و wp-content/plugins/widgets الفرعيّة والتي يجدر بك حذفها أيضًا. مجلد wp-images. ملف htaccess. لكن إذا سبق لك إضافة تعليمات خاصّة إلى هذا الملف فلا تحذفه. ملف robots.txt. لكن إذا كان مسار موقعك هو مجلّد الجذر في خادمك وأنت من أنشأ هذا الملف، فلا تحذفه. ارفع الملفّات الجديدة من حاسبك إلى مجلد ووردبريس على الخادم الخاصّ بموقعك. شغِّل برنامج تحديث ووردبريس وإتّبع الإرشادات الظّاهرة على شاشتك. حدِّث الرّوابط الدّائمة، وملف htaccess. ثبِّت تحديثات القوالب، والإضافات. أعد تفعيل إضافات ووردبريس. تفقّد التّغييرات الجديدة في الإصدار المُحدَّث من ووردبريس. هذه نظرة مختصرة عن الخطوات اللّازمة لتحديث ووردبريس، وستحتوي بقيّة هذا الدّليل على تفاصيل أوفر لتلك الإرشادات. لا تنسَ مراجعة هذه الإرشادات إذا واجهتك أيّ مشكلة أثناء تحديثك لووردبريس للتّأكد من اتِّباعك للإجراءات المناسبة، كما يمكنك الاستعانة بصفحة استكشاف وإصلاح الأخطاء المتعلّقة بمشاكل التّثبيت الشّائعة. التحديث عبر نسخ متعددة رغم إمكانيّة وصف هذه الإرشادات بالمسار الآمِن والمتحفّظ (طالما تحتفظ بالنسخ الاحتياطية المناسبة)، إلّا أنّها تتيح تحديث نظام ووردبريس من الإصدار الأول إلى الأخير مباشرةً. وتدعم ووردبريس هذه العمليّة بفضل تركيزها على الحفاظ على توافقيّة عالية مع النّسخ الأقدم، ومع ذلك فقد يتسبب هذا في جعل عمليّة التّحديث تستغرق وقتًا أطول من المتوقع، وفي هذه الحالة قد يصبح تحديث ووردبريس تدريجيًّا عبر نسخٍ متعدّدة أكثر جدوى، لكن لا تنسَ الإبقاء على نسخة احتياطيّة من موقعك حتّى تحتفظ بخطّ رجعة في حال حدوث مشكلة. إذا كنت تُخطّط لترقية ووردبريس وتخطّي إصدارين رئيسيّين، فيجدر بك التّفكير في التّرقية تدريجيًّا، لتفادي حوادث التّعارض، وتقليل خطر تضرّر قاعدة البيانات، ويمكنك تنزيل إصدارات ووردبريس الأقدم من صفحة أرشيف إصدارات ووردبريس. قدَّم ووردبريس ميزة تحديث النّظام بضغطة زر بدءًا من إصدار 3.7، والتي ستنقلك مباشرةً إلى الإصدار الأخير، إذ تُعد هذه الميزة آمنةً، ويمكنها تحديث ووردبريس من نسخة 3.7 إلى أيّ نسخة لاحقة. الخطوة الأولى: أنشئ نسخة احتياطية لقاعدة بياناتك نزِّل نسخةً احتياطيةً من قاعدة بيانات موقعك، فجميع بيانات موقع ووردبريس الخاصّ بك، مثل: حسابات المستخدمين، والمقالات، والصّفحات، والرّوابط، والتّصنيفات، مخزنة في قاعدة بيانات MySQL. راجع دليل نسخ قاعدة البيانات لمزيدٍ من التّفاصيل عن هذه العمليّة. من المهمّ للغاية نسخ قاعدة البيانات قبل الشّروع في تحديث ووردبريس، فإذا حدث وتطلّب الأمر العودة إلى الإصدار السّابق فقد تحتاج إلى استعادة البيانات من هذه النّسخة الاحتياطيّة. الخطوة الثانية: أنشئ نسخة احتياطية لجميع ملفات ووردبريس أنشئ نسخةً احتياطيّةً لجميع الملفّات الموجودة داخل مجلّد ووردبريس، بالإضافة إلى ملف htaccess، ففي العادة تتطلّب هذه العمليّة استخدام إحدى برامج FTP لتنزيل جميع ملفّات ووردبريس من الخادم إلى حاسبك. يمكنك مراجعة دليل نسخ موقع ووردبريس الخاصّ بك احتياطيًّا لمزيد من المعلومات عن هذه العمليّة. إذا أجريت تعديلات على أيٍّ من ملفات ووردبريس الرئيسيّة، أو كان لديك إضافة مُخصصة، أو قالب ووردبريس مصمّم خصيصًا لك، فستحتاج إلى إنشاء نسخة من تلك الملفّات أيضًا. ومن المهمّ للغاية إنشاء نسخة احتياطيّة قبل البدء في تحديث نظام ووردبريس، وإذا حدث واحتجت إلى العودة إلى تلك النّسخة، فستحتاج إلى إعادة رفعها مجدّدًا إلى خادمك. الخطوة الثالثة: تحقق من صلاحية النسخ الاحتياطية تحقّق من تخزين النّسخ الاحتياطية التي أنشأتها سابقًا بأمان، مع التأكد من صلاحيتها للاستخدام، إذ تُعدّ هذه الخطوة هي الأكثر أهميّةً في كامل عمليّة تحديث نظام ووردبريس. يتضمّن التّحقّق من صلاحيّة النّسخة الاحتياطيّة، التأكّد من قدرتك على رؤية الملفّات مخزّنةً في حاسوبك، بالإضافة إلى التّأكد من قدرتك على تصفّح تلك الملفّات والمجلّدات، فإذا كانت النّسخة الاحتياطيّة موجودة على هيئة ملفّ مضغوط، فتحقق من إمكانيّة فتح هذا الملفّ وفكّ ضغطه، ويجدر بك أيضًا استعراض ملف sql. على محرّر نصّي لرؤية إذا ما كانت الجداول والبيانات معروضةً بطريقة صحيحة. الخطوة الرابعة: ألغ تفعيل جميع الإضافات انتقل إلى قسم الإضافات في لوحة التّحكم بموقع ووردبريس الخاصّ بك، وألغِ تفعيل جميع الإضافات، فقد تتعارض بعض الإضافات مع عمليّة التّحديث بسبب التّغييرات المتوقعّة على نظام ووردبريس المُحدّث، وإذا لم تكن قادرًا على الوصول إلى لوحة التّحكم، فيمكنك إلغاء تفعيل إضافاتك عبر إعادة تسمية مجلد الإضافات في الخادم. الخطوة الخامسة: تأكد من إكمال الخطوات السابقة إذا لم تكمل بعد الخطوات السّابق ذكرها فتوقف وقم بها، ولا تحاول الاستمرار في عملية التّحديث ما لم تُنهي إجراء الخطوات السّابقة. ستجد أفضل الإرشادات لمشاكل التّحديث المُعتادة في منتديات دعم ووردبريس، فإذا واجهت مشكلة ما فغالبًا ما سيسألك المتطوّعون هناك عمّا إذا قمت بالخطوات الأربع الأولى. الخطوة السادسة: نزل واستخرج حزمة ملفات ووردبريس نزِّل، وفكّ الضّغط عن حزمة ووردبريس من الرّابط التّالي: https://wordpress.org/download إذا كنت تخطّط لرفع ووردبريس إلى خادم ويب عن بعد، فنزِّل حزمة ووردبريس إلى حاسوبك باستخدام متصفّحك، ثمّ فُكّ ضغط حزمة الملفّات المُحمَّلة. إذا كان لديك وصول للصدفة shell إلى خادم الويب الخاصّ بموقعك، وكنت معتادًا على التّعامل مع أدوات سطر الأوامر، فيجدر بك تنزيل ووردبريس إلى خادمك مباشرةً، ويمكنك فعل ذلك عبر استخدام برنامج ودجت wget، أو لنكس lynx، أو أيّ من متصفحات الويب النصيّة التي لا غنى عنها إذا كنت ترغب في تفادى استخدام بروتوكول FTP. ضع حزمة الملفات في مجلد موازٍ لمجلد ووردبريس على خادمك ثم فُكّ ضغطه عبر استخدام أمر: gunzip -c wordpress-Version.tar.gz | tar -xf - أو باستخدام أمر tar -xzvf latest.tar.gz سيستخرج هذا الأمر الملفّات المخزّنة في حزمة ووردبريس إلى مجلّد فرعي باسم wordpress. الخطوة السابعة: احذف ملفات ووردبريس القديمة لماذا يجدر بك حذف تلك الملفّات؟ يُنصح عادةً بحذف الملفّات غير الضّرورية متى كان ذلك ممكنًا، وذلك نظرًا لكون عمليّة رفع ملفّات ووردبريس، أو التّحديث عبر لوحة التّحكم في خدمة الاستضافة ( cPanel أو غيرها) قد لا تستبدل جميع الملفّات على نحوٍ صحيح، مما يزيد من احتمال ظهور مشكلة لاحقًا. تفادى حذف الملفات والمجلدات التالية: ملف wp-config.php مجلد wp-content مجلد wp-includes/languages، إذا كنت تستخدم ملفّات ترجمة، وكانت مخزنة هنا بدلًا من مجلد wp-content/languages، فلا تحذفه (ربّما تكون فكرة نقل ملفات التّرجمة إلى مجلد wp-content/languages أكثر جدوى لتسهيل تحديث ووردبريس في المستقبل). ملف htaccess. في حال أضفت تعليمات خاصّة إلى هذا الملف، فيجب عليك تفادي حذفه. مجلّدات الإضافات والمحتوى المخصّص: إذا كان لديك أي ملفّات وسائط، أو محتوى خاصّ، أو إضافات خاصّة داخل مجلّد wp-content، فلا تحذفه. من ناحيةٍ أخرى تأكّد من حذف الملفّات والمجلّدات التّالية: جميع المجلّدات التي تبدأ بسابقة -wp ما عدا المجلدات سابقة الذكر. احذف أيضًا ملفّات readme.html، وwp.php، وxmlrpc.php، بالإضافة إلى ملفّات التّراخيص license.txt. عمومًا احذف جميع الملفّات الموجودة على مجلّد الجذر في خادمك، أو مجلّد ووردبريس، مع إعادة التّذكير بعدم حذف ملفّ wp-config.php، ولاحظ أنّ بعض تلك الملفّات قد لا تكون موجودةً في الإصدارات المستقبليّة. مجلّد wp-admin. مجلّد wp-includes مجلّد wp-content/plugins/widgets، سيظهر هذا المجلد فقط في حال سبق وثبتَّ إضافة الودجت الجانبية، إذ تتعارض التّعليمات البرمجيّة لهذه الودجات، مع ميزة الودجت المُضمّنة في ووردبريس افتراضيًّا. كيف تحذف هذه الملفّات؟ هناك العديد من الطّرق لحذف الملفّات من خادم موقعك، إذ يمكنك استخدام عميل FTP الخاصّ بك، أو اتّصال SSH إذا كنت تمتلك وصولًا إلى هذه الميزة، حيث تُتيح بعض خدمات الاستضافة تعديل، وحذف الملفّات والمجلّدات عبر مدير ملفّات مُضمّن بلوحة التّحكم. حذف الملفات عبر استخدام عميل FTP يمكنك استخدام نفس عميل FTP الّذي تستعمله لرفع الملفّات إلى موقعك في حذف الملفّات والمجلّدات من خادمك، وإذا لم يسمح لك عميل FTP بحذف المجلّدات غير الفارغة، فستحتاج إلى تعديل إعداداته، ففي العادة يوجد خيار ضمن إعداداته يسمح لك بحذف المجلّدات غير الفارغة، والذي ستحتاج إلى تفعيله، وتُعدّ هذه الطّريقة حلًّا سريعًا، وعمليًا للتّخلص من ملفّات إصدارات ووردبريس الأقدم، ويُنصح بإعادة ضبط إعدادات عميل FTP إلى الوضع الافتراضيّ بمجرد إكمال هذه العمليّة لأسباب أمنيّة. حذف الملفات عبر استخدام اتصال SSH إذا كنت تمتلك صلاحيّة تسجيل الدّخول إلى خادمك عبر سطر الأوامر، فيمكنك إدخال التّعليمات التّالية لإنشاء نسخة احتياطيّة من ملفّات موقعك، وحذف ملفّات ووردبريس فقط الموجودة في الخادم (إضافة إلى ملف htaccess.)، وإذا خصّصت ملفّاتٍ أخرى (index.php على سبيل المثال) لا تتضمنها تعليمات سطر الأوامر أدناه، فيجب عليك نسخها احتياطيًّا هي الأخرى: $ mkdir backup cp wp-config.php .htaccess backup cp -R wp-content backup rm wp*.php .htaccess license.txt readme.html xmlrpc.php rm -rf wp-admin wp-includes cp backup/wp-config.php . يمكنك استعادة أيّ تعديلات مخصّصة لقوالبك وإضافاتك من نسختك الاحتياطيّة بعد إنهائك لعمليّة التحديث، وكمثال: استخدم أمر cp backup/index.php . لاستعادة ملف index.php؛ أمّا كبديل آخر، فيمكنك عبر استخدام اتّصال SSH نسخ ملفات wp-config.php، وhtaccess.، وأي محتوى مخصّص قمت بإضافته، أو تعديله سابقًا إلى مجلد ووردبريس جديد، ثم أعد تسمية المجلّد القديم لأرشفته، وانقل المجلّد الجديد مكانه. الخطوة الثامنة: ارفع الملفات الجديدة إلى خادمك ارفع ملفات حزمة ووردبريس الجديدة من حاسبك إلى خادم موقعك عبر استخدام عميل FTP، فقط إتّبع نفس الخطوات التي استخدمتها سابقًا عندما ثبتَّ ووردبريس لأول مرّة، وراجع دليل رفع ووردبريس إلى خادمك ودليل استخدام برنامج FileZilla لمزيد من التّفاصيل عن كيفيّة استخدام عميل FTP لرفع الملفّات. ملاحظة: إذا لم تحذف مجلّد wp-content، فستحتاج إلى استبدال بعض ملفّاته أثناء عمليّة رفع الملفّات إلى خادمك. يتضمّن مجلّد wp-content قوالب وإضافات ووردبريس الخاصّة بك، أبقِ على هذه الملفّات وارفع جميع الملفّات الأخرى أولًا، ثمّ ارفع ملفات ووردبريس الجديدة، أو المُحدّثة إلى مجلد wp-content الجديد، مستبدلًا أيّ نسخة قديمة من الإضافات الافتراضيّة بالإصدارات الجديدة. وإذا تغيّر قالب ووردبريس الافتراضيّ، فستحتاج إلى رفع مجلّد wp-content/themes/default من النّسخة الاحتياطيّة؛ أمّا في حال أجريت تعديلات على القالب الافتراضيّ، فستحتاج إلى مراجعتها، وتثبيتها بعد إنهاء عمليّة التّحديث. الخطوة التاسعة: شغِّل برنامج تحديث ووردبريس انتقل إلى لوحة التّحكم بووردبريس على العنوان الاعتيادي الذي ينتهي بكلمة wp-admin/ مستخدمًا متصفح الإنترنت، إذ سيتفقد ووردبريس ما إذا احتاجت قاعدة البيانات إلى تحديث، وسيزودك هذا برابط جديد لإجراء تلك العمليّة. سيقودك هذا الرابط إلى تشغيل برنامج ترقية ووردبريس عبر الوصول إلى ملف wp-admin/upgrade.php، فقط عليك بتّباع الإرشادات التي ستظهر على شاشتك للاستمرار. ملاحظة: تأكّد من حصول اسم مستخدم قاعدة البيانات الذي يخص ووردبريس، على صلاحيات إنشاء، وتعديل، وحذف جداول البيانات، قبل الشّروع في هذه الخطوة. فإذا قمت بتثبيت عاديّ لووردبريس بدون تغيير شيء، فيمكنك المواصلة وتجاهل هذه الملاحظة. إذا أردت تشغيل برنامج ترقية ووردبريس يدويًّا فاتَّبع الإرشادات التّالية: إذا كان ووردبريس مُثبّتًا في مجلّد الجذر على خادمك، فوجّه متصفحك إلى العنوان التالي: http://example.com/wp-admin/upgrade.php إذا كان ووردبريس مُثبّتًا في مجلّد فرعيّ باسم blog على سبيل المثال، فعليك توجيه متصفحك إلى العنوان التالي: http://example.com/blog/wp-admin/upgrade.php إذا واجهتك مشكلة عند تسجيل الدّخول بعد تحديث ووردبريس، فقد تحتاج إلى حذف ملفّات تعريف الارتباط (cookies) من متصفّحك. الخطوة العاشرة: حدث الروابط الدائمة وملف htaccess. توجَّه إلى صفحة الرّوابط الدّائمة في قسم الإعدادات بلوحة التّحكم بالووردبريس، وحدِّث بِنيتها، وإذا تطلّب الأمر ذلك، أدرج هذه التّعليمات في ملف htaccess. الخاصّ بك، زيمكنك مراجعة دليل استخدام الروابط الدائمة لمزيد من التّفاصيل عن هذه الروابط وملف htaccess. الخطوة الحادية عشر: تثبيت القوالب والإضافات المحدثة زر جميع صفحات القوالب والإضافات واحدةً تلو الأخرى، وتفقّد معلومات التّوافق مع إصدار ووردبريس الذي حدَّثته، وفي حال تطلّب الأمر ذلك، فحدِّث إصدارات القوالب، والإضافات التي تستخدمها. الخطوة الثانية عشر: أعد تفعيل إضافاتك أعد تفعيل إضافاتك من على لوحة التّحكم بووردبريس، وإذا كان لديك شكوك حول سلامة عملها مع إصدار ووردبريس الجديد، فيمكنك تفعيلها واحدةً تلو الأخرى، بينما تختبر موقعك بحثًا عن أيّ مشكلة قبل الاستمرار. الخطوة الثالثة عشر: راجع ما تغير في إصدار ووردبريس الجديد يمكنك استخدام الرّابط التّالي لتفقُّد ما هو جديد في إصدار ووردبريس المُحدَّث: سجل التغييرات استكشاف وإصلاح الأخطاء أخطاء أو مشاكل في تنسيق المظهر إذا بدت مدوّنتك بمظهر فوضوي بعد التّحديث أو ظهرت رسائل خطأ على صفحاته، فمن المرجح أنّ إحدى الإضافات القديمة هي السبّب، ولتحديد تلك الإضافة انتقل إلى قسم الإضافات في لوحة التّحكم بووردبريس، وألغِ تفعيل جميع الإضافات التي لا يتضمّنها ووردبريس افتراضيًّا، ثم أعد تفعيلها واحدةً تلو الأخرى بينما تتفقّد واجهة موقعك. هل أجريت تعديلات خاصة على ملفات ووردبريس الرئيسية؟ إذا سبق وأجريت بعض التّعديلات لإحدى ملفّات ووردبريس، فستحتاج إلى تعقّب هذه التّعديلات، ونقلها إلى الملفّات البرمجيّة الجديدة، وتحتوي صفحة سجل إصدارات ووردبريس على قائمة بالملفّات التي تغيّرت في كلّ إصدار. قاوم رغبتك في إعادة استخدام أكوادك البرمجية القديمة يمنحك التّحديث وصولًا إلى أحدث وأفضل الأكواد البرمجيّة، لكنّ استخدامك لأكواد برمجيّة قديمة سيزيد من تخصيص موقعك من مخاطر حدوث مشاكل غير متوقّعة، فمع أنّ إغراء استخدام نصوصك البرمجيّة القديمة عالٍ، إلّا أنّ احتمالات ظهور أخطاء ستكون أعلى. أيمكنني العودة إلى إصدار أقدم؟ نعم يمكنك فعل هذا، لكن لا يُنصح عادةً بالعودة من إصدارك الحاليّ إلى نسخة أقدم، لاحتواء الإصدارات الجديدة على تحديثات أمنية لا يجدر بك المخاطرة بفقدانها، كما قد تتسبّب الاختلافات في هيكل قاعدة البيانات بين الإصدارات، في تعقيد التّعامل مع محتوى الموقع، مثل: المقالات، والتّعليقات، والإضافات، التي تعتمد على المعلومات المُخزّنة في قاعدة البيانات. فإذا كنت ما تزال راغبًا في العودة إلى إصدار أقدم، فعليك الاستمرار على مسؤوليتك الخاصّة، ويُرجى ملاحظة أنّ إكمال عمليّة العودة إلى إصدار أقدم بدون نسخة احتياطيةّ كاملة مُعدّة مسبقًا لموقعك، وقاعدة بياناته هي شبه مستحيلة. للبدء في العودة إلى إصدار ووردبريس أقدم، عليك حذف جميع ملفّات ووردبريس عدا ملف wp-config، بعدها ارفع الملفّات من النّسخة الاحتياطيّة القديمة إلى خادم موقعك، واستعدْ قاعدة البيانات من تلك النّسخة الاحتياطيّة، مع تذكّر حاجتك إلى نسخة احتياطيّة صالحة للاستخدام لإنجاح هذه العملية، وأيضًا قد لا تنجح هذه العمليّة مع إصدارات ووردبريس القديمة. الحصول على المزيد من المساعدة إذا واجهت أيّ أخطاء أثناء إجراء عمليّة التّرقية، فتفقّد صفحات المساعدة التّالية: استكشاف وإصلاح أخطاء التّثبيت الشّائعة. دليل استكشاف وإصلاح الأخطاء. المقالات المُدرجة في تصنيف تثبيت ووردبريس. إذا لم تعثر على حلّ لمشكلتك، اكتب استفسارًا عن مشكلتك في قسم أسئلة البرامج والتطبيقات في أكاديمية حسوب أو في منتديات دعم ووردبريس، حيث ستُسأل إذا ما كنت تستخدم أكوادًأ برمجيّة قديمة ليُطلب منك تغييرها، لذا ربّما يجدر بك فعل ذلك مُقدّمًا. ترجمة -وبتصرف- للمقال Upgrading WordPress – Extended Instructions من موقع WordPress.org

إحدى المهارات الأساسية والمهمة التي عليك أن تتقنها هي القدرة على استيراد وتصدير قواعد البيانات، إذ تستطيع أخذ نسخ احتياطية لقواعد بياناتك وتستعيدها عند الحاجة، أو يمكنك الاستفادة منها لنقل البيانات إلى خادوم جديد أو بيئة تطوير مختلفة. إجراء عملية تصدير من قواعد بيانات MySQL و MariaDB هو أمرٌ بسيطٌ، وسنشرحه في هذا الدرس إضافةً إلى شرح طريقة استيراد النسخة الاحتياطية. المتطلبات المسبقة لتصدير أو استيراد قواعد بيانات MySQL ستحتاج إلى: وصول إلى خادوم لينكس يستعمل قواعد بيانات MySQL أو MariaDB. قاعدة بيانات مع معلومات المستخدم القادر على إجراء عمليات عليها. تصدير قاعدة البيانات تُستعمَل الأداة mysqldump لتصدير قواعد البيانات إلى ملفات SQL نصية، ويمكن بسهولة نقل تلك الملفات كيفما تشاء. ستحتاج إلى معرفة اسم قاعدة البيانات نفسها وإلى اسم المستخدم وكلمة المرور لحسابٍ يملك امتيازاتٍ تسمح –على الأقل– بأذونات القراءة الكاملة على قاعدة البيانات. استعمل الأمر الآتي لتصدير قاعدة البيانات: mysqldump -u username -p database_name > data-dump.sql username هو اسم المستخدم الذي يستطيع الوصول إلى قاعدة البيانات database_name هو اسم قاعدة البيانات التي نريد تصديرها data-dump.sql هو مسار الملف الذي نريد حفظ مخرجات عملية التصدير إليه لن يعرض الأمر السابق أيّة مخرجات مرئية، لكن يمكنك النظر في محتويات الملف data-dump.sql لتتأكد من وجود ملف SQL سليم فيه باستعمال الأمر: head -n 5 data-dump.sql يجب أن تبدو المخرجات (التي تظهر أوّل خمسة أسطر من الملف) كما يلي، يجدر بالذكر أنَّ الملف الآتي هو ناتج عملية تصدير قاعدة بيانات باسم database_name: -- MySQL dump 10.13 Distrib 5.7.16, for Linux (x86_64) -- -- Host: localhost Database: database_name -- ------------------------------------------------------ -- Server version 5.7.16-0ubuntu0.16.04.1 إذا حدثت أيّة أخطاء أثناء عملية التصدير، فسيعرضها mysqldump على الشاشة مباشرةً. استيراد قاعدة البيانات لاستيراد ملف SQL مُصدَّر إلى قاعدة بيانات MySQL أو MariaDB، فعليك أولًا إنشاء قاعدة بيانات جديدة التي ستستضيف البيانات المستوردة. سجِّل دخولك إلى عميل قواعد البيانات بحساب المستخدم root أو أي حساب آخر له امتيازات كافية لإنشاء قواعد بيانات جديدة: mysql -u root -p ستنتقل الآن إلى سطر الأوامر الخاص بقواعد MySQL، أنشِئ الآن قاعدة بيانات جديدة وليكن اسمها new_database: CREATE DATABASE new_database; يجب أن تشاهد الناتج الآتي الذي يدل على نجاح إنشائها: Query OK, 1 row affected (0.00 sec) اخرج الآن من عميل MySQL بكتابة الأمر exit أو بالضغط على الزرين Ctrl+D، وبعد عودتك إلى سطر الأوامر ستستطيع استيراد الملف باستخدام الأمر الآتي: mysql -u username -p new_database < data-dump.sql username هو اسم المستخدم الذي يستطيع الوصول إلى قاعدة البيانات new_database هو اسم قاعدة البيانات التي نريد استيراد البيانات إليها data-dump.sql هو مسار الملف الذي نريد استيراد محتوياته لن تظهر أية مخرجات إذا نجح تنفيذ الأمر السابق، لكن إن حدثت أخطاء خلال العملية فسيظهرها الأمر mysql على الشاشة. يمكنك التأكد من استيراد قاعدة البيانات بتسجيل الدخول إلى عميل MySQL مجددًا وتفحص البيانات، يمكن فعل ذلك بتحديد قاعدة البيانات الجديدة عبر USE new_database ثم كتابة الأمر SHOW TABLES;‎ أو ما شابهه. الخلاصة أصبحت تعلم كيف تصدِّر قواعد بيانات MySQL إلى ملفات وكيف تستوردها مجددًا. هنالك خياراتٌ أخرى متاحةٌ للأمر mysqldump التي تُعدِّل سلوك هذا الأمر عند تصدير قواعد البيانات، والتي يمكنك التعرف عليها في صفحة التوثيق الرسمي. ترجمة –وبتصرّف– للمقال How To Import and Export Databases in MySQL or MariaDB لصاحبه Mateusz Papiernik

تحتاج لوضع خطَّة صيانة شهريَّة لمواقعك على ووردبريس إلى تنظيم المهام التي تنجزها يوميًّا وأسبوعيًّا وشهريًّا وحتى سنويًّا وتقسيمها إلى بضعة فئات رئيسيَّة وهي: النسخ الاحتياطي والتحديثات الأساسيَّة لووردبريس وصيانة الإضافات (Plugin) وصيانة القوالب وسلامة الموقع بالكامل وسلامة المحتوى. يجب الإشارة إلى أنَّ هذا الدرس هو نموذج أساسي لإنشاء خطَّة صيانة شهرية خاصَّة بك؛ يمكنك تعديلها بحسب خبرتك بالمهام التي تنجزها بانتظام لوحدك أو مع فريقك، باعتبارك مطورًا لووردبريس. النسخ الاحتياطي في ووردبريس يجب إجراء النسخ الاحتياطي على ووردبريس في فترات منتظمة ويفضل أن تكون يوميَّة؛ النسخ الاحتياطي كل أسبوع لا بأس به ولكن النسخ الاحتياطي كل شهر هو أطول فترة وغير مفضل. يسمح لك الموقع «ManageWP» بتزويد العملاء بخدمة النسخ الاحتياطي التراكمي اليومي دون الحاجة إلى النسخ الاحتياطي للموقع الذي تديره يدويًّا. الخيارات المقترحة لإجراء النسخ الاحتياطي هي: • يوميًّا • أسبوعيًّا • شهريًّا التحديثات الأساسيَّة لووردبريس من الصعب جدولة عملية التحديثات (خصوصًا التحديثات الأساسيَّة لووردبريس) ضمن مخطط زمني ثابت إذ لا تصدر التحديثات في فترات منتظمة. على أي حال، نجد خلال العامين الماضيين أنَّ التحديثات أصبحت تتكرر بشكل كبير لذا أنصحك باختيار يوم ما في كل شهر تتفقد فيه التحديثات وتثبِّتها على جميع المواقع التي تديرها. يمكن أن نستثني من هذه القاعدة حالة تثبيت التحديثات الأساسيَّة لووردبريس عند صدورها مباشرةً بناءً على طلبك أو طلب شركتك. الخيارات المقترحة للتحقق من التحديثات وتثبيتها هي: • فور صدورها مباشرةً • شهريًّا صيانة الإضافات تتكون صيانة الإضافات في ووردبريس من عنصرين هما: • تحديث الإضافات • فحص الإضافات تحديث الإضافات تقترح ووردبريس التأكد من وجود تحديثات للإضافات كل 3 إلى 6 أشهر؛ إن كنت مطورًا لووردبريس فستدرك مدى ضعف هذه النصيحة لمواقع وردبريس التي من المفترض أن تعمل يوميًا بصورة صحيحة، وستسعفك حينئذٍ خبرتك في تحديد موعد لهذه التحديثات في مخططك الزمني. قد لا تتوافر التحديثات الأساسيَّة لووردبريس دومًا لذا يمكن التحقق من تحديثات الإضافات أيضًا في اليوم نفسه أي الجمع بينها في يوم واحد. الخيارات المقترحة للتحقق من تحديثات الإضافات وتثبيتها هي: • شهريًّا فحص الإضافات تختلف مهمة الصيانة هذه قليلًا عن المهمة السابقة التي تقتصر على التحقق من وجود تحديثات ثمَّ تثبيتها، كما أنَّها غير قابلة للجدولة أي لا تضاف إلى مخططك الزمني لتنفِّذها كلَّ شهر. أول أمر تتطلبه هذه المهمة هو التأكُّد من عدم وجود إضافات مثبَّتة ومفعَّلة في المواقع التي تديرها ولكنَّها غير مستخدمة، فقد يستمتع بعض العملاء بتجريب مزايا جديدة عبر تثبيت إضافات جديدة دون إذنك وينسَون بعدئذٍ إلغاء تفعيلها وحذفها. يجب أن تعرف الإضافات التي يتوافر لها تحديثات من تلك التي لا يوجد لها تحديثات، فمن المحتمل أن يُرفع الدعم عن الأخيرة وتصبح بذلك غير آمنة؛ إن صادفت وجود إضافة غير مدعومة فساعد عميلك على اختيار البديل المناسب. يجب عليك أيضًا أن تراقب جودة الإضافات وأداءها وتبحث دومًا عن وجود بديل أفضل من تلك التي تستخدمها إن شعرت أن أدائها آخذ في التدنِّي. لنأخذ مثلًا الإضافة Disqus الرسميَّة التي بدأت تكسب سمعة سيئة إذ أصبحت مشوبة بالأخطاء ومعطلة تمامًا؛ أخذ أحد المطورين على عاتقه تطويرها ليصدرها باسم Disqus Conditional Load وهي مشابهة للإضافة السابقة لكنَّها خالية نسبيًّا من الأخطاء وتُستخدم بكثرة حاليًّا. الجزء الأخير من هذه المهمة يتضمن استعراض مجلد الإضافات للتأكد من حذف كامل الإضافات التي أَلغيت أنت أو عميلك تثبيتها. الخيارات المقترحة لهذه المهمَّة هي: • 3 أشهر • 6 أشهر • سنة صيانة القوالب تُقسم هذه المهمة إلى جزأين وهما: تحديث القوالب يجب أن يكون جدول مواعيد المهام المتعلقة بتحديث القوالب مطابق لمواعيد للمهام التي تنجزها لتحديث الإضافات؛ بعبارة أخرى، حدِّد موعدًا واحدًا لمهمَّة تحديث القوالب ومهمَّة تحديث الإضافات لتنجزهما سويةً في الوقت ذاته، على فرض أنَّك تستخدم قوالب غير رسمية. الخيارات المقترحة لتحديث القوالب: • شهريًّا فحص القالب ستفيدك هنا خبرتك كثيرًا لتحديد المهام المتعلِّقة بفحص القوالب التي يجب أن تُنفِّذها وكم تحتاج من الوقت لتكرارها. بصورة مشابه لفحص الإضافات، تتضمن هذه المهمة التأكد من عدم وجود قوالب غير مستخدمة مثبَّتة في الموقع وأنَّ قالبًا واحدًا على الأقل موجودٌ باعتباره القالب الرئيسي والافتراضي في الموقع. إن كنت تستخدم قالبًا خاصًّا بك فأضف إلى هذه المهمة فحص ملفات وأنماط قالبك للتأكد من أنَّ كلَّ شي مرتبٌ ومنظمٌ والكود الذي كتبته ما يزال صالحًا. إن كنت تستخدم قالبًا خارجيًا فتأكد أنَّ المطور ما يزال يعمل على الكود ويقدم الدعم للقالب. الخيارات المقترحة لفحص القالب: • 3 أشهر • 6 أشهر • سنة إن كنت مرتاحًا بالعمل وفق مخططك الزمني الذي وضعته لقالبك أو نمطك المخصص بك على المواقع التي تديرها فاستمر بذلك. سلامة كامل الموقع يحوي الموقع «ManageWP» على مزيَّة التحديثات الأمنيَّة (Vulnerability Updates) التي تنبِّهك بوجود إضافات وقوالب وملفات ووردبريس أساسيَّة ومهمَّة، كما تسمح لك بعرض أداء الموقع. الخيارات المقترحة لتصفح التحديثات الأمنيَّة: • يوميًّا يوفِّر الموقع «ManageWP» أيضًا مزيَّة الفحص الأمني (Security Check) التي تفحص كامل موقعك بحثًا عن برمجيات خبيثة في أي وقت تريد، كما تستطيع تفعيل وضع مراقبة الأمن 24/7 الذي يوفِّره الإصدار المدفوع. الخيارات المقترحة لمراقبة أمن الموقع: • مرة يوميًّا • عدة مرات يوميًّا • 24/7 الأمر الأخير الذي أودُّ ذكره ضمن هذا الموضوع هو الأداء الكلي للموقع أي فترة تحميل صفحاته وحجمها ورفع أدائه وغيرها. يحوي الموقع «ManageWP» مزيَّة أخرى وهي فحص الأداء (Performance Scan) التي تعطيك لمحة عن أداء موقعك وما هي المشكلات التي يعاني منها وماذا يحدث فيه. الخيارات المقترحة لفحص أداء الموقع: • شهريًّا سلامة المحتوى قد تتطلب هذه المهمة منك العمل مع عميلك أغلب الوقت خلافًا للمهام السابقة؛ تتضمن هذه المهام التحقق من الأخطاء 404 أو الروابط المعطلة وتحسينها. الخيارات المقترحة لأداء هذه المهمة: • شهريًّا يجب عليك أيضًا العمل مع عميلك للبحث عن أي مقاطع فيديو أو صوت لم يعد يستخدمها أو للبحث عن مدونات منشورة يستطيع دمجها مع بعضها أو منشورات ذات محتوى قديم، وهذا ما يدعى “تدقيق المحتوى”. عليك أيضًا أن تراقب تصنيفات SEO لعملائك إذ إنَّ نجاحهم هو في النهاية نجاحك؛ للمزيد اقرأ هذه المقالة. الخيارات المتاحة لدقيق المحتوى: • 6 أشهر • سنة دورك الآن غطَّت هذه المقالة مهام الصيانة عمومًا التي قد تختلف عن المهام التي تنجزها أنت أو فريقك؛ ما هي المهام الأخرى التي تضيفها لجدولك الزمني؟ وما هي المهام التي تتركها؟ شاركنا رأيك بالتعليقات. ترجمة -وبتصرف- للمقال How to Create a Monthly Maintenance Plan for Your WordPress Sites لصاحبه Brenda Barron. حقوق الصورة البارزة محفوظة لـ Freepik

لقد سعد أفراد موقع WPMU DEV للغاية لأنهم أحبوا أتمتة أداة Automate للكثير من الأشياء. وكما فعلتَ أنت، ضاعفوا جهودهم لإضافة بعض التحسينات الجميلة، بدءًا بما يسمّونه "الترقيات الآمنة". أتريد إلقاء نظرة؟ أظن ذلك قبل أن نبدأ، إذا لم تكن معتادًا على Automate، فهي في الأساس أداة توفّر عليك وقتًا محددًا لتحديث جميع مواقعك التي تعمل بووردبريس (وكذلك مواقع عملائك). إليك كيفية ذلك في حالة اكتشاف تحديث: تُنشئ Automate نسخة احتياطية (backup) من موقعك. إذا نجح ذلك، ستُرقِّي Automate الإضافات (plugins) والقوالب (themes) التي حددتها على أنها موثوقة (مع تحديث نواة ووردبريس (WordPress core)). ستُرسَل إليك رسالة بريد إلكتروني تحتوي على الأخبار السعيدة (بالإضافة إلى أنها كلها مخزّنة في سجل النشاط). ولكن الآن، هناك خطوة إضافية، وهي على الأرجح ستعجبك: تُنشئ Automate نسخة احتياطية (backup) من موقعك. تسيطر أداة "الترقية الآمنة" على الشاشة مانعة إياك من إجراء أي عملية حتى الانتهاء من الترقية. إذا نجح ذلك، ستُرقِّي Automate الإضافات (plugins) والقوالب (themes) التي حددتها على أنها موثوقة (مع تحديث نواة ووردبريس (WordPress core)). تقوم "الترقية الآمنة" بالتحقق من عمل موقعك ومن خلوّه من الأخطاء (باستخدام خدمة موقع WPMU DEV المسماة Uptime). تتخذ "الترقية الآمنية" مكانًا من صفحتك الرئيسية لتعرض لك أي اختلافات حدثت مقارنة بالنسخة السابقة. سيُرسل إليك رسالة بريد إلكتروني تحتوي على الأخبار السعيدة (بالإضافة إلى أنها كلها مخزّنة في سجل الأنشطة) بما في ذلك وقت التشغيل (uptime) وفحص الأخطاء بالإضافة إلى تمييز لون أي اختلاف في الشاشة الجديدة. لذلك، يُختَبر في موقع WPMU DEV تلقائيًا الطريقة التي سارت بها الترقية (upgrade) وسيرسلون لك بريدًا إلكترونيًا على الفور لإعلامك بكل شيء عن هذه الترقية. تحقّق من ذلك. كل شيء جرى على ما يرام. ومع ذلك، إن كان هناك تغييرات كبيرة، فلن نذكر لك النسبة المئوية لاختلاف هذه الترقية عن النسخة السابقة، بل سنسّلط الضوء عليها باللون الوردي الفاقع (jarring pink)، لذلك لن تفوتك هذه التغيّرات ما لم يكن موقعك مطليًا كلّه باللون الوردي الآن، كما يمكنك أن ترى، يعود الفارق المئوي إلى شريط التمرير الكبير الضخم (massive slider)، ونلاحظ أن شرائط التمرير (sliders) ومربعات المحتوى (dynamic content) قد تحدث فرقًا. ويمكنك أن تراها في البريد الإلكتروني لذا لا يوجد تلاعب هنا. إنها رائعة وسهلة الإعداد. في الحقيقة، يظن أفراد موقع WPMU DEV أنه من المهم للغاية أنهم عملوا ذلك بالفعل من أجلك بالطبع، يمكنك إعداد البريد الإلكتروني الذي تريد أن يرسل يكون الإرسال إليه ويمكنك إعداد مدى تكرار ذلك. يُفضّل الكاتب James Farmer اختيار وصول البريد الإلكتروني على الفور لأنه يُعرّفك ما إذا كانت هناك أية مشكلات، ولكن يمكنك الحصول على ملخّصات يومية أو أسبوعية أو شهرية بحسب رغبتك. وبالتأكيد، فهناك سجل كامل حيث يمكنك الآن مراجعة التحديثات والنُسَخ الاحتياطية، بل ويمكنك أيضًا استعراض الشاشة التي عملتها أداة "الترقية الآمنة". ولن تتوقف عند هذا الحد! في الشهر القادم أو نحوه (بحسب تاريخ المقال الأصلي)، توقّع أن ترى بعض الميزات الأخرى المفيدة التي أضيفت إلى ووردبريس، مفصلة تفصيلًا أكبر أدناه: الأتمتة الآلية المجدولة (Scheduled Automate)، ونتيجة لذلك يمكنك ضبط الأتمتة الآلية (والترقية الآمنة Safe Upgrade) بأن تعمل في أوقات محددة. مثلا، خلال الأسبوع الذي تقضيه في العمل، إن حدث شيء ما، يمكنك إصلاحه في أسرع وقت ممكن. تنبيهات عتبة التحمّل (Threshold Alerts)، إذا تعطّل موقعك، فأنت تريد معرفة ذلك على الفور (وقام مطورو WPMU DEV بتوفير ذلك على الفور في أداة Uptime) ولكنه سيُسمح بإرسالك بريدًا إلكترونيا فقط إذا اكتشفت أداة الترقية الأمنة (Sage Upgrade) فارقًا أكبر من %25 قبل وبعد إمساك جزء من الشاشة (يمكنك تعيين النسبة المئوية التي تريد). ولكن لماذا يتوقف موقع WPMU DEV عند هذا الحد؟ أخبر موقع WPMU DEV كيف ترغب أن تكون أداة في المستقبل وما الميزات التي تريدها لهذه الأداة. أخبرهم في التعليقات فهم ينتظرون انطباعك بفارغ الصبر. ترجمة -وبتصرف- للمقال Automate Just Got More Amazing – Introducing ‘Safe Upgrade’ لصاحبه James Farmer

يختار كثيرون من مطوري الويب الحديث اليوم استخدام قواعد بيانات NoSQL في مشاريعهم، وعادة ما تكون MongoDB اختيارهم الأول. إنّ إنشاء نسخ احتياطية بشكل دوري أمر مهم إن كنت تستخدم قواعد MongoDB في مشاريع في طور التشغيل وذلك بغرض الحفاظ على البيانات من التلف، ولحسن الحظ، توفّر MongoDB أمرًا بسيطًا ضمن أدواتها لإنشاء واستعادة النسخ الاحتياطية. لفهم كيفية عمل النسخ الاحتياطية دون المساس بقواعد بيانات عملك الخاص، سنبدأ المقال بإنشاء قاعدة بيانات جديدة وإضافة قدر بسيط من البيانات إليها، بعد ذلك سنقوم بإنشاء نسخة احتياطية لهذه القاعدة، ومن ثم حذفها واستعادتها من النسخة الاحتياطية التي قمنا بإنشائها. المتطلبات نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة مقال الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. الخطوة الأولى: إنشاء قاعدة بيانات تجريبية إنّ إنشاء نسخة احتياطية لقاعدة بيانات فارغة ليس أمرًا مفيدًا، لذا سنقوم في هذه الخطوة بإنشاء قاعدة بيانات تجريبية وإضافة بعض البيانات لها. إنّ أسهل طريقة للتعامل مع MongoDB هي عبر سطر أوامرها الذي يمكن فتحه بتنفيذ الأمر mongo في سطر الأوامر العادي. > mongo بعد ذلك سنقوم بإنشاء قاعدة بيانات جديدة سندعوها myDatabase وذلك باستخدام الأمر المساعد use: $ use myDatabasee سنحصل على الخرج التالي نتيجة لتنفيذ الأمر: switched to db myDatabase ينبغي على جميع البيانات في قاعدة MongoDB أن تتبع لمجموعة collection. وبالرغم من ذلك، فليس هناك حاجة لإنشاء مجموعة بشكل خاص، فعند استخدام التابع insert لإدخال بيانات لمجموعة غير موجودة، سيتم إنشاء المجموعة بشكل تلقائي قبل كتابة البيانات. بإمكانك استخدام الشفرة البرمجية التالية لإضافة 3 سندات documents لمجموعة تدعى myCollection باستخدام التابع insert: db.myCollection.insert([ {'name': 'Alice', 'age': 30}, {'name': 'Bill', 'age': 25}, {'name': 'Bob', 'age': 35} ]); وستظهر الرسالة التالية إن تم تنفيذ الشفرة بنجاح: BulkWriteResult({ "writeErrors" : [ ], "writeConcernErrors" : [ ], "nInserted" : 3, "nUpserted" : 0, "nMatched" : 0, "nModified" : 0, "nRemoved" : 0, "upserted" : [ ] }) الخطوة الثانية: التحقق من حجم قاعدة البيانات الآن وبعد أن حصلنا على قاعدة مع بعض البيانات فيها، سنقوم بأخذ نسخة احتياطية لها. ولكن حجم النسخ الاحتياطية قد يكون كبيرًا إن كانت لديك قاعدة بيانات كبيرة، وبالتالي حتى نتجنب المخاطرة باستهلاك مساحة التخزين المتبقية في القرص، وبالنتيجة إبطاء الخادوم أو منعه من العمل، فيجب أن نتحقق من حجم قاعدة البيانات قبل البدء بالنسخ الاحتياطي. للقيام بذلك بإمكاننا استخدام التابع stats والتحقق من القيمة التي يعيدها المفتاح dataSize لمعرفة حجم القاعدة مقدّرًا بالبايت. $ db.stats().dataSize; وبالنسبة لقاعدة بياناتنا التجريبية فإن الحجم سيكون رقمًا صغيرًا يبلغ 592 بايت. انتبه إلى أن القيمة التي يعطيها dataSize هي قيمة تقريبية لحجم النسخة الاحتياطية. الخطوة الثالثة: إنشاء النسخة الاحتياطية بإمكاننا استخدام الأمر mongodump والذي سيقوم باستدعاء أداة من الأدوات المرفقة مع MongoDb. سيقوم الأمر mongodump بشكل افتراضي بإنشاء نسخة احتياطية لجميع قواعد البيانات المستخدمة. ولإنشاء نسخة احتياطية لقاعدة بيانات معيّنة، يجب إضافة الخيار -d وتحديد اسم القاعدة. إضافة لذلك، يمكن إعلام mongodump بالمكان الذي نرغب بتخزين النسخة الاحتياطية فيه وذلك باستخدام الخيار -o وتحديد المسار. يتم تنفيذ mongodump من سطر الأوامر العادي لذا سنقوم الآن بإنهاء العمل بسطر أوامر mongo والعودة لسطر الأوامر العادي وذلك بالضغط على مفتاحي Ctrl+D. سنقوم بعد ذلك بتنفيذ الأمر mongodump لإنشاء نسخة احتياطية لقاعدتنا myDatabase وتخزين النسخة في المسار backups/first_backup/~: $ mongodump -d myDatabase -o ~/backups/first_backup إن تم تنفيذ الأمر بنجاح فيفترض أن تظهر الرسالة التالية: 2015-11-24T18:11:58.590-0500 writing myDatabase.myCollection to /home/me/backups/first_backup/myDatabase/myCollection.bson 2015-11-24T18:11:58.591-0500 writing myDatabase.myCollection metadata to /home/me/backups/first_backup/myDatabase/myCollection.metadata.json 2015-11-24T18:11:58.592-0500 done dumping myDatabase.myCollection (3 documents) 2015-11-24T18:11:58.592-0500 writing myDatabase.system.indexes to /home/me/backups/first_backup/myDatabase/system.indexes.bson لاحظ بأنّ النسخة الاحتياطية ليست ملفًّا واحدًا بل هو مجلد يملك الهيكل التالي: first_backup └── myDatabase ├── myCollection.bson ├── myCollection.metadata.json └── system.indexes.bson الخطوة الرابعة: حذف قاعدة البيانات لاختبار النسخة الاحتياطية التي قمنا بالحصول عليها، يمكن إما التوجّه لخادوم آخر يملك نسخة MongoDB أخرى أو حذف قاعدة البيانات التجريبية من الخادوم الحالي، وسنختار الخيار الثاني في المقال. لنقم الآن بفتح سطر أوامر mongo ومن ثم الاتصال بقاعدة البيانات: $ mongo myDatabase سنقوم بحذف قاعدة البيانات باستخدام التابع dropDatabase: $ db.dropDatabase(); إن تم حذف القاعدة بنجاح، ستشاهد الرسالة التالية: { "dropped" : "myDatabase", "ok" : 1 } وللتأكد يمكن استخدام التابع find على المجموعة myCollection وسنرى بأن جميع البيانات المدخلة سابقًا قد اختفت. $ db.myCollection.find(); وبطبيعة الحال فلن يكون هناك أي خرج نتيجة لتنفيذ الأمر لعدم وجود بيانات لإظهارها. الخطوة الخامسة: استعادة قاعدة البيانات من النسخة الاحتياطية لاستعادة قاعدة البيانات التي حصلنا على نسخة احتياطية منها باستخدام الأمر mongodump، سنقوم باستخدام أداة أخرى من أدوات Mongo يسمى mongorestore، ولكن قبل استخدامه قم بالعودة لسطر الأوامر العادي بالنقر على مفتاحي Ctrl+D إن كنت ما تزال في سطر أوامر mongo. إن من السهل استخدام أمر mongorestore حيث يكفي تمرير المسار الذي توجد به النسخة الاحتياطية كما في المثال: $ mongorestore ~/backups/first_backup/ وستظهر رسالة تشبه التالية دلالة على نجاح التنفيذ: 2015-11-24T18:27:04.250-0500 building a list of dbs and collections to restore from /home/me/backups/first_backup/ dir 2015-11-24T18:27:04.251-0500 reading metadata file from /home/me/backups/first_backup/myDatabase/myCollection.metadata.json 2015-11-24T18:27:04.252-0500 restoring myDatabase.myCollection from file /home/me/backups/first_backup/myDatabase/myCollection.bson 2015-11-24T18:27:04.309-0500 restoring indexes for collection myDatabase.myCollection from metadata 2015-11-24T18:27:04.310-0500 finished restoring myDatabase.myCollection (3 documents) 2015-11-24T18:27:04.310-0500 done ولاختبار البيانات التي قمنا باستعادتها، سنقوم بفتح سطر أوامر mongo مجددًا والاتصال بقاعدة myDatabase: $ mongo myDatabase ومن ثم نستخدم الأمر find على المجموعة: $ db.myCollection.find(); فإن سار كل شيء على ما يرام، ينبغي الآن أن تظهر لك البيانات المدخلة سابقًا: { "_id" : ObjectId("5654e76f21299039c2ba8720"), "name" : "Alice", "age" : 30 } { "_id" : ObjectId("5654e76f21299039c2ba8721"), "name" : "Bill", "age" : 25 } { "_id" : ObjectId("5654e76f21299039c2ba8722"), "name" : "Bob", "age" : 35 } الخلاصة تعلّمنا كيفية استخدام mongodump و mongorestore لإنشاء نسخة احتياطية واستعادة واحدة تخص قاعدة بيانات MongoDB. تذكر بأن إنشاء نسخة احتياطية هي عملية شرهة لموارد النظام ويمكن لها أن تخفض من أداء محرك MongoDB، لذا ينصح بأن تتم العملية فقط في الساعات التي تكون فيها الطلبات على القاعدة أقل ما يمكن. ترجمة -وبتصرّف- للمقال How to Create and Use MongoDB Backups on Ubuntu 14.04 لصاحبته Hazel Virdó.

يُعدّ محرك قواعد بيانات MongoDB أحد أشهر محرّكات قواعد بيانات NoSQL، ويشتهر بمرونته وقابليته للتوسعة وقوّته ومدى اعتماديّته وسهولة استخدامه. سنتحدث في المقال عن كيفية إجراء نسخ احتياطي واستعادة نسخة احتياطية ونقل قاعدة بيانات MongoDB. عند الحديث عن الاستيراد والتصدير في MongoDB فالمقصود التعامل مع البيانات بصيغة مقروءة من قبل البشر، ومتوافقة مع باقي المنتجات البرمجية. بالمقابل، فإن عمليات النسخ الاحتياطي واستعادة النسخ الاحتياطية تُنشئ أو تَستخدم نمط بيانات ثنائية binary خاصّة بـ MongoDB، وتحافظ بالتالي على تناسق وسلامة البيانات إضافة إلى سمات MongoDB الخاصة. بناء على ما سبق، فإنّه من المفضّل استخدام النسخ الاحتياطي عند الحاجة لتهجير migration قاعدة البيانات طالما أن هناك توافقية ما بين النظام المصدر والنظام الهدف. المتطلبات الأولية قبل أن نتابع، يرجى التأكّد من توفر المتطلبات التالية بشكل كامل: نظام تشغيل Ubuntu، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة مقال الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. وعدا عمّا قد يستثنى بوضوح، فإنّ جميع الأوامر التي تحتاج لصلاحيات مدير نظام root في المقال، يجب أن يتم تنفيذها من قبل مستخدم عادي يملك صلاحيات sudo. نسخة قاعدة بيانات MongoDB تجريبية، ويمكن الحصول على واحدة وتثبيتها وفق التعليمات المذكورة في مقال استيراد وتصدير قاعدة بيانات MongoDB في نظام أوبنتو 14.04. تنبيه: يجب تنفيذ جميع الأوامر المذكورة في المقال بصلاحيات المستخدم العادي من خلال أمر sudo ويستثنى من ذلك ما يذكر صراحة أن يتم تنفيذه وفق صلاحيات مدير النظام root. فهم الأساسيات سنحتاج لفهم بعض الأمور قبل أن نتابع أكثر في المقال، وإن كنت تملك بعض الخبرة مع قواعد البيانات العلائقية relational المشهورة مثل MySQL، فربّما تجد بعض التشابه عند العمل مع MongoDB. إنّ أول ما تحتاج معرفته حول MongoDB هو أنها تستخدم صيغتي json و bson (الصيغة الثنائية binary من json) بغرض تخزين المعلومات. إنّ Json هي صيغة مقروءة من قبل البشر وبالتالي مناسبة جدًا لتصدير واستيراد البيانات في نهاية الأمر، ومن الممكن أيضًا التعديل على البيانات المصدّرة باستخدام أيّ أداة تدعم json، بما في ذلك أي محرر نصوص بسيط. يبدو أحد الأمثلة عن مستند json على الشكل التالي: {"address":[ {"building":"1007", "street":"Park Ave"}, {"building":"1008", "street":"New Ave"}, ]} إنّ Json مناسبة جدًا للعمل معها، لكنها لا تدعم جميع أنماط البيانات المتاحة في bson، وهذا يعني بأنّه سيكون لدينا "فقدان في الدقّة" في البيانات عند استخدام json، ولهذا السبب فإنّه من الأفضل استخدام الصيغة الثنائية bson في حالة النسخ الاحتياطي والاستعادة لأنّها ستساعد في استعادة قاعدة بيانات MongoDB بشكل أدق. ثانيًا، ليس هناك داعٍ للقلق حول إنشاء قاعدة البيانات إن لم تكن موجودة أصلًا عند القيام باستعادة نسخة احتياطية، حيث سيتم إنشاؤها بشكل تلقائي. إضافة لذلك، فإنّ هيكل المجموعات collections (التي تُقابل الجداول) في القاعدة -بخلاف محركات قواعد البيانات الأخرى- سيتم إنشاؤها أيضًا بشكل تلقائي عند إدراج insert أول سطر. ثالثًا، إن قراءة وإدراج كمّية كبيرة من البيانات في MongoDB، قد يستهلك مصادر النظام كقدرة المعالج، الذاكرة ومساحة التخزين بشكل كبير جدًا وهذه نقطة حساسة على اعتبار أن MongoDB تُستخدم عادة مع قواعد البيانات الكبيرة والبيانات الضخمة، والحل الأسهل لهذه المشكلة هو تنفيذ عمليات التصدير والنسخ الاحتياطي ليلًا. رابعًا، فقد يكون هناك مشكلة في تناسق البيانات إن كنت تملك خادوم MongoDB معرّض لضغط العمل باستمرار وبالتالي قد تتغير البيانات أثناء عملية التصدير، حيث لا يوجد حل بسيط لهذه المشكلة ولكن في نهاية المقال سنتحدث حول استنساخ البيانات replication. وعلى الرغم من أنه من الممكن استخدام وظائف الاستيراد والتصدير للحصول على نسخة احتياطية أو استعادتها، تبقى هناك طرق أفضل لتضمن دقة البيانات في قاعدة MongoDB، ومن هذه الطرق استخدام الأمر mongodump للحصول على نسخة احتياطية للبيانات، والأمر mongorestore لاستعادة نسخة احتياطية سابقة. الحصول على نسخة احتياطية لقاعدة بيانات MongoDB لنتحدث أولًا عن الحصول على نسخة احتياطية لقاعدة البيانات. يقوم المُعامل db-- في الأمر mongodump بتحديد اسم قاعدة البيانات التي نرغب بالحصول على نسخة احتياطية لها، فإن لم يتم تحديد اسم قاعدة البيانات، سيقوم الأمر بإنشاء نسخة احتياطية لجميع قواعد البيانات التي يديرها محرّك MongoDB. أما لتحديد مسار المجلّد الذي سيتم تخزين النسخ الاحتياطية فيه فنستخدم المُعامل out--. لنرى المثال التالي للحصول على نسخة احتياطية من قاعدة بيانات اسمها newdb ولتخزين النسخة في مجلد var/backups/mongobackups/. نصيحة: من الأفضل أن يتم تخزين كل نسخة احتياطية في مجلد فرعي يُسمّى بتاريخ اليوم الذي تم إنشاء النسخة الاحتياطية فيه، مثل var/backups/mongobackups/01-20-16/ (العشرون من كانون الثاني 2016). لنقم أولًا بإنشاء المجلد الرئيسي الذي سنقوم فيه بتخزين النسخ الاحتياطية لقواعد MongoDB التي نملكها، ونستخدم لذلك الأمر: $ sudo mkdir /var/backups/mongobackups ثم نقوم بإنشاء نسخة احتياطية بالأمر التالي: $ sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"` فإن تم تنفيذ الأمر بنجاح، سيظهر ما يشبه النتيجة التالية على الشاشة: 2016-01-20T10:11:57.685-0500 writing newdb.restaurants to /var/backups/mongobackups/01-20-16/newdb/restaurants.bson 2016-01-20T10:11:57.907-0500 writing newdb.restaurants metadata to /var/backups/mongobackups/01-20-16/newdb/restaurants.metadata.json 2016-01-20T10:11:57.911-0500 done dumping newdb.restaurants (25359 documents) 2016-01-20T10:11:57.911-0500 writing newdb.system.indexes to /var/backups/mongobackups/01-20-16/newdb/system.indexes.bson لاحظ في الأمر الذي قمنا بتنفيذه أننا أدرجنا الجزء التالي "date +"%m-%d-%y الذي يقوم بالحصول على تاريخ اليوم بشكل تلقائي، وبالتالي نحصل على نسخة احتياطية داخل مجلد فرعي /var/backups/mongobackups/01-20-16/، وهذا مناسب جدًا إن قمنا بجدولة الأمر ليتم تنفيذه بصورة اوتوماتيكية. عند الوصول إلى هذه المرحلة نكون قد حصلنا على نسخة احتياطية لقاعدة البيانات المسمّاة newdb في المسار /var/backups/mongobackups/01-20-16/newdb/، وتملك هذه النسخة جميع المعلومات اللازمة لاستعادة حالة القاعدة newdb في حال حصول مشكلة فيها. وكقاعدة عامة، يجب أن يتم الحصول على نسخ احتياطية بشكل دوري، على أساس نسخة احتياطية يومية مثلًا، ويستحسن أن يتم تنفيذ العملية في الوقت الذي يكون نشاط الخادوم أقل ما يمكن، وللقيام بذلك يمكن جدولة تنفيذ الأمر mongodump باستخدام cron حتى يتم تنفيذه بصورة دورية، مثلاً، الساعة 3:03 صباحًا من كل يوم. لتنفيذ ذلك سنقوم بفتح محرّر cron المسمّى crontab على الشكل التالي: $ sudo crontab -e ملاحظة: عندما يتم تنفيذ الأمر sudo crontab فإننا نقوم بتحرير المهام المجدولة الخاصة بحساب المستخدم مدير النظام root. إن هذا مستحسن لأنه في حال جدولة الأمر mongodump ليتم تنفيذه بصلاحيات مستخدم آخر فقد لا يتم التنفيذ بشكل صحيح وخصوصًا إن كانت إعدادات sudo تتطلب تأكيد الأمر بإدخال كلمة المرور. سنقوم في crontab بإدخال السطر التالي: 3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"` لاحظ أننا لم نستخدم المعامل db-- في الأمر السابق لأننا نرغب بالحصول على نسخة احتياطية دورية لجميع القواعد التي نملكها. إن تنفيذ النسخ الاحتياطي الدوري سيؤدي مع الوقت إلى استهلاك مساحة التخزين على القرص الصلب، لذا فمن الأفضل أن يتم حذف النسخ الاحتياطية القديمة بصورة دورية أو خفض المساحة التي تستهلكها عبر ضغطها. لحذف النسخ الاحتياطية التي تم الحصول عليها قبل 7 أيام يمكن أن نستخدم الأمر التالي: $ find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \; وكما في الأمر المُجدول السابق فمن الممكن التخلص من النسخ الاحتياطية القديمة بصورة دورية عبر تنفيذ الأمر قبل أمر النسخ الاحتياطي، ولأجل هذا سنقوم بإدراج السطر التالي في cron، والذي سيتم تنفيذه الساعة 3:01 صباحًا من كل يوم: 3 1 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \; وبإتمام الخطوات السابقة نكون قد ضمنّا حلًا مناسبًا للنسخ الاحتياطي لقواعد بيانات MongoDB. استعادة نسخة احتياطية لقاعدة بيانات MongoDB إن استعادة نسخة احتياطية سابقة لقاعدة بيانات MongoDB (كالتي حصلنا عليها من الخطوة السابقة) تتم باستخدام الأمر mongorestore والذي يمكّنك من الحصول على نسخة مطابقة تمامًا لبيانات القاعدة كما كانت في لحظة إنشاء النسخة الاحتياطية، متضمنًا ذلك جميع الفهارس وأنماط البيانات، وهذه مسألة مفيدة جدًا إن رغبت بنقل قاعدة البيانات. ومتابعة من المثال السابق، لنرى كيف من الممكن استعادة نسخة احتياطية سابقة. سنقوم باستخدام المُعامل db-- مع الأمر mongorestore لتحديد القاعدة التي نرغب باستعادة النسخة الاحتياطية إليها، كما سنستخدم المُعامل drop-- كي نضمن أن يتم حذف القاعدة القديمة حتى تتم استعادة النسخة الاحتياطية إلى نسخة جديدة من القاعدة لا تحتوي أي مشاكل، وأخيرًا سنقوم بتحديد مسار النسخة الاحتياطية التي نرغب باستعادتها; سيظهر الأمر كاملًا على النحو التالي (لا تنس استبدال المسار بمسار النسخة الموجودة لديك والتي ترغب باستعادتها): $ sudo mongorestore --db newdb --drop /var/backups/mongobackups/01-20-16/newdb/ وسيظهر ما يشبه الخرج التالي على الشاشة في حال تنفيذ الأمر بالشكل الصحيح: 2016-01-20T10:44:47.876-0500 building a list of collections to restore from /var/backups/mongobackups/01-20-16/newdb/ dir 2016-01-20T10:44:47.908-0500 reading metadata file from /var/backups/mongobackups/01-20-16/newdb/restaurants.metadata.json 2016-01-20T10:44:47.909-0500 restoring newdb.restaurants from file /var/backups/mongobackups/01-20-16/newdb/restaurants.bson 2016-01-20T10:44:48.591-0500 restoring indexes for collection newdb.restaurants from metadata 2016-01-20T10:44:48.592-0500 finished restoring newdb.restaurants (25359 documents) 2016-01-20T10:44:48.592-0500 done وفي هذه الحالة نكون قد أنجزنا استعادة نسخة احتياطية للقاعدة على الخادوم ذاته. أمّا لو رغبنا بنقل البيانات من خادوم لآخر باستخدام نفس الطريقة، فكُل ما نحتاجه هو نسخ مجلد النسخة الاحتياطية /var/backups/mongobackups/01-20-16/newdb/ إلى الخادوم الجديد قبل تنفيذ أمر استعادة النسخة الاحتياطية على الخادوم الجديد. الخلاصة تعرّفنا في المقال على أساسيات إدارة بيانات قاعدة MongoDB فيما يخص النسخ الاحتياطي والاستعادة من نسخة احتياطية سابقة، ونقل قاعدة البيانات من خادوم لآخر. إن آلية النسخ المُتماثل للبيانات ليست مهمّة بغرض قابلية التوسعة فحسب، وإنما مهمّة للموضوع الذي نتحدث عنه الآن، حيث تسمح الآلية باستمرارية تشغيل خدمة MongoDB دون توقّف أو انقطاع من خلال خادوم MongoDB ثانوي بينما يتم استعادة نسخة احتياطية على الخادوم الرئيسي في حال حدوث خلل ما فيه. وتعتبر سجلّات التشغيل (operations log (oplog جزءًا من آلية النسخة المُتماثل، حيث تقوم هذه السجلّات بتخزين جميع العمليات التي قامت بتغيير البيانات، ومن الممكن استخدام هذا السجل -كما يستخدم السجل الثنائي binary log في MySQL- بغرض استعادة البيانات بعد آخر نسخة احتياطية. تذكّر بأن النسخ الاحتياطي عادة يتم في فترة متأخرة من الليل، فإن قررت استعادة نسخة احتياطية ليلًا (قبل أن تبدأ عملية النسخ الاحتياطي) فستفقد جميع البيانات الجديدة التي لم يتم الحصول على نسخة احتياطية لها أولًا. ترجمة -وبتصرّف- للمقال How To Back Up, Restore, and Migrate a MongoDB Database on Ubuntu 14.04 لصاحبه Anatoliy Dimitrov.

تحدثنا في السابق عن بضع خطوات يمكنك تطبيقها لزيادة أمان وحماية موقعك العامل بسكربت ووردبريس الشهير. صحيحٌ أنّ نواة ووردبريس آمنة للغاية، ولكن يجب عليك تثبيت عدّة إضافات وملحقات إضافية لزيادة مستوى أمان موقعك. سنتحدّث في هذا الدرس عن أهم إضافات الأمان والنسخ الاحتياطي التي يمكنك تثبيتها وتفعيلها على سكربت ووردبريس الشهير. لماذا قد أحتاج إضافة للحماية؟بشكلٍ عام، تقوم إضافات الحماية والأمان بتوفير طبقة إضافية من الحماية ضدّ هجمات Bruteforce والهجمات الأخرى والبرمجيات الخبيثة التي قد تصيب موقعك، يمكنها أيضًا أن توفّر لك عدّة أدوات يمكنك استخدامها لتقليل المخاطر الأمنية المحيطة بك، كما توفّر بعض الأدوات للمراجعات اليدوية الدورية أيضًا. هناك إضافات أخرى للنسخ الاحتياطي تمكّنك من استرجاع موقعك بسرعة في حال ما إذا تمّ اختراقه. لهذا، سنتطرّق الآن إلى أهم الإضافات للحماية والأمان والنسخ الاحتياطي التي يمكنك استخدامها. iThemes Security تعتبر هذه الإضافة شهيرةً جدًا عندما يتعلّق الأمر بمجال أمان ووردبريس. كانت هذه الإضافة تدعى بالسابق "WP Security" ولكن تمّ تغيير اسمها. توفّر لك هذه الإضافة عدّة طرق لحماية موقعك. في الواقع، تقوم إضافة iThemes Security بالعديد من الأمور التي ذكرناها بالدروس السابقة تلقائيًا، مثل تغيير اسم المستخدم الرئيسي ورابط صفحة تسجيل الدخول، إزالة وسم generator والمزيد. كما تعرض عدّة أدوات للحماية مثل فحوصاتٍ دورية لملفّات موقعك للبحث عن الثغرات الأمنية والملفّات الخبيثة إن وجدت، مما يحسّن من أمان موقعك، كما أنّها تقوم بحظر المستخدمين الذين يفشلون بتسجيل الدخول لأكثر من مرّة عن طريق الـIP، وتحظر ربوتات الاختراق الشهيرة، وتفرض على المستخدمين اختيار كلمات مرورٍ قويّة.. والمزيد. توفّر إضافة iThemes Security ميزات التنبيه، حيث يمكنها أن تقوم بتنبيهك عندما يتم إجراء تغييراتٍ ما دون صلاحيات. يمكنها أن تلتقط الروبوتات التي تحاول اختراقك ويمكنها أن ترسل رسالة بريدٍ إلكتروني في حال التقطت أيًّا منها. توفّر الإضافة ميّزة النسخ الاحتياطي كذلك، حيث أنّها قادرة على أخذ نسخة احتياطية من جميع ملفّات موقعك وتدويناتك التي نشرتها، ويمكنها استعادتها في أيّ وقتٍ تريده. هناك إصدارٌ مدفوع من الإضافة كذلك ويوفّر ميّزاتٍ أكثر. All in One WP Security & Firewall خيارٌ آخر متوفّر أمامك هو إضافة All in One WP Security & Firewall، تتميز هذه الإضافة بسهولة تثبيتها وإعدادها مما يجعلها خيارًا جيَدًا للمدونين الجدد. تتضمن أيضًا نظام تقييم للحماية يحدد لك مدى أمان موقعك بوضعه الحالي. يمكنك من هناك تفعيل أو تعطيل مميزاتٍ معيّنة للأمان والحماية في موقعك حسبما تريده. تسمح لك هذه الإضافة المجانية كذلك بإعداد العديد من إجراءات الحماية بمجرّد بضع ضغطات، مثل تغيير اسم المستخدم "admin"، التعرّف على المستخدمين الذين يمتلكون أكثر من حساب وتفعيل أداة تقوية كلمات المرور. كما تحتوي الإضافة على ميزة تمنع هجمات Bruteforce على موقعك عبر حظر محاولات تسجيل الدخول الفاشلة لأكثر من مرّة. يمكنك أيضًا فرض تسجيل الخروج على حسابٍ معيّن، تتبع سجل النشاط الخاصّ به والمزيد. تتضمن الإضافة أيضًا مزايا حماية قواعد البيانات والملفّات، بالإضافة إلى إمكانية إنشاء ملفّ htaccess. عبرها وعمل النسخ الاحتياطية لملفّ wp-config.php. هناك ميزة أخرى مهمّة بهذه الإضافة وهي ميّزة الجدار الناري، حيث تسمح لك بتعديل ملفّ htaccess. لتمنع المخترقين حتّى من الوصول إلى الشفرة الخاصّة بموقعك. كما أنّها تحتوي على فاحص ملفّات، الحماية من نسخ النصوص، حماية ضد هجمات السخام (Spam)، تحديثات تلقائية والمزيد. Sucuri Security Sucuri Security هي إضافة أخرى شائعة لحماية ووردبريس. تسمح لك ميزة SiteCheck المُضمّنة بالتحقق من حالة موقعك الحالية وفحصه لإيجاد الثغرات الموجودة به بالإضافة للبحث عن البرمجيات الخبيثة إن وجدت. تمكّنك الميزة كذلك من البحث عن جميع أنواع الثغرات، مثل ثغرات حقن قواعد البيانات، محاولات التصيّد الاحتيالي، إعادة التوجيه المشبوهة.. إلخ، كما يمكنها أن تلتقط أكواد جافاسكربت وPHP الخبيثة إن وجدت. تستخدم الإضافة أكثر من واجهة تطبيق برمجية واحدة (API) لفحص موقعك، أيّ أنّها تستخدم أكثر من قاعدة بيانات للشفرات الضارّة والخبيثة الموجودة على الإنترنت للتأكد من أنّ موقعك لا يحتوي على أحدها، مما يوفّر فحصًا شاملًا لموقعك، تتضمن هذه المصادر الخارجية أسماءً عريقة مثل Norton, McAfee.. إلخ. هناك بعض المزايا الموجودة بالإضافة والتي توفّر الحماية لمسار رفع ملفّات الوسائط الخاصّ بموقعك، حيث تقيّد الوصول إلى مجلّديّ wp-content وwp-includes، تتحقق من إصدارات PHP ووردبريس وتعطّل محرر الإضافات والقوالب من لوحة التحكم. Wordfence Security تحدّثنا من قبل عن إضافة Wordfence Security، وقلنا أنّها من أهم إضافات الحماية لسكربت ووردبريس. بمجرّد تثبيتها على موقعك فإنّها ستقوم بعملية فحصٍ شامل للشفرة المصدرية للتأكّد من أنّها مطابقة للشفرة المصدرية الخامّة المنشورة من موقع ووردبريس الرئيسي، إذا اكتمل الفحص بنجاح، فإنّ الإضافة تقوم بعدها تلقائيا بتفعيل خيارات الحماية لزيادة أمان موقعك. هناك إصدار مدفوع ومجاني من الإضافة، كلاهما يعتمدان على منصّة "Wordfence Cloud"، مما يعني أنّ عملية الفحص وتفعيل الجدار الناري بالواقع تجريان على خواديم الشركة المطوّرة للاستضافة وليس على خادومك مما يقلل من الحمل الموجود عليه. توفّر هذه الإضافة دعمًا لأكثر من موقع ووردبريس في آنٍ واحد، تسجيل الدخول عبر الهاتف المحمول، دعم للإضافات الشهيرة مثل WooCommerce، الاستيثاق الثنائي، فرض كلمات المرور القوية، فحص الملفّات والمزيد. تتضمن الإضافة أيضًا جدارًا ناريًا لحماية موقعك من الروبوتات، البرمجيات الخبيثة وهجمات Bruteforce. بمجرّد تثبيتها فإنك ستكون قادرًا على حظر المهاجمين واتصالات الشبكات المشبوهة، وكلّه في الوقت الحقيقي (Real time). BruteProtect تمّ شراؤها مؤخرًا من قبل شركة Automattic (الشركة المطوّرة لووردبريس)، إضافة BruteProtect هي أحد الحلول الأمنية التي يمكنك استخدامها لصدّ هجمات Bruteforce بالتحديد. توفّر الإضافة أدواتٍ لمراقبة الهجمات الحالية على موقعك في حال حصولها بالوقت الحقيقي بالإضافة إلى التحديث التلقائي لنواة ووردبريس في موقعك. الإضافة ليست مجهّزة لحمايتك ضد الهجمات الأخرى، بل فقط ضدّ هجمات Bruteforce فلا تعتمد عليها لوحدها. Acunetix WP Security Acunetix WP Security هي إضافةٌ أخرى مجانية لفحص موقعك بسهولةٍ ويسر. تمكّنك من إعداد صلاحيات الملفّات، تأمين قاعدة البيانات، إخفاء إصدار ووردبريس الحالي الذي تستخدمه عن أعين المخترقين، تغيير اسم المستخدم admin والمزيد. تتوافق الإضافة مع مواقع ووردبريس المتعددة (multisite) وعمليات النسخ الاحتياطي، كما تتضمّن أداةً تعمل بالوقت الحقيقي لعرض من يتصفّح موقعك حاليًا وماذا يتصفّحون. Bulletproof Security آخر إضافة ووردبريس سنتحدث عنها هي إضافة Bulletproof Security. توفّر هذه الإضافة العديد من المزايا التي توفّرها الإضافات الأخرى مثل ملفّات htaccess. ، حفظ نسخة احتياطية من قاعدة البيانات، سمات مختلفة لواجهة الإضافة والمزيد. يتضمّن الإصدار المدفوع منها المزيد من المميزات مثل التثبيت بنقرة واحدة، الاستعادة التلقائية، جدار ناري يتعامل مع عناوين الـIP للمستخدمين، مسجّل للأخطاء، حامٍ من هجمات Bruteforce، حظر عناوين IP معيّنة والمزيد. أهمّية إضافات النسخ الاحتياطيبجانب إضافة قويّة للحماية والأمان، فإنّه يجب عليك استخدام إضافةٍ أخرى لعمليات النسخ الاحتياطي، معظم هذه الإضافات السابق ذكرها يتضمّن الميّزتين بالواقع مما يسهّل عليك الأمر، ولكن لا تنسى بتاتًا استخدام النسخ الاحتياطي. القيام دوريًا بعمل نُسخ احتياطية من موقعك هو أمرٌ مهم لخطّة أمان كاملة، وإلّا فكيف تتوقع أن تقوم باسترجاع موقعك في حال تمّ اختراقه مثلًا؟ هناك العديد من الإضافات الجيّدة للنسخ الاحتياطي مثل VaultPress ،WordPress Backup to Dropbox و BackupBuddy. تتنوّع هذه الإضافات ما بين المدفوعة والمجانية، ولكنّها مفيدة لضمان عدم فقدان أيّ شيء مهم يتعلّق بموقعك. الخاتمةصحيحٌ أنّه يمكنك القيام بالعديد من الأمور يدويًا لتحسين حماية ووردبريس، ولكن استخدام الإضافات قد يوفّر عليك الكثير من الوقت ويوفّر لك الكثير من المميزات، خاصةً لو كنتَ تمتلك أكثر من موقع ووردبريس واحد. الإضافات السابق ذكرها يجب أن تؤدّي المهمّة المطلوبة بالنسبة لك ويمكنك تجريبها جميعًا لتصل إلى أفضلٍ واحدةٍ منها بالنسبة لك. في الدرس الأخير من هذه السلسلة سنتحدث عن أهمية تحديث ووردبريس وإضافاته لزيادة أمان موقعك. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Security & Backup Plugins لصاحبته Brenda Barron.

إن Bacula هو برنامج للنسخ الاحتياطي يسمح لك بالنسخ والاستعادة والتحقق من البيانات عبر الشبكة؛ هنالك عملاء Bacula للينُكس وويندوز وماك OS X؛ مما يجعله حلًّا متعدد المنصات للنسخ الاحتياطي. لمحة يتألف Bacula من عدِّة مكونات وخدمات تُستخدَم لإدارة أيّة ملفات لتُنسَخ وأماكن النسخ: Bacula Director: خدمة تتحكم بجميع عمليات النسخ الاحتياطي والاستعادة والتحقق والأرشفة. Bacula Console: برنامج يسمح بالتواصل مع Director؛ هنالك ثلاثة إصدارات من Console: نسخة نصية تعتمد على سطر الأوامر. واجهة رسومية متناغمة مع غنوم وتَستخدم GTK+‎. واجهة رسومية تعتمد على wxWidgets. Bacula File: ويُعرَف أيضًا بعميل Bacula؛ يُثبَّت هذا التطبيق على الأجهزة التي ستُنسَخ احتياطيًا، وهو مسؤول عن البيانات التي تُطلَب من Director. Bacula Storage: التطبيق الذي يجري عملية تخزين واستعادة البيانات من وإلى الوسائط التخزينية. Bacula Catalog: مسؤول عن صيانة فهارس الملفات وقواعد بيانات الحجوم لجميع الملفات التي نُسِخَت احتياطيًا، مما يُمكِّن تحديد المكان والاستعادة السريعة للملفات المؤرشفة؛ يدعم Catalog ثلاثة محركات قواعد بيانات مختلفة هي MySQL و PostgreSQL و SQLite. Bacula Monitor: يسمح بمراقبة عمل Director، وعفاريت الملفات والتخزين؛ يتوفر Monitor حاليًا كتطبيق GTK+‎ فقط. يمكن أن تُشغَّل هذه الخدمات والتطبيقات في عدِّة خواديم وعملاء، أو يمكن تثبيتها على جهاز واحد إذا كانت ستأخذ نسخةً احتياطيةً لقرص واحد فقط. التثبيت ملاحظة: إذا كنت تستخدم MySQL أو PostgreSQL كقاعدة بيانات، فيجب أن تملك أولًا تلك الخدمات؛ إذ لن يثبتها Bacula. هنالك عدِّة حزم تحتوي على مختلف مكونات Bacula، أدخِل الأمر الآتي لتثبيت Bacula: sudo apt-get install bacula يَستخدم التثبيت الافتراضي لحزمة bacula قاعدة بيانات MySQL لتطبيق Catalog؛ إذا أردت استخدام SQLite أو PostgreSQL لتطبيق Catalog، فثبِّت الحزمة bacula-director-sqlite3 أو bacula-director-pgsql على التوالي وبالترتيب. ستُسأل أثناء التثبيت عن توفير تصاريح لمدير قاعدة البيانات ومالك قاعدة بيانات bacula؛ سيحتاج مدير قاعدة البيانات إلى امتلاك الأذونات الملائمة لإنشاء قاعدة بيانات؛ راجع درس قواعد البيانات لمزيدٍ من المعلومات. الضبط ملفات ضبط Bacula منسقة بناءً على «موارد» تشتمل على «تعليمات» محاطة بقوسين معقوفين «{}»؛ ولكل مكون من مكونات Bacula ملف منفصل في مجلد ‎/etc/bacula. يجب أن تُصرِّح مختلف مكونات Bacula عن نفسها لبعضها بعضًا؛ وهذا يتم باستخدام التعليمة password؛ على سبيل المثال، كلمة مرور مورد Storage في ملف ‎/etc/bacula/bacula-dir.conf يجب أن تُطابِق كلمة مرور Director في ‎/etc/bacula/bacula-sd.conf. افتراضيًا، تكون هنالك مهمة نسخ احتياطي اسمها Client1 لأرشفة Bacula Catalog؛ إذا كنت تخطط لاستخدام الخادوم للنسخ الاحتياطي لأكثر من عميل، فعليك تعديل اسم هذه المهمة إلى شيء أكثر وصفًا؛ لتغيير الاسم، عدِّل الملف ‎/eth]lc/bacula/bacula-dir.conf: # # Define the main nightly save backup job # By default, this job will back up to disk in Job { Name = "BackupServer" JobDefs = "DefaultJob" Write Bootstrap = "/var/lib/bacula/Client1.bsr" } ملاحظة: يغيّر المثال السابق اسم المهمة إلى BackupServer مما يطابق اسم المضيف للخادوم؛ استبدل الكلمة BackupServer باسم المضيف الملائم عندك، أو اسم أكثر وصفًا. يمكن استخدام Console لإنشاء طلبية لبرمجية Director عن المهام؛ لكن لكي تستخدم Console بمستخدم غير جذر، فيجب أن تضيف المستخدم لمجموعة bacula؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo adduser $username bacula ملاحظة: استبدل ‎$username باسم المستخدم الفعلي؛ وإذا أضفت المستخدم الحالي إلى المجموعة، فعليك تسجيل الخروج ثم إعادة تسجيل الدخول مرةً أخرى لتأخذ الأذونات الجديدة مفعولها. نسخة احتياطية محلية يشرح هذا القسم كيف تأخذ نسخة احتياطية لمجلدات محددة على مضيف واحد إلى شريط ممغنط محلي. أولًا، يجب ضبط جهاز Storage؛ وذلك بتعديل الملف ‎/etc/bacula/bacula-sd.conf وإضافة: Device { Name = "Tape Drive" Device Type = tape Media Type = DDS-4 Archive Device = /dev/st0 Hardware end of medium = No; AutomaticMount = yes; # when device opened, read it AlwaysOpen = Yes; RemovableMedia = yes; RandomAccess = no; Alert Command = "sh -c 'tapeinfo -f %c | grep TapeAlert'" } هذا المثال يستخدم شريطًا ممغنطًا من نوع DDS-4؛ عدِّل قيمة Media Type و Archive Device لتُطابِق عتادك. يمكنك أيضًا إزالة التعليق عن أحد الأمثلة في الملف. بعد تعديل ‎/etc/bacula/bacula-ds.conf، فيجب إعادة تشغيل عفريت Storage: sudo service bacula-sd restart أضف الآن مورد Storage إلى ملف ‎/etc/bacula/bacula-dir.conf لاستخدام الجهاز الجديد: # Definition of "Tape Drive" storage device Storage { Name = TapeDrive # Do not use "localhost" here Address = backupserver # N.B. Use a fully qualified name here SDPort = 9103 Password = "Cv70F6pf1t6pBopT4vQOnigDrR0v3LT3Cgkiyjc" Device = "Tape Drive" Media Type = tape } يجب أن تكون قيمة التعليمة Address هي الاسم الكامل للنطاق (FQDN) للخادوم؛ عدِّل backupserver إلى اسم المضيف الحقيقي. تأكد أيضًا أن التعليمة Password تُطابِق قيمة السلسلة النصية password في ‎/etc/bacula ‎/bacula-sd.conf. أنشِئ FileSet جديد، الذي سيُحدِّد المجلدات التي ستُأخذ نسخة احتياطية لها، وذلك بإضافة: # LocalhostBacup FileSet. FileSet { Name = "LocalhostFiles" Include { Options { signature = MD5 compression=GZIP } File = /etc File = /home } } سيُنسخ المجلدان ‎/etc و ‎/home احتياطيًا، تعليمات Options تضبط FileSet لإنشاء بصمة MD5 لكل ملف يُنسَخ احتياطيًا؛ ولضغط الملفات باستخدام gzip. الآن، أنشِئ Schedule (للجدولة) لمهمة النسخ: # LocalhostBackup Schedule -- Daily. Schedule { Name = "LocalhostDaily" Run = Full daily at 00:01 } ستعمل مهمة النسخ الاحتياطي كل يوم في تمام الساعة 00:01 أو 12:01‎ ‎AM؛ تتوفر العديد من خيارات الجدولة الإضافية. في النهاية، أنشِئ Job: # Localhost backup. Job { Name = "LocalhostBackup" JobDefs = "DefaultJob" Enabled = yes Level = Full FileSet = "LocalhostFiles" Schedule = "LocalhostDaily" Storage = TapeDrive Write Bootstrap = "/var/lib/bacula/LocalhostBackup.bsr" } مما سينسخ نسخةً كاملةً كل يوم إلى الشريط الممغنط. كل شريط ممغنط مستخدم يجب أن تكون له لافتة (Label)، إذا لم يكن للشريط الحالي لافتةٌ، فسيرسل Bacula بريدًا إلكترونيًا لجعلك تعلم بذلك؛ لضبط لافتة لشريط باستخدام Console، فعليك إدخال الأمر الآتي: bconsole وفي برنامج Bacula Console، أدخِل: label ثم ستُسأل عن مورد Storage: Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" The defined Storage resources are: 1: File 2: TapeDrive Select Storage resource (1-2):2 أدخِل اسم الحجم الجديد: Enter new Volume name: Sunday Defined Pools: 1: Default 2: Scratch استبدل Sunday باسمٍ ملائم. الآن اختر Pool: Select the Pool (1-2): 1 Connecting to Storage daemon TapeDrive at backupserver:9103 ... Sending label command for Volume "Sunday" Slot 0 ... تهانينا! لقد ضبطت Bacula لنسخ جهازك المحلي احتياطيًا إلى شريط ممغنط. مصادر لمزيد من المعلومات حول خيارات ضبط Bacula، راجع «Bacula User's Manual». تحتوي صفحة Bacula الرئيسية على آخر أخبار تطوير Bacula. أيضًا، راجع صفحة ويكي أوبنتو «Bacula». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Bacula.

هنالك عدِّة طرق لنسخ تثبيت أوبنتو احتياطيًا؛ أهم ما هنالك بالنسبة إلى النسخ الاحتياطية هو تطوير «خطة نسخ احتياطي» تحتوي على ماذا سيُنسَخ احتياطيًّا، وأين سيُنسَخ، وكيف سيُسترجَع. ستشرح الأقسام الآتية طرقًا مختلفة لإنجاز هذه المهام. سكربتات شل إحدى أبسط الطرق لنسخ نظام احتياطيًّا هي استخدام «سكربت شِل» (shell script)؛ على سبيل المثال، يمكن أن يُستخدَم سكربت لضبط أيّة مجلدات يجب أن تُنسَخ احتياطيًّا، وتُمرَّر هذه المجلدات كوسائط إلى الأداة tar، التي ستُنشِئ ملف أرشيف؛ ويمكن أن يُنقَل ذاك الملف أو ينُسَخ إلى مكانٍ آخر؛ ويمكن أن يُنشَأ أيضًا الأرشيف في نظام بعيد عبر NFS. الأداة tar تُنشِئ ملف أرشيف واحد من عدِّة ملفات أو مجلدات؛ يمكن أيضًا للأداة tar تمرير الملفات عبر أدوات ضغط، وهذا سيؤدي بدوره إلى تقليل حجم ملف الأرشيف. سكربت شِل بسيط السكربت الآتي يستخدم tar لإنشاء ملف أرشيف في نظام ملفات NFS موصول عن بعد؛ يُحدَّد اسم الأرشيف باستخدام أدوات إضافية تعمل من سطر الأوامر: #!/bin/bash #################################### # # Backup to NFS mount script. # #################################### # What to backup. backup_files="/home /var/spool/mail /etc /root /boot /opt" # Where to backup to. dest="/mnt/backup" # Create archive filename. day=$(date +%A) hostname=$(hostname -s) archive_file="$hostname-$day.tgz" # Print start status message. echo "Backing up $backup_files to $dest/$archive_file" date echo # Backup the files using tar. tar czf $dest/$archive_file $backup_files # Print end status message. echo echo "Backup finished" date # Long listing of files in $dest to check file sizes. ls -lh $dest ‎$backup_files: متغير يحتوي على قائمة بأيّة مجلدات تود أن تنسخها احتياطيًّا؛ يجب تعديل هذه القائمة لتناسب احتياجاتك. ‎$day: متغير يحتوي على اسم اليوم من الأسبوع (مثل Monday، أو Tuesday، أو Wednesday ...إلخ.)؛ وسيُستخدَم لإنشاء ملف أرشيف لكل يوم من الأسبوع، مما يعطي تاريخًا للنسخ الاحتياطي هو سبعة أيام؛ هنالك طرقٌ أخرى للقيام بذلك بما فيها استخدام الأداة date. ‎$hostname: متغير يحتوي على الاسم القصير للمضيف؛ استخدام اسم المضيف في اسم ملف الأرشيف يُمكِّنك من وضع ملفات الأرشيف اليومية من عدِّة خواديم في نفس المجلد. ‎$archive_file: الاسم الكامل لملف الأرشيف. ‎$dest: الوجهة التي سيُخزَّن فيها ملف الأرشيف؛ يجب أن يكون المجلد موجودًا وفي هذه الحالة موصولًا قبل تنفيذ أمر النسخ الاحتياطي؛ راجع درس «نظام ملفات الشبكة (NFS)» لمزيدٍ من التفاصيل حول استخدام NFS. status messages: الرسائل الاختيارية التي ستُطبَع إلى الطرفية باستخدام الأمر echo. tar czf $dest/$archive_file $backup_files: أمر tar المُستخدَم لإنشاء ملف الأرشيف. الخيار c: إنشاء أرشيف. الخيار z: تمرير الملف الناتج عبر الأداة gzip لضغط الأرشيف. الخيار f: الإخراج إلى ملف أرشيف؛ عدا ذلك، سيُرسِل الأمر tar مخرجاته إلى مجرى الخرج القياسي. ls -lh $dest: عبارة اختيارية تطبع قائمة تفصيلية (‎-l) بتنسيق سهل القراءة للبشر (‎-h) لمحتويات مجلد الهدف، هذا الأمر مفيدٌ للتحقق السريع من الحجم التخزيني لملف الأرشيف؛ هذا التحقق ليس بديلًا عن اختبار ملف الأرشيف نفسه! هذا مثالٌ بسيطٌ عن سكربت شِل للنسخ الاحتياطي؛ لكن هنالك العديد من الخيارات التي يمكن تضمينها في مثل هكذا سكربت، راجع قسم «مصادر» في هذا الدرس للحصول على روابط تُوفِّر معلومات تفصيلية عن كتابة سكربتات شِل. تنفيذ السكربت التنفيذ من الطرفية: أبسط طريقة لتنفيذ سكربت النسخ الاحتياطي السابق هي نسخ ولصق محتوياته في ملف باسم backup.sh على سبيل المثال، ثم تنفيذ ما يلي من الطرفية: sudo bash backup.sh هذه طريقة رائعة لاختبار أن كل شيء يعمل على ما يرام في السكربت. التنفيذ عبر المهام المجدولة (cron): يمكن استخدام الأداة cron ﻷتمتة تنفيذ السكربت، يسمح عفريت cron بتنفيذ السكربتات أو الأوامر في أوقات وتواريخ محددة مسبقًا. يُضبَط cron عبر قيود في ملف crontab؛ تنقسم ملفات crontab إلى حقول: # m h dom mon dow command الحقل m: الدقيقة التي سيُنفَّذ عندها الأمر؛ تتراوح القيمة بين 0 و 59. الحقل h: الساعة التي سيُنفَّذ عندها الأمر؛ تتراوح القيمة بين 0 و 23. الحقل dom: يوم الشهر الذي سينُفَّذ عنده السكربت. الحقل mon: الشهر الذي سيُنفَّذ عنده السكربت، بين 1 و 12. الحقل dow: يوم الأسبوع الذي سيُنفَّذ عنده الأمر، تتراوح قيمته بين 0 و 7؛ حيث يمكن تحديد يوم الأحد باستخدام 0 أو 7، حيث يجوز استخدام كلا القيمتين. الحقل command: الأمر الذي سيُنفَّذ. يجب استخدام الأمر crontab -e لإضافة أو تعديل المدخلات في ملف crontab؛ أيضًا يجب عرض محتويات الملف crontab باستخدام الأمر crontab -l. أدخِل الأمر الآتي في الطرفية لتنفيذ سكربت backup.sh السابق باستخدام cron: sudo crontab -e ملاحظة: استخدام sudo مع الأمر crontab -e سيُعدِّل جدول المهام للمستخدم الجذر؛ هذا ضروريٌ إذا كنت تنسخ مجلدات احتياطيًا لا يملك وصولًا إليها عدا المستخدم الجذر. أضف القيد الآتي إلى ملف crontab: # m h dom mon dow command 0 0 * * * bash /usr/local/bin/backup.sh يجب أن يُنفَّذ سكربت backup.sh كل يوم في تمام الساعة 12:00 AM. ملاحظة: يجب نسخ سكربت backup.sh إلى مجلد ‎/usr/local/bin لكي يعمل القيد السابق عملًا صحيحًا؛ يمكن أن يقبع السكربت في أي مكان في نظام الملفات، وكل ما عليك فعله هو تعديل المسار المذكور في القيد أعلاه بما يلائم مكان وجوده. الاستعادة من أرشيف بعد إنشاء الأرشيف، فمن المهم تجربته؛ يمكن أن يُجرَّب الأرشيف بعرض قائمة بالملفات التي يحتويها؛ لكن أفضل طريقة للاختبار هي استعادة ملف من الأرشيف. يمكنك تنفيذ الأمر الآتي لعرض قائمة بمحتويات الأرشيف: tar -tzvf /mnt/backup/host-Monday.tgz لاستعادة ملف من الأرشيف إلى مجلد مختلف، أدخِل الأمر: tar -xzvf /mnt/backup/host-Monday.tgz -C /tmp etc/hosts يوجه الخيار ‎-C الأمر tar ليستخرج الملفات إلى مجلد محدد؛ حيث سيستخرج الأمر السابق الملف ‎/etc/hosts إلى ‎/tmp/etc/hosts؛ يعيد tar إنشاء هيكلة المجلدات التي تحتوي الملفات. لاحظ أيضًا أن الشرطة المائلة / في أول المسار قد أزيلت من المسار المُستخرَج إليه. لاستعادة كل الملفات من الأرشيف، أدخِل الأمرين: cd / sudo tar -xzvf /mnt/backup/host-Monday.tgz ملاحظة: سيكتب الأمر السابق فوق الملفات في نظام الملفات. مصادر للمزيد من المعلومات حول كتابة سكربتات الشِل، راجع «Advanced Bash-Scription Guide». كتاب «Teach Yourself Shell Programming in 24 Hours» متوفر على الإنترنت، وهو مصدر ممتاز يشرح كتابة سكربتات الشِل. صفحة الويكي «CronHowto» تحتوي على تفاصيل عن خيارات cron المتقدمة. راجع دليل GNU tar للمزيد من خيارات tar. صفحة ويكيبيديا «Bachup Rotation Scheme» تحتوي على معلومات عن أنماط أخرى للنسخ الاحتياطي. يستخدم سكربت الشِل الأداةَ tar لإنشاء الأرشيف، لكن هنالك أدواتٌ سطريةٌ أخرى يمكن استعمالها، على سبيل المثال: cpio: يُستخدَم لنسخ الملفات إلى ومن الأرشيفات. dd: جزء من حزمة coreutils، الذي هو أداة منخفضة المستوى تستطيع نسخ البيانات من صيغة لأخرى. rsnapshot: أداة لأخذ snapshot لنظام الملفات تُستخدَم لإنشاء نسخ من كامل نظام الملفات. rsync: أداة مرنة تُستخدَم لإنشاء نسخ تراكمية من الملفات. وبالطبع، كتاب «سطر أوامر لينُكس» يحتوي على شرحٍ تفصيلي لأغلبية المواضيع التي ناقشناها هاهنا. دورة الأرشيف يسمح السكربت المشروح في القسم الأول من هذا الدرس بسبعة أرشيفات مختلفة فقط؛ ربما يكفي هذا لخادوم لا تتغير البيانات التي فيه كثيرًا؛ أما لو كان يملك الخادوم كميةً كبيرةً من البيانات، فيجب استخدام مخطط معقد للدورات. دورة أرشيفات NFS سنعدِّل في هذا القسم السكربت السابق لتطبيق مخطط الجد-الأب-الابن (شهريًا-أسبوعيًا-يوميًا): ستُنشَأ نسخ احتياطية يومية من الأحد إلى الجمعة. ستُأخذ نسخة احتياطية أسبوعية في يوم السبت مما يمنحك أربع نسخ احتياطية أسبوعية في الشهر. ستُأخذ نسخة احتياطية شهرية في أول كل شهر وتكون الدورة شهرين بناءً إذا ما كان رقم الشهر فرديًا أو زوجيًا. هذا هو السكربت: #!/bin/bash #################################### # # Backup to NFS mount script with # grandfather-father-son rotation. # #################################### # What to backup. backup_files="/home /var/spool/mail /etc /root /boot /opt" # Where to backup to. dest="/mnt/backup" # Setup variables for the archive filename. day=$(date +%A) hostname=$(hostname -s) # Find which week of the month 1-4 it is. day_num=$(date +%d) if (( $day_num <= 7 )); then week_file="$hostname-week1.tgz" elif (( $day_num > 7 && $day_num <= 14 )); then week_file="$hostname-week2.tgz" elif (( $day_num > 14 && $day_num <= 21 )); then week_file="$hostname-week3.tgz" elif (( $day_num > 21 && $day_num < 32 )); then week_file="$hostname-week4.tgz" fi # Find if the Month is odd or even. month_num=$(date +%m) month=$(expr $month_num % 2) if [ $month -eq 0 ]; then month_file="$hostname-month2.tgz" else month_file="$hostname-month1.tgz" fi # Create archive filename. if [ $day_num == 1 ]; then archive_file=$month_file elif [ $day != "Saturday" ]; then archive_file="$hostname-$day.tgz" else archive_file=$week_file fi # Print start status message. echo "Backing up $backup_files to $dest/$archive_file" date echo # Backup the files using tar. tar czf $dest/$archive_file $backup_files # Print end status message. echo echo "Backup finished" date # Long listing of files in $dest to check file sizes. ls -lh $dest/ يمكن تنفيذ هذا السكربت بنفس آلية التنفيذ في القسم السابق «تنفيذ السكربت». عادة جيدة هي أخذ وسائط تخزين النسخ الاحتياطية خارج مكان العمل تحسبًا لوقوع كارثة؛ في مثال سكربت الشِل؛ وسيط التخزين هو خادوم آخر يوفر مشاركة NFS؛ في مثل هذه الحالة، لن يكون خيارًا عمليًا نقل خادوم NFS إلى موقع آخر؛ لكن بناءً على سرعة الاتصال يمكنك نسخ ملف الأرشيف عبر خط WAN إلى خادوم في مكان آخر. خيار آخر هو نسخ ملف الأرشيف على قرص صلب خارجي يمكن أن يؤخذ بعد ذلك خارج الموقع؛ ولما كانت أسعار الأقراص الصلبة الخارجية تستمر بالانخفاض، فربما يكون ملائمًا استخدام قرصين صلبين لكل مستوى من مستويات الأرشفة؛ هذا سيسمح بوجود قرص صلب خارجي موصول إلى خادوم النسخ الاحتياطي، وآخر في مكانٍ بعيد. محركات الأشرطة الممغنطة يمكن استخدام شريط ممغنط (tape) بدلًا من مشاركة NFS، يُسهِّل استخدام الأشرطة الممغنطة دورات الأرشيفات؛ ويجعل أخذ وسائط التخزين خارج الموقع أمرًا هينًا. القسم الخاص باسم الملف في السكربت لن يكون ضروريًا عند استخدام الأشرطة، لأن البيانات تُرسَل مباشرةً إلى الشريط؛ هنالك حاجة لبعض الأوامر للتعديل على الأشرطة، يتم ذلك باستخدام الأداة mt، التي تُستخدَم للتحكم بالأشرطة الممغنطة وهي جزء من حزمة cpio. هذا هو سكربت الشِل المعدَّل لاستخدام شريط ممغنط: #!/bin/bash #################################### # # Backup to tape drive script. # #################################### # What to backup. backup_files="/home /var/spool/mail /etc /root /boot /opt" # Where to backup to. dest="/dev/st0" # Print start status message. echo "Backing up $backup_files to $dest" date echo # Make sure the tape is rewound. mt -f $dest rewind # Backup the files using tar. tar czf $dest $backup_files # Rewind and eject the tape. mt -f $dest rewoffl # Print end status message. echo echo "Backup finished" date ملاحظة: اسم الجهاز الافتراضي لشريط SCSI ممغنط هو ‎/dev/st0؛ استخدم مسار الجهاز الملائم لنظامك في السكربت السابق. الاستعادة من شريط ممغنط هي نفس عملية الاستعادة من ملف؛ ببساطة أعد لَفّ الشرط واستخدم مسار الجهاز بدلًا من مسار ملف؛ على سبيل المثال، لاستعادة ملف ‎/etc/hosts إلى ‎/tmp/etc/hosts: mt -f /dev/st0 rewind tar -xzf /dev/st0 -C /tmp etc/hosts ترجمة -وبتصرف- للمقالين Ubuntu Server Guide; Shell Scripts و Ubuntu Server Guide: Archive Rotation.

تعرفنا في المقالين السابقين على كيفية تثبيت وضبط خادوم OpenLDAP على أوبنتو و كيفية القيام بعملية التناسخ لتفادي توقف الخادوم. استيثاق LDAPبعد أن أصبح عندك خادوم LDAP يعمل جيدًا، فستحتاج إلى تثبيت مكتبات على جهاز العميل التي تعلم كيف ومتى عليها أن تتصل إلى الخادوم؛ يتم ذلك في أوبنتو تقليديًا بتثبيت حزمة libnss-ldap؛ ستجلب هذه الحزمة أدواتٍ أخرى، وستساعدك في خطوة الضبط؛ ثبت الآن الحزمة: sudo apt-get install libnss-ldapستُسأل عن معلوماتٍ حول خادوم LDAP؛ إذا ارتكبت خطأً هنا، فتستطيع المحاولة مرة أخرى بالأمر: sudo dpkg-reconfigure ldap-auth-configستظهر نتائج مربع الحوار السابق في ملف ‎/etc/ldap.conf، إذا تطلَّب الخادوم خياراتٍ غير موجودة في القائمة، فعليك تعديل هذا الملف وفقًا لها. اضبط LDAP لاستخدامه مع NSS: sudo auth-client-config -t nss -p lac_ldapاضبط النظام لاستخدام LDAP للاستيثاق: sudo pam-auth-updateاختر LDAP وأيّة آليات استيثاق أخرى قد تحتاج لها من القائمة. تستطيع الآن تسجيل الدخول بتصاريح مبنية على LDAP. سيحتاج عملاء LDAP إلى الإشارة إلى عدّة خواديم إذا اُستخدِم الاستنساخ؛ يجب أن تضع شيئًا شبيهًا بالسطر الآتي في ملف ‎/‎etc/ldap.conf: uri ldap://ldap01.example.com ldap://ldap02.example.comإذا نَفِذَت مهلة (timeout) الطلب، فسيحاول العميل الوصول إلى المستهلك (ldap02) إذا لم يستجيب المزود (ldap01). إذا كنت تريد استخدام LDAP لتخزين مستخدمي سامبا، فإن عليك ضبط سامبا ليستوثق عبر LDAP، وسنشرح ذلك في الدرس القادم. ملاحظة: بديل عن حزمة libnss-ldap هي حزمة libnss-ldapd؛ التي ستجلب معها حزمة nscd الذي قد لا نرغب فيها؛ احذفها ببساطة بعد التثبيت. إدارة المستخدمين والمجموعاتتأتي حزمة ldap-utils مع أدوات كافية لإدارة الدليل، لكن السلسلة الكبيرة من الإعدادات المطلوبة قد تصعِّب استخدامها؛ تحتوي حزمة ldapscripts على سكربتات متعلقة بهذه الأدوات التي يجدها بعض الأشخاص أسهل في الاستخدام. ثبِّت الحزمة: sudo apt-get install ldapscriptsثم عدِّل الملف ‎/etc/ldapscripts/ldapscripts.conf حتى يصبح شبيهًا بالآتي: SERVER=localhost BINDDN='cn=admin,dc=example,dc=com' BINDPWDFILE="/etc/ldapscripts/ldapscripts.passwd" SUFFIX='dc=example,dc=com' GSUFFIX='ou=Groups' USUFFIX='ou=People' MSUFFIX='ou=Computers' GIDSTART=10000 UIDSTART=10000 MIDSTART=10000أنشِئ الآن الملف ldapscripts.passwd لكي يستطيع rootDN الوصول إلى الدليل: sudo sh -c "echo -n 'secret' > /etc/ldapscripts/ldapscripts.passwd" sudo chmod 400 /etc/ldapscripts/ldapscripts.passwdملاحظة: ضع كلمة المرور الخاصة بمستخدم rootDN بدلًا من «secret». أصبحت السكربتات جاهزةً لإدارة دليلك؛ هذه بضعة أمثلة حول طريقة استخدامها: إنشاء مستخدم جديد: sudo ldapadduser george exampleهذا ما سيُنشِئ مستخدمًا بمعرِّف george ويضبط مجموعة المستخدم الرئيسية إلى example. تغيير كلمة مرور المستخدم: sudo ldapsetpasswd george Changing password for user uid=george,ou=People,dc=example,dc=com New Password: New Password (verify):حذف مستخدم: sudo ldapdeleteuser georgeإضافة مجموعة: sudo ldapaddgroup qaحذف مجموعة: sudo ldapdeletegroup qaإضافة مستخدم إلى مجموعة: sudo ldapaddusertogroup george qaعليك أن ترى الآن خاصية memberUid لمجموعة qa ذات القيمة george. إزالة مستخدم من مجموعة: sudo ldapdeleteuserfromgroup george qaيجب أن تزال الآن الخاصية memberUid من المجموعة qa. يسمح لك سكربت ldapmodifyuser بإضافة أو حذف أو استبدل خاصيات المستخدم؛ يستخدم هذا السكربت البنية العامة لأداة ldapmodify، على سبيل المثال: sudo ldapmodifyuser george # About to modify the following entry : dn: uid=george,ou=People,dc=example,dc=com objectClass: account objectClass: posixAccount cn: george uid: george uidNumber: 1001 gidNumber: 1001 homeDirectory: /home/george loginShell: /bin/bash gecos: george description: User account userPassword:: e1NTSEF9eXFsTFcyWlhwWkF1eGUybVdFWHZKRzJVMjFTSG9vcHk= # Enter your modifications here, end with CTRL-D. dn: uid=george,ou=People,dc=example,dc=com replace: gecos gecos: George Carlinيجب أن يصبح الآن المستخدم gecos باسم «George Carlin». ميزة جميلة من ميزات ldapscripts هو نظام القوالب؛ تسمح لك القوالب بتخصيص خاصيات المستخدم، والمجموعة، وكائنات الجهاز؛ فعلى سبيل المثال، لتفعيل قالب user، عدِّل الملف ‎/etc/ldapscripts/ldapscripts.conf مغيّرًا: UTEMPLATE="/etc/ldapscripts/ldapadduser.template"هنالك عينات عن القوالب في مجلد ‎/etc/ldapscripts، انسخ أو أعد تسمية ملف ldapadduser.template.sample إلى ‎/etc/ldapscripts/ldapadduser.template: sudo cp /usr/share/doc/ldapscripts/examples/ldapadduser.template.sample \ /etc/ldapscripts/ldapadduser.templateعدِّل القالب الجديد ليضيف الخاصيات التي تريدها؛ سيُنشِئ ما يلي مستخدمين جدد بقيمة inetOrgPerson للخاصية objectClass: dn: uid=<user>,<usuffix>,<suffix> objectClass: inetOrgPerson objectClass: posixAccount cn: <user> sn: <ask> uid: <user> uidNumber: <uid> gidNumber: <gid> homeDirectory: <home> loginShell: <shell> gecos: <user> description: User account title: Employeeلاحظ القيمة <ask> المُستخدَمة للخاصية sn؛ وهي ما سيجعل ldapadduser يسألك عن قيمتها. هنالك أدوات في هذه الحزمة لم نشرحها هنا، هذه هي قائمةٌ كاملةٌ بها: ldaprenamemachine ldapadduser ldapdeleteuserfromgroup ldapfinger ldapid ldapgid ldapmodifyuser ldaprenameuser lsldap ldapaddusertogroup ldapsetpasswd ldapinit ldapaddgroup ldapdeletegroup ldapmodifygroup ldapdeletemachine ldaprenamegroup ldapaddmachine ldapmodifymachine ldapsetprimarygroup ldapdeleteuserالنسخ الاحتياطي والاسترجاعالآن يجب أن يعمل LDAP كما نريده تمامًا، فحان الآن الوقت للتحقق من أن عملنا يمكن أن يُستَرجَع وقت الحاجة. كل ما نحتاج هو طريقة لنسخ قاعدة بيانات ldap احتياطيًا، وخصوصًا السند الخلفي (backend التي هي cn=config) والواجهة الأمامية (frontend التي هي dc=example,dc=com)؛ إذا كنت ستنسخ هذه القواعد نسخًا احتياطيًا إلى- ولِنَقُل- ‎/export/backup، فإننا سنستخدم slapcat كما هو موضَّح في السكربت الآتي المدعو ‎/usr/local/bin/ldapbackup: #!/bin/bash BACKUP_PATH=/export/backup SLAPCAT=/usr/sbin/slapcat nice ${SLAPCAT} -n 0 > ${BACKUP_PATH}/config.ldif nice ${SLAPCAT} -n 1 > ${BACKUP_PATH}/example.com.ldif nice ${SLAPCAT} -n 2 > ${BACKUP_PATH}/access.ldif chmod 640 ${BACKUP_PATH}/*.ldifملاحظة: هذه الملفات هي ملفات نصية غير مضغوطة تحتوي كل شيء في قواعد بيانات LDAP بما فيها مخطط الشجرة، وأسماء المستخدمين، وكل كلمات المرور؛ لذلك ربما تفكر في جعل ‎/export/backup قسمًا مشفرًا؛ وحتى كتابة سكربت يشفر هذه الملفات عند إنشائها، وربما تفعل كلا الأمرين، ولكن ذلك متعلقٌ بمتطلبات الأمن في نظامك. كل ما يلزم الآن هو الحصول على سكربت مهام مجدولة (cron) لتشغيل هذا البرنامج كل فترة زمنية (ترى أنها مناسبة)؛ سيكون ملائمًا للكثيرين جدولة تنفيذ البرنامج مرة واحدة كل يوم؛ لكن قد يحتاج الآخرون إلى مراتٍ أكثر في اليوم؛ هذا مثال عن سكربت cron مدعو ‎/etc/cron.d/ldapbackup، والذي سيعمل كل ليلة في تمام الساعة 22:45: MAILTO=backup-emails@domain.com 45 22 * * * root /usr/local/bin/ldapbackupوبعد إنشاء الملفات، يجب نقلها لخادوم النسخ الاحتياطي. وعلى فرض أنك أعدت تثبيت ldap، فإن عملية الاسترجاع ستكون شبيهةً بما يلي: sudo service slapd stop sudo mkdir /var/lib/ldap/accesslog sudo slapadd -F /etc/ldap/slapd.d -n 0 -l /export/backup/config.ldif sudo slapadd -F /etc/ldap/slapd.d -n 1 -l /export/backup/domain.com.ldif sudo slapadd -F /etc/ldap/slapd.d -n 2 -l /export/backup/access.ldif sudo chown -R openldap:openldap /etc/ldap/slapd.d/ sudo chown -R openldap:openldap /var/lib/ldap/ sudo service slapd startمصادرالمصدر الأساسي هو توثيق www.openldap.org.هنالك الكثير من صفحات الدليل للحزمة slapd؛ هذه أهمها آخذين بعين الاعتبار المعلومات المقدمة في هذا الفصل:man slapd man slapd-config man slapd.access man slapo-syncprovصفحات الدليل الأخرى: man auth-client-config man pam-auth-updateصفحة ويكي مجتمع أوبنتو «OpenLDAP» تحتوي مجموعةً من الملاحظات.كتاب O'Reilly المدعو «LDAP System Administration».كتاب Packt المدعو «Mastering OpenLDAP».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenLDAP Server.

إنّ Bacula-web هو عبارة عن تطبيق ويب مكتوب بلغة PHP يُزوِّدنا بطريقة سهلة لعرض ملخصات ومخططات بيانية لوظائف النسخ الاحتياطي backup jobs التي تم تشغيلها مسبقًا، وبالرغم من أنّه لا يسمح لنا بالتحكم بـ Bacula بأي طريقة فهو يُزوِّدنا بواجهة رسوميّة بديلة لطريقة عرض الوظائف من الـ console، إنّ Bacula-web مفيد خاصّة للمستخدمين الجديدين على Bacula، حيث تُسهِّل علينا تقاريره فهم آلية عمل Bacula. سنشرح في هذا الدّرس كيفيّة تثبيت Bacula-web على خادوم Ubuntu الذي تعمل عليه برمجيّة خادوم Bacula. المتطلبات الأساسيةيجب أن تمتلك من أجل متابعة الدّرس برمجيّة خادوم Bacula للنسخ الاحتياطي مُثبَّتة على خادوم Ubuntu لديك، تستطيع إيجاد تعليمات تثبيت Bacula هنا: كيفيّة تثبيت خادوم Bacula على Ubuntu. يفترض هذا الدّرس أنّ خادوم Bacula لديك يستخدم قاعدة بيانات MySQL، إن كنت تستخدم قاعدة بيانات أخرى مثل PostgreSQL فتأكّد من أن تقوم بالضبط المناسب من أجل هذا الدّرس، ستحتاج إلى تثبيت وحدة PHP مناسبة والقيام بضبط أمثلة معلومات اتصال قاعدة البيانات. فلنبدأ الآن. تثبيت Nginx و PHPإنّ Bacula-web هو عبارة عن تطبيق PHP لذا نحتاج لتثبيت PHP وخادوم ويب، سنستخدم Nginx، إن أردت تعلم المزيد حول إعداد هذه البرمجيّة فتحقّق من هذا الدّرس LEMP tutorial. نقوم بتحديث قوائم apt-get لدينا: sudo apt-get updateنُثبِّت بعدها Nginx، PHP-fpm، وبعض الحِزَم الأخرى باستخدام apt-get: sudo apt-get install nginx apache2-utils php5-fpm php5-mysql php5-gdنحن الآن جاهزون لإعداد PHP وNginx. إعداد PHP-FPMنفتح ملف إعدادات PHP-FPM باستخدام مُحرِّر النصوص الذي نفضّله، سنستخدم vi: sudo vi /etc/php5/fpm/php.iniنبحث عن السطر الذي يُحدِّد cgi.fix_pathinfo، نزيل التعليق عنه ونستبدل قيمته بـ 0، يجب أن يبدو كما يلي بعد أن ننتهي من ذلك: cgi.fix_pathinfo=0نبحث الآن عن الإعداد date.timezone، نزيل التعليق عنه ونستبدل قيمته بقيمة المنطقة الزمنية لدينا، سنضع New York على سبيل المثال: date.timezone = America/New_Yorkإن أردت الحصول على قائمة بكافّة المناطق الزمنية timezones فتحقّق من وثائق PHP. نحفظ الملف ونخرج منه. الآن وقد أصبح PHP-FPM مُعدًّا بشكل صحيح فلنقم بإعادة تشغيله لتطبيق التغييرات: sudo service php5-fpm restartإعداد Nginxحان الوقت الآن لإعداد Nginx ليُخدِّم تطبيقات PHP. في البداية نقوم بإنشاء ملف htpasswd لكي لا نسمح بالأشخاص غير المُصرَّح لهم بالنفاذ إلى Bacula-web، نستخدم الأمر htpasswd لإنشاء مستخدم مُدير admin، يُدعى "admin" (يجب أن تستخدم اسمًا آخر)، والذي يستطيع النفاذ إلى واجهة Bacula-web: sudo htpasswd -c /etc/nginx/htpasswd.users adminندخل كلمة السّر في المُحِث prompt، ونقوم بتحديد تذكر تسجيل الدخول هذا لأنّنا سنحتاجه للنفاذ إلى Bacula-web. نفتح الآن ملف إعدادات كتلة block الخادوم الافتراضيّة في Nginx من خلال مُحرِّر نصوص، سنستخدم vi: sudo vi /etc/nginx/sites-available/defaultنستبدل محتويات الملف بكتلة الشيفرة code التالية، احرص على تبديل القيمة server_name باسم نطاق خادومك أو عنوان IP الخاص به: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.php index.html index.htm; server_name server_domain_name_or_IP; auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/htpasswd.users; location / { try_files $uri $uri/ =404; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }نقوم بحفظ الملف والخروج منه، يقوم هذا بإعداد Nginx لتخديم تطبيقات PHP وليستخدم ملف htpasswd الذي أنشأناه سابقًا من أجل الاستيثاق authentication. ولتطبيق التغييرات نعيد تشغيل Nginx: sudo service nginx restartنحن الآن جاهزون لتنزيل Bacula-web. تنزيل وإعداد Bacula-webنقوم بالانتقال إلى الدليل الرئيسي home لدينا وتنزيل إصدار Bacula-web الأخير على شكل ملف أرشيف، الإصدار الأخير في وقت كتابة هذا الدّرس هو 7.0.3: cd ~ wget --content-disposition http://www.bacula-web.org/download.html?file=files/bacula-web.org/downloads/bacula-web-7.0.3.tgzنُنشِئ الآن دليلًا جديدًا اسمه bacula-web، وننتقل إليه، ثمّ نستخرج محتويات الأرشيف Bacula-web إليه: mkdir bacula-web cd bacula-web tar xvf ../bacula-web-*.tgzينبغي قبل نسخ الملفّات إلى جذر المستند document root لخادوم الويب لدينا أن نقوم بإعداده أولًا. نقوم بالانتقال إلى دليل الإعدادات كما يلي: cd application/configيُزوِّدنا Bacula-web بعيّنة sample من الإعدادات، ننسخها كما يلي: cp config.php.sample config.phpنقوم الآن بتحرير ملف الإعدادات ضمن مُحرِّر نصوص، سنستخدم vi: vi config.phpنبحث بداخله عن: MySQL bacula catalog //ونزيل التعليق عن تفاصيل الاتصال، نضع أيضًا كلمة سر قاعدة بيانات Bacula الخاصّة بنا بدلًا من القيمة password (والتي يُمكِن إيجادها في المسار etc/bacula/bacula-dir.conf/ ضمن الإعداد "dbpassword"): // MySQL bacula catalog $config[0]['label'] = 'Backup Server'; $config[0]['host'] = 'localhost'; $config[0]['login'] = 'bacula'; $config[0]['password'] = 'bacula-db-pass'; $config[0]['db_name'] = 'bacula'; $config[0]['db_type'] = 'mysql'; $config[0]['db_port'] = '3306';نحفظ الملف ونخرج منه. أصبح الآن Bacula-web مُعدًّا كما يجب، الخطوة الأخيرة هي وضع ملفّات التطبيق في المكان المناسب. نسخ تطبيق Bacula-web إلى جذر المستند Document Rootقمنا بإعداد Nginx ليستخدم usr/share/nginx/html/ كجذر المستند، ننتقل إلى هذا المسار ونحذف الملف index.html الافتراضي باستخدام الأوامر التالية: cd /usr/share/nginx/html sudo rm index.htmlننقل الآن ملفّات Bacula-web إلى الموقع الحالي، وهو جذر مستند Nginx: sudo mv ~/bacula-web/* .نقوم بتغيير ملكيّة الملفّات إلى www-data، وهو المستخدم العفريت (بالإنجليزية Daemon وهو برنامج يعمل في خلفيّة النظام) الذي يقوم بتشغيل Nginx: sudo chown -R www-data: *الآن تمّ تثبيت Bacula-web بشكل كامل. النفاذ إلى Bacula-web من خلال المتصفحأصبح الآن Bacula-web قابلًا للنفاذ على اسم نطاق خادومنا أو من خلال عنوان IP العام له. ربّما ترغب الآن أن تختبر أنّ كل شيء مُعَد بشكل صحيح، ولحسن الحظ يُزوّدنا Bacula-web بصفحة اختبار test، نستطيع الوصول إليها بفتح الرابط التالي في متصفّح الإنترنت (مع وضع عنوان خادومنا بدلًا من server_public_IP): http://server_public_IP/test.phpينبغي أن نرى الآن جدول يُظهِر الحالة لمختلف عناصر Bacula-web، ويجب أن تملك كافّة العناصر علامة صح خضراء بجانبها، ما عدا وحدات قواعد البيانات التي لا نريدها، على سبيل المثال نحن نستخدم هنا MySQL لذا لا نحتاج لوحدات قواعد البيانات الأخرى: إن سار كل شيء على ما يرام فنحن الآن جاهزون لاستخدام الصفحة الرئيسيّة dashboard، نستطيع الوصول إليها عن طريق النقر على النص "Bacula-web" الموجود في الأعلى والأيسر، أو عن طريق زيارة خادومنا من خلال متصفّح الإنترنت: http://server_public_IP/يجب أن تبدو مماثلة لما يلي: الخاتمةأصبحنا مستعدين الآن لاستخدام Bacula-web لمراقبة مُختلَف وظائف Bacula وحالاتها بسهولة. ترجمة -وبتصرّف- لـ How To Install Bacula-web on Ubuntu 14.04 لصاحبه Mitchell Anicas.

سنتعلّم في هذا الدّرس كيفيّة إعداد Bacula لإنشاء نُسَخ احتياطيّة backups لمُضيف Ubuntu عن بُعد remote وذلك عبر اتصال عن طريق الشبكة، يتضمّن هذا تثبيت وإعداد برمجيّة عميل Bacula على مُضيف عن بُعد remote host، والقيام ببعض الإضافات لإعدادات خادوم Bacula موجود حاليًّا (تمّت تغطية هذا الموضوع في فقرة المتطلبات الأساسيّة الآتي ذكرها). المتطلبات الأساسيةيفترض هذا الدّرس أنّك تمتلك خادوم تعمل عليه عناصر خادوم Bacula، كما هو موصوف في هذا الرّابط: كيف تثبت خادوم Bacula للنسخ الاحتياطي على Ubuntu 14.04. نفترض أيضًا أنّك تستخدم واجهات شبكة خاصّة للنسخ الاحتياطي للاتصالات بين الخادوم والعميل، سنقوم بالرجوع إلى FQDN الخاص للخواديم (حيث تُشير FQDNs إلى عناوين IP الخاصّة)، إن كنت تستخدم عناوين IP فضع معلومات الاتصال الخاصّة بك في الأماكن الملائمة. سنقوم في بقيّة هذا الدّرس بالإشارة إلى خادوم Bacula بـ "BaculaServer"، "Bacula Server"، أو "Backup Server"، سنشير إلى المُضيف عن بُعد والذي يتم النسخ الاحتياطي له بـ "ClientHost"، "Client Host"، أو "Client". فلنبدأ بالقيام ببعض التغييرات السريعة لإعدادات خادوم Bacula. تنظيم إعدادات مدير Bacula Director (الخادوم)نقوم على خادوم Bacula بتطبيق هذا القسم مرّة واحدة. ربما قد لاحظت عند إعداد خادوم Bacula أنّ ملفّات الإعدادات طويلة بشكل زائد، سنحاول تنظيم إعدادات مدير Bacula قليلًا بحيث يستخدم ملفّات منفصلة لإضافة الإعدادات الجديدة مثل الوظائف jobs، مجموعات الملفّات file sets، والأحواض pools. فلنقم بإنشاء دليل ليساعدنا على تنظيم ملفّات إعدادات Bacula: sudo mkdir /etc/bacula/conf.dنفتح بعدها ملف إعدادات مدير Bacula: sudo vi /etc/bacula/bacula-dir.confنضيف هذا السطر في نهاية الملف: @|"find /etc/bacula/conf.d -name '*.conf' -type f -exec echo @{} \;"نقوم بحفظ الملف والخروج منه، يُخبِر هذا السطر المدير أن يبحث في الدليل /etc/bacula/conf.d عن ملفّات إضافيّة للإعدادات ليقوم بإلحاقها، وهذا يعني أنّ أي ملف .conf تتم إضافته هنا سيتم تحميله كجزء من الإعدادات. إضافة حوض الملفات عن بعد RemoteFile Poolنريد إضافة حوض Pool إضافي لإعدادات مدير Bacula لدينا، وسنستخدمه لإعداد وظائف النسخ الاحتياطي عن بُعد. نفتح الملف conf.d/pools.conf: sudo vi /etc/bacula/conf.d/pools.confنضيف موارد الحوض Pool التالية: Pool { Name = RemoteFile Pool Type = Backup Label Format = Remote- Recycle = yes # Bacula can automatically recycle Volumes AutoPrune = yes # Prune expired volumes Volume Retention = 365 days # one year Maximum Volume Bytes = 50G # Limit Volume size to something reasonable Maximum Volumes = 100 # Limit number of Volumes in Pool }نقوم بحفظ الملف والخروج منه، يُعرِّف هذا حوض للملفّات عن بُعد "RemoteFile"، والذي سنستخدمه من قبل وظيفة النسخ الاحتياطي التي سنقوم بإنشائها لاحقًا، ولك الحريّة في تغيير أي مُعامِل بحيث يُلائم احتياجاتك. حتى الآن لا نحتاج إلى إعادة تشغيل مدير Bacula، ولكن فلنتحقّق أنّ إعداداته لا تحتوي على أيّة أخطاء فيها: sudo bacula-dir -tc /etc/bacula/bacula-dir.confإن لم تكن هنالك أيّة أخطاء فنحن جاهزون للمتابعة في إعداد عميل Bacula Client. تثبيت وإعداد عميل Baculaنقوم بتنفيذ هذا القسم على أي مُضيف عميل Client Host نريد إضافته إلى إعداد Bacula. في البداية نُحدِّث apt-get: sudo apt-get updateنثبّت بعدها الحزمة bacula-client: sudo apt-get install bacula-clientيقوم هذا بتثبيت عفريت (بالإنجليزية Daemon وهو برنامج يعمل في خلفيّة النظام) ملفّات Bacula FD أي (Bacula File Daemon)، والذي عادة تتم الإشارة إليه بعميل Bacula أي "Bacula client". إعداد العميلينبغي قبل إعداد عفريت ملفّات العميل File Daemon إيجاد المعلومات التالية، والتي سيتم استخدامها خلال هذا الدّرس: اسم مضيف العميل Client hostname: سيستخدم مثالنا "ClientHost".FQDN الخاص للعميل Client Private FQDN: سنشير له بـ "clientprivateFQDN"، وهو يبدو مُشابِهًا لـ clienthost.private.example.com.اسم مضيف خادوم Bacula أي Bacula Server hostname: سيستخدم مثالنا "BackupServer".ستختلف إعداداتك الفعلية عن هذه الأمثلة، لذا تأكّد من وضع معلوماتك في الأماكن المناسبة. نفتح إعدادات عفريت الملفّات File Daemon: sudo vi /etc/bacula/bacula-fd.confنحتاج لتغيير بعض العناصر وحفظ بعض المعلومات التي سنحتاجها لأجل إعدادات خادومنا. نبدأ بإيجاد مورد المدير Director resource المُسمّى على اسم مضيف العميل لدينا (على سبيل المثال "ClientHost-dir")، وبما أنّ مدير Bacula الذي نريد التحكّم من خلاله بالعميل متواجد على خادوم Bacula فلنقم بتغيير مُعامِل الاسم "Name" إلى اسم المضيف لخادوم النسخ الاحتياطي لدينا متبوعًا بـ "-dir"، في مثالنا وباستخدام "BackupServer" كاسم مضيف خادوم Bacula يجب أن يبدو هذا مُشابِهًا لما يلي: Director { Name = BackupServer-dir Password = "IrIK4BHRA2o5JUvw2C_YNmBX_70oqfaUi" }نحتاج أيضًا أن ننسخ المُعامِل Password ونحفظه من أجل العودة إليه لاحقًا، وهو عبارة عن كلمة السّر المُولَّدة تلقائيًّا والمستخدمة من أجل الاتصال إلى عفريت الملفّات File Daemon، سيتم استخدامها في إعدادات مدير خادوم النسخ الاحتياطي حيث سنقوم بتعيينها في خطوة قادمة من أجل الاتصال إلى عفريت الملفّات File Daemon الخاص بالعميل. نحتاج بعدها إلى ضبط معامل واحد في مورد عفريت الملفّات FileDaemon، حيث سنقوم بتغيير المُعامِل FDAddress ليُطابِق FQDN الخاص لأجهزة عملائنا، يجب أن يكون مُسبقًا قد تم إعداد المُعامِل Name بشكل صحيح مع اسم عفريت الملفّات file daemon للعميل، ينبغي أن يبدو المورد مشابهًا لما يلي (قم بوضع FQDN الفعلية أو عنوان IP لديك): FileDaemon { # this is me Name = ClientHost-fd FDport = 9102 # where we listen for the director WorkingDirectory = /var/lib/bacula Pid Directory = /var/run/bacula Maximum Concurrent Jobs = 20 FDAddress = client_private_FQDN }نحتاج أيضًا لضبط هذا العفريت daemon ليقوم بتمرير رسائل سجلّاته إلى خادوم النسخ الاحتياطي، نقوم بالبحث عن مورد الرسائل Messages وتغيير المُعامِل director ليطابق اسم مضيف خادوم النسخ الاحتياطي لدينا مع اللاحقة "-dir"، ينبغي أن يبدو مشابهًا لما يلي: Messages { Name = Standard director = BackupServer-dir = all, !skipped, !restored }نقوم بحفظ الملف والخروج منه، تم الآن إعداد عفريت الملفّات File Daemon (عميل Bacula) ليستمع للاتصالات عبر الشبكة الخاصّة. نتحقّق من أن ملف الإعدادات يمتلك الصياغة الصحيحة باستخدام الأمر التالي: sudo bacula-fd -tc /etc/bacula/bacula-fd.confإن لم يُعد الأمر أي خَرْج output فهذا يعني أنّ ملف الإعدادات يمتلك صياغة صحيحة، نعيد تشغيل عفريت الملفّات File Daemon ليستخدم الإعدادات الجديدة: sudo service bacula-fd restartفلنقم بإعداد دليل يستطيع خادوم Bacula استعادة الملفّات إليه، نقوم بإنشاء بنية الملفّات وحصر الصلاحيّات والملكيّة لأجل الأمان عن طريق الأوامر التالية: sudo mkdir -p /bacula/restore sudo chown -R bacula:bacula /bacula sudo chmod -R 700 /baculaتمّ الآن إعداد جهاز العميل بشكل صحيح، سنقوم بعدها بضبط خادوم النسخ الاحتياطي ليكون قادرًا على الاتصال إلى عميل Bacula. إضافة مجموعات الملفات FileSets (الخادوم)تُعرِّف Bacula FileSet مجموعة من الملفّات أو الأدلة التي يتم تضمينها أو استثناؤها من اختيار النسخ الاحتياطي، ويتم استخدامها من قبل وظائف النسخ الاحتياطي على خادوم Bacula. إن اتبعت الدّرس الموجود في المتطلّبات الأساسيّة والذي يقوم بإعداد عناصر خادوم Bacula فأنت تمتلك مسبقًا مجموعة ملفّات FileSet تُدعى "Full Set"، إن كنت تريد تشغيل وظائف نسخ احتياطي تتضمّن كل ملف على جهاز العميل لديك فتستطيع استخدام مجموعة الملفّات FileSet هذه في وظائفك، ومع ذلك ربّما تجد غالبًا أنّك لا تريد ولا تحتاج امتلاك نسخة احتياطية لكل شيء على الخادوم، وبهذا تكفيك مجموعة فرعيّة من البيانات. عندما تكون أكثر انتقائيّة في اختيار الملفّات التي تريد تضمينها في مجموعة الملفّات FileSet ستوفّر من مساحة القرص لديك وتوفّر من الوقت الذي يحتاجه خادوم النسخ الاحتياطي للقيام بوظيفة نسخ احتياطي، وستجعل عمليّة استعادة الملفّات أبسط حيث لن يتوجب عليك البحث في مجموعة كاملة "Full Set" لإيجاد الملفّات التي تريد استعادتها. سنشرح كيفيّة إنشاء موارد مجموعة ملفّات FileSet جديدة، بحيث تستطيع أن تكون أكثر انتقائية فيما تريد نسخه احتياطيًّا. على خادوم Bacula نفتح الملف الذي يُدعى filesets.conf الموجود في دليل إعدادات مدير Bacula الذي أنشأناه: sudo vi /etc/bacula/conf.d/filesets.confنقوم بإنشاء مورد مجموعة ملفّات FileSet لكل مجموعة محدّدة من الملفّات التي نريد استخدامها في وظائف النسخ الاحتياطي، سننشئ في هذا المثال مجموعة ملفّات FileSet تشمل فقط الدليل الرئيسي home والدليل etc: FileSet { Name = "Home and Etc" Include { Options { signature = MD5 compression = GZIP } File = /home File = /etc } Exclude { File = /home/bacula/not_important } }هنالك الكثير من الأشياء التي تحدث في هذا الملف ولكن هذه بعض التفاصيل التي يجب أن تبقى في ذهننا: يجب أن يكون اسم مجموعة الملفّات FileSet فريدًاتضمين أي ملفّات أو أقراص نريد الحصول على نسخ احتياطيّة لهااستثناء أي ملفّات لا نريد النسخ الاحتياطي لها ولكن تمّ اختيارها نتيجة وجودها بداخل ملفّات مُضمَّنةنستطيع إنشاء العديد من مجموعات الملفّات FileSets إن كنّا نرغب بذلك، نقوم بالحفظ والخروج بعد الانتهاء. نحن الآن مستعدون لإنشاء وظيفة نسخ احتياطي تستخدم مجموعة ملفّاتنا الجديدة. إضافة عميل Client ووظيفة نسخ احتياطي Backup Job إلى خادوم Baculaنحن الآن جاهزون لإضافة عميلنا إلى خادوم Bacula، ولعمل هذا يجب علينا إعداد مدير Bacula مع موارد العميل والوظيفة الجديدة. نفتح الملف conf.d/clients.conf: sudo vi /etc/bacula/conf.d/clients.conf1. إضافة مورد عميل Client Resourceيقوم مورد العميل بضبط المدير Director مع المعلومات التي يحتاجها للاتصال إلى مضيف العميل، يتضمّن هذا الاسم، العنوان، وكلمة السّر لعفريت ملفّات العميل Client File Daemon. نقوم بلصق التعريف التالي لمورد العميل إلى ذلك الملف، تأكد من أن تضع اسم مضيف العميل لديك، FQDN الخاص، وكلمة السّر (من ملف العميل bacula-fd.conf): Client { Name = ClientHost-fd Address = client_private_FQDN FDPort = 9102 Catalog = MyCatalog Password = "IrIK4BHRA2o5JUvw2C_YNmBX_70oqfaUi" # password for Remote FileDaemon File Retention = 30 days # 30 days Job Retention = 6 months # six months AutoPrune = yes # Prune expired Jobs/Files }نحتاج لعمل هذا مرّة واحدة فقط لكل عميل. 2. إنشاء وظيفة نسخ احتياطي backup jobتُعرِّف وظيفة النسخ الاحتياطي backup job تفاصيل حول العميل والبيانات التي يجب عمل نسخ احتياطي لها، ويجب أن يملك اسمًا فريدًا. نلصق وظيفة النسخ الاحتياطي التالية إلى الملف، مع وضع اسم مضيف العميل لدينا بدلًا من كلمة ClientHost: Job { Name = "BackupClientHost" JobDefs = "DefaultJob" Client = ClientHost-fd Pool = RemoteFile FileSet="Home and Etc" }يقوم هذا بإنشاء وظيفة نسخ احتياطي تُدعى "BackupClientHost" والتي تقوم بإنشاء نسخة احتياطيّة للدليلين home وetc من مضيف العميل، كما هو مُعرَّف في مجموعة الملفّات FileSet التي تُدعى "Home and Etc"، ستستخدم هذه الوظيفة الإعدادات المُحدّدة في تعريف الوظائف JobDefs الذي يُدعى "DefaultJob" وموارد الحوض Pool الذي يُدعى "RemoteFile"، وكلاهما مُعرَّف في الملف الرئيسي bacula-dir.conf، الوظائف التي تُحدِّد JobDefs = "DefaultJob" يتم تشغيلها أسبوعيًّا بشكل افتراضي. عند الانتهاء نحفظ الملف ونخرج منه. 3. التحقق من إعدادات المدير Directorفلنتحقّق من عدم وجود أخطاء صياغة في ملف إعدادات المدير لدينا: sudo bacula-dir -tc /etc/bacula/bacula-dir.confإن تمّت إعادتنا إلى مُحث الصدفة shell prompt فهذا يعني أنّه لا توجد أخطاء صياغة في ملفّات إعدادات مدير Bacula. 4. إعادة تشغيل مدير Baculaولتطبيق التغييرات التي قمنا بها نعيد تشغيل مدير Bacula: sudo service bacula-director restartيكون العميل أو المضيف عن بعد مُعدًّا الآن ليتم نسخه احتياطيًّا عن طريق خادوم Bacula. اختبار اتصال العميلينبغي أن نتحقّق من قدرة مدير Bacula على الاتصال بعميل Bacula. ندخل إلى Bacula Console على خادوم Bacula: sudo bconsole Select Client resource: ClientHost-fd The defined Client resources are: 1: BackupServer-fd 2: ClientHost-fd Select Client (File daemon) resource (1-2): 2ينبغي أن تعود إلينا حالة عفريت ملفّات العميل Client File Daemon، وإن لم يحدث ذلك ووجد خطأ بالاتصال فهنالك مشكلة ما في إعدادات خادوم Bacula أو عفريت ملفّات العميل Client File Daemon. اختبار وظيفة النسخ الاحتياطيفلنقم بتشغيل وظيفة النسخ الاحتياطي للتأكد من أنّها تعمل. نستخدم هذا الأمر على خادوم Bacula من خلال الـ Console: runسيتم حثّنا على اختيار الوظيفة التي نريد تشغيلها، نختار الوظيفة التي أنشأناها سابقًا (في مثالنا "4. BackupClientHost"): Select Job resource: BackupClientHost The defined Job resources are: 1: BackupLocalFiles 2: BackupCatalog 3: RestoreLocalFiles 4: BackupClientHost Select Job resource (1-4): 4وفي مُحث prompt التأكيد نختار "yes": Confirmation prompt: OK to run? (yes/mod/no): yesالتحقق من الرسائل والحالةسيخبرنا Bacula بعد تشغيل الوظيفة أنّنا نمتلك رسائل، وهي عبارة عن خَرْج تمّ توليده من قبل الوظائف قيد التشغيل. نتحقّق من الرسائل بكتابة: messagesينبغي أن تخبرنا الرسائل أنّه لم يتم إيجاد تسجيل لوظيفة نسخ احتياطي كامل سابقة "No prior Full backup Job record found" وأنّه بدأت وظيفة النسخ الاحتياطي لدينا، إن وُجِدَت أيّة أخطاء أخرى فهناك خطأ ما ويجب أن تعطيك هذه الأخطاء تلميحًا عن سبب عدم عمل الوظيفة. ومن الطرق الأخرى لرؤية حالة الوظيفة هي التحقّق من حالة المدير Director، ولعمل هذا نكتب الأمر التالي في bacula console: status directorإن كان كل شيء على ما يرام فينبغي أن نرى أنّ وظيفتنا قيد التشغيل أو تمّت مقاطعتها بحالة "OK". القيام باستعادة ملفات Restoreيجب أن نختبر في المرّة الأولى لإعداد عميل Bacula جديد أنّ استعادة الملفّات تعمل بشكل صحيح. إن أردنا القيام باستعادة ملفّات نستخدم الأمر restore في Bacula Console: restore allستظهر قائمة للاختيار مع العديد من الخيارات المختلفة، والتي تُستخدم لتحديد مجموعة النسخ الاحتياطي التي نريد الاستعادة منها، وبما أنّنا نملك نسخة احتياطيّة واحدة فقط سنختار الخيار 5 وهو اختيار أحدث نسخة احتياطيّة "Select the most recent backup": Select item (1-13): 5يجب بعدها أن نحدّد العميل الذي نريد الاستعادة إليه، نريد الاستعادة للمضيف عن بعد الذي قمنا بإعداده للتو، وهو في مثالنا "ClientHost-fd": Select the Client: ClientHost-fd Defined Clients: 1: BackupServer-fd 2: ClientHost-fd Select the Client (1-2): 2ستُعرَض الآن لنا شجرة ملفّات افتراضية مع كامل بنية الدليل الذي قمنا بالنسخ الاحتياطي له، تسمح هذه الواجهة المشابهة لواجهة الصدفة shell للأوامر البسيطة بتحديد وإلغاء تحديد الملفّات التي نريد استعادتها. ولأنّنا حدّدنا أنّنا نريد استعادة كافّة الملفّات "restore all"، فجميع الملفّات الموجودة في النسخة الاحتياطيّة مُحدّدة لاستعادتها، الملفّات المحدّدة مسبوقة بالحرف *. ولتحسين اختيار الملفّات، نستطيع التصفّح وسرد الملفّات باستخدام الأمرين "ls" و"cd"، تحديد الملفّات باستخدام الأمر "mark"، وإلغاء تحديد الملفّات باستخدام الأمر "unmark"، وتوجد قائمة من الأوامر متاحة بكتابة "help" في الـ console. عند الانتهاء من اختيار الملفّات التي نريد استعادتها نتابع بكتابة ما يلي: doneنقوم بتأكيد أنّنا نرغب بتنفيذ وظيفة الاستعادة: OK to run? (yes/mod/no): yesالتحقق من الرسائل والحالةيجب علينا التحقّق من الرسائل وحالة المدير بعد تشغيل وظيفة استعادة الملفّات، كما هو الحال مع وظيفة النسخ الاحتياطي. نتحقّق من الرسائل بكتابة ما يلي: messagesينبغي أن نجد رسالة تخبرنا أنّ وظيفة استعادة الملفّات قد بدأت أو تمّت مقاطعتها بحالة "Restore OK"، إن وُجِدَت أيّة أخطاء أخرى فهناك خطأ ما ويجب أن تعطيك هذه الأخطاء تلميحًا عن سبب عدم عمل الوظيفة. وكما وجدنا سابقَا فإنّ التحقّق من حالة المدير هو طريقة رائعة لنرى حالة وظيفة استعادة الملفّات: status directorعند الانتهاء من استعادة الملفّات نكتب exit لمغادرة Bacula Console: exitإن سار كل شيء على ما يرام فسنجد الملفّات التي تمّت استعادتها على مضيف العميل في الدليل /bacula/restore، إن كنت فقط تختبر عمليّة استعادة الملفّات فاحذف محتويات هذا الدليل. الخاتمةتمتلك الآن خادوم Bacula يقوم بالنسخ الاحتياطي للملفّات من عميل Bacula عن بعد، تأكّد من أن تراجع إعداداتك حتى تصبح متأكدًا من أنّك تقوم بالنسخ الاحتياطي لمجموعة الملفّات FileSets الصحيحة، وبجدول ملائم لاحتياجاتك. الخطوة القادمة التي يجب فعلها هي أن تعيد الخطوات السابقة من أجل خواديم Ubuntu الإضافية التي تريد عمل نسخ احتياطي لها. ترجمة -وبتصرّف- لـ How To Back Up an Ubuntu 14.04 Server with Bacula لصاحبه Mitchell Anicas.

Bacula هو برنامج مفتوح المصدر للنسخ الاحتياطي في الشبكة؛ يمكّن من إنشاء نسخ احتياطية Backups من نظام التشغيل واستعادة البيانات في حال حصول مشكل. يتميز Bacula بالمرونة والمتانة، الأمر الذي يجعل منه مناسبا للنسخ الاحتياطي في حالات كثيرة؛ على الرغم من أن إعداده مرهق قليلا. يعد نظام النسخ الاحتياطي جزءا مهما في أغلب البنى التحتية للخواديم؛ نظرا لكون إعادة البيانات (إرجاعها) عنصرا أساسيا في أغلب خطط استعادة الأنظمة. سنشرح في هذا الدرس كيفية تثبيت عناصر الخادوم في Bacula على خادوم Ubuntu 14.04 وضبطها. سنعد Bacula لإنشاء شغل أسبوعي job ينشئ نسخة احتياطية محلية (أي على المضيف Host الذي يعمل عليه Bacula). لا يفرض Bacula نسخ البيانات محليَّا، إلا أننا بهذه الطريقة نوفر نقطة انطلاق جيدة لإنشاء نسخ احتياطية من خواديم أخرى يثبَّت عليها عميل Client لـ Bacula ويُضبط الاتصال بينه والخادوم. المتطلباتتتطلب خطوات المقال صلاحيات وصول المستخدم الأعلى (sudo) على خادوم Ubuntu 14.04. سيحتاج الخادوم أيضا لمساحة قرص صلب كافية لتخزين جميع النسخ الاحتياطية التي تخطط للإبقاء عليها ضمن حيز زمني محدَّد. سنعد Bacula لاستخدام اسم نطاق معرَّف بالكامل Fully Qualified Domain Name, FQDN (راجع مقال مقدّمة إلى مُصطَلحات وعناصر ومفاهيم نظام أسماء النطاقات للمزيد عن اسم النطاق المعرَّف بالكامل)، على سبيل المثال bacula.private.example.com. استخدم عناوين IP المناسبة إن لم يكن لديك نظام لإدارة النطاقات. أبدل معلومات الاتصال بالشبكة الموجودة في هذا الدرس بعناوين شبكة يمكن لخواديمك الوصول إليها (عناوين IP أو أنفاق شبكات خاصة افتراضية) نبدأ بعرض عام للعناصر المكوِّنة لـ Bacula. نظرة عامة على عناصر Baculaيتبع Bacula نموذج خادوم-عميل Server-client في النسخ الاحتياطي، ويتكون من عناصر برمجية مختلفة. سنركز في ما يلي على جزأيْ الخادوم والعميل بدلا من الحديث عن كل عنصر لوحده. إلا أنه يبقى من الأهمية بمكان أخذ معرفة سطحية بالعناصر المكونة للتطبيق. يتكون خادوم Bacula (نشير إليه في بعض الأحيان بـ”خادوم النسخ الاحتياطي”) من العناصر التالية: مدير Bacula (يُشار إليه بـDIR): وهو البرنامج الذي يتحكم في عمليات النسخ الاحتياطي والإعادة التي تنفذها خدمتا File وStorage.خدمة التخزين Storage (يُشار إليها بـSD): برنامج يقرأ من أجهزة التخزين المستخدمة للنسخ الاحتياطي ويكتب فيها.برنامج الفهرس Catalog: خدمات تحتفظ بقاعدة بيانات للملفات المنسوخة احتياطا. تُستخدم قاعدة بيانات مثل MySQL أو PostgreSQL لهذا الغرض.وحدة تحكم Bacula: واجهة بسطر أوامر يتفاعل بواسطتها مسؤول النسخ الاحتياطي مع مدير Bacula ويتحكم فيه.ملحوظة: ليس مفروضا تواجدُ جميع العناصر المكونة لخادوم Bacula على نفس الخادوم الحسي؛ إلا أنها جميعها تعمل معا لتوفير وظيفة خادوم النسخ الاحتياطي. يشغِّل عميلُ Bacula (أي الخادوم الذي نريد أخذ نسخ احتياطية منه) خدمة File (يُشار إليها بـFD). هذا العنصر عبارة عن برنامج يتيح لخادوم Bacula (مدير Bacula تحديدا) الوصول إلى البيانات التي ستُنسَخ. نسمي الخواديم التي نريد أخذ نسخ منها “عملاء النسخ الاحتياطي” أو “العملاء”. سنعدّ مثل ما أشرنا في المقدمة، خادوم النسخ الاحتياطي لإنشاء نسخة احتياطية من نظام ملفاته الخاص؛ وهو ما يعني أن خادوم النسخ الاحتياطي سيكون أيضا عميل نسخ احتياطي وبالتالي سيشغل خدمة File. نبدأ بالتثبيت. تثبيت MySQLيستخدم Bacula قاعدة بيانات SQL مثل MySQL وPostgreSQL لإدارة الفهرس. سنستخدم MySQL في هذا الدرس. نبدأ بتحديث الحزم: $ sudo apt-get updateثم نثبت خادوم MySQL: $ sudo apt-get install mysql-serverسيُطلَب منك إدخال كلمة سر خاصة بالحساب الإداري root لـMySQL. أدخل كلمة سر ثم أكدها. ستحتاج لكلمة السر هذه أثناء تثبيت Bacula. تثبيت Baculaننفذ الأمر التالي لتثبيت العناصر المكونة لخادوم Bacula وعميله: $ sudo apt-get install bacula-server bacula-clientسيُطلب منك إدخال معلومات ستُستخدم لإعداد Postfix الذي يستخدمه Bacula: النوع العام لإعداد البريد General Type of Mail Configuration: اختر Internet Site.اسم نظام البريد: أدخل اسم النطاق الكامل لخادومك أو اسم المضيف.في الخطوة الموالية تُطلب معلومات تستخدم لإعداد قاعدة بيانات Bacula: اختر Yes بالنسبة لخيار Configure database for bacula-director-mysql with dbconfig-common.أدخل كلمة سر الحساب الإداري لـMySQL ثم أكدها (خيار Password of the database's administrative user).أدخل كلمة سر جديدة وأكدها عند خيار MySQL application password for bacula-director-mysql أو اتركها فارغة لتوليد كلمة سر عشوائية.الخطوة الأخيرة في عملية التثبيت هي تحديث أذون السكربت الذي يستخدمه Bacula أثناء شغل فهرس النسخ الاحتياطي: $ sudo chmod 755 /etc/bacula/scripts/delete_catalog_backupننتقل الآن، بعد تثبيت الخادوم والعميل الخاصين بـBacula إلى إنشاء مجلدات النسخ الاحتياطي والإعادة. إنشاء مجلدات النسخ الاحتياطي والإعادةيحتاج Bacula إلى مجلد للنسخ الاحتياطي يخزِّن فيه الأرشيف، ومجلد للإعادة يضع فيه الملفات المُعادة. تأكد من إنشاء هذه المجلدات على تجزئة بمساحة كافية. ننشئ مجلدين جديدين: $ sudo mkdir -p /bacula/backup /bacula/restoreنعدّل أذون الملف لكي يقتصر إذن الوصول للمجلدات على عمليّة bacula (والمستخدم الأعلى): $ sudo chown -R bacula:bacula /bacula $ sudo chmod -R 700 /baculaبهذا نكون جاهزين لإعداد مدير Bacula. إعداد مدير Baculaيتكون Bacula من عناصر عدة يجب إعداد كل واحد منها على حدة ليعمل بطريقة صحيحة. توجد جميع ملفات الإعداد في المجلَّد etc/bacula/. نبدأ بمدير Bacula. افتح ملف إعداد المدير لتحريره: $ sudo nano /etc/bacula/bacula-dir.confإعداد الأشغال المحليةيُستخدَم شغل Bacula لـتنفيذ إجراءات النسخ الاحتياطي والإعادة. تعرِّف موارد الشغل تفاصيل ما يفعله شغلٌ مّا. تتضمن تفاصيل الشغل اسم العميل، مجموعة الملفات FileSet المُراد نسخها أو إعادتها وأمورا أخرى. سنعد هنا الأشغال التي سنستخدمها لنسخ نظام الملفات المحلي. ابحث في ملف bacula-dir.conf عن مورد الشغل ذي الاسم BackupClient1. غير قيمة Name لتصبح BackupLocalFiles: Job { Name = "BackupLocalFiles" JobDefs = "DefaultJob" }ابحث الآن عن مورد الشغل RestoreFiles. يجب أن تعدِّل قيمتين في هذا المورد: غير قيمة Name لتصبح RestoreLocalFiles وقيمة Where لتصبح bacula/restore/. يبدو الملف بعد التعديل على النحو التالي: Job { Name = "RestoreLocalFiles" Type = Restore Client=BackupServer-fd FileSet="Full Set" Storage = File Pool = Default Messages = Standard Where = /bacula/restore }تعد هذه التعليمات شغل RestoreLocalFiles لإعادة الملفات إلى المجلَّد bacula/restore/ الذي أنشأناه سابقا. إعداد مجموعة الملفاتتعيّن مجموعة ملفات Bacula - كما يشير الاسم - مجموعة ملفات أو مجلدات للتضمين أو الإبعاد من النسخ الاحتياطية. ابحث عن مجموعة ملفات FileSet باسم Full Set (توجد تحت التعليق # List of files to be backed up أي قائمة جميع الملفات المراد نسخها). سنجري ثلاثة تعديلات:(1) إضافة خيار استخدام gzip لضغط النسخ الاحتياطية، (2) تغيير الملفات المضمّنة من usr/sbin/ إلى / و(3) تغيير الملفات المبعدة وإضافة المسار bacula/. يبدو المورد بعد نزع التعليقات على النحو التالي: FileSet { Name = "Full Set" Include { Options { signature = MD5 compression = GZIP } File = / } Exclude { File = /var/lib/bacula File = /bacula File = /proc File = /tmp File = /.journal File = /.fsck } }أولا، تفعِّل التعليمات استخدام gzip لضغط الملفات أثناء إنشاء النسخ الاحتياطية؛ ثم تضيف الجذر / إلى الملفات المُراد نسخها (أي جميع ملفات التجزئة). وأخيرا تبعد المجلّد bacula/ من النسخة الاحتياطية لكي لا نعيد نسخ النسخ الاحتياطية السابقة والملفات المُعادة. ملحوظة: إن رغبت في إضافة تجزئات مركَّبة Mounted partitions في / إلى مجموعة الملفات فيجب إضافة تعليمة File لكل واحدة منها. تذكر أن النسخ الاحتياطية ستحتاج، عند استخدام مجموعات ملفات كبيرة مثل Full Set في أشغال النسخ الاحتياطي، مساحة أكبر على القرص الصلب مما لو كان اختيار ملفات النسخ أكثر تحديدا. على سبيل المثال، إن كان لديك مخطّط إعادة Recovery plan يحدد الحزم البرمجية الواجب تثبيتها والأماكن التي يجب وضع الملفات المعادة فيها؛ فإن مجموعة ملفات لا تتضمن سوى ملفات الإعداد المخصَّص وقواعد البيانات تكفي لاحتياجاتك ولا تستخدم سوى جزء يسير من القرص الصلب لتخزين أرشيف النسخ الاحتياطية. إعداد الاتصال الخاص بخدمة التخزين Storageيعرّف مورد Storage في ملف إعداد المدير خدمة التخزين التي يجب على مدير Bacula الاتصال بها. سنضبُط خدمة التخزين في ما بعد. اعثُر على مورد Storage وأبدل قيمة Address (أي localhost) باسم النطاق الكامل FQDN المحلي (أو عنوان IP المحلي) لخادوم النسخ الاحتياطي. يبدو الملف بعد التعديل كالتالي (أبدل : Storage { Name = File # Do not use "localhost" here Address = backup_server_private_FQDN # N.B. Use a fully qualified name here SDPort = 9103 Password = "ITXAsuVLi1LZaSfihQ6Q6yUCYMUssdmu_" Device = FileStorage Media Type = File } سنعد خدمة التخزين للإنصات لواجهة الشبكة المحلية حتى يتسنى للعملاء الاتصال بها، لذا من المهم إعداد المورد لاستخدام العنوان المحلي لخادوم النسخ الاحتياطي. إعداد مجمع تخزين Storage poolيعرف مورد Pool وسائط التخزين التي سيخزن عليها Bacula النسخ الاحتياطية. سنتعامل مع ملفات كما لو كانت تجزئات للتخزين ثم نحدث اللصيقة Label لتوصيف النسخ الاحتياطية المحلية. ابحث عن مورد Pool باسم File (توجد تحت التعليق # File Pool definition) وأضف سطرا لتحديد صيغة اللصيقة. يبدو المورد، بعد التعديل، على النحو التالي: # File Pool definition Pool { Name = File Pool Type = Backup Label Format = Local- Recycle = yes # Bacula can automatically recycle Volumes AutoPrune = yes # Prune expired volumes Volume Retention = 365 days # one year Maximum Volume Bytes = 50G # Limit Volume size to something reasonable Maximum Volumes = 100 # Limit number of Volumes in Pool }احفظ الملف ثم أغلقه. بهذا يكتمل إعداد مدير Bacula. التحقق من إعدادات مدير Baculaنتحقق من عدم وجود أخطاء صياغة في ملف إعداد المدير DIR: $ sudo bacula-dir -tc /etc/bacula/bacula-dir.confإن لم تظهر رسائل خطأ فملف الإعداد نظيف من أخطاء الصياغة. ننتقل لإعداد خدمة التخزين SD. إعداد خدمة التخزيننحتاج لإعداد خدمة التخزين حتى يعرف خادوم Bacula أين يخزّن النسخ الاحتياطية. افتح ملف إعداد التخزين لتحريره: $ sudo nano /etc/bacula/bacula-sd.confإعداد مورد Storageاعثر على مورد Storage في ملف الإعداد الذي فتحته للتو. يعرّف هذا المورد العنوان الذي تنصت خدمة التخزين للاتصالات القادمة منه. أضف معطى SDAddress وحدد قيمته بالنطاق الكامل (أو عنوان IP) المحلي لخادوم النسخ الاحتياطي: Storage { # definition of myself Name = BackupServer-sd SDPort = 9103 # Director's port WorkingDirectory = "/var/lib/bacula" Pid Directory = "/var/run/bacula" Maximum Concurrent Jobs = 20 SDAddress = backup_server_private_FQDN }إعداد وسيط التخزيناعثر على مورد Device باسم FileStorage وحدث قيمة Archive Device لتوافق مجلد النسخ الاحتياطي لديك: Device { Name = FileStorage Media Type = File Archive Device = /bacula/backup LabelMedia = yes; # lets Bacula label unlabeled media Random Access = Yes; AutomaticMount = yes; # when device opened, read it RemovableMedia = no; AlwaysOpen = no; }احفظ الملف ثم أغلقه. التحقق من إعداد خدمة التخزينننفذ الأمر التالي للتحقق من عدم وجود أخطاء صياغة في ملف الإعداد الخاص بخدمة التخزين: $ sudo bacula-sd -tc /etc/bacula/bacula-sd.confإن لم تظهر رسائل خطأ فملف الإعداد نظيف من أخطاء الصياغة. أكملنا إعداد Bacula وأصبحنا جاهزين لإعادة تشغيل عناصر خادوم Bacula. إعادة تشغيل مدير Bacula وخدمة التخزيننعيد تشغيل مدير Bacula وخدمة التخزين لاعتماد تعديلات الإعدادات: $ sudo service bacula-director restart $ sudo service bacula-sd restartنجرب، بعد إعادة تشغيل الخدمتين، عمل خادوم Bacula بإنشاء شغل نسخ احتياطي. اختبار شغل للنسخ الاحتياطينستخدم وحدة تحكم Bacula لتشغيل أول شغل للنسخ الاحتياطي؛ إن عمل دون مشاكل فسنتأكد أن Bacula مضبوط بطريقة صحيحة. ادخل إلى وحدة التحكم بتنفيذ الأمر التالي: $ sudo bconsoleستُنقَل إلى محثّ Prompt وحدة تحكم Bacula المُشار إليه ب*. إنشاء لصيقةابدأ بتنفيذ أمر label: * labelسيُطلب منك إدخال اسم للتجزئة: Enter new Volume name: MyVolumeثم اختر مجمع التخزين الذي تريد أن يستخدم للنسخ الاحتياطية. سنختار File الذي أعددناه سابقا بإدخال الرقم 2: Select the Pool (1-3): 2التشغيل اليدوي لشغل نسخ احتياطيأعطينا Bacula المعلومات الكافية ليعرف كيف يخزن بيانات النسخ الاحتياطية، ويمكن بالتالي تشغيل النسخ الاحتياطي لمعرفة ما إذا كان يعمل بطريقة صحيحة: * runسيطلب منك اختيار الشغل الذي تريد تشغيله. نريد تشغيل BackupLocalFiles لذا سنختار 1: Select Job resource (1-3): 1راجع التفاصيل في محث التأكيد Run Backup job ثم اختر Yes للتشغيل: * yesفحص الرسائل والحالةسيخبرك Bacula بعد تشغيل شغل للنسخ الاحتياطي أن لديك رسائل، وهي مخرجات ولّدتها الأشغال الجارية. افحص الرسائل بتنفيذ الأمر: * messagesيجب أن تظهر رسالة No prior Full backup Job record found (أي لم يُعثر على سجل لنسخة احتياطية كاملة سابقة) وأخرى تخبرك ببدء الشغل. ستظهر رسائل خطأ في حال وجود مشاكل مع تلميحات لأسبابها، لماذا لم ينفَّذ الشغل مثلا. توجد طريقة أخرى لمعرفة حالة الشغل وهي فحص حالة المدير. لاستعمال هذه الطريقة أدخل اﻷمر التالي في محث وحدة التحكم bconsole: * status directorإن كان كل شيء جرى على ما يرام فسترى أن الشغل يعمل. ستظهر مخرجات تشبه التالي: Running Jobs: Console connected at 09-Apr-15 12:16 JobId Level Name Status ====================================================================== 3 Full BackupLocalFiles.2015-04-09_12.31.41_06 is running ====ستنتقل وحدة التحكم إلى فقرة Terminated Jobs (أشغال مكتملة) من تقرير الحالة عند انتهاء تنفيذ الشغل. تظهر المخرجات بما يشبه التالي: Terminated Jobs: JobId Level Files Bytes Status Finished Name ==================================================================== 3 Full 161,124 877.5 M OK 09-Apr-15 12:34 BackupLocalFilesتشير الحالة OK إلى أن شغل النسخ الاحتياطي عمل دون مشاكل. الخطوة التالية هي اختبار شغل الإعادة. اختبار شغل الإعادةمن المهم بعد إنشاء النسخ الاحتياطية اختبار إمكانية إعادتها على نحو سليم. يمكن أمر restore من إعادة الملفات التي نسخناها احتياطا. تنفيذ الشغل Restore Allسنعيد جميع الملفات الموجودة في آخر نسخة احتياطية، لذا نستخدم الأمر: * restore allستظهر قائمة بها خيارات متعددة تستخدم لتعريف أي مجموعة نسخ احتياطية نعيد الملفات منها. بما أنه لا توجد لدينا سوى نسخة واحدة فسنحدد الخيار 5 Select the most recent backup (اختر النسخة الاحتياطية الأحدث): Select item (1-13): 5بما أنه لا يوجد سوى عميل واحد وهو خادوم Bacula فسيُختار. المحث التالي يسأل عن مجموعة الملفات التي تريد استخدامها. اختر Full Set أي الرقم 2: Select FileSet resource (1-2): 2سيُحيلك الخيار إلى شجرة افتراضية للملفات يوجد بها تخطيط كامل للمجلد الذي نسخته احتياطا. تسمح هذه الواجهة التي تشبه Shell بتحديد الملفات المرادة إعادتها أو نزع تحديدها. بما أننا نفذنا أمر restore all (إعادة الجميع) فإن كل ملف في المخطّط الشجري محدَّد لإعادته. تسبق علامة * الملفات المحدّدة. إن أردت تخصيص الاختيار فيمكن التنقل في قائمة الملفات باستخدام الأمرين ls وcd، تحديد الملفات بmark ونزع تحديدها بunmark. تحصل على قائمة بجميع الأوامر المتاحة عند تنفيذ الأمر help (مساعدة) في وحدة التحكم. لبدء عملية الإعادة، بعد الانتهاء من تحديد الملفات، نفذ الأمر: * doneأكد رغبتك في تنفيذ شغل الإعادة: OK to run? (yes/mod/no): yesفحص الرسائل والحالةندقق، مثل ما فعلنا مع شغل النسخ الاحتياطي، في رسائل مدير Bacula وحالته بعد تنفيذ شغل الإعادة. افحص الرسائل بتنفيذ: * messagesيجب أن تظهر رسالة تفيد ببدء شغل الإعادة أو أنه اكتمل مع حالة OK دلالةً على نجاح العملية. ستظهر رسائل خطأ في حال وجود مشاكل مع تلميحات لأسبابها. يمكن أيضا فحص حالة المدير: * status directorنفذ الأمر exit للخروج من وحدة تحكم Bacula بعد الانتهاء من إعادة الملفات: * exitالتحقق من إعادة الملفاتيمكن بالنظر إلى المجلد bacula/restore/ (عرّفناه ضمن شغل RestoreLocalFiles في إعداد مدير Bacula) التحقق من أن شغل الإعادة أرجع فعلا الملفات المحدَّدة: $ sudo ls -la /bacula/restoreيجب أن تظهر الملفات المُعادة في جذر نظام الملفات مع إبعاد الملفات والمجلدات الموجودة في فقرة Exclude من شغل RestoreLocalFiles. يجب أن تنسخ الملفات المعادة من النسخ الاحتياطية، عند إرجاع بيانات مفقودة، إلى أماكنها المناسبة (وضع ملفات الإعداد مثلا في المجلد المناسب حسب البرنامج أو التطبيق). حذف الملفات المعادةنفذ الأمر التالي إن أردت حذف الملفات المعادة، لإخلاء مساحة في القرص الصلب: $ sudo -u root bash -c "rm -rf /bacula/restore/*"يجب تنفيذ أمر rm بصلاحيات root إذ أن الكثير من الملفات المعادة يمتلكها المستخدم الأعلى. خاتمةيكون لديك باتباع الخطوات المشروحة في هذا المقال إعداد أساسي لـBacula يمكن من نسخ نظام الملفات المحلي وإعادته. الخطوة الموالية هي إضافة خواديم عميلة لتتمكن من إرجاع بياناتها في حال فقدان ملفات من النظام. ترجمة -وبتصرف- للمقال How To Install Bacula Server on Ubuntu 14.04 لصاحبه Mitchell Anicas.

تحتاج خطط الاسترداد التي أعددناها في الجزء السابق إلى نظام للنسخ الاحتياطي. سنركز في هذا المقال على نظام النسخ الاحتياطي Bacula. يتيح Bacula تحكّمًا تامًا في ما تريد نسخه أو استعادته على المستوى الفردي للملفات؛ كما يسمح بجدولة النسخ الاحتياطي والاستعادة وفقا لما تراه أفضل بالنسبة لك. سنُعدّ Bacula في هذا الجزء لتخزين نسخ احتياطية يوميا. تحوي النسخُ الملفاتِ الضروريةَ من الخواديم التي تكون التطبيق (app2، app1، db1 وlb1). حددنا في الجزء السابق الملفات التي نريد نسخها احتياطيا. يُريك هذا المقال كيفية استخدام Bacula لإنشاء نسخ احتياطية من حزمة برمجيات LAMP (أي MySQL، Apache، Linux وPHP). سنستعمل أيضا Percona XtraBackup لإنشاء نسخ احتياطية ساخنة Hot backups من قاعدة بيانات MySQL. ثم - في الأخير - نستخدم rsync لنسخ الملفات التي أنشأها Bacula على خادوم يوجد في موقع جغرافي آخر؛ أي أنه ستكون لدينا نسختان احتياطيتان، واحدة موجودة في نفس مركز بيانات الذي توجد به بيئة الإنتاج والأخرى في موقع ناء. سنضيف خادومين إلى الخواديم الموجودة سلفا: backups وremotebackups؛ الأخير يوجد في مركز بيانات ناء. ملحوظة: نعني بالنسخ الاحتياطي الساخن - أو الديناميكي - أخذ نسخة من قاعدة البيانات وهي في حالة نشاط؛ مما يعني أنه قد يحصل تعديل عليها أثناء عملية النسخ. يقابل النسخَ الساخن النسخُ البارد Cold backup والذي توقف فيه قاعدة البيانات عن العمل، ثم تؤخذ نسخة منها قبل أن يُعاد تشغيلها. تثبيت Bacula على خادوم النسخ الاحتياطيةاضبط Bacula على خادوم backups باتباع خطوات الدرس التالي: كيف تثبت خادوم Bacula على Ubuntu 14.04. ثم اتبع فقرة تنظيم إعداد مدير Bacula (الخادوم) في مقال كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. ستحتاج لاسم المدير Director name عند إعداد عملاء Bacula على الخواديم التي تريد نسخها احتياطيا. توقف عند الوصول إلى فقرة تثبيت عميل Bacula وإعداده. تثبيت عميل Bacula على كل خادومثبت عميل Bacula على كل واحد من الخواديم التي تريد نسخها احتياطيا (app2، app1، db1 وlb1) باتباع فقرة تثبيت عميل Bacula وإعداده من درس كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. توقف عند الوصول إلى فقرة إضافة مجموعة ملفات FileSets (الخادوم). يرجى الانتباه إلى أنك ستحتاج اسم FileDaemon (جنيّ الملفات، يكون عادة اسم المستضيف مضافا إليه “fd-“) وكلمة سر المدير Director (كلمة السر التي سيستخدمها خادوم Bacula للاتصال بكل واحد من العملاء). توجد القيمتان ضمن ملف bacula-fd.conf الموجود على كل خادوم. إضافة عملاء Bacula إلى خادوم النسخ الاحتياطيأضف، إلى خادوم Bacula (أي backups)، موردَ عميل Client resource لكل واحد من الخواديم التي ثبت عليها عميل Bacula. يُضاف مورد العميل إلى الملف etc/bacula/conf.d/clients.conf/: sudo nano /etc/bacula/conf.d/clients.confفي ما يلي مثال على تعريف مورد العميل بالنسبة لخادوم قاعدة البيانات db1. يجب أن توافق قيمة Name اسم المورد FileDaemon الموجود على الخادوم العميل. نفس الشيء بالنسبة لPassword التي يجب أن توافق قيمة Password ضمن مورد Director على الخادوم العميل. توجد هذه القيم في ملف etc/bacula/bacula-fd.conf/ على كل واحد من عملء Bacula. Client { Name = db1-fd Address = db1.nyc3.example.com FDPort = 9102 Catalog = MyCatalog Password = "PDL47XPnjI0QzRpZVJKCDJ_xqlMOp4k46" # كلمة سر العميل File Retention = 30 days # 30 يوما Job Retention = 6 months # 6 أشهر AutoPrune = yes # التخلص من الأشغال/الملفات منتهية الصلاحية }أنشئ بنفس الطريقة مورد عميل لكل واحد من الخواديم العميلة لخادوم Bacula. يجب بانتهاء الإعداد في المثال أن تكون لدينا أربعة موارد عملاء: app2-fd، app1-fd، db1-fd وlb1-fd. تضبط هذه الإعدادات الخادوم backups ليكون قادرا على الاتصال بعميل Bacula الموجود على كل خادوم. احفظ الملف ثم أغلقه. يمكن الحصول على تفاصيل أكثر بمراجعة فقرة تثبيت عميل Bacula وإعداده في درس كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. إنشاء نسخ احتياطية ساخنة من قاعدة البياناتيجب إيلاء اهتمام خاص لنسخ قاعدة البيانات الاحتياطية، من أجل إنشاء نسخ احتياطية متناسقة وقابلة للاستخدام. توجد طريقة سهلة وفعالة لإنشاء نسخ احتياطية ساخنة لقاعدة بيانات MySQL وهي استخدام Percona XtraBackup. تثبيت Percona XtraBackupثبت Percona XtraBackup واضبطه على خادوم قاعدة البيانات db1 باتباع خطوات الدرس كيف تستخدم Percona XtraBackup لإنشاء نسخ احتياطية فورية من قواعد بيانات MySQL على Ubuntu 14.04. توقف عند الوصول إلى فقرة إنشاء نسخة احتياطية كاملة فوريا. إنشاء سكربت XtraBackupPercona XtraBackup جاهز الآن لإنشاء نسخ احتياطية ساخنة من قاعدة بيانات MySQL. سيحتفظ Bacula بهذه النسخ؛ إلا أنه يجب أولا إيجاد طريقة لجدولة النسخ الساخنة. نستخدم cron لهذه المهمة. أنشئ سكربت Bash في usr/local/bin/ وسمه run_extra_backup.sh: sudo nano /usr/local/bin/run_xtrabackup.shأضف السكربت التالي إلى الملف الذي أنشأته للتو (تأكد من إدراج اسم المستخدم وكلمة السر الذين استعملتهما عند تثبيت XtraBackup): #!/bin/bash # pre xtrabackup chown -R mysql: /var/lib/mysql find /var/lib/mysql -type d -exec chmod 770 "{}" \; # delete existing full backup rm -r /data/backups/full # xtrabackup create backup innobackupex --user=bkpuser --password=bkppassword --no-timestamp /data/backups/full # xtrabackup prepare backup innobackupex --apply-log /data/backups/fullاحفظ الملف ثم أغلقه. سيؤدي تنفيذ هذا الملف بصلاحيات الحساب الإداري إلى حذف نسخة XtraBackup الاحتياطية الموجودة ضمن مسار data/backups/full/ وإنشاء نسخة احتياطية كاملة جديدة. توجد تفاصيل أكثر عن النسخ الاحتياطية باستخدام XtraBackup ضمن فقرة إنشاء نسخة احتياطية كاملة ساخنة في درس XtraBackup. اجعل السكربت قابلا للتنفيذ: sudo chmod +x /usr/local/bin/run_xtrabackup.shيجب تنفيذ سكربت XtraBackup وإكماله قبل أن يحاول Bacula أخذ نسخة احتياطية من خادوم قاعدة البيانات، وذلك من أجل نسخ قاعدة البيانات بطريقة صحيحة. يمكن إعداد شغل Job في Bacula للتعامل مع السكربت على أنه “سكربت لما قبل النسخ الاحتياطي”؛ إلا أننا سنختار هنا استخدام شغل cron توخيا للسهولة. أنشئ ملف إعداد لcron (تُضاف الملفات الموجودة ضمن المجلد etc/cron.d/ إلى جدول cron الخاص بالمستخدم الجذر): sudo nano /etc/cron.d/xtrabackupأضف شغل cron التالي: 30 22 * * * root /usr/local/bin/run_xtrabackup.shيُجدول هذا الشغل السكربت ليعمل بصلاحيات الجذر كل يوم عند الساعة العاشرة والنصف مساء (22:30). اخترنا هذا الوقت لأن Bacula مُجدول حاليا ليأخذ نسخا احتياطية يوميا عند الساعة الحادية عشرة مساء وخمس دقائق (23:05). سنناقش هذا الخيار في ما بعد. يعطينا فارق الجدولة هذا 35 دقيقة ليكتمل عمل سكربت XtraBackup. اكتمل الآن إعداد النسخ الاحتياطي الساخن لقاعدة البيانات. ننتقل لمجموعات ملفات FileSets النسخة الاحتياطية لBacula. إعداد مجموعة ملفات FileSets في Baculaسننشئ نسخا احتياطية من الملفات المحدَّدة ضمن مجموعة الملفات المربوطة بأشغال النسخ الاحتياطي التي ستُنفَّذ. ستغطي هذه الفقرة إنشاء مجموعة ملفات تحوي النسخ الاحتياطية الضرورية المحدّدة في خطط الاسترداد. يمكن إيجاد تفاصيل أكثر عن إضافة مجموعة ملفات إلى Bacula تحت فقرة إضافة مجموعة ملفات FileSets (الخادوم) في درس Bacula. افتح ملف filesets.conf الموجود على خادوم النسخ الاحتياطي backups: sudo nano /etc/bacula/conf.d/filesets.confمجموعة الملفات الخاصة بخادوم قاعدة البياناتتتضمن النسخ الاحتياطية المطلوبة من خادوم قاعدة البيانات، وفقا لخطة استرداد قاعدة البيانات: قاعدة بيانات MySQL: ينشئ سكربت XtraBackup نسخة احتياطية من قاعدة البيانات يوميا عند الساعة 22:30 ويضعها في المجلد data/backups/full/.ملف إعداد MySQL الموجود في المجلد etc/mysql/.سنضمِّن أيضا سكربت usr/local/bin/run_xtrabackup.sh/ وملف cron المتعلق به. نضيف اعتمادا على ما سبق مجموعة ملفات باسم MySQL Database إلى إعداد Bacula: FileSet { Name = "MySQL Database" Include { Options { signature = MD5 compression = GZIP } File = /data/backups File = /etc/mysql/my.cnf File = /usr/local/bin/run_xtrabackup.sh File = /etc/cron.d/xtrabackup } Exclude { File = /data/backups/exclude } } ننتقل الآن إلى مجموعة ملفات التطبيق. مجموعة الملفات الخاصة بخادوم التطبيقتتضمن النسخ الاحتياطية المطلوبة من خادوم التطبيق وفقا لخطة استرداد هذا الأخير: ملفات التطبيق الموجودة - في مثالنا - على المسار var/www/html/.نضيف اعتمادا على هذه المعلومة مجموعة ملفات Apache DocumentRoot إلى ملف إعداد Bacula: FileSet { Name = "Apache DocumentRoot" Include { Options { signature = MD5 compression = GZIP } File = /var/www/html } Exclude { File = /var/www/html/exclude } } يمكن أيضا أن تضيف ملف الإعداد الخاص بمنافذ Apache، إلا أنه يمكن تغيير هذا الملف بسهولة عند الحاجة. مجموعة الملفات الخاصة بخادوم توزيع الحملالطريقة المتَّبعة هي نفسها. نحدد الملفات المطلوب نسخها ثم ننشئ مجموعة ملفات في Bacula اعتمادا عليها. الملفات المطلوبة: ملف PEM الخاص بشهادة SSL والملفات المتعلقة بها، توجد هذه الملفات على مسار root/certs/ في مثالنا.ملف إعداد HAProxy: يوجد في مجلد etc/haproxy.سنضيف هذه الملفات إلى مجموعة Apache DocumentRoot: FileSet { Name = "Apache DocumentRoot" Include { Options { signature = MD5 compression = GZIP } File = /var/www/html File = /root/certs File = /etc/haproxy } Exclude { File = /var/www/html/exclude File = /root/exclude } }احفظ الملف ثم أغلقه. بهذا نكمل إعداد مجموعات الملفات. ننتقل لإعداد أشغال Bacula التي ستستخدم هذه المجموعات. إنشاء أشغال النسخ الاحتياطي في Baculaمهمة الأشغال في Bacula هي إنشاء نسخ احتياطية من الخواديم. أنشئ ملف jobs.conf في المسار etc/bacula/conf.d/: >sudo nano /etc/bacula/conf.d/jobs.confشغل النسخ الاحتياطي لخادوم قاعدة البياناتسننشئ شغل نسخ احتياطي جديدا لخادوم قاعدة البيانات باسم Backup db1. من المهم هنا تحديد الاسم الصحيح للعميل db1-fd واسم مجموعة الملفات MySQL Database: Job { Name = "Backup db1" JobDefs = "DefaultJob" Client = db1-fd Pool = RemoteFile FileSet="MySQL Database" }أشغال النسخ الاحتياطي لخواديم التطبيقاتسننشئ شغل نسخ احتياطي لكل من خادومي التطبيق، Backup app1 للخادوم app1 وBackup app2 لapp2. من المهم، مثل ما فعلنا مع خادوم قاعدة البيانات، تحديد الأسماء الصحيحة للعملاء (app1-fd وapp2-fd) ومجموعة الملفات (Apache DocumentRoot). بالنسبة للخادوم app1: Job { Name = "Backup app1" JobDefs = "DefaultJob" Client = app1-fd Pool = RemoteFile FileSet="Apache DocumentRoot" } وبالنسبة للخادوم app2: Job { Name = "Backup app2" JobDefs = "DefaultJob" Client = app2-fd Pool = RemoteFile FileSet="Apache DocumentRoot" }شغل النسخ الاحتياطي لخادوم توزيع الحملنتبع نفس مبدأ الخطوات السابقة لإنشاء شغل جديد ونسميه Backup lb1: Job { Name = "Backup lb1" JobDefs = "DefaultJob" Client = lb1-fd Pool = RemoteFile FileSet="SSL Certs and HAProxy Config" }احفظ الملف ثم أغلقه. إعادة تشغيل مدير Baculaأعد تشغيل Bacula على خادوم النسخ الاحتياطي لاعتماد التغييرات التي أجريناها في الفقرات السابقة: sudo service bacula-director restartيجب أن تختبر، بالوصول إلى هذه النقطة، اتصالات عملاء Bacula وأشغال النسخ الاحتياطي. يغطى مقال كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula هذين الجانبين. يُرجى ملاحظة أنه لاستعادة قاعدة بيانات MySQL ستحتاج لاتباع خطوة الاستعادة من نسخة احتياطية ضمن درس Percona XtraBackup. مراجعة جدول النسخ الاحتياطييمكن تنظيم جدول النسخ الاحتياطي في Bacula بالتعديل على إعداد مدير Bacula (الملف etc/bacula/bacula-dir.conf/). تستخدم جميع الأشغال التي أنشأناها تعريف الشغل DefaultJob الذي يستخدم جدولةً بدورة أسبوعية تعرَّف على النحو التالي: نسخة احتياطية كاملة Full backup في أول يوم أحد من الشهر عند الساعة 23:05.نسخ احتياطية تفاضلية Differential backups في أيام الأحد المتبقية عند الساعة 23:05.نسخ احتياطية تزايدية Incremental backups في باقي الأيام، من الإثنين إلى السبت عند الساعة 23:05.يمكنك التأكد من طريقة الجدولة وفحص حالة المدير في وحدة تحكم Bacula. يجب أن يظهر جميع الأشغال المُجدولة: Scheduled Jobs: Level Type Pri Scheduled Name Volume =================================================================================== Incremental Backup 10 20-May-15 23:05 BackupLocalFiles MyVolume Incremental Backup 10 20-May-15 23:05 Backup lb1 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup app2 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup app1 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup db1 Remote-0002سيكون من الجيد ضبط جدولة النسخ في خواديم التطبيقات بحيث يحدُث في نفس الوقت الذي ينسَخ فيه سكربت XtraBackup قاعدة البيانات (22:30)؛ وهو ما سيحول دون أن تكون نسخ خواديم التطبيقات غير متجانسة مع نسخة قاعدة البيانات. إعداد نسخ احتياطية نائيةيمكننا الآن إعداد خادوم ناء نحفظ فيه النسخ الاحتياطية التي أنشأها Bacula (إضافة إلى حفظها على خادوم Bacula). يجب أن يكون هذا الخادوم في موقع جغرافي منفصل لكي يمكنك الحصول على النسخ الاحتياطية الهامة إن حدث مشكل مزمن في مركز البيانات الذي توجد فيه بيئة الإنتاج. اخترنا SF01 في المثال موقعا لخادوم remotebackups. سنشرح طريقة سهلة لإرسال النسخ الاحتياطية من خادوم backups إلى خادوم remotebackups باستخدام مفاتيح SSH، أداة rsync وcron. أنشئ حسابا على خادوم remotebackups لاستخدامه في الولوج عبر rsync. ثم أنشئ باستخدام الحساب الجذر زوج مفاتيح SSH لا يحتاج لكلمة سر على خادوم backups. ثبت المفتاح العمومي على الحساب الذي أنشأته للتو على خادوم remotebackups؛ الطريقة مشروحة في مقال العمل مع خواديم SSH: العملاء والمفاتيح اكتب، على خادوم backups أمر rsync ينسخ الملفات الموجودة على مسار bacula/backup/ إلى مكان يوجد على خادوم remotebackups. يغطي درس كيف تستخدِم Rsync لمزامنة مجلّدات بين الجهاز المحلّي والخادوم طريقة استخدام rsync. الشكل العام للأمر سيكون على النحو التالي (remoteuser الحساب على الخادوم البعيد، remotebackups_public_hostname_or_IP اسم المستضيف أو عنوان IP العمومي الخاص بالخادوم البعيد، وpath/to/remote/backup/ مسار مجلد النسخ الاحتياطي على الخادوم البعيد): rsync -az /bacula/backup remoteuser@remotebackups_public_hostname_or_IP:/path/to/remote/backupأضف الأمر لسكربت، مثلا: usr/local/bin/rsync_backups.sh/ واجعله قابلا للتنفيذ. وأخيرا، اضبط شغل cron ينفذ سكربت rsync_backups.sh بصلاحيات root بعد إكمال أشغال Bacula. تمكن مراجعة درس كيف تجدول مهامك الروتينية باستخدام أداتي Cron و Anacron في لينكس لمزيد من التفاصيل عن عمل cron. تأكد بعد ضبط كل هذه الإعدادات من وجود نسخ احتياطية على خادوم remotebackups في اليوم الموالي. اعتبارات أخرىلم نتحدث في ما سبق عن متطلبات القرص الصلب من ناحية التخزين. يجب أن تراجع مساحة التخزين التي تستخدمها نسخك الاحتياطية ثم تعيد النظر في إعداد النسخ الاحتياطي وجدولته وفقا لاحتياجاتك والموارد المتوفرة لديك. يمكن أن تحتاج أيضا إلى إعداد نسخ احتياطية لخواديم أخرى غير خواديم التطبيق. على سبيل المثل خادوما المراقبة والسجلات بعد إكمال إعدادهما. خاتمةيجب أن تكون لديك الآن نسخ احتياطية يومية من خواديم التطبيق في بيئة الإنتاج، ونسخ منها على خادوم بعيد. تحقق من إمكانية استعادة الملفات وأضف خطوات استعادة البيانات إلى خطط الاسترداد. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Backups لصاحبه Mitchell Anicas.

أكملنا في الجزء السابق من هذه السّلسلة إعداد التطبيق المثال؛ يجب علينا الآن تصميم خطة استرداد Recovery plan. خطة الاسترداد (أو الاستعادة) عبارة عن مجموعة موثقة من العمليات التي يجب تنفيذها لتصحيح إعدادات بيئة العمل بعد حدوث مشاكل مزمنة أو عند حصول أخطاء إدارية. يساعد إنشاء خطة استرداد أيضا على تحديد العناصر والبيانات الأساسية ضمن إعدادات خادوم التطبيق. يمكن أن تتمثل خطة استرداد قاعدية من إخفاق بيئة العمل في لائحة بالخطوات الواجب اتباعها لإنجاز النشر الابتدائي للخادوم؛ إلى جانب عمليات إضافية لاستعادة بيانات التطبيق من النسخ الاحتياطية. للحصول على خطة استرداد أفضل يجب، إضافة للتوثيق الجيد، استغلال سكربتات النشر وأدوات إدارة الإعدادات مثل Chef، Ansible وPuppet؛ للمساعدة في أتممة وتسريع الاسترداد. سنوضح في هذا الجزء من السّلسلة كيفية إنشاء خطة استرداد قاعدية لتطبيق ووردبريس الذي أعددناه. سيساعدك الشرح في البدء بتصميم خطة استرداد خاصة بك حتى ولو كانت احتياجاتك مختلفة. متطلبات خطة الاستردادمطلبنا الأساسي هو إمكانية استرداد بيئة العمل بعد فقدان واحد من الخواديم المكوّنة لها، واستعادة وظيفة التطبيق وبياناته؛ إلى حد زمني مقبول. سننشئ جردًا لإعدادات كل خادوم نحدد من خلاله البيانات التي نحتاج لنسخ احتياطية منها؛ ثم نكتب خطة استرداد اعتمادا على ما يوجد في الخادوم. يجب أن نتحقق بعد تنفيذ أي واحدة من خطط الاسترداد أن التطبيق استُرِدّ بطريقة صحيحة. سنخرج بخطة استرداد لكل نوع من الخواديم التي يتكون منها التطبيق: خادوم قاعدة البيانات.خواديم التطبيق.خادوم توزيع الحمل.نبدأ بخادوم قاعدة البيانات. خادوم قاعدة البياناتبإعادة تتبع خطواتنا (وإعادة النظر في الدرس السابق) نجد أن خادوم قاعدة البيانات أنشئ وفقا للخطوات التالية: تثبيت MySQL.إعداد MySQL.إعادة تشغيل MySQL.إنشاء قاعدة البيانات والمستخدمين.خطة استرداد خادوم قاعدة البياناتنعرف، بالنظر لطريقة إنشاء خادوم قاعدة البيانات، أنه تمكن إعادة إنشائه من الصفر ما عدا محتوى قاعدة البيانات. تُخزَّن أغلب بيانات تطبيق ووردبريس (التدوينات مثلا) في قاعدة البيانات. يعني هذا أنه يجب علينا الاحتفاظ بنسخة احتياطية من قاعدة البيانات إن أردنا توفير القدرة على استرداد خادوم قاعدة البيانات. سنحتفظ أيضا بنسخ احتياطية من ملف إعدادات MySQL الذي غيرنا فيه قليلا. في ما يلي ملخَّص لخطة الاسترداد الخاصة بخادوم قاعدة البيانات: يجب الآن التدرب على تنفيذ خطة الاستعادة هذه، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية. خواديم التطبيقنعرف بالنظر في طريقة إنشاء خواديم التطبيق (ومراجعة الدرس السابق)؛ أنّ الخطوات المتَّبعة كانت على النحو التالي: تثبيت كل من PHP وApache وإعدادهما.تنزيل التطبيق (ووردبريس) وإعداده.نسخ ملفات التطبيق إلى جذر المستند Document root.تكرار ملفات التطبيق على جميع خواديم التطبيق.خطة الاسترداد لخادوم التطبيقتمكن إعادة إنشاء خادوم التطبيق من الصفر، ما عدا ملفات التطبيق. تتضمن ملفات التطبيق في المثال ملفات إعداد ووردبريس (التي تحتوي على معلومات الاتصال بقاعدة البيانات)، إضافات ووردبريس المثّبَّتة، والملفات المحمَّلة. أي أنه يجب علينا الاحتفاظ بنسخة احتياطية من ملفات التطبيق إن أردنا إمكانية استرداد خادوم التطبيق. أعددنا الخواديم بحيث تُكرَّر الملفات على خواديم التطبيق؛ يعني هذا أننا لا نحتاج لاستعادة البيانات من النسخ الاحتياطية إلا إذا أخفقت خواديم التطبيق جميعها أو تلَفتْ البيانات بطريقة أو بأخرى. إن بقي خادوم تطبيق واحد على الأقل يعمل جيدا، مع ملفات التطبيق الصحيحة؛ فإن إعادة ضبط تكرار الملفات مرة أخرى سيعيد الملفات الصحيحة إلى خادوم التطبيق الجديد. في ما يلي ملخَّص لخطة الاسترداد الخاصة بخواديم التطبيقات، اعتمادا على الجرد أعلاه: اكتمل إعداد خطة الاسترداد لخواديم التطبيق. يجب الآن التدرب على تنفيذ خطة الاسترداد، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية. خادوم توزيع الحملالمبدأ هو نفسه، ننظر إلى خطوات إنشاء موزع الحمل في الدرس السابق؛ فنخرج بالتالي: الحصول على شهادة SSL والملفات المتعلقة بها.تثبيت HAProxy.إعداد HAProxy.إعادة تشغيل HAProxy.خطة الاسترداد لخادوم توزيع الحملنعرف من الخطوات أعلاه، أنه تمكن إعادة إنشاء موزع الحمل انطلاقا من صفر، ما عدا الملفات المتعلقة بشهادة SSL. يعني هذا أنه يتوجب علينا الاحتفاظ بنسخ احتياطية من الملفات المتعلقة بشهادة SSL إن أردنا توفير القابلية لاسترداد خادوم توزيع الحمل. سنضيف أيضا ملف إعداد HAProxy ضمن النسخ الاحتياطية. نضع - مثل ما فعلنا مع العناصر السابقة، ملخصا لخطة الاسترداد الخاصة بخادوم توزيع الحمل: اكتمل إعداد خطة الاسترداد لخادوم توزيع الحمل. يجب الآن التدرب على تنفيذ خطة الاسترداد، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية. اعتبارات أخرىإن تطلب استرداد أحد العناصر إعادة ضبط عنصر آخر (تغير عنوان IP الخاص بخادوم قاعدة البيانات مثلا)؛ فعليك التأكد من إدراج الخطوات الضرورية في خطط الاسترداد. ستحتاج أيضا لكتابة خطط استرداد للعناصر الأخرى المكوِّنة للتطبيق مثل خادوم النطاقات؛ وكذلك جميع العناصر التي يمكن أن تضيفها في المستقبل مثل خواديم النسخ الاحتياطي، المراقبة والسجلات. يجب، مع تطور إعداداتك، إعادة النظر في خطط الاستعادة الموجودة وإجراء التغييرات اللّازمة. لم نتطرق لحد الساعة إلى كيفية إنشاء ثم استعادة النسخ الاحتياطية؛ لذا سنحتاج للنظر في هذه التفاصيل لاحقا. سيكون النسخ الاحتياطي موضوع الجزء الموالي من هذا الدليل. خاتمةيجب الاحتفاظ بخطط الاستعادة الخاصة بالخواديم المختلفة في مكان آمن يمكن لمن أراد تنفيذ الخطوات الموجودة فيها الوصولُ إليه. احتفظ بها في مكان منفصل تماما عن بيئة العمل. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Recovery Planning لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

إنّ Redis هي عبارة عن ذاكرة مؤقتة cache بنمط مفتاح-قيمة key-value ومَخزَن في الذاكرة (أي قاعدة بيانات) والتي يمكن نقلها وحفظها بشكل دائم على القرص، سنشرح في هذا الدّرس كيفيّة النّسخ الاحتياطي لقاعدة بيانات Redis على خادوم Ubuntu. يتم حفظ بيانات Redis بشكل افتراضي إلى القرص في ملف rdb.، والذي هو لقطة snapshot لنقطة في الوقت المناسب لمجموعة بيانات Redis لدينا، يتم عمل اللقطة في فواصل مُحدّدة، ويكون هذا رائعًا من أجل النسخ الاحتياطيّة لدينا. المتطلبات الأساسيةسنحتاج لإكمال الخطوات في هذا الدّرس إلى: خادوم Ubuntu.تنصيب redis، تستطيع اتباع الإعداد الرئيسي master في هذا الدّرس لإعداد Redis (بالرغم من أنّه سيعمل بشكل جيّد مع عنقود تابع ومتبوع master-slave cluster).التحقق من أنّ خادوم Redis قيد التشغيل لدينا.إن تمّ تعيين كلمة سر لخادوم Redis -والذي ننصح به بشدّة- يكون ذلك مفيدًا، توجد كلمة السّر في ملف الإعدادات /etc/redis/redis.confالخطوة الأولى – إيجاد دليل بيانات Redisتقوم Redis بتخزين بياناتها إلى دليل على خادومنا، وهو ما نريده من أجل النّسخ الاحتياطي، نحتاج في البداية لمعرفة مكان هذا الدّليل. يوجد دليل قاعدة بيانات Redis في Ubuntu وتوزيعات لينِكس الأخرى في المسار var/lib/redis/، ولكن إن كُنّا ندير خادوم تم تغيير مكان بيانات Redis فيه، نستطيع تحديد مكانه بكتابة ما يلي: sudo locate *rdbوبإمكاننا بشكل بديل إيجاده عن طريق المُحث prompt الذي يُدعى redis-cli، ولفعل هذا نكتب ما يلي: redis-cliإن لم يكن خادوم Redis قيد التشغيل ستكون الاستجابة التي سنتلقاها هي: Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected>وفي هذه الحالة نقوم بتشغيل Redis وإعادة الاتصال باستخدام الأوامر التالية: sudo service redis-server startredis-cliسيتغير مُحث الـ Shell إلى: 127.0.0.1:6379>في الوقت الذي نكون متصلين فيه إلى Redis سيقوم الأمران التاليان بالاستيثاق authenticate معه والحصول على دليل البيانات: 127.0.0.1:6379> auth insert-redis-password-here 127.0.0.1:6379> 127.0.0.1:6379> config get dirيجب أن يكون خَرْج الأمر الأخير هو دليل بيانات Redis لدينا: 1) "dir" 2) "/var/lib/redis"نلاحظ دليل Redis لدينا فإن كان مختلفًا عن الدّليل الظاهر هنا فيجب أن نحرص على استعماله خلال هذا الدّرس. نستطيع الآن الخروج من واجهة سطر الأوامر لقاعدة البيانات: 127.0.0.1:6379> exitنتحقّق من أنّ هذا هو الدّليل الصحيح: ls /var/lib/redisينبغي أن نرى ملف dump.rdb وهو عبارة عن بيانات Redis، إن تمّ تمكين appendonly فسنرى ملف يُدعى appendonly.aof أو حتى أي ملف aof. آخر، والذي يحتوي على سجل لجميع عمليّات الكتابة التي تم تلقّيها بواسطة الخادوم. قم بقراءة هذا المنشور حول استمرار Redis persistence من أجل النقاش حول الاختلافات بين هذين الملفين. بشكل مُبسَّط فإنّ الملف rdb. هو اللقطة الحاليّة، والملف aof. يقوم بحفظ تاريخ Redis، وكلاهما يستحقّان أخذ نسخة احتياطيّة عنهما. سنبدأ فقط بالملف rdb. وننتهي بنسخة احتياطيّة تلقائيّة لكلا الملفين. الخطوة الثانية (اختيارية) – إضافة عينة sample بياناتسنقوم في هذا القسم بإنشاء عيّنة بيانات لتخزينها في قاعدة بيانات Redis، إن كنتَ تملك مٌسبقًا بيانات على خادومك تستطيع النسخ الاحتياطي للمحتوى الموجود حاليًّا. نقوم بتسجيل الدخول من خلال واجهة سطر الأوامر لقاعدة البيانات: redis-cliنقوم بالاستيثاق بكتابة ما يلي: 127.0.0.1:6379> auth insert-redis-password-hereفلنقم بإضافة عيّنة بيانات، يجب أن نتلقّى استجابة OK بعد كل خطوة. 127.0.0.1:6379> SET shapes:triangles "3 sides" 127.0.0.1:6379> 127.0.0.1:6379> SET shapes:squares "4 sides"نتأكّد من أنّه تمّت إضافة البيانات: 127.0.0.1:6379> GET shapes:triangles 127.0.0.1:6379> 127.0.0.1:6379> GET shapes:squaresوهذا هو الخَرْج output الذي يجب أن نحصل عليه: "3 sides" "4 sides"ولفرض هذه التغييرات على الملف var/lib/redis/dump.rdb/ نقوم بحفظهم: 127.0.0.1:6379> saveنستطيع الآن الخروج: 127.0.0.1:6379> exitبإمكاننا الآن إن كُنّا نرغب التّحقّق من محتويات الملف dump، يجب أن يحتوي على بياناتنا ولو أنّها في شكل مناسب للآلة أكثر: sudo cat /var/lib/redis/dump.rdb REDIS0006?shapes:squares4 sidesshapes:triangles3 sides??o????Cالخطوة الثالثة – النسخ الاحتياطي لبيانات Redisحان الوقت الآن لعمل نسخة احتياطيّة بعد أن أصبحنا نعلم مكان تواجد بيانات Redis لدينا، نجد هذا الاقتباس من موقع Redis الرّسمي: إذًا نستطيع النسخ الاحتياطي أو نسخ ملف قاعدة البيانات أثناء تشغيل خادوم Redis، وعلى افتراض أنّنا نريد النسخ الاحتياطي لها إلى دليل داخل الدّليل الرئيسي لدينا فإنّ القيام بالنسخ الاحتياطي بسيط بكتابة ما يلي: sudo cp /var/lib/redis/dump.rdb /home/sammy/redis-backup-001يحفظ Redis المحتوى هنا بشكل دوري، ممّا يعني أنّ الأمر السابق غير مضمون بالنسبة لنا وأنّنا لا نملك أحدث نسخة احتياطيّة حتى الدقيقة الأخيرة إن كان كل ما نقوم به هو تشغيل هذا الأمر، نحتاج لحفظ البيانات الخاصّة بنا أولًا. ومع ذلك إن كان من المقبول فقدان كمية صغيرة من البيانات فإنّ النّسخ الاحتياطي لهذا الملف فقط سيعمل بشكل جيّد. حفظ حالة قاعدة البياناتللحصول على نسخة أحدث بكثير من بيانات Redis فمن الأفضل النفاذ إلى redis-cli، سطر أوامر Redis. نقوم بالاستيثاق كما شرحنا في الخطوة الأولى. ثمّ نكتب الأمر حفظ save كما يلي: 127.0.0.1:6379> saveينبغي أن يكون الخَرْج مُشابِهًا لهذا: OK (1.08s)نخرج من قاعدة البيانات. نستطيع الآن تشغيل الأمر cp السّابق واثقين من أنّ النسّخة الاحتياطيّة هي أحدث نسخة حتى الآن بشكل كامل. بينما يُزوِّدنا الأمر cp بنسخة احتياطيّة مرّة واحدة من قاعدة البيانات، فإنّ الحل الأنسب هو إعداد وظيفة cron تقوم بأتمتة هذه العمليّة، واستخدام أداة تستطيع تنفيذ تحديثات تزايديّة incremental updates وتستعيد البيانات إن احتجنا لذلك. الخطوة الرابعة – إعداد التحديثات التلقائية باستخدام rdiff-backup وCronسنقوم في هذا القسم بإعداد نسخ احتياطي تلقائي يشمل كامل دليل بيانات Redis لدينا، بما في ذلك كلا ملفي البيانات. توجد العديد من أدوات النسخ الاحتياطي التلقائي المتاحة، سنستخدم أداة جديدة وسهلة الاستخدام تُدعى rdiff-backup. إنّ rdiff-backup هي أداة نسخ احتياطي تعمل عبر سطر الأوامر، من المحتمل أنّ rdiff-backup غير مُثبَّتة على خادومك، لذا يجب عليك تثبيتها أولًا: sudo apt-get install -y rdiff-backupنستطيع الآن بعد تثبيتها أن نختبرها بالنسخ الاحتياطي لبيانات Redis لدينا إلى مجلّد في دليلنا الرئيسي، سنفترض في هذا المثال أنّ الدليل الرئيسي لدينا هو home/sammy/. نلاحظ أنّ الدليل الهدف سيتم إنشاؤه من قبل الـ script إن لم يكن موجودًا، أي بمعنى آخر لا نحتاج إنشاءه بأنفسنا. ومع وجود preserve-numerical-ids-- ستكون الملكيّات نفسها للمجلدات المصدر والوجهة. sudo rdiff-backup --preserve-numerical-ids /var/lib/redis /home/sammy/redisوكما وجدنا مع الأمر cp سابقًا فإنّ هذه نسخة احتياطيّة لمرّة واحدة، ولكنّ الذي تغيّر هو أنّنا نقوم الآن بالنسخ الاحتياطي لكامل الدليل var/lib/redis/ وباستخدام rdiff-backup. سنقوم الآن بأتمتة النّسخ الاحتياطي باستخدام cron بحيث تحدث النسخة الاحتياطيّة في وقت مُحدّد، ولإنجاز هذا نفتح crontab النّظام: sudo crontab -e(إن لم تستخدم crontab على هذا الخادوم من قبل قم باختيار مُحرّر النّصوص المفضل لديك عند سؤالك عنه.) نقوم بإضافة المُدخَل entry التالي في نهاية الملف: 0 0 * * * rdiff-backup --preserve-numerical-ids --no-file-statistics /var/lib/redis /home/sammy/redisسيقوم مُدخَل Cron هذا بعمل نسخة احتياطيّة لـ Redis يوميًّا عند منتصف الليل، سيعطّل التحوّل no-file-statistics-- الكتابة إلى الملف file_statistics في الدّليل rdiff-backup-data، والذي يجعل من rdiff-backup يعمل بشكل أسرع أكثر ويستخدم مساحة قرص أقل بقليل. ونستطيع بشكل بديل استخدام هذا المُدخَل للقيام بنسخ احتياطي يومي: @daily rdiff-backup --preserve-numerical-ids --no-file-statistics /var/lib/redis /home/sammy/redisوكما هو مذكور سيتم عمل نسخة احتياطيّة مرّة في اليوم، لذا بإمكانك العودة غدًا من أجل اختباره لآخر مرّة، أو تستطيع بشكل مؤقّت زيادة وتيرة النّسخ الاحتياطي لكي تتأكّد من أنّه يعمل. ولأنّ الملفّات مملوكة من قبل مستخدم النّظام redis نستطيع التحقّق من أنّها في مكانها باستخدام هذا الأمر.(تأكّد من الانتظار إلى أن يتم تحفيز بدء النسخ الاحتياطي): ls -l /home/sammy/redisينبغي أن يبدو الخَرْج مُشابِهًا لما يلي: total 20 -rw-rw---- 1 redis redis 70 Sep 14 13:13 dump.rdb drwx------ 3 root root 12288 Sep 14 13:49 rdiff-backup-data -rw-r----- 1 redis redis 119 Sep 14 13:09 redis-staging-ao.aofنمتلك الآن نُسَخ احتياطيّة يوميّة لبيانات Redis لدينا مُخزَّنة في الدّليل الرئيسي على نفس الخادوم. الخاتمةإنّ النّسخ الاحتياطي لبيانات Redis بالطرق المذكورة في هذا الدّرس جيّد عندما لا نمانع من النّسخ الاحتياطي للبيانات إلى دليل على نفس الخادوم. يبقى النهج الأكثر أمانًا بالطّبع هو النّسخ الاحتياطي إلى جهاز آخر، تستطيع استكشاف المزيد من خيارات النسخ الاحتياطي بقراءة هذا الدّرس حول النُسَخ الاحتياطيّة: كيفية اختيار استراتيجية فعالة للنسخ الاحتياطي للخادوم الخاص الافتراضي VPS. نستطيع استخدام العديد من طرق النّسخ الاحتياطي هذه مع نفس الملفّات في الدّليل var/lib/redi/. ترجمة -وبتصرّف- لـ How To Back Up Your Redis Data on Ubuntu 14.04 لصاحبه finid.

ما هي MySQL؟MySQL هي عبارة عن أداة إدارة قواعد بيانات شهيرة تستخدم لغة استعلامات SQL للوصول إلى البيانات والتعامل معها، يمكن استخدامها بسهولة لإدارة البيانات ضمن المواقع أو تطبيقات الويب. عمليات النسخ الاحتياطي مهمة جدًا لأي نوع من البيانات، وهذا مرتبط بشدّة عندما نتحدث عن قواعد البيانات. يمكن نسخ قواعد بيانات MySQL احتياطيا بواسطة عدة طرق سنشرحها في هذا الدرس. سنستخدم خادوم Ubuntu 12.04 مع MySQL 5.5 في شرحنا هذا. تأتي معظم توزيعات لينكس بإصداراتٍ حديثة من MySQL ويجب ألّا تواجه صعوبةً في تطبيق نفس المهام بطريقةٍ مشابهة على تلك التوزيعات. نسخ قاعدة بيانات MySQL باستخدام mysqldumpواحدة من أكثر الطرق شيوعا لعمل النسخ الاحتياطي لقاعدة بيانات MySQL هي استخدام أمرٍ يدعى "mysqldump". النسخ الاحتياطيالشكل الأساسي للأمر هو: mysqldump -u username -p database_to_backup > backup_name.sqlالاستعادةلاستعادة نسخة قاعدة بيانات MySQL مصنوعة بـmysqldump، يمكنك ببساطة إعادة توجيه الملفّ إلى MySQL مرةً أخرى. نحتاج إنشاء قاعدة بيانات فارغة لاستضافة البيانات التي سنقوم باستيرادها مجددًا. أوّلًا، قم بالولوج إلى MySQL عبر كتابة: mysql -u username -pأنشئ قاعدة بيانات جديدة الآن - والتي ستحوي جميع البيانات الموجودة في نسخة قاعدة البيانات التي قمت بنسخها مسبقًا - ومن ثمَّ، قم بالخروج: CREATE DATABASE database_name; exitالآن، يمكننا إعادة توجيه ملفّ النسخة إلى قاعدة البيانات الجديدة التي قمنا بإنشائها مسبقًا عبر استخدام الأمر: mysql -u username -p database_name < backup_name.sqlيجب أن يتم استعادة بياناتك الآن إلى قاعدة البيانات الجديدة التي أنشئتها. نسخ جدول MySQL احتياطيا إلى ملف نصييمكنك تصدير البيانات من جدول ما مباشرة إلى ملف نصي عبر استخدام جملة SELECT مع MySQL. الشكل الأساسي للعملية هو: SELECT * INTO OUTFILE 'table_backup_file' FROM name_of_table;ستقوم هذه العملية بحفظ بيانات الجدول إلى الملف النصي المطلوب. وسيفشل في حال كان هناك اسم ملف آخر موجود بنفس المسار الذي قررت حفظ الملف إليه. ملاحظة: يقوم هذا الخيار بحفظ بيانات الجدول فقط. إذا كانت بنية جدولك معقّدة ويجب حفظها كما هي، فالأفضل أن تستخدم طريقةً أخرى. نسخ معلومات MySQL احتياطيا باستخدام automysqlbackupهناك برنامج أداة يدعى "automysqlbackup" متوفّر في مستودعات توزيعة أوبونتو الرسمية. يمكن أن يتم جدولة هذه الأداة يدويا للقيام بعمليات النسخ الاحتياطي بأوقات محددة. لتثبيت هذا البرنامج، طبق الأمر التالي في الطرفية: sudo apt-get install automysqlbackupوقم بتشغيله عبر الأمر: sudo automysqlbackupستجد ملف الإعدادات الرئيسي لـautomysqlbackup في المسار "etc/default/automysqlbackup/". افتحه بصلاحيات الجذر: sudo nano /etc/default/automysqlbackupيمكنك أن ترى أن هذا الملف يقوم افتراضيا بتعيين العديد من المتغيرات باستخدام ملف MySQL الموجود في المسار "etc/mysql/debian.cnf/". وهو يقوم بقراءة اسم المستخدم وكلمة المرور وقواعد البيانات التي يجب نسخها احتياطيًا من هذا الملفّ. المسار الافتراضي للنُسَخ الاحتياطية هو “/var/lib/automysqlbackup”. ابحث عن هذا المسار لترى بنية النُسَخ الاحتياطية: ls /var/lib/automysqlbackup daily monthly weeklyإذا نظرنا إلى مجلد "daily"، فإنّه يمكننا أن نرى مجلدا فرعيًا داخله لكل قاعدة بيانات، حيث يكون بداخلها أيضًا ملفات النُسَخ الاحتياطية لقاعدة البيانات مضغوطة بصيغة gzip. استخدم الأمر التالي لترى محتويات ذاك المسار: .: database_name information_schema performance_schema ./database_name: database_name_2013-08-27_23h30m.Tuesday.sql.gz ./information_schema: information_schema_2013-08-27_23h30m.Tuesday.sql.gz ./performance_schema: performance_schema_2013-08-27_23h30m.Tuesday.sql.gzتقوم Ubuntu بتثبيت سكربت cron مع هذا البرنامج لتشغيله كل يوم. سيقوم تلقائيًا بتنظيم الملفات إلى مسارها الصحيح. كيفية النسخ الاحتياطي عند استخدام النسخ المتماثلمن الممكن استخدام النسخ المتماثل (Replication) في MySQL لعمل نسخة احتياطية عن البيانات مع الطرق المذكورة أعلاه كذلك. النسخ المتماثل هو عملية تمرير البيانات من خادومٍ إلى آخر (من رئيسي إلى فرعي) أو تمرير التغييرات من خادومٍ رئيسي إلى خادومٍ رئيسيٍ آخر. صحيح أن النسخ المتماثل يسمح بتمرير البيانات وحفظها، إلا أنه يعاني عندما تحاول حفظ البيانات من نقطة معينة من الزمان. هذا بسبب أن عملية النسخ المتماثل تحصل بشكل مستمر لتنسخ التغييرات الجديدة التي يتم إجراؤها على النظام. لتفادي هذه المشكلة يمكننا: تعطيل النسخ المتماثل مؤقتًا. جعل آلة النسخ الاحتياطي قابلة للقراءة فقط مؤقتًا.تعطيل النسخ المتماثل مؤقتايمكنك تعطيل النسخ المتماثل للخادوم الفرعي مؤقتًا عبر تنفيذ: mysqladmin -u user_name -p stop-slaveخيار آخر يمكنك استخدامه ولا يقوم بتعطيل عملية النسخ المتماثل بالكامل، بل يضعها بوضع الإيقاف المؤقت، هو تطبيق: mysql -u user_name -p -e 'STOP SLAVE SQL_THREAD;بعد إيقاف عملية النسخ المتماثل مؤقتًا، يمكنك القيام بعملية النسخ الاحتياطي باستخدام أحد الطرق المذكورة مسبقًا. يسمح لك هذا بإبقاء قاعدة البيانات الرئيسية نشطة بينما يتم نسخ قاعدة البيانات الفرعية. عندما يكتمل هذا، قم بإعادة تفعيل النسخ المتماثل عبر: mysqladmin -u user_name -p start-slaveجعل آلة النسخ الاحتياطي قابلة للقراءة فقط مؤقتايمكنك أيضًا أن تحافظ على البيانات على الخادوم عبر جعلها قابلة للقراءة فقط. يمكنك تنفيذ هذه الخطوات سواء كان على الخادوم الرئيسي (Master) أو الفرعي (Slave). أولا، قم بالولوج إلى MySQL بالصلاحيات اللازمة للقيام بذلك: mysql -u root -pالآن، يمكننا كتابة جميع التغييرات المحفوظة إلى القرص وجعل النظام قابلًا للقراءة فقط (read-only) عبر كتابة: FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON;الآن، قم بعمل النسخ الاحتياطي باستخدام mysqludump. بمجرّد اكتمال عملية النسخ الاحتياطي، قم بإعادة النظام إلى وضعه الأصلي عبر كتابة: SET GLOBAL read_only = OFF; UNLOCK TABLES; ملاحظة عن الطرق التي لم تعد مستحسنةmysqlhotcopyتتضمن MySQL سكربتا مكتوبا بلغة Perl لنسخ قواعد البيانات احتياطيا بسرعة ويدعى "mysqlhotcopy". يمكن أن يتم استخدام هذه الأداة للقيام بنسخ قاعدة البيانات بسرعة على الآلة المحلّية، ولكنها تمتلك بعض التقييدات التي تجعلنا نتجنبها. السبب الأهم الذي جعلنا لا نستخدمها هو أنها فقط تعمل مع البيانات التي تم تخزينها باستخدام محركات التخزين "MyISAM" و"Stroage" فقط. معظم المستخدمين لا يقومون بتغيير المحرك الافتراضي للتخزين، وبدءً من الإصدار 5.5 من MySQL فإن المحرك الافتراضي هو "InnoDB". لهذا لا يمكن استخدام هذه الأداة لأنها لا تتوافق مع المحرك. مشكلة أخرى مع هذا السكربت هو أنه يمكن تشغيله فقط على الآلة التي يتم تخزين قاعدة البيانات عليها. يمنعك هذا من القيام بعمليات النسخ الاحتياطي باستخدام آلة بعيدة (remote machine)، والذي يمكنه أن يكون مشكلة حقيقية في بعض الأحيان. نسخ ملفات الجداولطريقة أخرى تقتَرح بعض الأحيان هي القيام بنسخ الجداول التي تقوم MySQL بوضع البيانات فيها ببساطة ونقلها إلى مكان آخر. تعاني هذه الطريقة من نفس مشكلة "mysqlhotcopy". قد يكون منطقيًا استخدام هذه الطريقة مع المحرّكات التي تقوم بتخزين بياناتها على شكل ملفات، إلا أن InnoDB (وهو المحرك الافتراضي الجديد لـMySQL) لا يمكن نسخ قواعد البيانات الخاصة به بهذه الطريقة. الخاتمةهناك العديد من الطرق لإجراء عمليات النسخ الاحتياطي لقواعد بيانات MySQL، جميعها يمتلك نقاط قوة وضعف، ولكن بعضها أسهل للمستخدم وأفضل للتطبيق من غيرها. ستعتمد طريقة عملية النسخ الاحتياطي التي ستستخدمها بشكل رئيسي على احتياجاتك ومواردك، بالإضافة إلى بيئة العمل الخاصة بك. مهما كانت الطريقة التي تعتمد عليها، كن متأكدا من التحقق من النُسَخ الاحتياطية الخاصّة بك وحاول استرجاعها للتأكد من الأمر، لتكون متأكدا من أنها لا تحوي أي مشاكل. ترجمة -وبتصرف- للمقال How to Backup MySQL Databases on an Ubuntu VPS لصاحبه Justin Ellingwood.