باختصار: سجّل بصمة حين تكتب ملفًا، وقارنها لاحقًا. إذا اختلفت البصمات ولم يعدّل شيء الملف، فقد تغيّرت البايتات من تحتك.
لا شيء آخر يكشف هذا. القرص الذي عليه تلف صامت يجتاز الإسعاف الأولي، ويبلّغ عن SMART سليم، ويُحمَّل بشكل مثالي.
التخزين شيء مادي. المجالات المغناطيسية على القرص الدوّار تضعف. والشحنة تتسرب من خلايا الذاكرة الفلاشية، أسرع حين يكون الجو دافئًا وأسرع أيضًا حين يبقى القرص بلا كهرباء مدة طويلة. والكابل قد يُسقط بتًا أثناء النقل. والبرامج الثابتة فيها أخطاء.
تصحح الأقراص معظم ذلك بنفسها، برموز تصحيح الأخطاء وبنقل القطاعات التي تجدها تتلف. التلف المهم هو الجزء الذي يتجاوز ذلك: قراءة تُعيد بايتات مختلفة عن التي كُتبت، وتبلّغ عن النجاح.
الاسم الذي يتجادل حوله الناس. بعضهم يسميه bit rot، وبعضهم تلف البيانات الصامت، وبعضهم تدهور البيانات. كلها الشيء نفسه لأغراضنا: الملف مختلف ولم يقل شيء ذلك.
هذا الجزء يستحق الفهم، لأنه يفسر لماذا كل أداة قد تلجأ إليها هي الأداة الخطأ.
cp وFinder يقرآن البايتات ويكتبانها. إذا أعادت القراءة بايتات خاطئة، فإنهما يكتبان البايتات الخاطئة بأمانة.إذن الموقف الصادق هو: لا يملك جهاز Mac آلية تخبرك. والعَرَض الأول صورة يمر عبرها شريط من التشويش، أو أرشيف لا يُفتح، أو فيديو يتوقف في المنتصف.
نادر لكل ملف، وليس نادرًا عبر مجموعة كبيرة على مدى طويل، وهذه هي الحالة التي توجد النسخة الاحتياطية من أجلها. أمران يرفعان الاحتمال بشكل ملحوظ:
سبب أهميته في النسخة الاحتياطية أكثر من قرص العمل أن ملف العمل يُفتح، والملف التالف المفتوح تلف اكتشفته. أما النسخة الاحتياطية فتُكتب مرة ولا تُقرأ أبدًا، ما يعني أن التلف فيها يُكتشف يوم تحتاج إليها.
سجّل ما كتبته:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txt
ثم، بعد أشهر، اسأل هل لا يزال كما هو:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'
أي شيء يُطبع هو ملف تغيّرت بايتاته. إذا لم تعدّله، فهذه إجابتك.
ملاحظتان عمليتان. احتفظ بملف البصمات في مكان غير القرص الذي يصفه، وإلا ستفقد الاثنين معًا. ويستغرق هذا ما تستغرقه قراءة القرص كله، فجدوله ليلًا.
كل ما سبق هو سبب وجود التطبيق بالشكل الذي هو عليه. يخزّن كل جزء من النسخة الاحتياطية تحت بصمة محتواه، ثم يقرأ النسخة الاحتياطية مجددًا وفق جدول ويفحص كل جزء مقابل البصمة التي خُزّن بها.
عدم التطابق إذن دليل: البايتات ليست البايتات التي كُتبت، ولا يوجد تفسير يجعل ذلك مقبولًا. ويُبلَّغ عن أي جزء حُذف من تحت النسخة الاحتياطية على أنه مفقود. والدرجة في الشاشة الرئيسية لا تحسب إلا ما تحقق منه مؤخرًا، ولهذا هي أقل مما يتوقع الناس، وهذا هو المقصود.
امتلاك موقع ثانٍ أهم هنا من أي مكان آخر في هذا الموقع. التلف في نسخة واحدة إزعاج حين توجد اثنتان، ونهاية الملف حين توجد واحدة.
لا. يفحص الإسعاف الأولي بنية نظام الملفات، لا محتوى ملفاتك. القرص الذي عليه ملفات تالفة بصمت يجتازه بنجاح، وهذا بالضبط ما يجعل هذه المشكلة على ما هي عليه.
ليس لهذا الغرض. يبلّغ SMART عن الأخطاء التي لاحظها القرص وصححها أو نقلها. أما التلف الصامت فهو تحديدًا ما لم يلاحظه. ومع ذلك يستحق الفحص لقرص يتعطل، وهي مشكلة مختلفة وأوضح بكثير.
يحسب المجاميع الاختبارية لبياناته الوصفية، لا لبيانات ملفاتك. يحسب ZFS وBtrfs المجاميع الاختبارية لمحتوى الملفات ويمكنهما الإصلاح من نسخة احتياطية زائدة، ولا يتوفر أي منهما كوحدة إقلاع أو وحدة خارجية عادية في macOS. هذه الفجوة هي سبب جدوى الفحص على مستوى التطبيق.
بما يكفي لاكتشاف النسخة السيئة ما دامت النسخة الجيدة موجودة. كل ثلاثة أشهر معقول للأرشيف؛ وشهريًا إن كانت النسخة الوحيدة من شيء لا يُعوَّض. الإجابة الصحيحة هي ما لن تتخطاه فعلًا، وهذا يرجّح أن يكون آليًا.
لا. التحقق يخبرك أن نسخة ما فسدت. ولا يستطيع إعادة الملف. الاكتشاف مفيد فقط حين توجد نسخة ثانية تستعيد منها، وهذه هي الحجة الكاملة لقاعدة 3-2-1.
ذو صلة: كيف تتحقق من أن النسخة الاحتياطية قابلة للقراءة، وتنسيق المستودع، وقاعدة 3-2-1.