आपदा पुनर्प्राप्ति फ़ाइल ट्रांसफर: व्यापार निरंतरता

आपदा पुनर्प्राप्ति फ़ाइल ट्रांसफर यह सुनिश्चित करता है कि प्राथमिक साइट विफल होने पर भी परिचालन जारी रहे — क्रॉस-रीजन रेप्लिकेशन (S3 CRR, Azure GRS), वार्म स्टैंडबाय इन्फ्रास्ट्रक्चर, और दस्तावेज़ीकृत फ़ेलओवर रनबुक के माध्यम से। DR-तैयार फ़ाइल सिस्टम सेकंड से घंटों के RPO के भीतर परिवर्तनों को एक द्वितीयक स्थान पर लगातार कॉपी करता है, RTO लक्ष्य के भीतर फ़ेलओवर का समर्थन करता है, और यथार्थवादी परिस्थितियों में परीक्षण किया जाता है। उपयोगी DR का सबसे छोटा रास्ता: एक वर्कलोड चुनें, उसे दूसरे क्षेत्र में रेप्लिकेट करें, शनिवार को रीजनल विफलता सिमुलेट करें, और मापें कि वास्तव में क्या होता है।

व्यावसायिक प्रभाव के आधार पर वर्कलोड का वर्गीकरण

हर फ़ाइल सिस्टम हॉट-हॉट रेप्लिकेशन का हकदार नहीं होता। एक बिज़नेस इम्पैक्ट एनालिसिस सिस्टम को डाउनटाइम और डेटा हानि की सहनशीलता के आधार पर वर्गीकृत करता है:

Tier 0 (मिशन-क्रिटिकल): भुगतान प्रसंस्करण, क्लिनिकल सिस्टम। RPO <1 मिनट, RTO <15 मिनट।
Tier 1 (क्रिटिकल): ऑर्डर प्रबंधन, ग्राहक-सामना करने वाले ऐप। RPO <15 मिनट, RTO <1 घंटा।
Tier 2 (महत्वपूर्ण): आंतरिक टूल, रिपोर्टिंग। RPO <24 घंटे, RTO <8 घंटे।
Tier 3 (मानक): प्रशिक्षण सामग्री, अभिलेखागार। RPO <1 सप्ताह, RTO <3 दिन।

Tier 0 को रेप्लिकेट करना Tier 3 से 3-10 गुना महंगा है। सिस्टम को ईमानदारी से मैप करें। अधिकांश कंपनियों के 5-10% सिस्टम Tier 0-1 में हैं — खर्च वहीं केंद्रित करें, न कि सब कुछ समान रूप से सोने से मढ़ने की कोशिश करें।

रेप्लिकेशन टोपोलॉजी

फ़ाइल स्टोरेज के लिए तीन रेप्लिकेशन मॉडल प्रभावी हैं:

एक्टिव-पैसिव: प्राथमिक राइट्स लेता है, सेकेंडरी रेप्लिका प्राप्त करता है। फ़ेलओवर के लिए प्रमोशन आवश्यक। अधिकांश रीजनल DR सेटअप में उपयोग।
एक्टिव-एक्टिव: दोनों रीजन राइट्स लेते हैं, कॉन्फ्लिक्ट रेज़ोल्यूशन के साथ। अधिक जटिल लेकिन लगभग-शून्य RTO। ग्लोबल सिस्टम में उपयोग।
बैकअप-आधारित: सेकेंडरी में आवधिक बैकअप। सबसे अधिक RPO लेकिन सरलतम। Tier 3 के लिए उपयोग।

S3 Cross-Region Replication (CRR) सब-मिनट RPO के साथ एक्टिव-पैसिव लागू करता है। S3 Multi-Region Access Points फ़ेलओवर रूटिंग जोड़ते हैं। एक्टिव-एक्टिव के लिए, डेटाबेस के लिए DynamoDB Global Tables और CockroachDB; फ़ाइलों के लिए, कॉन्फ्लिक्ट-रेज़ोल्यूशन टैग के साथ दोनों दिशाओं में rclone एक DIY तरीका है।

द्वितीयक क्षेत्र का चयन

प्राथमिक और द्वितीयक स्वतंत्र रूप से विफल होने चाहिए। अंगूठे का नियम:

अलग भौगोलिक क्षेत्र (us-east-1 → us-west-2, us-east-1 → us-east-2 नहीं)
अलग पावर ग्रिड (अमेरिका में पश्चिम तट बनाम पूर्व तट, विभिन्न यूरोपीय देश ग्रिड)
जहाँ प्रासंगिक हो, अलग टेक्टोनिक ज़ोन (रिंग ऑफ फायर पर दोनों न हों)

अनुपालन वर्कलोड के लिए, दोनों क्षेत्रों को विनियमन पूरा करना होगा। DPDP Act 2023 के तहत भारतीय उपयोगकर्ताओं का डेटा Data Protection Board of India के दिशानिर्देशों के अनुसार संग्रहीत होना चाहिए — मुंबई से हैदराबाद रेप्लिकेट करें, न कि सिंगापुर। HIPAA के लिए द्वितीयक क्षेत्र में भी BAA आवश्यक है। क्षेत्र चयन और तर्क दस्तावेज़ीकृत करें; ऑडिटर पूछेंगे।

क्रॉस-रीजन रेप्लिकेशन लागत

रेप्लिकेशन के तीन लागत घटक हैं:

स्टोरेज: प्राथमिक लागत दोगुनी (दोनों क्षेत्र एक प्रति रखते हैं)
डेटा ट्रांसफर: AWS रीजन के बीच CRR के लिए $0.02/GB चार्ज करता है
रिक्वेस्ट शुल्क: गंतव्य पर PUT ऑपरेशन

10 TB मासिक रेप्लिकेशन के लिए, Virginia और Oregon के बीच AWS में लगभग ₹58,000/माह अपेक्षित करें। समाधान: गंतव्य पर सस्ती स्टोरेज क्लास में रेप्लिकेट करें (Standard के बजाय S3 Glacier Instant Retrieval), गैर-क्रिटिकल डेटा को बाहर करने के लिए prefix या tag द्वारा रेप्लिकेशन फ़िल्टर करें, और रनअवे रेप्लिकेशन पकड़ने के लिए बकेट रेप्लिकेशन मेट्रिक्स का उपयोग करें।

फ़ेलओवर रनबुक

जो रनबुक केवल एक विचार के रूप में मौजूद है, वह विफल होने वाला रनबुक है। प्रोडक्शन-तैयार रनबुक में शामिल हैं:

ट्रिगर मानदंड: कौन सी स्थितियाँ फ़ेलओवर शुरू करती हैं (रीजन स्टेटस पेज, एप्लिकेशन हेल्थ चेक, थ्रेशोल्ड से अधिक P99 लेटेंसी)
निर्णय अधिकार: निर्णय कौन लेता है (आमतौर पर VP Engineering + SRE लीड, स्वचालित ट्रिगर के लिए पूर्व-स्वीकृत थ्रेशोल्ड के साथ)
चरण: क्रम में सटीक कमांड, अपेक्षित आउटपुट के साथ
सत्यापन: प्रत्येक चरण काम किया, यह कैसे पुष्टि करें
रोलबैक: यदि फ़ेलओवर स्वयं समस्याएँ पैदा करे तो कैसे वापस करें
संचार: स्टेटस पेज अपडेट, ग्राहक अधिसूचना, आंतरिक Slack

S3-समर्थित एप्लिकेशन के लिए उदाहरण फ़ेलओवर चरण: Route 53 अपडेट करें ताकि files.example.com प्राथमिक बकेट के CloudFront से द्वितीयक बकेट के CloudFront पर पॉइंट करे। dig और एक कैनरी अपलोड से परीक्षण करें। समय लक्ष्य: 10 मिनट से कम।

DNS और रूटिंग रणनीति

DNS आमतौर पर फ़ेलओवर चलाता है। विकल्प:

Route 53 Failover routing: हेल्थ चेक के आधार पर स्वचालित स्विच के साथ एक्टिव-पैसिव
Route 53 Latency routing: निकटतम स्वस्थ क्षेत्र पर ट्रैफिक
CloudFront with origin failover: क्लाइंट के लिए पारदर्शी
Multi-region backends के साथ Load balancer: काम करता है लेकिन जटिलता बढ़ाता है

TTL मायने रखता है। 300-सेकंड TTL वाला DNS रिकॉर्ड 5 मिनट में फ़ेलओवर होता है; 3,600-सेकंड TTL एक घंटे लेता है। DR-क्रिटिकल रिकॉर्ड को TTL 60-300 सेकंड पर सेट करें, तेज़ convergence के लिए थोड़ा अधिक DNS ट्रैफिक स्वीकार करते हुए।

फ़ेलओवर के दौरान डेटा अखंडता

रेप्लिकेशन लैग का मतलब है कि सेकेंडरी थोड़ा पीछे है। फ़ेलओवर करने से हाल के राइट्स खो सकते हैं। RPO को सबसे खराब स्थिति की अपेक्षित हानि के रूप में दस्तावेज़ीकृत करें और एक reconciliation योजना रखें:

एप्लिकेशन लेयर पर uncommitted राइट्स लॉग करें ताकि उन्हें replay किया जा सके
in-flight ट्रांजेक्शन कैप्चर करें और event logs से replay करें
हानि को स्पष्ट रूप से स्वीकार करें (गैर-क्रिटिकल डेटा के लिए, सरलता बेहतर है)

विशेष रूप से फ़ाइल अपलोड के लिए, फ़ेलओवर से बाधित multipart अपलोड सेकेंडरी पर अधूरे अपलोड छोड़ सकता है। दोनों क्षेत्रों पर AbortIncompleteMultipartUpload lifecycle नियम कॉन्फ़िगर करें।

DR का गंभीरता से परीक्षण

परीक्षित DR योजना और अपरीक्षित DR योजना दो अलग चीज़ें हैं। परीक्षण के स्तर:

Tabletop exercise: रनबुक को मौखिक रूप से चलाएं। त्रैमासिक।
आंशिक फ़ेलओवर: एक सबसिस्टम विफल करें (जैसे, केवल फ़ाइल सेवा)। अर्ध-वार्षिक।
पूर्ण रीजनल फ़ेलओवर: निर्धारित रखरखाव विंडो में सब कुछ विफल करें। वार्षिक।
Chaos engineering: अनिर्धारित, सिमुलेटेड, व्यावसायिक घंटों के दौरान। Tier 0 सिस्टम के लिए त्रैमासिक।

सब कुछ रिकॉर्ड करें। क्या टूटा। प्रत्येक चरण में वास्तव में कितना समय लगा। जब उन्हें ज़रूरत थी तो कौन दस्तावेज़ीकरण तक नहीं पहुँच सका। प्रत्येक परीक्षण के बाद रनबुक में सुधार करें। जो टीमें यह करती हैं उनके फ़ेलओवर काम करते हैं; जो नहीं करतीं वे वास्तविक घटनाओं के दौरान समस्याएँ खोजती हैं।

संचार चैनल मायने रखते हैं

किसी घटना के दौरान, इन-क्लाउड संचार अनुपलब्ध हो सकता है। उसी AWS क्षेत्र में होस्ट किया गया Slack जो विफल हो रहा है, बेकार है। आउट-ऑफ-बैंड चैनल पहले से व्यवस्थित करें:

किसी भिन्न क्षेत्र में होस्ट किया गया द्वितीयक Slack workspace
Twilio या Telnyx के माध्यम से SMS ब्रिज
WhatsApp Business ग्रुप अंतिम उपाय के रूप में — भारत में यह सर्वाधिक विश्वसनीय बैकअप चैनल है
आपके प्राथमिक इन्फ्रास्ट्रक्चर के बाहर होस्ट किया गया सार्वजनिक स्टेटस पेज (Atlassian Statuspage, StatusGator)

चैनलों को भौतिक बाइंडर में दस्तावेज़ीकृत करें। उन पर स्विच करने का अभ्यास करें।

लोगों के बीच रिकवरी फ़ाइलें ट्रांसफर करना

जब रीजनल विफलता लोगों को सामान्य सहयोग टूल से बाहर कर देती है, तो विशिष्ट फ़ाइलें ट्रांसफर करना — एक वर्तमान डेटाबेस डंप, एक कॉन्फ़िगरेशन एक्सपोर्ट, एक incident-response playbook — एक ऐसे चैनल की आवश्यकता होती है जो आपके इन्फ्रास्ट्रक्चर से स्वतंत्र रूप से काम करे।

HexaTransfer किसी भी ब्राउज़र पर बिना अकाउंट सेटअप के चलता है — उपयोगी जब SSO प्रदाता भी डाउन हो, या जब प्रतिक्रिया करने वाले सलाहकारों को आपके tenant में प्रावधान किए बिना फ़ाइलें प्राप्त करनी हों। एंड-टू-एंड AES-256-GCM एन्क्रिप्शन का मतलब है कि तनावपूर्ण keyboard moments में भी secrets वायर पर लीक नहीं होते।

घटना के बाद समीक्षा

प्रत्येक DR परीक्षण और प्रत्येक वास्तविक घटना एक blameless postmortem की हकदार है। दस्तावेज़ करें:

घटनाओं की समयरेखा
क्या काम किया
क्या नहीं किया
मूल कारण (तकनीकी और प्रक्रिया)
मालिकों और समय सीमाओं के साथ कार्य आइटम

कार्य आइटमों को पूरा होने तक ट्रैक करें। 20 कार्यों और शून्य पूर्ण के साथ postmortem, किसी postmortem से भी बुरा है — यह टीम को संकेत देता है कि सुधार कोई मायने नहीं रखते। लूप बंद करें, और अगली घटना पिछली से बेहतर होती है।

आपदा पुनर्प्राप्ति अधिकतर अनुशासन है। RPO/RTO सेट करें, लगातार रेप्लिकेट करें, रनबुक दस्तावेज़ीकृत करें, त्रैमासिक परीक्षण करें, और आउट-ऑफ-बैंड संचार करें। तकनीक आसान हिस्सा है।

hexatransfer.com पर आज़माएं — मुफ़्त, कोई अकाउंट नहीं, अधिकतम 10 GB।