ابدأ الآن

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

يحتاج PostgreSQL تفريغًا متسقًا قبل أن يلمس restic. ينفّذ Dockstash الأمر `pg_dumpall -U "$POSTGRES_USER"` داخل الحاوية ويلتقط المخرجات ويخزنها مشفّرة خارجيًا — ولا ينسخ /var/lib/postgresql/data حيًا أبدًا، لأن يقرأ pg_dumpall لقطة MVCC متسقة: تُلتقط كل قاعدة في لحظة واحدة دون حجب الكتّاب.

الاكتشاف

ما يكتشفه Dockstash

متغيرات البيئة المكتشفةPOSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB
المنفذ الافتراضي5432
مسارات البيانات الحية (لا تُنسخ حية أبدًا)/var/lib/postgresql/data
أمثلة الصورpostgres:16-alpine, postgres:16, postgres:15, postgres
خطوة بخطوة

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

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

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

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

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

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

    افتح المشروع وانظر إلى تبويب Plan. يقرأ Dockstash ملف docker-compose.yml ويتعرف على صورة postgres ويضيف طبقة قاعدة بيانات بأمر التفريغ الصحيح — مع اسم الحاوية المحلول ومتغيرات البيئة المكتشفة (POSTGRES_USER وPOSTGRES_PASSWORD وPOSTGRES_DB). يمكنك تفعيل أو تعطيل الملفات وقواعد البيانات وإعدادات الوكيل قبل الحفظ.

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

    إن أردت دليلًا قبل الأتمتة، شغّل التفريغ نفسه الذي سيشغّله Dockstash. سترى تدفق تعليمات SQL — هذا المخرج هو ما يُنسخ احتياطيًا، وليس دليل البيانات الحي أبدًا.

    docker exec <postgres-container> sh -c 'pg_dumpall -U "$POSTGRES_USER"' | head -n 20

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

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

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

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

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

    انقر Backup Now على بطاقة المشروع. ينفّذ Dockstash الأمر pg_dumpall داخل الحاوية العاملة ويدفق التفريغ مباشرة إلى restic — يمكنك متابعة مخرجات restic الحية سطرًا سطرًا في لوحة السجلات.

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

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

الأوامر

أمر التفريغ

pg_dumpall -U "$POSTGRES_USER"

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

psql -U "$POSTGRES_USER"

يقرأ pg_dumpall لقطة MVCC متسقة: تُلتقط كل قاعدة في لحظة واحدة دون حجب الكتّاب.

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

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

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

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

    افتح Snapshots واختر المشروع وتصفح الخط الزمني لنقاط الاستعادة. كل صف هو تفريغ كامل ومتسق لكل قواعد العنقود، مع ملفات المشروع الملتقطة في التشغيل نفسه.

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

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

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

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

    docker exec <postgres-container> sh -c 'psql -U "$POSTGRES_USER" -c "\l"'

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

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

المطبات

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

  • لا تشغّل restic أبدًا على الدليل الحي /var/lib/postgresql/data — صفحة heap منسوخة أثناء الكتابة ممزقة وغير قابلة للاستعادة.
  • يلتقط pg_dumpall الأدوار وكل قواعد البيانات؛ أما pg_dump منفردًا فيفوّت الكائنات العامة كالأدوار وtablespaces.
  • يجب تثبيت الإضافات (PostGIS وpgvector) في صورة الوجهة قبل الاستعادة وإلا فشل SQL.
استكشاف الأخطاء

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

العرض
يفشل التفريغ برسالة «role does not exist» أو أخطاء مصادقة.
السبب
قيمة POSTGRES_USER في compose لم تعد تطابق دورًا فعليًا في القاعدة — شائع بعد إعادة تسمية دور يدويًا أو استعادة وحدة تخزين من مشروع آخر.
العلاج
شغّل psql داخل الحاوية وافحص الأدوار الفعلية بـ \du ثم وائم بيئة compose (أو بيانات اعتماد التفريغ في الخطة) مع دور superuser موجود.
العرض
يفشل SQL المستعاد برسالة «extension ... is not available».
السبب
يشير التفريغ إلى CREATE EXTENSION (مثل PostGIS أو pgvector) لكن صورة وجهة الاستعادة لا تتضمن ثنائيات تلك الإضافات.
العلاج
استعد إلى الصورة نفسها التي تستخدمها خدمة الإنتاج (مثل postgis/postgis أو بناء يتضمن pgvector) لا إلى صورة postgres خام.
العرض
النسخ صارت فجأة أبطأ بكثير أو المستودع يتضخم بسرعة.
السبب
مخرجات pg_dumpall تتغير كتلةً عندما تكتب الجداول الكبيرة بكثافة، ما يقلل إزالة التكرار في restic.
العلاج
أبقِ الجدول يوميًا ودع prune مع سياسة الاحتفاظ يشذّبان التاريخ؛ وللعناقيد الضخمة تأكد من اتجاه حجم المستودع على بطاقة المشروع أن الاحتفاظ يعمل فعلًا.
العرض
يفشل تشغيل النسخ الاحتياطي بقفل restic قديم بعد انهيار أو إعادة تشغيل.
السبب
ماتت مهمة سابقة في منتصف التشغيل وتركت المستودع مقفولًا.
العلاج
لا شيء يدويًا: التشغيل التالي يكتشف القفل اليتيم وينفّذ restic unlock تلقائيًا قبل المتابعة. إن استمر الفشل فراجع لوحة السجلات الحية لمعرفة الخطأ الأصلي.

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

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

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

آخر تحديث: July 2026

ذو صلة

MySQL

نسخ MySQL في Docker

MariaDB

نسخ MariaDB في Docker

MongoDB

نسخ MongoDB في Docker

n8n

Workflow automation

Supabase

Backend-as-a-Service

Directus

Headless CMS

Plausible Analytics

Analytics

Metabase

Business intelligence

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

لماذا pg_dumpall بدل نسخ دليل البيانات؟

دليل بيانات Postgres الحي يُكتب باستمرار. نسخه يلتقط حالة ممزقة وغير متسقة لن تعمل. يقرأ pg_dumpall لقطة MVCC متسقة من الخادم العامل وينتج تفريغًا يُستعاد نظيفًا.

هل يقفل Dockstash القاعدة أثناء النسخ؟

لا. يستخدم pg_dumpall لقطات MVCC: القراءة متسقة دون حجب الكتابة. يواصل تطبيقك خدمة الزيارات أثناء التفريغ.

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

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

كيف أستعيد قاعدة واحدة بدل الكل؟

أرشيف pg_dumpall هو SQL خام؛ يمكنك استعادة العنقود كله بـ psql أو استخدام pg_dump/pg_restore لكل قاعدة. يستعيد Dockstash افتراضيًا اللقطة المتسقة الكاملة.

ماذا عن إضافات مثل PostGIS أو pgvector؟

يشير التفريغ إلى CREATE EXTENSION لكنه لا يحمل الثنائيات. تأكد أن صورة وجهة الاستعادة توفر الإضافات نفسها قبل الاستعادة.

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

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

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

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