لعمل نسخة احتياطية من وحدة تخزين Docker، تقوم بربطها داخل حاوية مؤقتة وأرشفتها — لا يمكنك ببساطة نسخ المجلد الموجود تحت /var/lib/docker/volumes والوثوق به. الأمر المكوَّن من سطر واحد الذي ينجح مع معظم وحدات التخزين هو حاوية Alpine للاستخدام لمرة واحدة تضغط البيانات بـ tar إلى ملف تتحكم فيه أنت. أما الحقيقة الأصعب، وهي الجزء الذي تتجاوزه معظم الدروس، فهي أن وحدة تخزين قاعدة بيانات حية تُنسخ بهذه الطريقة كثيرًا ما تكون تالفة بشكل خفي، وأن النسخة الاحتياطية التي لم تستعدها من قبل ليست نسخة احتياطية. يغطي هذا الدليل الأوامر الدقيقة، وكيفية التعامل مع قواعد البيانات بشكل صحيح، وكيفية الأتمتة ودفع النسخ إلى خارج الموقع، وكيفية إثبات أن النسخة الاحتياطية تعمل فعلًا.
كيف تعمل نسخة احتياطية من وحدة تخزين Docker؟
الطريقة القياسية هي تشغيل حاوية قصيرة العمر تربط وحدة التخزين المُسمّاة للقراءة فقط وتكتب أرشيف tarball مضغوطًا إلى دليل على المضيف مربوط عبر bind. أمر واحد يتكفل بذلك:
docker run --rm \
-v mydata:/source:ro \
-v $(pwd)/backups:/backup \
alpine tar czf /backup/mydata-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .
هذا يُشغّل Alpine، ويربط وحدة التخزين mydata باسم /source (للقراءة فقط)، ويكتب ملف .tar.gz مختومًا بالوقت داخل ./backups على المضيف. يستخدم دليل النسخ الاحتياطي من OneUptime نمط tar للقراءة فقط نفسه، وهو أقرب ما يكون إلى نهج مرجعي معتمد. وهو ينجح لأن وثائق Docker نفسها تشير إلى أن وحدات التخزين أسهل في النسخ الاحتياطي من bind mounts — إذ تعيش البيانات في موضع واحد مُدار. بالنسبة لذاكرة تخزين مؤقتة لتطبيق عديم الحالة أو مخزن ملفات، هذا كل ما تحتاجه. أما بالنسبة لأي شيء يحتوي على قاعدة بيانات، فلا.
لماذا لا يكفي نسخ وحدة تخزين حية
تفترض النسخ الاحتياطية على مستوى نظام الملفات أن الملفات على القرص في حالة متسقة في اللحظة التي تقرؤها فيها. وقاعدة البيانات قيد التشغيل نادرًا ما تكون كذلك. تحتفظ Postgres وMySQL وMongoDB بعمليات الكتابة في الذاكرة وتُفرِغها إلى القرص وفق جدولها الخاص، لذا فإن ضغط دليل بيانات حي بـ tar قد يلتقط معاملة مكتوبة نصف كتابة أو فهرسًا يشير إلى صفوف لم تصل بعد. عندئذٍ تفشل الاستعادة، أو الأسوأ من ذلك، تُحمِّل بيانات تالفة بصمت. القاعدة العملية لدى الممارسين هي أن عمليات dump الخاصة بقاعدة البيانات متسقة معاملاتيًا، بخلاف النسخ الاحتياطية على مستوى نظام الملفات. أمامك خياران آمنان: إيقاف الحاوية قبل الـ tar (مقبول لمختبر منزلي، سيئ لأي شيء يحتاج إلى توافر)، أو استخدام أداة dump الخاصة بقاعدة البيانات بينما تظل قيد التشغيل. والخيار الثاني هو الإجابة الصحيحة في معظم الأحيان.
انسخ قواعد البيانات باستخدام dumps لا بـ tar
بالنسبة لقاعدة بيانات في حاوية، خذ نسخة dump منطقية باستخدام الأداة الأصلية للمحرك وانسخ ملف الـ dump احتياطيًا بدلًا من وحدة التخزين الخام. ينتج عن ذلك لقطة متسقة حتى بينما تخدم قاعدة البيانات حركة مرور حية. بالنسبة لـ Postgres، يمنحك pg_dump مع --single-transaction تصديرًا متسقًا لنقطة زمنية دون أقفال طويلة، وفقًا لوثائق PostgreSQL الرسمية:
docker exec -t my-postgres \
pg_dump -U postgres --single-transaction mydb \
| gzip > backups/mydb-$(date +%Y%m%d).sql.gz
تستخدم MySQL وMariaDB الأمر mysqldump --single-transaction (متسق لجداول InnoDB)؛ وتستخدم MongoDB الأمر mongodump. يهم الترتيب عند الأتمتة: خذ نسخة dump من قاعدة البيانات أولًا، ثم شغّل نسخة وحدة التخزين أو النسخة خارج الموقع فوق الدليل الذي يحتوي الآن على الـ dump الجديد. وإذا كنت تستضيف ذاتيًا حزمة خلفية كاملة، فإن المنطق نفسه ينطبق على Postgres العاملة تحتها — إذ يعتمد دليل الإنتاج للاستضافة الذاتية لـ Supabase على نمط «الـ dump أولًا ثم التخزين» نفسه بدلًا من نسخ ملفات البيانات.
أتمِتها: الأدوات مقابل restic
تشغيل هذه الأوامر يدويًا مرة واحدة سهل؛ أما تذكّر تشغيلها كل ليلة فهو حيث يفشل من يستضيفون ذاتيًا. هناك نهجان ناضجان يؤتمتان الحلقة بأكملها. تتولى حاوية مُخصصة لهذا الغرض مثل offen/docker-volume-backup الجدولة والتدوير والرفع في صورة واحدة: فهي تنسخ وحدات التخزين احتياطيًا إلى S3 وWebDAV وAzure Blob وDropbox وGoogle Drive أو وجهات SSH، مع تشفير GPG اختياري وتدوير تلقائي للنسخ القديمة، ويمكنها إيقاف حاوية أثناء التشغيل لضمان السلامة عندما تضع لها العلامة المناسبة. البديل هو restic، الذي يمنحك نسخًا احتياطية مشفرة ومُزالة التكرار وتزايدية إلى أي خلفية تقريبًا — ومن الأنماط الشائعة الاحتفاظ بـ --keep-daily 7 --keep-weekly 4 --keep-monthly 6، وبفضل إزالة التكرار، يخزّن كل تشغيل ليلي ما تغيّر فقط.
| الطريقة | متصلة (دون إيقاف)؟ | وجهات خارج الموقع | التشفير | الأفضل لـ |
|---|---|---|---|---|
أمر tar من سطر واحد | لا (أوقفها لقواعد البيانات) | نسخ يدوي | لا شيء (أضف GPG) | لقطات سريعة وعابرة |
offen/docker-volume-backup | إيقاف اختياري | S3، WebDAV، Azure، Dropbox، GDrive، SSH | GPG | نسخ وحدات التخزين بأسلوب «اضبط وانسَ» |
| restic | نعم (مع dumps) | S3، B2، SFTP، REST، محلي | مدمج | تاريخ مُزال التكرار ومُدار بالإصدارات |
dump لقاعدة البيانات (pg_dump) | نعم | التمرير إلى أي مما سبق | عبر الوجهة | قواعد البيانات، دائمًا |
بالنسبة لمعظم الحزم المستضافة ذاتيًا، فإن التركيبة الفائزة هي pg_dump (أو mysqldump) ليلي يُغذّي تشغيل restic الذي يدفع نسخة مشفرة ومُزالة التكرار خارج الجهاز.
طبّق قاعدة 3-2-1 واذهب إلى خارج الموقع
نسخة احتياطية على نفس VPS الذي تحتوي عليه البيانات تحميك من نشرة سيئة، لا من موت الخادم أو انقطاع في الدفع أو برامج الفدية. تعالج قاعدة 3-2-1 العريقة ذلك: احتفظ بـ 3 نسخ من بياناتك، على 2 من الوسائط المختلفة، مع 1 خارج الموقع. عمليًا يعني ذلك: وحدة التخزين الحية، ودليل نسخ احتياطي محلي، ونسخة واحدة على تخزين كائنات بعيد. التخزين خارج الموقع رخيص بما يكفي لجعل التكلفة عذرًا غير مقبول. اعتبارًا من يوليو 2026، تبلغ تكلفة Storage Box BX11 من Hetzner €3.20/شهريًا مقابل 1 TB عبر SSH/SFTP — وهي وجهة طبيعية لـ restic أو rsync — بينما يكلّف Backblaze B2 نحو $7 لكل TB شهريًا عبر واجهة برمجة متوافقة مع S3 يتحدثها كل من restic وoffen/docker-volume-backup بشكل أصلي. أيٌّ منهما يحوّل النسخ الاحتياطي خارج الموقع إلى بضعة يوروهات في الشهر. وإذا كنت تراقب فاتورتك أصلًا بعد زيادات أسعار VPS في 2026، فإن تخزين الكائنات للنسخ الاحتياطية هو آخر مكان تقتطع منه.
استعِدها — واختبِر الاستعادة
الاستعادة هي الجزء الوحيد من النسخة الاحتياطية الذي يهم فعلًا، وهي الخطوة التي يتجاوزها الجميع تقريبًا. لاستعادة نسخة احتياطية بـ tar، أوقف الحاوية، ثم استخرج الأرشيف مرة أخرى إلى وحدة التخزين (الفارغة):
docker run --rm \
-v mydata:/target \
-v $(pwd)/backups:/backup:ro \
alpine tar xzf /backup/mydata-20260717-120000.tar.gz -C /target
بالنسبة لـ dump قاعدة بيانات، حمّله في حاوية جديدة وتحقق من المخطط وأعداد الصفوف قبل أن تثق به. جدوِل تمرين استعادة حقيقيًا — الشهري أمر معقول — داخل حاوية للاستخدام لمرة واحدة، وشغّل التطبيق على البيانات المستعادة، وتأكد من أنه يعمل. النسخة الاحتياطية التي لم تستعدها من قبل هي أمل، لا خطة استرداد. اجعل هذا جزءًا من سير عملك بالطريقة نفسها التي تُحصّن بها جهازًا جديدًا في الساعة الأولى الآمنة من إعداد VPS.
الأسئلة الشائعة
هل يمكنني عمل نسخة احتياطية من وحدة تخزين Docker دون إيقاف الحاوية؟
نعم، مع تحفّظ. بالنسبة لمخازن الملفات وذواكر التخزين المؤقت، ربط وحدة التخزين للقراءة فقط وضغطها بـ tar بينما الحاوية قيد التشغيل أمر جيد. أما بالنسبة لقواعد البيانات، فلا تضغط وحدة التخزين الحية بـ tar — استخدم بدلًا من ذلك أداة dump الخاصة بالمحرك (pg_dump وmysqldump وmongodump)، التي تنتج تصديرًا متسقًا دون إيقاف الخدمة.
أين تُخزَّن وحدات تخزين Docker فعلًا؟
على Linux، تعيش وحدات التخزين المُسمّاة تحت /var/lib/docker/volumes/<name>/_data. يمكنك تقنيًا نسخ ذلك الدليل، لكن النسخ الاحتياطي عبر حاوية (أو dump لقواعد البيانات) أكثر أمانًا وقابلية للنقل بين المضيفين، ولهذا توصي وثائق Docker بنهج ربط وحدة التخزين.
ما أفضل أداة لأتمتة النسخ الاحتياطي لوحدات تخزين Docker؟
للنسخ الاحتياطي لوحدات التخزين دون تدخّل، مع جدولة وتدوير ورفع سحابي مدمجة، فإن offen/docker-volume-backup هو الخيار الأشهر ذو الحاوية الواحدة. أما للحصول على تاريخ مُزال التكرار ومشفّر ومُدار بالإصدارات عبر عدة خلفيات، فإن restic هو الخيار الأقوى. تجمع كثير من الإعدادات بين dump ليلي لقاعدة البيانات ودفعة restic إلى خارج الموقع.
كم مرة ينبغي أن أنسخ احتياطيًا؟
طابِق التكرار مع حجم البيانات التي يمكنك تحمّل فقدانها. الليلي هو الوضع الافتراضي الشائع للتطبيقات المستضافة ذاتيًا؛ وقد تستدعي قاعدة بيانات مزدحمة عمليات dump كل ساعة. أيًّا كان الإيقاع، احتفظ بعدة أجيال (على سبيل المثال 7 يومية، و4 أسبوعية، و6 شهرية) حتى يظل أي تلف تلاحظه متأخرًا قابلًا للاسترداد.
Sources
- OneUptime — كيفية النسخ الاحتياطي واستعادة وحدات تخزين Docker: أوامر النسخ الاحتياطي والاستعادة بـ
tarللقراءة فقط، والنقطة القائلة إن عمليات dump لقواعد البيانات متسقة معاملاتيًا حيث لا تكون النسخ الاحتياطية على مستوى نظام الملفات كذلك. - Docker Docs — Volumes: الإرشاد الرسمي بأن وحدات التخزين أسهل في النسخ الاحتياطي والترحيل من bind mounts، وأين تُخزَّن بيانات وحدة التخزين.
- وثائق PostgreSQL — pg_dump: سلوك الـ dump المتسق لـ
--single-transactionلقواعد البيانات الحية. - offen/docker-volume-backup (GitHub): خلفيات التخزين المدعومة، وتشفير GPG، والجدولة، وإيقاف الحاوية أثناء النسخ الاحتياطي، والتدوير.
- restic: نسخ احتياطية مشفرة ومُزالة التكرار وتزايدية عبر خلفيات تخزين متعددة.
- Hetzner Storage Box وأسعار Backblaze B2: تكاليف التخزين خارج الموقع المذكورة (يوليو 2026).
وقاص احمد وسیر
وقاص احمد وسیر مطوّر ومهندس أتمتة بخبرة تزيد على 8 سنوات في بناء أنظمة إنتاجية يستخدمها أكثر من 100 ألف شخص. يبني تطبيقات SaaS متعددة المستأجرين، وأتمتة بالذكاء الاصطناعي (n8n، تدفقات LLM، بوتات واتساب)، وبنية استضافة (WHM/cPanel، CloudLinux) — وهو صانع WaSphere وFlowMaticX وعلامة الاستضافة WaseerHost. أنجز أكثر من 100 مشروع لشركات صغيرة ومتوسطة ووكالات وشركات ناشئة ممولة.
