نسخ MySQL وMariaDB احتياطياً: التصدير المنطقي والنسخ الفيزيائي والاستعادة إلى نقطة زمنية

هناك طريقتان لنسخ خادم MySQL أو MariaDB احتياطياً: النسخ المنطقي الذي يصدّر أوامر SQL تعيد إنشاء البيانات، والنسخ الفيزيائي الذي ينسخ ملفات قاعدة البيانات نفسها. لكلٍّ منهما مكانه، ولا يتيح أيٌّ منهما وحده العودة إلى الدقيقة التي سبقت استعلاماً خاطئاً. يشرح هذا الدليل كيف تأخذ كل نوع بطريقة صحيحة على خادم Debian أو Ubuntu، وكيف تستعيده، وكيف يسد السجل الثنائي (binary log) الفجوة بين نسخة وأخرى.

اعرف الخادم الذي تشغّله

توفّر Debian خادم MariaDB بديلاً متوافقاً مع MySQL: الإصدار 10.11 في Debian 12 (bookworm) والإصدار 11.8 في Debian 13 (trixie). أما MySQL 8.4 LTS من Oracle فيأتي من مستودعات MySQL نفسها أو من توزيعات أخرى. وتختلف الأدوات في أسمائها وبعض خياراتها، فابدأ بالتحقق:

mariadb --version || mysql --version

في MariaDB تحمل أدوات العميل الأسماء mariadb وmariadb-dump وmariadb-binlog. وما زال الاسم القديم mysqldump يعمل عبر رابط للتوافق، لكن توثيق MariaDB يصفه بأنه مهمل منذ الإصدار 11.0، فاستخدم الأسماء الجديدة في السكربتات الجديدة.

النسخ المنطقي عبر mariadb-dump أو mysqldump

ملف التصدير قابل للنقل بين الإصدارات والأجهزة، وسهل الفحص، ويسهل أن تستعيد منه قاعدة بيانات واحدة. ومع جداول InnoDB يأخذ الخيار --single-transaction لقطة متسقة دون أن يعطّل التطبيق:

# MariaDB on Debian: root connects through the local socket
sudo mariadb-dump --single-transaction --quick --routines --events \
  --databases shop > /var/backups/db/shop-$(date +%F).sql

# MySQL 8.4
mysqldump --single-transaction --quick --routines --events \
  --databases shop > /var/backups/db/shop-$(date +%F).sql

تفاصيل مهمة:

• الاتساق لجداول InnoDB فقط: يضمن --single-transaction رؤية متسقة للجداول التي تدعم المعاملات وحدها، أما جداول MyISAM أو MEMORY فقد تتغير أثناء التصدير.
• لا تغييرات على البنية أثناء التصدير: ينبّه توثيق MariaDB إلى أن أوامر ALTER TABLE وCREATE TABLE وDROP TABLE وRENAME TABLE وTRUNCATE TABLE من اتصال آخر قد تجعل الملف غير صحيح أو تُفشل التصدير، فأبعد موعده عن عمليات النشر التي تنفّذ ترحيلات قاعدة البيانات.
• الإجراءات والأحداث اختيارية: المشغّلات (triggers) تُصدَّر مع جداولها، أما الإجراءات المخزنة والدوال والأحداث المجدولة فتحتاج --routines و--events.
• تحقق من الفشل: إذا مرّرت التصدير عبر gzip فشغّل السكربت مع set -o pipefail كي لا يختفي فشل التصدير خلف نجاح الضغط.

والاستعادة تعني إعادة الملف إلى العميل، ويُفضّل أن تكون إلى خادم اختبار أولاً:

sudo mariadb < /var/backups/db/shop-2026-10-31.sql
# or for a compressed dump
zcat /var/backups/db/shop-2026-10-31.sql.gz | sudo mariadb

ودليل MySQL صريح في حدود هذه الطريقة: فأداة mysqldump ليست مصممة لتكون حلاً سريعاً أو قابلاً للتوسع مع البيانات الكبيرة، وقد تكون الاستعادة بطيئة جداً لأن كل صف وفهرس يُعاد بناؤه بتنفيذ أوامر SQL. وحين تصبح مدة الاستعادة أطول مما يحتمله العمل، انتقل إلى النسخ الفيزيائي.

النسخ الفيزيائي عبر mariadb-backup أو Percona XtraBackup

تنسخ الأدوات الفيزيائية ملفات InnoDB والخادم يعمل، ثم تجعل النسخة متسقة في خطوة تحضير منفصلة. والاستعادة أسرع بكثير لأنه لا يُعاد بناء شيء.

مع MariaDB استخدم mariadb-backup (واسمه السابق mariabackup، وأصله تفرّع عن Percona XtraBackup 2.3.8)، وهو في Debian ضمن الحزمة mariadb-backup. ويحتاج مستخدم النسخ إلى الصلاحيات RELOAD وPROCESS وLOCK TABLES وBINLOG MONITOR.

sudo apt install mariadb-backup
sudo mariadb-backup --backup --target-dir=/var/backups/mariadb/full
sudo mariadb-backup --prepare --target-dir=/var/backups/mariadb/full

الملفات لا تكون متسقة قبل تنفيذ --prepare، فلا تنسخ نسخة غير محضّرة إلى مجلد البيانات أبداً. وللاستعادة: أوقف الخادم، وتأكد من أن مجلد البيانات فارغ، وانسخ النسخة إليه، ثم صحّح الملكية:

sudo systemctl stop mariadb
sudo mariadb-backup --copy-back --target-dir=/var/backups/mariadb/full
sudo chown -R mysql:mysql /var/lib/mysql/
sudo systemctl start mariadb

واستخدم إصداراً من mariadb-backup يطابق الخادم الذي تنسخه، والتوثيق صريح في ذلك عند التخطيط للترقية.

ومع MySQL من Oracle تؤدي Percona XtraBackup الدور نفسه عبر xtrabackup --backup و--prepare و--copy-back. وقاعدة Percona أن تستخدم إصداراً من XtraBackup يساوي الإصدار الرئيسي للخادم، أي XtraBackup 8.4 مع MySQL 8.4. أما أداة Oracle الفيزيائية MySQL Enterprise Backup فهي جزء من الإصدار التجاري.

الاستعادة إلى نقطة زمنية عبر السجل الثنائي

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

• فعّله: التسجيل الثنائي مفعّل افتراضياً في MySQL 8.4. وفي MariaDB فعّله بالإعداد log_bin في ملف إعداد الخادم، وتحقق عبر SHOW VARIABLES LIKE 'log_bin';.
• سجّل نقطة بداية كل نسخة: الخيار --master-data=2 في MariaDB أو --source-data=2 في MySQL 8.4 يكتب اسم ملف السجل وموضعه داخل ملف التصدير كتعليق، وتكتبهما mariadb-backup في الملف mariadb_backup_binlog_info (أو xtrabackup_binlog_info في الإصدارات الأقدم).
• احتفظ بالسجلات وانسخها: أبقِ السجلات الثنائية مدة لا تقل عن الفاصل بين نسختين كاملتين، وانسخها خارج الخادم مع النسخ الاحتياطية.

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

mariadb-binlog --start-position=321 \
  --stop-datetime="2026-10-31 15:59:00" \
  /var/lib/mysql/mariadb-bin.000042 > replay.sql
# review replay.sql, then apply it
sudo mariadb < replay.sql

وفي MySQL تسمى الأداة mysqlbinlog، وعند إعادة تنفيذ عدة ملفات سجل يوصي دليل MySQL بتمريرها عبر اتصال واحد.

أيهما تختار؟

في خطط الاستضافة المُدارة قد تتولى المنصة جزءاً من ذلك؛ فخطط الاستضافة لدى Skyline مثلاً تتضمن نسخاً ليلية للمواقع وقواعد البيانات تُحفظ 30 يوماً مع استعادة بنقرة واحدة. أما على خادم افتراضي تديره بنفسك فإعداد كل ما سبق مسؤوليتك.

ما الذي ينبغي فعله

1. حدّد الخادم وإصداره، واستخدم الأدوات المطابقة (أدوات mariadb-* مع MariaDB).
2. خذ تصديراً منطقياً ليلياً مع --single-transaction --routines --events، وتحقق من حالة خروجه، وانسخه خارج الخادم.
3. إن كانت الاستعادة من التصدير بطيئة أكثر من اللازم، فأضف mariadb-backup أو XtraBackup بالإصدار المطابق لخادمك.
4. فعّل السجلات الثنائية واحتفظ بها، وسجّل موضع السجل مع كل نسخة.
5. استعد النسخ إلى خادم اختبار وفق جدول ثابت وقِس الزمن؛ فهذا الرقم هو زمن التعافي الحقيقي لديك.

المصادر

• mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb...
• mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/mariadb-backup-o...
• mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/full-backup-and-...
• mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/point-in-time-re...
• mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/activating-...
• mariadb.com/docs/server/clients-and-utilities/logging-tools/mariadb-binlog/mariadb-binl...
• mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-...
• dev.mysql.com/doc/refman/8.4/en/mysqldump.html
• dev.mysql.com/doc/refman/8.4/en/backup-methods.html
• dev.mysql.com/doc/refman/8.4/en/point-in-time-recovery-binlog.html
• docs.percona.com/percona-xtrabackup/8.4/server-backup-version-comparison.html
• docs.percona.com/percona-xtrabackup/8.4/create-full-backup.html
• docs.percona.com/percona-xtrabackup/8.4/restore-a-backup.html
• qa.debian.org/madison.php?package=mariadb
• packages.debian.org/trixie/amd64/mariadb-client/filelist
• cloud.alskyline.com/hosting