ليه بيانات قاعدتك بتختفي بعد كل docker restart؟ الحل في الـ Volumes

المستوى: مبتدئ. هذا الشرح مكتوب لحد بيبدأ مع Docker، ومبني على فرضية إنك بتشغّل الحاوية على سيرفر Linux واحد (مش Kubernetes ولا cluster).

لو شغّلت قاعدة بيانات زي PostgreSQL في Docker، سجّلت مستخدمين، وبعد docker restart لقيت القاعدة رجعت فاضية — ده مش باج، وده مش عطل في PostgreSQL. ده سلوك Docker الطبيعي، والحل سطر واحد. هتكسب من المقال ده إنك تخلّي بياناتك تعيش أطول من الحاوية نفسها.

تخزين بيانات Docker الدائم عبر الـ Volumes

المشكلة باختصار

أي بيانات بتكتبها الحاوية جوّه نظام ملفاتها الخاص بتعيش وتموت مع الحاوية. أول ما الحاوية تتشال أو تتبني من جديد، الكتابة دي بتروح. الـ docker restart لوحده مش بيمسح، لكن أي docker rm ثم docker run — وده اللي بيحصل مع كل تحديث صورة أو تغيير إعداد — بيبدأ بطبقة كتابة نضيفة فاضية.

الحاوية زي غرفة فندق

تخيّل إنك نازل فندق. دخلت الغرفة، رصصت هدومك في الدولاب، وكتبت ملاحظات على السبورة اللي في الغرفة. ده مريح ليك طول ما انت ساكن. لكن ساعة ما تعمل تسجيل خروج (checkout)، شغّالة النظافة بتفضّي الدولاب وتمسح السبورة، وتجهّز الغرفة نضيفة للنزيل اللي بعدك.

الحاوية بالظبط كده. طبقة الكتابة بتاعتها زي السبورة في الغرفة: بتكتب فيها وانت شغّال، بس بمجرد ما الحاوية تتشال، الطبقة دي بتتمسح وتتعمل واحدة فاضية للحاوية الجديدة. عشان بياناتك ما تروحش، محتاج تحطها في «خزنة» خارج الغرفة — والخزنة دي اسمها Volume.

التفسير العلمي: طبقة الكتابة والـ Copy-on-Write

صورة Docker (الـ image) مكوّنة من طبقات (layers) للقراءة فقط. لما تشغّل حاوية، Docker بيضيف فوقها طبقة واحدة قابلة للكتابة اسمها الـ writable layer، وبيربط الطبقات كلها بنظام ملفات موحّد اسمه OverlayFS (الـ storage driver الافتراضي overlay2).

الفكرة اسمها Copy-on-Write: أي ملف موجود في طبقات الصورة بيتقرأ من مكانه مباشرة، لكن أول ما تعدّله، Docker بينسخه للطبقة القابلة للكتابة الأول وبعدين يعدّل النسخة. يعني كل كتابة بتحصل في طبقة الحاوية المؤقتة. وعشان الطبقة دي مربوطة بعمر الحاوية، لما الحاوية تتشال بتروح معاها.

الـ Volume بيكسر الحلقة دي. هو مساحة تخزين على قرص المضيف (host) بيديرها Docker، وبتتوصّل لمسار جوّه الحاوية. أي كتابة على المسار ده بتعدّي طبقة الحاوية بالكامل وبتروح على القرص مباشرة، فبتفضل موجودة بعد ما الحاوية تختفي.

الحل: خطوتين وأنت بتكسب

1. اعمل named volume باسم واضح.
2. اربطه بمسار البيانات جوّه الحاوية بـ -v.

مثال كامل على PostgreSQL، بيانات القاعدة بتتخزّن في /var/lib/postgresql/data:

# 1) اعمل الـ volume مرة واحدة
docker volume create pgdata

# 2) شغّل القاعدة واربط الـ volume بمسار البيانات
docker run -d --name db \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

# 3) الاختبار: امسح الحاوية بالكامل وأعد تشغيلها
docker rm -f db
docker run -d --name db \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16
# البيانات لسه موجودة — لأنها على الـ volume مش في الحاوية

ونفس الفكرة في docker-compose.yml:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

تتأكد إن الـ volume شغّال فعلًا بالأمرين دول:

docker volume ls
docker volume inspect pgdata

Named Volume ولا Bind Mount؟ الـ trade-off

في نوعين شائعين للتخزين الدائم، وكل واحد ليه ثمنه:

• Named volume (زي المثال فوق): Docker هو اللي بيديره ويخزّنه في مساره الخاص. بتكسب: نقل أسهل، صلاحيات أنضف، وأداء I/O أعلى — خصوصًا على Docker Desktop. بتخسر: مش بتوصل للملفات على المضيف بسهولة زي المسار العادي.
• Bind mount (مسار مضيف صريح زي -v /home/app/data:/var/lib/postgresql/data): بتكسب: بتشوف وتعدّل الملفات على المضيف مباشرة، مفيد وقت التطوير. بتخسر: مربوط بمسار وبنية المضيف، وبيجيب مشاكل صلاحيات (UID/GID) وأداء أبطأ على macOS و Windows.

رقم يفرق: توثيق Docker الرسمي بيوضّح إن الكتابة المكثّفة على الـ writable layer عبر الـ copy-on-write أبطأ من الكتابة المباشرة على volume، وإن على Docker Desktop (Mac/Windows) الـ bind mounts بتكون أبطأ بشكل ملحوظ من named volumes بسبب طبقة مشاركة الملفات بين النظامين. القاعدة العملية: لقواعد البيانات استخدم named volume.

سيناريو واقعي

لو عندك API صغير بيخدم 5,000 مستخدم، وبتعمل deploy كل أسبوع بتحديث صورة الحاوية (docker rm ثم docker run بالصورة الجديدة)، من غير volume كل deploy هيبدأ بقاعدة فاضية — يعني تفقد كل حساباتك أسبوعيًا. مع named volume، الصورة بتتغيّر والبيانات بتفضل ثابتة على القرص. نفس الأمر ينطبق على ملفات المستخدمين المرفوعة، إعدادات التطبيق، وملفات Redis اللي عايزها تكمّل بعد restart.

متى لا تستخدم هذه الطريقة

مش كل حاجة محتاجة تعيش. لو البيانات مؤقتة بطبيعتها — كاش تحبّه يتمسح، أو ملفات build وسيطة — سيبها في طبقة الحاوية عادي وخليها تختفي. ولو عندك بيانات حساسة عايزها في الرام بس ومتتكتبش على القرص أبدًا، استخدم --tmpfs بدل الـ volume. الـ Volumes مخصّصة للبيانات اللي لازم تفضل موجودة، مش لكل ملف بتكتبه الحاوية.

الخطوة التالية

افتح أمر تشغيل أطول خدمة قاعدة بيانات عندك دلوقتي، وشوف فيه -v بيربط مسار البيانات بـ volume ولا لأ. لو مش موجود، أضف -v pgdata:/var/lib/postgresql/data، اعمل docker rm ثم شغّل من جديد، وجرّب الـ restart واتأكد إن البيانات باقية. لو راحت، يبقى المسار اللي ربطته مش هو مسار تخزين القاعدة الفعلي — راجعه في توثيق الصورة.

المصادر

• توثيق Docker الرسمي — Volumes: docs.docker.com/engine/storage/volumes
• توثيق Docker الرسمي — Storage overview (volumes vs bind mounts vs tmpfs): docs.docker.com/engine/storage
• توثيق Docker الرسمي — Storage drivers و Copy-on-Write و overlay2: docs.docker.com/engine/storage/drivers
• صورة PostgreSQL الرسمية على Docker Hub (مسار /var/lib/postgresql/data): hub.docker.com/_/postgres