لماذا يمكن لنسخة احتياطية من جهاز تخزين الشبكة المنزلي (NAS) أن تحافظ على بيانات تالفة بالفعل؟

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

توقيت الفساد مهم. قد تحمي اللقطة نسخة أقدم من الكتابة فوقها لاحقًا، لكنها لا تستطيع إنشاء نسخة نظيفة لم يتم التقاطها أبدًا. كما أن مشاركة الكتل بنظام النسخ عند الكتابة تخلق حالة ثانية: قد يؤثر الضرر المادي لكتلة على أكثر من عرض لنظام الملفات لا يزال يشير إلى تلك الكتلة.

اللقطة تحافظ على حالة نظام الملفات، وليس نسخة معروفة بأنها سليمة

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

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

الفساد الموجود عند وقت اللقطة يصبح جزءًا من نقطة الاسترداد

اعتبر لقطة مجدولة تم إنشاؤها عند منتصف الليل. إذا أفسد تطبيق قاعدة بيانات في الساعة 10:00 مساءً، فإن لقطة منتصف الليل تسجل حالة نظام الملفات بعد الفساد. التراجع إلى تلك اللقطة يعيد قاعدة البيانات إلى منتصف الليل، لكن منتصف الليل يكون قد فات لتوفير نسخة سليمة.

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

توقيت الفساد يحدد ما إذا كانت اللقطة يمكن أن تساعد

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

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

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

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

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

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

مجموعات التحقق والتنظيفات تختبر السلامة؛ اللقطات لا تفعل ذلك

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

يمكن لمجموعات التحقق اكتشاف تغييرات غير متوقعة في الكتل

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

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

التكرار يحدد ما إذا كان الفحص يمكنه إصلاح التلف

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

تفصل دراسة USENIX حول سلامة بيانات ZFS بشكل مشابه بين الكشف القائم على مجموعات التحقق والاسترداد باستخدام التكرار. الدرس العملي أضيق من "الفحص يصلح التلف": يمكن للفحص إصلاح فقط الأعطال التي يمكن لنظام التخزين تحديدها أو إعادة بناء بيانات بديلة موثوقة لها.

تساعد فترة الاحتفاظ باللقطات فقط إذا كانت هناك حالة سليمة لا تزال موجودة

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

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

تحقق من لقطة قبل استبدال بيانات NAS الحية

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

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

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

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

هل يمكن أن تصبح لقطة تم أخذها قبل التلف غير قابلة للقراءة؟

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

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

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

هل يمكن لفحص البيانات إصلاح التلف الذي كتبه التطبيق؟

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

هل يؤدي استبدال ملف حي تالف إلى إصلاح اللقطات القديمة؟

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