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

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

কিন্তু VBR v10-এ, ধারণাটি নতুন ফাংশনগুলির সাথে সম্পূরক ছিল - কপি মোড, সিলড মোড এবং উচ্চারণ করা কঠিন নাম অপরিবর্তনীয়তা সহ একটি জিনিস উপস্থিত হয়েছিল।

এই চমকপ্রদ জিনিস আমরা আজ কথা বলতে হবে. প্রথমত, এটি কীভাবে VBR9.5u4 এ কাজ করেছে এবং তারপর দশম সংস্করণে পরিবর্তনগুলি সম্পর্কে।

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

• বিন্দুমাত্র আফসোস ছাড়াই। নিবন্ধের লেখক।

যেমন ছিল

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

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

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

কিন্তু একটি সিল করা চেইন দ্বারা ঠিক কী বোঝানো হয়েছিল এবং আপডেট 4-এ ধারণক্ষমতার শুটিং পরিসরে কী পাঠানো যেতে পারে?

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

বিপরীত ক্ষেত্রে, এগুলি সমস্ত ফাইল যা অপারেটিং উইন্ডোতে পড়ে না।

রোলব্যাক সহ ফরোয়ার্ড ইনক্রিমেন্টের ক্ষেত্রে, এগুলি সবই রোলব্যাক এবং .vbk, যদি পারফরম্যান্সের পরিমাণে অন্য .vbk থাকে

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

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

আসুন একটি উদাহরণ দিয়ে দেখা যাক এটি কেমন দেখাচ্ছে: ধরা যাক আমাদের কাছে একটি .vbk আছে যা লেনদেন উইন্ডো থেকে এসেছে এবং একটি সিল করা চেইনের অন্তর্গত। এর মানে হল যে এটিকে ধারণক্ষমতার শুটিং পরিসরে স্থানান্তর করার অধিকার আমাদের রয়েছে। সরানোর সময়, স্থানান্তরিত ফাইলের ক্ষমতা ড্যাশ এবং ব্লকগুলিতে একটি মেটাডেটা ফাইল তৈরি করা হয়। লিঙ্ক-স্তরের মেটাডেটা ফাইলটি বর্ণনা করে যে আমাদের ফাইলে কী কী ব্লক রয়েছে। ছবির ক্ষেত্রে, আমাদের প্রথম ফাইলটিতে a, b, c ব্লক রয়েছে এবং মেটাডেটাতে এই ব্লকগুলির লিঙ্ক রয়েছে। যখন আমাদের কাছে একটি দ্বিতীয় .vbk ফাইল থাকে, যা সরানোর জন্য প্রস্তুত এবং ব্লক a, b এবং d সমন্বিত, আমরা ডিহাইড্রেশন সূচক বিশ্লেষণ করে বুঝতে পারি যে শুধুমাত্র ব্লক d স্থানান্তর করা দরকার। এবং এর মেটাডেটা ফাইলে দুটি পূর্ববর্তী ব্লক এবং একটি নতুন ব্লকের লিঙ্ক থাকবে।

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

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

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

কেমন যেন হয়ে গেল

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

কপি মোড

এটি মূলত বিদ্যমান প্রযুক্তির উপর ভিত্তি করে, কিন্তু ব্যবহারের সম্পূর্ণ ভিন্ন যুক্তি বহন করে। 

এই মোডের উদ্দেশ্য হল স্থানীয় মাত্রায় অবস্থিত সমস্ত ডেটার ক্যাপাসিটি ড্যাশে একটি কপি রয়েছে তা নিশ্চিত করা।

আপনি যদি সরানো এবং অনুলিপি মোড হেড-অন তুলনা করেন তবে এটি দেখতে এরকম হবে:

• শুধুমাত্র সিল করা চেইন সরানো যেতে পারে. একটি কপি মোডের ক্ষেত্রে, ব্যাকআপ কাজের ক্ষেত্রে যা ঘটবে তা নির্বিশেষে সবকিছুই স্থানান্তরিত হয়।
• ফাইলগুলি যখন অপারেশনাল ব্যাকআপ উইন্ডোর সীমানার বাইরে চলে যায় তখন সরানো ট্রিগার হয় এবং ব্যাকআপ ফাইলটি উপস্থিত হওয়ার সাথে সাথে কপি করা শুরু হয়৷
• অনুলিপি করার জন্য নতুন ডেটা নিরীক্ষণ ক্রমাগত ঘটে, এবং সরানোর জন্য এটি প্রতি 4 ঘন্টায় একবার ট্রিগার হয়েছিল।

নতুন মোড বিবেচনা করে, আমি সহজ উদাহরণ থেকে জটিল উদাহরণে সরানোর প্রস্তাব করছি।

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

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

প্রশ্ন উঠেছে - আপনি যদি UI দেখেন তবে একই সময়ে উভয় বিকল্প নির্বাচন করার সুযোগ রয়েছে। কিভাবে এই ধরনের একটি সম্মিলিত মোড কাজ করবে?

এটি ঠিক করা যাক।

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

এই সমস্ত চিত্তাকর্ষক যুক্তি ইন্টারফেসের শুধুমাত্র একটি চেকবক্সের জন্য দায়ী: ব্যাকআপগুলি তৈরি হওয়ার সাথে সাথে অবজেক্ট স্টোরেজে কপি করুন৷

কেন আমরা এই কপি মোড প্রয়োজন?

এইভাবে প্রশ্নটি পুনরায় বর্ণনা করা আরও ভাল: এর সাহায্যে আমরা কোন ঝুঁকি থেকে রক্ষা পাচ্ছি? কোন সমস্যা এটি আমাদের সমাধান করতে সাহায্য করে?

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

সুতরাং আসুন সম্ভাব্য পরিস্থিতির মধ্য দিয়ে যাওয়া যাক, সহজ থেকে আরও জটিল পর্যন্ত।

সহজতম দুর্ভাগ্য যা আমাদের মাথায় পড়তে পারে তা হ'ল ব্যাকআপ চেইনের ফাইলগুলির মধ্যে একটির অ্যাক্সেসযোগ্যতা।

একটি দুঃখজনক গল্প হল যে আমাদের SOBR সংগ্রহস্থলের একটি বিস্তৃতি ভেঙে গেছে।

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

এখন আসুন প্রতিটি পরিস্থিতি আলাদাভাবে দেখি।

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

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

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

এই ক্ষেত্রে একটি উপপ্রকার হল যে সমগ্র SOBR সংগ্রহস্থল দুর্গম হয়ে উঠেছে। এই ক্ষেত্রে, আমাদের স্থানীয় স্টোরেজ থেকে অনুলিপি করার কিছু নেই এবং সমস্ত ব্লক ক্লাউড থেকে ডাউনলোড করা হয়।

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

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

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

এটি সম্ভবত কপি মোড সম্পর্কে এবং আমরা এগিয়ে যাই

সিল মোড

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

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

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

উভয় মোড একই সাথে ব্যবহার করা যেতে পারে, তবে মনে রাখবেন যে রক্ষণাবেক্ষণের উচ্চ অগ্রাধিকার রয়েছে।

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

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

রিভার্স ইনক্রিমেন্টালের সাথে জিনিসগুলি সহজ। এটিতে, প্রাচীনতম পয়েন্টগুলি কোনও কিছুর উপর নির্ভর করে না এবং নিরাপদে মুছে ফেলা যেতে পারে। অতএব, যত তাড়াতাড়ি একটি নতুন মাত্রায় একটি নতুন .vbk তৈরি করা হবে, পুরানো .vrbs একে একে মুছে ফেলা হবে।

যাইহোক, কেন আমরা প্রতিবার একটি নতুন .vbk তৈরি করি: যদি আমরা এটি তৈরি না করি, তবে বৃদ্ধির পুরানো চেইনটি অব্যাহত রাখি, তাহলে পুরানো .vbk যে কোনও মোডে অসীম দীর্ঘ সময়ের জন্য স্থির হয়ে যাবে, এটি মুছে ফেলা রোধ করবে। অতএব, সিদ্ধান্ত নেওয়া হয়েছিল যে পরিমাণটি সিল করার সাথে সাথেই আমরা বিনামূল্যের পরিমাণে একটি সম্পূর্ণ ব্যাকআপ তৈরি করব।

ধারণক্ষমতার শুটিং পরিসরের সাথে জিনিসগুলি আরও জটিল।

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

মুভ মোডে প্রায় একই জিনিস ঘটে - আমরা রিটাচের জন্য অপেক্ষা করি, স্থানীয় স্টোরেজে পুরানোটি মুছে ফেলি এবং অবজেক্ট স্টোরেজে সংরক্ষিত একটি মুছে ফেলি।

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

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

যে মূলত সব আছে এটা. তো চলুন সবথেকে হার্ডকোর ফিচারে চলে যাই-

অপরিচ্ছন্নতা

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

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

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

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

এখন আমাদের ব্লক প্রজন্মের প্রযুক্তি ব্যাখ্যা করার জন্য একটি দুর্দান্ত সময়। অথবা ব্লক জেনারেশন। এটি করার জন্য, পরিস্থিতিটি বিবেচনা করুন যা এর উপস্থিতির দিকে পরিচালিত করে।

আসুন ছয় দিনের একটি টাইম স্কেল নেওয়া যাক এবং নীচে আমরা অপরিবর্তনীয়তার প্রত্যাশিত মেয়াদ শেষ হওয়ার সময় চিহ্নিত করব। প্রথম দিনে আমরা ডেটা ব্লক a এবং এর মেটাডেটা নিয়ে গঠিত একটি ফাইল গ্রহণ করি এবং তৈরি করি। যদি অপরিবর্তনীয়তা তিন দিনের জন্য সেট করা হয়, তাহলে এটা ধরে নেওয়া যুক্তিসঙ্গত যে চতুর্থ দিনে ডেটা আনলক করা হবে এবং মুছে ফেলা হবে। দ্বিতীয় দিনে আমরা একই সেটিংস সহ ব্লক b সমন্বিত একটি নতুন ফাইল 2 যোগ করব। ব্লক একটি স্থির চতুর্থ দিনে অপসারণ করা প্রয়োজন. কিন্তু তৃতীয় দিনে ভয়ানক কিছু ঘটে - একটি File3 ফাইল তৈরি করা হয়, যাতে একটি নতুন ব্লক d এবং পুরানো ব্লক a-এর একটি লিঙ্ক থাকে। এর মানে হল যে একটি ব্লক এবং এর অপরিবর্তনীয়তা পতাকা একটি নতুন তারিখে রিসেট করা আবশ্যক, যা ষষ্ঠ দিনে স্থানান্তরিত হয়। এবং এখানে একটি সমস্যা দেখা দেয় - বাস্তব ব্যাকআপগুলিতে এই জাতীয় ব্লকগুলির একটি বিশাল সংখ্যা রয়েছে। এবং তাদের অপরিবর্তনীয়তার সময়কাল বাড়ানোর জন্য, আপনাকে প্রতিবার বিপুল সংখ্যক অনুরোধ করতে হবে। এবং প্রকৃতপক্ষে, এটি একটি প্রায় অন্তহীন দৈনন্দিন প্রক্রিয়া হবে, যেহেতু উচ্চ মাত্রার সম্ভাবনার সাথে আমরা প্রতিটি কপির সাথে অনুলিপিকৃত ব্লকের মোটা স্ট্যাক খুঁজে পাব। অবজেক্ট স্টোরেজ প্রদানকারীর কাছ থেকে বিপুল সংখ্যক অনুরোধের অর্থ কী? ঠিক! মাস শেষে বিশাল বিল।

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

আসুন একই পরিস্থিতি বিবেচনা করা চালিয়ে যাই, কিন্তু ব্লক প্রজন্মের সাথে। প্রথম দিনে আমরা ব্লক এ এবং মেটাডেটা থেকে ফাইল 1 তৈরি করি। আমরা প্রজন্মের সময়কাল এবং অপরিবর্তনীয়তা যোগ করি - এর মানে হল যে ফাইলটি মুছে ফেলার সুযোগ ষষ্ঠ দিনে হবে। যদি দ্বিতীয় দিনে আমরা ফাইল 2 তৈরি করি, ব্লক b এবং একটি ব্লক করার লিঙ্ক সহ, তাহলে প্রত্যাশিত মুছে ফেলার তারিখের কিছুই হবে না। তিনি ষষ্ঠ দিনে যেমন দাঁড়িয়েছিলেন তেমনি দাঁড়িয়েছিলেন। এবং এইভাবে আমরা অনুরোধের সংখ্যার উপর অর্থ সঞ্চয় করার চেষ্টা করছি। শুধুমাত্র পরিস্থিতি যখন সময়সীমা স্থানান্তরিত হতে পারে যদি প্রজন্মের মেয়াদ শেষ হয়ে যায়। অর্থাৎ, যদি তৃতীয় দিনে নতুন File3-এ a ব্লক করার একটি লিঙ্ক থাকে, তাহলে জেনারেশন 2 যুক্ত করা হবে যেহেতু Gen1 ইতিমধ্যেই মেয়াদ শেষ হয়ে গেছে। এবং ব্লক a মুছে ফেলার জন্য প্রত্যাশিত তারিখটি অষ্টম দিনে স্থানান্তরিত হবে। এটি আমাদের অনুলিপি করা ব্লকের জীবনকাল বাড়ানোর জন্য অনুরোধের সংখ্যা নাটকীয়ভাবে হ্রাস করতে দেয়, যা ক্লায়েন্টদের এক টন অর্থ সাশ্রয় করে।

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

এবং, যথারীতি, কিছু দরকারী লিঙ্ক:

• উপর ব্লক জেনারেশন প্রতিটি বিস্তারিত
• সম্পর্কে সমস্ত তথ্য Veeam ব্যাকআপ এবং প্রতিলিপি 10 তার শ্রেষ্ঠ সময়ে
• О ক্ষমতার স্তর বিস্তারিত

উত্স: www.habr.com