VPN-এ rsync: ভাঙা স্থানান্তর পুনর্ব্যবহার করা একটি পুনঃপ্রয়াস
কেটে যাওয়া টানেল সংযোগ শেষ করে, ডেটা নয়। --partial-dir দিয়ে অংশটি রাখুন, একই অনুলিপি আবার চালান, এবং প্রকাশের আগে ফাইলটি যাচাই করুন।
আপনার আপলোড বারো গিগাবাইটের একটি আর্কাইভের চার গিগাবাইটে আটকে যায়, আর ডাউনলোড ম্যানেজার থেকে শেখা অভ্যাস বলে রিজিউম চাপতে। rsync TCP স্ট্রিম পুনরায় শুরু করবে না, কারণ সেই স্ট্রিম টানেলের শেষ রিট্রান্সমিশনের সঙ্গে চলে গেছে। যা করতে পারে তা হল, ইতিমধ্যে পাওয়া বাইটগুলো রেখে সেগুলোকে পরবর্তী প্রয়াসের ভিত্তি হিসেবে ব্যবহার করা — এটি ভিন্ন নিয়মের ভিন্ন একটি ব্যবস্থা। আপনি যে ফ্ল্যাগ বাছাই করবেন তা ঠিক করে এই পুনর্ব্যবহার আদৌ ঘটবে কি না।
পুনঃপ্রয়াস অবস্থা পুনর্গঠন করে, স্ট্রিম পুনরায় শুরু করে না
SSH সেশন কেটে গেলে দূরের প্রান্তে শুধু যা ডিস্কে ফ্লাশ করেছে তাই থাকে, আর কিছু নয়। আবার যুক্ত হওয়ার জন্য কোনো সেশন টোকেন নেই, রিপ্লে করার জন্য কোনো ক্রম সংখ্যা নেই। পরের রান নতুন সংযোগ খোলে, উৎস আবার পড়ে এবং গ্রহীতাকে জিজ্ঞেস করে তার কাছে ইতিমধ্যে কী আছে।
সেই শেষ প্রশ্নটাই ব্যাখ্যা করে কেন আংশিক ফাইল রেখে দেওয়া মূল্যবান। গ্রহীতার অনুলিপি rsync-কে তুলনার কিছু দেয়, এবং অ্যালগরিদম কেবল যে পার্থক্যগুলো শনাক্ত করতে পারে সেগুলোই পাঠায়। এটি এখনও মেটাডেটার নতুন স্থানান্তর এবং উৎসের ওপর নতুন পাস, তাই বাঁচানো সময় নির্ভর করে ফাইলের কতটা মেলে তার ওপর, আগের সংযোগ কতদূর এগিয়েছিল তার ওপর নয়। গ্রহীতা কিছুই রাখেনি হলে পরের প্রয়াস পূর্ণ অনুলিপি, প্রথমটি যত গিগাবাইটই সরানো হোক না কেন।
পুনর্ব্যবহারযোগ্য অংশটি কোথায় থাকবে তা ঠিক করুন
ডিফল্ট আচরণ আংশিক ফাইলটি গন্তব্য পথে লেখে, যা অর্ধেক লেখা আর্কাইভকে চূড়ান্ত নামের নিচে দৃশ্যমান করে। --partial-dir এটি আপনার বেছে নেওয়া একটি ডিরেক্টরিতে সরায়, এবং ম্যানুয়াল সেই ডিরেক্টরিকে পরবর্তী স্থানান্তরের দ্বারা ডেটা হিসেবে ব্যবহারের জন্য সংরক্ষিত বলে বর্ণনা করে। আপেক্ষিক নাম গন্তব্য ডিরেক্টরির অধীনে সমাধান হয়, দুটি প্রান্তের বিন্যাস ভিন্ন হতে পারে তখন এটাই আপনি চান।
rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
large-archive.bin [email protected]:/srv/incoming/
গন্তব্যেও ক্রম গুরুত্বপূর্ণ: আংশিক ডিরেক্টরিতে অংশটির জন্য যথেষ্ট জায়গা লাগে, আর ভলিউমে সম্পূর্ণ ফাইলের জন্যও যথেষ্ট জায়গা লাগে। স্থানান্তরের মাঝপথে লক্ষ্য ভলিউম ভরে গেলে এমন ব্যর্থতা হয় যা নেটওয়ার্ক সমস্যার মতো দেখায় কিন্তু নয়, এবং সংরক্ষিত অংশটি ছোট হয়ে যেতে পারে। রান শুরুর আগেই গ্রহণকারী হোস্টে খালি জায়গা দেখুন, ব্যর্থ হওয়ার পরে নয়। একই SSH পথে df -h দিয়ে কয়েক সেকেন্ড পরিকল্পনার সবচেয়ে সস্তা পরীক্ষা।
অনুমতিগুলো ছোট কিন্তু বাস্তব উদ্বেগ। অসংশ্লিষ্ট অ্যাকাউন্টে লেখার উপযোগী আংশিক ডিরেক্টরি অন্য কাউকে এমন বিষয়বস্তু বসানোর সুযোগ দেয় যা আপনার পরের রান ইতিমধ্যে পাওয়া বলে ধরবে। এটি স্থানান্তর অ্যাকাউন্টের মালিকানায় রাখুন, এবং অন্য সেবারা প্রকাশ করে এমন জায়গায় রাখবেন না।
একই অনুলিপি চালান, বুদ্ধিমান কোনোটা নয়
পুনর্ব্যবহার কেবল তখনই প্রযোজ্য যখন উৎস ও গন্তব্য এখনও একই বস্তু বর্ণনা করে। একই পথ, একই নাম, একই ফাইল। উৎসের নাম বদলালে বা অন্য গন্তব্য ডিরেক্টরিতে দেখালে কাজে লাগে না এমন কিছুর সঙ্গে নতুন তুলনা শুরু হয়।
ডেল্টা আচরণ আশা করে --whole-file যোগ করবেন না। ওই অপশন rsync-কে রোলিং-চেকসাম তুলনা ছাড়াই পুরো ফাইল কপি করতে বলে, যা দ্রুত স্থানীয় লিংকে যুক্তিসঙ্গত পছন্দ এবং ব্যর্থ দূরপাল্লার আপলোডের পরে ঠিক উল্টো পছন্দ। --inplace গল্পটাও বদলে দেয়: এটি সরাসরি গন্তব্য ফাইলে লেখে, তাই বাধা পড়লে পুরোনো ও নতুন মিশ্রিত একটি ফাইল থাকে, পিছু হটার আলাদা অংশ থাকে না।
প্রগ্রেস লাইন স্থানান্তরের সামগ্রিক অগ্রগতি জানায়। এটি সমাপ্তির সংকেত নয়। সংযোগ খোলা থাকতেই সংখ্যা একশো শতাংশে পৌঁছালে বোঝায় ডেটা পাঠানো হয়েছে, গ্রহীতা কিছু নাম বদলেছে, সিঙ্ক করেছে বা গ্রহণ করেছে তা নয়।
মিলে যাওয়ার পরেই বস্তুটি গ্রহণ করুন
আগে এক্সিট স্ট্যাটাস নিশ্চিত করুন, তারপর ত্রুটির অনুপস্থিতিতে ভরসা না করে ফলাফল তুলনা করুন। আকার পরীক্ষা বেশিরভাগ ছোট হয়ে যাওয়া স্থানান্তর ধরে; চেকসাম তুলনা বাকিটা ধরে, এবং আপলোড আবার চালানোর তুলনায় দুটোই সস্তা।
আর্কাইভ যদি ডাউনস্ট্রিম প্রক্রিয়া দিয়ে প্রকাশিত হয়, সেই প্রক্রিয়াকে গৃহীত ফাইলের জন্য অপেক্ষা করান। চূড়ান্ত নামে নজরদারি করা ডিরেক্টরিতে পড়া সংরক্ষিত অংশ পরের স্ক্যানে উঠে যায়, এবং ভোক্তার ত্রুটি হবে নষ্ট ইনপুট নিয়ে, কখনও শেষ হয়নি এমন স্থানান্তর নিয়ে নয়।
প্রাপক নিশ্চিত না করা পর্যন্ত উৎসটি ছুঁবেন না। প্রয়াসের মাঝে আর্কাইভ পুনরায় তৈরি করলে তুলনার ভিত্তি বদলায়, আর পরের রান হয় প্রায় সবকিছু স্থানান্তর করে, নয়তো এমন ফাইল তৈরি করে যা পুরোনো বা নতুন কোনও উৎসের সঙ্গেই মেলে না।
যখন লিংক, ফ্ল্যাগ নয়, সীমা
হেডার ও প্রোটোকল ওভারহেড স্থানান্তরের একটি খরচ, এবং বড় ফাইল কত সময় নেবে তা খুব কমই এটাই ঠিক করে। রিস্টার্ট আচরণ বেশি গুরুত্বপূর্ণ: যে পদ্ধতি হাতে কিছু না করেই বিচ্ছিন্নতা কাটিয়ে ওঠে, সেটি আবার শুরু করতে হওয়া দ্রুততর পদ্ধতির চেয়ে আগে ব্যবহারযোগ্য ফাইল দেয়। দুই প্রান্তের স্টোরেজ ও প্রমাণীকরণের পথ একই তুলনায় পড়ে।
একই ফাইল ও একই গন্তব্য নিয়ে অনুমোদিত বিকল্প পথগুলো তুলনা করুন, এবং বাধার পরে প্রতিটি কোথা থেকে আবার শুরু করে তা লিখে রাখুন। ওই একটিমাত্র কলাম VPN-এর ওপর দিয়ে বারো গিগাবাইটের আপলোড সম্পর্কে সংক্ষিপ্ত পরীক্ষায় মাপা যেকোনো শিখর গতির চেয়ে বেশি বলে।