ابدأ الآن

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

نسخ MongoDB بأمان قاعدةٌ واحدة: فرّغ ولا تنسخ. ينتج `mongodump --archive --oplog` تفريغًا متسقًا قابلًا للاستعادة من الحاوية العاملة، يشفّره restic بعدها خارجيًا. يسجّل --oplog العمليات أثناء التفريغ ليعيد mongorestore --oplogReplay بناء لقطة متسقة زمنيًا. كل ما ينسخ /data/db حيًا يخاطر بنسخة غير قابلة للاستعادة.

الاكتشاف

ما يكتشفه Dockstash

متغيرات البيئة المكتشفةMONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE
المنفذ الافتراضي27017
مسارات البيانات الحية (لا تُنسخ حية أبدًا)/data/db
أمثلة الصورmongo:7, mongo:6, mongo:5, mongo
خطوة بخطوة

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

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

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

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

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

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

    افتح المشروع وتبويب Plan. يقرأ Dockstash ملف docker-compose.yml ويتعرف على صورة mongo ويضيف طبقة قاعدة بيانات بأمر التفريغ الصحيح — مع اسم الحاوية والمتغيرات المكتشفة (MONGO_INITDB_ROOT_USERNAME وMONGO_INITDB_ROOT_PASSWORD وMONGO_INITDB_DATABASE). فعّل أو عطّل الملفات والقواعد وإعدادات الوكيل قبل الحفظ.

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

    إن أردت دليلًا قبل الأتمتة، شغّل التفريغ نفسه — يكتب mongodump أرشيفًا واحدًا إلى stdout موجّهًا إلى عدّاد بايتات. عدد بايتات كبير وغير صفري يثبت تدفق الأرشيف نظيفًا. هذا الأرشيف هو ما يُنسخ، وليس الدليل الحي /data/db أبدًا.

    docker exec <mongo-container> sh -c 'mongodump --archive --oplog' | wc -c

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

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

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

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

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

    انقر Backup Now. ينفّذ Dockstash الأمر mongodump مع --archive و--oplog داخل الحاوية ويدفق الأرشيف مباشرة إلى restic — تابع المخرجات الحية في لوحة السجلات.

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

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

الأوامر

أمر التفريغ

mongodump --archive --oplog

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

mongorestore --archive --oplogReplay --drop

يسجّل --oplog العمليات أثناء التفريغ ليعيد mongorestore --oplogReplay بناء لقطة متسقة زمنيًا.

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

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

نسخة MongoDB الاحتياطية لا تصبح حقيقية إلا بعد استعادتها. استعادات Dockstash لا تكتب فوق قاعدتك الحية افتراضيًا — إلى منطقة staging جديدة أولًا حيث يُعاد تشغيل الأرشيف وتُفحص البيانات ثم تُرقّى بوعي.

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

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

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

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

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

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

    docker exec <mongo-container> mongosh --quiet --eval "db.adminCommand({ listDatabases: 1 })"

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

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

المطبات

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

  • لا تشغّل restic أبدًا على ملفات WiredTiger الحية في /data/db — منسوخة في منتصف checkpoint تكون غير متسقة وغالبًا غير قابلة للإنقاذ.
  • يتطلب --oplog أن يكون الخادم عضو replica set (ولو بعقدة واحدة)؛ على mongod المستقل هو بلا أثر ولا ضمانة point-in-time.
  • عند الاستعادة يجب أن يرافق --oplogReplay تفريغات --oplog وإلا ضاع اتساق point-in-time.
استكشاف الأخطاء

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

العرض
يفشل التفريغ برسالة «--oplog mode only supported on replica set members» (أو نحوها).
السبب
يعمل mongod لديك standalone. يحتاج --oplog إلى oplog يقرأه، ولا يحتفظ به إلا أعضاء replica set — لا شيء يُلتقط على خادم standalone.
العلاج
حوّله إلى replica set بعقدة واحدة: شغّل mongod بـ --replSet rs0 ونفّذ rs.initiate() مرة واحدة. الحاوية نفسها والبيانات نفسها، مع ضمانة point-in-time.
العرض
يفشل mongodump برسالة «Authentication failed» رغم ضبط MONGO_INITDB_ROOT_USERNAME في compose.
السبب
متغيرات MONGO_INITDB_* تنشئ المستخدم فقط عند أول تهيئة لوحدة /data/db فارغة. إن كانت الوحدة موجودة أصلًا أو غُيّرت البيانات لاحقًا فقيم compose لم تعد تعكس الواقع.
العلاج
صادق بالبيانات الموجودة فعلًا في القاعدة (تحقق عبر mongosh) أو أعد إنشاء المستخدم ثم وائم بيئة compose.
العرض
يفشل mongorestore في الحاوية التجريبية بخطأ إصدار غير مدعوم أو أرشيف غير صالح.
السبب
الأرشيف من خادم أو mongodump أحدث مما تفهمه الوجهة — استعادة أرشيف mongo:7 في mongo:5 غير مدعومة.
العلاج
استعد إلى الإصدار الرئيسي نفسه (مثل mongo:7) وأبقِ mongodump/mongorestore من إصدار Database Tools نفسه. ترقية الإصدارات يجريها الخادم بعد الاستعادة لا mongorestore.
العرض
يفشل تشغيل النسخ الاحتياطي بقفل restic قديم بعد انهيار أو إعادة تشغيل.
السبب
ماتت مهمة سابقة في منتصف التشغيل وتركت المستودع مقفولًا.
العلاج
لا شيء يدويًا: التشغيل التالي يكتشف القفل اليتيم وينفّذ restic unlock تلقائيًا قبل المتابعة. إن استمر الفشل فراجع لوحة السجلات الحية لمعرفة الخطأ الأصلي.

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

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

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

آخر تحديث: July 2026

ذو صلة

PostgreSQL

نسخ PostgreSQL في Docker

Redis

نسخ Redis في Docker

Elasticsearch

نسخ Elasticsearch في Docker

n8n

Workflow automation

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

ماذا يفعل --oplog فعليًا؟

يسجّل مدخلات سجل العمليات الحاصلة أثناء عمل mongodump ويحفظها في الأرشيف. عند الاستعادة يطبّقها --oplogReplay ليعكس التفريغ لحظة واحدة متسقة بدل تمويه عبر نافذة التفريغ.

هل أحتاج replica set لنسخ متسقة؟

لاتساق point-in-time نعم — يعمل --oplog على عضو replica set فقط. كثير من النشرات أحادية العقدة تعمل كمجموعة من عضو واحد لهذه الضمانة تحديدًا.

لماذا لا ننسخ /data/db مباشرة؟

يكتب WiredTiger نقاط تفتيش باستمرار. نسخ الملفات في منتصف checkpoint يلتقط حالة غير متسقة كثيرًا ما لا تعمل. يقرأ mongodump لقطة منطقية قابلة للاستعادة.

كيف أستعيد إلى قاعدة نظيفة؟

يحذف mongorestore --archive --oplogReplay --drop المجموعات القائمة قبل الاستعادة كيلا تختلط البيانات القديمة بالجديدة. يستعيد Dockstash افتراضيًا إلى وجهة staging أولًا.

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

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

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

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

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

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