كيفية اختيار استراتيجية فعالة للنسخ الاحتياطي للخادوم الخاص الافتراضي VPS

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

سنقوم في هذا الدّرس بمناقشة بعض الطرق المختلفة لتوفير النسخ الاحتياطي ووفرة البيانات 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 على خادوم، اضغط هنا.

Duplicity

Duplicity هي بديل رائع للأدوات التقليديّة، الميّزة الأساسيّة للتفاضل في 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.