RTO और RPO तय करें और जाँचें

दो अलग objectives तय करें

Recovery Time Objective (RTO) उपयोगी service लौटने से पहले अधिकतम स्वीकार्य interruption तय करता है। Recovery Point Objective (RPO) समय के रूप में अधिकतम स्वीकार्य data loss तय करता है। तय service और failure scenario के लिए business के जिम्मेदार व्यक्ति से इन objectives पर सहमति लें।

Availability target किसी अवधि में service की performance बताता है। RTO और RPO recovery की अपेक्षाएँ बताते हैं। वे अलग प्रश्नों के उत्तर देते हैं।

काल्पनिक ordering service के लिए जिम्मेदार व्यक्ति RTO 60 मिनट और RPO 15 मिनट तय करता है। ये उदाहरण के values हैं, सामान्य सुझाव नहीं। दूसरी service को अलग सीमाएँ चाहिए हो सकती हैं, क्योंकि छूटे orders और देर से मिली reports का असर अलग है।

पूरी recovery मापें

Service 10:00 पर रुकती है। Team इस अभ्यास का record रखती है:

कुल recovery time 55 मिनट है। अभ्यास 60 मिनट का RTO पूरा करता है। केवल 25 मिनट का restore operation गिनने से interruption का बड़ा हिस्सा छिप जाएगा।

नवीनतम उपयोग योग्य recovery point 09:40 है। 10:00 के interruption से अंतर 20 मिनट है। यह 15 मिनट के RPO से 5 मिनट अधिक है। वही डेटा जल्दी restore करने से यह अंतर नहीं घटेगा।

वास्तव में छूटे या असंगत records देखें। समय का अंतर exposure बताता है; वह प्रभावित orders नहीं गिनता। सामान्य processing शुरू करने से पहले external payment और fulfillment records का मिलान करें। Recovery अभ्यास में अलग धारणाएँ परखें।

Recovery strategy चुनें

Strategy में जरूरी service, डेटा और dependencies शामिल होने चाहिए। इन patterns का मापे गए objectives से मिलान करें:

इन patterns के लिए हर स्थिति पर लागू recovery times नहीं हैं। Implementation, data volume, dependencies और test conditions परिणाम तय करते हैं। निर्णय में संचालन लागत और team की क्षमता शामिल करें।

केवल outage से आगे की सुरक्षा करें

Replica अनचाहा deletion या corrupted record भी copy कर सकता है। जहाँ जरूरी हो, recover किए जा सकने वाले versions या point-in-time recovery रखें। Retention, restore permissions और encryption keys तक access जाँचें। Backup isolation को scenario से मिलाएँ, जिसमें primary account का access खोना भी शामिल हो।

Regional recovery के लिए स्वीकार्य data location और पूरी dependency chain जाँचें। Identity, DNS, certificates, secrets, deployment artifacts, quotas और network access शामिल करें। एक जरूरी key के बिना recovery environment अनुपयोगी हो सकता है।

तय करें कि घटना कौन घोषित कर सकता है, recovery कौन करता है और restored service कौन स्वीकार करता है। Failback या recovery environment में संचालन जारी रखने की योजना बनाएँ। अलग components से टकराने वाले writes रोकें और फिर switch करने से पहले डेटा का मिलान करें।

योजना को प्रमाण में बदलें

Runbook लिखें और नियंत्रित परिस्थितियों में अभ्यास करें। Scenario, dataset size, शुरू और समाप्त होने के समय, recovered data point, failed steps और जिम्मेदार लोग दर्ज करें। सुरक्षित test records से वास्तविक business operation जाँचें।

संबंधित बदलावों के बाद और सहमत schedule पर अभ्यास दोहराएँ। Schema change, नई external dependency या अलग data volume पुराने परिणाम अमान्य कर सकते हैं। अभ्यास का प्रमाण release और संचालन की जिम्मेदारियों से जोड़ें।