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

ধীর লাগলে কাজটি কোন ধাপে থাকে

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

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

সর্বজনীন এন্ডপয়েন্ট ও ব্যক্তিগত NAS ভিন্নভাবে ব্যর্থ হয়

সর্বজনীন ব্যাকআপ সেবা নিজস্ব প্রমাণিত অ্যাপ্লিকেশন সংযোগ বহন করে, আর টানেল দীর্ঘ পথের এক ধাপ। ব্যক্তিগত NAS সাধারণত আপনার নেটওয়ার্কে পৌঁছানোর জন্য সেই টানেলের উপর নির্ভর করে। এই পার্থক্যই ঠিক করে টানেল বন্ধ করা বৈধ ভিত্তিরেখা, নাকি কিছুই না পরীক্ষা।

সর্বজনীন ক্ষেত্রে নীতি অনুমতি দিলে অন্য রুটে একই কাজ ন্যায্য তুলনা হতে পারে। ব্যক্তিগত ক্ষেত্রে টানেল সরালে সার্ভারে পৌঁছানোর কোনো পথই থাকে না, তাই ফলটি আপনি ব্যবহার করা পথ নয়, বরং আপনি মুছে ফেলা পথের বর্ণনা দেয়।

DestinationWhat the tunnel providesValid baseline
Public backup serviceOne hop among severalThe same job over another route
Private NASThe only path to the serverNone that removes the tunnel
Self-hosted gatewayPath plus split-DNS policyOnly if the policy is unchanged

স্থবিরতা ধীর স্থানান্তরের চেয়ে ভিন্ন ব্যর্থতা

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

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

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

একটি আপলোড অন্য সব প্রবাহকে অনাহারে রাখতে পারে

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

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

গতি পরীক্ষা নয়, পুনরুদ্ধার দিয়ে শেষ করুন

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

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

নেটওয়ার্ক পরিবর্তনের পর স্থানান্তর ও পুনরুদ্ধার দুটোই পুনরাবৃত্তি করুন, যাতে দেখা যায় উন্নতিটি কেবল দ্রুততর তথ্য সরানো নয়, বরং ব্যাকআপের সেবায়। সেই দ্বিতীয় চালানই টিকিট বন্ধ করে। অপরীক্ষিত পুনরুদ্ধারসহ দ্রুততর স্থানান্তর অসুরক্ষিত থাকার এক ধীরগতির উপায়।

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