كيف تنسخ قاعدة بيانات تطبيقك احتياطيًا (وتستعيدها فعلًا)

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

هذا الدليل موجّه لمن يشغّل تطبيقًا صغيرًا ويريد أن يتوقف عن القلق من فقدانه. يستخدم Postgres في الأمثلة، لأن معظم التطبيقات المبنية بالذكاء الاصطناعي تستخدمه، لكن المبادئ تنطبق على أي قاعدة بيانات.

ما الذي يجب أن تغطيه النسخة الاحتياطية

التطبيق أكثر من قاعدة بياناته. اعرف أي جزء تحميه كل نسخة احتياطية.

البيانات هي الجزء الذي لا يمكن إعادة إنشائه. يمكن إعادة كتابة الكود وإعادة إدخال الإعدادات، أما طلبات عملائك فلا.

الخطوة 1: قرّر حجم ما يمكنك خسارته

هناك سؤالان يحددان خطة النسخ الاحتياطي:

• كم من البيانات الحديثة يمكنك أن تخسر؟ إذا نسخت مرة واحدة يوميًا وتعطلت قاعدة البيانات مساءً، فستخسر تغييرات ذلك اليوم. بالنسبة لتطبيق هواة فهذا مقبول. أما لتطبيق يستقبل طلبات، فقد لا يكون كذلك.
• كم يمكن أن يبقى التطبيق متوقفًا أثناء الاستعادة؟ قاعدة البيانات الصغيرة تُستعاد في دقائق، أما الكبيرة فقد تستغرق وقتًا أطول بكثير، ومن المهم أن تعرف ذلك قبل أن تحتاجه.

بالنسبة لمعظم التطبيقات الصغيرة، يُعد نسخًا تلقائيًا يوميًا مع نسخة يدوية قبل التغييرات الخطرة بداية معقولة. أما التطبيقات التي تتعامل مع أموال أو بيانات صحية فتستحق نسخًا أكثر تكرارًا، أو قاعدة بيانات مُدارة تتيح الاستعادة إلى نقطة زمنية محددة (أي استعادة إلى أي لحظة، لا إلى آخر نسخة فقط).

الخطوة 2: تحقق مما يفعله مزوّد الاستضافة بالفعل

كثير من مزوّدي قواعد البيانات المُدارة يأخذون نسخًا احتياطية تلقائية. تحقق من التالي:

• هل النسخ الاحتياطية مفعّلة في خطتك، وكم مرة تعمل؟
• كم من الوقت تُحفظ؟
• هل يمكنك الاستعادة إلى نقطة زمنية، أم فقط إلى لقطة يومية؟
• هل يمكنك تنزيل النسخة، أم تستعيدها داخل نظامهم فقط؟

النسخ الاحتياطية التي يقدمها المزوّد مفيدة، لكنها تشترك في نقطة فشل واحدة مع قاعدة البيانات نفسها: الحساب. إذا أُغلق الحساب أو عُلّق أو حُذف المشروع، فقد تذهب النسخ معه. لذلك تحتاج أيضًا إلى نسخة خاصة بك.

الخطوة 3: أنشئ نسخة بـ pg_dump

pg_dump يصدّر قاعدة بيانات Postgres إلى ملف. وهو يقرأ لقطة متسقة، لذلك يمكن للتطبيق أن يواصل العمل أثناء تشغيله.

أمر نموذجي، يستخدم سلسلة الاتصال التي يملكها تطبيقك بالفعل في متغير بيئة:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

ما تفعله الخيارات:

• --format=custom يكتب ملفًا مضغوطًا يقرؤه pg_restore، ويتيح لك استعادة جداول مفردة لاحقًا. استخدم --format=plain إذا أردت ملف .sql قابلًا للقراءة.
• --no-owner يحذف أوامر الملكية، مما يجعل الاستعادة إلى قاعدة بيانات مختلفة أبسط.
• التاريخ في اسم الملف يفصل النسخ عن بعضها.

يجب أن تكون نسخة pg_dump بالإصدار نفسه لإصدار Postgres لديك أو أحدث منه. النسخة الأقدم قد ترفض العمل.

إذا كنت تبني بالذكاء الاصطناعي ولا تريد التعامل مع سطر الأوامر، يمكنك أن تطلب:

أنشئ نسخة احتياطية من قاعدة بيانات التطبيق باستخدام pg_dump بتنسيق custom، مع تاريخ اليوم في اسم الملف. لا تطبع سلسلة الاتصال أو أي سر. أخبرني باسم الملف وحجمه عند الانتهاء.

الخطوة 4: اجعلها تلقائية

النسخ اليدوي يُنسى. أتمتها بما يدعمه إعدادك:

• النسخ المجدولة لمزوّد قاعدة البيانات، إذا كان يقدمها.
• مهمة مجدولة على خادم أو خدمة CI تشغّل pg_dump وترفع الملف إلى التخزين.
• خدمة نسخ احتياطي مستضافة تتصل بقاعدة بياناتك.

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

الخطوة 5: احفظ النسخ في مكان آخر

القاعدة المعروفة تسمى 3-2-1: ثلاث نسخ من بياناتك، على نوعين مختلفين من التخزين، مع نسخة واحدة خارج الموقع. للتطبيق الصغير، نسخة عملية من هذه القاعدة هي:

• قاعدة البيانات الحية
• النسخ التلقائية التي يقدمها المزوّد
• نسخك الخاصة في تخزين منفصل، مثل حاوية تخزين كائنات في حساب مختلف

وأيضًا:

• قيّد الوصول. النسخة الاحتياطية تحتوي على بيانات كل مستخدم، فعاملها معاملة قاعدة البيانات الحية.
• ضع سياسة للاحتفاظ. مثلًا، نسخ يومية لمدة أسبوعين ونسخ شهرية لمدة سنة. احذف القديم عن قصد، وتذكّر أن قوانين الخصوصية قد تفرض حذف البيانات الشخصية عند الطلب.
• لا تُضف النسخ الاحتياطية إلى Git أبدًا. التفريغ داخل مستودع هو تسريب بيانات ينتظر الوقوع.

الخطوة 6: اختبر الاستعادة

النسخة الاحتياطية لا تساوي أكثر من آخر استعادة ناجحة قمت بها. اختبرها على الأقل كل بضعة أشهر، وبعد أي تغيير في عملية النسخ:

1. أنشئ قاعدة بيانات جديدة وفارغة. لا تستعد فوق القاعدة الحية أبدًا للاختبار.
2. استعد أحدث نسخة فيها:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

بالنسبة لملف .sql نصي، استخدم psql "$TEST_DATABASE_URL" -f backup.sql بدلًا من ذلك.

1. تحقق من وجود كل الجداول، وقارن عدد الصفوف مع قاعدة البيانات الحية، وألقِ نظرة على بعض السجلات الحديثة.
2. شغّل نسخة من التطبيق عليها وسجّل الدخول إن أمكن.
3. دوّن المدة التي استغرقتها الاستعادة. هذا هو زمن التعافي الحقيقي لديك.

الخطوة 7: خذ نسخة احتياطية قبل التغييرات الخطرة

خذ نسخة جديدة مباشرة قبل:

• تشغيل ترحيل لقاعدة البيانات يحذف أعمدة أو يعيد تسميتها
• استيراد بيانات بكميات كبيرة
• السماح لوكيل ذكاء اصطناعي بإجراء تغييرات كبيرة على نموذج البيانات
• حذف سجلات قديمة

في التطبيق المبني بالذكاء الاصطناعي، قد يغيّر الوكيل بنية الجداول كجزء من ميزة جديدة. نقاط الحفظ وإدارة الإصدارات تعيد كودك إلى الوراء، لكنها لا تستعيد الصفوف التي حُذفت. نسخة احتياطية مدتها ثلاثون ثانية قبل تغيير كبير تكلفتها زهيدة مقارنة بالخسارة المحتملة.

الأخطاء الشائعة

• افتراض أن Git أو تصدير الكود نسخة احتياطية. إنه يحتوي على الكود لا على البيانات.
• عدم اختبار الاستعادة أبدًا. كثير من النسخ الاحتياطية تتضح أنها فارغة أو ناقصة أو غير قابلة للقراءة فقط عندما تُحتاج.
• الاحتفاظ بالنسخ في الحساب نفسه الذي فيه قاعدة البيانات. حساب واحد مخترَق أو مغلق يفقدهما معًا.
• نسيان الملفات المرفوعة. قاعدة البيانات تخزن مسار الملف، أما الصورة نفسها فتعيش في التخزين.
• ترك الأسرار داخل سكربتات النسخ. اقرأ سلسلة الاتصال من متغير بيئة، ولا تكتبها داخل نص السكربت. انظر كيف تحافظ على مفاتيح API آمنة.

النسخ الاحتياطية وMythex

يمكن أن تملك مشاريع Mythex قاعدة Postgres مخصصة، وتفاصيل اتصالها تُحقن في مساحة العمل والتطبيق المنشور. وثائق Mythex لا تصف ميزة نسخ احتياطي أو استعادة لقاعدة البيانات، لذا خطط لنسختك الخاصة: اطلب من الوكيل إنشاء تفريغ، ونزّله واحفظه في مكان آمن، خاصة قبل التغييرات الكبيرة. تصدير المشروع (في خطة Pro) يحتوي على كودك، مع استبعاد الأسرار وnode_modules، لكنه لا يحتوي على صفوف قاعدة البيانات. انظر قاعدة البيانات وملكية البيانات في الوثائق. لمزيد من المعلومات عن قاعدة البيانات نفسها، اقرأ ما هو Postgres.

قائمة التحقق من النسخ الاحتياطي

• حددت حجم البيانات التي يمكنك خسارتها والمدة التي يمكن أن يبقى فيها التطبيق متوقفًا
• تحققت من النسخ التلقائية التي يقدمها مزوّد قاعدة البيانات
• تعمل نسختك الخاصة وفق جدول زمني، والفشل يرسل لك تنبيهًا
• النسخ محفوظة بشكل منفصل عن قاعدة البيانات، مع وصول مقيّد
• سياسة الاحتفاظ مكتوبة
• الملفات المرفوعة مشمولة بالنسخ الاحتياطي إلى جانب قاعدة البيانات
• اختبرت الاستعادة في قاعدة بيانات فارغة وتحققت من أعداد الصفوف
• تأخذ نسخة احتياطية قبل كل تغيير خطر

الأسئلة