كيفية تأمين قواعد بيانات MySQL/MariaDB وتفعيل النسخ الاحتياطي التلقائي المجدول عبر السيرفر

تحتوي قواعد بيانات MySQL وMariaDB على أهم بيانات المواقع، لذلك يجب الجمع بين تأمين الوصول وإنشاء نسخ احتياطية تلقائية قابلة للاستعادة. يشرح هذا الدليل حماية قاعدة البيانات على خادم Linux، وتطبيق أقل الصلاحيات، وتقييد الاتصال، ثم إعداد نسخ مجدولة ومراقبتها.

تحديث الخادم وقاعدة البيانات

استخدم إصدارات مدعومة وحدّث حزم الأمان دورياً. على Ubuntu وDebian:

sudo apt update
sudo apt upgrade

خذ نسخة احتياطية قبل الترقيات الكبيرة وراجع تأثيرها في بيئة الإنتاج.

تشغيل الإعداد الأمني

sudo mysql_secure_installation

تختلف الخيارات بين MySQL وMariaDB والإصدارات، لذلك اقرأ كل خطوة قبل تطبيقها.

لا تستخدم root لتطبيق الموقع

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

تقييد الوصول إلى MySQL/MariaDB

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

لا تفتح 3306 للعالم

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

حماية كلمات المرور

استخدم كلمات مرور طويلة وفريدة ولا تحفظها في مستودعات عامة أو ملفات متاحة عبر الويب. اضبط صلاحيات ملفات الإعداد والأسرار بحيث تقرأها الخدمات المطلوبة فقط.

تشفير الاتصال

عندما تنتقل اتصالات قاعدة البيانات بين خوادم مختلفة، استخدم TLS عندما تتطلب البنية ذلك، واتبع توثيق إصدار MySQL أو MariaDB المستخدم.

Replication ليس نسخة احتياطية

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

إنشاء نسخة باستخدام mysqldump

mysqldump --single-transaction --routines --triggers appdb | gzip > appdb.sql.gz

يكون --single-transaction مناسباً في حالات كثيرة مع InnoDB، لكن متطلبات الاتساق تختلف باختلاف تصميم القاعدة.

لا تكتب كلمة المرور في الأمر

تجنب وضع كلمة المرور مباشرة في سطر الأوامر أو Cron. استخدم آلية بيانات اعتماد مناسبة تدعمها أدوات قاعدة البيانات، مع صلاحيات ملفات مقيدة أو مدير أسرار.

إنشاء مجلد آمن للنسخ

sudo mkdir -p /var/backups/mysql
sudo chmod 700 /var/backups/mysql

لا تضع ملفات SQL داخل public_html أو أي Web Root.

سكربت نسخ تلقائي

يمكن إنشاء سكربت Bash يحدد مجلد النسخ واسم قاعدة البيانات والتاريخ، ثم ينفذ mysqldump مع الضغط ويتحقق من أن الملف الناتج غير فارغ. استخدم set -euo pipefail حتى تتوقف المهمة عند الأخطاء، وطبّق umask 077 لحماية الملفات الجديدة.

اختبر السكربت يدوياً

قبل الجدولة شغّل السكربت وتأكد من نجاحه ومن إنشاء ملف بالحجم المتوقع. لا تعتبر وجود الملف وحده دليلاً نهائياً على صلاحية النسخة؛ يجب اختبار الاستعادة أيضاً.

جدولة النسخ عبر Cron

افتح جدول root أو المستخدم المخصص:

sudo crontab -e

مثال لتشغيل سكربت النسخ يومياً الساعة 03:30:

30 3 * * * /usr/local/sbin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

تحقق من المنطقة الزمنية للخادم وراقب السجل حتى لا تفشل المهمة بصمت.

systemd Timer كبديل

يمكن استخدام systemd timers بدلاً من Cron في الأنظمة الحديثة. اختر آلية جدولة واحدة واضحة لتجنب تشغيل نسخ مكررة دون قصد.

سياسة الاحتفاظ بالنسخ

تراكم النسخ قد يملأ القرص. اعرض أولاً الملفات القديمة التي ستتأثر:

find /var/backups/mysql -type f -name '*.sql.gz' -mtime +14 -print

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

احتفظ بنسخة خارج الخادم

إذا تعطّل القرص أو تعرض الخادم للاختراق، قد تفقد البيانات والنسخ المحلية معاً. احتفظ بنسخة إضافية في موقع مستقل وآمن، مثل خادم نسخ أو تخزين مخصص.

تشفير النسخ الاحتياطية

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

التحقق من سلامة الملفات

sha256sum appdb.sql.gz > appdb.sql.gz.sha256

يساعد Hash على اكتشاف تغير الملف أو تلفه، لكنه لا يغني عن اختبار الاستعادة.

اختبار الاستعادة

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

RPO وRTO

RPO هو مقدار البيانات الذي يمكن تحمل فقدانه زمنياً، وRTO هو الوقت المقبول لإعادة الخدمة. متجر يتلقى طلبات باستمرار يحتاج غالباً إلى خطة مختلفة عن موقع يتغير مرة يومياً.

مراقبة نجاح النسخ

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

مراقبة مساحة القرص

df -h

اجمع بين سياسة الاحتفاظ ومراقبة المساحة حتى لا تصبح النسخ سبباً في توقف قاعدة البيانات.

حماية phpMyAdmin وأدوات الإدارة

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

أخطاء أمنية شائعة

• استخدام root داخل التطبيق.
• فتح 3306 لجميع الإنترنت.
• منح صلاحيات أوسع من المطلوب.
• إعادة استخدام كلمات المرور.
• تجاهل التحديثات.
• حفظ الأسرار داخل ملفات مكشوفة.

أخطاء شائعة في النسخ الاحتياطي

• الاحتفاظ بالنسخة الوحيدة على الخادم نفسه.
• عدم اختبار الاستعادة.
• عدم مراقبة Cron.
• عدم وجود سياسة احتفاظ.
• حفظ SQL داخل Web Root.
• نقل النسخ الحساسة دون حماية مناسبة.

خطة عملية مختصرة

1. حدّث النظام وقاعدة البيانات.
2. راجع الحسابات والصلاحيات.
3. قيّد الوصول الشبكي.
4. احمِ بيانات الاعتماد.
5. أنشئ حساباً مناسباً للنسخ.
6. أنشئ مجلداً محمياً.
7. اختبر النسخ يدوياً.
8. جدوله عبر Cron أو systemd.
9. طبّق سياسة احتفاظ.
10. احتفظ بنسخة مستقلة ومشفرة.
11. اختبر الاستعادة دورياً.

أسئلة شائعة

كم مرة يجب أخذ نسخة؟

يعتمد ذلك على معدل تغير البيانات وRPO. كلما كانت البيانات تتغير بسرعة وتزداد أهميتها، احتجت إلى نقاط استعادة أقرب.

هل mysqldump مناسب لكل قاعدة؟

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

هل نسخة الاستضافة تكفي؟

راجع عدد النسخ ومدة الاحتفاظ ومكانها وآلية الاستعادة. وجود نسخة مستقلة إضافية يوفر طبقة حماية مهمة للبيانات الحساسة.

هل تغيير منفذ MySQL يكفي للحماية؟

لا. لا يعوض عن الجدار الناري وتقييد الوصول والمصادقة والتحديثات.

الخلاصة

يتطلب تأمين MySQL وMariaDB تحديثات مستمرة، وأقل الصلاحيات، وتقييد الوصول، وحماية بيانات الاعتماد والمراقبة. أما النسخ الاحتياطي فيجب أن يكون تلقائياً ومراقباً ومحمياً، مع نسخة مستقلة خارج الخادم وسياسة احتفاظ واضحة.

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