كيفية اختبار ما إذا كان Time Machine يواصل سجل النسخ الاحتياطي أم يعيد إنشاءه

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

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

حدّد الشروط الكامنة وراء قرار استمرارية سجل Time Machine

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

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

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

اختبر الادعاء من دون تخفيف المتطلب الأصلي

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

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

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

tmutil destinationinfo
tmutil listbackups
tmutil status

فسّر نتائج النجاح والفشل والاستثناء

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

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

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

أكّد القرار تحت عبء العمل الأصلي

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

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

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

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

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

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

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

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

هل يعني التشغيل الأول الكبير دائمًا فقدان السجل؟

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

هل يمكن أن تحمل sparsebundle اثنتان أسماء متشابهة؟

نعم. استخدم هوية الجهاز وبيانات تعريف الوجهة، لا اسم الملف وحده.

هل ينبغي حذف الحزمة القديمة بعد بدء نسخة احتياطية جديدة؟

ليس قبل إثبات الاستمرارية أو اجتياز السجل الكامل الجديد اختبار استرداد.

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