Recovery की गणना · 8 MIN
RTO और RPO के अनुसार recovery जाँचें
Recovery के चरण और data gap बदलें। देखें कि तेज restore का अर्थ हमेशा कम data loss क्यों नहीं है।
स्थिति
एक काल्पनिक ordering service 10:00 पर रुकती है। उसका नवीनतम recover किया जा सकने वाला data 09:40 का है। व्यवसाय 60 मिनट की बाधा और अधिकतम 15 मिनट का data loss स्वीकार करता है।
क्या करें
- मूल outage चुनें। बाधा की अवधि की तुलना RTO और data के अंतर की तुलना RPO से करें।
- तेज restore और फिर नया recovery point आजमाएँ। पढ़ें कि कौन-सा लक्ष्य सुधरता है और किस input से वह बदलाव हुआ।
उदाहरण से शुरू करें
हर उदाहरण नीचे के fields भरता है और परिणाम दिखाता है। फिर आप खुद मान बदल सकते हैं।
Recovery point → बाधा
Data को किस पिछले समय तक recover करना होगा?बाधा → उपयोगी service
उपयोगी service वापस आने में कितना समय लगता है?अभ्यास का परिणाम
दूसरे उदाहरण की तुलना करें · इन मानों को बदलें
- पहचानें
- निर्णय लें
- Restore करें
- सत्यापित करें
यह परिणाम केवल दिए गए परिदृश्य पर लागू है। इससे service की availability या वास्तविक data integrity सिद्ध नहीं होती। गायब records का मिलान करें और recover किए गए व्यावसायिक कामकाज को सत्यापित करें।
एक बार में एक धारणा बदलें
Restore की अवधि 25 से 10 मिनट करें। देखें कि data का अंतर नहीं बदलता। फिर data का अंतर 5 मिनट करें और दोबारा गणना करें।
केवल Multi-AZ या दूसरा Region पर्याप्त क्यों नहीं है?
Replica अनचाहे deletion को copy कर सकता है। AZ failure, Region उपलब्ध न होने और data corruption के लिए अलग tests चाहिए। चुने गए परिदृश्य के लिए recover होने योग्य data, keys, dependencies, capacity और निर्णय जाँचें।
पूरा करने के लिए
आप service जल्दी restore करते हैं। क्या आपने data loss भी घटाया है?
अपने उत्तर की तुलना व्याख्या से करें
नहीं। इस उदाहरण में तेज restore से बाधा की अवधि 55 से 40 मिनट होती है। Recovery point के कारण अब भी 20 मिनट का data गायब है। नया recovery point उस अंतर को 5 मिनट करता है। Recovery के समय और recover किए जा सकने वाले data के लिए अलग प्रमाण चाहिए।
काम में इसका उपयोग करें
Recovery अभ्यास में service उपयोग योग्य होने का समय और नवीनतम recover किए गए transaction का समय, दोनों दर्ज करें।
दूसरा अभ्यास चुनें