نسخة الظلّ لوحدة التخزين (VSS): الآليّة والممارسة ── لماذا تستطيع برمجيّات النسخ الاحتياطيّ نسخ ملفّات قيد الاستخدام

«حاولت نسخ ملفّ تفتحه تطبيق آخر فقيل لي إنّ العمليّة لا تستطيع الوصول إلى الملفّ لأنّه قيد الاستخدام من عمليّة أخرى.» «طُلب منا نسخ مجلّد البيانات احتياطيّاً دون إيقاف النظام الجوهريّ.» «لماذا تستطيع برمجيّات النسخ الاحتياطيّ نسخ ملفّ قاعدة بيانات قيد الاستخدام بهدوء؟» ── سواء طوّرت تطبيقات أعمال أو شغّلت خوادم ملفّات، فهذه أسئلة تصطدم بها عاجلاً أم آجلاً.

في مركز الجواب تقف خدمة نسخة الظلّ لوحدة التخزين (VSS: Volume Shadow Copy Service). وهي مدمجة في Windows منذ أكثر من عشرين عاماً، وتقوم عليها Windows Server Backup واستعادة النظام وتقريباً كلّ منتج نسخ احتياطيّ تجاريّ.¹

يستهدف هذا المقال مطوّري تطبيقات الأعمال الذين يُطلب منهم إضافة وظيفة «نسخ ملفّ قيد الاستخدام»، ومسؤولي نظم المعلومات الذين يشغّلون النسخ الاحتياطيّ لخوادم الملفّات وحواسيب العمل. انطلاقاً من مصادر أوّليّة حتّى أغسطس 2026، يرتّب شخصيّات VSS وآليّته، وممارسة التشغيل اليوميّ بـ vssadmin، وأين ينبغي أن يقع الخطّ في مدى انخراط المطوّر بـ VSS. سلسلة «أعماق إدخال/إخراج Windows» نظرت داخل مدير الذاكرة المؤقّتة وNTFS؛ وهذا المقال تتمّتها، ويعالج طبقة «اللقطة» التي تتدخّل مباشرة فوق وحدة التخزين.

1. الخلاصة أوّلاً

• VSS مجموعة واجهات COM وخدمة تنسيق تجعل من الممكن نسخ وحدة تخزين احتياطيّاً بينما يواصل التطبيق الكتابة إليها. وهي مدمجة في Windows منذ Windows XP.²
• هناك ثلاثة أدوار زائد منسّق. تتوسّط خدمة VSS بين الطالب (requester) الذي يطلب نسخة ظلّيّة (برمجيّة النسخ الاحتياطيّ)، والكاتب (writer) الذي يضمن اتّساق البيانات في جانب التطبيق (SQL Server مثلاً)، والمزوّد (provider) الذي ينشئ اللقطة فعلاً.¹
• المزوّد النظاميّ القياسيّ في Windows يستخدم النسخ عند الكتابة (copy-on-write). بدل تكرار وحدة التخزين بأكملها، ينقل فقط الكتل التي تُعاد كتابتها بعد اللقطة ── ومحتواها قبل الكتابة فحسب ── إلى منطقة فروق (diff area). ويجب أن تقع منطقة الفروق على وحدة تخزين NTFS.¹
• تُصنَع نقطة السكون عبر «تجميد الكتّاب (حتّى 60 ثانية) ← إنشاء اللقطة (خلال 10 ثوانٍ) ← الإذابة». إن تُجووز أيّ من الحدّين الزمنيّين أُلغي الإنشاء وأعاد الطالب المحاولة.¹
• تعاون الكاتب من عدمه يغيّر جودة النسخة. لقطة بلا تعاون كاتب تعادل «القرص في لحظة قطع الكهرباء» (اتّساق الانهيار، crash consistent)؛ ومع التعاون تكون السجلات قد رُحِّلت والذاكرة المؤقّتة فُرِّغت، فتبقى حالة متّسقة يضمن التطبيق نفسه قابليّة استردادها (اتّساق التطبيق، application consistent).³¹
• vssadmin أداة التحقّق من حالة التشغيل. استخدم list shadows / list writers / list shadowstorage لرؤية الوضع الحاليّ، وresize shadowstorage لضبط حدّ منطقة الفروق. عندما تنفد منطقة الفروق تُحذف أقدم النسخ الظلّيّة صامتاً.⁴⁵¹
• بناء طالب VSS داخل تطبيقك عمل كبير. واجهة أصليّة قائمة على COM بلا غلاف .NET رسميّ. في معظم الحالات تكفي إعادة المحاولة أو ضبط وضع المشاركة أو توقّف قصير؛ وإن لزم VSS حقّاً فسكربت DiskShadow هو الجواب العمليّ (Windows Server فقط).⁶⁷
• النسخة الظلّيّة ليست نسخاً احتياطيّاً بحدّ ذاتها. لأنّ فروق النسخ عند الكتابة تعتمد على الكتل السليمة في وحدة التخزين الأصليّة، فلا حماية أمام عطل يُفقد الوحدة الأصليّة بأكملها كعطل القرص أو السرقة. ولا يُعوَّل عليها أمام برمجيّات الفدية أيضاً، لأنّ النسخ الظلّيّة نفسها قد تُحذف (القسم 7.3) أو تُستنفَد منطقة الفروق بإعادة كتابة واسعة (القسم 7.4). لا تصير ذات معنى إلّا حين تُقرَن بنسخ احتياطيّة على وسائط منفصلة.¹

2. صياغة المشكلة ── لماذا لا يمكن نسخ ملفّ قيد الاستخدام بالطريقة العاديّة؟

نقطة الانطلاق وضع مشاركة الملفّات في Windows. عند فتح ملفّ في Windows ‏(CreateFile) تعلن، بوضع المشاركة (dwShareMode)، ما تسمح لعمليّات أخرى بفعله بينما الملفّ مفتوح لديك. وما دام ثمّة عمليّة تمسك الملفّ مفتوحاً على نحو لا يسمح بالمشاركة للقراءة، فإنّ أيّ عمليّة لاحقة تحاول فتحه للقراءة تفشل بـ انتهاك مشاركة (ERROR_SHARING_VIOLATION، الخطأ 32).⁸ وفي .NET يظهر هذا بالـ IOException المألوفة («لا يمكن للعمليّة الوصول إلى الملفّ لأنّه قيد الاستخدام من عمليّة أخرى»).

المهمّ أنّ هذا ليس خطأ، بل الآليّة الصحيحة لحماية البيانات. إن قُرئ ملفّ قيد الكتابة في منتصف الطريق، انتهى القارئ بحالة ناقصة قيد الإنجاز. وكما عولج بالتفصيل في «التحكّم الآمن في تزامن تكامل الملفّات - أفضل الممارسات لـ file lock والمطالبة الذرّيّة والمعالجة idempotent»، فإنّ تصميم الإقصاء المتبادل أساس التكامل بين التطبيقات.

غير أنّ هذه الآليّة الصحيحة تصطدم جذريّاً بالنسخ الاحتياطيّ.

• جدار انتهاك المشاركة: ملفّ تبقيه قاعدة بيانات أو تطبيق أعمال مفتوحاً قد لا يُفتَح أصلاً كمصدر للنسخ.
• جدار الاتّساق: حتّى إن أمكن الفتح (لأنّ المشاركة للقراءة مسموحة)، فالنسخ يستغرق وقتاً. ولأنّ التطبيق يواصل الكتابة أثناء النسخ، قد تعكس النصف الأوّل والنصف الثاني من الملفّ لحظتين مختلفتين، أو تخرج عدّة ملفّات (ملفّ البيانات وسجله مثلاً) عن التوافق فيما بينها. وكما رأينا في حلقة «مدير الذاكرة المؤقّتة»، تستقرّ الكتابة أوّلاً في الذاكرة المؤقّتة في الذاكرة، فالنظر إلى الملفّ على القرص وحده لا يضمن أنّك ترى أحدث محتوى.
• جدار التشغيل: «إذن أوقف التطبيق وانسخ» جواب معقول من حيث المبدأ، لكنّه غير مقبول لنظام أعمال أو خادم ملفّات يعمل على مدار الساعة.

بمعنى آخر، المطلوب فعلاً «نسخة للحظة واحدة متّسقة، دون إيقاف التطبيق». وهذا أثقل من أن تحلّه التطبيقات فرادى، فبُني VSS آليّة على مستوى نظام التشغيل لتوفيره. يُقدَّم VSS إطار عمل بواجهات COM يجعل من الممكن نسخ وحدة تخزين احتياطيّاً حتّى بينما يواصل التطبيق الكتابة إليها.²

3. شخصيّات VSS ── الطالب والكاتب والمزوّد

ينقسم تكوين VSS إلى ثلاثة أدوار والخدمة التي تتوسّط بينها.¹

لطف تقسيم العمل هذا أنّ منتجات لا تعرف شيئاً بعضها عن بعض تستطيع مع ذلك التعاون. برمجيّة النسخ الاحتياطيّ (الطالب) لا تعرف البنية الداخليّة لـ SQL Server، لكنّ كاتب SQL Server يصرّح، كبيانات وصفيّة، بأيّ ملفّات (مكوّنات) يلزم نسخها احتياطيّاً، ويرتّب بياناته هو قبيل نقطة السكون وبعدها مباشرة ── فيستطيع الطالب أخذ نسخة احتياطيّة متّسقة بمجرّد اتّباع ذلك.¹⁹ وتقريباً كلّ منتج نسخ احتياطيّ من طرف ثالث يعمل على Windows طالب VSS.¹

في تشغيل نظم المعلومات، اللحظة التي تحتاج فيها فعلاً إلى التفكير في هذه الأدوار الثلاثة هي استكشاف الأعطال. إن كان فشل النسخ الاحتياطيّ مشكلة في الطالب (جانب البرمجيّة)، أو في كاتب معيّن (جانب التطبيق)، أو في المزوّد / منطقة الفروق (جانب البنية)، فإنّ مكان البحث يتغيّر تماماً (القسمان 5 و7).

4. آليّة اللقطات ── النسخ عند الكتابة و«نقطة السكون»

4.1. النسخ عند الكتابة ── حفظ «تلك اللحظة» دون تكرار وحدة التخزين

سماع كلمة «لقطة» يجعلك تتخيّل تكرار وحدة التخزين بأكملها، لكنّ الطريقة التي يستخدمها المزوّد النظاميّ القياسيّ في Windows هي النسخ عند الكتابة (copy-on-write). في لحظة أخذ اللقطة لا يُنسَخ تقريباً شيء. لاحقاً، عندما تكون كتلة في الوحدة الأصليّة على وشك إعادة الكتابة، يُنقَل محتوى تلك الكتلة قبل الكتابة إلى منطقة الفروق (diff area، مخزن النسخ الظلّيّة) قبل اكتمال إعادة الكتابة، ثمّ يُسمَح للكتابة بالمرور.¹ والنقل يلزم فقط أوّل مرّة تُعاد فيها كتابة كلّ كتلة؛ إعادة الكتابة على كتلة نُقلت أصلاً لا تزيد منطقة الفروق بعد ذلك.

لقراءة «وحدة التخزين كما كانت في تلك اللحظة»، تُقرأ الكتل التي لم تتغيّر من الوحدة الأصليّة، والكتل التي تغيّرت من منطقة الفروق، ويُركَّب الاثنان. لأنّ الجزء المتغيّر وحده يُنسَخ، يكون الإنشاء فوريّاً والمساحة المستهلكة هي الفروق فقط. الوجه الآخر أنّ كلّما كثرت الكتابة على وحدة تخزين تسارع استهلاك منطقة الفروق (تمهيد للقسم 7)، وأنّ منطقة الفروق تقع على وحدة NTFS في الجهاز نفسه الذي يحمل البيانات المصدر.¹ وما يسند هذه الآليّة ملف مكوّن المزوّد النظاميّ swprv.dll، وبرنامج التشغيل الذي يعترض إدخال/إخراج الوحدة volsnap.sys.¹ إن أهمّك «كيف» يُعتَرَض مكدّس الإدخال/الإخراج، انظر أيضاً «برامج تشغيل المرشّح والمرشّحات المصغّرة».

وثمّة طرائق أخرى: النسخ الكامل الذي يفصل مرآة، وإعادة التوجيه عند الكتابة (redirect-on-write) الذي يكتب التغييرات إلى وحدة أخرى؛ ويستخدم مزوّدو العتاد الطريقة الأنسب لمصفوفة التخزين.¹

4.2. تدفّق صنع نقطة السكون ── تنسيق تجميد 60 ثانية وإنشاء 10 ثوانٍ

إن كان النسخ عند الكتابة يدور حول كيف تُحفَظ البيانات، فإنّ جوهر VSS في حالة أيّ لحظة تُحفَظ ── أي في كيف تُصنَع نقطة السكون. يتقدّم إنشاء النسخة الظلّيّة كما يلي.¹

flowchart TB
    accTitle: تدفّق إنشاء النسخة الظلّيّة
    accDescr: تدفّق إنشاء النسخة الظلّيّة. ما يتوقّف فعلاً ثوانٍ إلى عشرات الثواني فقط؛ أمّا النسخ الاحتياطيّ نفسه فيجري لاحقاً على اللقطة
    R["الطالب يطلب الإنشاء<br/>يعدّد الكتّاب ويجمع البيانات الوصفيّة"] --> M["كلّ كاتب يصرّح بأهداف النسخ الاحتياطيّ<br/>(المكوّنات) بصيغة XML"]
    M --> P["كلّ كاتب يُعدّ بياناته<br/>ترحيل السجلات وتفريغ الذاكرة المؤقّتة وغيرها<br/>ليصل إلى حالة متّسقة قابلة للاسترداد"]
    P --> F["تجميد إدخال/إخراج الكتابة للكتّاب<br/>(القراءة ممكنة. حتّى 60 ثانية كحدّ أقصى)"]
    F --> FS["VSS يفرّغ مخازن نظام الملفّات<br/>ويجمّد نظام الملفّات"]
    FS --> C["المزوّد ينشئ النسخة الظلّيّة<br/>(خلال 10 ثوانٍ. إدخال/إخراج الكتابة مجمّد في هذه الأثناء)"]
    C --> T["تحرير نظام الملفّات → إذابة الكتّاب (thaw)<br/>يستأنف التطبيق الكتابة"]
    T --> B["الطالب ينفّذ النسخ الاحتياطيّ من<br/>النسخة الظلّيّة مستغرقاً ما يلزم من الوقت"]

الشكل 1: تدفّق إنشاء النسخة الظلّيّة. ما يتوقّف فعلاً ثوانٍ إلى عشرات الثواني فقط؛ أمّا النسخ الاحتياطيّ نفسه فيجري لاحقاً على اللقطة

ثمّة ثلاث نقاط جديرة بالملاحظة.

1. التطبيق لا يتوقّف إلّا للحظة صنع نقطة السكون. التجميد محدود بـ 60 ثانية، والإنشاء (الالتزام) من المزوّد محدود بـ 10 ثوانٍ؛ إن تُجووز أيّ منهما أُلغي الإنشاء وأعاد الطالب المحاولة.¹ أمّا النسخ الاحتياطيّ نفسه، الذي قد يستغرق ساعات، فيجري على النسخة الظلّيّة الجاهزة للقراءة فقط بينما يواصل التطبيق العمل.
2. القراءة ما تزال ممكنة أثناء التجميد. ما يتوقّف هو إدخال/إخراج الكتابة فقط.¹
3. نظام الملفّات يُجمَّد أيضاً. لأنّ VSS يفرّغ مخازن نظام الملفّات قبل التجميد، فإنّ الكتابات التي كانت في الذاكرة المؤقّتة، وبيانات نظام الملفّات الوصفيّة، تنعكس في اللقطة بترتيب متّسق.¹

4.3. اتّساق الانهيار واتّساق التطبيق

هنا يظهر تمييز مهمّ يحدّد جودة النسخ الاحتياطيّ.

النسخة الظلّيّة المنشأة بلا تعاون كاتب تكون في ما تسمّيه مصطلحات Microsoft حالة اتّساق الانهيار (crash consistent). التعريف الرسميّ «حالة قرص تعادل الحالة التي تُوجَد بعد عطل كارثيّ يُغلق النظام فجأة»، ويوصف الاسترداد منها بأنّه «يعادل إعادة التشغيل بعد إغلاق مفاجئ».³ كنظام ملفّات ليست فاسدة، لكن من منظور التطبيق هي «لحظة سحب الكهرباء وهو يكتب». قاعدة بيانات ذات آليّة استرداد من سجلّ المعاملات كثيراً ما تستطيع الاسترداد من هذا، غير أنّ معالجة الاسترداد يجب أن تجري أوّلاً ── شرط مسبق لا مكافأة.

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

سبب وجود إعدادات في برمجيّات النسخ الاحتياطيّ مثل «استخدام VSS» أو «ضمان اتّساق التطبيق» هو هذا التمييز بالضبط. لمجموعة ملفّات عاديّة على خادم ملفّات نادراً ما تشكّل اتّساق الانهيار مشكلة؛ أمّا على خادم يستضيف قاعدة بيانات أو مخزن بريد، فإنّ سلامة الكاتب المقابل هي، في ذاتها، جودة النسخ الاحتياطيّ.

5. تشغيل VSS يوماً بيوم ── vssadmin و«الإصدارات السابقة»

الأداة التي يستخدمها مسؤولو نظم المعلومات عمليّاً للتحقّق من حالة VSS هي vssadmin (شغّلها من موجّه أوامر بامتيازات مرتفعة). مرجع الأوامر الحاليّ يدرج list shadows / list writers / delete shadows / resize shadowstorage متاحة على العميل والخادم كليهما.⁴ والمرجع الموجَّه إلى Windows Server يضيف إليها create shadow / list shadowstorage / list providers وغيرها.⁵ ولاحظ أنّ vssadmin لا يدير إلّا النسخ الظلّيّة التي أنشأها المزوّد النظاميّ.¹

إن أظهر list writers كاتباً في حالة خطأ، فالمشتبَه به ليس VSS نفسه بل التطبيق الذي يقدّم ذلك الكاتب. راجع حالة خدمة التطبيق المالك وسجلّي الأحداث Application/System (القسم 7).

يسمح /maxsize لدى resize shadowstorage بتحديد الحدّ بوحدة مثل KB/MB/GB؛ اتركه بلا تعيين فلا حدّ على الإطلاق. وما يستحقّ الانتباه أنّ وثائق Microsoft تنصّ صراحة على أنّ تغيير حدّ المخزن ── ولا سيّما تقليصه ── قد يسبّب هو نفسه فقدان نسخ ظلّيّة.¹⁰ لا تقلّص الحدّ بخفّة على وحدة تخزين تريد الاحتفاظ بأجيال متعدّدة فيها.

5.1. العلاقة بـ «الإصدارات السابقة»

تفعيل نسخ الظلّ للمجلّدات المشتركة (Shadow Copies of Shared Folders) على خادم ملفّات يحتفظ دوريّاً بنسخ لحظيّة للملفّات على المشاركة، فيتيح للمستخدمين استرداد ملفّ حذفوه أو كتبوا فوقه من الإصدارات السابقة دون حاجة إلى مساعدة مدير.¹ وهو أقرب تطبيقات VSS عهداً، ويقطع عبء مكتب المساعدة بموثوقيّة.

غير أنّ ثمّة حدّاً. نسخ المزوّد النظاميّ الظلّيّة تبلغ أقصاها 512 لكلّ وحدة تخزين، منها ما تحتفظ به ميزة نسخ الظلّ للمجلّدات المشتركة حتّى 64 افتراضيّاً (قابل للتغيير عبر قيمة السجلّ MaxShadowCopies).¹ وكما سيأتي من القسم التالي فصاعداً، إن ضاقت منطقة الفروق أُزيلت الأجيال الأقدم تلقائيّاً. الأسلم أن تفهم أنّ «كم جيلاً تحتفظ به فعلاً» يقرّره لا العدد الذي ضبطته، بل كم كُتب وحجم منطقة الفروق.

6. منظور المطوّر ── هل يحتاج تطبيقك إلى VSS؟

من هنا منظور المطوّر. عندما يُطلب منك «إضافة ميزة نسخ احتياطيّ تستطيع نسخ الملفّات حتّى وهي قيد الاستخدام»، كيف ينبغي أن تقارب VSS؟

6.1. كتابة طالب خاصّ بك عمل كبير

واجهة VSS، للطالب والكاتب كليهما، تُقدَّم كـ واجهات COM وC++ (قلب الطالب هو IVssBackupComponents).⁶ ليس ثمّة غلاف .NET رسميّ، وعليك تنفيذ كلّ شيء صحّة من جمع بيانات الكتّاب الوصفيّة، مروراً بإدارة مجموعة اللقطات، إلى التنظيف بعد خطأ ── لذا ليست شيئاً تلصقه بخفّة كميزة واحدة في تطبيق أعمال. في تقديرات التطوير التعاقديّ لدينا يُعامَل «بناء طالب VSS» بنداً مستقلّاً.

ثمّة جوابان واقعيّان. الأوّل ترك الأمر لمنتج نسخ احتياطيّ قائم مدرك لـ VSS. والثاني، على Windows Server، تشغيل DiskShadow من سكربت. DiskShadow طالب VSS المشحون مع نظام التشغيل؛ إلى جانب وضعه التفاعليّ لديه وضع سكربت (diskshadow /s script.txt)، ويستطيع سكربت واحد أن يغطي إنشاء النسخة الظلّيّة، وعرضها كحرف محرّك (expose)، وتشغيل دفعة تقوم بالنسخ (exec)، ثمّ التنظيف بعدها.⁷¹ يمكنك بناء التدفّق «أنشئ نسخة ظلّيّة ← اسحب الملفّات منها بمنطق النسخ لديك ← احذفها» دون كتابة سطر COM واحد. غير أنّ DiskShadow خاصّ بـ Windows Server ولا يُضمَّن في إصدارات العميل من نظام التشغيل.¹ إن دخلت حواسيب العميل أيضاً في نطاق المتطلّب، فإنّ هذه الحقيقة وحدها تُميل الكفّة نحو اعتماد منتج نسخ احتياطيّ قائم.

6.2. هل تحتاج VSS أصلاً؟ ── جدول قرار

من خبرتنا، الغالبيّة العظمى من طلبات «نسخ ملفّ قيد الاستخدام» تُحَلّ دون VSS. حدّد مستوى المتطلّب بدقّة قبل أن تختار الأداة.

6.3. هل ينبغي لتطبيقك أن يسجّل كاتباً؟

يجدر توضيح السؤال المعكوس أيضاً: هل ينبغي لتطبيق الأعمال الذي تكتبه أن يقدّم كاتب VSS؟ إن كتبت واحداً، نُسخت بيانات تطبيقك احتياطيّاً باتّساق التطبيق أيّاً كان منتج النسخ الاحتياطيّ الذي يستخدمه الزبون. وثمّة أيضاً آليّة أخفّ من الكاتب العاديّ، الكاتب السريع (express writer) ‏(IVssExpressWriter)، لكنّ كلّ ما تفعله هو تسجيل بيانات وصفيّة تصرّح بأيّ ملفّات تُدرَج أو تُستبعَد.⁶ لا تتلقّى إشعارات التجميد/الإذابة، لذا لا تستطيع إيقاف كتابات تطبيقك لتتوافق مع إنشاء اللقطة. الكاتب السريع مناسب فقط حين يُقرَن بتصميم تخزين لا يفسد حتّى إن التُقط في منتصف الكتابة (أي يكفي اتّساق الانهيار)؛ إن احتجت تنسيقاً فعليّاً عند نقطة السكون، فأنت تحتاج تنفيذ كاتب كامل.

ومع ذلك، قاعدة القرار بسيطة.

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

7. المزالق ── أربعة أمور تؤثّر حقّاً في التشغيل

7.1. VSS ليس نسخاً احتياطيّاً بحدّ ذاته

هذا أهمّ مزلق على الإطلاق. نسخة المزوّد النظاميّ الظلّيّة فروق تقع على قرص الجهاز نفسه الذي يحمل البيانات الأصليّة. إن فُقدت منطقة الفروق لم يبقَ ما يُركَّب منه، لذا لا تقدّم أيّ حماية أمام عطل قرص، أو سرقة الجهاز أو ضياعه، أو تشفير وحدة تخزين بأكملها. وثائق Microsoft نفسها ترسم خطاً واضحاً بين النسخ الظلّيّة والنسخ الاحتياطيّ: «المحتوى المنسوخ من نسخة ظلّيّة إلى وسيط كالشريط هو النسخ الاحتياطيّ، ويجوز حذف النسخة الظلّيّة نفسها بعد إتمام ذلك النسخ.»¹ النسخة الظلّيّة نقطة سكون ووسيلة سريعة للاسترداد من خطأ ── وليست بديلاً عن نسخة احتياطيّة على وسيط منفصل وفي موقع منفصل.

7.2. خطأ الكاتب مشكلة في جانب التطبيق

عندما تفشل برمجيّة النسخ الاحتياطيّ بـ «خطأ VSS»، ابدأ بتحديد أيّ كاتب فشل، مستخدماً vssadmin list writers. ولأنّ الكاتب، في جوهره، مكوّن ينتمي إلى التطبيق (أو إلى مكوّن Windows)¹، فإنّ ساحة التحقيق الرئيسة في السبب هي حالة خدمة ذلك التطبيق وسجلّات أحداثه. الانجرار وراء المظهر السطحيّ لـ «خطأ من برمجيّة النسخ الاحتياطيّ» ومواصلة التحقيق في برمجيّة النسخ الاحتياطيّ وحدها يطيل الطريق. نمط التضييق العامّ هو نفسه المعروض في «عندما ترث نظاماً بلا شيفرة مصدريّة ولا مواصفات ── الإجراءات العمليّة لتشغيله وصيانته دون توقّف»: ضيّق قائمة المشتبَه بهم من الوقائع التي تستطيع رصدها فعلاً.

7.3. برمجيّات الفدية تأتي لنسخك الظلّيّة

هذه حقيقة يجدر معرفتها اعتباراً دفاعيّاً بحتاً. يغري الأمل بأنّك إن استطعت الرجوع بالإصدارات السابقة فقد تستردّ حتّى بعد إصابة ببرمجيّة فدية ── لكن من المعروف على نطاق واسع أنّ كثيراً من برمجيّات الفدية تحذف النسخ الظلّيّة قبل التشفير أو بعده، تحديداً لقطع مسار الاسترداد هذا. حذف النسخ الظلّيّة ممكن بأمر مشروع تماماً ما دامت لديك امتيازات المدير، لذا لا يصلح خطّ دفاع أخيراً أمام مهاجم دخل أصلاً. فأركان المواجهة إذاً: (1) عامل النسخ الظلّيّة كـ «مفيدة إن وُجدت» لا كـ «جزء من خطّة الاسترداد»؛ (2) احتفظ بنسخة احتياطيّة غير متّصلة وفي موقع منفصل لا يستطيع المهاجم بلوغها؛ (3) لا تمنح امتيازات المدير لحسابات التشغيل اليوميّ. للدفاع عبر دورة حياة الحاسوب بأكملها، بما في ذلك النسخ الاحتياطيّ والتشفير والتخلّص، انظر أيضاً «الدليل العمليّ لـ BitLocker ── تشفير محرّك الأقراص بدءاً من إدارة مفتاح الاسترداد» و«ما ينبغي فعله قبل التخلّص من حاسوب Windows ── قائمة تحقّق عمليّة لمحو البيانات وفكّ ربط الحسابات والنسخ الاحتياطيّ».

7.4. عندما تنفد منطقة الفروق تختفي الأجيال الأقدم صامتاً

كما ورد في القسم 4، يستهلك النسخ عند الكتابة منطقة الفروق فقط عندما تُعاد كتابة كلّ كتلة للمرّة الأولى بعد أخذ اللقطة. إعادة الكتابة على كتلة نُقلت أيّ عدد إضافيّ من المرّات لا يزيد الاستهلاك، لذا لا يقرّر الاستهلاكَ «كم كتابة حدثت» بل «كم اتّسع نطاق الكتل المُعاد كتابتها منذ أخذ اللقطة المحتفَظ بها.» وما إن تبلغ منطقة الفروق حدّها حتّى تُحذف نسخ تلك الوحدة الظلّيّة، الأقدم أوّلاً.¹ لا يُخطَر المستخدم التفاعليّ بشيء، لذا كثيراً ما لا يظهر الأمر إلّا عندما يصير «يفترض أن أستطيع الرجوع إلى إصدار الأسبوع الماضي» غير صحيح. غير أنّه ليس صامتاً تماماً: يسجّل سجلّ System أحداثاً من المصدر volsnap (معرّف الحدث 25 عندما تُحذف نسخة لأنّ المساحة لم تُحرَّر لمنطقة الفروق، و35/36 عندما يفشل توسيع أو يُلغى بعد بلوغ الحدّ، وما شابه). إلى جانب الفحوص الدوريّة، فإنّ إدراج أحداث volsnap هذه في المراقبة والتنبيه يتيح التقاط الفقدان سريعاً. وسبب أنّ العمليّات الجماعيّة التي «تمسح الوحدة بأكملها» ── تحديثات ملفّات واسعة، تحويلات دفعيّة، إلغاء التجزئة ── قد تلتهم منطقة الفروق دفعة واحدة يعود إلى هذه الخاصّيّة بالضبط: الاستهلاك يقرّره نطاق الكتل المُعاد كتابتها. راجع بانتظام ما إذا كان عدد الأجيال التي تحتفظ بها ما يزال يلبّي متطلّب العمل («أقصى كم يوماً قد يمرّ قبل أن يلاحظ أحد حذفاً غير مقصود؟») مقابل الاستخدام الذي يظهره vssadmin list shadowstorage، ووسّع الحدّ إن احتجت.⁵¹⁰

8. الخلاصة

• سبب أنّ ملفّاً قيد الاستخدام لا يُنسَخ عادة مسألة انتهاك مشاركة واتّساق، وتلك هي الآليّة الصحيحة لحماية البيانات. VSS هو جواب نظام التشغيل على «أريد نسخة متّسقة دون إيقاف التطبيق».
• VSS إطار تتوسّط فيه خدمة VSS بين ثلاثة أدوار ── الطالب (يطلب)، والكاتب (يضمن الاتّساق)، والمزوّد (ينشئ) ── فيتيح لبرمجيّات النسخ الاحتياطيّ وتطبيقات الأعمال التي لا تعرف شيئاً بعضها عن بعض أن تتعاون.
• يستخدم المزوّد النظاميّ النسخ عند الكتابة، وتُصنَع نقطة السكون عبر «تجميد الكتّاب (حتّى 60 ثانية) ← إنشاء (خلال 10 ثوانٍ) ← إذابة». بلا تعاون كاتب تحصل على اتّساق الانهيار؛ ومعه، اتّساق التطبيق.
• تحقّق من حالة التشغيل بـ vssadmin ‏(list shadows / list writers / list shadowstorage). اشتبه بجانب التطبيق عند خطأ كاتب، وراجع استخدام منطقة الفروق بانتظام.
• على المطوّرين أوّلاً استخدام جدول القرار للتحقّق ممّا إذا كانت إعادة المحاولة أو أوضاع المشاركة أو نافذة توقّف أو تصميم تكامل تحلّ المشكلة، واللجوء إلى VSS فقط عندما يلزم حقّاً. سكربت DiskShadow (الخادم فقط) أو منتج قائم هو الجواب الواقعيّ، قبل البناء الذاتيّ.
• النسخة الظلّيّة ليست نسخاً احتياطيّاً. ليست سوى فروق تعتمد على الكتل السليمة في وحدة التخزين الأصليّة؛ وهي عاجزة أمام فقدان تلك الوحدة كما في عطل القرص، ولا يُعوَّل عليها أمام برمجيّات الفدية أيضاً، نظراً إلى أنّ النسخ الظلّيّة قد تُحذف أو تُستنفَد منطقة الفروق. اقرنها بنسخة احتياطيّة غير متّصلة في موقع منفصل.

مقالات ذات صلة

• التحكّم الآمن في تزامن تكامل الملفّات - أفضل الممارسات لـ file lock والمطالبة الذرّيّة والمعالجة idempotent
• أعماق إدخال/إخراج Windows (الجزء 4) ── مدير الذاكرة المؤقّتة: متى يصل WriteFile فعليّاً إلى القرص؟
• أعماق إدخال/إخراج Windows (الجزء 5) ── داخل NTFS: فهم نظام الملفّات عبر MFT
• عندما ترث نظاماً بلا شيفرة مصدريّة ولا مواصفات ── الإجراءات العمليّة لتشغيله وصيانته دون توقّف
• الدليل العمليّ لـ BitLocker ── تشفير محرّك الأقراص بدءاً من إدارة مفتاح الاسترداد
• ما ينبغي فعله قبل التخلّص من حاسوب Windows ── قائمة تحقّق عمليّة لمحو البيانات وفكّ ربط الحسابات والنسخ الاحتياطيّ

مجالات الاستشارة ذات الصلة

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

• الاستشارات التقنيّة ومراجعة التصميم
• التحقيق في الأخطاء وتحليل السبب الجذري
• تطوير تطبيقات ويندوز
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

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

أسئلة شائعة حول موضوع هذه المقالة.

إن وُجدت نسخ ظلّيّة، فهل يغني ذلك عن النسخ الاحتياطيّ؟

لا يغني. النسخ الظلّيّة التي ينشئها المزوّد النظاميّ القياسيّ في Windows فروق بأسلوب النسخ عند الكتابة، وليست نسخة كاملة منفصلة لوحدة التخزين في تلك اللحظة، بل تعتمد على الكتل غير المُعاد كتابتها في وحدة التخزين الأصليّة. حتّى إن وُضعت منطقة الفروق (diff area) على وحدة تخزين أخرى، فإنّ فقدان الوحدة الأصليّة يمنع الاسترداد كما هو، ولا حماية في أحداث تُفقد فيها الوحدة الأصليّة بأكملها كعطل القرص أو سرقة الحاسوب أو ضياعه. وينطبق الأمر على برمجيّات الفدية: كتابة التشفير نفسها تنقل الكتل قبل الكتابة إلى منطقة الفروق، لكن الهجمات الفعليّة تحذف النسخ الظلّيّة أو تستنفد منطقة الفروق بإعادة كتابة واسعة، فلا يُعوَّل عليها. وثائق Microsoft نفسها تميّز بينهما بوضوح: النسخ الاحتياطيّ هو البيانات المنسوخة من النسخة الظلّيّة إلى وسيط كالشريط، ويجوز حذف النسخة الظلّيّة نفسها بعد إتمام ذلك النسخ. النسخة الظلّيّة «نقطة سكون لأخذ نسخة احتياطيّة منها» و«وسيلة سريعة للاسترداد من خطأ بسيط»، وليست بديلاً عن نسخة احتياطيّة على وسيط منفصل وفي موقع منفصل.

أريد لتطبيق الأعمال الذي أكتبه أن ينسخ ملفّات قيد الاستخدام ── هل ينبغي استخدام VSS؟

الخطوة الواقعيّة الأولى البحث عن طريق يجنّبك الحاجة إليه. طالبو VSS يُكتبون بواجهة أصليّة قائمة على COM ‏(مثل IVssBackupComponents)، وليس ثمّة غلاف .NET رسميّ، لذا فإنّ دمجه في تطبيقك عمل كبير. إن كان المطلوب «قراءة ملفّ تكتب فيه عمليّة أخرى، ولو بعد حين»، تكفي إعادة المحاولة؛ وإن كان «التطبيق الآخر يسمح بالمشاركة للقراءة»، يكفي فتح الملفّ بوضع مشاركة موافق. وإن أمكن إيقاف التطبيق وقتاً قصيراً، فالنسخ في فترة هدوء طبيعيّة للعمل أبسط الخيارات وأوثقها. لا يستحقّ VSS مكانه إلّا عندما يكون المطلوب «استنساخ مجموعة بيانات كاملة من تطبيق لا يمكن إيقافه، في حالة متّسقة» ── وحتّى حينها، انظر أوّلاً إلى منتج نسخ احتياطيّ مدرك لـ VSS أو إلى سكربت DiskShadow قبل أن تبني تنفيذاً خاصّاً.

vssadmin list writers يُظهر كاتباً في حالة خطأ. ماذا أفعل؟

الأساس أن تُجري التحقيق فيه كمشكلة في جانب التطبيق الذي يملك ذلك الكاتب. يعرض vssadmin list writers الكتّاب المسجَّلين مع حالتهم، فابدأ بتحديد أيّ كاتب فشل. ولأنّ الكتّاب تقدّمهم تطبيقات مثل SQL Server أو مكوّنات Windows (السجلّ مثلاً)، فإنّ السبب يكاد يكون دائماً في حالة خدمة التطبيق المالك، أو في أخطاء مسجَّلة في سجلّي الأحداث Application/System، لا في VSS نفسه. أعد تشغيل الخدمة المعنيّة وضيّق شروط إعادة الإنتاج؛ فإن لم يُحَلّ الأمر، راجع معلومات دعم ذلك التطبيق. وهذا أيضاً خطوة الفرز الأولى الصحيحة عندما تفشل برمجيّة النسخ الاحتياطيّ بخطأ VSS.

اختفت نسخة ظلّيّة دون أن أشعر. لماذا؟

أشيع الأسباب نفاد مساحة منطقة الفروق (مخزن النسخ الظلّيّة). في النسخ عند الكتابة يُنقَل محتوى كلّ كتلة إلى منطقة الفروق أوّل مرّة تُعاد كتابتها بعد أخذ اللقطة، فكلّما اتّسع نطاق الكتل المُعاد كتابتها ازداد استهلاك المنطقة. عند بلوغ الحدّ المعيَّن يحذف Windows أقدم النسخ الظلّيّة أوّلاً ليحرّر مساحة. يحدث ذلك صامتاً بلا إشعار للمستخدم التفاعليّ، فيُكتشَف عادة حين يتوقّع أحدهم استرداد إصدار الأسبوع الماضي من «الإصدارات السابقة» فلا يجده (يسجّل سجلّ System أحداثاً مثل معرّف الحدث 25 من المصدر volsnap، فمراقبتها تتيح الالتقاط). راجع الاستخدام والحدّ بـ vssadmin list shadowstorage، وارفع الحدّ بـ vssadmin resize shadowstorage إن لزم. غير أنّ تغيير الحدّ ── ولا سيّما تقليصه ── قد يسبّب هو نفسه فقدان نسخ ظلّيّة.

ما علاقة «الإصدارات السابقة» في مستكشف الملفّات بـ VSS؟

«الإصدارات السابقة» أحد مداخل استرداد إصدارات سابقة لملفّ من نسخة ظلّيّة أنشأها VSS. على خادم ملفّات، يؤدي تفعيل «نسخ الظلّ للمجلّدات المشتركة» (Shadow Copies of Shared Folders) إلى أخذ نسخ ظلّيّة وفق جدول، فيستطيع المستخدمون النقر بالزرّ الأيمن على ملفّ في مجلّد مشترك واسترداده بأنفسهم من الإصدارات السابقة. الفائدة أنّ المستخدم يصلح حذفاً أو كتابة فوق غير مقصودة دون حاجة إلى مدير. لكنّ الأساس نسخ ظلّيّة، فهناك حدّ أعلى لعدد الأجيال المحتفَظ بها، وإن ضاقت منطقة الفروق اختفت الأجيال الأقدم أوّلاً. وكما ورد في متن المقال، «لدينا إصدارات سابقة» لا تعني «لا حاجة إلى نسخ احتياطيّ».

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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