Volume Shadow Copy (VSS) की संरचना और व्यवहार — in-use फ़ाइल का backup क्यों लिया जा सकता है

«दूसरे app की खुली फ़ाइल copy करने गया तो कहा गया कि process फ़ाइल तक पहुँच नहीं सकता क्योंकि वह दूसरे process के इस्तेमाल में है।» «Main system रोके बिना data folder का backup लेने को कहा गया।» «Backup software in-use database फ़ाइल को इतनी आसानी से copy कैसे कर लेता है?» — business app development में भी, file server operations में भी, ये प्रश्न देर-सबेर आते हैं।

उत्तर के केंद्र में Volume Shadow Copy Service (VSS) है। यह Windows में बीस से अधिक वर्षों से बनी हुई है, और Windows Server Backup, System Restore, तथा लगभग हर commercial backup product इसी नींव पर खड़े हैं।¹

यह लेख «in-use फ़ाइल copy» माँगने वाले business app developers और file server व business PC का backup चलाने वाले IT कर्मियों के लिए है। VSS के roles और संरचना, vssadmin से दैनिक operations, और «developer VSS में कितना घुसे» का निर्णय, अगस्त 2026 तक के primary sources पर आधारित है। «Windows I/O की गहराई» श्रृंखला में Cache Manager और NTFS के भीतर देखा गया; यह लेख उसकी अगली कड़ी है, volume के ठीक ऊपर बैठने वाली «snapshot» परत पर।

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

• VSS COM interface समूह और coordination service है, जिससे app लिखते रहने पर भी volume का backup संभव होता है। यह Windows XP से Windows में है।²
• Roles तीन प्लस coordinator हैं। Shadow copy माँगने वाला requester (backup software), app पक्ष पर data की consistency guarantee देने वाला writer (SQL Server आदि), और snapshot वास्तव में बनाने वाला provider — इनके बीच VSS service मध्यस्थता करती है।¹
• Windows का standard system provider copy-on-write इस्तेमाल करता है। पूरा volume नहीं दोहराता; snapshot के बाद बदले जाने वाले blocks ही, बदलने से पहले, diff area में भेजता है। Diff area NTFS volume पर होना चाहिए।¹
• Consistent point «writer freeze (अधिकतम 60 सेकंड) → snapshot create (10 सेकंड के भीतर) → thaw» से बनता है। Time limit पार हो तो create रद्द होता है और requester फिर कोशिश करता है।¹
• Writer सहयोग दे या न दे, copy की गुणवत्ता बदलती है। बिना सहयोग का snapshot «बिजली कटते क्षण की disk» के बराबर है (crash-consistent); सहयोग हो तो log roll और cache flush पूरे हो चुके होते हैं, और app स्वयं recoverable consistent state guarantee करता है (application-consistent)।³¹
• Operations की जाँच vssadmin से होती है। list shadows / list writers / list shadowstorage से वर्तमान देखें, resize shadowstorage से diff area की limit बदलें। Diff area खत्म हो तो पुरानी shadow copy चुपचाप मिटती हैं।⁴⁵¹
• खुद के app में VSS requester जोड़ना बड़ा काम है। COM-based native API है, .NET का official wrapper नहीं। अधिकतर retry, share mode का समायोजन, या थोड़ी रोक काफी है; सचमुच VSS चाहिए तो DiskShadow script यथार्थ उत्तर है (केवल Windows Server)।⁶⁷
• Shadow copy स्वयं backup नहीं है। Copy-on-write diffs original volume के अक्षत blocks पर depend करती हैं, इसलिए disk failure या चोरी जैसी घटना, जहाँ original volume ही खो जाए, पर यह बेबस है। Ransomware पर भी shadow copy स्वयं मिटना (खंड 7.3) या भारी overwrite से diff area खत्म होना (खंड 7.4) भरोसा तोड़ देता है। अलग medium के backup के साथ जोड़ने पर ही अर्थ बनता है।¹

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 26, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. समस्या का ढाँचा — in-use फ़ाइल सामान्यतः copy क्यों नहीं हो पाती

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

महत्वपूर्ण यह है कि यह bug नहीं, data की रक्षा का सही तंत्र है। लिखी जा रही फ़ाइल बीच में पढ़ी जाए तो reader «अधूरी, बीच की state» पाता है। Exclusion का डिज़ाइन «File integration के exclusion control की मूल बातें — file lock और atomic claim की best practices» में विस्तार से है, और apps के बीच integration की नींव है।

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

• Sharing violation की दीवार: Database या business app की खुली फ़ाइल copy source के रूप में खुल ही नहीं सकती।
• Consistency की दीवार: खुल भी जाए (read sharing हो) तो copy समय लेती है। Copy चलते app लिखता रहता है, इसलिए फ़ाइल का पहला और दूसरा आधा अलग क्षणों का हो सकता है, या कई फ़ाइलें (data और log) आपस में न मिलें। और «Cache Manager» किस्त में देखा, write पहले memory cache में बैठता है, इसलिए disk की फ़ाइल मात्र देखने से latest होने की guarantee नहीं।
• Operations की दीवार: «तो app रोककर copy कर लो» सिद्धांत में ठीक है, पर 24 घंटे चलने वाली business system या file server पर स्वीकार्य नहीं।

अर्थात माँग है «app रोके बिना, एक क्षण की consistent state की copy»। यह हर app अकेले नहीं सुलझा सकता, इसलिए OS स्तर पर VSS बना। VSS COM interface वाला ढाँचा है, जिससे app volume पर लिखते रहने पर भी volume का backup संभव होता है।²

3. VSS के roles — requester, writer, provider

VSS की संरचना तीन roles और उनके बीच coordination service में बँटी है।¹

इस विभाजन की खूबी यह है कि एक-दूसरे को न जानने वाले products भी सहयोग कर सकते हैं। Backup software (requester) SQL Server की आंतरिक संरचना नहीं जानता, पर SQL Server का writer किन फ़ाइलों (components) का backup चाहिए metadata में घोषित करता है, और consistent point के ठीक आसपास अपना data सँवारता है — इसलिए requester उस संकेत पर चलकर consistent backup ले लेता है।¹⁹ Windows पर चलने वाला लगभग हर third-party backup product VSS requester है।¹

IT operations में इन तीन roles की याद तब आती है जब समस्या हो। Backup failure requester (software पक्ष) की है, किसी writer (app पक्ष) की है, या provider / diff area (infrastructure पक्ष) की — जाँच का स्थान पूरी तरह बदल जाता है (खंड 5 और 7)।

4. Snapshot की संरचना — copy-on-write और «consistent point»

4.1. Copy-on-write — volume की नकल किए बिना «उस क्षण» को सहेजना

«Snapshot» सुनकर पूरा volume दोहराने की कल्पना होती है, पर Windows का standard system provider copy-on-write इस्तेमाल करता है। Snapshot के क्षण लगभग कुछ copy नहीं होता। बाद में original volume का block बदले जाने वाला हो तो बदलाव पूरा होने से पहले उस block की पूर्व सामग्री diff area (shadow copy storage) में भेजकर write आगे बढ़ता है।¹ प्रत्येक block की पहली बार की overwrite पर ही यह transfer चाहिए; पहले से भेजे block पर फिर लिखने से diff area नहीं बढ़ता।

«उस क्षण का volume» पढ़ने के लिए न बदले blocks original volume से, बदले blocks diff area से पढ़कर जोड़े जाते हैं। केवल बदला अंश copy होता है, इसलिए create तत्काल है और जगह केवल diff जितनी। उलटा यह कि जितना अधिक write, उतनी तेज़ diff area की खपत (खंड 7 की पूर्व-छाया), और diff area source data वाली मशीन के NTFS volume पर होता है।¹ इस तंत्र को system provider की component फ़ाइल swprv.dll और volume I/O काटने वाला driver volsnap.sys थामते हैं।¹ I/O stack में «कैसे काटते हैं» में रुचि हो तो «Filter driver और minifilter» भी देखें।

अन्य विधियाँ भी हैं: mirror काटकर full copy, और बदलाव दूसरे volume पर लिखने वाला redirect-on-write; hardware providers storage array के अनुकूल विधि चुनते हैं।¹

4.2. Consistent point बनाने का flow — freeze 60 सेकंड, create 10 सेकंड का coordination

Copy-on-write «कैसे सहेजें» है; VSS की असल ताकत «किस क्षण की state सहेजें» है — अर्थात consistent point कैसे बने। Shadow copy create इस flow से चलता है।¹

flowchart TB
    accTitle: Shadow copy create का flow
    accDescr: Shadow copy create का flow। रुकता केवल कुछ सेकंड से कुछ दसियों सेकंड है; backup स्वयं उसके बाद snapshot पर चलता है
    R["Requester create का request करता है<br/>writers की list बनाकर metadata इकट्ठा करता है"] --> M["प्रत्येक writer backup target<br/>(component) XML में घोषित करता है"]
    M --> P["प्रत्येक writer data तैयार करता है<br/>log roll, cache flush आदि<br/>recoverable consistent state तक लाता है"]
    P --> F["Writers का write I/O freeze<br/>(read संभव। अधिकतम 60 सेकंड तक)"]
    F --> FS["VSS file system buffer flush करता है<br/>और file system freeze करता है"]
    FS --> C["Provider shadow copy बनाता है<br/>(10 सेकंड के भीतर। इस दौरान write I/O freeze)"]
    C --> T["File system मुक्त → writer thaw<br/>app write फिर शुरू करते हैं"]
    T --> B["Requester shadow copy से<br/>समय लेकर backup चलाता है"]

चित्र 1: Shadow copy create का flow। रुकता केवल कुछ सेकंड से कुछ दसियों सेकंड है; backup स्वयं उसके बाद snapshot पर चलता है

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

1. App रुकता केवल consistent point बनाने के क्षण। Freeze अधिकतम 60 सेकंड, provider का create (commit) 10 सेकंड के भीतर; कोई limit टूटे तो create रद्द और requester फिर कोशिश करता है।¹ घंटों लग सकने वाला वास्तविक backup तैयार, read-only shadow copy पर, app को चलाए रखते हुए चलता है।
2. Freeze के दौरान read संभव रहता है। रुकता केवल write I/O है।¹
3. File system भी freeze होता है। VSS file system buffer flush कर फिर freeze करता है, इसलिए cache में बैठे writes और file system metadata consistent क्रम में snapshot में आते हैं।¹

4.3. Crash consistency और application consistency

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

Writer के सहयोग बिना बनी shadow copy Microsoft की शब्दावली में crash-consistent state है। Official परिभाषा है «ऐसी catastrophic failure के बाद पाई जाने वाली disk state के बराबर, जो system अचानक बंद कर दे», और उससे restore «अचानक बंद के बाद restart के बराबर» कही गई है।³ File system के रूप में corrupt नहीं, पर app की दृष्टि से «लिखते समय बिजली खींच ली गई क्षण» है। Transaction-log recovery वाला database अक्सर इससे उबर सकता है, पर पहले recovery चलनी ही है — यह bonus नहीं, पूर्व शर्त है।

Writer का सहयोग हो तो consistent point से ठीक पहले प्रत्येक writer transaction log roll करता है, cache flush करता है, और data को उस consistent state में लाता है जिसे app स्वयं सही recovery योग्य guarantee करता है।¹ यही application consistency है, और writer तंत्र का अस्तित्व इसीलिए है। ध्यान रहे: writer जो guarantee देता है वह «app के लिए consistent, recoverable state» है — वह चल रहे transactions चुपचाप commit कर पूरा नहीं करता। Uncommitted काम restore पर rollback होता है, साधारण database recovery जैसा। Writer यह गुणवत्ता app रोके बिना, कुछ दसियों सेकंड के freeze से देता है।

Backup software में «VSS इस्तेमाल करें» या «application consistency guarantee करें» जैसी setting इसी अंतर की उपज हैं। File server की साधारण फ़ाइलों पर crash consistency प्रायः समस्या नहीं; पर database या mail store वाले server पर related writer healthy होना ही backup की गुणवत्ता है।

5. Operations command का व्यवहार — vssadmin और «Previous Versions»

IT कर्मी VSS की state देखने के लिए व्यवहार में vssadmin इस्तेमाल करते हैं (elevated Command Prompt से चलाएँ)। वर्तमान command reference में list shadows / list writers / delete shadows / resize shadowstorage client और server दोनों पर उपलब्ध बताए गए हैं।⁴ Windows Server-oriented reference में इसके अतिरिक्त create shadow / list shadowstorage / list providers आदि हैं।⁵ ध्यान रहे, vssadmin केवल system provider की shadow copy manage कर सकता है।¹

list writers में writer error state में हो तो संदेह VSS पर नहीं, उस writer देने वाले app पर है। उस app की service state और Application/System event log देखें (खंड 7)।

resize shadowstorage का /maxsize limit KB/MB/GB जैसी इकाई से तय करता है; न दें तो limit ही नहीं। ध्यान की बात: Microsoft के documents स्पष्ट कहते हैं कि storage limit बदलना — खासकर घटाना — स्वयं shadow copy खो सकता है।¹⁰ कई generations रखनी हों तो उस volume की limit हल्के से न घटाएँ।

5.1. «Previous Versions» से संबंध

File server पर Shadow Copies of Shared Folders चालू करें तो share पर फ़ाइलों की किसी क्षण की copy नियमित रहती है, और user मिटाई या overwrite की गई फ़ाइल admin के बिना Previous Versions से लौटा सकते हैं।¹ Helpdesk का काम घटाने वाला, VSS का सबसे परिचित अनुप्रयोग है।

पर limit है। System provider की shadow copy प्रति volume अधिकतम 512, जिनमें Shadow Copies of Shared Folders सुविधा default में 64 तक रखती है (registry value MaxShadowCopies से बदला जा सकता है)।¹ और अगले खंडों में है, diff area कम पड़े तो पुरानी generation स्वतः मिटती है। «कितनी generations रहेंगी» set की संख्या से नहीं, write मात्रा और diff area के आकार से तय होती है — यही समझ सुरक्षित है।

6. Developer के रूप में जुड़ाव — खुद के app को VSS चाहिए?

यहाँ से developer की दृष्टि है। «In-use फ़ाइलें भी copy कर सके, ऐसी backup सुविधा जोड़ो» कहा जाए तो VSS से कैसे जुड़ें?

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

VSS API, requester और writer दोनों के लिए, COM और C++ interface के रूप में है (requester का केंद्र IVssBackupComponents)।⁶ Official .NET wrapper नहीं, और writer metadata इकट्ठा करने से snapshot set management, error के बाद cleanup तक सही लागू करना पड़ता है — business app की एक सुविधा के रूप में हल्के से नहीं जोड़ा जा सकता। हमारे Custom Software Development estimate में «VSS requester बनाना» अलग पंक्ति की मद है।

यथार्थ उत्तर दो हैं। पहला, मौजूदा VSS-capable backup product पर छोड़ दें। दूसरा, Windows Server पर DiskShadow script से चलाएँ। DiskShadow OS के साथ आने वाला VSS requester है; interactive mode के अलावा script mode (diskshadow /s script.txt) है, और एक script shadow copy बनाना, drive letter पर खोलना (expose), copy करने वाला batch चलाना (exec), और बाद की cleanup तक ढक सकती है।⁷¹ «Shadow copy बनाओ → उसमें से खुद के copy logic से फ़ाइल निकालो → मिटाओ» यह flow बिना एक पंक्ति COM लिखे बनता है। पर DiskShadow केवल Windows Server है, client editions में नहीं आता।¹ माँग में client PC भी हों तो यहीं मौजूदा backup product की ओर झुकाव बढ़ता है।

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

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

6.3. खुद के app को writer register करना चाहिए?

उलटा प्रश्न भी साफ़ करें: क्या खुद का business app VSS writer दे? लिखें तो ग्राहक कोई भी backup product इस्तेमाल करे, आपके app का data application consistency से लिया जाएगा। सामान्य writer से हल्का express writer (IVssExpressWriter) भी है, पर वह केवल किन फ़ाइलों को include/exclude रखना metadata घोषित कर register करता है।⁶ Freeze/thaw notification नहीं मिलती, इसलिए snapshot create से मेल खाते app के write रोकना संभव नहीं। Express writer तभी ठीक है जब save डिज़ाइन लिखते बीच पकड़े जाने पर भी न टूटे (अर्थात crash consistency काफी हो); consistent point पर coordination सचमुच चाहिए तो पूरा writer implementation चाहिए।

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

• Data SQL Server जैसे DB में हो तो नहीं चाहिए। DB का अपना writer consistency guarantee करता है।¹
• साधारण फ़ाइल save हो तो पहले save प्रक्रिया के डिज़ाइन से सुलझाएँ। Temporary फ़ाइल में पूरा लिखकर atomic rename से स्थान पर रखें तो crash-consistent snapshot भी «टूटी saved फ़ाइल» नहीं छोड़ता।
• Writer registration विचारने योग्य केवल उन apps के लिए है जो कई फ़ाइलों पर फैला proprietary data store रखते हैं और consistent point पर आपसी consistency चाहिए। इतने data को घर के format में रखना ही सही है, यह पहले फिर सोचना चाहिए।

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

7.1. VSS स्वयं backup नहीं है

सबसे महत्वपूर्ण pitfall। System provider की shadow copy original data वाली उसी मशीन की disk पर बैठा diff है। Diff area खो जाए तो rebuild की सामग्री नहीं, इसलिए disk failure, मशीन की चोरी-खोई, या पूरे volume का encryption — इनसे कोई रक्षा नहीं। Microsoft के documents shadow copy और backup को साफ़ अलग करते हैं: «Shadow copy से tape जैसे medium पर copy की सामग्री backup है, और copy के बाद shadow copy मिटाई जा सकती है।»¹ Shadow copy consistent point है और गलती से तेज़ वापसी — अलग medium, अलग site के backup का विकल्प नहीं।

7.2. Writer की error app पक्ष की समस्या है

Backup software «VSS error» से गिरे तो पहले vssadmin list writers से पहचानें कौन-सा writer fail है। Writer वस्तुतः app (या Windows component) का हिस्सा है¹, इसलिए कारण जाँच का मुख्य मैदान उस app की service state और event log हैं। «Backup software की error» के रूप पर बहककर केवल backup software जाँचते रहना लंबा चक्कर है। छँटाई का सामान्य ढाँचा वही है जो «जब source code और documents के बिना system मिल जाए — बिना रोके चलाने-रखरखाव की व्यावहारिक प्रक्रिया» में है: देखे जा सकने वाले तथ्यों से संदिग्ध घटाएँ।

7.3. Ransomware shadow copy मिटाने आता है

रक्षा पक्ष की चेतावनी के रूप में जानने योग्य तथ्य। Previous Versions से लौटा सकें तो ransomware के बाद भी लौटेंगे — यह आशा लुभाती है, पर बहुत सा ransomware encryption के पहले या बाद shadow copy मिटाकर इस restore पथ को बंद कर देता है, यह व्यापक रूप से ज्ञात है। Shadow copy मिटाना Administrator अधिकार हों तो पूरी तरह वैध command से हो जाता है, इसलिए घुस चुके attacker के विरुद्ध अंतिम दीवार नहीं बन सकता। अतः उपाय की धुरी: (1) Shadow copy को «recovery plan का भाग» नहीं, «हो तो तेज़» मानें; (2) attacker की पहुँच से बाहर offline, अलग site का backup अलग रखें; (3) दैनिक operations accounts को admin rights न दें। Backup, encryption और disposal तक PC lifecycle की रक्षा के लिए «BitLocker practical guide — recovery key management से शुरू drive encryption» और «Windows PC का disposal करने से पहले — data मिटाना, account unlink, backup की practical checklist» भी देखें।

7.4. Diff area खत्म हो तो पुरानी generations चुपचाप गायब हो जाती हैं

खंड 4 में देखा, copy-on-write diff area तब खाता है जब snapshot के बाद प्रत्येक block पहली बार बदले। पहले भेजे block पर कितनी भी overwrite खपत नहीं बढ़ाती, इसलिए खपत «कितनी बार लिखा» से नहीं, «रखी snapshot के बाद कितने व्यापक blocks बदले» से तय होती है। और diff area limit पर पहुँचे तो उस volume की shadow copy पुरानी से मिटती हैं।¹ Interactive user को कुछ नहीं बताया जाता, इसलिए «पिछले सप्ताह का version लौटा सकेंगे» जब लौट नहीं पाता तब पता चलता है। पूरी तरह मौन नहीं: System log में volsnap source के events दर्ज होते हैं (diff area के लिए जगह न बनने पर मिटाने का 25, expand fail या limit पर रुकने का 35/36 आदि)। नियमित जाँच के अलावा इन volsnap events को monitoring और alert में रखें तो क्षति जल्दी पकड़ में आए। भारी फ़ाइल update, सामूहिक conversion, defrag जैसे «पूरे volume पर फेर» काम diff area एक झटके में इसलिए खा जाते हैं कि खपत बदले blocks की चौड़ाई से तय होती है। रखी generations व्यवसाय की माँग («गलत delete कितने दिन बाद तक पकड़ में आए») पूरी कर रही हैं या नहीं, vssadmin list shadowstorage के usage से नियमित देखें, और ज़रूरत हो तो limit बढ़ाएँ।⁵¹⁰

8. सारांश

• In-use फ़ाइल सामान्यतः copy न हो पाना sharing violation और consistency की बात है, और वह data की रक्षा का सही तंत्र है। «रोके बिना consistent copy चाहिए» का OS-level उत्तर VSS है।
• VSS वह ढाँचा है जिसमें VSS service तीन roles — requester (माँग), writer (consistency guarantee), provider (create) — के बीच मध्यस्थता करती है, जिससे एक-दूसरे को न जानने वाला backup software और business app सहयोग कर सकते हैं।
• System provider copy-on-write इस्तेमाल करता है, और consistent point «writer freeze (अधिकतम 60 सेकंड) → create (10 सेकंड के भीतर) → thaw» से बनता है। Writer सहयोग न हो तो crash consistency, हो तो application consistency।
• Operations जाँच vssadmin से (list shadows / list writers / list shadowstorage)। Writer error पर app पक्ष संदेह करें, diff area का usage नियमित देखें।
• Developer पहले निर्णय तालिका से देखें कि retry, share mode, रोक का समय, या integration डिज़ाइन काफी है या नहीं, और सचमुच ज़रूरत हो तभी VSS की ओर जाएँ। खुद के implementation से पहले DiskShadow script (केवल Server) या मौजूदा product यथार्थ उत्तर है।
• Shadow copy backup नहीं है। वह original volume के अक्षत blocks पर depend करती diff मात्र है; disk failure जैसी original volume की हानि पर बेबस है, और ransomware पर भी shadow copy मिटने या diff area खत्म होने से भरोसा नहीं। Offline, अलग site के backup के साथ जोड़ें।

संबंधित लेख

• File integration के exclusion control की मूल बातें — file lock और atomic claim की best practices
• Windows I/O की गहराई (भाग 4) — Cache Manager: आपका WriteFile disk तक कब पहुँचता है?
• Windows I/O की गहराई (भाग 5) — NTFS की आंतरिक संरचना: MFT से file system समझना
• जब source code और documents के बिना system मिल जाए — बिना रोके चलाने-रखरखाव की व्यावहारिक प्रक्रिया
• BitLocker practical guide — recovery key management से शुरू drive encryption
• Windows PC का disposal करने से पहले — data मिटाना, account unlink, backup की practical checklist

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

KomuraSoft LLC «in-use फ़ाइल की copy और backup सुविधा» सहित business app का डिज़ाइन-विकास, file integration के आसपास sharing violation और backup failure (VSS writer error) की root-cause investigation, तथा file server के backup और generation management की operations संरचना सँभालता है। «क्या VSS वास्तव में ज़रूरी requirement है» इस प्रश्न से शुरू करना पर्याप्त है।

• Windows app development
• Bug और कारणों की जाँच
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

Shadow copy हों तो क्या backup की ज़रूरत नहीं?

ज़रूरत खत्म नहीं होती। Windows के standard system provider की shadow copy copy-on-write diffs हैं — वे उस क्षण की पूरी अलग copy नहीं, बल्कि original volume के अभी न बदले blocks पर depend करती हैं। Diff area दूसरे volume पर रखें तब भी original volume खोने पर restore असंभव रहती है, और disk failure या PC की चोरी-खोई जैसी घटनाओं में, जहाँ original volume ही चला जाता है, यह बेबस है। Ransomware पर भी: encryption का write बदले से पहले के blocks diff area में भेजता है, पर वास्तविक attacks shadow copy मिटा देते हैं या भारी overwrite से diff area खत्म कर देते हैं, इसलिए भरोसा नहीं किया जा सकता। Microsoft के documents दोनों को अलग रखते हैं: shadow copy से tape जैसे medium पर copy किया data backup है, और copy के बाद shadow copy मिटाई जा सकती है। Shadow copy «backup लेने का consistent point» और «हल्की गलती से तेज़ वापसी» है — अलग medium, अलग site के backup का विकल्प नहीं।

खुद के business app में in-use फ़ाइल copy करनी है — क्या VSS इस्तेमाल करें?

पहले बिना VSS के रास्ता खोजना यथार्थ है। VSS requester COM-based native API (IVssBackupComponents आदि) से लिखना पड़ता है, .NET के लिए official wrapper नहीं है, इसलिए खुद के app में जोड़ना बड़ा काम है। माँग «दूसरा process लिख रहा हो तो फ़ाइल कभी पढ़ लेना काफी» हो तो retry काफी है; «read sharing अनुमति है» तो share mode मिलाकर खोलना काफी है। App थोड़ी देर रोका जा सके तो business के idle time पर copy सबसे सरल और विश्वसनीय है। «न रुक सकने वाले app के पूरे data को consistent state में दोहराना» ही VSS का स्थान है, और तब भी खुद का implementation पहले नहीं — VSS-capable backup product या DiskShadow script पहले देखें।

vssadmin list writers में writer error state में है। क्या करें?

मूल बात यह है कि उसे उस writer के app पक्ष की समस्या मानकर जाँचें। vssadmin list writers registered writers को state सहित दिखाता है, इसलिए पहले पहचानें कौन-सा writer fail है। Writer SQL Server जैसे app या Windows components (registry आदि) देते हैं, इसलिए कारण प्रायः VSS में नहीं, बल्कि उस app की service state या Application/System event log की errors में होता है। Related service restart करें, reproduce की शर्तें छाँटें; न सुलझे तो उस app की support जानकारी देखें। Backup software VSS error से गिरे तो पहली छँटाई भी यही है।

Shadow copy बिना बताए गायब हो गई। क्यों?

सबसे आम कारण diff area (shadow copy storage) की कमी है। Copy-on-write में snapshot के बाद प्रत्येक block पहली बार बदलते समय बदले से पहले की सामग्री diff area में जाती है, इसलिए जितना व्यापक बदलाव उतना अधिक consumption। Allocated limit पहुँचते ही Windows सबसे पुरानी shadow copy से मिटाकर जगह बनाता है। Interactive user को notification नहीं मिलती, चुपचाप मिटती है, इसलिए «Previous Versions से पिछले सप्ताह का version लौटा सकेंगे समझा, पर था ही नहीं» के रूप में पकड़ में आती है (System log में volsnap source का event 25 आदि दर्ज होता है, monitoring में रखें तो पता चलता है)। vssadmin list shadowstorage से usage और limit देखें, ज़रूरत हो तो vssadmin resize shadowstorage से limit बढ़ाएँ। ध्यान रहे, limit बदलना — खासकर घटाना — स्वयं shadow copy खो सकता है।

File Explorer के «Previous Versions» और VSS का क्या संबंध है?

«Previous Versions» VSS की shadow copy से फ़ाइल का पुराना रूप निकालने का एक द्वार है। File server पर «Shadow Copies of Shared Folders» चालू करें तो नियमित shadow copy बनती हैं, और user shared folder की फ़ाइल पर दायाँ क्लिक कर Previous Versions से स्वयं restore कर सकते हैं। Admin के बिना delete-overwrite की गलती सुधारना लाभ है। पर वस्तु shadow copy ही है, इसलिए रखी जा सकने वाली generations की limit है, और diff area कम पड़े तो पुरानी generation पहले गायब होती है। «Previous Versions हैं इसलिए backup नहीं चाहिए» लागू नहीं होता — यह लेख के मुख्य भाग में है।

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

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

Go Komura

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

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