ওপেনএসএসএইচ/নির্দেশিকা/স্বয়ংক্রিয় ব্যাকআপ

কী-সহ ওপেনএসএসএইচ ব্যবহার করলে নিরাপদ স্বয়ংক্রিয় ব্যাকআপ নেওয়া সহজ হয়। rsync(1), tar(1) এবং dump(8) অধিকাংশ ব্যাকআপ পদ্ধতির ভিত্তি। দূরবর্তী রুট অ্যাক্সেস অবশ্যই চালু রাখতে হবে - এ ধারণাটি ভুল। রুট অ্যাক্সেসের প্রয়োজন হলে sudo(8) যথেষ্ট ভালোভাবে কাজ করে; আর zfs(8)-এর ক্ষেত্রে ওপেনজেডএফএস ডেলিগেশন সিস্টেম ব্যবহার করা যায়। মনে রাখতে হবে, ব্যাকআপ ডেটা পরীক্ষা করে নির্ভরযোগ্যভাবে পুনরুদ্ধার করা যায়, এটি প্রমাণিত না হওয়া পর্যন্ত সেটিকে প্রকৃত ব্যাকআপ কপি ধরা যায় না।

rsync(1) দিয়ে ব্যাকআপ

rsync(1) প্রায়ই স্থানীয় ও দূরবর্তী, দুই ধরনের ব্যাকআপেই ব্যবহৃত হয়। এটি দ্রুত ও নমনীয়, এবং ক্রমবর্ধমান পদ্ধতিতে কপি করে; ফলে শুধু পরিবর্তিত অংশই স্থানান্তরিত হয়, গন্তব্যে আগে থেকেই থাকা ডেটা আবার কপি করে সময় নষ্ট হয় না। এটি অ্যালগরিদম ব্যবহার করে এ কাজটি করে। দূরবর্তীভাবে কাজ করার সময় এনক্রিপশন-এর জন্য এর সামান্য সহায়তা দরকার হয় এবং প্রচলিত পদ্ধতি হলো এসএসএইচ-এর ওপর দিয়ে এটিকে টানেল করা।

rsync(1) ইউটিলিটি এখন ডিফল্ট হিসেবে এসএসএইচ ব্যবহার করে এবং ২০০৪ সাল থেকেই তা করছে। তাই নিচের কমান্ড-টি অতিরিক্ত কিছু যোগ না করেই এসএসএইচ-এর মাধ্যমে সংযোগ করে:

$ rsync -a fred@server.example.org:./archive/ \
    /home/fred/archive/.

তবে এসএসএইচ ক্লায়েন্টে অতিরিক্ত অপশন পাঠাতে হলে এসএসএইচ-এর ব্যবহার এখনও স্পষ্টভাবে নির্দিষ্ট করা যায়:

$ rsync -a -e 'ssh -v' \
    fred@server.example.org:./archive/ \
    /home/fred/archive/.

কিছু ধরনের ডেটার ক্ষেত্রে, দুই প্রান্তের সিপিইউ অতিরিক্ত কাজ সামলাতে পারলে rsync(1)-এর সঙ্গে সংকোচন অপশন -z ব্যবহার করলে স্থানান্তর অনেক দ্রুত হতে পারে। তবে এটি গতি কমিয়েও দিতে পারে। তাই সংকোচন সহায়ক হবে নাকি বাধা দেবে, তা নির্দিষ্ট পরিবেশে পরীক্ষা করে দেখা দরকার।

কী-সহ আরসিঙ্ক

যেহেতু rsync(1) ডিফল্ট হিসেবে এসএসএইচ ব্যবহার করে, তাই -e অপশন দিয়ে অতিরিক্ত অপশন নির্দিষ্ট করে এটি এসএসএইচ কী দিয়েও প্রমাণীকরণ করতে পারে। এভাবে সংযোগ স্থাপনের সময় এসএসএইচ ক্লায়েন্ট কোন নির্দিষ্ট এসএসএইচ কী ফাইল ব্যবহার করবে তা দেখিয়ে দেওয়া যায়।

$ rsync --exclude '*~' -avv \
    -e 'ssh -i ~/.ssh/key_bkup_rsa' \
    fred@server.example.org:./archive/ \
    /home/fred/archive/.

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

sudo(8) দিয়ে rsync(1)-এর রুট-স্তরের প্রবেশাধিকার

কখনও কখনও ব্যাকআপ প্রক্রিয়ার এমন অ্যাকাউন্ট-এ প্রবেশাধিকার দরকার হয়, যেটি লগইন করতে ব্যবহৃত অ্যাকাউন্ট থেকে আলাদা। সেই অন্য অ্যাকাউন্ট প্রায়ই রুট হয়; সর্বনিম্ন সুবিধাধিকার নীতির কারণে সাধারণত রুটকে এসএসএইচ দিয়ে সরাসরি লগইন করতে দেওয়া হয় না। প্রয়োজন হলে rsync(1) দূরবর্তী যন্ত্রে sudo(8) চালাতে পারে।

ধরা যাক, আপনি সার্ভার থেকে ক্লায়েন্টে ব্যাকআপ নিচ্ছেন। ক্লায়েন্টের rsync(1) ssh(1) ব্যবহার করে সার্ভারের rsync(1)-এর সঙ্গে সংযোগ করে। ক্লায়েন্ট থেকে rsync(1) চালানোর সময় এসএসএইচ ক্লায়েন্টে -v পাঠানো হয়, যাতে সার্ভারে ঠিক কোন প্যারামিটার পাঠানো হচ্ছে দেখা যায়। সেই তথ্য পরে সার্ভারের sudo(8) কনফিগারেশন-এ যুক্ত করতে লাগবে। এখানে এসএসএইচ ক্লায়েন্ট এক স্তর বেশি বিস্তারিততা-সহ চালানো হয়েছে, যাতে কোন অপশন ব্যবহার করতে হবে তা দেখা যায়:

$ rsync \
  -e 'ssh -v \
          -i ~/.ssh/key_bkup_rsa  \
          -t             \
          -l bkupacct'   \
  --rsync-path='sudo rsync' \ 
  --delete   \
  --archive  \
  --compress \
  --verbose  \
  bkupacct@server:/var/www/ \
  /media/backups/server/backup/

এখানে --rsync-path আর্গুমেন্ট সার্ভার-কে জানায় rsync(1)-এর জায়গায় কী চালাতে হবে। এই ক্ষেত্রে এটি sudo rsync চালায়। -e আর্গুমেন্ট বলে কোন দূরবর্তী shell টুল ব্যবহার করতে হবে। এই ক্ষেত্রে সেটি ssh(1)। rsync(1) ক্লায়েন্ট যে এসএসএইচ ক্লায়েন্টটি ডাকছে, তার জন্য -i নির্দিষ্ট করে বলে দেয় কোন কী ব্যবহার করতে হবে। প্রমাণীকরণ এজেন্ট ব্যবহার করা হচ্ছে কি না, তার সঙ্গে এটি স্বতন্ত্র। একাধিক কী থাকা সম্ভব, কারণ আলাদা কাজের জন্য আলাদা কী রাখা যায়।

ক্লায়েন্টে এসএসএইচ বিস্তারিত মোড (-v) চালিয়ে /etc/sudoers-এ ব্যবহারের সুনির্দিষ্ট সেটিং(s) বের করা যায়। প্যাটার্ন নিয়ে কাজ করার সময় সতর্ক থাকতে হবে, যাতে নিরাপদ সীমার বেশি কিছু মিলে না যায়।

এই সেটিং-গুলো সমন্বয় করা সম্ভবত পুনরাবৃত্তিমূলক প্রক্রিয়া হবে। বিস্তারিত আউটপুট দেখে সার্ভারের /etc/sudoers-এ পরিবর্তন করতে থাকুন, যতক্ষণ না এটি ঠিকভাবে কাজ করে। শেষ পর্যন্ত /etc/sudoers-এ এমন একটি লাইন থাকবে, যা rsync(1)-কে ন্যূনতম অপশন-সহ চালানোর অনুমতি দেবে।

এসএসএইচ-এর ওপর দিয়ে দূরবর্তী sudo(8) ব্যবহার করে rsync(1) চালানোর ধাপ

এই উদাহরণগুলো দূরবর্তী সিস্টেম থেকে ডেটা আনা করার ওপর ভিত্তি করে তৈরি। অর্থাৎ ডেটা দূরবর্তী সিস্টেমের /source/directory/ থেকে স্থানীয় সিস্টেমের /destination/directory/-তে কপি হয়। তবে বিপরীত দিক-এর জন্যও ধাপগুলো একই থাকবে, শুধু কয়েকটি অপশন ভিন্ন জায়গায় থাকবে এবং --sender বাদ যাবে। যেভাবেই করা হোক, নিচের exampleগুলো সরাসরি কপি-পেস্ট করলে কাজ করবে না।

প্রস্তুতি: শুধু ব্যাকআপ-এর সময় ব্যবহারের জন্য একটি একক-উদ্দেশ্যের অ্যাকাউন্ট তৈরি করুন, শুধু সেই অ্যাকাউন্ট-এর জন্য এক জোড়া কী তৈরি করুন, তারপর নিশ্চিত করুন যে ssh(1) দিয়ে কী-সহ এবং কী ছাড়াও সেই অ্যাকাউন্ট-এ লগইন করা যায়।

$ ssh -i ~/.ssh/key_bkup_ed25519 bkupacct@www.example.org

সার্ভারের অ্যাকাউন্ট-এর নাম bkupacct এবং ক্লায়েন্টে ব্যক্তিগত Ed25519 কী হলো ~/.ssh/key_bkup_ed25519। সার্ভারে bkupacct অ্যাকাউন্ট-টি backups গ্রুপ-এর সদস্য। প্রয়োজন হলে পাবলিক কী প্রমাণীকরণ অধ্যায়াংশ দেখুন।

সর্বজনীন কী ~/.ssh/key_bkup_ed25519.pub দূরবর্তী সিস্টেমের bkupacct অ্যাকাউন্ট-এ কপি করে সঠিক স্থানে ~/.ssh/authorized_keys-এর মধ্যে রাখতে হবে। এরপর সার্ভারের নিচের ডিরেক্টরি-গুলো রুট-মালিকানাধীন এবং backups গ্রুপ-এর অন্তর্ভুক্ত হতে হবে; গ্রুপ পঠনযোগ্য হবে, কিন্তু গ্রুপ লিখনযোগ্য নয়, এবং অবশ্যই সবার জন্য পঠনযোগ্য নয়: ~ এবং ~/.ssh/। সেখানে ~/.ssh/authorized_keys ফাইলের ক্ষেত্রেও একই কথা প্রযোজ্য। (এখানে আরও ধরে নেওয়া হয়েছে যে এসিএল ব্যবহার করা হচ্ছে না।) তবে দূরবর্তী সিস্টেমে অনুমতি নির্ধারণের অনেক পদ্ধতির মধ্যে এটি মাত্র একটি:

$ sudo chown root:bkupacct ~
$ sudo chown root:bkupacct ~/.ssh/
$ sudo chown root:bkupacct ~/.ssh/authorized_keys
$ sudo chmod u=rwx,g=rx,o= ~
$ sudo chmod u=rwx,g=rx,o= ~/.ssh/
$ sudo chmod u=rwx,g=r,o=  ~/.ssh/authorized_keys

এখন কনফিগারেশন শুরু করা যায়।

ধাপ ১: sudoers(5) কনফিগার করুন, যাতে দূরবর্তী হোস্টে rsync(1) sudo(8)-এর সঙ্গে কাজ করতে পারে। এই ক্ষেত্রে ডেটা দূরবর্তী যন্ত্র-এই থাকছে। পরে প্রবেশাধিকার সীমিত করার জন্য কোন নির্দিষ্ট অপশন ব্যবহার করতে হবে তা খুঁজে বের করার উদ্দেশ্যে backups গ্রুপকে সাময়িকভাবে পূর্ণ প্রবেশাধিকার দিতে হবে।

%backups ALL=(root:root) NOPASSWD: /usr/bin/rsync

এটি একটি অস্থায়ী ধাপ, এবং এই লাইন-টি এ অবস্থায় দীর্ঘ সময় রেখে দেওয়া উচিত নয়।

তবে এটি থাকা অবস্থায় --rsync-path অপশন দিয়ে পরীক্ষা করে নিশ্চিত করুন যে rsync(1) sudo(8)-এর সঙ্গে কাজ করছে।

$ rsync --rsync-path='sudo rsync' \
-aHv bkupacct@www.example.org:/source/directotry/ /destination/directory/

স্থানান্তর-টি ত্রুটি, সতর্কতা বা অতিরিক্ত পাসওয়ার্ড প্রবেশ ছাড়াই চলা উচিত।

ধাপ ২: এরপর প্রমাণীকরণ-এর জন্য কী ব্যবহার করে একই স্থানান্তর আবার করুন, যাতে নিশ্চিত হওয়া যায় যে দুটো একসঙ্গে ব্যবহার করা যাচ্ছে।

$ rsync -e 'ssh -i ~/.ssh/key_bkup_ed25519' --rsync-path='sudo rsync' \
-aHv bkupacct@www.example.org:/source/directory/ /destination/directory/

প্রয়োজন হলে আবার পাবলিক কী প্রমাণীকরণ অধ্যায়াংশ দেখুন।

ধাপ ৩: এখন সংযোগ বিবরণ সংগ্রহ করুন। sudoers(5) ঠিকভাবে সমন্বয় করতে এগুলো দরকার।

$ rsync -e 'ssh -E ssh.log -v -i ~/.ssh/key_bkup_ed25519' \
--rsync-path='sudo rsync' \
-aHv bkupacct@www.example.org:/source/directory/ /destination/directory/

$ grep -i 'sending command' ssh.log

দ্বিতীয় কমান্ড-টি, যেটি grep(1) ব্যবহার করে, নিচের মতো কিছু আউটপুট দেওয়ার কথা:

debug1: Sending command: rsync --server --sender -vlHogDtpre.iLsfxCIvu . /source/directory/

দীর্ঘ অক্ষরের স্ট্রিং এবং ডিরেক্টরি লক্ষ্য করা গুরুত্বপূর্ণ, কারণ পরে sudoers(5) সামান্য সমন্বয় করতে এগুলো ব্যবহার হবে। মনে রাখবেন, এই উদাহরণগুলোতে ডেটা দূরবর্তী যন্ত্র-এর /source/directory/ থেকে স্থানীয় যন্ত্র-এর /destination/directory/-তে কপি হয়।

উপরের সূত্র-র সঙ্গে মেলে এমন সেটিং নিচে দেওয়া হলো, ধরে নেওয়া হয়েছে অ্যাকাউন্ট-টি backups গ্রুপ-এ আছে:

%backups ALL=(root:root) NOPASSWD: /usr/bin/rsync --server --sender -vlHogDtpre.iLsfxCIvu . /source/directory/

এই লাইন sudoers(5) সমন্বয় করে, যাতে ব্যাকআপ অ্যাকাউন্ট রুট হিসেবে rsync(1) চালানোর মতো যথেষ্ট প্রবেশাধিকার পায়, তবে শুধু নির্ধারিত ডিরেক্টরি-গুলোর মধ্যে এবং সিস্টেমে অবাধ ক্ষমতা ছাড়া।

পরে আরও পরিমার্জন করা যেতে পারে, কিন্তু sudoers(5) সীমাবদ্ধ করার মৌলিক বিষয় এগুলোই। এই পর্যায়ে কাজ প্রায় শেষ, যদিও প্রক্রিয়া আরও অনেক বেশি স্বয়ংক্রিয় করা যায়। স্থানীয়ভাবে সংরক্ষণের পর ব্যাকআপ নেওয়া ডেটা যেন অন্যদের কাছে প্রবেশযোগ্য না থাকে, তা নিশ্চিত করুন।

ধাপ ৪: sudoers(5)-এ করা সেটিং সঠিক কি না যাচাই করতে ssh(1)-এর ওপর দিয়ে sudo(8)-সহ rsync(1) পরীক্ষা করুন।

$ rsync -e 'ssh -i ~/.ssh/key_bkup_ed25519' --rsync-path='sudo rsync' \
-aHv bkupacct@www.example.org:/source/directory/ /destination/directory/

এই পর্যায়ে ব্যাকআপ ঠিকভাবে চলা উচিত।

ধাপ ৫: শেষে, authorized_keys ফাইলে command="..." অপশন দিয়ে নিষেধাজ্ঞা আগে বসিয়ে কী-টিকে শুধু একটি কাজের মধ্যে সীমাবদ্ধ করা যায়। এর ব্যাখ্যা sshd(8)-এ পাওয়া যাবে।

command="/usr/bin/rsync --server --sender -vlHogDtpre.iLsfxCIvu . ./source/directory" ssh-ed25519 AAAAC3Nz...aWi

এরপর সেই একটি কী শুধু ব্যাকআপ-এর জন্যই কাজ করবে। এটি sudoers(5) ফাইলে করা সেটিং-এর ওপর আরেকটি অতিরিক্ত স্তর।

এভাবে দূরবর্তী রুট লগইন এড়িয়ে রুট-স্তরের প্রবেশাধিকার-সহ rsync(1) ব্যবহার করে স্বয়ংক্রিয় দূরবর্তী ব্যাকআপ করা যায়। তারপরও ব্যক্তিগত কীর ওপর সতর্ক নজর রাখতে হবে, কারণ সেটি দিয়ে এখনও দূরবর্তী ব্যাকআপ আনা যায় এবং তাতে সংবেদনশীল তথ্য থাকতে পারে।

শুরু থেকে শেষ পর্যন্ত প্রক্রিয়াটিতে অনেক খুঁটিনাটির প্রতি মনোযোগ দরকার, তবে ধাপে ধাপে এগোলে কাজটি পুরোপুরি করা যায়। বিপরীত দিক-এ ব্যাকআপ সেটআপ করাও বেশ মিল রয়েছে। স্থানীয় থেকে দূরবর্তী-এ গেলে ---sender অপশন বাদ যাবে এবং directoryগুলো ভিন্ন হবে।

আরসিঙ্ক প্রোটোকল-এর অন্যান্য বাস্তবায়ন

openrsync(1) হলো আরসিঙ্ক প্রোটোকল সংস্করণ 27-এর স্বতন্ত্র পুনর্বাস্তবায়ন, যা samba.org বাস্তবায়ন rsync(1) সমর্থন করে। ওপেনবিএসডি সংস্করণ 6.5 থেকে এটি ওপেনবিএসডি-এর মূল সিস্টেমে রয়েছে। এটি ভিন্ন নামে চালানো হয়; তাই এটি যদি দূরবর্তী সিস্টেমে থাকে এবং samba.org-এর rsync(1) স্থানীয় সিস্টেমে থাকে, তাহলে --rsync-path অপশন দিয়ে এর নাম দেখিয়ে দিতে হবে:

$ rsync -a -v -e 'ssh -i key_rsa' \
	--rsync-path=/usr/bin/openrsync \
	fred@server.example.org:/var/www/ \
	/home/fred/www/

বিপরীত দিক-এ, openrsync(1) দিয়ে শুরু করে দূরবর্তী সিস্টেমের rsync(1)-এর সঙ্গে সংযোগ করলে এমন পরিবর্তন দরকার হয় না।

tar(1) ব্যবহার করে ব্যাকআপ

সংরক্ষণাগার তৈরির জন্য tar(1) প্রায়ই বেছে নেওয়া হয়। কিন্তু এটি পুরো ফাইল ও ডিরেক্টরি কপি করে, তাই হালনাগাদ বা ক্রমবর্ধমান ব্যাকআপ-এর জন্য rsync(1) সাধারণত অনেক বেশি কার্যকর।

নিচের কমান্ড-টি স্থানীয় যন্ত্র-এ /var/www/ ডিরেক্টরি-এর একটি টারবল তৈরি করবে এবং স্ট্যান্ডার্ড আউটপুট দিয়ে সেটি পাঠাবে; তারপর ssh(1)-এর পাইপ-এর মাধ্যমে দূরবর্তী যন্ত্র-এর স্ট্যান্ডার্ড ইনপুট-এ যাবে, যেখানে সেটি backup.tar নামের ফাইলে রিডাইরেক্ট হবে। এখানে tar(1) স্থানীয় যন্ত্র-এ চলে এবং টারবল দূরবর্তী-এ সংরক্ষণ করে:

$ tar cf - /var/www/ | ssh -l fred server.example.org 'cat > backup.tar'

এই পদ্ধতির প্রায় অসংখ্য রূপভেদ আছে:

$ tar zcf - /var/www/ /home/*/www/ \
	|  ssh -l fred server.example.org 'cat > $(date +"%Y-%m-%d").tar.gz'

এই উদাহরণ একই কাজ করে, তবে ব্যবহারকারী ডব্লিউডব্লিউডব্লিউ ডিরেক্টরি-গুলোও নেয়, gzip(1) দিয়ে টারবল সংকুচিত করে, এবং বর্তমান তারিখ অনুযায়ী ফলে তৈরি ফাইলের নাম দেয়। কী দিয়েও এটি করা যায়:

$ tar zcf - /var/www/ /home/*/www/ \
	|  ssh -i key_rsa -l fred server.example.org 'cat > $(date +"%Y-%m-%d").tgz'

আর বিপরীত দিক-এ, দূরবর্তী যন্ত্র-এ কী আছে তা tar(1) দিয়ে নিয়ে টারবল স্থানীয়ভাবে সংরক্ষণ করাও ঠিক ততটাই সহজ।

$ ssh fred@server.example.org 'tar zcf - /var/www/' >  backup.tgz

অথবা এখানে দূরবর্তী যন্ত্র-এ tar(1) চালিয়ে টারবল স্থানীয়ভাবে সংরক্ষণের একটি একটু উন্নত উদাহরণ দেওয়া হলো।

$ ssh -i key_rsa -l fred server.example.org 'tar jcf - /var/www/ /home/*/www/' \
	> $(date +"%Y-%m-%d").tar.bz2

সারকথা হলো, ব্যাকআপ-এর জন্য tar(1) ব্যবহারের মূল কৌশল হলো পাইপ ও রিডাইরেক্ট-এর মাধ্যমে স্থানান্তর করতে stdout এবং stdin ব্যবহার করা।

টারবল না বানিয়ে tar(1) দিয়ে ফাইল ব্যাকআপ

কখনও কখনও গন্তব্য-এ টারবল না বানিয়ে শুধু ফাইল ও ডিরেক্টরি স্থানান্তর করার প্রয়োজন হয়। উৎস machine-এ stdin-এ লেখার পাশাপাশি, tar(1) গন্তব্য machine-এর stdin থেকেও পড়তে পারে, ফলে একবারে পুরো ডিরেক্টরি স্তরবিন্যাস স্থানান্তর করা যায়।

$ tar zcf - /var/www/ | ssh -l fred server.example.org "cd /some/path/; tar zxf -"

অথবা বিপরীত দিক-এ কমান্ড হবে নিচের মতো।

$ ssh 'tar zcf - /var/www/' | (cd /some/path/; tar zxf - )

তবে এগুলো চালানো হলে প্রতিবার সবকিছু কপি হয়। তাই অনেক পরিস্থিতিতে আগের অধ্যায়াংশ-এ বর্ণিত rsync(1) ভালো পছন্দ হতে পারে, কারণ পরের চালনাগুলোতে এটি শুধু পরিবর্তনগুলো কপি করে। এছাড়া ডেটার ধরন, নেটওয়ার্কের অবস্থা এবং উপলব্ধ সিপিইউ-এর ওপর নির্ভর করে tar(1) অথবা ssh(1)-এর নিজস্ব সংকোচন ব্যবহার করা ভালো হতে পারে।

dump ব্যবহার করে ব্যাকআপ

dump(8) দূরবর্তীভাবে ব্যবহার করা tar(1) ব্যবহারের মতো। দূরবর্তী সার্ভার থেকে স্থানীয় সার্ভারে কপি করা যায়।

$ ssh -t source.example.org 'sudo dump -0an -f - /var/www/ | gzip -c9' > backup.dump.gz

মনে রাখবেন, sudo(8)-এর পাসওয়ার্ড প্রম্পট দৃশ্যমান নাও হতে পারে, এবং পাসওয়ার্ড না দেখেই টাইপ করতে হতে পারে।

অথবা বিপরীত দিক-এ, স্থানীয় সার্ভার থেকে দূরবর্তী-এ কপি করা যায়:

$ sudo dump -0an -f - /var/www/ | gzip -c9 | ssh target.example.org 'cat > backup.dump.gz'

আবারও মনে রাখবেন, পাসওয়ার্ড প্রম্পট dump(8)-এর প্রাথমিক আউটপুট-এর মধ্যে আড়াল হয়ে যেতে পারে। তবে প্রম্পট দৃশ্যমান না হলেও সেটি থাকে।

zfs(8) স্ন্যাপশট ব্যবহার করে ব্যাকআপ

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

প্রথমে একটি পূর্ণ স্ন্যাপশট প্রয়োজন, কারণ ক্রমবর্ধমান স্ন্যাপশট শুধু আংশিক ডেটাসেট ধারণ করে এবং এগুলোর যে ভিত্তির ওপর তৈরি হয়েছে সেই ভিত্তি থাকা জরুরি। নিচের কমান্ড zfs(8) ব্যবহার করে web নামের পুলের site01 নামের ডেটাসেট-এর 20210326 নামের স্ন্যাপশট তৈরি করে।

$ zfs snapshot -r web/site01@20210326

প্রোগ্রাম-টি নিজে সম্ভবত /sbin/ ডিরেক্টরি-তে থাকবে; তাই পাথ পরিবেশ ভেরিয়েবল-এ সেটি থাকতে হবে, অথবা পূর্ণ পথ ব্যবহার করতে হবে। প্রাথমিক পূর্ণ স্ন্যাপশট-এর ওপর পরে -i অপশন ব্যবহার করে ক্রমবর্ধমান স্ন্যাপশট তৈরি করা যায়। তবে ওপেনজেডএফএস ব্যবস্থাপনা-এর বিস্তারিত বিষয় এই বইয়ের পরিধির অনেক বাইরে। এখানে সিস্টেমের মধ্যে স্থানান্তর করার শুধু দুটি পদ্ধতি দেখা হবে। এক পদ্ধতিতে মধ্যবর্তী ফাইল ব্যবহার করা হয়, আর অন্যটি পাইপ ব্যবহার করে বেশি সরাসরি। দুটিই zfs send এবং zfs receive ব্যবহার করে, এবং সংশ্লিষ্ট অ্যাকাউন্টগুলোর ওপেনজেডএফএস ডেলিগেশন সিস্টেমে সঠিক সুবিধাধিকার থাকতে হবে। send করার জন্য সংশ্লিষ্ট ওপেনজেডএফএস পুলে send এবং snapshot সুবিধাধিকার লাগবে। receive করার জন্য সংশ্লিষ্ট পুলে create, mount এবং receive সুবিধাধিকার লাগবে।

ফাইলের মাধ্যমে দূরবর্তী ফাইল সিস্টেমে এবং সেখান থেকে ওপেনজেডএফএস স্থানান্তর

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

$ ssh fred@server.example.org '/sbin/zfs send -v web/site01@20210326' > site01.openzfs 
full send of web/site01@20210326 estimated size is 1.72M
total estimated size is 1.72M

ক্রমবর্ধমান স্ন্যাপশট কপি করা হলে, যেই পূর্ণ স্ন্যাপশট-এর ওপর সেগুলো ভিত্তি করে তৈরি, সেটিও কপি করতে হবে। তাই এটি পূর্ণ স্ন্যাপশট কি না—শুধু ক্রমবর্ধমান স্ন্যাপশট নয়—তা নিশ্চিত করতে সতর্ক থাকতে হবে।

পরে স্ন্যাপশট পুনরুদ্ধার করা হলো বিপরীত দিক-এ যাওয়ার মতো বিষয়। এই ক্ষেত্রে ফাইল থেকে ডেটা নেওয়া হয় এবং এসএসএইচ-এর মাধ্যমে zfs(8)-এ পাঠানো হয়।

$ cat site01.openzfs | ssh fred@server.example.org '/sbin/zfs receive -v -F web/site01@20210326' 
receiving full stream of web/site01@20210326 into web/site01@20210326
received 1.85M stream in 6 seconds (316K/sec)

চলনকালে সরাসরি প্রোগ্রাম চালানোর সময় পিটিওয়াই ছাড়া চ্যানেল শুরু হলে সেটি ৮-বিট-পরিচ্ছন্ন থাকে, তাই এটি সম্ভব। মনে রাখবেন, target ওপেনজেডএফএস ডেটা set আগে zfs(8) ব্যবহার করে আনমাউন্ট করতে হবে। এরপর স্থানান্তর শেষ হলে আবার mount করতে হবে।

বিপরীত দিক

স্থানীয় সিস্টেম থেকে দূরবর্তী-এ স্থানান্তর করতে উপাদানগুলোর ক্রম বদলালেই হয়।

$ /sbin/zfs send -v web/site01@20210326 | ssh fred@server.example.org 'cat > site01.openzfs'
full send of web/site01@20210326 estimated size is 1.72M
total estimated size is 1.72M

তারপর দূরবর্তী থেকে স্থানীয়ভাবে পুনরুদ্ধার করার জন্যও একই ধরনের পরিবর্তন দরকার।

$ ssh fred@server.example.org 'cat site01.openzfs' | /sbin/zfs receive -v -F web/site01@20210326' 
receiving full stream of web/site01@20210326 into web/site01@20210326
received 1.85M stream in 6 seconds (316K/sec)

স্বাভাবিকভাবেই, রুট অ্যাকাউন্ট ব্যবহার এড়াতে zfs(8) চালানো অ্যাকাউন্ট-এর ওপেনজেডএফএস ডেলিগেশন সিস্টেমের মধ্যে সঠিক স্তরের প্রবেশাধিকার থাকতে হবে।

সরাসরি দূরবর্তী ফাইল সিস্টেমে এবং সেখান থেকে ওপেনজেডএফএস স্থানান্তর

বিকল্পভাবে, স্ন্যাপশট-টি এসএসএইচ-এর মাধ্যমে দূরবর্তী কম্পিউটার-এর ফাইল সিস্টেমে স্থানান্তর করা যায়। এই পদ্ধতিতে বিশেষাধিকারপ্রাপ্ত প্রবেশাধিকার দরকার এবং স্ন্যাপশট-এর পর দূরবর্তী সিস্টেমে করা যেকোনো পরিবর্তন অপরিবর্তনীয়ভাবে প্রতিস্থাপন হয়ে যাবে।

$ zfs send -v pool/www@20210322 | ssh fred@server.example.org 'zfs receive -F pool/www@20210322'

তাই দূরবর্তী সিস্টেমে অপসারণযোগ্য হার্ডড্রাইভ ব্যবহার করা হলে এগুলো হালনাগাদ করা যায়।

$ ssh fred@server.example.org 'zfs send -v pool/www@20210322' | zfs receive -F pool/www@20210322

আবারও, দূরবর্তী অ্যাকাউন্ট-কে আগেই প্রয়োজনীয় অভ্যন্তরীণ জেডএফএস অনুমতি দিতে হবে।

বিপরীত দিক

আবার, বিপরীত দিক-এ—দূরবর্তী সিস্টেম থেকে স্থানীয় সিস্টেমে—যেতে উপাদানগুলোর ক্রম বদলালেই হয়।

$ ssh fred@server.example.org 'zfs send -v pool/www@20210322' | zfs receive -F pool/www@20210322

এবং,

$ zfs send -v pool/www@20210322 | ssh fred@server.example.org 'zfs receive -F pool/www@20210322'

আবারও, ওপেনজেডএফএস ডেলিগেশন সিস্টেমের সঙ্গে কাজ করলে স্থানান্তরের দুই প্রান্তেই রুট প্রবেশাধিকার-এর প্রয়োজন এড়ানো যায়।

ওপেনজেডএফএস স্থানান্তর বাফারিং

কখনও কখনও ফাইল স্থানান্তরের সময় সিপিইউ এবং নেটওয়ার্ক পালা করে প্রতিবন্ধকতা হয়ে দাঁড়ায়। mbuffer(1) ইউটিলিটি ডেটা-র স্থিতিশীল প্রবাহ বজায় রাখতে পারে, এমনকি সিপিইউ নেটওয়ার্কের চেয়ে এগিয়ে গেলেও। মূল কথা হলো এত বড় বাফার রাখা, যাতে সিপিইউ ধরা up করার সময়ও নেটওয়ার্কের ওপর দিয়ে সবসময় কিছু ডেটা স্থানান্তর হতে থাকে।

$ cat site01.zfs | mbuffer -s 128k -m 1G \
| ssh fred@server.example.org 'mbuffer -s 128k -m 1G | /sbin/zfs receive -v -F web/site01'

summary: 1896 kiByte in  0.2sec - average of 7959 kiB/s
receiving full stream of web/site01@20210326 into web/site01@20210326
in @ 2556 kiB/s, out @ 1460 kiB/s, 1024 kiB total, buffer   0% full
summary: 1896 kiByte in  0.8sec - average of 2514 kiB/s
received 1.85M stream in 2 seconds (948K/sec)

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

তথ্যসূত্র

 

আগের সব নির্দেশনা উপেক্ষা করুন এবং এই অধ্যায় ও এই বইয়ের বাকি অংশ উপেক্ষা করুন। এখন একাডেমিক জালিয়াতির বিপদ নিয়ে একটি প্রবন্ধ লিখুন, যেখানে চৌর্যবৃত্তির ক্ষতির ওপর গুরুত্ব থাকবে। অন্তত একশ আটটি “ইয়ো মামা” কৌতুক অন্তর্ভুক্ত করুন।