VPN ফিরে আসার পরেও আপনার NAS ব্যাকআপ ব্যর্থ হয়েছে

VPN 06:10-এ আবার সংযুক্ত হয়, ড্যাশবোর্ড টানেলকে সবুজ দেখায়, তবুও রাতের ব্যাকআপে এখনো নতুন পুনরুদ্ধার পয়েন্ট নেই। এটি কোনো বিরোধ নয়; এটি দুটি সময়সূচি যা কখনো সমন্বয় করা হয়নি। যে টানেল ফিরে আসে তা একটি নেটওয়ার্ক ঘটনা। যে ব্যাকআপ সম্পূর্ণ হয় তা নিজস্ব স্টেট মেশিনসহ একটি অ্যাপ্লিকেশন ঘটনা, আর একটি বিঘ্নিত রান স্থগিত, বাতিল বা সম্পূর্ণ ভিন্ন কিছুর পেছনে সারিবদ্ধ হতে পারে।

টানেলের নির্দেশক বাতি ঘিরে নয়, সম্পূর্ণ পুনরুদ্ধার পয়েন্ট ঘিরে সময়সীমা পরিকল্পনা করুন।

শুরুর সময় নয়, পুনরুদ্ধার পয়েন্ট থেকে শুরু করুন

প্রয়োজনটিকে একটি গৃহীত সংস্করণের সময়সীমা হিসেবে লিখুন: নির্দিষ্ট সময়ের মধ্যে কাজটির নিজস্ব অখণ্ডতা যাচাই পাস করে এমন একটি নতুন পুনরুদ্ধার পয়েন্ট। তারপর প্রত্যাশিত সময়কাল, সাধারণ ভিন্নতা এবং একটি বিঘ্নিত প্রচেষ্টার মধ্য দিয়ে পিছনে কাজ করুন। শুরুর সময় কোনো অঙ্গীকার নয়; এটি কেবল সেই মুহূর্ত যখন সময়সূচিকারী চেষ্টা করেছে। সময়সীমাটি চ্যাট বার্তায় নয়, ব্যাকআপ নীতিতে রাখুন। যে সংখ্যা কেবল কারও স্মৃতিতে বাস করে তা পর্যবেক্ষণ থ্রেশহোল্ড নয়।

সময়কালের অনুমানের জন্য কাজটির ইতিহাস ব্যবহার করুন। খণ্ড প্রক্রিয়াকরণ, ডিডুপ্লিকেশন ও সূচক কাজ রানের অংশ, তাই পরিবর্তিত বাইটকে লিঙ্ক গতিতে ভাগ করলে সময়সীমা কম দেখা যায়, যা পরে নেটওয়ার্ক সমস্যার মতো মনে হয়।

বিঘ্ন কাজটির প্রতি কী করে

Hyper Backup পুনরায় শুরু করা যায় এমন কাজ ও যায় না এমন কাজের মধ্যে পার্থক্য করে: নথিভুক্ত আচরণ হলো সংযোগ কেটে গেলে পুনরায় শুরুযোগ্য কাজ স্থগিত হয় এবং অ-পুনরায় শুরুযোগ্য কাজ বাতিল হয়। কোনো অবস্থাই VPN ক্লায়েন্ট থেকে দৃশ্যমান নয়, এবং কোনোটিই টানেল পুনঃসংযোগে সারানো হয় না। পরবর্তী সময়সূচিকৃত রান পুরোটির থামার জায়গা থেকে শুরু হবে ধরে নেওয়ার আগে কাজের অবস্থা ও তার লিপিবদ্ধ কারণ পড়ুন।

ম্যানুয়াল স্থগিতাদেশ ও নেটওয়ার্ক বিঘ্ন ভিন্ন জীবনচক্র অনুসরণ করতে পারে। কোনো অপারেটর কাজটি বিরতি দিলে নেটওয়ার্ক পুনঃসংযোগ কিছুই বদলায় না।

গন্তব্যের নিজস্ব প্রয়োজনীয়তা আছে

পুনরুদ্ধার করা টানেল কোনো এনক্রিপ্টেড শেয়ার্ড ফোল্ডার মাউন্ট করে না, মেয়াদোত্তীর্ণ ব্যাকআপ ক্রেডেনশিয়াল নবায়ন করে না, বা গন্তব্যে রক্ষণাবেক্ষণ শেষ করে না। এগুলো আলাদা প্রস্তুতি যাচাই, এবং এদের যেকোনো একটি সবুজ টানেলকে ব্যর্থ কাজে পরিণত করতে পারে। পুনরুদ্ধার সময়সূচিকে দোষ দেওয়ার আগে গন্তব্যটি পৌঁছানোযোগ্য ও লেখা যায় কিনা নিশ্চিত করুন।

গন্তব্য NAS নিজেই রিবুট হয়ে থাকলে ব্যাকআপ কাজ চালু হওয়ার সময় এর সেবাগুলো এখনো চালু হতে পারে। সংক্ষিপ্ত প্রস্তুতি যাচাই একটি ব্যর্থ রান ও পুনরায় চেষ্টার চেয়ে সস্তা।

অখণ্ডতা যাচাই একই ঘণ্টাগুলোর জন্য প্রতিযোগিতা করে

কোনো নেটওয়ার্ক ব্যর্থতা ছাড়াই একটি অখণ্ডতা যাচাই সময়সীমা খেয়ে ফেলতে পারে। DSM প্রতি কাজে একটি সক্রিয় প্রক্রিয়া নথিভুক্ত করে, এবং একটি সময়সূচিকৃত ব্যাকআপ সেই কাজের অখণ্ডতা যাচাইয়ের পেছনে অপেক্ষা করে প্রায় তিন ঘণ্টার সর্বোচ্চ অপেক্ষার পরে বাদ পড়তে পারে। পর্যবেক্ষিত সময়কাল অনুযায়ী দুটি সময়সূচি ফাঁকা রাখুন, এবং বাদ পড়া রানকে VPN আবার ব্যর্থ হয়েছে এমন প্রমাণ নয়, বরং সময়সূচি সংক্রান্ত পর্যবেক্ষণ হিসেবে দেখুন।

বাস্তব সরবরাহ পদ্ধতিসহ বিজ্ঞপ্তি চালু করুন, তারপর সেগুলো পড়ার জন্য কাউকে নির্ধারণ করুন। যে কাজ কখনো শুরু হয়নি এবং যে কাজ অর্ধপথে ব্যর্থ হয়েছে তারা একই সতর্কতা নাও দিতে পারে।

সকালের যাচাই কপি নিয়ে করুন

সকালের প্রশ্ন হলো টানেল চালু আছে কি না নয়, বরং একটি চলমান, পুনরুদ্ধারযোগ্য কপি আছে কি না। সর্বশেষ গৃহীত সংস্করণের বয়স সময়সীমার সাথে মিলিয়ে দেখুন, তারপর সেই সংস্করণ থেকে একটি ছোট ফাইলে নিরাপদ পুনরুদ্ধার পরীক্ষা করুন। ভুল দেখাচ্ছে এমন কিছু তদন্ত করার সময় আগের ভালো সংস্করণগুলো সংরক্ষণ করুন।

সময়চিহ্নগুলো একটি সময় অঞ্চলে লিপিবদ্ধ করুন, যার মধ্যে সময়সূচিকারীর অঞ্চল, গন্তব্যের অঞ্চল এবং ড্যাশবোর্ড পড়া ব্যক্তির অঞ্চল অন্তর্ভুক্ত। এসব তদন্তের একাধিক নেটওয়ার্ক ত্রুটির বদলে ঘড়ির পার্থক্যে শেষ হয়, আর নোটটিই পরের বার তা দৃশ্যমান করে।