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

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

قد تتفاجأ ببعض المشاكل في عرض الصور بعد تثبيت شهادة SSL على مدونة ووردبريس. لا تقلق، ما عليك إلا أن تتابع قراءة هذا الموضوع لتتعرف على كيفية حل هذه المشكلة. عند تثبيت شهادة SSL على موقعك، يتغير عنوان موقعك بشكل طفيف، يسبب هذا التغيير حتى وإن كان بسيطا في الإضرار ببعض عناصر موقعك، الأمر الذي ينتج عن الاختلاف بين عنوان URL الذي تمت برمجة الموقع لاستخدامه وعنوان URL القديم الذي تستخدمه بعض عناصر المحتوى كالصور مثلا، أي أنه بعد تثبيت شهادة SSL يتم نقل كل المحتوى إلى عنوان https في حين لا تزال الصور تشير إلى عنوان http. يتجلى الحل إذن في ضرورة تغيير روابط كل الصور واستبدال http بـhttps ، ما يبدو أمرا شاقا للغاية. من حسن الحظ أنك لن تحتاج إلى تغيير روابط كل الصور التي سبق أن رفعتها واحدة تلو الأخرى. تبقى إمكانية التغيير اليدوي في قاعدة البيانات أمرا متاحا كما يمكنك اتباع الطريقة الأسهل والأكثر أمانا من خلال استخدام ملحق. إن واجهتك مشاكل في عمل الصور بعد تحديث موقعك باستخدام عنوان URL آمن جديد، تابع القراءة لتتعرف على كيفية القيام بالتغييرات الضرورية بشكل يدوي في قاعدة البيانات ولتطلع أيضا على الملحقات التي يمكن أن تستخدمها كحل بديل يتميز بالأمان وسرعة الاستخدام. البحث والاستبدال اليدويان باستخدام استعلامات قاعدة البيانات من الممكن القيام بتغيير روابط الصور بشكل يدوي في قاعدة البيانات. حتى نكون أكثر وضوحا: تجدر الإشارة إلى مدى سهولة ارتكابك للأخطاء أثناء القيام بذلك والإضرار بموقعك. سنتطرق لطريقة الاستبدال اليدوي لنشمل جميع الطُرق المُمكنة فقط رغم المخاطر التي ترافق القيام بالعملية. نظرًا لاحتمال ارتكابك لأخطاء أنصح باستعمال ملحق موثوق لتجنّب أيّة مشاكل قد تنتج عن التّعديل اليدوي. يعتبر عمل نسخة احتياطية (backup) لموقعك قبل القيام بأي تغيير كتعديل روابط الصور أمرا جيدا. يمكنك الإطلاع على المقال يفية نقل مواقع ووردبريس بسهولة باستخدام Snapshot في أكاديمية حسوب. بناء على ما سبق، إن وجدت نفسك في حالة نادرة تتطلب منك البحث في قاعدة البيانات لإيجاد روابط بعض الصور المعطلة، يمكنك القيام بذلك من خلال البحث في قاعدة البيانات بالطّريقة التّالية: سجل دخولك إلى phpMyAdmin، اضغط على قاعدة بيانات موقعك المدرجة في القائمة على اليسار ثم اضغط على تبويب Query. في استعلام SQL في خانة قاعدة البيانات أسفل الصفحة، أدخل الاستعلام التالي، ثم اضغط على GO: UPDATE wp_posts SET `post_content` = REPLACE (`post_content`, 'src="http://www.your-site.com', 'src="https://www.your-site.com'); تأكد من تحديث www.your-site.com إلى اسم نطاق موقعك الصحيح، ثم قم بتغيير البادئة النصية للجدول wp الخاصة ب wp_posts إذا لم تكن تستخدم البادئة الافتراضية وسبق لك أن قمت بتغييرها سابقا. إن كنت تستخدم نسخة ووردبريس متعددة المواقع ، تأكد من استخدام هذا الاستعلام لاحقا إن أردت أن تحدث الصور: UPDATE wp_2_posts SET `post_content` = REPLACE (`post_content`, 'src="http://www.your-site.com', 'src="https://www.your-site.com'); قم بتغيير 2 المتواجدة في wp_2_posts ليوافق رقم التعريف (ID) الصحيح لموقعك عند مطابقته مع مواقعك الفرعية، يجب عليك أن تستخدم هذا الاستعلام لكل المواقع في شبكتك. من المحتمل أن لا يكون ذلك ضروريا دائما، لكن إن كانت شبكتك معدة لاستخدام المجلدات الفرعية (sub-directories) ولم تكن مواقعك مجهزة لاستخدام نطاقات مختلفة قد تجد نفسك أمام ضرورة تغيير روابط صورك. يجب أن تستخدم الاستعلام أسفله لتحديث GUID الخاص بالصور المدرجة كمرفقات (attachments): UPDATE wp_posts SET `guid` = REPLACE (`guid`, 'http://www.your-site.com', 'https://www.your-site.com') WHERE post_type = 'attachment'; على غرار المثال الأول، يجب تغيير النطاق برابط URL الحالي وتغيير table prefix إن لم تكن تستخدم الإعداد الافتراضي. من المحتمل أن تحتاج استخدام هذا الاستعلام بالنسبة لكل المواقع على شبكتك: UPDATE wp_2_posts SET `guid` = REPLACE (`guid`, 'http://www.your-site.com', 'https://www.your-site.com') WHERE post_type = 'attachment'; لا تنس تغيير 2 المتواجدة في wp_2_posts برقم التعريف (ID number) الخاص بالمواقع في شبكتك. بعد القيام بما أسلفنا الذكر، من المفترض أن يتم تحديث كل الصور لتستخدم العنوان URL الجديد الذي (الذي يستخدم https)، إن لم ينجح الأمر في المرة الأولى كرر المحاولة فقد يكون ذلك مجديا. يساعد عدم استخدام كل الاستعلامات دفعة واحدة بل كل استعلام على حدة في نجاح هذه الطريقة. البحث عن روابط الصور واستبدالها باستخدام الملحقات يعتبر البحث عن روابط كل الصور واستبدالها باستخدام ملحق ما أكثر سهولة من القيام بذلك يدويا وأقل عرضة لارتكاب خطأ يؤدي إلى إيقاف موقعك. رغم ذلك، يبقى من المحتمل أن ترتكب خطأ ما، لذا يجب عليك أن تتأكد مرتين من كل ما تقوم بكتابته. يتم تحديث كل الملحقات التي سنتطرق لها بشكل تلقائي، لا تقلق فلن تستخدم ملحقا سرعان ما سيتجاوزه الزمن. في حين لا تتمتع كل هذه الملحقات بإمكانية العمل على المواقع المتعددة (Multisite) فإنها تفي بالغرض عند تفعيلها على كل موقع على حدة. بغض النظر عن أي هذه الخيارات ستقرر استخدامه نؤكد لك أنها كلها ذات جودة عالية كفيلة بإتمام العمل على أكمل وجه. Better Search Replace يتميز ملحق Better Search Replace على وجه الخصوص بتوفره على خاصية دعم المواقع المتعددة (Multisite)، فضلا عن بساطة تصميمه، يتوفر هذا الملحق على عدد محدود من الخصائص والإعدادات الضرورية التي لا يحتاج جُلُّ المستخدمين غيرَها. من أجل تثبيت هذا الملحق ببساطة، ما عليك إلا أن تتوفر على نسخة على ووردبريس منصبة، تعتبر إمكانية القيام بمعاينة تجريبية لترى أي الجداول تتأثر بالخيارات التي تحددها قبل تطبيقها فعليا من أفضل خاصيات Better Search Replace، تضمن لك هذه الخاصية احتماليةً أقل لاقتراف أي خطأ، ما يجعل منها أداة قَيِّمَةً للغاية. Search and Replace فضلا عن استبدال روابط الصور على موقعك، يمكن لملحق Search and Replace أن يقوم بالكثير من الأمور الأخرى، كتغيير عنوان URL ونطاق الموقع، عمل نسخة احتياطية لقاعدة بياناتك واستعادتها، إضافة إلى تغيير القيمة الافتراضية wp في table prefixes. يستطيع هذا الملحق القيام بمحاكاة للتغييرات التي تقترحها قبل تطبيقها فعليا، يكون ارتكاب الخطأ أقل احتمالا عند توافر إمكانية معاينة نتائج التغييرات دون القلق حول تطبيقها ثم إلغائها. يتطلب هذا الملحق استخدام نسخة 5.4 أو أحدث من PHP، يتم تثبيت Search and Replace بنفس سهولة أي ملحق آخر دون أي خطوات إضافية كما يتضمن أيضا دعم المواقع المتعددة (Multisite). WP Migrate DB يُستخدم WP Migrate DB عادة لتهجير (migration) المواقع، لكن يمكنك استخدامه أيضا للبحث عن الروابط القديمة لصورك وتغييرها، يتميز هذا الملحق بقدرته على تهجير موقع مطور محليا (locally developed) إلى استضافة مباشرة (live setup). يتميز هذا الملحق بسهولة الاستخدام فضلا عن عدم اشتراط أي متطلبات للتشغيل، رغم عدم أخذ الكثيرين لهذا الملحق بعين الاعتبار من أجل استبدال روابط الصور فإنه يبقى الخيار الأول للعديد من مستخدمي ووردبريس. خلاصة قد تسبب الصور بعض التعقيدات عند إضافة شهادة SSL إلى موقعك، حتى بعد تحديث عنوان URL الخاص بموقعك فإن الصور تبقى معطلة. يبقى الحل الوحيد هو قيامك بتحديث روابط الصور بنفسك ما يصبح عملية سهلة باستخدام أحد الملحقات المقدمة في هذا الموضوع. هل تمكنت من تغيير روابط صورك بنجاح؟ أي الملحقات استخدمت أو أيها تفضل؟ هل تفضل ملحقا آخر غير تلك التي أدرجنا في هذا الموضوع؟ تفضل بمشاركتنا تجربتك في التعليقات أسفله. ترجمة -وبتصرف- للمقال: Replacing Image Links in WordPress After Installing an SSL Certificate لكاتبته: JENNI MCKINNON.

سنكمل في هذا المقال من سلسلة المقالات حول التعامل مع ويندوز 10 ما بدأناه في المقال السابق حول إجراء النسخ الاحتياطي في ويندوز 10. حيث سنعمل على استعادة النسخ الاحتياطي لكل نوع من الأنواع التي تعاملنا معها. استعادة النسخ الاحتياطي القياسي للملفات في ويندوز 10 انقر زر ابدأ ثم انقر زر الاعدادات الموجود فوق زر الطاقة مباشرةً: ستظهر أمامك نافذة الاعدادات. اختر منها "التحديث والأمان" لتظهر النافذة المسؤولة عن جميع مزايا التحديث والأمان. اختر من القائمة الموجودة في الطرف الأيمن "النسخ الاحتياطي" لتظهر محتويات النسخ الاحتياطي كما في الشكل التالي: صِل القرص الصلب الخارجي الذي استخدمته لعمليّة النسخ الاحتياطي، في حال استخدمت قرصًا صلبًا خارجيًا، أمّا في حال كنت قد استخدمت قرصًا داخليًا، فيمكنك أن تنقر مباشرةً على "خيارات أكثر" ثم تستخدم شريط التمرير للانتقال إلى أسفل النافذة ليظهر لك شكل شبيه بما يلي: انقر على "استعادة الملفات من النسخة الاحتياطية الحالية" لتظهر لك نافذة شبيهة بما يلي: يظهر في الشكل السابق المجلّدات التي أجريت لها نسخًا احتياطيًّا بالأسلوب القياسي من قبل. يمكنك نقر الزر الأخضر الموجود في الوسط لتبدأ عملية الاستعادة للملفات. قد تظهر لك رسالة تفيد بأنّه يوجد تشابه بأسماء الملفات، حيث سيعرض عليك خيارات تشتمل على الكتابة فوق الملفات القديمة. اختر منها ما يناسبك. وبعد الانتهاء أغلق نافذة الاسترداد. استعادة النسخ الاحتياطي الشامل (استعادة صورة القرص الصلب) سنعمل في هذه الحالة على استرداد صورة القرص الصلب كاملةً. سيؤدي ذلك إلى إرجاع القرص الصلب للحاسوب إلى الحالة التي كان عليها عند إجراء النسخ الاحتياطي. ويجب الانتباه إلى أنّ هذه العمليّة ستؤدّي إلى إزالة أيّ ملفات جديدة أُحدثَت بعد النسخ الاحتياطي، أو حتى أي تعديلات أو برمجيّات تمّ تثبيتها على نظام التشغيل. لإجراء عملية الاستعادة سنحتاج إلى إعادة تشغيل الحاسوب. انقر زر ابدأ ثم انقر أيقونة الطاقة لتظهر لك قائمة صغيرة. اضغط المفتاح Shift من لوحة المفاتيح، ثم انقر على خيار "إعادة التشغيل". سيؤدّي ذلك إلى إعادة تشغيل الحاسوب مع الدخول في طور الصيانة. انظر إلى الشكل الذي حصلت عليه بعد إعادة التشغيل: انقر الخيار "استكشاف الأخطاء وإصلاحها" لتظهر لك نافذة شبيهة بما يلي: اختر من هذه النافذة الخيار "خيارات متقدّمة" لتحصل على نافذة جديدة شبيهة بما يلي: اختر الآن "استرداد صورة النظام" لتصل إلى النافذة التالية: لاحظ هنا أنّ معالج الاسترداد سيطلب منك تسجيل الدخول إلى الحساب المرتبط بنظام التشغيل الحالي الموجود على الحاسوب، وذلك نظرًا للضرورة الأمنيّة التي تتمثّل في منع الأشخاص غير المخوّل لهم بإجراء هذه العمليّة الحسّاسة. انقر على الحساب الخاص بك، واكتب كلمة المرور، ثم انقر زر متابعة لتحصل على النافذة التالية: تخبرنا هذه النافذة عن مكان تواجد أحدث نسخة احتياطيّة متوفّرة (يجب أن يكون القرص الصلب الخارجي الذي يحتوي على النسخ الاحتياطي موصولًا قبل الوصول إلى هذه النافذة). انقر زر "Next" لتصل إلى النافذة التالية: انقر زر "Next" من جديد لتصل إلى النافذة الأخيرة التي تخبرنا بما سيحدث عند البدء بعمليّة الاستعادة، حيث تحذرنا هذه النافذة أنّه في حال حدثت مقاطعة لعمليّة الاستعادة، كأن يتوقف تشغيل الحاسوب مثلًا فمن الممكن حدوث مشكلة بنظام التشغيل. انقر زر "Finish" ليعرض لك رسالة تأكيد، اختر منها "نعم" لتبدأ عملية الاستعادة التي قد تأخذ بعض الوقت. عند الانتهاء سيعمل نظام ويندوز 10 بشكل طبيعي وينقلك إلى شاشة تسجيل الدخول. لقد عاد القرص الصلب كما في اللحظة التي تمّ فيها إنشاء النسخة الاحتياطية الشاملة. استرداد نقطة استعادة لنظام التشغيل سنعمل على استرداد حالة نظام التشغيل وفقًا لنقطة استعادة قديمة كنت قد أنشأتها من قبل. انتقل إلى لوحة التحكّم، ومنها اختر "النظام" لتظهر لك النافذة التالية: اختر من القائمة الموجودة في الجهة اليمنى "إعدادات النظام المتقدّمة" لتظهر لك النافذة الموافقة. اختر لسان التبويب "حماية النظام" من الأعلى لتحصل على شكل شبيه بما يلي: انفر زر "استعادة النظام" ليبدأ معالج الاستعادة كما في الشكل التالي: انقر زر التالي لتحصل على النافذة التي تحتوي على نقاط الاستعادة المتوفرة على حاسوبك. اختر نقطة الاستعادة المرغوبة ثم انقر زر "التالي". لتصل إلى النافذة التي ستخبرك بملخص العمل الذي سيتم إنجازه. انقر زر "إنهاء"، سيعرض معالج الاسترداد رسالة تأكيد. وافق عليها لتبدأ عملية الاسترداد التي قد تتطلّب بعض الوقت أيضًا. الخلاصة تعرّفنا في هذا المقال على كيفيّة استرداد أشكال النسخ الاحتياطي التي يدعمها ويندوز 10 والتي تعرّفنا عليها في مقال سابق. ربما قد تكون قد لاحظت اختلاف وتنوّع طرق الاستعادة بحسب نوع النسخ الاحتياطي الذي أجريناه. قد تكون بعض هذه الطرق تتطلّب إجراءات متعدّدة، ووقت كبير نسبيًّا لإتمام عمليّة الاستعادة، إلّا أنّ المستخدم لن يحتاج إلى مثل هذه العمليّة إلًّا نادرًا.

سنتحدّث في هذا المقال من سلسلة المقالات حول التعامل مع ويندوز 10 عن النسخ الاحتياطي في ويندوز 10 وأنواعه ومميزاته. مما لا شك فيه أنّنا جميعًا نحتاج إلى إجراء نوع من النسخ الاحتياطي للبيانات التي نمتلكها. تتنوّع البيانات التي بحوزتنا، من مجرّد ملفات عامّة كالصور والمستندات سواءً الشخصيّة أو تلك المتعلّقة بالعمل. أو البرمجيّات والاعدادات الخاصة بنظام التشغيل. قد يؤدّي فقدان الملفات سواءً الشخصيّة أن تلك المتعلّقة بالعمل إلى أضرار كبيرة وربما يكون من الصعب جدًّا تلافيها، أمّا البرمجيّات والاعدادات الخاصة بنظام التشغيل فقد يؤدّي فقدانها بسبب مشكلة أو طارئ أصاب نظام التشغيل إلى خسارة وقت وجهد كبيرين في محاولة إعادة تنصيب البرمجيّات وضبط اعدادات نظام التشغيل من جديد. توجد لدينا بعض الحلول الفعّالة للمشاكل السابقة. فلحل مشكلة النسخ الاحتياطي للبيانات من ملفات ومستندات فمن الممكن استخدام أحد الأسلوبين التاليين: خدمات التخزين السحابيّة. من بين هذه الخدمات خدمة OneDrive التابعة لمايكروسوفت والتي تحدثنا عنها في مقال سابق. والتي يمكنها حل مشكلة حفظ البيانات بصورة آمنة، واستخدامها من خلال أكثر من جهاز بما فيها أجهزة أندرويد وiPhone، أو حتى مشاركتها مع الآخرين. ميزة خدمة OneDrive الأساسيّة هي في تكاملها مع نظام التشغيل ويندوز 10، وبصورة أدق مع حساب مايكروسوفت الذي تمتلكه. استخدام ميزة النسخ الاحتياطي للملفات، وهي مدعومة من قبل ويندوز 10. وفيه يعمل ويندوز 10 على أخذ نسخ احتياطي محلّي للملفات لكامل القرص الصلب، أو ضمن قسم أو مجلّد محدّد ضمنه. ستحتاج للاستفادة من هذه الميزة إلى وجود قرص صلب خارجي، أو قرص صلب داخلي مستقل (ومن الممكن استخدام الشبكة المحليّة لإجراء نسخ على خادوم مخصّص). أمّا بالنسبة لمشكلة النسخ الاحتياطي للإعدادات والبرمجيّات الخاصة بنظام التشغيل، فيوجد أسلوبين منفصلين أيضًا: الأسلوب الأوّل قديم مازال مدعومًا في ويندوز 10 وهو إنشاء صورة image شاملة عن القرص الصلب يمكن الرجوع إليها مستقبلًا، مما يسمح بإعادة القرص الصلب بكل ما يحتويه مطابقًا للحظة التي أُخذت فيها هذه الصورة. استخدام ميزة إنشاء نقطة استعادة لنظام التشغيل وهي مفيدة في حال أردنا إنشاء نقطة مرجعيّة للإعدادات الأساسيّة لنظام التشغيل، يمكن العودة إليها في أيّ وقت في حال حصلت مشكلة طارئة لمثل هذه الاعدادات أثّرت على عمل الجهاز. سنتحدّث عن هذه الأنواع في مقالنا هذا. النسخ الاحتياطي القياسي للملفات في ويندوز 10 انقر زر ابدأ ثم انقر زر الاعدادات الموجود فوق زر الطاقة مباشرةً: ستظهر أمامك نافذة الاعدادات. اختر منها "التحديث والأمان" لتظهر النافذة المسؤولة عن جميع مزايا التحديث والأمان. اختر من القائمة الموجودة في الطرف الأيمن "النسخ الاحتياطي" لتظهر المحتويات النسخ الاحتياطي كما في الشكل التالي: صِل قرصًا صلبًا خارجيًا، ثم انقر على "إضافة محرك أقراص" ليعمل ويندوز عند ذلك على البحث عن الأقراص المتوفرة والتي من الممكن استخدمها في عملية النسخ الاحتياطي. بالنسبة لي أظهر ويندوز 10 القرص التالي المتوفّر لدي (وهو قرص تجريبي، يمكنك التأكّد من ذلك بالنظر إلى حجمه المتواضع 44.9 جيغا بايت). انقر على القرص المتوفّر لديك، سيعمل ويندوز 10 على البدء بعمليّة النسخ الاحتياطي، لمجموعة محدّدة من المجلّدات. إذا أردت الاطلاع عليها يمكنك نقر "خيارات أكثر" لتظهر نافذة تعرض خيارات إضافية تتحكم بعمليّة النسخ الاحتياطي مثل توقيت أخذ النسخ الاحتياطي، بالإضافة إلى عرض المجلّدات الحالية التي يتم النسخ منها. يمكنك إضافة المزيد من المجلّدات التي سيعمل ويندوز 10 على أخد نسخة احتياطية من محتوياتها، بالنقر على زر "إضافة مجلّد". النسخ الاحتياطي الشامل (صورة القرص الصلب) في هذه الحالة سيقوم ويندوز 10 بأخذ ما يشبه الصورة لكامل القرص الصلب بكل ما يحتويه، وهو النسخ الاحتياطي الأشمل الذي يمكن للمرء أن يجريه. علمًا أنّ هذه الخدمة كانت موجودًا مسبقًا في إصدارات قديمة للويندوز، ولكنّها مازالت مدعومة في ويندوز 10. انقر زر ابدأ، ثم اكتب مباشرةً "لوحة التحكم" ليقوم ويندوز بالبحث عنها، وعرضها. انقر على لوحة التحكم من نتائج البحث لتظهر لك النافذة الخاصة بها. اختر منها "النسخ الاحتياطي والاستعادة (Windows 7)". في حال لم يكن هذا الخيار ظاهرًا، فيمكنك اختيار طريقة العرض: "أيقونات صغيرة". بعد ظهور النافذة المطلوبة، اختر من الجهة اليمنى في الأعلى "إنشاء صورة نظام" ليعمل الويندوز على البحث عن وسائط التخزين المتوفرة. لاحظ أنّه يعرض عليك حفظ الصورة في ثلاثة أماكن مختلفة كما في الشكل: سأختار الحفظ ضمن القرص الصلب المستقل الخاص بي (الخيار الأوّل) ثم سأنقر زر "التالي". ستوضّح لك هذه النافذة الأقراص التي سيتم النسخ منها. بعد التأكّد من أنّ جميع الأمور تجري كما هو متوقّع يمكن نقر زر "بدء النسخ الاحتياطي" كما يظهر في الشكل التالي: مع الانتباه إلى أنّ هذه العمليّة ستأخذ وقتًا طويلًا نسبيًّا بحسب سرعة المعالج وسرعة القرص الصلب، وحسب حجم الصورة أيضًا. إنشاء نقطة استعادة لنظام التشغيل وهي ميزة مفيدة في حال أردنا إجراء نسخ احتياطي سريع للإعدادات الرئيسيّة المستقرّة لنظام التشغيل. ومن ثمّ العودة إليها وقت الحاجة. انتقل إلى لوحة التحكّم، ومنها اختر "النظام" لتظهر لك النافذة التالية: اختر من القائمة الموجودة في الجهة اليمنى "إعدادات النظام المتقدّمة" لتظهر لك النافذة الموافقة. اختر لسان التبويب "حماية النظام" من الأعلى لتحصل على شكل شبيه بما يلي: انقر زر موافق وسيطلب منك الويندوز ادخال اسم لنقطة الاستعادة هذه. أدخل اسمًا معبّرًا وانقر موافق، لتبدأ عملية الإنشاء التي ستستغرق بعض الوقت. الخلاصة تعرّفنا في هذا المقال على مزايا النسخ الاحتياطي التي يدعمها ويندوز 10. هذه المزايا المهمة والضرورية للحفاظ على سلامة البيانات وعلى عدة مستويات. يختلف نوع النسخ الاحتياطي الواجب اعتماده حسب الحاجة الشخصيّة أو حاجة المؤسّسة التي يعمل بها المستخدم. بالنسبة إليّ، فقد استخدمت النسخ الاحتياطي الذي يوفره ويندوز 10 عدة مرّات، وبخاصة ميزة الصورة الشاملة. سنتابع في المقال التالي، كيفيّة استعادة النسخ الاحتياطي الذي أجريناه في هذا المقال.

يختار كثيرون من مطوري الويب الحديث اليوم استخدام قواعد بيانات 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.

إنّ 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.

إنّ أحد أهم الاعتبارات التي يجب أخذها بالحسبان عند تخزين عملنا وبياناتنا في بيئة رقميّة هو كيفيّة التّأكّد من أنّ المعلومات الخاصّة بنا ستكون متاحة في حال وجود مشكلة، قد يعني هذا أشياء مختلفة بالنظر إلى التطبيقات التي نستخدمها، مدى أهميّة الحصول على فشل فوري ونوعية المشاكل التي نتوقّعها. سنقوم في هذا الدّرس بمناقشة بعض الطرق المختلفة لتوفير النسخ الاحتياطي ووفرة البيانات data redundancy، ولأنّ حالات الاستخدام المختلفة تتطلّب حلولًا مختلفة فلن نكون قادرين على إعطاء إجابة تناسب جميع الحالات، ولكن سنتعلّم ما هو الشيء المهم في حالات مختلفة وما هو التّنفيذ implementation (أو التّنفيذات implementations) الأكثر مُلاءَمة لهذه العمليّة. سنناقش في هذا الدرس الحلول المختلفة التي يُمكننا استخدامها للنسخ الاحتياطي والمزايا النسبيّة لكلّ واحدة منها بحيث نستطيع اختيار الخطّة التي تناسب البيئة التي نعمل عليها. ما الفرق بين وفرة البيانات Redundancy والنسخ الاحتياطي Backing Up؟غالبًا ما نجد تداخل في معظم الحالات بين المصطلحين وفرة البيانات redundant والنسخ الاحتياطي backup، وهما مفهومان مميّزان مرتبطان ببعضهما ولكنّهما مختلفان، وبعض الحلول تُوفِّرهما معًا. 1. وفرة البيانات Redundancyتعني وفرة البيانات وجود تجاوز للفشل failover فوري في حال وجود مشكلة في النّظام، والمقصود من تجاوز الفشل أنّه في حال أصبحت مجموعة من البيانات غير متوفّرة فسيتمّ استبدالها فورًا بنسخة كاملة لتحلّ محلّها، وينتج عن هذا زمن إيقاف تشغيل down time غير مُلاحظ تقريبًا ويستطيع التطبيق أو الموقع مواصلة تخديم الطلبات وكأنّ شيئًا لم يكن، وفي هذه الأثناء يملك مدير النظام الفرصة لإصلاح المشكلة وإعادة النظام إلى الحالة التي يعمل فيها بشكل تام. وبينما يبدو هذا وكأنّه حل رائع لتخديم النسخ الاحتياطي فإنّ هذا في الحقيقة فكرة خاطئة خطيرة، فلا تُزوِّدنا وفرة البيانات بحماية ضدّ الفشل الذي يؤثر على كامل الآلة أو النّظام، على سبيل المثال إن كُنّا نملك mirrored RAID مضبوط (مثل RAID1) فستكون بياناتنا متوافرة فيه وفي حال فشل أحد الأقراص سيبقى الآخر متوافرًا، ولكن إن فشلت الآلة نفسها فقد نفقد جميع البيانات الخاصّة بنا. ومن مساوئ هذا النوع من الإعداد أنّ كل عمليّة يتمّ تنفيذها على كل نسخة من البيانات، ويتضمّن هذا العمليّات الخبيثة malicious أو التي تمّت بغير قصد، يُمكّننا حل النّسخ الاحتياطي الصحيح الاستعادة من نقطة سابقة حيث كانت البيانات معروفة بكونها بحالة جيّدة. 2. النسخ الاحتياطي Backupكما أشرنا سابقًا فإنّه من المُحتّم علينا الحفاظ على نُسَخ احتياطيّة تعمل بشكل جيّد لبياناتنا الهامّة، واعتمادًا على الموقف فقد يعني هذا النسخ الاحتياطي للتطبيق أو لمعلومات المستخدمين أو حتى لكامل الموقع أو الآلة، والفكرة من وراء النُسَخ الاحتياطيّة أنّه في حال حدوث فقدان في النّظام أو الآلة أو البيانات فإنّنا نستطيع استعادة restore، إعادة نشر redeploy، أو الوصول إلى بياناتنا، قد تتطلّب الاستعادة من نسخة احتياطيّة زمن إيقاف تشغيل، ولكن يوجد فرق بين البدء من نقطة في اليوم السابق والبدء من الصفر، أي شيء لا نستطيع تحمل خسارته -بالتعريف- يجب علينا عمل نسخة احتياطية له. ومن حيث الأساليب يوجد عدد قليل من المستويات المختلفة للنُسَخ الاحتياطيّة يُمكن تصنيفها إلى عدّة طبقات بحسب الحاجة إلى حساب أنواع مختلفة من المشاكل، على سبيل المثال ربّما نقوم بالنسخ الاحتياطي لملف الإعدادات configuration file قبل تعديله وذلك لكي نستطيع العودة بسهولة إلى الإعدادات القديمة قبل أن تنشأ المشكلة، يكون هذا مثالي للتغيرات الصغيرة التي نستطيع مراقبتها بشكل فعال، ولكن هذا الإعداد سيفشل على نحو بائس في حال فشل القرص أو أي شيء أكثر تعقيدًا، ينبغي علينا أيضًا الحصول على نُسَخ احتياطيّة بشكل منتظم وتلقائي إلى موقع بعيد remote location. النُّسَخ الاحتياطيّة بحد ذاتها لا تزوّدنا بتجاوز الفشل تلقائيًا، وهذا يعني أنّ الفشل لن يُكلّفنا خسارة أيّة معلومات (على اعتبار أنّ النُسَخ الاحتياطيّة التي نملكها حديثة 100%)، ولكن قد يُكلفنا زمن تشغيل Uptime، وهذا هو أحد الأسباب التي تجعلنا نستخدم وفرة البيانات والنَسخ الاحتياطي جنبًا إلى جنب بدلًا من أن تُلغي كلّ واحدة منهما الأخرى. النسخ الاحتياطي على مستوى الملف File-Level Backupإنّ النَسخ الاحتياطي على مستوى الملف هو واحد من أشيع أشكال النَسخ الاحتياطي، يستخدم هذا النّوع من النَّسخ الاحتياطي أدوات النسخ الاعتياديّة الموجودة مع النّظام لنقل الملفات إلى موقع أو جهاز آخر. 1. كيفية استخدام الأمر cpأبسط أشكال النَّسخ الاحتياطي لآلة تعمل بنظام لينِكس مثل الـ VPS هي عن طريق الأمر cp، ينسخ هذا الأمر ببساطة الملفات من موقع محلّي local إلى موقع آخر، ونستطيع على حاسوب محلّي وصْل mount قُرص قابل للإزالة وبعدها نسخ الملفات إليه: mount /dev/sdc /mnt/my-backup cp -a /etc/* /mnt/my-backup umount /dev/sdcيقوم هذا المثال بوصْل قرص قابل للإزالة ومن ثُمّ ينسخ الدّليل etc/ إلى القرص، وبعدها يقوم بإلغاء وصْل unmount القرص، والذي يُمكننا تخزينه في مكان آخر. 2. كيفية استخدام الأمر Rsyncإنّ الأمر rsync هو بديل أفضل للأمر cp، حيث يُمكّننا من إجراء نُسَخ احتياطيّة محليّة مع قَدْر أكبر من المرونة، نستطيع تنفيذ نفس العمليّات السابقة باستخدام rsync عن طريق الأوامر التالية: mount /dev/sdc /mnt/my-backup rsync -azvP /etc/* /mnt/my-backup umount /dev/sdcوفي حين أنّ هذا يبدو بسيطًا حتى هذه النقطة، إلّا أنّنا سندرك بسرعة أنّ النَّسخ الاحتياطي على نظام ملفّات محلّي مرهق ومُعقّد، حيث يجب علينا فيزيائيًا وصْل وفصْل قرص النَسخ الاحتياطي ونقله إلى مكان آخر إن أردنا الحفاظ على المعلومات في حال حدوث سرقة أو حريق، نستطيع تحقيق الكثير من نفس المزايا باستخدام النَسخ الاحتياطي عبر الشبكة. يستطيع الأمر Rsync تنفيذ نُسخ احتياطيّة عن بُعد remote بنفس السهولة التي يستطيع القيام بها بنُسخ احتياطيّة محليّة، يجب علينا فقط استخدام صيغة بديلة، سيعمل هذا الأمر على أي مُضيف host نستطيع الدخول إليه عن طريق SSH طالما أنّ rsync مُثبّت لدى الطرفين: rsync -azvP /etc/* username@remote_host:/backup/سيقوم هذا الأمر بالنسخ الاحتياطي للدليل etc/ الموجود على الجّهاز المحلّي إلى دليل على remote_host موجود في backup/. سينجح هذا الأمر إن كُنّا نملك صلاحيات للكتابة على هذا الدّليل وتوجد مساحة كافية. للمزيد من المعلومات حول كيفيّة استخدام rsync للنّسخ الاحتياطي اضغط هنا. 3. كيفية استخدام أدوات أخرى للنسخ الاحتياطيبالرغم من بساطة الأمرين cp و rsync وإمكانيّة استخدامهما بسهولة إلّا أنّهما ليسا دومًا الحل المثالي، لجعل النُسخ الاحتياطية مُؤتمتة نحتاج لوضع هاتين الأداتين ضمن Script وكتابة أي شيفرة ضرورية من أجل الدوران والجماليّات الأخرى. لحسن الحظ توجد بعض الأدوات المساعدة التي تقوم بتنفيذ إجراءات مُعقّدة أكثر للنسخ الاحتياطي ببساطة. Baculaإنّ أداة Bacula هي حل مُركّب ومرن يُعزّز نموذج خادوم عميل للنسخ الاحتياطي للمضيفين hosts، تفصل Bacula بين أفكار العملاء، أماكن النسخ الاحتياطي والإدارة directors (المُكوِّن الذي يُنسّق النسخ الاحتياطي الفعلي)، وتقوم أيضًا بضبط كل مهمّة نسخ احتياطي ضمن وحدة تدعى الوظيفة job. يسمح لنا هذا بتضبيط configuration مُحبّب ومرن بشدّة، نستطيع النسخ الاحتياطي للعديد من العملاء إلى جهاز تخزين وحيد، عميل واحد إلى عدّة أجهزة تخزين، وتعديل مُخطط النسخ الاحتياطي بسرعة وسهولة عن طريق إضافة عُقَد أو ضبط تفاصيلهم، تعمل هذه الأداة بشكل جيّد عبر بيئة تحتوي على شبكة، وهي قابلة للتوسيع وتقسيمها إلى وحدات، مما يجعلها رائعة للنسخ الاحتياطي لموقع أو تطبيق مُوزَّع عبر عدّة أجهزة. لكي تتعلّم المزيد حول كيفيّة تضبيط خادوم Bacula للنسخ الاحتياطي وكيفيّة النسخ الاحتياطي للأنظمة عن بعد باستخدام Bacula، قم بزيارة هذه الروابط. BackupPCمن الحلول الشائعة الأخرى هي أداة BackupPC، يُمكن استخدام هذه الأداة للنسخ الاحتياطي لأنظمة لينِكس وويندوز بسهولة، يتم تنصيبها على جهاز أو VPS والذي سيعمل كخادوم للنسخ الاحتياطي، وبعدها يسحب الخادوم البيانات من عملائه باستخدام طرق نقل الملفّات المُعتادة. يُقدّم هذا الإعداد ميزة تنصيب جميع الحِزَم packages المتعلّقة بذلك على جهاز مركزي واحد، والتضبيط الوحيد الذي نحتاجه هو السماح لخادوم النسخ الاحتياطي بالوصول عبر SSH، يُمكن بسهولة إعداد هذا، وباستخدام DigitalOcean نستطيع تضمين مفاتيح SSH لخادوم BackupPC إلى العملاء بينما نقوم بالنشر، يسمح لنا هذا بضبط النسخ الاحتياطيّة من خادوم النسخ الاحتياطي بسهولة ونشر بيئات الإنتاج الخاصّة بنا بشكل نظيف بدون أيّة برمجيّات إضافيّة. لكي تتعلّم كيفيّة تثبيت واستخدام BackupPC على خادوم، اضغط هنا. DuplicityDuplicity هي بديل رائع للأدوات التقليديّة، الميّزة الأساسيّة للتفاضل في Duplicity هي أنها تستخدم تعمية GPG encryption لنقل وتخزين البيانات، ولهذا بعض الفوائد الرائعة. إنّ الفائدة الواضحة من استخدام تشفير GPG للنسخ الاحتياطي للملفّات هي أنّه لا يتم تخزين البيانات بشكل نص مُجرَّد plain text. الشّخص الوحيد الذي يستطيع فكّ تعمية decrypt البيانات هو من يملك مفتاح GPG key، يُوفِّر هذا درجة من الحماية لتعويض تضخّم التدابير الأمنية اللازمة عندما يتم تخزين البيانات في مواقع مُتعدّدة. الفائدة الأخرى التي قد لا تكون واضحة بشكل فوري للأشخاص الذين لا يستخدمون GPG عادةً هي أنّه يتمّ التّحقّق من كل عمليّة نقل لتكون دقيقة تمامًا، تفرض GPG فحص تلبيد Hash صارم للتأكّد من عدم وجود ضياع في البيانات أثناء النقل، ويعني هذا أنّه عندما يحين الوقت لاستعادة البيانات من النُسخة الاحتياطيّة سنكون أقل عُرضة للوقوع في مشاكل تَلَف الملفات. لكي تتعلّم كيفيّة تمكين النُسخ المُشفّرة باستخدام GPG في Duplicity، اتبع هذا الرابط. النسخ الاحتياطي على مستوى الكتلة Block-Level Backupsإنّ النسخ الاحتياطي على مستوى الكُتلة هو أقل شيوعًا من النسخ الاحتياطي على مستوى الملف ولكنّه بديل هام له، يُعرف أيضًا هذا النمط من النسخ الاحتياطي بالتصوير imaging لأنّه من المُمكن استخدامه لاستنساخ duplicate واستعادة كامل الأجهزة. يسمح النسخ الاحتياطي على مستوى الكُتلة بالنسخ على مستوى أعمق من الملف، فبينما يقوم النسخ الاحتياطي على مستوى الملف بنسخ الملف1، الملف2، والملف3 إلى موقع نسخ احتياطي، يقوم النسخ الاحتياطي على مستوى الكُتلة بنسخ كامل الكُتلة Block التي تحتوي على هذه الملفات، ولتفسير المفهوم بطريقة أخرى يمُكننا القول أنّ النسخ الاحتياطي على مستوى الكتلة ينسخ المعلومات بِت bit تلو الآخر، فهو لا يهتم بالملفات المُجرّدة التي قد تُمثّلها هذه البتّات bits (ولكن سيتم نقل الملفّات بشكل كامل خلال هذه العمليّة). إنّ إحدى الفوائد من النسخ الاحتياطي على مستوى الكتلة أنّه عادة ما يكون أسرع، وبينما يقوم النسخ الاحتياطي على مستوى الملف بالبدء بعمليّة نقل جديدة لكل ملف مُنفصل، يقوم النسخ الاحتياطي على مستوى الكُتلة بنقل الكُتَل والتي عادةً ما تكون أكبر حجمًا، وهذا يعني الحاجة للبدء بعمليّات نقل أقل لإتمام النسخ. استخدام الأداة dd لتنفيذ عمليات النسخ الاحتياطي على مستوى الكتلةإنّ أبسط طريقة لتنفيذ عمليّات النسخ الاحتياطي على مستوى الكُتلة هي باستخدام الأداة dd، هذه البرمجيّة مرنة جدًا وتتيح لنا نسخ المعلومات بِت تلو الآخر إلى مكان جديد، ويعني هذا أنّنا نستطيع النسخ الاحتياطي لقسم partition أو قرص disk إلى ملف واحد أو إلى جهاز raw device بدون أي خطوات تمهيدية. أبسط طريقة للنسخ الاحتياطي لقسم أو قرص هي استخدام dd كما يلي: dd if=/path/of/original/device of=/path/to/place/backupفي هذه الحالة تُحدّد =if جهاز الدخل input أو موقع، تُشير =of إلى ملف الخرج output أو موقع، من الهام جدًا تذكّر هذا الفرق، لأنّه من البديهي مسح قرص كامل إن تمّ عكسهما. إن كُنّا نرغب بالنسخ الاحتياطي لقسم يحتوي على مُستنداتنا الموجودة في dev/sda3/ نستطيع إنشاء ملف صورة كما يلي: dd if=/dev/sda3 of=~/documents.imgتُوجد العديد من الحلول الأخرى للنسخ الاحتياطي على مستوى الكتلة متوفّرة على أجهزة لينِكس، ولكنّنا لن نناقشهم هنا. إصدارات النسخ الاحتياطيةإنّ أحد أهم الأسباب الرئيسيّة للنسخ الاحتياطي للبيانات هو القدرة على استعادة إصدار سابق من ملف أو مجموعة ملفّات في حال حدوث تغيير غير مرغوب أو حذف، وبينما تُزوّدنا جميع آليات النسخ الاحتياطي المذكورة حتى الآن بهذا إلى حدّ ما، نستطيع تنفيذ نظام أكثر قوّة باستخدام أدوات إضافيّة. الطريقة اليدويّة لإنجاز هذا هي إنشاء ملف نسخة احتياطية قبل التعديل كما يلي: cp file1 file1.bak nano file1نستطيع أيضًا أتمتة هذه العمليّة عن طريق إنشاء ملفّات مخفيّة ذات ختم زمني timestamped في كل مرّة نقوم فيها بتعديل ملف عن طريق المُحرّر، على سبيل المثال نستطيع وضع ما يلي في ملف bashrc./~ : nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }عندما نستدعي الآن الأمر nano سيقوم تلقائيًا بإنشاء نُسَخ احتياطيّة. يُوفّر لنا هذا مستوى مُعيَّن من النسخ الاحتياطي، ولكنّها طريقة هشّة جدًّا وقد تملأ القرص بسرعة إن كُنّا نُعدِّل الملفّات كثيرًا، لذلك هي ليست حلًّا رائعًا وربما ينتهي بنا الأمر أسوأ من القيام بالنسخ اليدوي للملفات التي نريد تحريرها. ومن البدائل التي تقوم بحل العديد من المشاكل المُتأصّلة في هذا التصميم هو استخدام git، والتي هي تحديدًا نظام تحكّم بالإصدار، وبالرغم أنّ هذا قد يكون غير واضح نستطيع استخدام git للتحكّم بأي ملف تقريبًا. نستطيع إنشاء مستودع git repository في الدليل الرئيسي فورًا، ببساطة عن طريق كتابة ما يلي: cd ~ git initربّما نحتاج هنا إلى تطويع tweak الإعدادات لاستثناء بعض الملفات، ولكن بشكل عام يقوم بإنشاء إصدارات بشكل فوري، بإمكاننا بعدها إضافة محتويات الدليل الخاص بنا وتضمين الملفّات عن طريق ما يلي: git add . git commit -m "Initializing home directory"نستطيع ببساطة الانتقال إلى موقع بعيد remote location نظام git المُضمَّن أيضًا: git remote add backup_server git://backup_server/path/to/project git push backup_server masterإنّ هذا النظام ليس رائعًا للنسخ الاحتياطي من تلقاء نفسه، ولكن بجمعه مع نظام نسخ احتياطي آخر يتمكّن هذا النمط من التحكّم بالإصدار من تزويدنا بتحكّم جيّد ومُحبّب بشدّة بالتغيرات التي نقوم بها. للتعلّم أكثر حول كيفيّة استخدام git وكيف نستطيع استخدام git لإصدار الملفّات العاديّة، تحقّق من هذه الروابط. النسخ الاحتياطي على مستوى VPS، ومزود DigitalOcean كنموذجفي حين أنّه من المهم إدارة النُسخ الاحتياطيّة بأنفسنا، تُزوّدنا خدمة DigitalOcean مثلا ببعض الآليات لإكمال النسخ الاحتياطيّة الخاصّة بنا. نمتلك دالّة للنسخ الاحتياطي تقوم بانتظام بعمل نُسَخ احتياطيّة تلقائيّة من أجل droplets (مصطلح مقابل لـ VPS على DigitalOcean) التي تُمكّن هذه الخدمة، نستطيع تشغيلها خلال إنشاء droplet عن طريق اختيار صندوق التأشير "تمكين النُسَخ الاحتياطيّة" "Enable Backups": سيقوم هذا بأخذ نُسخة احتياطيّة لكامل صورة الـ VPS، وهذا يعني أنّنا نستطيع بسهولة إعادة النشر من النُسخة الاحتياطيّة أو استخدامها كأساس للـ droplets الجديدة. ولأخذ صورة لمرّة واحدة عن النظام لدينا نستطيع إنشاء لقطات snapshots، والتي تعمل بصورة مشابهة للنُسَخ الاحتياطيّة ولكنّها غير مؤتمتة، نستطيع إنشاءَها عن طريق الذهاب إلى droplet لدينا واختيار "Snapshots" من القائمة العلويّة: ترجمة -وبتصرّف- للمقال How To Choose an Effective Backup Strategy for your VPS لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

تحتاج خطط الاسترداد التي أعددناها في الجزء السابق إلى نظام للنسخ الاحتياطي. سنركز في هذا المقال على نظام النسخ الاحتياطي 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.

يعرض هذا الدّرس والذي يُعتبر الأول من سلسلة ذات ستة أجزاء كيفية إعداد بنية تحتية لتطبيق مكوَّن من خواديم عدة، انطلاقا من الصفر. سيحتوي الإعداد النهائي على آليات للنسخ الاحتياطي Backup، المراقبة Monitoring، نُظُم مركزية للسجلات Centralized logging مما يعزز من إمكانية تشخيص المشاكل واستعادة إعدادات التطبيق عند الحاجة. الهدف الأسمى هو إنشاء نظام إدارة قائم بذاته، والتعريف بأهم المفاهيم والاعتبارات العملية التي ينبغي التنبه لها عند إعداد خادوم موجَّه للإنتاج Production server. ملحوظة: توجد -عادة- أثناء تطوير وإعداد البرامج بيئة إنتاج وبيئة اختبار (أو أكثر). في بيئة الاختبار يستخدم قليلون التطبيق، ويكون المستخدمون في هذه الحالة غالبا مطورين يبحثون عن علل لترقيعها. في الجانب الآخر فإن التطبيق في بيئة الإنتاج يستخدمه المستهدَفون الحقيقيون بالمنتَج (التطبيق)؛ لذا يجب أن يعمل بكفاءة وسلاسة. قراءة الدّرس التالي وفهمه سيساعدك في المضي قدما مع هذا الدّرس: خمسة إعدادات شائعة لتطبيقات الوب.يقدم المقال خطوطا عريضة لإعداد تطبيق موجَّه للإنتاج، بينما يوضح هذا الدّرس كيفية التخطيط لتطبيق نموذجي وإعداده من البداية إلى النهاية. المأمول هو أن يساعدك الدرس في التخطيط لإعداد خادومك الخاص ثم تنفيذ الإعداد حتى ولو كنت تشغِّل حزمة تطبيقات مختلفة تماما. يحيل الدّرس في أحيان كثيرة، نظرا لأنه يغطي مواضيع مختلفة من إدارة النظم، إلى شروحات مفصلة ضمن مقالات أخرى تقدم معلومات إضافية. الهدفسنحصل بنهاية مجموعة المقالات هذه على خادوم إنتاج معدّ لتشغيل تطبيق PHP، ووردبريس على سبيل المثال، يمكن الوصول إليه عبر العنوان https://www.example.com/. سنعدّ أيضا خواديم إضافية لدعم خواديم التطبيق في بيئة الإنتاج. سيبدو الإعداد النهائي على النحو التالي (لا تظهر خواديم نظام إدارة النطاقات DNS الداخلية ولا النسخ الاحتياطية البعيدة في الصورة أدناه): نعُدُّ الخواديم الموجودة في مربع التطبيق ضرورية ليعمل التطبيق على النحو المرجو. تعمل العناصر المتبقية - النسخ الاحتياطية، المراقبة، والسجلات - بجانب خطة الاستعادة وخادوم النسخ الاحتياطي البعيد؛ على دعم خادوم الإنتاج. سنثبت كل عنصر على خادوم Ubuntu 14.04 منفصل ضمن نفس الحيز الجغرافي مع تفعيل التشبيك الخاص Private networking. نستخدم أسماء المستضيفات Hostnames لتمييز الخواديم المكوِّنة للتطبيق: lb1: موزع الحمل HAProxy، يمكن الوصول إليه عبر العنوان https://www.example.com/.app1: خادوم تطبيقات Apache و PHP.app2: خادوم تطبيقات Apache و PHP.db1: خادوم لقاعدة بيانات MySQL.من المهم التنبيه إلى أنه تم اختيار هذا النوع من الإعداد لتوضيح كيف يمكن لعناصر تطبيق أن تُنشأ على خواديم عدة؛ يجب أن يُخصَّص إعداد تطبيقك بناء على احتياجاتك. توجد نقطة إخفاق Point of failure وحيدة في هذا الإعداد، ويمكن التغلب عليها بتركيب موزع حمل إضافي (وخادوم DNS دوري) ومضاعفة قاعدة البيانات؛ وهو ما لن تطرق إليه في هذا الدرس. نميز العناصر الداعمة للتطبيق بأسماء المستضيفات التالية: النسخ الاحتياطية backups: خادوم النسخ الاحتياطي Bacula.المراقبة monitoring: خادوم Nagios.السجلات logging: سجلات مركزية باستخدام حزمة برمجيات مكونة من Kibana (ELK)، Logstash و Elasticsearch.توجد عناصر أخرى لا تظهر في الصورة، وهي: ns1: وهو خادومنا الرئيس لنظام أسماء النطاقات. نستخدم Bind لهذا الغرض.ns2: وهو الخادوم الثانوي لنظام أسماء النطاقات. نستخدم Bind.remotebackups: خادوم بعيد يوجد في منطقة جغرافية أخرى نحفظ عليه نسخ Bacula الاحتياطية احترازا من كارثة تحل بمركز البيانات الذي يوجد فيه التطبيق.يمكنك أيضا استخدام عنوان IP عائم Floating IP؛ وهو عبارة عن عنوان IP ثابت يُتاح للعموم الوصول إليه ويمكن توجيهه إلى أحد خواديمك الافتراضية أو بنيتك التحتية المكرَّرة Redundant ثم إطلاق موقعك أو خدمتك باستخدام عنوان IP عمومي وحيد. يمكن بعدها إعادة توجيه العنوان العائم إلى خادوم جديد من أجل بيئة إنتاج أكثر مرونة وأسرع تجاوبا. سنضع أيضا خطط استعادة لكلٍّ من العناصر المكونة للتطبيق. ستكون لدينا، عند بلوغ الهدف النهائي، عشرة خواديم. سننشئها كلَّها في نفس الوقت لتسهيل بعض الأمور مثل إعداد النطاقات؛ ولكن يمكنك إنشاؤها الواحد تلو الآخر حسب الحاجة. شبكة خاصة افتراضية Virtual Private Network (اختياري)إذا أردت تأمين اتصالات الشبكة بين خواديمك فيجب عليك إعداد شبكة خاصة افتراضية VPN. يصبح تأمين نقل البيانات عبر الشبكة بتعميتها Encryption أكثر أهمية إذا كانت البيانات تمر عبر الإنترنت. من منافع استخدام شبكة خاصة افتراضية التحقق من هوية المستضيفات بالاستيثاق منها؛ وهو ما يحمي من المصادر التي لا يُرخص لها الوصول للخدمات. إذا كنت تبحث عن أداة مفتوحة المصدر فيمكنك استخدام OpenVPN واتباع خطوات درس دليلك لكيفية إعداد خادوم OpenVPN على Ubuntu لإعداده. المتطلباتيتوجب أن يكون لدى كل خادوم أوبنتو 14.04 حساب مستخدم بصلاحيات إدارية غير المستخدم الجذر؛ يمكن إعداد مستخدم لهذا الغرض باتّباع الخطوات المشروحة في مقال الإعداد الابتدائي لخادوم أوبنتو 14.04. سننفّذ كل الأوامر باستخدام هذا الحساب. سنفترض أيضا أن لديك معرفة بالمفاهيم الأساسية للأمان في لينكس. إذا رغبت في درس تمهيدي حول الموضوع فيمكن الاطلاع على مقال 7 تدابير أمنيّة لحماية خواديمك. اسم نطاقنفترض في هذا المقال أن الوصول إلى التطبيق يكون عبر اسم نطاق، example.com مثلا. إنْ لم يكن لديك اسم نطاق فبالإمكان شراء واحد من أحد مسجلي أسماء النطاقات Domain name registrar. نحتاج اسم النّطاق ليس فقط لتسهيل الوصول إلى الموقع (مقارنة بعنوان IP المكون من أرقام فقط) بل أيضا للحصول على فوائد التحقق من الهوية والنطاق؛ وهو ما يتيح إمكانية الاستفادة من شهادات SSL التي تعمّي البيانات المنقولة بين التطبيق ومستخدميه. شهادة SSLيعمل بروتوكول TLS/SSL على تعميّة البيانات والتحقق من نطاقها أثناء الاتصال بين التطبيق ومستخدميه؛ لذا سنستخدم شهادة SSL لإضافة هذا الإعداد. في المثال نريد أن يصل المستخدمون إلى الموقع عبر العنوان www.example.com وهي القيمة التي سنحددها في الاسم الشّائع للشهادة Common Name (أو ما يُعرف اختصارًا بـ CN). سنثبت الشهادة على خادومHAProxy (المُسمّى lb1) وهو ما يعني أنه من الأفضل توليد مفاتيح الشهادة وطلب توقيع الشهادة Certificate Signing Request CSR على هذا الخادوم. إذا احتجت للتحقق من الهوية فستحتاج لشراء شهادة SSL. توجد الكثير من سلطات الشهادات Certificate Authorities التجارية التي يمكن شراء شهادة SSL منها. كما توجد إمكانية لاستخدام شهادة مجانية من StartSSL يتوفر أيضا حل بديل يتمثل في التوقيع الذاتي لشهادة SSL بتنفيذ الأمر التالي: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crtالخطوات المتبعة للوصول إلى الهدفعرضنا في الفقرات السابقة نظرة عامة على إعداد تطبيقنا الموجَّه للإنتاج، ننتقل الآن لإنشاء خطة عامة نسير وفقها لتحقيق هدفنا. العناصر الأهم هي تلك التي يتكون منها التطبيق؛ لذا يجب أن نشغلها مبكرا. لكن نظرا لأننا نخطط لاستخدام عنونة تعتمد على أسماء النطاقات للاتصالات ضمن الشبكة الخاصة فيجب أن نعد نظام أسماء النطاقات أولا. سنعدّ، بعد الانتهاء من ضبط إعداد النطاقات، الخواديم التي تكون التطبيق من أجل أن يكون جاهزا للتشغيل. يحتاج التطبيق إلى أن تكون قاعدة بيانات مهيَّأة سلفا، كما يتطلب موزع الحِمل أن يكون التطبيق جاهزا. انطلاقا من هذه الاعتبارات فإن إعداد العناصر سيكون حسب الترتيب التالي: خادوم قاعدة البيانات.خواديم التطبيق.موزع الحمل.سيمكننا - بعد إكمال الخطوات السالفة الذكر من أجل إعداد التطبيق - استنباطُ خطة للاستعادة اعتمادا على سيناريوهات عدة. ستكون خطة الاستعادة أساسية في التخطيط لآليات النسخ الاحتياطي. بعد خطة الاستعادة يأتي دور إعداد النسخ الاحتياطي ثم بعد استكماله يمكن ضبط نظام المراقبة من أجل التأكد من أن جميع الخواديم وكل الخدمات في وضعيةِ عمل مقبولة. ثم نأتي للخطوة الأخيرة وهي إنشاء نظام مركزي لتخزين السجلات مما يسمح بعرضها عند الحاجة، تشخيص المشاكل عند حدوثها وتحليلها لتحديد أنواع الاستخدام وطبيعته. خاتمةخطة العمل جاهزة الآن مما يعني أننا جاهزون للبدء في تنفيذ إعدادات التطبيق. ينبغي تذكر أن هذا الإعداد، رغم أنه يعمل على النحو المراد، يبقى مثالا يجب أن تستطيع التقاط معلومات مفيدة منه ثم استخدام ما تعلمته لتحسين إعداد تطبيقك الخاص. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Overview لصاحبه 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.