ব্যাকআপ, পার্ট 1: উদ্দেশ্য, পদ্ধতি এবং প্রযুক্তির পর্যালোচনা

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

একটি আদর্শ প্রোগ্রাম দ্রুত চলে, মেমরি ফাঁস করে না, কোন ছিদ্র নেই এবং এর অস্তিত্ব নেই।

-অজানা

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

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

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

ভালো শিল্পীরা কপি করে, বড় শিল্পীরা চুরি করে।

-পাবলো পিকাসো.

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

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

যদি আমি জানতাম তুমি কোথায় পড়বে, আমি খড় বিছিয়ে দিতাম!

-বেলারুশিয়ান লোক প্রবাদ

এর মানে হল যে ব্যাকআপ কপিগুলি তাদের জন্য অত্যাবশ্যক যারা:

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

এখানে একটি সামান্য তত্ত্ব আছে

কোন শ্রেণীবিভাগ নির্বিচারে হয়. প্রকৃতি শ্রেণীবদ্ধ করে না। আমরা শ্রেণীবদ্ধ করি কারণ এটি আমাদের জন্য আরও সুবিধাজনক। এবং আমরা ডেটা অনুসারে শ্রেণিবদ্ধ করি যা আমরা নির্বিচারে গ্রহণ করি।

- জিন ব্রুলার

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

ব্লক ডেটা স্টোরেজ বোঝায় যে একটি শারীরিক ডিভাইস রয়েছে যেখানে ডেটা নির্দিষ্ট নির্দিষ্ট অংশে, ব্লকগুলিতে লেখা হয়। ব্লকগুলি একটি নির্দিষ্ট ঠিকানায় অ্যাক্সেস করা হয়; ডিভাইসের মধ্যে প্রতিটি ব্লকের নিজস্ব ঠিকানা রয়েছে।

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

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

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

এটি ফাইল স্টোরেজ থেকে আলাদা যে এটিতে একাধিক নেস্টিং (ফ্ল্যাট স্কিম) নেই এবং ফাইলের নামগুলি, যদিও মানুষ-পাঠযোগ্য, তবুও মেশিন দ্বারা প্রক্রিয়াকরণের জন্য আরও উপযুক্ত। ব্যাকআপ করার সময়, অবজেক্ট স্টোরেজকে প্রায়শই ফাইল স্টোরেজের মতোই বিবেচনা করা হয়, তবে মাঝে মাঝে অন্যান্য বিকল্প রয়েছে।

— দুই ধরনের সিস্টেম অ্যাডমিনিস্ট্রেটর আছে, যারা ব্যাকআপ করে না এবং যারা আগে থেকেই করে।
- প্রকৃতপক্ষে, তিনটি প্রকার রয়েছে: এমনও আছেন যারা চেক করেন যে ব্যাকআপগুলি পুনরুদ্ধার করা যেতে পারে।

-অজানা

এটিও বোঝার মতো যে ডেটা ব্যাকআপ প্রক্রিয়া নিজেই প্রোগ্রামগুলি দ্বারা সঞ্চালিত হয়, তাই এটির অন্য কোনও প্রোগ্রামের মতো একই অসুবিধা রয়েছে। মানব ফ্যাক্টরের উপর নির্ভরতা দূর করা (বাদ দেওয়া নয়!) সেইসাথে বৈশিষ্ট্যগুলি - যা পৃথকভাবে একটি শক্তিশালী প্রভাব ফেলে না, তবে একসাথে একটি লক্ষণীয় প্রভাব দিতে পারে - তথাকথিত নিয়ম 3-2-1। এটি কীভাবে পাঠোদ্ধার করতে হয় তার জন্য অনেকগুলি বিকল্প রয়েছে, তবে আমি নিম্নলিখিত ব্যাখ্যাটি আরও ভাল পছন্দ করি: একই ডেটার 3 সেট অবশ্যই সংরক্ষণ করতে হবে, 2 সেট অবশ্যই বিভিন্ন ফর্ম্যাটে সংরক্ষণ করতে হবে এবং 1 সেট অবশ্যই একটি ভৌগলিকভাবে দূরবর্তী স্টোরেজে সংরক্ষণ করতে হবে৷

স্টোরেজ বিন্যাস নিম্নলিখিত হিসাবে বোঝা উচিত:

• যদি ফিজিক্যাল স্টোরেজ পদ্ধতির উপর নির্ভরতা থাকে, আমরা ভৌত পদ্ধতি পরিবর্তন করি।
• লজিক্যাল স্টোরেজ পদ্ধতির উপর নির্ভরতা থাকলে, আমরা লজিক্যাল পদ্ধতি পরিবর্তন করি।

3-2-1 নিয়মের সর্বাধিক প্রভাব অর্জন করতে, উভয় উপায়ে স্টোরেজ বিন্যাস পরিবর্তন করার সুপারিশ করা হয়।

একটি ব্যাকআপ এর উদ্দিষ্ট উদ্দেশ্যের জন্য প্রস্তুতির দৃষ্টিকোণ থেকে - কার্যকারিতা পুনরুদ্ধার করা - "গরম" এবং "ঠান্ডা" ব্যাকআপগুলির মধ্যে একটি পার্থক্য তৈরি করা হয়েছে। গরমগুলি কেবলমাত্র একটি জিনিসের মধ্যে ঠান্ডাগুলির থেকে পৃথক: তারা অবিলম্বে ব্যবহারের জন্য প্রস্তুত, যখন ঠান্ডাগুলির পুনরুদ্ধারের জন্য কিছু অতিরিক্ত পদক্ষেপের প্রয়োজন: ডিক্রিপশন, সংরক্ষণাগার থেকে নিষ্কাশন ইত্যাদি।

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

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

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

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

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

ipsos কাস্টোড কি হেফাজত করতে পারেন?

(প্রহরীকে নিজেরা পাহারা দেবে কে? - ল্যাট।)

ব্যাকআপ কপি না থাকলে এটা খুবই অপ্রীতিকর, কিন্তু ব্যাকআপ কপি তৈরি করা হয়েছে বলে মনে হলে এটি আরও খারাপ, কিন্তু পুনরুদ্ধার করার সময় দেখা যাচ্ছে যে এটি পুনরুদ্ধার করা যাবে না কারণ:

• উৎস তথ্যের অখণ্ডতা আপস করা হয়েছে.
• ব্যাকআপ স্টোরেজ ক্ষতিগ্রস্ত হয়েছে।
• পুনরুদ্ধার খুব ধীরে কাজ করে; আপনি আংশিকভাবে পুনরুদ্ধার করা ডেটা ব্যবহার করতে পারবেন না।

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

উৎস তথ্যের অখণ্ডতা বিভিন্ন উপায়ে নিশ্চিত করা যেতে পারে। সর্বাধিক ব্যবহৃত নিম্নলিখিতগুলি হল: ক) ব্লক স্তরে ফাইল সিস্টেমের স্ন্যাপশট তৈরি করা, খ) ফাইল সিস্টেমের অবস্থা "হিমায়িত করা", গ) সংস্করণ স্টোরেজ সহ একটি বিশেষ ব্লক ডিভাইস, ঘ) ফাইলগুলির অনুক্রমিক রেকর্ডিং বা ব্লক পুনরুদ্ধারের সময় ডেটা যাচাই করা নিশ্চিত করতে চেকসামগুলিও প্রয়োগ করা হয়।

চেকসাম ব্যবহার করে স্টোরেজ দুর্নীতিও সনাক্ত করা যেতে পারে। একটি অতিরিক্ত পদ্ধতি হ'ল বিশেষ ডিভাইস বা ফাইল সিস্টেমের ব্যবহার যেখানে ইতিমধ্যে রেকর্ড করা ডেটা পরিবর্তন করা যায় না, তবে নতুন যুক্ত করা যেতে পারে।

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

মশলা বিশেষজ্ঞ সেই ব্যক্তি নন যিনি প্রতিটি খাবারে এগুলি যোগ করেন, তবে যিনি কখনও অতিরিক্ত কিছু যোগ করেন না।

-ভিতরে. সিনিয়াভস্কি

সিস্টেম অ্যাডমিনিস্ট্রেটরদের দ্বারা ব্যবহৃত সফ্টওয়্যার সম্পর্কিত অনুশীলনগুলি পরিবর্তিত হতে পারে, তবে সাধারণ নীতিগুলি এখনও, এক বা অন্যভাবে, একই, বিশেষ করে:

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

ব্লক ডিভাইস থেকে ব্যাকআপ নেওয়ার জন্য নিম্নলিখিত সাধারণ প্রোগ্রাম আছে:

• dd, সিস্টেম অ্যাডমিনিস্ট্রেশন ভেটেরান্সদের সাথে পরিচিত, এটিতে অনুরূপ প্রোগ্রামও রয়েছে (উদাহরণস্বরূপ একই dd_rescue)।
• কিছু ফাইল সিস্টেমে তৈরি ইউটিলিটি যা ফাইল সিস্টেমের ডাম্প তৈরি করে।
• সর্বভুক উপযোগিতা; উদাহরণস্বরূপ partclone.
• নিজস্ব, প্রায়ই মালিকানা, সিদ্ধান্ত; উদাহরণস্বরূপ, NortonGhost এবং পরে।

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

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

ব্যাকআপ কপি তৈরি করার সময় ডেটা সামঞ্জস্য নিশ্চিত করার জন্য সফ্টওয়্যার সরঞ্জামগুলি সম্পর্কে আলাদাভাবে উল্লেখ করা উচিত। সর্বাধিক ব্যবহৃত বিকল্পগুলি হল:

• শুধুমাত্র-পঠন মোডে ফাইল সিস্টেম মাউন্ট করা (Only), অথবা ফাইল সিস্টেম ফ্রিজ করা (ফ্রিজ) - পদ্ধতিটি সীমিত প্রযোজ্য।
• ফাইল সিস্টেম বা ব্লক ডিভাইসের (LVM, ZFS) অবস্থার স্ন্যাপশট তৈরি করা।
• ইমপ্রেশনগুলি সংগঠিত করার জন্য তৃতীয় পক্ষের সরঞ্জামগুলির ব্যবহার, এমনকি এমন ক্ষেত্রে যেখানে পূর্ববর্তী পয়েন্টগুলি কোনও কারণে প্রদান করা যায় না (হটকপির মতো প্রোগ্রাম)।
• কপি-অন-চেঞ্জ কৌশল (CopyOnWrite), তবে, এটি প্রায়শই ব্যবহৃত ফাইল সিস্টেমের সাথে সংযুক্ত থাকে (BTRFS, ZFS)।

সুতরাং, একটি ছোট সার্ভারের জন্য আপনাকে একটি ব্যাকআপ স্কিম প্রদান করতে হবে যা নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ করে:

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

যারা কমবেশি প্রয়োজনীয়তা পূরণ করে তাদের থেকে আবেদনকারী:

• rdiff-ব্যাকআপ
• rsnapshot
• বারপ
• নকল
• ছলনা
• চুপ করুক
• দার
• zbackup
• অস্থির
• borgbackup

নিম্নলিখিত বৈশিষ্ট্য সহ একটি ভার্চুয়াল মেশিন (জেনসার্ভারের উপর ভিত্তি করে) একটি পরীক্ষা বেঞ্চ হিসাবে ব্যবহার করা হবে:

• 4 কোর 2.5 GHz,
• 16 জিবি র‍্যাম,
• 50 জিবি হাইব্রিড স্টোরেজ (ভার্চুয়াল ডিস্কের আকারের 20% SSD-তে ক্যাশিং সহ স্টোরেজ সিস্টেম) পার্টিশন ছাড়াই একটি পৃথক ভার্চুয়াল ডিস্ক আকারে,
• 200 Mbps ইন্টারনেট চ্যানেল।

প্রায় একই মেশিন একটি ব্যাকআপ রিসিভার সার্ভার হিসাবে ব্যবহার করা হবে, শুধুমাত্র একটি 500 GB হার্ড ড্রাইভ সহ।

অপারেটিং সিস্টেম - Centos 7 x64: স্ট্যান্ডার্ড পার্টিশন, অতিরিক্ত পার্টিশন ডাটা সোর্স হিসেবে ব্যবহার করা হবে।

প্রাথমিক তথ্য হিসাবে, চলুন 40 গিগাবাইট মিডিয়া ফাইল এবং একটি mysql ডাটাবেস সহ একটি ওয়ার্ডপ্রেস সাইট নেওয়া যাক। যেহেতু ভার্চুয়াল সার্ভারগুলি বৈশিষ্ট্যে ব্যাপকভাবে পরিবর্তিত হয়, এবং আরও ভাল প্রজননযোগ্যতার জন্য, এখানে

sysbench ব্যবহার করে সার্ভার পরীক্ষার ফলাফল।sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu রান
sysbench 1.1.0-18a9f86 (বান্ডেলড LuaJIT 2.1.0-beta3 ব্যবহার করে)
নিম্নলিখিত বিকল্পগুলির সাথে পরীক্ষা চালানো:
থ্রেডের সংখ্যা: 4
বর্তমান সময় থেকে র্যান্ডম নম্বর জেনারেটর শুরু করা হচ্ছে

মৌলিক সংখ্যার সীমা: 20000

কর্মী থ্রেড শুরু করা হচ্ছে...

থ্রেড শুরু!

সিপিইউ গতি:
প্রতি সেকেন্ডে ইভেন্ট: 836.69

থ্রুপুট:
ঘটনা/s (eps): 836.6908
সময় অতিবাহিত: 30.0039s
ইভেন্টের মোট সংখ্যা: 25104

বিলম্ব (ms):
মিনিট: 2.38
গড়: 4.78
সর্বোচ্চ: 22.39
95 তম পার্সেন্টাইল: 10.46
যোগফল: 119923.64

সুতা সুতা:
ইভেন্ট (এভিজি/এসটিডিডেভ): 6276.0000/13.91
সঞ্চালনের সময় (এভিজি/এসটিডিডেভ): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.1.0-18a9f86 (বান্ডেলড LuaJIT 2.1.0-beta3 ব্যবহার করে)
নিম্নলিখিত বিকল্পগুলির সাথে পরীক্ষা চালানো:
থ্রেডের সংখ্যা: 4
বর্তমান সময় থেকে র্যান্ডম নম্বর জেনারেটর শুরু করা হচ্ছে

নিম্নলিখিত বিকল্পগুলির সাথে মেমরি গতি পরীক্ষা চলছে:
ব্লকের আকার: 1KiB
মোট আকার: 102400MiB
অপারেশন: পড়া
সুযোগ: বিশ্বব্যাপী

কর্মী থ্রেড শুরু করা হচ্ছে...

থ্রেড শুরু!

মোট অপারেশন: 50900446 (1696677.10 প্রতি সেকেন্ড)

49707.47 MiB স্থানান্তরিত (1656.91 MiB/সেকেন্ড)

থ্রুপুট:
ঘটনা/s (eps): 1696677.1017
সময় অতিবাহিত: 30.0001s
ইভেন্টের মোট সংখ্যা: 50900446

বিলম্ব (ms):
মিনিট: 0.00
গড়: 0.00
সর্বোচ্চ: 24.01
95 তম পার্সেন্টাইল: 0.00
যোগফল: 39106.74

সুতা সুতা:
ইভেন্ট (এভিজি/এসটিডিডেভ): 12725111.5000/137775.15
সঞ্চালনের সময় (এভিজি/এসটিডিডেভ): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (বান্ডেলড LuaJIT 2.1.0-beta3 ব্যবহার করে)
নিম্নলিখিত বিকল্পগুলির সাথে পরীক্ষা চালানো:
থ্রেডের সংখ্যা: 4
বর্তমান সময় থেকে র্যান্ডম নম্বর জেনারেটর শুরু করা হচ্ছে

নিম্নলিখিত বিকল্পগুলির সাথে মেমরি গতি পরীক্ষা চলছে:
ব্লকের আকার: 1KiB
মোট আকার: 102400MiB
অপারেশন: লিখুন
সুযোগ: বিশ্বব্যাপী

কর্মী থ্রেড শুরু করা হচ্ছে...

থ্রেড শুরু!

মোট অপারেশন: 35910413 (1197008.62 প্রতি সেকেন্ড)

35068.76 MiB স্থানান্তরিত (1168.95 MiB/সেকেন্ড)

থ্রুপুট:
ঘটনা/s (eps): 1197008.6179
সময় অতিবাহিত: 30.0001s
ইভেন্টের মোট সংখ্যা: 35910413

বিলম্ব (ms):
মিনিট: 0.00
গড়: 0.00
সর্বোচ্চ: 16.90
95 তম পার্সেন্টাইল: 0.00
যোগফল: 43604.83

সুতা সুতা:
ইভেন্ট (এভিজি/এসটিডিডেভ): 8977603.2500/233905.84
সঞ্চালনের সময় (এভিজি/এসটিডিডেভ): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G ফাইলিও রান
sysbench 1.1.0-18a9f86 (বান্ডেলড LuaJIT 2.1.0-beta3 ব্যবহার করে)
নিম্নলিখিত বিকল্পগুলির সাথে পরীক্ষা চালানো:
থ্রেডের সংখ্যা: 4
বর্তমান সময় থেকে র্যান্ডম নম্বর জেনারেটর শুরু করা হচ্ছে

অতিরিক্ত ফাইল খোলা পতাকা: (কোনও নয়)
128টি ফাইল, 8MiB প্রতিটি
1GiB মোট ফাইলের আকার
ব্লক সাইজ 4KiB
IO অনুরোধের সংখ্যা: 0
সম্মিলিত র্যান্ডম IO পরীক্ষার জন্য পড়ুন/লিখুন অনুপাত: 1.50
পর্যায়ক্রমিক FSYNC সক্ষম, প্রতিটি 100টি অনুরোধ fsync() কল করে।
পরীক্ষার শেষে fsync() কল করা, সক্রিয়।
সিঙ্ক্রোনাস I/O মোড ব্যবহার করে
র্যান্ডম r/w পরীক্ষা করছেন
কর্মী থ্রেড শুরু করা হচ্ছে...

থ্রেড শুরু!

থ্রুপুট:
পড়ুন: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
লিখুন: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

বিলম্ব (ms):
মিনিট: 0.00
গড়: 0.27
সর্বোচ্চ: 18.01
95 তম পার্সেন্টাইল: 1.08
যোগফল: 238469.45

এই নোট একটি বড় শুরু

ব্যাকআপ সম্পর্কে নিবন্ধের সিরিজ

1. ব্যাকআপ, পার্ট 1: কেন ব্যাকআপ প্রয়োজন, পদ্ধতি, প্রযুক্তি পর্যালোচনা
2. ব্যাকআপ পার্ট 2: rsync-ভিত্তিক ব্যাকআপ টুল পর্যালোচনা এবং পরীক্ষা করা
3. ব্যাকআপ পার্ট 3: ডুপ্লিসিটি, ডুপ্লিসিটি, ডেজা ডুপ পর্যালোচনা এবং পরীক্ষা করা
4. ব্যাকআপ পার্ট 4: Zbackup, restic, borgbackup পর্যালোচনা এবং পরীক্ষা
5. ব্যাকআপ, পার্ট 5: লিনাক্সের জন্য ব্যাকুলা এবং ভিম ব্যাকআপ পরীক্ষা করা
6. ব্যাকআপ পার্ট 6: ব্যাকআপ টুলের তুলনা
7. ব্যাকআপ পার্ট 7: উপসংহার

উত্স: www.habr.com