KomuraSoft LLC
संपर्क करें
मेनू

वॉल्यूम शैडो कॉपी (VSS) की संरचना और व्यवहार — उपयोग में फ़ाइल का बैकअप क्यों लिया जा सकता है

· · Windows, VSS, बैकअप, फ़ाइल, NTFS, व्यावसायिक ऐप, बग जाँच, सूचना प्रणाली

«दूसरे ऐप की खुली फ़ाइल कॉपी करने गया तो कहा गया कि प्रोसेस फ़ाइल तक पहुँच नहीं सकता क्योंकि वह दूसरे प्रोसेस के उपयोग में है।» «मुख्य प्रणाली रोके बिना डेटा फ़ोल्डर का बैकअप लेने को कहा गया।» «बैकअप सॉफ़्टवेयर उपयोग में डेटाबेस फ़ाइल को इतनी आसानी से कॉपी कैसे कर लेता है?» — व्यावसायिक ऐप विकास में भी, फ़ाइल सर्वर संचालन में भी, ये प्रश्न देर-सबेर आते हैं।

उत्तर के केंद्र में वॉल्यूम शैडो कॉपी सेवा (VSS: Volume Shadow Copy Service) है। यह Windows में बीस से अधिक वर्षों से बनी हुई है, और Windows Server Backup, सिस्टम पुनर्स्थापना, तथा लगभग हर व्यावसायिक बैकअप उत्पाद इसी नींव पर खड़े हैं।1

यह लेख «उपयोग में फ़ाइल कॉपी» माँगने वाले व्यावसायिक ऐप डेवलपर्स और फ़ाइल सर्वर व व्यावसायिक PC का बैकअप चलाने वाले सूचना प्रणाली कर्मियों के लिए है। VSS के पात्र और संरचना, vssadmin से दैनिक संचालन, और «डेवलपर VSS में कितना घुसे» का निर्णय, अगस्त 2026 तक के प्राथमिक स्रोतों पर आधारित है। «Windows I/O की गहराई» श्रृंखला में कैश मैनेजर और NTFS के भीतर देखा गया; यह लेख उसकी अगली कड़ी है, वॉल्यूम के ठीक ऊपर बैठने वाली «स्नैपशॉट» परत पर।

1. पहले निष्कर्ष

  • VSS COM इंटरफ़ेस समूह और समन्वय सेवा है, जिससे ऐप लिखते रहने पर भी वॉल्यूम का बैकअप संभव होता है। यह Windows XP से Windows में है।2
  • पात्र तीन भूमिकाएँ प्लस समन्वयक हैं। शैडो कॉपी माँगने वाला रिक्वेस्टर (बैकअप सॉफ़्टवेयर), ऐप पक्ष पर डेटा की सुसंगतता गारंटी देने वाला राइटर (SQL Server आदि), और स्नैपशॉट वास्तव में बनाने वाला प्रोवाइडर — इनके बीच VSS सेवा मध्यस्थता करती है।1
  • Windows का मानक सिस्टम प्रोवाइडर कॉपी-ऑन-राइट उपयोग करता है। पूरा वॉल्यूम नहीं दोहराता; स्नैपशॉट के बाद बदले जाने वाले ब्लॉक ही, बदलने से पहले, डिफ़ क्षेत्र (diff area) में भेजता है। डिफ़ क्षेत्र NTFS वॉल्यूम पर होना चाहिए।1
  • स्थिर बिंदु «राइटर फ़्रीज़ (अधिकतम 60 सेकंड) → स्नैपशॉट निर्माण (10 सेकंड के भीतर) → थॉ» से बनता है। समय सीमा पार हो तो निर्माण रद्द होता है और रिक्वेस्टर फिर कोशिश करता है।1
  • राइटर सहयोग दे या न दे, कॉपी की गुणवत्ता बदलती है। बिना सहयोग का स्नैपशॉट «बिजली कटते क्षण की डिस्क» के बराबर है (क्रैश सुसंगत); सहयोग हो तो लॉग रोल और कैश फ़्लश पूरे हो चुके होते हैं, और ऐप स्वयं पुनर्प्राप्य सुसंगत अवस्था गारंटी करता है (ऐप्लिकेशन सुसंगत)।31
  • संचालन की जाँच vssadmin से होती है। list shadows / list writers / list shadowstorage से वर्तमान देखें, resize shadowstorage से डिफ़ क्षेत्र की सीमा बदलें। डिफ़ क्षेत्र खत्म हो तो पुरानी शैडो कॉपी चुपचाप मिटती हैं।451
  • स्वयं के ऐप में VSS रिक्वेस्टर जोड़ना बड़ा काम है। COM-आधारित नेटिव API है, .NET का आधिकारिक रैपर नहीं। अधिकतर पुनःप्रयास, साझा मोड का समायोजन, या थोड़ी रोक काफी है; सचमुच VSS चाहिए तो DiskShadow स्क्रिप्ट यथार्थ उत्तर है (केवल Windows Server)।67
  • शैडो कॉपी स्वयं बैकअप नहीं है। कॉपी-ऑन-राइट अंतर मूल वॉल्यूम के अक्षत ब्लॉकों पर निर्भर है, इसलिए डिस्क खराबी या चोरी जैसी घटना, जहाँ मूल वॉल्यूम ही खो जाए, पर यह बेबस है। रैनसमवेयर पर भी शैडो कॉपी स्वयं मिटना (खंड 7.3) या भारी पुनर्लेखन से डिफ़ क्षेत्र खत्म होना (खंड 7.4) भरोसा तोड़ देता है। अलग माध्यम के बैकअप के साथ जोड़ने पर ही अर्थ बनता है।1

2. समस्या का ढाँचा — उपयोग में फ़ाइल सामान्यतः कॉपी क्यों नहीं हो पाती

शुरुआत Windows के फ़ाइल साझा मोड से है। Windows में फ़ाइल खोलते समय (CreateFile) आप «जब तक मैं खोले रखूँ, दूसरे प्रोसेस को क्या अनुमति है» साझा मोड (dwShareMode) के रूप में घोषित करते हैं। कोई प्रोसेस पढ़ने की साझेदारी न देते हुए खुले रखे, तो बाद में पढ़ने के लिए खोलने वाला साझाकरण उल्लंघन (ERROR_SHARING_VIOLATION, त्रुटि 32) से विफल होता है।8 .NET में यही जाना-माना IOException है («The process cannot access the file because it is being used by another process»)।

महत्वपूर्ण यह है कि यह बग नहीं, डेटा की रक्षा का सही तंत्र है। लिखी जा रही फ़ाइल बीच में पढ़ी जाए तो पाठक «अधूरी, बीच की अवस्था» पाता है। बहिष्करण का डिज़ाइन «फ़ाइल एकीकरण के बहिष्करण नियंत्रण की मूल बातें - फ़ाइल लॉक और अणु claim की सर्वोत्तम प्रथाएँ» में विस्तार से है, और ऐपों के बीच एकीकरण की नींव है।

पर यही सही तंत्र बैकअप से मौलिक रूप से टकराता है।

  • साझाकरण उल्लंघन की दीवार: डेटाबेस या व्यावसायिक ऐप की खुली फ़ाइल कॉपी स्रोत के रूप में खुल ही नहीं सकती।
  • सुसंगतता की दीवार: खुल भी जाए (पढ़ने की साझेदारी हो) तो कॉपी समय लेती है। कॉपी चलते ऐप लिखता रहता है, इसलिए फ़ाइल का पहला और दूसरा आधा अलग क्षणों का हो सकता है, या कई फ़ाइलें (डेटा और लॉग) आपस में न मिलें। और «कैश मैनेजर» किस्त में देखा, लेखन पहले मेमोरी कैश में बैठता है, इसलिए डिस्क की फ़ाइल मात्र देखने से नवीनतम होने की गारंटी नहीं।
  • संचालन की दीवार: «तो ऐप रोककर कॉपी कर लो» सिद्धांत में ठीक है, पर चौबीस घंटे चलने वाली व्यावसायिक प्रणाली या फ़ाइल सर्वर पर स्वीकार्य नहीं।

अर्थात माँग है «ऐप रोके बिना, एक क्षण की सुसंगत अवस्था की कॉपी»। यह हर ऐप अकेले नहीं सुलझा सकता, इसलिए OS स्तर पर VSS बना। VSS COM इंटरफ़ेस वाला ढाँचा है, जिससे ऐप वॉल्यूम पर लिखते रहने पर भी वॉल्यूम का बैकअप संभव होता है।2

3. VSS के पात्र — रिक्वेस्टर, राइटर, प्रोवाइडर

VSS की संरचना तीन भूमिकाओं और उनके बीच मध्यस्थ सेवा में बँटी है।1

भूमिका क्या सँभालती है उदाहरण
VSS सेवा भूमिकाओं के बीच समन्वय। Windows का भाग VSS इंजन स्वयं
रिक्वेस्टर शैडो कॉपी निर्माण (या आयात, या मिटाना) माँगने वाला सॉफ़्टवेयर बैकअप सॉफ़्टवेयर सामान्यतः। Windows Server Backup और DiskShadow भी रिक्वेस्टर हैं
राइटर ऐप पक्ष पर बैकअप डेटा की सुसंगतता गारंटी देने वाला घटक SQL Server या Exchange Server जैसे उत्पाद देते हैं। रजिस्ट्री जैसे Windows घटकों के राइटर OS के साथ आते हैं
प्रोवाइडर शैडो कॉपी वास्तव में बनाने और बनाए रखने वाला घटक Windows का मानक सिस्टम प्रोवाइडर (कॉपी-ऑन-राइट)। स्टोरेज ऐरे विक्रेता हार्डवेयर प्रोवाइडर भी देते हैं

इस विभाजन की खूबी यह है कि एक-दूसरे को न जानने वाले उत्पाद भी सहयोग कर सकते हैं। बैकअप सॉफ़्टवेयर (रिक्वेस्टर) SQL Server की आंतरिक संरचना नहीं जानता, पर SQL Server का राइटर किन फ़ाइलों (कंपोनेंट) का बैकअप चाहिए मेटाडेटा में घोषित करता है, और स्थिर बिंदु के ठीक आसपास अपना डेटा सँवारता है — इसलिए रिक्वेस्टर उस संकेत पर चलकर सुसंगत बैकअप ले लेता है।19 Windows पर चलने वाला लगभग हर तृतीय-पक्ष बैकअप उत्पाद VSS रिक्वेस्टर है।1

सूचना प्रणाली के संचालन में इन तीन भूमिकाओं की याद तब आती है जब समस्या हो। बैकअप विफलता रिक्वेस्टर (सॉफ़्टवेयर पक्ष) की है, किसी राइटर (ऐप पक्ष) की है, या प्रोवाइडर / डिफ़ क्षेत्र (आधार पक्ष) की — जाँच का स्थान पूरी तरह बदल जाता है (खंड 5 और 7)।

4. स्नैपशॉट की संरचना — कॉपी-ऑन-राइट और «स्थिर बिंदु»

4.1. कॉपी-ऑन-राइट — वॉल्यूम की नकल किए बिना «उस क्षण» को सहेजना

«स्नैपशॉट» सुनकर पूरा वॉल्यूम दोहराने की कल्पना होती है, पर Windows का मानक सिस्टम प्रोवाइडर कॉपी-ऑन-राइट (copy-on-write) उपयोग करता है। स्नैपशॉट के क्षण लगभग कुछ कॉपी नहीं होता। बाद में मूल वॉल्यूम का ब्लॉक बदले जाने वाला हो तो बदलाव पूरा होने से पहले उस ब्लॉक की पूर्व सामग्री डिफ़ क्षेत्र (diff area, शैडो कॉपी संग्रह) में भेजकर लेखन आगे बढ़ता है।1 प्रत्येक ब्लॉक की पहली बार की ओवरराइट पर ही यह स्थानांतरण चाहिए; पहले से भेजे ब्लॉक पर फिर लिखने से डिफ़ क्षेत्र नहीं बढ़ता।

क्षण मूल वॉल्यूम डिफ़ क्षेत्र
T0: स्नैपशॉट बना 1 2 3 4 5 (खाली)
T1: ब्लॉक 3 बदला 1 2 3’ 4 5 3 (बदले से पहले की सामग्री यहाँ गई)
T2: शैडो कॉपी पढ़ना ब्लॉक 1, 2, 4, 5 यहाँ से पढ़े जाते हैं ब्लॉक 3 यहाँ से पढ़ा जाता है

«उस क्षण का वॉल्यूम» पढ़ने के लिए न बदले ब्लॉक मूल वॉल्यूम से, बदले ब्लॉक डिफ़ क्षेत्र से पढ़कर जोड़े जाते हैं। केवल बदला अंश कॉपी होता है, इसलिए निर्माण तत्काल है और जगह केवल अंतर जितनी। उलटा यह कि जितना अधिक लेखन, उतनी तेज़ डिफ़ क्षेत्र की खपत (खंड 7 की पूर्व-छाया), और डिफ़ क्षेत्र स्रोत डेटा वाली मशीन के NTFS वॉल्यूम पर होता है।1 इस तंत्र को सिस्टम प्रोवाइडर की घटक फ़ाइल swprv.dll और वॉल्यूम I/O काटने वाला ड्राइवर volsnap.sys थामते हैं।1 I/O स्टैक में «कैसे काटते हैं» में रुचि हो तो «फ़िल्टर ड्राइवर और मिनीफ़िल्टर» भी देखें।

अन्य विधियाँ भी हैं: मिरर काटकर पूर्ण कॉपी, और बदलाव दूसरे वॉल्यूम पर लिखने वाला रीडायरेक्ट-ऑन-राइट; हार्डवेयर प्रोवाइडर स्टोरेज ऐरे के अनुकूल विधि चुनते हैं।1

4.2. स्थिर बिंदु बनाने का प्रवाह — फ़्रीज़ 60 सेकंड, निर्माण 10 सेकंड का समन्वय

कॉपी-ऑन-राइट «कैसे सहेजें» है; VSS की असल ताकत «किस क्षण की अवस्था सहेजें» है — अर्थात स्थिर बिंदु कैसे बने। शैडो कॉपी निर्माण इस प्रवाह से चलता है।1

शैडो कॉपी निर्माण का प्रवाहशैडो कॉपी निर्माण का प्रवाह। रुकता केवल कुछ सेकंड से कुछ दसियों सेकंड है; बैकअप स्वयं उसके बाद स्नैपशॉट पर चलता हैरिक्वेस्टर निर्माण का अनुरोध करता हैराइटरों की सूची बनाकर मेटाडेटा एकत्र करता हैप्रत्येक राइटर बैकअप लक्ष्य(कंपोनेंट) XML में घोषित करता हैप्रत्येक राइटर डेटा तैयार करता हैलॉग रोल, कैश फ़्लश आदिपुनर्प्राप्य सुसंगत अवस्था तक लाता हैराइटरों का लेखन I/O फ़्रीज़(पढ़ना संभव। अधिकतम 60 सेकंड तक)VSS फ़ाइल सिस्टम बफ़र फ़्लश करता हैऔर फ़ाइल सिस्टम फ़्रीज़ करता हैप्रोवाइडर शैडो कॉपी बनाता है(10 सेकंड के भीतर। इस दौरान लेखन I/O फ़्रीज़)फ़ाइल सिस्टम मुक्त → राइटर थॉ (thaw)ऐप लेखन फिर शुरू करते हैंरिक्वेस्टर शैडो कॉपी सेसमय लेकर बैकअप चलाता है

चित्र 1: शैडो कॉपी निर्माण का प्रवाह। रुकता केवल कुछ सेकंड से कुछ दसियों सेकंड है; बैकअप स्वयं उसके बाद स्नैपशॉट पर चलता है

ध्यान के तीन बिंदु हैं।

  1. ऐप रुकता केवल स्थिर बिंदु बनाने के क्षण। फ़्रीज़ अधिकतम 60 सेकंड, प्रोवाइडर का निर्माण (कमिट) 10 सेकंड के भीतर; कोई सीमा टूटे तो निर्माण रद्द और रिक्वेस्टर फिर कोशिश करता है।1 घंटों लग सकने वाला वास्तविक बैकअप तैयार, केवल-पढ़ने योग्य शैडो कॉपी पर, ऐप को चलाए रखते हुए चलता है।
  2. फ़्रीज़ के दौरान पढ़ना संभव रहता है। रुकता केवल लेखन I/O है।1
  3. फ़ाइल सिस्टम भी फ़्रीज़ होता है। VSS फ़ाइल सिस्टम बफ़र फ़्लश कर फिर फ़्रीज़ करता है, इसलिए कैश में बैठे लेखन और फ़ाइल सिस्टम मेटाडेटा सुसंगत क्रम में स्नैपशॉट में आते हैं।1

4.3. क्रैश सुसंगतता और ऐप्लिकेशन सुसंगतता

यहाँ बैकअप की गुणवत्ता तय करने वाला महत्वपूर्ण अंतर आता है।

राइटर के सहयोग बिना बनी शैडो कॉपी Microsoft की शब्दावली में क्रैश सुसंगत (crash consistent) अवस्था है। आधिकारिक परिभाषा है «ऐसी विनाशकारी विफलता के बाद पाई जाने वाली डिस्क अवस्था के बराबर, जो सिस्टम अचानक बंद कर दे», और उससे पुनर्स्थापना «अचानक बंद के बाद पुनःप्रारंभ के बराबर» कही गई है।3 फ़ाइल सिस्टम के रूप में भ्रष्ट नहीं, पर ऐप की दृष्टि से «लिखते समय बिजली खींच ली गई क्षण» है। लेनदेन-लॉग पुनर्प्राप्ति वाला डेटाबेस अक्सर इससे उबर सकता है, पर पहले पुनर्प्राप्ति चलनी ही है — यह बोनस नहीं, पूर्व शर्त है।

राइटर का सहयोग हो तो स्थिर बिंदु से ठीक पहले प्रत्येक राइटर लेनदेन लॉग रोल करता है, कैश फ़्लश करता है, और डेटा को उस सुसंगत अवस्था में लाता है जिसे ऐप स्वयं सही पुनर्प्राप्ति योग्य गारंटी करता है।1 यही ऐप्लिकेशन सुसंगतता है, और राइटर तंत्र का अस्तित्व इसीलिए है। ध्यान रहे: राइटर जो गारंटी देता है वह «ऐप के लिए सुसंगत, पुनर्प्राप्य अवस्था» है — वह चल रहे लेनदेन चुपचाप कमिट कर पूरा नहीं करता। अकमिटेड काम पुनर्स्थापना पर रोलबैक होता है, साधारण डेटाबेस पुनर्प्राप्ति जैसा। राइटर यह गुणवत्ता ऐप रोके बिना, कुछ दसियों सेकंड के फ़्रीज़ से देता है।

बैकअप सॉफ़्टवेयर में «VSS उपयोग करें» या «ऐप्लिकेशन सुसंगतता गारंटी करें» जैसी सेटिंग इसी अंतर की उपज हैं। फ़ाइल सर्वर की साधारण फ़ाइलों पर क्रैश सुसंगतता प्रायः समस्या नहीं; पर डेटाबेस या मेल स्टोर वाले सर्वर पर संबंधित राइटर स्वस्थ होना ही बैकअप की गुणवत्ता है।

5. संचालन कमांड का व्यवहार — vssadmin और «पिछले संस्करण»

सूचना प्रणाली कर्मी VSS की अवस्था देखने के लिए व्यवहार में vssadmin उपयोग करते हैं (उन्नत Command Prompt से चलाएँ)। वर्तमान कमांड संदर्भ में list shadows / list writers / delete shadows / resize shadowstorage क्लाइंट और सर्वर दोनों पर उपलब्ध बताए गए हैं।4 Windows Server-उन्मुख संदर्भ में इसके अतिरिक्त create shadow / list shadowstorage / list providers आदि हैं।5 ध्यान रहे, vssadmin केवल सिस्टम प्रोवाइडर की शैडो कॉपी प्रबंधित कर सकता है।1

कमांड क्या दिखता है व्यवहार में कहाँ
vssadmin list shadows मौजूदा शैडो कॉपी की सूची — निर्माण समय, लक्ष्य वॉल्यूम, शैडो कॉपी वॉल्यूम नाम पुनर्स्थापना के लिए स्थिर बिंदु कितनी पीछे तक है। बैकअप के बाद अवशेष तो नहीं
vssadmin list writers पंजीकृत राइटरों की सूची और अवस्था बैकअप सॉफ़्टवेयर VSS त्रुटि से गिरे तो पहली छँटाई — कौन-सा राइटर, इसलिए कौन-सा ऐप, विफल है
vssadmin list shadowstorage शैडो कॉपी संग्रह (डिफ़ क्षेत्र) का उपयोग, आवंटन, सीमा «पिछला संस्करण गायब» की जाँच — सीमा लगी तो नहीं
vssadmin resize shadowstorage — (डिफ़ क्षेत्र की सीमा बदलता है) रखनी पीढ़ियों के अनुपात में डिफ़ क्षेत्र छोटा हो तो विस्तार10

list writers में राइटर त्रुटि अवस्था में हो तो संदेह VSS पर नहीं, उस राइटर देने वाले ऐप पर है। उस ऐप की सेवा अवस्था और Application/System इवेंट लॉग देखें (खंड 7)।

resize shadowstorage का /maxsize सीमा KB/MB/GB जैसी इकाई से तय करता है; न दें तो सीमा ही नहीं। ध्यान की बात: Microsoft के दस्तावेज़ स्पष्ट कहते हैं कि संग्रह सीमा बदलना — खासकर घटाना — स्वयं शैडो कॉपी खो सकता है।10 कई पीढ़ियाँ रखनी हों तो उस वॉल्यूम की सीमा हल्के से न घटाएँ।

5.1. «पिछले संस्करण» से संबंध

फ़ाइल सर्वर पर साझा फ़ोल्डर की शैडो कॉपी (Shadow Copies of Shared Folders) चालू करें तो साझा पर फ़ाइलों की किसी क्षण की कॉपी नियमित रहती है, और उपयोगकर्ता मिटाई या अधिलेखित फ़ाइल व्यवस्थापक के बिना पिछले संस्करण से लौटा सकते हैं।1 हेल्पडेस्क का काम घटाने वाला, VSS का सबसे परिचित अनुप्रयोग है।

पर सीमा है। सिस्टम प्रोवाइडर की शैडो कॉपी प्रति वॉल्यूम अधिकतम 512, जिनमें साझा फ़ोल्डर की शैडो कॉपी सुविधा डिफ़ॉल्ट में 64 तक रखती है (रजिस्ट्री मान MaxShadowCopies से बदला जा सकता है)।1 और अगले खंडों में है, डिफ़ क्षेत्र कम पड़े तो पुरानी पीढ़ी स्वतः मिटती है। «कितनी पीढ़ियाँ रहेंगी» सेट की संख्या से नहीं, लेखन मात्रा और डिफ़ क्षेत्र के आकार से तय होती है — यही समझ सुरक्षित है।

6. डेवलपर के रूप में जुड़ाव — स्वयं के ऐप को VSS चाहिए?

यहाँ से डेवलपर की दृष्टि है। «उपयोग में फ़ाइलें भी कॉपी कर सके, ऐसी बैकअप सुविधा जोड़ो» कहा जाए तो VSS से कैसे जुड़ें?

6.1. रिक्वेस्टर स्वयं लिखना बड़ा काम है

VSS API, रिक्वेस्टर और राइटर दोनों के लिए, COM और C++ इंटरफ़ेस के रूप में है (रिक्वेस्टर का केंद्र IVssBackupComponents)।6 आधिकारिक .NET रैपर नहीं, और राइटर मेटाडेटा एकत्र करने से स्नैपशॉट सेट प्रबंधन, त्रुटि के बाद सफ़ाई तक सही लागू करना पड़ता है — व्यावसायिक ऐप की एक सुविधा के रूप में हल्के से नहीं जोड़ा जा सकता। हमारे ठेका-विकास अनुमान में «VSS रिक्वेस्टर बनाना» अलग पंक्ति की मद है।

यथार्थ उत्तर दो हैं। पहला, मौजूदा VSS-सक्षम बैकअप उत्पाद पर छोड़ दें। दूसरा, Windows Server पर DiskShadow स्क्रिप्ट से चलाएँ। DiskShadow OS के साथ आने वाला VSS रिक्वेस्टर है; संवादात्मक मोड के अलावा स्क्रिप्ट मोड (diskshadow /s script.txt) है, और एक स्क्रिप्ट शैडो कॉपी बनाना, ड्राइव अक्षर पर खोलना (expose), कॉपी करने वाला बैच चलाना (exec), और बाद की सफ़ाई तक ढक सकती है।71 «शैडो कॉपी बनाओ → उसमें से स्वयं के कॉपी तर्क से फ़ाइल निकालो → मिटाओ» यह प्रवाह बिना एक पंक्ति COM लिखे बनता है। पर DiskShadow केवल Windows Server है, क्लाइंट संस्करण में नहीं आता।1 माँग में क्लाइंट PC भी हों तो यहीं मौजूदा बैकअप उत्पाद की ओर झुकाव बढ़ता है।

6.2. क्या VSS वास्तव में चाहिए? — निर्णय तालिका

हमारे अनुभव में «उपयोग में फ़ाइल कॉपी» की अधिकांश माँग VSS के बिना सुलझती है। माँग का स्तर पहचानकर औज़ार चुनें।

माँग यथार्थ उत्तर VSS चाहिए?
दूसरे ऐप की लिखी जा रही फ़ाइल थोड़ी प्रतीक्षा कर पढ़ लेना काफी पुनःप्रयास — पुनःप्रयास प्लस प्रतीक्षा अंतराल। साझाकरण उल्लंघन प्रायः क्षणिक अवस्था है नहीं
दूसरा ऐप पढ़ने की साझेदारी देता है मिला साझा मोड से खोलें (.NET में FileShare.ReadWrite)। पर अधूरे लेखन पढ़ने का जोखिम स्वयं सँभालें नहीं
व्यवसाय के विराम (रात, सुस्ती) पर ऐप रोका जा सकता है रुके हुए कॉपी करें। सबसे सरल और सबसे विश्वसनीय नहीं
दूसरे ऐप से एकीकरण का समझौता हो सकता है अणु हस्तांतरण डिज़ाइन पर जाएँ — लिखकर फिर स्थान पर नाम बदलना, उदाहरण के लिए (बहिष्करण लेख देखें) नहीं
न रुक सकने वाले ऐप के पूरे डेटा को सुसंगत अवस्था में दोहराना है VSS। पहले मौजूदा बैकअप उत्पाद, फिर DiskShadow स्क्रिप्ट (केवल Server), अंत में स्वयं का रिक्वेस्टर हाँ

6.3. स्वयं के ऐप को राइटर पंजीकृत करना चाहिए?

उलटा प्रश्न भी साफ़ करें: क्या स्वयं का व्यावसायिक ऐप VSS राइटर दे? लिखें तो ग्राहक कोई भी बैकअप उत्पाद उपयोग करे, आपके ऐप का डेटा ऐप्लिकेशन सुसंगतता से लिया जाएगा। सामान्य राइटर से हल्का एक्सप्रेस राइटर (IVssExpressWriter) भी है, पर वह केवल किन फ़ाइलों को शामिल/बाहर रखना मेटाडेटा घोषित कर पंजीकृत करता है।6 फ़्रीज़/थॉ सूचना नहीं मिलती, इसलिए स्नैपशॉट निर्माण से मेल खाते ऐप के लेखन रोकना संभव नहीं। एक्सप्रेस राइटर तभी ठीक है जब सहेज डिज़ाइन लिखते बीच पकड़े जाने पर भी न टूटे (अर्थात क्रैश सुसंगतता काफी हो); स्थिर बिंदु पर समन्वय सचमुच चाहिए तो पूरा राइटर कार्यान्वयन चाहिए।

फिर भी निर्णय का संकेत सरल है।

  • डेटा SQL Server जैसे DB में हो तो नहीं चाहिए। DB का अपना राइटर सुसंगतता गारंटी करता है।1
  • साधारण फ़ाइल सहेज हो तो पहले सहेज प्रक्रिया के डिज़ाइन से सुलझाएँ। अस्थायी फ़ाइल में पूरा लिखकर अणु नाम-परिवर्तन से स्थान पर रखें तो क्रैश सुसंगत स्नैपशॉट भी «टूटी सहेजी फ़ाइल» नहीं छोड़ता।
  • राइटर पंजीकरण विचारने योग्य केवल उन ऐप के लिए है जो कई फ़ाइलों पर फैला स्वामित्व डेटा स्टोर रखते हैं और स्थिर बिंदु पर आपसी सुसंगतता चाहिए। इतने डेटा को घर के फ़ॉर्मैट में रखना ही सही है, यह पहले फिर सोचना चाहिए।

7. जाल — संचालन में सचमुच असर डालने वाले चार

7.1. VSS स्वयं बैकअप नहीं है

सबसे महत्वपूर्ण जाल। सिस्टम प्रोवाइडर की शैडो कॉपी मूल डेटा वाली उसी मशीन की डिस्क पर बैठा अंतर है। डिफ़ क्षेत्र खो जाए तो पुनर्निर्माण की सामग्री नहीं, इसलिए डिस्क खराबी, मशीन की चोरी-खोई, या पूरे वॉल्यूम का एन्क्रिप्शन — इनसे कोई रक्षा नहीं। Microsoft के दस्तावेज़ शैडो कॉपी और बैकअप को साफ़ अलग करते हैं: «शैडो कॉपी से टेप जैसे माध्यम पर कॉपी की सामग्री बैकअप है, और कॉपी के बाद शैडो कॉपी मिटाई जा सकती है।»1 शैडो कॉपी स्थिर बिंदु है और गलती से तेज़ वापसी — अलग माध्यम, अलग स्थल के बैकअप का विकल्प नहीं।

7.2. राइटर की त्रुटि ऐप पक्ष की समस्या है

बैकअप सॉफ़्टवेयर «VSS त्रुटि» से गिरे तो पहले vssadmin list writers से पहचानें कौन-सा राइटर विफल है। राइटर वस्तुतः ऐप (या Windows घटक) का हिस्सा है1, इसलिए कारण जाँच का मुख्य मैदान उस ऐप की सेवा अवस्था और इवेंट लॉग हैं। «बैकअप सॉफ़्टवेयर की त्रुटि» के रूप पर बहककर केवल बैकअप सॉफ़्टवेयर जाँचते रहना लंबा चक्कर है। छँटाई का सामान्य ढाँचा वही है जो «जब स्रोत कोड और दस्तावेज़ के बिना सिस्टम मिल जाए — बिना रोके चलाने-रखरखाव की व्यावहारिक प्रक्रिया» में है: देखे जा सकने वाले तथ्यों से संदिग्ध घटाएँ।

7.3. रैनसमवेयर शैडो कॉपी मिटाने आता है

रक्षा पक्ष की चेतावनी के रूप में जानने योग्य तथ्य। पिछले संस्करण से लौटा सकें तो रैनसमवेयर के बाद भी लौटेंगे — यह आशा लुभाती है, पर बहुत सा रैनसमवेयर एन्क्रिप्शन के पहले या बाद शैडो कॉपी मिटाकर इस पुनर्स्थापना पथ को बंद कर देता है, यह व्यापक रूप से ज्ञात है। शैडो कॉपी मिटाना व्यवस्थापक अधिकार हों तो पूरी तरह वैध कमांड से हो जाता है, इसलिए घुस चुके हमलावर के विरुद्ध अंतिम दीवार नहीं बन सकता। अतः उपाय की धुरी: (1) शैडो कॉपी को «पुनर्प्राप्ति योजना का भाग» नहीं, «हो तो तेज़» मानें; (2) हमलावर की पहुँच से बाहर ऑफ़लाइन, अलग स्थल का बैकअप अलग रखें; (3) दैनिक संचालन खातों को व्यवस्थापक अधिकार न दें। बैकअप, एन्क्रिप्शन और निपटान तक PC जीवनचक्र की रक्षा के लिए «BitLocker व्यावहारिक मार्गदर्शिका — रिकवरी कुंजी प्रबंधन से शुरू ड्राइव एन्क्रिप्शन» और «Windows PC का निपटान करने से पहले — डेटा मिटाना, खाता अनलिंक, बैकअप की व्यावहारिक जाँच-सूची» भी देखें।

7.4. डिफ़ क्षेत्र खत्म हो तो पुरानी पीढ़ियाँ चुपचाप गायब हो जाती हैं

खंड 4 में देखा, कॉपी-ऑन-राइट डिफ़ क्षेत्र तब खाता है जब स्नैपशॉट के बाद प्रत्येक ब्लॉक पहली बार बदले। पहले भेजे ब्लॉक पर कितनी भी ओवरराइट खपत नहीं बढ़ाती, इसलिए खपत «कितनी बार लिखा» से नहीं, «रखी स्नैपशॉट के बाद कितने व्यापक ब्लॉक बदले» से तय होती है। और डिफ़ क्षेत्र सीमा पर पहुँचे तो उस वॉल्यूम की शैडो कॉपी पुरानी से मिटती हैं।1 संवादात्मक उपयोगकर्ता को कुछ नहीं बताया जाता, इसलिए «पिछले सप्ताह का संस्करण लौटा सकेंगे» जब लौट नहीं पाता तब पता चलता है। पूरी तरह मौन नहीं: System लॉग में volsnap स्रोत के इवेंट दर्ज होते हैं (डिफ़ क्षेत्र के लिए जगह न बनने पर मिटाने का 25, विस्तार विफल या सीमा पर रुकने का 35/36 आदि)। नियमित जाँच के अलावा इन volsnap इवेंट को निगरानी और अलर्ट में रखें तो क्षति जल्दी पकड़ में आए। भारी फ़ाइल अद्यतन, सामूहिक रूपांतरण, डीफ़्रैग जैसे «पूरे वॉल्यूम पर फेर» काम डिफ़ क्षेत्र एक झटके में इसलिए खा जाते हैं कि खपत बदले ब्लॉकों की चौड़ाई से तय होती है। रखी पीढ़ियाँ व्यवसाय की माँग («गलत मिटान कितने दिन बाद तक पकड़ में आए») पूरी कर रही हैं या नहीं, vssadmin list shadowstorage के उपयोग से नियमित देखें, और ज़रूरत हो तो सीमा बढ़ाएँ।510

8. सारांश

  • उपयोग में फ़ाइल सामान्यतः कॉपी न हो पाना साझाकरण उल्लंघन और सुसंगतता की बात है, और वह डेटा की रक्षा का सही तंत्र है। «रोके बिना सुसंगत कॉपी चाहिए» का OS-स्तरीय उत्तर VSS है।
  • VSS वह ढाँचा है जिसमें VSS सेवा तीन भूमिकाओं — रिक्वेस्टर (माँग), राइटर (सुसंगतता गारंटी), प्रोवाइडर (निर्माण) — के बीच मध्यस्थता करती है, जिससे एक-दूसरे को न जानने वाला बैकअप सॉफ़्टवेयर और व्यावसायिक ऐप सहयोग कर सकते हैं।
  • सिस्टम प्रोवाइडर कॉपी-ऑन-राइट उपयोग करता है, और स्थिर बिंदु «राइटर फ़्रीज़ (अधिकतम 60 सेकंड) → निर्माण (10 सेकंड के भीतर) → थॉ» से बनता है। राइटर सहयोग न हो तो क्रैश सुसंगतता, हो तो ऐप्लिकेशन सुसंगतता।
  • संचालन जाँच vssadmin से (list shadows / list writers / list shadowstorage)। राइटर त्रुटि पर ऐप पक्ष संदेह करें, डिफ़ क्षेत्र का उपयोग नियमित देखें।
  • डेवलपर पहले निर्णय तालिका से देखें कि पुनःप्रयास, साझा मोड, रोक का समय, या एकीकरण डिज़ाइन काफी है या नहीं, और सचमुच ज़रूरत हो तभी VSS की ओर जाएँ। स्वयं के कार्यान्वयन से पहले DiskShadow स्क्रिप्ट (केवल Server) या मौजूदा उत्पाद यथार्थ उत्तर है।
  • शैडो कॉपी बैकअप नहीं है। वह मूल वॉल्यूम के अक्षत ब्लॉकों पर निर्भर अंतर मात्र है; डिस्क खराबी जैसी मूल वॉल्यूम की हानि पर बेबस है, और रैनसमवेयर पर भी शैडो कॉपी मिटने या डिफ़ क्षेत्र खत्म होने से भरोसा नहीं। ऑफ़लाइन, अलग स्थल के बैकअप के साथ जोड़ें।

संबंधित लेख

संबंधित परामर्श क्षेत्र

KomuraSoft LLC «उपयोग में फ़ाइल की कॉपी और बैकअप सुविधा» सहित व्यावसायिक ऐप का डिज़ाइन-विकास, फ़ाइल एकीकरण के आसपास साझाकरण उल्लंघन और बैकअप विफलता (VSS राइटर त्रुटि) की मूल-कारण जाँच, तथा फ़ाइल सर्वर के बैकअप और पीढ़ी प्रबंधन की संचालन संरचना सँभालता है। «क्या VSS वास्तव में ज़रूरी आवश्यकता है» इस प्रश्न से शुरू करना पर्याप्त है।

संदर्भ लिंक

  1. Microsoft Learn, Volume Shadow Copy Service (Windows Server). VSS सेवा, रिक्वेस्टर (बैकअप सॉफ़्टवेयर — Windows Server Backup और DPM उदाहरण हैं, और Windows पर लगभग हर बैकअप सॉफ़्टवेयर रिक्वेस्टर है), राइटर (SQL Server या Exchange Server जैसे उत्पाद देते हैं, रजिस्ट्री जैसे Windows घटकों के राइटर OS के साथ आते हैं) और प्रोवाइडर की भूमिका विभाजन पर; शैडो कॉपी निर्माण प्रक्रिया (राइटर मेटाडेटा एकत्र → लेनदेन पूरा करना, लॉग रोल, कैश फ़्लश से तैयारी → लेखन I/O फ़्रीज़ अधिकतम 60 सेकंड, पढ़ना संभव → फ़ाइल सिस्टम बफ़र फ़्लश और फ़्रीज़ → प्रोवाइडर द्वारा निर्माण 10 सेकंड के भीतर → थॉ, सीमा टूटे तो रद्द और रिक्वेस्टर पुनःप्रयास) पर; पूर्ण कॉपी, कॉपी-ऑन-राइट, रीडायरेक्ट-ऑन-राइट तीन विधियों पर; सिस्टम प्रोवाइडर के कॉपी-ऑन-राइट और डिफ़ क्षेत्र के NTFS वॉल्यूम पर होने पर; घटक फ़ाइलों swprv.dll और volsnap.sys पर; डिफ़ क्षेत्र खाली जगह खत्म हो तो उस वॉल्यूम की शैडो कॉपी पुरानी से मिटने पर; सॉफ़्टवेयर शैडो कॉपी प्रति वॉल्यूम अधिकतम 512 और साझा फ़ोल्डर की शैडो कॉपी डिफ़ॉल्ट 64 (MaxShadowCopies से बदली जा सकती है) पर; साझा फ़ोल्डर की शैडो कॉपी से उपयोगकर्ता व्यवस्थापक के बिना मिटाई-बदली फ़ाइल लौटा सकने पर; शैडो कॉपी और बैकअप के अंतर (माध्यम पर कॉपी की सामग्री बैकअप है, शैडो कॉपी मिटाई जा सकती है) पर; DiskShadow के VSS रिक्वेस्टर और केवल Windows Server होने पर; तथा vssadmin के केवल सिस्टम प्रोवाइडर की शैडो कॉपी प्रबंधित कर सकने पर। ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28

  2. Microsoft Learn, Volume Shadow Copy Service (Win32). इस पर कि VSS उन COM इंटरफ़ेस समूह को लागू करता है जो सिस्टम पर ऐप वॉल्यूम पर लिखते रहने के दौरान भी वॉल्यूम का बैकअप चलाने वाला ढाँचा देते हैं, और Windows XP से समर्थित हैं। ↩ ↩2

  3. Microsoft Learn, VSS Glossary: crash consistent state. इस पर कि क्रैश सुसंगत अवस्था «ऐसी विनाशकारी विफलता के बाद पाई जाने वाली डिस्क अवस्था के बराबर है जो सिस्टम अचानक बंद कर दे»; ऐसे शैडो कॉपी सेट से पुनर्स्थापना «अचानक बंद के बाद पुनःप्रारंभ के बराबर» है; और यह राइटर समर्थन के बिना शैडो-कॉपी किए डेटा की डिफ़ॉल्ट अवस्था है। ↩ ↩2

  4. Microsoft Learn, vssadmin. इस पर कि vssadmin वर्तमान वॉल्यूम शैडो कॉपी और स्थापित सभी शैडो कॉपी राइटर-प्रोवाइडर दिखाने वाला कमांड है, और delete shadows / list shadows / list writers / resize shadowstorage उपकमांड क्लाइंट और सर्वर दोनों पर उपलब्ध बताए गए हैं। ↩ ↩2

  5. Microsoft Learn, Vssadmin (Windows Server 2012 R2 and 2012). Windows Server-उन्मुख संदर्भ में vssadmin उपकमांड सूची add shadowstorage / create shadow / delete shadows / delete shadowstorage / list providers / list shadows / list shadowstorage (सिस्टम की सभी शैडो कॉपी संग्रह संबद्धताएँ सूचीबद्ध करता है) / list volumes / list writers / resize shadowstorage के रूप में दर्ज होने पर। ↩ ↩2 ↩3

  6. Microsoft Learn, Volume Shadow Copy API Interfaces. इस पर कि VSS API रिक्वेस्टर और राइटर बनाने हेतु COM तथा C++ इंटरफ़ेस के रूप में है, और रिक्वेस्टर के लिए IVssBackupComponents परिवार, राइटर के लिए IVssCreateWriterMetadata परिवार, तथा हल्के एक्सप्रेस राइटर के लिए IVssExpressWriter परिभाषित हैं। ↩ ↩2 ↩3

  7. Microsoft Learn, Diskshadow. इस पर कि DiskShadow VSS की क्षमताएँ खोलने वाला उपकरण है, संवादात्मक कमांड इंटरप्रेटर और स्क्रिप्ट मोड (diskshadow /s script.txt) दोनों के साथ; चलाने के लिए स्थानीय Administrators समूह की सदस्यता चाहिए; और add, create, expose (स्थायी शैडो कॉपी को ड्राइव अक्षर आदि के रूप में खोलना), exec (स्थानीय फ़ाइल चलाना), delete shadows जैसे कमांड से शैडो कॉपी निर्माण से खोलने और बैकअप स्क्रिप्ट चलाने तक एक स्क्रिप्ट में लिखा जा सकता है। ↩ ↩2

  8. Microsoft Learn, CreateFileW function. इस पर कि फ़ाइल खोलते समय dwShareMode बाद के खोलने को अनुमति साझा पहुँच (पढ़ना, लिखना, मिटाना) तय करता है; और मौजूदा हैंडल के साझा मोड से टकराने वाली पहुँच माँगने वाला खोलना साझाकरण उल्लंघन (ERROR_SHARING_VIOLATION) से विफल होता है। ↩

  9. Microsoft Learn, Overview of Processing a Backup Under VSS. इस पर कि बैकअप प्रक्रिया में रिक्वेस्टर और राइटर सहयोग करते हैं, राइटर केवल-पढ़ने योग्य मेटाडेटा (Writer Metadata Document) से अपनी फ़ाइलें (कंपोनेंट) घोषित करता है, रिक्वेस्टर उसे पढ़कर बैकअप लक्ष्य चुनता है और अपने मेटाडेटा (Backup Components Document) में दर्ज करता है; तथा राइटर शैडो कॉपी निर्माण से पहले I/O संक्षेप में रोकता है और पूरा होने पर सामान्य संचालन पर लौटता है। ↩

  10. Microsoft Learn, Vssadmin resize shadowstorage. इस पर कि यह शैडो कॉपी संग्रह के रूप में उपयोग योग्य अधिकतम आकार बदलने वाला कमांड है; /maxsize न दें तो संग्रह उपयोग पर सीमा नहीं; मान KB/MB/GB/TB/PB/EB इकाई से दिया जा सकता है; और संग्रह संबद्धता का आकार बदलने से शैडो कॉपी खोने की चेतावनी है। ↩ ↩2 ↩3

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

व्यावहारिक मल्टीथ्रेडिंग सर्वोत्तम प्रथाएँ: C++ संस्करण — RAII और jthread से संरचना द्वारा दुर्घटनाएँ मिटाना

C++ में मल्टीथ्रेडिंग वह संसार है जहाँ डेटा रेस अपरिभाषित व्यवहार बन जाता है। यह लेख std::thread के डिस्ट्रक्टर का जाल, jthread और stop_t...

लेख पढ़ें

व्यावहारिक मल्टीथ्रेडिंग सर्वोत्तम प्रथाएँ: .NET संस्करण — और थ्रेड जोड़ने से पहले क्या तय करें

मल्टीथ्रेडेड .NET/C# कोड को कभी-कभी क्रैश या हैंग होने से बचाने वाले डिज़ाइन नियमों का व्यावहारिक सार: थ्रेड स्वयं न बनाकर Task पर चलें, ...

लेख पढ़ें

स्लीप से रिज़्यूम पर टूटने वाले ऐप — Windows पावर इवेंट कैसे काम करते हैं और उनसे बचने वाले व्यावसायिक ऐप कैसे बनाएँ

लैपटॉप खोला और व्यावसायिक ऐप के कनेक्शन मर चुके थे — कारण वह डिज़ाइन है जिसने स्लीप का हिसाब ही नहीं रखा। यह लेख WM_POWERBROADCAST सूचना ...

लेख पढ़ें

Windows ऐप सुलभता का परिचय — UI Automation और युक्तियुक्त समायोजन आवश्यकताओं की तैयारी

अप्रैल 2024 से प्रभावी विकलांगता भेदभाव उन्मूलन संशोधन के संदर्भ में यह लेख WinForms/WPF में नामकरण, कीबोर्ड संचालन, कंट्रास्ट और सत्यापन...

लेख पढ़ें

Group Policy से Intune — छोटे और मध्यम व्यवसायों के लिए डिवाइस-प्रबंधन माइग्रेशन मार्गदर्शिका

जब AD सर्वर बदलने आए, Group Policy पर रहें या Entra ID प्लस Intune पर जाएँ? यह लेख छोटे और मध्यम व्यवसायों के लिए दोनों के लागू होने के अ...

लेख पढ़ें

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

शैडो कॉपी हों तो क्या बैकअप की ज़रूरत नहीं?
ज़रूरत खत्म नहीं होती। Windows के मानक सिस्टम प्रोवाइडर की शैडो कॉपी कॉपी-ऑन-राइट अंतर हैं — वे उस क्षण की पूरी अलग प्रति नहीं, बल्कि मूल वॉल्यूम के अभी न बदले ब्लॉकों पर निर्भर हैं। डिफ़ क्षेत्र (diff area) दूसरे वॉल्यूम पर रखें तब भी मूल वॉल्यूम खोने पर पुनर्स्थापना असंभव रहती है, और डिस्क खराबी या PC की चोरी-खोई जैसी घटनाओं में, जहाँ मूल वॉल्यूम ही चला जाता है, यह बेबस है। रैनसमवेयर पर भी: एन्क्रिप्शन का लेखन बदले से पहले के ब्लॉक डिफ़ क्षेत्र में भेजता है, पर वास्तविक हमले शैडो कॉपी मिटा देते हैं या भारी पुनर्लेखन से डिफ़ क्षेत्र खत्म कर देते हैं, इसलिए भरोसा नहीं किया जा सकता। Microsoft के दस्तावेज़ दोनों को अलग रखते हैं: शैडो कॉपी से टेप जैसे माध्यम पर कॉपी किया डेटा बैकअप है, और कॉपी के बाद शैडो कॉपी मिटाई जा सकती है। शैडो कॉपी «बैकअप लेने का स्थिर बिंदु» और «हल्की गलती से तेज़ वापसी» है — अलग माध्यम, अलग स्थल के बैकअप का विकल्प नहीं।
स्वयं के व्यावसायिक ऐप में उपयोग में फ़ाइल कॉपी करनी है — क्या VSS उपयोग करें?
पहले बिना VSS के रास्ता खोजना यथार्थ है। VSS रिक्वेस्टर COM-आधारित नेटिव API (IVssBackupComponents आदि) से लिखना पड़ता है, .NET के लिए आधिकारिक रैपर नहीं है, इसलिए स्वयं के ऐप में जोड़ना बड़ा काम है। माँग «दूसरा प्रोसेस लिख रहा हो तो फ़ाइल कभी पढ़ लेना काफी» हो तो पुनःप्रयास काफी है; «पढ़ने की साझेदारी अनुमति है» तो साझा मोड मिलाकर खोलना काफी है। ऐप थोड़ी देर रोका जा सके तो व्यवसाय के विराम पर कॉपी सबसे सरल और विश्वसनीय है। «न रुक सकने वाले ऐप के पूरे डेटा को सुसंगत अवस्था में दोहराना» ही VSS का स्थान है, और तब भी स्वयं का कार्यान्वयन पहले नहीं — VSS-सक्षम बैकअप उत्पाद या DiskShadow स्क्रिप्ट पहले देखें।
vssadmin list writers में राइटर त्रुटि अवस्था में है। क्या करें?
मूल बात यह है कि उसे उस राइटर के ऐप पक्ष की समस्या मानकर जाँचें। vssadmin list writers पंजीकृत राइटरों को अवस्था सहित दिखाता है, इसलिए पहले पहचानें कौन-सा राइटर विफल है। राइटर SQL Server जैसे ऐप या Windows घटक (रजिस्ट्री आदि) देते हैं, इसलिए कारण प्रायः VSS में नहीं, बल्कि उस ऐप की सेवा अवस्था या Application/System इवेंट लॉग की त्रुटियों में होता है। संबंधित सेवा पुनः शुरू करें, पुनरुत्पादन की शर्तें छाँटें; न सुलझे तो उस ऐप की सहायता जानकारी देखें। बैकअप सॉफ़्टवेयर VSS त्रुटि से गिरे तो पहली छँटाई भी यही है।
शैडो कॉपी बिना बताए गायब हो गई। क्यों?
सबसे आम कारण डिफ़ क्षेत्र (शैडो कॉपी संग्रह) की कमी है। कॉपी-ऑन-राइट में स्नैपशॉट के बाद प्रत्येक ब्लॉक पहली बार बदलते समय बदले से पहले की सामग्री डिफ़ क्षेत्र में जाती है, इसलिए जितना व्यापक बदलाव उतना अधिक उपभोग। आवंटित सीमा पहुँचते ही Windows सबसे पुरानी शैडो कॉपी से मिटाकर जगह बनाता है। संवादात्मक उपयोगकर्ता को सूचना नहीं मिलती, चुपचाप मिटती है, इसलिए «पिछले संस्करण से पिछले सप्ताह का संस्करण लौटा सकेंगे समझा, पर था ही नहीं» के रूप में पकड़ में आती है (System लॉग में volsnap स्रोत का इवेंट 25 आदि दर्ज होता है, निगरानी में रखें तो पता चलता है)। vssadmin list shadowstorage से उपयोग और सीमा देखें, ज़रूरत हो तो vssadmin resize shadowstorage से सीमा बढ़ाएँ। ध्यान रहे, सीमा बदलना — खासकर घटाना — स्वयं शैडो कॉपी खो सकता है।
फ़ाइल एक्सप्लोरर के «पिछले संस्करण» और VSS का क्या संबंध है?
«पिछले संस्करण» VSS की शैडो कॉपी से फ़ाइल का पुराना रूप निकालने का एक द्वार है। फ़ाइल सर्वर पर «साझा फ़ोल्डर की शैडो कॉपी» (Shadow Copies of Shared Folders) चालू करें तो नियमित शैडो कॉपी बनती हैं, और उपयोगकर्ता साझा फ़ोल्डर की फ़ाइल पर दायाँ क्लिक कर पिछले संस्करण से स्वयं पुनर्स्थापित कर सकते हैं। व्यवस्थापक के बिना मिटाने-अधिलेखन की गलती सुधारना लाभ है। पर वस्तु शैडो कॉपी ही है, इसलिए रखी जा सकने वाली पीढ़ियों की सीमा है, और डिफ़ क्षेत्र कम पड़े तो पुरानी पीढ़ी पहले गायब होती है। «पिछले संस्करण हैं इसलिए बैकअप नहीं चाहिए» लागू नहीं होता — यह लेख के मुख्य भाग में है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।

संपर्क करें

सार्वजनिक लिंक

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal
ब्लॉग पर लौटें