ما هي طريقة النسخ الاحتياطي التي تحافظ على اتساق حاوية قاعدة البيانات الجارية على جهاز NAS منزلي؟

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

عرف "متسق" على أنه استعادة تقبلها قاعدة البيانات

النسخة الاحتياطية المتسقة ليست مجرد شجرة مجلدات كاملة. بعد الاستعادة، يجب أن يبدأ محرك قاعدة البيانات، يستعيد المعاملات بشكل صحيح، يجتاز فحوصات السلامة، ويعرض حالة نقطة زمنية يمكن للتطبيق استخدامها. على خادم منزلي يشغل Immich، Nextcloud، Paperless-ngx، Home Assistant، أو تطبيق مستضاف ذاتيًا آخر، يعني ذلك أن قاعدة البيانات، التحميلات، التكوين، والأسرار يجب أن تتوافق مع بعضها البعض.

استمرارية الحاوية تشرح فقط مكان وجود الملفات. لا تجعل قاعدة بيانات تعمل آمنة للنسخ. قد تحتوي قاعدة البيانات على معاملات نشطة، صفحات مخزنة مؤقتًا، سجلات كتابة مسبقة، ملفات مؤقتة، أو بيانات وصفية تتغير أثناء قراءة برنامج النسخ الاحتياطي لـ NAS للحجم.

الطريقة 1: استخدام تفريغ منطقي أصلي لقاعدة البيانات كإعداد افتراضي لـ NAS المنزلي

التفريغ المنطقي يطلب من محرك قاعدة البيانات تصدير تمثيل متسق للمخططات والسجلات. بالنسبة لحاوية PostgreSQL أو MariaDB متواضعة على NAS عائلي، عادةً ما تكون هذه أسهل طريقة للجدولة، الفحص، النسخ إلى موقع خارجي، والاستعادة في حاوية بديلة نظيفة. يوضح دليل النسخ الاحتياطي الحالي لـ Docker هذا النمط من خلال تشغيل تفريغات أصلية لقاعدة البيانات من حاوية نسخ احتياطي مجدولة.

اكتب التفريغ إلى دليل نسخ احتياطي مخصص خارج حجم البيانات الحي. ثم دع مهمة النسخ الاحتياطي لـ NAS تحمي التفريغ، ملف Compose، قالب البيئة، تكوين التطبيق، والبيانات المحملة. لا تكشف عن كلمات مرور الإنتاج داخل اسم ملف التفريغ أو السجلات غير المحمية.

الطريقة 2: إيقاف قاعدة البيانات مؤقتًا قبل نسخ حجمها

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

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

الطريقة 3: تنسيق لقطة سريعة مع قاعدة البيانات

يمكن لأنظمة اللقطات مثل ZFS و Btrfs و LVM و NAS التقاط حجم قاعدة بيانات كبير بسرعة، لكن يجب تنسيق اللقطة مع قاعدة البيانات. بالنسبة لـ MariaDB أو MySQL، قد يعني ذلك نافذة قفل أو تفريغ قصيرة؛ بالنسبة لـ PostgreSQL، قد يعني ذلك عملية النسخ الاحتياطي أو نقطة التحقق المدعومة من قاعدة البيانات؛ بالنسبة لقاعدة بيانات تُدار بواسطة التطبيق، قد يعني ذلك وجود خطاف قبل اللقطة.

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

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

لا تعامل تصدير صورة Docker أو الحاوية كنسخة احتياطية لقاعدة البيانات

تحتوي صورة الحاوية على وقت تشغيل التطبيق، وليس بالضرورة البيانات الحية الدائمة. تصدير الحاوية أو الالتزام بها قد يتجاهل الأحجام المسماة ولا يطلب من قاعدة البيانات إنشاء نقطة استرداد متسقة. يستنتج حساب نسخ احتياطي لحاوية PostgreSQL أن أوامر Docker save و commit لا تحل محل تقنيات النسخ الاحتياطي الخاصة بـ PostgreSQL.

لخادم منزلي يعمل بنظام ZimaOS أو Docker، احتفظ بتعريف النشر وخطة حماية البيانات منفصلين: احتفظ بملفات Compose وعلامات الصور حتى يمكن إعادة بناء الخدمة، واحتفظ بقاعدة البيانات من خلال طريقة متسقة مع قاعدة البيانات حتى يمكن استعادة حالتها.

لا تنسخ أبدًا حجم قاعدة بيانات يتم الكتابة عليه بنشاط بشكل عادي

قد يقرأ برنامج النسخ الاحتياطي لـ NAS ملفات قاعدة بيانات مختلفة في لحظات مختلفة. يمكن أن يحتوي الأرشيف الناتج على ملف بيانات من حالة معاملة واحدة، وسجل من أخرى، وبيانات وصفية من ثالثة. تحذر نظرة عامة على طرق النسخ الاحتياطي المفتوحة المصدر لـ SQL من أن قاعدة البيانات المتحركة يمكن التقاطها في لحظة غير متسقة بينما لا تزال الحالة المهمة في الذاكرة.

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

تعامل مع حاويات SQLite كقواعد بيانات، وليس كملفات عادية

تستخدم العديد من تطبيقات خوادم المنزل SQLite لأنها مضغوطة وسهلة النشر. الخطر هو أن المسؤولين يرون ملف .db واحد ويفترضون أنه يمكن نسخه أثناء كتابة التطبيق. في وضع WAL، قد تكون التغييرات الملتزمة حديثًا خارج الملف الرئيسي. توصي مقالة عملية عن استرداد SQLite باستخدام آلية النسخ الاحتياطي عبر الإنترنت أو نسخة مغلقة نظيفة بدلاً من نسخ ملف قاعدة بيانات مباشر.

استخدم النسخ الاحتياطي المدمج في التطبيق إذا كان متوفرًا. وإلا فاستخدم وظيفة النسخ الاحتياطي عبر الإنترنت الخاصة بـ SQLite أو أوقف التطبيق نظيفًا قبل نسخ دليل قاعدة البيانات بالكامل. لا تنسخ فقط ملف قاعدة البيانات الرئيسي مع ترك سجلها أو حالة WAL.

اختر الطريقة حسب وقت التوقف، حجم قاعدة البيانات، وقابلية نقل الاستعادة

قم بعمل نسخة احتياطية للتطبيق المستضاف ذاتيًا بالكامل، وليس قاعدة البيانات فقط

يجب أن تتضمن حزمة الاسترداد القابلة للاستخدام نسخة احتياطية من قاعدة البيانات، وملف Docker Compose، وإصدارات الصور، ومتغيرات البيئة أو حزمة أسرار قابلة للاسترداد، وإعدادات البروكسي العكسي، وتكوين التطبيق، والملفات المرفوعة، وأي مفاتيح تشفير. النسخ الاحتياطي لتفريغ SQL فقط قد يستعيد السجلات لكنه يترك التطبيق غير قادر على العثور على الصور أو المستندات أو الصور المصغرة أو الشهادات أو مسارات التخزين.

للتخطيط لاسترداد الخادم المنزلي، يشرح دليل ZimaSpace حول الربط والتخزين المسمي لماذا تساعد مسارات التخزين المرئية في الاسترداد لكنها لا تحل محل نسخة احتياطية متناسقة مع التطبيق لقاعدة البيانات.

ثبت الطريقة عن طريق الاستعادة في حاوية جديدة

أنشئ مجموعة اختبار معزولة باسم مشروع جديد، ومنافذ مضيف مختلفة، ودليل بيانات مؤقت. استعد التفريغ أو اللقطة، وابدأ قاعدة البيانات، وشغّل فحوصات السلامة أو التناسق، ثم اربط نسخة اختبار من التطبيق. تأكد من وجود المستخدمين والسجلات والمرفقات والمعاملات الأخيرة.

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

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

هل يكفي إيقاف حاوية قاعدة البيانات مؤقتًا قبل نسخ الحجم؟

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

هل لقطة NAS وحدها كافية لـ PostgreSQL أو MariaDB؟

فقط عندما تكون اللقطة ذرية ومنسقة مع عملية التناسق المدعومة من قاعدة البيانات. قد تكون اللقطة غير المنسقة متوافقة فقط مع حالة تعطل، ونسخة الملف غير الذرية قد تكون أسوأ.

ماذا يجب أن أقوم بنسخه احتياطيًا لتطبيق خادم منزلي يعتمد على SQLite؟

استخدم تصدير التطبيق أو النسخة الاحتياطية عبر الإنترنت لـ SQLite عند توفرها. كما يجب الحفاظ على تكوين التطبيق، وملف Compose، والأسرار، والمرفقات، والدليل الذي يحتوي على قاعدة البيانات بدلاً من افتراض الملف الرئيسي. .db الملف هو التطبيق بأكمله.

التوصية النهائية

استخدم النسخ المنطقية المجدولة كإعداد افتراضي لمعظم حاويات PostgreSQL وMariaDB على جهاز NAS منزلي. استخدم نسخة نظيفة من الحجم المتوقف عندما يكون وقت التوقف القصير مقبولًا، واستخدم اللقطات المنسقة أو أدوات الفيزياء الأصلية لقاعدة البيانات عندما تكون قاعدة البيانات كبيرة أو نافذة نقطة الاسترداد ضيقة. مهما كانت الطريقة التي تختارها، قم باستعادتها في حاوية جديدة قبل الوثوق بها.