ভলিউম শ্যাডো কপি (VSS)-এর কৌশল ও প্রয়োগ — ব্যবহারে থাকা ফাইলের ব্যাকআপ কেন নেওয়া যায়

«অন্য অ্যাপ খোলা ফাইল কপি করতে গিয়ে “প্রক্রিয়া ফাইলে প্রবেশ করতে পারছে না” বলে ধমক খেলাম।» «মূল সিস্টেম না থামিয়ে ডেটা ফোল্ডারের ব্যাকআপ নিতে বলা হয়েছে।» «ব্যাকআপ সফটওয়্যার ব্যবহারে থাকা ডেটাবেস ফাইল কেন নির্বিকার কপি করতে পারে?» — ব্যবসায়িক অ্যাপ ডেভেলপ করুন বা ফাইল সার্ভার চালান, এই প্রশ্নগুলো একসময় আসেই।

উত্তরের কেন্দ্রে ভলিউম শ্যাডো কপি সার্ভিস (VSS: Volume Shadow Copy Service)। Windows-এ বিশ বছরেরও বেশি ধরে বসানো, আর Windows Server Backup, সিস্টেম রিস্টোর, এবং বাজারের প্রায় সব ব্যাকআপ সফটওয়্যার এই ভিত্তির উপর দাঁড়ায়।¹

এই নিবন্ধ লক্ষ্য করে সেই ব্যবসায়িক-অ্যাপ ডেভেলপারদের যাদের «ব্যবহারে থাকা ফাইল কপির ফিচার» চাওয়া হয়, আর ফাইল সার্ভার ও ব্যবসায়িক PC-র ব্যাকআপ চালান এমন তথ্য-ব্যবস্থা কর্মীদের। VSS-এর চরিত্র ও কৌশল, vssadmin দিয়ে দৈনন্দিন প্রয়োগ, এবং «ডেভেলপার VSS-এ কতদূর জড়াবেন» তার সিদ্ধান্ত আগস্ট 2026 পর্যন্ত প্রাথমিক সূত্রে সাজায়। «Windows I/O-এর গভীরতা» সিরিজে Cache Manager ও NTFS-এর ভিতর দেখা হয়েছিল; এই নিবন্ধ তার পরের কিস্তি, ভলিউমের ঠিক উপরে বসা «স্ন্যাপশট» স্তর নিয়ে।

1. আগে সিদ্ধান্ত

• VSS হলো COM ইন্টারফেসের সেট ও সমন্বয়কারী সার্ভিস, যা অ্যাপ ভলিউমে লিখে যেতে থাকলেও সেই ভলিউমের ব্যাকআপ সম্ভব করে। Windows XP থেকে বসানো।²
• চরিত্র তিনটি, প্লাস সমন্বয়কারী। শ্যাডো কপি চায় রিকোয়েস্টার (ব্যাকআপ সফটওয়্যার), অ্যাপের দিকে ডেটার সামঞ্জস্য নিশ্চিত করে রাইটার (SQL Server ইত্যাদি), আর স্ন্যাপশট সত্যি তৈরি করে প্রোভাইডার — VSS সার্ভিস এদের মাঝে দাঁড়ায়।¹
• Windows-এর স্ট্যান্ডার্ড সিস্টেম প্রোভাইডার কপি-অন-রাইট ব্যবহার করে। পুরো ভলিউম নকল করে না; স্ন্যাপশটের পর যে ব্লক ওভাররাইট হয়, শুধু তার লেখার-আগের বিষয়বস্তু ডিফ এরিয়ায় সরায়। ডিফ এরিয়া NTFS ভলিউমে থাকতে হয়।¹
• স্থিরবিন্দু তৈরি হয় «রাইটার ফ্রিজ (সর্বোচ্চ 60 সেকেন্ড) → স্ন্যাপশট তৈরি (10 সেকেন্ডের মধ্যে) → থ (thaw)» দিয়ে। সময়সীমা ছাড়ালে তৈরি বাতিল হয়, রিকোয়েস্টার আবার চেষ্টা করে।¹
• রাইটার সহযোগিতা করলে কপির গুণ বদলায়। সহযোগিতা ছাড়া স্ন্যাপশট «বিদ্যুৎ কাটার মুহূর্তের ডিস্ক»-এর সমতুল্য (ক্র্যাশ সামঞ্জস্য); সহযোগিতা থাকলে লগ রোল ও ক্যাশ ফ্লাশ হয়ে যায়, অ্যাপ নিজেই পুনরুদ্ধারযোগ্য বলে নিশ্চিত করা সামঞ্জস্যপূর্ণ অবস্থা (অ্যাপ্লিকেশন সামঞ্জস্য)।³¹
• অপারেশনের পরখ vssadmin দিয়ে। list shadows / list writers / list shadowstorage দিয়ে বর্তমান অবস্থা দেখুন, resize shadowstorage দিয়ে ডিফ এরিয়ার সীমা বদলান। ডিফ এরিয়া ফুরিয়ে গেলে পুরনো শ্যাডো কপি থেকে চুপচাপ মুছে যায়।⁴⁵¹
• নিজের অ্যাপে VSS রিকোয়েস্টার বসানো বড় কাজ। COM-ভিত্তিক নেটিভ API, .NET-এর অফিসিয়াল র‍্যাপার নেই। বেশিরভাগ ক্ষেত্রে পুনঃচেষ্টা, শেয়ার মোড মেলানো, বা অল্পক্ষণ থামানোই যথেষ্ট; সত্যি VSS লাগলে DiskShadow স্ক্রিপ্টই বাস্তব সমাধান (কেবল Windows Server)।⁶⁷
• শ্যাডো কপি ব্যাকআপ নিজে নয়। কপি-অন-রাইট ডিফারেনশিয়াল মূল ভলিউমের অক্ষত ব্লকের উপর নির্ভর করে, তাই ডিস্ক নষ্ট বা চুরির মতো ঘটনায় মূল ভলিউমই চলে গেলে কিছুই রক্ষা করে না। র‍্যানসমওয়্যারের বিরুদ্ধেও শ্যাডো কপি মুছে ফেলা (ধারা 7.3) বা ব্যাপক ওভাররাইটে ডিফ এরিয়া ফুরিয়ে যাওয়া (ধারা 7.4) দিয়ে ভরসা করা যায় না। আলাদা মাধ্যমের ব্যাকআপের সঙ্গে জোড়া লাগলে তবেই অর্থ হয়।¹

2. সমস্যার সেটআপ — ব্যবহারে থাকা ফাইল সাধারণভাবে কপি হয় না কেন

শুরু Windows-এর ফাইল শেয়ার মোড। Windows-এ ফাইল খোলার সময় (CreateFile) আপনি «আমি খোলা রাখাকালীন অন্য প্রক্রিয়াকে কী করতে দেব» শেয়ার মোড (dwShareMode) হিসেবে ঘোষণা করেন। পড়া শেয়ার না-দেওয়া খোলা ধরে রাখা প্রক্রিয়া থাকতে পরে পড়ার জন্য খুলতে চাইলে শেয়ারিং ভায়োলেশন (ERROR_SHARING_VIOLATION, ত্রুটি 32)-এ ব্যর্থ হয়।⁸ .NET-এ পরিচিত IOException («অন্য প্রক্রিয়া ব্যবহার করছে বলে প্রক্রিয়া ফাইলে প্রবেশ করতে পারছে না») রূপে দেখা দেয়।

গুরুত্বপূর্ণ কথা, এটা বাগ নয়, ডেটা রক্ষার সঠিক ব্যবস্থা। লেখার মাঝপথে পড়লে পড়ার পক্ষ «অসমাপ্ত, আধলেখা অবস্থা» হাতে পায়। একচেটিয়া নিয়ন্ত্রণের নকশা «ফাইল-ভিত্তিক ইন্টিগ্রেশনের একচেটিয়া নিয়ন্ত্রণের মূলকথা»-তে বিস্তারে আছে; এটা অ্যাপ-অ্যাপ সহযোগিতার ভিত্তি।

তবে এই সঠিক ব্যবস্থা ব্যাকআপের সঙ্গে মূলেই সংঘর্ষ করে।

• শেয়ারিং ভায়োলেশনের দেয়াল: ডেটাবেস বা ব্যবসায়িক অ্যাপ খোলা রাখা ফাইল কপি-উৎস হিসেবে খোলাই যায় না কখনো।
• সামঞ্জস্যের দেয়াল: খুলতে পারলেও (পড়া শেয়ার থাকলেও) কপিতে সময় লাগে। কপির মাঝেও অ্যাপ লিখে যায়, তাই ফাইলের আগের অংশ আর পরের অংশ আলাদা মুহূর্তের বিষয়বস্তু হয়ে যেতে পারে, বা একাধিক ফাইলের (ডেটা ও লগ ইত্যাদি) মধ্যে মিল থাকে না। আর «Cache Manager» কিস্তিতে দেখা গেছে, লেখা আগে মেমোরির ক্যাশে ওঠে, তাই ডিস্কের ফাইল দেখেই সর্বশেষ বলা যায় না।
• অপারেশনের দেয়াল: «তাহলে অ্যাপ থামিয়ে কপি করুন» নীতিতে ঠিক, কিন্তু 24 ঘণ্টা চলা ব্যবসায়িক সিস্টেম বা ফাইল সার্ভারে গ্রহণযোগ্য নয়।

অর্থাৎ চাহিদা «অ্যাপ না থামিয়ে, এক মুহূর্তের সামঞ্জস্যপূর্ণ অবস্থার কপি চাই»। একা একা অ্যাপের পক্ষে ভারী, তাই OS স্তরের ব্যবস্থা হিসেবে 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 এবং ভলিউমের I/O-তে ঢোকে এমন ড্রাইভার volsnap.sys।¹ I/O স্ট্যাকে «কীভাবে ঢোকে» জানতে চাইলে «ফিল্টার ড্রাইভার ও মিনিফিল্টার»-ও দেখুন।

অন্য পদ্ধতিও আছে: মিরর আলাদা করে পূর্ণ কপি, আর বদল অন্য ভলিউমে লেখা রিডাইরেক্ট-অন-রাইট; হার্ডওয়্যার প্রোভাইডার স্টোরেজ যন্ত্রের উপযোগী পদ্ধতি ব্যবহার করে।¹

4.2. স্থিরবিন্দু তৈরির প্রবাহ — ফ্রিজ 60 সেকেন্ড, তৈরি 10 সেকেন্ডের সহযোগিতা

কপি-অন-রাইট যদি «কীভাবে রাখা যায়» হয়, VSS-এর আসল ক্ষমতা «কোন মুহূর্তের অবস্থা রাখা যায়» — অর্থাৎ স্থিরবিন্দু তৈরি। শ্যাডো কপি তৈরি এই প্রবাহে চলে।¹

flowchart TB
    accTitle: শ্যাডো কপি তৈরির প্রবাহ
    accDescr: শ্যাডো কপি তৈরির প্রবাহ। থেমে থাকে কেবল কয়েক সেকেন্ড থেকে কয়েক দশক সেকেন্ড; ব্যাকআপ নিজে স্ন্যাপশটের উপর চলে
    R["রিকোয়েস্টার তৈরির অনুরোধ করে<br/>রাইটার তালিকা করে মেটাডেটা সংগ্রহ করে"] --> M["প্রতিটি রাইটার ব্যাকআপের লক্ষ্য<br/>(কম্পোনেন্ট) XML-এ ঘোষণা করে"]
    M --> P["প্রতিটি রাইটার ডেটা প্রস্তুত করে<br/>লগ রোল, ক্যাশ ফ্লাশ ইত্যাদি<br/>পুনরুদ্ধারযোগ্য সামঞ্জস্যপূর্ণ অবস্থায় আনে"]
    P --> F["রাইটারের লেখার I/O ফ্রিজ করে<br/>(পড়া যায়। সর্বোচ্চ 60 সেকেন্ড)"]
    F --> FS["VSS ফাইল সিস্টেম বাফার ফ্লাশ করে<br/>ফাইল সিস্টেম হিমায়িত করে"]
    FS --> C["প্রোভাইডার শ্যাডো কপি তৈরি করে<br/>(10 সেকেন্ডের মধ্যে। এ সময় লেখার I/O হিমায়িত)"]
    C --> T["ফাইল সিস্টেম মুক্ত → রাইটার থ (thaw)<br/>অ্যাপ লেখা আবার শুরু করে"]
    T --> B["রিকোয়েস্টার শ্যাডো কপি থেকে<br/>সময় নিয়ে ব্যাকআপ চালায়"]

চিত্র 1: শ্যাডো কপি তৈরির প্রবাহ। থেমে থাকে কেবল কয়েক সেকেন্ড থেকে কয়েক দশক সেকেন্ড; ব্যাকআপ নিজে স্ন্যাপশটের উপর চলে

তিনটি কথা মনে রাখুন।

1. অ্যাপ থামে কেবল স্থিরবিন্দু তৈরির সেই মুহূর্ত। ফ্রিজ 60 সেকেন্ডের মধ্যে, প্রোভাইডারের তৈরি (কমিট) 10 সেকেন্ডের মধ্যে বাঁধা; ছাড়ালে তৈরি বাতিল হয়ে রিকোয়েস্টার আবার চেষ্টা করে।¹ ঘণ্টার পর ঘণ্টা লাগা ব্যাকআপ নিজে তৈরি হয়ে যাওয়া, পড়ার-যোগ্য শ্যাডো কপির উপর চলে, অ্যাপ চালু রেখেই।
2. ফ্রিজের সময়ও পড়া যায়। থামে কেবল লেখার I/O।¹
3. ফাইল সিস্টেমও হিমায়িত হয়। VSS ফাইল সিস্টেম বাফার ফ্লাশ করে তারপর হিমায়িত করে, তাই ক্যাশে থাকা লেখা ও ফাইল সিস্টেমের মেটাডেটা সামঞ্জস্যপূর্ণ ক্রমে স্ন্যাপশটে পড়ে।¹

4.3. ক্র্যাশ সামঞ্জস্য ও অ্যাপ্লিকেশন সামঞ্জস্য

এখানে ব্যাকআপের গুণ ভাগ করে এমন গুরুত্বপূর্ণ পার্থক্য আসে।

রাইটারের সহযোগিতা ছাড়া তৈরি শ্যাডো কপি Microsoft-এর পরিভাষায় ক্র্যাশ সামঞ্জস্যপূর্ণ (crash consistent) অবস্থা। অফিসিয়াল সংজ্ঞা «সিস্টেমকে হঠাৎ বন্ধ করে দেওয়া ধ্বংসাত্মক বিপর্যয়ের পরে যে অবস্থা পাওয়া যায় তার সমতুল্য ডিস্ক অবস্থা», আর সেখান থেকে পুনরুদ্ধার «হঠাৎ বন্ধের পর রিস্টার্টের সমতুল্য»।³ ফাইল সিস্টেম হিসেবে ভাঙা নয়, কিন্তু অ্যাপের চোখে «লেখার মাঝে বিদ্যুৎ তুলে নেওয়ার মুহূর্ত»। ট্রানজ্যাকশন লগ থেকে পুনরুদ্ধারের ব্যবস্থা থাকা ডেটাবেস প্রায়ই ফিরতে পারে, তবে পুনরুদ্ধার প্রক্রিয়া আগে চালাতে হয় — সেটা শর্ত, বাড়তি সুবিধা নয়।

রাইটারের সহযোগিতা থাকলে স্থিরবিন্দুর ঠিক আগে প্রতিটি রাইটার ট্রানজ্যাকশন লগ রোল করে, ক্যাশ ফ্লাশ করে, অ্যাপ নিজেই «এখান থেকে ঠিকমতো ফিরতে পারি» বলে নিশ্চিত করা সামঞ্জস্যপূর্ণ অবস্থায় আনে।¹ এটাই অ্যাপ্লিকেশন সামঞ্জস্য, আর রাইটার ব্যবস্থার অস্তিত্বের কারণ। খেয়াল রাখুন, রাইটার যা নিশ্চিত করে তা «অ্যাপ হিসেবে সামঞ্জস্যপূর্ণ, পুনরুদ্ধারযোগ্য অবস্থা» — চলতি ট্রানজ্যাকশন নিজে থেকে কমিট করে শেষ করে দেয় না। আনকমিটেড কাজ পুনরুদ্ধারের সময় রোলব্যাক হয় (ডেটাবেসের সাধারণ পুনরুদ্ধারের মতো)। রাইটার এই গুণের নিশ্চয়তা অ্যাপ না থামিয়ে, কয়েক দশক সেকেন্ডের ফ্রিজ দিয়েই দেয়।

ব্যাকআপ সফটওয়্যারের সেটিংয়ে «VSS ব্যবহার করুন» বা «অ্যাপ্লিকেশনের সামঞ্জস্য নিশ্চিত করুন» থাকার কারণ এই পার্থক্য। ফাইল সার্ভারের সাধারণ ফাইলসমূহে ক্র্যাশ সামঞ্জস্য প্রায় সমস্যা হয় না; কিন্তু ডেটাবেস বা মেইল স্টোর ধরা সার্ভারে সংশ্লিষ্ট রাইটার সুস্থ কি না — সেটাই ব্যাকআপের গুণ।

5. অপারেশন কমান্ডের প্রয়োগ — 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)।

resize shadowstorage-এর /maxsize-এ KB/MB/GB ইত্যাদি একক দিয়ে সীমা দেওয়া যায়; না দিলে সীমা থাকে না। খেয়াল করার কথা, স্টোরেজ সীমা বদলানো (বিশেষ করে কমানো) নিজেই শ্যাডো কপি হারাতে পারে বলে স্পষ্ট লেখা আছে।¹⁰ প্রজন্ম রাখতে চাওয়া ভলিউমের সীমা হালকা হাতে কমাবেন না।

5.1. «পূর্ববর্তী সংস্করণ»-এর সঙ্গে সম্পর্ক

ফাইল সার্ভারে শেয়ার্ড ফোল্ডারের শ্যাডো কপি (Shadow Copies of Shared Folders) চালু করলে শেয়ারে থাকা ফাইলের এক-এক মুহূর্তের কপি নিয়মিত রাখা হয়, আর ব্যবহারকারী মুছে ফেলা বা ওভাররাইট করা ফাইল প্রশাসকের সাহায্য ছাড়াই «পূর্ববর্তী সংস্করণ» থেকে ফেরাতে পারেন।¹ হেল্পডেস্কের কাজ কমায়, VSS-এর সবচেয়ে চেনা প্রয়োগ।

তবে সীমা আছে। সিস্টেম প্রোভাইডারের শ্যাডো কপি ভলিউমপ্রতি সর্বোচ্চ 512, তার মধ্যে শেয়ার্ড ফোল্ডারের শ্যাডো কপি ফিচার ডিফল্টে 64 পর্যন্ত রাখে (রেজিস্ট্রির MaxShadowCopies দিয়ে বদলানো যায়)।¹ আর পরের ধারাগুলোতে যেমন বলা, ডিফ এরিয়া কমলে পুরনো প্রজন্ম থেকে আপনাআপনি মুছে যায়। «কত প্রজন্ম থাকে» সেট করা সংখ্যা নয়, লেখার পরিমাণ ও ডিফ এরিয়ার আকারে ঠিক হয় — এভাবে বোঝাই নিরাপদ।

6. ডেভেলপার হিসেবে জড়ানো — নিজের অ্যাপে VSS দরকার কি

এখান থেকে ডেভেলপারের দৃষ্টি। «ব্যবহারে থাকা ফাইলও কপি করা যায় এমন ব্যাকআপ ফিচার দিন» বলা হলে VSS-এর সঙ্গে কীভাবে থাকবেন।

6.1. রিকোয়েস্টার নিজে লেখা বড় কাজ

VSS API, রিকোয়েস্টার ও রাইটার দুইয়ের জন্যই, COM ও C++ ইন্টারফেস হিসেবে দেওয়া (রিকোয়েস্টারের কেন্দ্র IVssBackupComponents)।⁶ .NET-এর অফিসিয়াল র‍্যাপার নেই, আর রাইটার মেটাডেটা সংগ্রহ থেকে স্ন্যাপশট সেট ব্যবস্থাপনা, ত্রুটির পর পরিষ্কার — সব ঠিকমতো ইমপ্লিমেন্ট করতে হয়, তাই ব্যবসায়িক অ্যাপের এক ফিচার হিসেবে হালকা হাতে বসানো যায় না। আমাদের চুক্তিভিত্তিক ডেভেলপমেন্টের খরচ-হিসাবেও «VSS রিকোয়েস্টার নিজে তৈরি» আলাদা উন্নয়ন আইটেম।

বাস্তব সমাধান দুটো। প্রথম, বিদ্যমান VSS-সচেতন ব্যাকআপ সফটওয়্যারের হাতে ছেড়ে দেওয়া। দ্বিতীয়, Windows Server হলে DiskShadow স্ক্রিপ্ট থেকে ব্যবহার। DiskShadow OS-এর সঙ্গে আসা VSS রিকোয়েস্টার; ইন্টারঅ্যাকটিভ মোড ছাড়া স্ক্রিপ্ট মোডও আছে (diskshadow /s script.txt), আর শ্যাডো কপি তৈরি, ড্রাইভ অক্ষরে প্রকাশ (expose), কপি করা ব্যাচ চালানো (exec), পরে পরিষ্কার — এক স্ক্রিপ্টে লেখা যায়।⁷¹ «শ্যাডো কপি তৈরি → সেখান থেকে নিজের কপি লজিক দিয়ে ফাইল টেনে আনা → মুছে ফেলা» এই প্রবাহ COM-এর এক লাইন না লিখেই গড়া যায়। তবে DiskShadow কেবল Windows Server-এর, ক্লায়েন্ট OS-এ নেই।¹ ক্লায়েন্ট PC-ও চাহিদার মধ্যে থাকলে এই তথ্যই বিদ্যমান ব্যাকআপ সফটওয়্যারের দিকে ঠেলে।

6.2. আদৌ VSS দরকার কি — সিদ্ধান্ত সারণি

অভিজ্ঞতায় «ব্যবহারে থাকা ফাইল কপি»-র বেশিরভাগ আলোচনা VSS ছাড়াই মেটে। চাহিদার স্তর দেখে তারপর হাতিয়ার বাছুন।

6.3. নিজের অ্যাপ কি রাইটার নিবন্ধন করবে

উল্টো প্রশ্নও সাজানো যাক: নিজের ব্যবসায়িক অ্যাপ কি VSS রাইটার দেবে? রাইটার লিখলে গ্রাহক যে ব্যাকআপ সফটওয়্যারই ব্যবহার করুক, নিজের অ্যাপের ডেটা অ্যাপ্লিকেশন সামঞ্জস্যে নেওয়া যায়। সাধারণ রাইটারের চেয়ে হালকা এক্সপ্রেস রাইটার (IVssExpressWriter)ও আছে, কিন্তু এটা কেবল «কোন ফাইল লক্ষ্য/বাদ» সেই মেটাডেটা ঘোষণা নিবন্ধন করে।⁶ ফ্রিজ/থ বিজ্ঞপ্তি পায় না, তাই স্ন্যাপশট তৈরির সঙ্গে মিলিয়ে অ্যাপের লেখা থামানো যায় না। এক্সপ্রেস রাইটার তখনই, যখন লেখার মাঝে ধরা পড়লেও ভাঙে না এমন সংরক্ষণ নকশার সঙ্গে জোড়া (ক্র্যাশ সামঞ্জস্যই যথেষ্ট); স্থিরবিন্দুতে সহযোগিতা লাগলে সাধারণ রাইটার ইমপ্লিমেন্টেশন লাগে।

তবু সিদ্ধান্তের মাপকাঠি সরল।

• ডেটা SQL Server ইত্যাদি DB-তে থাকলে দরকার নেই। DB-এর রাইটার সামঞ্জস্য নিশ্চিত করে।¹
• সরল ফাইল সংরক্ষণ হলে আগে সংরক্ষণ রুটিনের নকশায় মেলান। অস্থায়ী ফাইলে লিখে শেষ করে রিনেম দিয়ে বদলালে অ্যাটমিক সংরক্ষণ হয়, ক্র্যাশ-সামঞ্জস্যপূর্ণ স্ন্যাপশটেও «ভাঙা সেভ ফাইল» থাকে না।
• রাইটার নিবন্ধনের কথা ভাবার মতো কেবল সেই অ্যাপ যেগুলো একাধিক ফাইল জুড়ে নিজস্ব ডেটা স্টোর রাখে, আর স্থিরবিন্দুতে তাদের পারস্পরিক সামঞ্জস্য লাগে। সেই পরিমাণ ডেটা ঘরোয়া ফরম্যাটে ধরে রাখাটাই আগে পুনর্বিবেচনা করা যায়।

7. ফাঁদ — অপারেশনে সত্যি কাজে লাগে এমন চারটি

7.1. VSS ব্যাকআপ নিজে নয়

সবচেয়ে গুরুত্বপূর্ণ ফাঁদ। সিস্টেম প্রোভাইডারের শ্যাডো কপি মূল ডেটার একই মেশিনের ডিস্কে থাকা ডিফারেনশিয়াল। ডিফ এরিয়া হারালে জোড়া যায় না, তাই ডিস্ক নষ্ট, মেশিন চুরি/হারিয়ে যাওয়া, বা পুরো ভলিউম এনক্রিপশনের বিরুদ্ধে কোনো সুরক্ষা দেয় না। Microsoft-এর ডকুমেন্টও শ্যাডো কপি ও ব্যাকআপ আলাদা করে: «শ্যাডো কপি থেকে টেপ ইত্যাদি মাধ্যমে কপি করা বিষয়বস্তুই ব্যাকআপ, আর কপি হয়ে গেলে শ্যাডো কপি মুছে ফেলা যায়»।¹ শ্যাডো কপি স্থিরবিন্দু, আর ভুল থেকে দ্রুত ফেরার উপায় — আলাদা মাধ্যম ও আলাদা স্থানের ব্যাকআপের বিকল্প নয়।

7.2. রাইটারের ত্রুটি অ্যাপের দিকের সমস্যা

ব্যাকআপ সফটওয়্যার «VSS ত্রুটি»তে ব্যর্থ হলে আগে vssadmin list writers দিয়ে কোন রাইটার ব্যর্থ চিহ্নিত করুন। রাইটার মূলত অ্যাপের (বা Windows উপাদানের) অংশ,¹ তাই কারণ খোঁজার মূল ময়দান সেই অ্যাপের সার্ভিস অবস্থা ও ইভেন্ট লগ। «ব্যাকআপ সফটওয়্যারের ত্রুটি» দেখে কেবল ব্যাকআপ সফটওয়্যার খুঁজতে থাকলে পথ ঘুরে যায়। কাটাকুটির সাধারণ ধরন «সোর্সও নথিও নেই এমন সিস্টেম হাতে পেলে»-এও আছে: দেখা যায় এমন তথ্য থেকে সন্দেহভাজনদের তালিকা ছোট করা।

7.3. র‍্যানসমওয়্যার শ্যাডো কপি মুছতে আসে

প্রতিরক্ষার খাতিরে জেনে রাখার কথা। «পূর্ববর্তী সংস্করণ» দিয়ে ফেরা গেলে র‍্যানসমওয়্যারে এনক্রিপ্ট হলেও ফেরা যাবে — এ আশা জাগে, কিন্তু অনেক র‍্যানসমওয়্যার এনক্রিপশনের আগে বা পরে শ্যাডো কপি মুছে এই পুনরুদ্ধার পথ বন্ধ করে দেয় বলে ব্যাপকভাবে জানা। শ্যাডো কপি মুছে ফেলা প্রশাসক অধিকার থাকলে বৈধ কমান্ডেই হয়, তাই ঢুকে পড়া আক্রমণকারীর শেষ প্রতিরোধ হয় না। তাই প্রতিরক্ষার খুঁটি: (1) শ্যাডো কপিকে «পুনরুদ্ধার পরিকল্পনার অংশ» নয়, «থাকলে তাড়াতাড়ি» মাত্রা দিন; (2) আক্রমণকারী পৌঁছাতে পারে না এমন অফলাইন, আলাদা স্থানের ব্যাকআপ আলাদা রাখুন; (3) দৈনন্দিন অ্যাকাউন্টে প্রশাসক অধিকার দেবেন না। ব্যাকআপ, এনক্রিপশন ও ফেলে দেওয়া পর্যন্ত PC জীবনচক্রের প্রতিরক্ষা «BitLocker বাস্তব নির্দেশিকা» ও «PC ফেলে দেওয়ার চেকলিস্ট»-ও দেখুন।

7.4. ডিফ এরিয়া ফুরিয়ে গেলে পুরনো প্রজন্ম চুপচাপ উধাও

ধারা 4-এ দেখা গেছে, কপি-অন-রাইট ডিফ এরিয়া খায় স্ন্যাপশট নেওয়ার পর প্রতিটি ব্লক প্রথমবার ওভাররাইট হলে। ইতিমধ্যে সরানো ব্লকে যতবারই লিখুন খরচ বাড়ে না, তাই খরচ «কতবার লেখা হয়েছে» নয়, «রাখা স্ন্যাপশটের পর কত চওড়া পরিসরের ব্লক ওভাররাইট হয়েছে» দিয়ে ঠিক হয়। আর ডিফ এরিয়া সীমায় পৌঁছালে সেই ভলিউমের শ্যাডো কপি পুরনো থেকে মুছে যায়।¹ ইন্টারঅ্যাকটিভ ব্যবহারকারীকে কিছু জানানো হয় না, তাই «গত সপ্তাহের সংস্করণে ফেরা যাবে» আর যায় না — তখনই ধরা পড়ে। পুরোপুরি নীরবও নয়: System লগে volsnap উৎসের ইভেন্ট লেখা হয় (ডিফ এরিয়া খালাস করতে না পেরে মুছে ফেলার 25, সম্প্রসারণ ব্যর্থ বা সীমায় পৌঁছে বন্ধের 35/36 ইত্যাদি)। নিয়মিত পরখ ছাড়া এই volsnap ইভেন্ট মনিটরিং ও অ্যালার্টে রাখলে হারানো তাড়াতাড়ি ধরা যায়। বিপুল ফাইল আপডেট, বাল্ক রূপান্তর, ডিফ্র্যাগের মতো «ভলিউম চওড়া করে হাত বোলানো» কাজ ডিফ এরিয়া এক ধাক্কায় খেয়ে ফেলে — এই «ওভাররাইটের পরিসর দিয়ে ঠিক হয়» ধর্মের জন্যই। রাখা প্রজন্ম ব্যবসার শর্ত («ভুল মুছে ফেলা ধরতে সর্বোচ্চ কত দিন লাগে») মেটাচ্ছে কি না vssadmin list shadowstorage-এর ব্যবহার নিয়মিত দেখুন, দরকার হলে সীমা বাড়ান।⁵¹⁰

8. সারাংশ

• ব্যবহারে থাকা ফাইল সাধারণভাবে কপি না হওয়ার কারণ শেয়ারিং ভায়োলেশন ও সামঞ্জস্য, আর সেটা ডেটা রক্ষার সঠিক ব্যবস্থা। «না থামিয়ে সামঞ্জস্যপূর্ণ কপি চাই»-এর OS-স্তরের উত্তর VSS।
• VSS রিকোয়েস্টার (অনুরোধ), রাইটার (সামঞ্জস্যের নিশ্চয়তা), প্রোভাইডার (তৈরি) — এই তিন ভূমিকাকে VSS সার্ভিস সমন্বয় করে, একে অপরকে না-জানা ব্যাকআপ সফটওয়্যার ও ব্যবসায়িক অ্যাপ সহযোগিতা করতে পারে।
• সিস্টেম প্রোভাইডার কপি-অন-রাইট ব্যবহার করে, স্থিরবিন্দু «রাইটার ফ্রিজ (সর্বোচ্চ 60 সেকেন্ড) → তৈরি (10 সেকেন্ডের মধ্যে) → থ» দিয়ে হয়। রাইটার সহযোগিতা না থাকলে ক্র্যাশ সামঞ্জস্য, থাকলে অ্যাপ্লিকেশন সামঞ্জস্য।
• অপারেশন পরখ vssadmin (list shadows / list writers / list shadowstorage)। রাইটার ত্রুটিতে অ্যাপের দিক সন্দেহ করুন, ডিফ এরিয়ার ব্যবহার নিয়মিত দেখুন।
• ডেভেলপার আগে সিদ্ধান্ত সারণি দিয়ে দেখুন পুনঃচেষ্টা, শেয়ার মোড, থামার সময়, সহযোগিতার নকশা দিয়ে মেটে কি না; সত্যি দরকার হলেই VSS-এ যান। নিজে ইমপ্লিমেন্ট করার চেয়ে DiskShadow স্ক্রিপ্ট (কেবল Server) বা বিদ্যমান সফটওয়্যারই বাস্তব সমাধান।
• শ্যাডো কপি ব্যাকআপ নয়। মূল ভলিউমের অক্ষত ব্লকের উপর নির্ভর করা ডিফারেনশিয়াল মাত্র; ডিস্ক নষ্টের মতো মূল ভলিউম হারানোতে অসহায়, র‍্যানসমওয়্যারের বিরুদ্ধেও শ্যাডো কপি মুছে ফেলা বা ডিফ এরিয়া ফুরিয়ে যাওয়ায় ভরসা করা যায় না। অফলাইন, আলাদা স্থানের ব্যাকআপের সঙ্গে জোড়ুন।

সম্পর্কিত নিবন্ধ

• Mutual Exclusion Fundamentals for File-Based Integration - Best Practices for File Locks and Atomic Claims
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
• When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running
• BitLocker Practical Guide — Drive Encryption Starting With Recovery Key Management
• What to Do Before Disposing of a Windows PC — A Practical Checklist for Data Erasure, Account Unlinking, and Backups

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC «ব্যবহারে থাকা ফাইল কপি ও ব্যাকআপ ফিচার»সহ ব্যবসায়িক অ্যাপের নকশা ও ডেভেলপমেন্ট, ফাইল সহযোগিতার শেয়ারিং ভায়োলেশন ও ব্যাকআপ ব্যর্থতা (VSS রাইটার ত্রুটি)-র কারণ তদন্ত, এবং ফাইল সার্ভারের ব্যাকআপ ও প্রজন্ম ব্যবস্থাপনার অপারেশন গুছানো সামলায়। «আদৌ VSS দরকার এমন চাহিদা কি না» সেই কাটাকুটি থেকে শুরু করলেই হয়।

• Windows অ্যাপ ডেভেলপমেন্ট
• বাগ ও কারণ তদন্ত
• প্রযুক্তিগত পরামর্শ ও ডিজাইন রিভিউ
• যোগাযোগ করুন

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

শ্যাডো কপি থাকলে কি ব্যাকআপ আর দরকার নেই?

না, দরকার থেকে যায়। 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 সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।