ابدأ الآن

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

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

الاكتشاف

ما يكتشفه Dockstash

متغيرات البيئة المكتشفةMYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD
المنفذ الافتراضي3306
مسارات البيانات الحية (لا تُنسخ حية أبدًا)/var/lib/mysql
أمثلة الصورmysql:8, mysql:8.0, mysql:5.7, mysql
خطوة بخطوة

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

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

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

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

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

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

    افتح المشروع وتبويب Plan. يقرأ Dockstash ملف docker-compose.yml ويتعرف على صورة mysql ويضيف طبقة قاعدة بيانات بأمر التفريغ الصحيح — مع اسم الحاوية والمتغيرات المكتشفة (MYSQL_ROOT_PASSWORD وMYSQL_DATABASE وMYSQL_USER وMYSQL_PASSWORD). يمكنك تفعيل أو تعطيل الملفات والقواعد وإعدادات الوكيل قبل الحفظ.

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

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

    docker exec <mysql-container> sh -c 'mysqldump --all-databases --single-transaction -uroot -p"$MYSQL_ROOT_PASSWORD"' | head -n 20

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

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

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

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

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

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

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

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

الأوامر

أمر التفريغ

mysqldump --all-databases --single-transaction --routines --triggers -uroot -p"$MYSQL_ROOT_PASSWORD"

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

mysql -uroot -p"$MYSQL_ROOT_PASSWORD"

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

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

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

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

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

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

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

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

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

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

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

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

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

المطبات

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

  • لا تشغّل restic أبدًا على الدليل الحي /var/lib/mysql — مساحات جداول InnoDB المنسوخة أثناء الكتابة غير متسقة وستفشل الاستعادة.
  • يمنح --single-transaction لقطة متسقة لجداول InnoDB المعاملاتية فقط؛ MyISAM غير مشمول ويحتاج قفلًا.
  • أضف --routines و--triggers وإلا سقطت الإجراءات المخزنة والمحفزات بصمت من التفريغ.
استكشاف الأخطاء

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

العرض
يفشل التفريغ برسالة «Access denied for user 'root'@'localhost'».
السبب
MYSQL_ROOT_PASSWORD في compose لم يعد يطابق كلمة المرور داخل وحدة التخزين — المتغير يضبطها فقط عند أول تهيئة؛ تغييره لاحقًا لا يؤثر على وحدة موجودة.
العلاج
استخدم كلمة المرور التي هُيّئت بها الوحدة، أو أعد ضبط كلمة مرور root داخل الحاوية، ثم وائم بيئة compose.
العرض
يكتمل التفريغ لكن بعض الجداول غير متسقة بعد الاستعادة.
السبب
تلك الجداول MyISAM. يضمن --single-transaction لقطة متسقة لجداول InnoDB المعاملاتية فقط؛ MyISAM خارج الضمان.
العلاج
افحص المحرك بـ SHOW TABLE STATUS. رحّل جداول MyISAM إلى InnoDB (ALTER TABLE ... ENGINE=InnoDB) — الحل الدائم — أو اقبل قفلًا وجيزًا بـ --lock-tables.
العرض
الاستعادة في حاوية تجريبية تعطي «Unknown collation: utf8mb4_0900_ai_ci».
السبب
التفريغ من MySQL 8.x وأنت تستعيد في صورة 5.7؛ ترتيبات 8.0 الافتراضية غير موجودة في الخوادم الأقدم.
العلاج
استعد إلى الإصدار الرئيسي نفسه للتفريغ (مثل mysql:8). تفريغ قديم إلى خادم أحدث يعمل؛ والعكس كثيرًا ما يفشل.
العرض
يفشل تشغيل النسخ الاحتياطي بقفل restic قديم بعد انهيار أو إعادة تشغيل.
السبب
ماتت مهمة سابقة في منتصف التشغيل وتركت المستودع مقفولًا.
العلاج
لا شيء يدويًا: التشغيل التالي يكتشف القفل اليتيم وينفّذ restic unlock تلقائيًا قبل المتابعة. إن استمر الفشل فراجع لوحة السجلات الحية لمعرفة الخطأ الأصلي.

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

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

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

آخر تحديث: July 2026

ذو صلة

MariaDB

نسخ MariaDB في Docker

PostgreSQL

نسخ PostgreSQL في Docker

MongoDB

نسخ MongoDB في Docker

WordPress

CMS

Matomo

Analytics

Umami

Analytics

Nextcloud

File sync / Collaboration

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

لِمَ --single-transaction مهم؟

من دونه يقرأ mysqldump الجداول واحدًا واحدًا، وكتابة بين جدولين تنتج تفريغًا غير متسق. يغلّف --single-transaction كل شيء في معاملة InnoDB واحدة: التفريغ كله يعكس لحظة واحدة دون قفل كتابة.

هل يتضمن التفريغ الإجراءات المخزنة والمحفزات؟

فقط مع تمرير --routines و--triggers، وهو ما يفعله Dockstash. يغفلها mysqldump الافتراضي — سبب شائع لقاعدة «مستعادة لكنها معطوبة».

هل يمكن نسخ MySQL بنسخ /var/lib/mysql؟

لا. تُكتب مساحة جداول InnoDB وسجلات redo باستمرار؛ نسخ الملفات أثناء الكتابة غير متسق. يشغّل Dockstash بدلًا من ذلك mysqldump داخل الحاوية.

ماذا لو كنت أستخدم جداول MyISAM؟

لا يجعل --single-transaction محرك MyISAM متسقًا لأنه غير معاملاتي. الاعتماد على MyISAM يستلزم قفلًا وجيزًا (--lock-tables) — وترحيل تلك الجداول إلى InnoDB هو الحل الدائم.

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

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

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

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

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

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