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

# 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:

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

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