डिज़ास्टर रिकवरी प्लान बनाने की एक व्यावहारिक, चरण-दर-चरण मार्गदर्शिका: यथार्थवादी RTO और RPO लक्ष्य कैसे तय करें, बिज़नेस इम्पैक्ट एनालिसिस कैसे चलाएं, टियर्ड बैकअप रणनीति कैसे डिज़ाइन करें, और वास्तव में ज़रूरत पड़ने से पहले रिकवरी का परीक्षण कैसे करें।
डिज़ास्टर रिकवरी प्लान असल में क्या है
डिज़ास्टर रिकवरी (DR) प्लान वह प्रलेखित, परीक्षित प्रक्रिया है जिसका पालन आपकी टीम किसी आउटेज के बाद IT सिस्टम और डेटा को बहाल करने के लिए करती है — एक विफल सर्वर, रैंसमवेयर, एक डिलीट किया गया डेटाबेस, एक डूबा हुआ डेटा सेंटर, या एक क्लाउड-रीजन की विफलता। यह बैकअप के समान नहीं है। बैकअप डेटा की एक प्रति है; DR प्लान वह प्लेबुक है जो उस प्रति को वापस एक चालू बिज़नेस में बदल देती है।
हर DR प्लान दो संख्याओं पर टिका होता है: RTO और RPO। इन्हें सही कर लें और बाकी की योजना लगभग अपने-आप ही बन जाती है।
RTO बनाम RPO: वे दो संख्याएं जो मायने रखती हैं
- रिकवरी टाइम ऑब्जेक्टिव (RTO) वह अधिकतम स्वीकार्य समय है जितनी देर कोई सिस्टम गंभीर नुकसान पहुंचाने से पहले बंद रह सकता है। अगर आपकी ई-कॉमर्स साइट का RTO 2 घंटे है, तो रिकवरी घटना के 2 घंटे के भीतर पूरी हो जानी चाहिए।
- रिकवरी पॉइंट ऑब्जेक्टिव (RPO) वह अधिकतम स्वीकार्य डेटा की मात्रा है, जिसे समय के रूप में मापा जाता है, जिसे खोने का जोखिम आप उठा सकते हैं। 15 मिनट का RPO इसका मतलब है कि आपके बैकअप (या रेप्लिकेशन) 15 मिनट से अधिक पुराने नहीं होने चाहिए, ताकि आप अधिक से अधिक 15 मिनट का काम खोएं।
इसे याद रखने का एक सरल तरीका: RTO आगे की ओर देखता है ("हम कितनी देर में वापस आएंगे?") और RPO पीछे की ओर देखता है ("हम कितना हाल का डेटा खो सकते हैं?")।
| अवधारणा | जिस प्रश्न का यह उत्तर देता है | किससे संचालित होता है | कम लक्ष्य की लागत |
|---|---|---|---|
| RTO | हमें कितनी तेज़ी से रिकवर करना होगा? | फेलओवर/रिस्टोर की गति | अधिक ऑटोमेशन, वॉर्म स्टैंडबाय |
| RPO | हम कितना डेटा खो सकते हैं? | बैकअप/रेप्लिकेशन की आवृत्ति | अधिक बार-बार बैकअप, रेप्लिकेशन |
कड़े लक्ष्यों की लागत अधिक होती है, इसलिए इन्हें हर वर्कलोड के अनुसार तय करें, एक साथ सब कुछ के लिए नहीं।
चरण 1: एक बिज़नेस इम्पैक्ट एनालिसिस (BIA) चलाएं
हर सिस्टम को सूचीबद्ध करें और पूछें: इसके बंद रहने के हर घंटे बिज़नेस का क्या होता है, और कितना डेटा नुकसान सहनीय है? वर्कलोड को टियर्स में क्रमबद्ध करें।
| टियर | उदाहरण वर्कलोड | RTO | RPO |
|---|---|---|---|
| 1 — क्रिटिकल | पेमेंट/ERP डेटाबेस, ग्राहक-सामने वाला ऐप | < 1 घंटा | < 15 मिनट |
| 2 — महत्वपूर्ण | आंतरिक ऐप्स, बिज़नेस ईमेल | < 4 घंटे | < 1 घंटा |
| 3 — मानक | फ़ाइल शेयर, रिपोर्टिंग, dev/test | < 24 घंटे | < 24 घंटे |
ईमानदार रहें। एक मार्केटिंग ब्लॉग के लिए 5-मिनट का RTO बर्बाद पैसा है; एक पेमेंट लेज़र के लिए 24-घंटे का RPO एक बिज़नेस-खत्म करने वाली गलती है।
चरण 2: प्रति टियर एक रिकवरी रणनीति चुनें
हर टियर को एक आर्किटेक्चर से मिलाएं:
- बैकअप और रिस्टोर (सबसे सस्ता, सबसे धीमा): ऑब्जेक्ट स्टोरेज पर शेड्यूल किए गए बैकअप; मांग पर पुनर्निर्माण। टियर 3 और कई टियर 2 वर्कलोड के लिए उपयुक्त।
- पायलट लाइट / वॉर्म स्टैंडबाय: एक दूसरे स्थान पर चलते हुए रखी गई वातावरण की एक न्यूनतम प्रति, जिसे फेलओवर के दौरान स्केल अप किया जाता है। मध्यम RTO वाले टियर 1 के लिए उपयुक्त।
- हॉट स्टैंडबाय / एक्टिव-एक्टिव: एक पूरी तरह से चलती हुई रेप्लिका जो लगभग तुरंत कार्यभार संभाल लेती है। सबसे अधिक लागत; इसे उन टियर 1 सिस्टमों के लिए आरक्षित रखें जहां मिनटों का डाउनटाइम भी अस्वीकार्य है।
सऊदी संगठनों के लिए, यह भी पुष्टि करें कि हर प्रति भौतिक रूप से कहां रहती है। PDPL और NCA दिशा-निर्देशों के तहत, प्राथमिक और DR प्रतियों को इन-किंगडम क्लाउड इन्फ्रास्ट्रक्चर पर रखने से आप डेटा-रेसिडेंसी अपेक्षाओं के सही पक्ष में बने रहते हैं और सीमा-पार ट्रांसफर समीक्षाओं से बचते हैं।
चरण 3: 3-2-1 बैकअप नियम लागू करें
टियर चाहे जो भी हो, बैकअप को सिद्ध 3-2-1 नियम के इर्द-गिर्द डिज़ाइन करें:
- अपने डेटा की 3 प्रतियां (1 प्राथमिक + 2 बैकअप)
- 2 विभिन्न मीडिया या स्टोरेज प्रकार
- 1 प्रति ऑफ़-साइट (एक अलग रीजन या प्रोवाइडर)
एक आधुनिक संस्करण, 3-2-1-1-0, इसमें 1 इम्यूटेबल/ऑफ़लाइन प्रति (रैंसमवेयर से बचाता है) और रिस्टोर पर सत्यापित 0 त्रुटियां जोड़ता है। इम्यूटेबिलिटी मायने रखती है: रैंसमवेयर अब सबसे पहले बैकअप को निशाना बनाता है।
यहां restic का उपयोग करके S3-कम्पैटिबल ऑब्जेक्ट स्टोरेज पर एक डेटाबेस और ऐप डायरेक्टरी का एक विश्वसनीय, डीडुप्लीकेटिंग, एन्क्रिप्टेड बैकअप दिया गया है:
# Install restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic
# Point restic at your object storage bucket
export RESTIC_REPOSITORY="s3:https://s3.example.com/dr-backups"
export AWS_ACCESS_KEY_ID="<access-key>"
export AWS_SECRET_ACCESS_KEY="<secret-key>"
export RESTIC_PASSWORD="<strong-repo-passphrase>" # keep this safe & off-server
# One-time: initialise the encrypted repository
restic init
# Dump the database, then back up the dump + app files
mysqldump --single-transaction --routines --triggers \
-u backup -p"$DB_PASS" appdb > /var/backups/appdb.sql
restic backup /var/backups/appdb.sql /srv/app --tag nightly
# Enforce retention (keeps storage and RPO sane)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
आपकी बैकअप आवृत्ति आपके RPO को संतुष्ट करनी चाहिए। अगर RPO 1 घंटा है, तो जॉब को cron के माध्यम से प्रति घंटा शेड्यूल करें और पुष्टि करें कि हर रन घंटे के भीतर अच्छी तरह से पूरा हो जाता है:
# /etc/cron.d/dr-backup — hourly backup at minute 5
5 * * * * root /usr/local/bin/dr-backup.sh >> /var/log/dr-backup.log 2>&1
डेटाबेस पर कड़े RPO के लिए, निरंतर तरीकों का उपयोग करें — MySQL/MariaDB बाइनरी-लॉग शिपिंग या PostgreSQL WAL आर्काइविंग / स्ट्रीमिंग रेप्लिकेशन — केवल स्नैपशॉट पर निर्भर रहने के बजाय।
चरण 4: रिकवरी रनबुक लिखें
ऐसा बैकअप जिसे दबाव में कोई रिस्टोर न कर सके, बेकार है। सटीक रिस्टोर चरणों को एक रनबुक के रूप में प्रलेखित करें जिसका पालन ऑन-कॉल कोई भी व्यक्ति कर सके:
- घटना की घोषणा करें और DR कोऑर्डिनेटर को सूचित करें।
- रिकवरी इन्फ्रास्ट्रक्चर प्रोविज़न करें (एक स्टैंडबाय क्लाउड सर्वर या होस्टिंग वातावरण जिसे आप तेज़ी से चालू कर सकें)।
- नवीनतम सत्यापित बैकअप से डेटा रिस्टोर करें।
- इंटीग्रिटी सत्यापित करें, फिर ट्रैफ़िक को रीडायरेक्ट करें (DNS/लोड बैलेंसर)।
- हितधारकों को स्थिति की जानकारी दें।
ऊपर दिए गए restic उदाहरण से एक रिस्टोर बस इतना सरल है:
# List recovery points, then restore the latest into a target path
restic snapshots
restic restore latest --target /srv/recovery
रनबुक को नामों, फ़ोन नंबरों, और क्रेडेंशियल्स के स्थानों के साथ रखें — स्वयं क्रेडेंशियल्स नहीं — किसी ऐसी जगह जहां तब भी पहुंचा जा सके जब आपके मुख्य सिस्टम बंद हों।
चरण 5: परीक्षण करें, फिर दोबारा परीक्षण करें
DR प्लान सड़ जाते हैं। टियर 1 सिस्टमों के लिए कम से कम तिमाही आधार पर रिकवरी ड्रिल शेड्यूल करें:
- टेबलटॉप टेस्ट: रनबुक को कागज़ पर पढ़कर चलें।
- रिस्टोर टेस्ट: वास्तव में एक बैकअप को एक पृथक वातावरण में रिस्टोर करें और पुष्टि करें कि डेटा सही है (3-2-1-1-0 में "0")।
- फुल फेलओवर: DR साइट पर कटओवर करें और उस पर चलाएं।
हर ड्रिल के बाद, अपने वास्तविक रिकवरी समय और डेटा नुकसान को अपने RTO और RPO के मुकाबले मापें। अगर आप उन्हें चूक गए, तो कमी को ठीक करें — अधिक बार-बार बैकअप, अधिक ऑटोमेशन, या एक अधिक वॉर्म स्टैंडबाय — और दोबारा परीक्षण करें।
इसे एक साथ रखना
एक कारगर DR प्लान संक्षिप्त होता है: एक एक-पृष्ठ की टियरिंग टेबल, प्रति-टियर RTO/RPO लक्ष्य, एक 3-2-1-1-0 बैकअप डिज़ाइन, एक परीक्षित रनबुक, और एक ड्रिल शेड्यूल। अपने सबसे क्रिटिकल वर्कलोड से शुरू करें, साबित करें कि रिस्टोर एंड-टू-एंड काम करता है, फिर टियर-दर-टियर विस्तार करें।
अगर आप ऐसे बैकअप और स्टैंडबाय इन्फ्रास्ट्रक्चर चाहते हैं जो PDPL और NCA अनुपालन के लिए किंगडम के भीतर ही रहें, तो संबंधित गाइड्स के लिए क्लाउड बैकअप क्लस्टर को एक्सप्लोर करें, या एक Skyline Cloud अकाउंट बनाएं और मिनटों में इन-किंगडम ऑब्जेक्ट स्टोरेज, क्लाउड सर्वर, और बैकअप प्रोविज़न करें।
Comments
0 total · 0 threads