ابدأ الآن

كيف تنسخ حاوية Docker لـMariaDB احتياطيًا (2026)

الطريقة الصحيحة لنسخ حاوية MariaDB هي تفريغ منطقي لا نسخ ملفات. نفّذ `mariadb-dump --all-databases --single-transaction --routines --triggers -uroot -p"$MARIADB_ROOT_PASSWORD"` داخل الحاوية وانسخ مخرجاته. نسخ /var/lib/mysql بينما يكتب MariaDB ينتج لقطة غير متسقة؛ يغلّف --single-transaction التفريغ في معاملة InnoDB واحدة فيلتقط كل الجداول عند نقطة متسقة واحدة دون قفل كتابة.

الاكتشاف

ما يكتشفه Dockstash

متغيرات البيئة المكتشفةMARIADB_ROOT_PASSWORD, MYSQL_ROOT_PASSWORD, MARIADB_DATABASE, MARIADB_USER
المنفذ الافتراضي3306
مسارات البيانات الحية (لا تُنسخ حية أبدًا)/var/lib/mysql
أمثلة الصورmariadb:11, mariadb:10.11, mariadb:10, mariadb
خطوة بخطوة

انسخ MariaDB مع Dockstash خطوة بخطوة

  1. أنشئ حساب Dockstash وافتح لوحة التحكم

    سجّل مجانًا على app.dockstash.com/register. يسألك معالج الإعداد لمرة واحدة عن خادم التخزين VPS (الجهاز الذي سيحتفظ بالنسخ الاحتياطية المشفّرة) ويولّد كلمة مرور تشفير — احفظها فورًا في مدير كلمات مرور، فهي تُعرض مرة واحدة فقط.

  2. أضف مشروع Docker الذي يشغّل MariaDB

    في شاشة Projects يكتشف Dockstash تلقائيًا كل مجلد مشروع Compose على الخادم (افتراضيًا تحت /var/www). اختر المشروع الذي يحتوي خدمة MariaDB. لم يُنسخ شيء بعد — أنت فقط تخبر Dockstash أين يقيم المشروع.

  3. تحقق من اكتشاف MariaDB

    افتح المشروع وتبويب Plan. يقرأ Dockstash ملف docker-compose.yml ويتعرف على صورة mariadb ويضيف طبقة قاعدة بيانات بأمر التفريغ الصحيح — مع اسم الحاوية والمتغيرات المكتشفة (MARIADB_ROOT_PASSWORD أو القديم MYSQL_ROOT_PASSWORD، إضافة إلى MARIADB_DATABASE وMARIADB_USER). فعّل أو عطّل الملفات والقواعد وإعدادات الوكيل قبل الحفظ.

  4. اختياري: تحقق من التفريغ يدويًا

    إن أردت دليلًا قبل الأتمتة، شغّل التفريغ نفسه — mariadb-dump مع --single-transaction. سترى SQL يتدفق: CREATE DATABASE وCREATE TABLE وINSERT. هذا المخرج هو ما يُنسخ، وليس الدليل الحي /var/lib/mysql.

    docker exec <mariadb-container> sh -c 'mariadb-dump --all-databases --single-transaction -uroot -p"$MARIADB_ROOT_PASSWORD"' | head -n 20

  5. أكّد وجهة التخزين

    تُخزَّن النسخ كلقطات restic مشفّرة على خادم التخزين VPS الخاص بك عبر SSH. إن أكملت معالج الإعداد فهي مهيّأة بالفعل؛ ويمكنك تغيير المضيف والمستخدم والمنفذ ومفتاح SSH في أي وقت من Settings → Storage.

  6. اضبط جدول النسخ الاحتياطي

    في تبويب Schedule اختر يوميًا أو أسبوعيًا أو cron مخصصًا (يُتحقق أثناء الكتابة). يوميًا في ساعة هادئة هو الافتراضي الصحيح لمعظم مشاريع MariaDB. أضف prune أسبوعيًا مع سياسة الاحتفاظ.

  7. شغّل أول نسخة احتياطية الآن

    انقر Backup Now. ينفّذ Dockstash الأمر mariadb-dump مع --single-transaction و--routines و--triggers داخل الحاوية ويدفق التفريغ مباشرة إلى restic — تابع المخرجات الحية في لوحة السجلات.

  8. تأكد من وجود اللقطة

    عند انتهاء التشغيل تعرض بطاقة المشروع وقت آخر نسخة وعدد اللقطات وحجم المستودع. افتح شاشة Snapshots وسترى نقطة الاستعادة في الخط الزمني — هذا دليلك على وصول النسخة إلى موقعها الخارجي.

الأوامر

أمر التفريغ

mariadb-dump --all-databases --single-transaction --routines --triggers -uroot -p"$MARIADB_ROOT_PASSWORD"

أمر الاستعادة

mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"

يغلّف --single-transaction التفريغ في معاملة InnoDB واحدة فيلتقط كل الجداول عند نقطة متسقة واحدة دون قفل كتابة.

الاستعادة والتحقق

استعد نسخة MariaDB وأثبت أنها تعمل

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

  1. اختر نقطة استعادة

    افتح Snapshots واختر المشروع وتصفح الخط الزمني. كل صف تفريغ كامل للحظة واحدة لكل قواعد الخادم — المخططات والبيانات والإجراءات والمحفزات — مع ملفات المشروع من التشغيل نفسه.

  2. استعد إلى موقع جديد

    انقر Restore وأبقِ الوضع الافتراضي «Restore to new location». اكتب اسم المشروع للتأكيد — إجراء متعمّد بتأكيد مكتوب. يهبط التفريغ والملفات في المسار الهدف الذي تختاره دون المساس بالمشروع الحي.

  3. تحقق من البيانات المستعادة

    حمّل التفريغ في حاوية MariaDB تجريبية ونفّذ SHOW DATABASES عبر عميل mariadb للتأكد من عودة كل مخطط، وافحص عينات من جداول تطبيقك.

    docker exec <mariadb-container> sh -c 'mariadb -uroot -p"$MARIADB_ROOT_PASSWORD" -e "SHOW DATABASES;"'

  4. رقِّ النتيجة عند الاقتناع

    بعد التحقق من البيانات المستعادة وجّه تطبيقك إليها (أو أعد الاستعادة بوضع «Overwrite existing» — موافقة صريحة). الأفضل: دع تدريب الاستعادة الأسبوعي ينتج هذا الدليل تلقائيًا كي لا تكون الاستعادة الحقيقية أول بروفة لك.

المطبات

مطبات يجب تجنبها

  • لا تشغّل restic أبدًا على الدليل الحي /var/lib/mysql — نسخة InnoDB أثناء الكتابة غير قابلة للاستعادة.
  • الصور الجديدة تحمل mariadb-dump؛ والقديمة تستخدم mysqldump. يكتشف Dockstash الثنائي الذي توفره الصورة.
  • تقبل MariaDB مفتاح MARIADB_ROOT_PASSWORD أو المفتاح القديم MYSQL_ROOT_PASSWORD — وكلاهما يُكتشف.
استكشاف الأخطاء

مشكلات شائعة في نسخ MariaDB

العرض
يفشل التفريغ اليدوي برسالة «mariadb-dump: command not found».
السبب
صور MariaDB الأقدم (10.4 فأدنى) تحمل ثنائي mysqldump فقط؛ جاء mariadb-dump لاحقًا وبقي mysqldump وصلة توافق على الصور الجديدة.
العلاج
استخدم mysqldump بالخيارات نفسها على الصور القديمة — المخرجات مطابقة. يكتشف Dockstash الثنائي المتوفر في الصورة ويستدعي الصحيح تلقائيًا.
العرض
يفشل التفريغ برسالة «Access denied for user 'root'@'localhost'».
السبب
مفتاح كلمة مرور root في compose (MARIADB_ROOT_PASSWORD أو القديم MYSQL_ROOT_PASSWORD) لم يعد يطابق كلمة المرور الفعلية للوحدة — يضبطها المتغير فقط عند أول تهيئة.
العلاج
استخدم كلمة مرور التهيئة الأولى للوحدة أو أعد ضبط root داخل الحاوية ثم وائم بيئة compose.
العرض
استعادة التفريغ في حاوية MySQL تفشل بأخطاء صياغة.
السبب
تباعد MariaDB وMySQL — تسلسلات MariaDB وبعض الترتيبات وخيارات التخزين غير موجودة في MySQL؛ الاستعادة العابرة للمحركات قد تنكسر.
العلاج
استعد إلى صورة MariaDB من الإصدار الرئيسي نفسه للتفريغ. ولا تجرِ ترحيل MariaDB → MySQL إلا عمدًا بعد تنظيف التفريغ.
العرض
يفشل تشغيل النسخ الاحتياطي بقفل restic قديم بعد انهيار أو إعادة تشغيل.
السبب
ماتت مهمة سابقة في منتصف التشغيل وتركت المستودع مقفولًا.
العلاج
لا شيء يدويًا: التشغيل التالي يكتشف القفل اليتيم وينفّذ restic unlock تلقائيًا قبل المتابعة. إن استمر الفشل فراجع لوحة السجلات الحية لمعرفة الخطأ الأصلي.

أنجزه بنقرة واحدة مع Dockstash

ينفّذ Dockstash التفريغ أعلاه بالضبط ويسلّمه إلى restic خارجيًا ويختبر الاستعادة بتدريب تلقائيًا — بلا سكربت تصونه.

ابدأ مجانًاكل الأدلة

آخر تحديث: July 2026

ذو صلة

MySQL

نسخ MySQL في Docker

PostgreSQL

نسخ PostgreSQL في Docker

MongoDB

نسخ MongoDB في Docker

Appwrite

Backend-as-a-Service

WordPress

CMS

Nextcloud

File sync / Collaboration

الأسئلة الشائعة

هل تُنسخ MariaDB كما تُنسخ MySQL؟

تقريبًا بالمثل. كلاهما يستخدم --single-transaction للقطة InnoDB متسقة. الفرق في ثنائي العميل: صور MariaDB الحديثة تحمل mariadb-dump (وmysqldump وصلة توافق). يختار Dockstash الصحيح.

أي مفتاح كلمة مرور root يكتشفه Dockstash؟

كلا المفتاحين MARIADB_ROOT_PASSWORD وMYSQL_ROOT_PASSWORD القديم، إذ تقبل صور MariaDB أيًا منهما حسب الإصدار.

هل يمكن استعادة تفريغ MariaDB في MySQL أو العكس؟

غالبًا لكن ليس دائمًا — انحراف الميزات والصياغة بينهما يكسر الحالات الحدية. للنتيجة الموثوقة استعد إلى عائلة المحرك نفسها للتفريغ.

لماذا لا نأخذ لقطة للوحدة فحسب؟

وحدة /var/lib/mysql تُكتب باستمرار. لقطة أثناء الكتابة غير متسقة. التفريغ المنطقي عبر mariadb-dump هو الطريق القابل للاستعادة.

كم مرة يجب نسخ MariaDB احتياطيًا؟

يوميًا هو الافتراضي العملي لمعظم المشاريع؛ وكل ساعة إن كان فقدان يوم من الكتابات غير مقبول. في خطة Free النسخ يدوي فقط؛ Pro تسمح بجداول حتى كل ساعة، وBusiness بأي cron. اقرن الجدول بتدريب استعادة أسبوعي.

أين تعيش النسخ الاحتياطية فعليًا؟

على خادم التخزين VPS الخاص بك، كلقطات restic مشفّرة تُدفع عبر SSH. لا يحتفظ Dockstash ببياناتك أبدًا على سحابة طرف ثالث — أنت توجّهه إلى جهاز تتحكم فيه، والمستودع مشفّر بكلمة مرور لا يملكها سواك.

كيف أعرف أن النسخة قابلة للاستعادة دون استعادة يدوية؟

جدوِل تدريب استعادة. يستعيد Dockstash أحدث لقطة إلى مساحة عمل معزولة، ويقارن كل ملف بايتًا ببايت مع المصدر، ويتحقق من التفريغ المستعاد — ثم يختم المشروع بشارة نجاح/فشل. تدريب أسبوعي يعني دليلًا طازجًا دائمًا.