RTO और RPO समझाइए और यह भी कि वे disaster recovery के डिजाइन को कैसे तय करते हैं।

recovery time objective यह है कि service बहाल करने में आप कितना वक्त ले सकते हैं; recovery point objective यह है कि आप कितना डेटा खोना बर्दाश्त कर सकते हैं। यही रणनीति चुनते हैं: backup and restore सबसे सस्ता है और recovery में घंटे लगते हैं, pilot light मुख्य हिस्सों को चलता रखकर तेज recovery देता है, warm standby एक छोटी copy चलाता है, और कई region में active लगभग तुरंत है और सबसे महंगा। दोनों नंबर बिज़नेस से आते हैं, इंजीनियरिंग से नहीं।

recovery time objective यह है कि बिज़नेस कितनी देर बंद रह सकता है; recovery point objective यह है कि वह हाल का कितना डेटा खो सकता है। दोनों बिज़नेस के फैसले हैं, और मेरा काम उन्हें एक डिजाइन और एक कीमत में बदलना है ताकि कोई समझदारी से चुन सके। अगर वे कहते हैं चार घंटे बंद और एक घंटे का डेटा नुकसान, तो वह बार बार लिए गए snapshot के साथ backup and restore है, जो सस्ता है। अगर तीस मिनट और लगभग शून्य डेटा नुकसान है, तो हम लगातार replication वाले warm standby में हैं, जिसमें असली पैसा लगता है। लगभग तुरंत और बिना नुकसान का मतलब है दो region में active और एक बिल्कुल अलग application डिजाइन, और वह इस पर बातचीत है कि क्या एक घंटे की downtime सचमुच उस आर्किटेक्चर से ज्यादा महंगी है। अहम बारीकी यह है कि नंबर हर workload के लिए अलग होते हैं; checkout और अंदरूनी reporting टूल एक ही निवेश के हकदार नहीं हैं। और मैं टेस्टिंग पर अड़ता हूं, एक साफ environment में तय समय पर restore जहां हम शुरू से आखिर तक वक्त नापते हैं, क्योंकि जब मैंने यह पहली बार किया तो जो recovery कागज पर चार घंटे की थी वह ग्यारह निकली, जिसमें ज्यादातर वक्त credentials ढूंढने में गया।