فحص استعادة ZIP: اكتشاف التلف رغم تطابق عدد الملفات

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

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

ما قسناه باستخدام ثمانية ملفات

نُفذت التجربة في Windows بتاريخ 28 سبتمبر 2026، باستخدام PowerShell 7.6.0-rc.1 وMicrosoft.PowerShell.Archive 1.2.5. لم نقارن التوافق بين عدة إصدارات مستقرة. تضمنت البيانات ملفًا حجمه صفر، واسمًا كوريًا يحتوي مسافات، وملفين مختلفي المحتوى حجم كل منهما 4 بايت، وملفين بالاسم نفسه داخل مجلدين فرعيين مختلفين، وملفًا ثنائيًا حجمه 256 بايت، وملف إرشادات. المجموع 8 ملفات بحجم 372 بايت.

أعددنا قائمة الأصل أولًا. سجلنا موقع كل ملف نسبةً إلى مجلد التجربة، مثل nested/level2/sample.txt، وحجمه وبصمته. ضغطنا المجلد في ZIP ثم فككناه إلى مجلد جديد. قارنا الحجم والبصمة للملفات ذات المسار النسبي نفسه. مقارنة الاسم وحده قد تخلط بين ملفي sample.txt في مجلدين مختلفين.

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

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

قراءة ملفات CSV

يلخص restore-summary.csv التجارب الثلاث. ويحتوي restore-comparison.csv على 24 صفًا على مستوى الملفات. Case اسم التجربة وRelativePath الموقع داخل المجلد. ExpectedBytes وActualBytes حجما الأصل والملف المفحوص، وعمودا SHA256 هما بصمتا المحتوى.

• MATCH: تطابق الحجم والبصمة الكاملة لهذا المسار.
• MISSING: مسار موجود بقائمة الأصل لكنه غير موجود بالمجموعة المفحوصة. فراغ خانة الحجم الفعلي يعني غياب الملف، وليس ملفًا حجمه صفر.
• HASH_MISMATCH: الحجم متساوٍ لكن البصمة مختلفة. أعد استعادة هذا الملف وفحصه.
• يعرض السكربت SIZE_MISMATCH لاختلاف الحجم، وUNEXPECTED لملف غير موجود بالقائمة الأصلية. لم نُدخل أخطاء منفصلة لاختبار هذين الفرعين ضمن التجارب الثلاث.

مثلًا، صف same-a.txt في same_size_change يعرض حجمًا قدره 4 في الجانبين. لكن بصمة الأصل تبدأ بـ63C1DD95… وبصمة النسخة المعدّلة بـ96741164…. المقارنة الفعلية استخدمت الرموز الـ64 كلها، لا البداية فقط. أما empty.txt فحجمه صفر أصلًا وتطابقت بصمته عند الاستعادة الطبيعية. الحكم بأن كل ملف صفري تالف يُصنّف الملفات الفارغة عمدًا تصنيفًا خاطئًا.

إعادة التجربة بأمان قبل استخدام بياناتك

اقرأ نص سكربت إعادة التجربة، ثم احفظه في مجلد تدريب باسم restore-lab.ps1. تأكد أن الامتداد لم يبقَ .ps1.txt. لا يستقبل السكربت مسارات ملفات المستخدم؛ ينشئ في كل تشغيل مجلد تجربة جديدًا بجواره، ولا يضغط أو يستعيد أو يغيّر سوى الملفات التي أنشأها بنفسه. لا يتضمن أمر حذف الأصل أو خيار الكتابة القسرية فوق استعادة موجودة. ضعه أولًا في مجلد تدريب فارغ، واقرأ محتواه، ثم شغّله في PowerShell. إذا منعت سياسة الشركة تشغيل السكربتات، فلا تعطل السياسة بنفسك؛ يمكنك فهم التسلسل اليدوي أدناه بدلًا من ذلك.

# شغّل من مجلد التدريب الذي حفظت فيه restore-lab.ps1
& '.\restore-lab.ps1'

يجب أن تكون نتيجة zip_restore هي PASS، ونتيجتا الخطأ المتعمد FAIL. إذا كانت ControlBehavedAsExpected تساوي True في الصفوف الثلاثة، فقد استجاب الفحص لهذه الحالات الطبيعية والخاطئة كما توقعنا. لا تخلط FAIL في اختبار الخطأ مع فشل نسخة احتياطية عادية. بعد التشغيل، افتح CSV وresults.json من المجلد الجديد الظاهر على الشاشة لمراجعة الوقت والإصدارات والبصمات الكاملة.

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

هذه الأوامر الأساسية. المسارات أمثلة تعليمية، فغيّرها لمجلد التدريب فقط. يضغط الأمر الأول الأصل التدريبي، ويستعيد الثاني ZIP في موقع جديد، ويعرض الأخيران بصمتي الملفين المتناظرين. يظهر مستوى إضافي باسم source لأننا ضغطنا المجلد نفسه.

Compress-Archive -LiteralPath '.\source' -DestinationPath '.\trial.zip'
Expand-Archive -LiteralPath '.\trial.zip' -DestinationPath '.\restore-new'
Get-FileHash -LiteralPath '.\source\notes.txt' -Algorithm SHA256
Get-FileHash -LiteralPath '.\restore-new\source\notes.txt' -Algorithm SHA256

تشرح Microsoft مقارنة بصمات المحتوى واعتماد SHA256 افتراضيًا في Get-FileHash. وتفصل إرشادات Expand-Archive بين تحديد الوجهة وخيار الكتابة فوق الملفات. هذا المثال لا يستخدم -Force للكتابة فوق ملفات موجودة.

ما لم نفحصه حتى بعد النجاح

Q. هل PASS تعني سلامة النسخة الاحتياطية كلها؟

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

Q. ماذا عن الملفات المخفية والكبيرة؟

توضح وثيقة Compress-Archive أن الملفات والمجلدات المخفية قد تُتجاوز، وأن هناك حدًا لحجم الملف. لا تعمم مثال ZIP الصغير ليصبح طريقة لحفظ نظام التشغيل كله أو الإعدادات المخفية. لم نضع ملفات مخفية أو ملفات بحجم 2GB فأكثر في مجموعة الأصل.

Q. هل تنتهي المراجعة عند تطابق البصمة؟

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