RPO বর্ণনা করে ডেটা-ক্ষতির উইন্ডো যা আপনি গ্রহণ করতে প্রস্তুত; RTO বর্ণনা করে যে বাধা আপনি লক্ষ্যের মধ্যে রাখতে চান। একটি উপযোগী ব্যবসায়িক ফাংশনের জন্য উভয়ই নির্ধারণ করুন, তারপর একটি অনুশীলনে পুনরুদ্ধার ক্রম প্রমাণ করুন। একটি ব্যাকআপ সময়সূচি বা একটি সার্ভার স্পেসিফিকেশন একা কোনও উদ্দেশ্য প্রতিষ্ঠা করে না।
এমন একটি পরিষেবা দিয়ে শুরু করুন যা মানুষ ব্যবহার করতে পারে
পুনরুদ্ধার উদ্দেশ্যগুলি উপযোগী হয় যখন তারা একটি বিচ্ছিন্ন মেশিনের পরিবর্তে একটি ব্যবসায়িক ফাংশন বর্ণনা করে। একটি সার্ভার বুট হতে পারে যখন গ্রাহকরা এখনও সাইন ইন করতে, ফাইল পুনরুদ্ধার করতে বা একটি অনুরোধ সম্পূর্ণ করতে পারে না। সাধারণ ভাষায় শেষ শর্তটি লিখুন: অনুমোদিত ব্যবহারকারীরা অ্যাপ্লিকেশনটি অ্যাক্সেস করতে পারেন এবং প্রয়োজনীয় ডেটা সামঞ্জস্যপূর্ণ। এটি লক্ষ্যটিকে অবকাঠামো দলের বাইরের কারও দ্বারা পরীক্ষাযোগ্য করে তোলে।
অ্যাপ্লিকেশনের মালিককে জিজ্ঞাসা করুন একটি বাধা কী প্রতিরোধ করবে এবং অনুপস্থিত ডেটার কী খরচ হবে। একটি সাপ্তাহিক প্রকাশনা এবং একটি লেনদেন-প্রক্রিয়াকরণ অ্যাপ্লিকেশনের ভিন্ন উত্তর থাকতে পারে। ফলস্বরূপ উদ্দেশ্যগুলিকে পরিকল্পনা লক্ষ্য হিসাবে বিবেচনা করুন, হার্ডওয়্যার ক্যাটালগ থেকে উদ্ভাবিত প্রতিশ্রুতি হিসাবে নয়। কে সেগুলি অনুমোদন করেছে এবং পরিকল্পনাটি কোন ব্যর্থতার পরিস্থিতি কভার করে তা রেকর্ড করুন।
দুটি ঘড়ি আলাদা করুন
RPO উদ্বেগ করে যে পুনরুদ্ধার করা ডেটা বিঘ্নের তুলনায় কতটা পিছনে যেতে পারে। RTO উদ্বেগ করে যে ফাংশনটি কতক্ষণ অনুপলব্ধ থাকতে পারে। একটি সাম্প্রতিক ব্যাকআপ ডেটা-ক্ষতির উইন্ডো উন্নত করতে পারে যখন একটি ধীর পুনরুদ্ধার এখনও পুনরুদ্ধার-সময় লক্ষ্য মিস করে। বিপরীতভাবে, একটি দ্রুত রিবুট একটি অ্যাপ্লিকেশনে অ্যাক্সেস পুনরুদ্ধার করতে পারে যার নতুন ডেটা টিকে নেইনি।
রেফারেন্স পয়েন্টগুলি নির্দিষ্ট করুন। ঘটনার ঘড়ি কখন শুরু হয়, কী পুনরুদ্ধার করা অপারেশন হিসাবে গণ্য হয় এবং ব্যবহারযোগ্য ডেটা পয়েন্ট কীভাবে চিহ্নিত করা হবে তা নির্ধারণ করুন। লক্ষ্যগুলিকে পরিমাপ করা ফলাফল থেকে আলাদা রাখুন: একটি উদ্দেশ্য যা আপনি চান; একটি অনুশীলন দেখায় বর্তমান প্রক্রিয়া কী অর্জন করেছে। অ্যাপ্লিকেশন বা ডেটাসেট পরিবর্তিত হলে যেকোনোটিই পুনর্বিবেচনা করুন।
পুনরুদ্ধারের প্রতিটি ধাপে বাজেট করুন
একটি ব্যবহারিক RTO বাজেটে সনাক্তকরণ, মূল্যায়ন, অনুমোদন, পুনরুদ্ধার পরিবেশে অ্যাক্সেস, পুনরুদ্ধার, অ্যাপ্লিকেশন যাচাইকরণ এবং পুনরায় খোলা অন্তর্ভুক্ত। ফাইল-কপি সময় শুধুমাত্র একটি উপাদান। যদি পুনরুদ্ধার কী ধারণকারী ব্যক্তি অনুপলব্ধ থাকে, একটি তাত্ত্বিকভাবে দ্রুত ব্যাকআপ এখনও অব্যবহারযোগ্য হতে পারে। নির্ভরতাগুলি তালিকাভুক্ত করুন এবং নিশ্চিত করুন যে পুনরুদ্ধার দল বিবেচিত ব্যর্থতার সময় সেগুলিতে পৌঁছাতে পারে।
প্রতিটি ধাপে একটি অস্থায়ী সময় নির্ধারণ করুন, তারপর অনুমানগুলি পর্যবেক্ষণ দিয়ে প্রতিস্থাপন করুন। এই উদাহরণস্বরূপ দুই ঘন্টার বাজেটে, পুনরুদ্ধার সবচেয়ে বড় ভাতা পায় কিন্তু যাচাইকরণের এখনও সুরক্ষিত সময় থাকে। সংখ্যাগুলি একটি পরিকল্পনা উদাহরণ বর্ণনা করে, SwissOctet পরিষেবা সরবরাহ নয়। যদি মোটের কোনও মার্জিন না থাকে, উদ্দেশ্যটি বিশ্বাসযোগ্য হওয়ার আগে ডিজাইনের উন্নতি প্রয়োজন।
| পুনরুদ্ধার ধাপ | উদাহরণস্বরূপ ভাতা | সংগ্রহ করার প্রমাণ |
|---|---|---|
| সনাক্ত এবং মূল্যায়ন | 15 মিনিট | সতর্কতা আগমন এবং ঘটনা সিদ্ধান্ত |
| পুনরুদ্ধার পরিবেশ প্রস্তুত করুন | 20 মিনিট | অ্যাক্সেস এবং কনফিগারেশন উপলব্ধ |
| ডেটা এবং পরিষেবা পুনরুদ্ধার করুন | 50 মিনিট | সামঞ্জস্যপূর্ণ ডেটা সহ সম্পূর্ণ পুনরুদ্ধার |
| যাচাই করুন এবং পুনরায় খুলুন | 25 মিনিট | ব্যবহারকারী যাত্রা সফল |
| আকস্মিক মার্জিন | 10 মিনিট | অপ্রত্যাশিত কাজ রেকর্ড করা |
প্রকৃত ডেটা-ক্ষতির উইন্ডো পরীক্ষা করুন
প্রতি ঘন্টায় নির্ধারিত একটি কাজ স্বয়ংক্রিয়ভাবে এক ঘন্টার RPO প্রদান করে না। একটি ব্যর্থ কাজ, বিলম্বিত আপলোড বা অব্যবহারযোগ্য অনুলিপি সর্বশেষ পুনরুদ্ধারযোগ্য পয়েন্টকে অনেক পুরানো করে তুলতে পারে। সফল সমাপ্তি এবং যে অবস্থাটি প্রকৃতপক্ষে পুনরুদ্ধার করা যায় তা পর্যবেক্ষণ করুন। বেশ কয়েকটি ডেটা স্টোর সহ একটি অ্যাপ্লিকেশনের জন্য, প্রতিটি টাইমস্ট্যাম্প আলাদাভাবে পড়ার পরিবর্তে তাদের পুনরুদ্ধার পয়েন্টগুলি সামঞ্জস্যপূর্ণ কিনা তা নিশ্চিত করুন।
একটি অনুশীলনের সময় একটি রেফারেন্স ইভেন্ট বেছে নিন, যেমন একটি পরিচিত সময়ে তৈরি একটি অনুমোদিত পরীক্ষামূলক রেকর্ড। পুনরুদ্ধারের পরে, নতুন বৈধ রেকর্ডটি চিহ্নিত করুন এবং ব্যবধান পরিমাপ করুন। নিরীহ পরীক্ষামূলক ডেটা ব্যবহার করুন। এটি একটি ব্যবহারিক ফলাফল দেয় এবং এমন অনুমান প্রকাশ করে যা শুধুমাত্র কাজের সাফল্য দেখানো একটি ড্যাশবোর্ড লুকিয়ে রাখতে পারে।
বাজেটের মধ্যে একটি কৌশল বেছে নিন
ব্যাকআপ-এবং-পুনরুদ্ধার, প্রস্তুত স্ট্যান্ডবাই পরিবেশ এবং প্রতিলিপিকৃত অ্যাপ্লিকেশন ডিজাইন পুনরুদ্ধারের গতির বিরুদ্ধে খরচ এবং জটিলতা বিনিময় করে। প্রতিলিপি কিছু বিলম্ব কমাতে পারে কিন্তু একটি দুর্ঘটনাজনিত মুছে ফেলা বা অ্যাপ্লিকেশন ভুলও পুনরুত্পাদন করতে পারে। একটি স্ট্যান্ডবাই যা কার্যকরী কনফিগারেশন থেকে বিচ্যুত হয়েছে নিজস্ব ঝুঁকি তৈরি করে। আপনি যে ব্যর্থতার পরিস্থিতি এবং উদ্দেশ্যগুলি নথিভুক্ত করেছেন তার বিরুদ্ধে একটি কৌশল নির্বাচন করুন।
একটি ছোট পরিষেবা বিবেচনা করুন যার চার ঘন্টার লক্ষ্য এবং একটি বড় ডেটাসেট যার পুনরুদ্ধার একা একটি অনুশীলনে ছয় ঘন্টা সময় নেয়। একটি দ্রুত নেটওয়ার্ক পোর্ট কেনা শুধুমাত্র একটি অনুমান: স্টোরেজ রিড, রিসিভিং রাইট এবং অ্যাপ্লিকেশন পুনরুদ্ধার প্রাধান্য পেতে পারে। পরিমাপ করা সীমাবদ্ধ ধাপটি উন্নত করুন, পুনরুদ্ধার সেট হ্রাস করুন বা কৌশল পরিবর্তন করুন, তারপর আবার অনুশীলন করুন।
উৎপাদনকে বিপন্ন না করে অনুশীলন করুন
একটি বিচ্ছিন্ন পুনরুদ্ধার পরিবেশ এবং একটি নির্ধারিত অনুশীলন উইন্ডো ব্যবহার করুন। নিশ্চিত করুন যে পুনরুদ্ধার করা কাজগুলি প্রকৃত বিজ্ঞপ্তি পাঠাতে, পাবলিক পেমেন্ট গ্রহণ করতে বা উৎপাদন ইন্টিগ্রেশনে লিখতে পারে না। অনুশীলনটি সম্পূর্ণ বিবেচনা করার আগে অ্যাক্সেস, ডেটা অখণ্ডতা এবং প্রতিনিধি ব্যবহারকারী যাত্রা পরীক্ষা করুন। মূল পদ্ধতি লিখেনি এমন একজন ব্যক্তিকে অন্তর্ভুক্ত করুন যাতে অনুপস্থিত নির্দেশাবলী প্রকাশ পায়।
অনুশীলনের একটি টাইমলাইন, অর্জিত পুনরুদ্ধার পয়েন্ট এবং অনুপলব্ধ তথ্যের কারণে সৃষ্ট প্রতিটি বাধা রাখুন। একটি উপযোগী প্রতিবেদন পরিমাপ করা ফলাফল, উদ্দেশ্যের সাথে ব্যবধান এবং একটি নির্দিষ্ট সংশোধনমূলক পদক্ষেপ বর্ণনা করে। অর্থপূর্ণ পরিবর্তনের পরে এবং প্রকল্পের গুরুত্বের সাথে উপযুক্ত একটি ব্যবধানে পুনরাবৃত্তি করুন।
ব্যর্থতার সময় পরিকল্পনাটি ব্যবহারযোগ্য রাখুন
পুনরুদ্ধার পদ্ধতিটি যেখানে দলটি শুধুমাত্র ব্যর্থ অ্যাপ্লিকেশনের উপর নির্ভর না করে অ্যাক্সেস করতে পারে সেখানে সংরক্ষণ করুন। ক্রেডেনশিয়াল এবং এনক্রিপশন কী একটি সুরক্ষিত স্থানে একটি পরীক্ষিত অ্যাক্সেস প্রক্রিয়া সহ রাখুন। প্রকল্প বিকশিত হওয়ার সাথে সাথে পরিচিতি, ডেটাসেট আকার এবং নির্ভরতা আপডেট করুন। একটি অপ্রচলিত পরিকল্পনা পুনরুদ্ধার শুরু হওয়ার আগেই সময়ের মার্জিন গ্রাস করতে পারে।
SwissOctet কনফিগারেশন তুলনা করার সময়, আপনার পুনরুদ্ধার আর্কিটেকচারকে ক্যাটালগের ঐচ্ছিক ব্যাকআপ পছন্দ থেকে আলাদা করুন। একটি বিকল্প কী কভার করে, পুনরুদ্ধার ডেটা কোথায় রাখা হয় এবং কে পুনরুদ্ধার করে তা নিশ্চিত করুন। ক্যাটালগ একটি অ্যাপ্লিকেশন RPO বা RTO প্রতিষ্ঠা করে না। আপনার পরিমাপ করা প্রক্রিয়া এবং প্রকৃত পরিষেবা শর্তাবলী সেই সিদ্ধান্তের ভিত্তি প্রদান করে।
আপনার ব্যবহারিক চেকলিস্ট।
- পুনরুদ্ধার করা ব্যবসায়িক ফাংশন নির্ধারণ করুন।
- আলাদা RPO এবং RTO লক্ষ্য অনুমোদন করুন।
- সনাক্তকরণ, অ্যাক্সেস, পুনরুদ্ধার এবং যাচাইকরণে বাজেট করুন।
- সর্বশেষ ব্যবহারযোগ্য ডেটা পয়েন্ট পরিমাপ করুন।
- একটি বিচ্ছিন্ন পরিবেশে অনুশীলন করুন।
- ব্যবধান রেকর্ড করুন এবং প্রাসঙ্গিক পরিবর্তনের পরে পুনরাবৃত্তি করুন।
যে বিবরণগুলো গুরুত্বপূর্ণ।
RTO কি আপটাইমের সমান?+
না। RTO একটি বাধা পরিস্থিতির জন্য একটি পুনরুদ্ধার লক্ষ্য। আপটাইম একটি সময়কাল ধরে প্রাপ্যতা পরিমাপ করে; একটি অন্যটি প্রতিষ্ঠা করে না।
প্রতি ঘন্টায় ব্যাকআপ কি এক ঘন্টার RPO নিশ্চিত করে?+
না। সম্পূর্ণ, ব্যবহারযোগ্য অনুলিপি এবং অ্যাপ্লিকেশনের সামঞ্জস্যতার প্রয়োজনীয়তা পরীক্ষা করুন। ব্যর্থ কাজ এবং বিলম্বিত স্থানান্তর পুনরুদ্ধারযোগ্য-ডেটা ব্যবধান প্রশস্ত করতে পারে।
প্রতিটি প্রকল্পকে কি একটি স্ট্যান্ডবাই সার্ভার ব্যবহার করতে হবে?+
প্রকল্পের পুনরুদ্ধার উদ্দেশ্য এবং পরিমাপ করা পুনরুদ্ধার প্রক্রিয়ার বিরুদ্ধে একটি কৌশল বেছে নিন। একটি স্ট্যান্ডবাই খরচ এবং পরিচালনাগত জটিলতা যোগ করে এবং স্বয়ংক্রিয়ভাবে প্রয়োজনীয় নয়।
সূত্রে যান।
এই রেফারেন্সগুলি এই গাইডের প্রযুক্তিগত ধারণাগুলি সমর্থন করে। একটি উৎপাদন সিস্টেম পরিবর্তন করার আগে বর্তমান ডকুমেন্টেশন অনুসরণ করুন।
- NIST SP 800-34 Rev. 1: কন্টিনজেন্সি প্ল্যানিং গাইড nvlpubs.nist.gov
- AWS Well-Architected: পুনরুদ্ধার উদ্দেশ্য নির্ধারণ করুন docs.aws.amazon.com
- Microsoft Learn: ব্যবসায়িক ধারাবাহিকতা, উচ্চ প্রাপ্যতা এবং দুর্যোগ পুনরুদ্ধার learn.microsoft.com
SwissOctet দ্বারা সম্পাদকীয় নির্দেশনা। উদাহরণগুলি উদাহরণমূলক। সেবা স্পেসিফিকেশন, উপলব্ধ অপশন এবং চুক্তিভিত্তিক শর্তগুলি আলাদাভাবে যাচাই করতে হবে।