क्लाउड बैकअप: जो AWS वापस नहीं ला सकता

सोचिए, सोमवार की सुबह आप अपने सिस्टम का पैनल खोलते हैं और प्रोवाइडर का यह नोटिस पढ़ते हैं: आपका कुछ डेटा रिस्टोर नहीं किया जा सकता। "देर लगेगी" नहीं। "हम इस पर काम कर रहे हैं" नहीं। बस वापस नहीं आएगा। वॉल स्ट्रीट जर्नल के अनुसार, मध्य पूर्व में ईरानी हमलों की चपेट में आई सुविधाओं के बाद AWS ने ग्राहकों को कुछ ऐसा ही बताया। यह वैसी खबर है जो क्लाउड पर निर्भर हर इंसान को एक पल के लिए रोक देती है: अगर यह मेरे साथ होता तो? जवाब पूरी तरह इस पर निर्भर करता है कि आपका क्लाउड बैकअप आज कैसे बना है।

मैं सीधे कहूंगा: मैं जिन ज्यादातर कंपनियों के साथ काम करता हूं, उनके पास बैकअप नहीं है। उनके पास बैकअप का एहसास है। ये दोनों अलग चीजें हैं।

"लेकिन यह तो क्लाउड में है, सुरक्षित नहीं है क्या?"

यह आज टेक्नोलॉजी की सबसे महंगी गलतफहमी है।

क्लाउड एक खास समस्या बहुत अच्छे से हल करता है: यह आपसे सर्वर खरीदने, जला हुआ HD बदलने और सर्वर रूम के एसी का बिल भरने की जिम्मेदारी ले लेता है। यह आपसे आपके डेटा की जिम्मेदारी नहीं लेता। हर बड़े प्रोवाइडर के कॉन्ट्रैक्ट में यह लिखा होता है, जिसे वे साझा जिम्मेदारी मॉडल कहते हैं। वे इंफ्रास्ट्रक्चर संभालते हैं। आप संभालते हैं जो आप उसके अंदर रखते हैं।

बिजनेस मालिक की भाषा में: अगर कोई डेटा सेंटर राख हो जाए, तो प्रोवाइडर सर्विस लौटा देगा। आपकी फाइलें तभी लौटेंगी जब आपने उन्हें पहले कहीं और कॉपी करवाया हो।

और एक तकनीकी बात है जो बहुत लोगों को धोखा देती है। जब आप क्लाउड सर्विस लेते हैं, तो एक "रीजन" चुनते हैं, जैसे साओ पाउलो या नॉर्थ वर्जीनिया। एक रीजन के अंदर अवेलेबिलिटी जोन होते हैं, जो अलग-अलग इमारतें हैं। ज्यादातर सिस्टम एक इमारत गिरने पर बचने के लिए सेट किए जाते हैं। लगभग कोई भी पूरे रीजन के खत्म होने पर बचने के लिए सेट नहीं होता। और ठीक यही रीजनल परिदृश्य युद्ध, प्राकृतिक आपदा, बड़ी आग या कानूनी रोक में सामने आता है।

यह कोई कल्पना नहीं है, कई बार हो चुका है

युद्ध दूर लगता है। तो चलिए ज्यादा घरेलू उदाहरण लेते हैं।

मार्च 2021 में यूरोप की सबसे बड़ी क्लाउड प्रोवाइडर OVH का स्ट्रासबर्ग वाला एक डेटा सेंटर आग में नष्ट हो गया। पूरी इमारत। हजारों ग्राहकों ने हमेशा के लिए डेटा खो दिया। कई लोगों को उसी दिन पता चला कि जिस "बैकअप" के वे पैसे दे रहे थे, वह उसी कैंपस में था जो जल गया। कंपनियां बंद हो गईं।

2014 में Code Spaces, जो दूसरी कंपनियों का कोड होस्ट करती थी, एक हमले का शिकार हुई। हमलावर AWS के एडमिन पैनल में घुसा और डेटा के साथ बैकअप भी मिटा दिया, क्योंकि बैकअप और प्रोडक्शन एक ही अकाउंट में थे, एक ही क्रेडेंशियल के साथ। कंपनी ने 24 घंटे से भी कम समय में कामकाज बंद करने की घोषणा कर दी।

2023 में एक दक्षिण कोरियाई प्रोवाइडर ने ग्राहकों का डेटा खो दिया, जब रैंसमवेयर ने प्रोडक्शन और उससे जुड़े बैकअप दोनों को एन्क्रिप्ट कर दिया। पैटर्न वही दोहराता है: बैकअप मौजूद था, पर उसी समस्या की पहुंच में था।

जो बैकअप ओरिजिनल के साथ ही मर जाए, वह कभी बैकअप था ही नहीं। वह तो जोखिम की दूसरी कॉपी थी।

आपके प्रोवाइडर के क्लाउड के बाहर आपके पास सच में क्या होना चाहिए

IT का एक पुराना नियम है, 3-2-1, और वह बहुत अच्छे से टिका हुआ है। डेटा की तीन कॉपी, दो अलग तरह के मीडिया या प्लेटफॉर्म पर, और उनमें से एक मुख्य जगह से बाहर।

SaaS पर चलने वाले छोटे या मध्यम बिजनेस के लिए मैं इसे ऐसे ढालता हूं:

• एक कॉपी मुख्य प्रोवाइडर के बाहर। अगर आपका सिस्टम AWS पर चलता है, तो सुरक्षा कॉपी सिर्फ AWS में नहीं हो सकती। वह Google Cloud पर जा सकती है, Backblaze जैसे सस्ते स्टोरेज पर, या ऑफिस के NAS पर भी।
• एक कॉपी जिसे प्रोडक्शन सिस्टम मिटा न सके। अलग क्रेडेंशियल, अलग अकाउंट, और बेहतर हो कि एक तय अवधि तक डिलीट पर रोक हो (इम्यूटेबिलिटी)। यही चीज आपको रैंसमवेयर और नाराज कर्मचारी से बचाती है।
• एक कॉपी ऐसे फॉर्मेट में जिसे आप प्रोवाइडर के बिना पढ़ सकें। CSV, JSON, PDF, SQL। अगर आपके CRM का बैकअप सिर्फ उसी CRM के अंदर खुलता है, और CRM गायब हो गया, तो आपके पास एक सुंदर और बेकार फाइल है।

यह तीसरा बिंदु SaaS में सबसे ज्यादा भुलाया जाता है और सबसे जरूरी है। आप सिर्फ इंफ्रास्ट्रक्चर क्लाउड पर नहीं हैं। आप Bling पर हैं, Omie पर, RD Station पर, Notion पर, ClickUp पर, WhatsApp Business पर। इनमें से हर एक आपके बिजनेस के टुकड़े रखता है। इनमें से हर एक कार्ड फ्रॉड के शक में आपको ब्लॉक कर सकता है, कोई प्लान बंद कर सकता है, या बस टूट सकता है।

वह टेस्ट जो लगभग कोई नहीं करता

यह रहा वह सवाल जो मैं हर पहली मीटिंग में पूछता हूं और जो लगभग हमेशा बातचीत रोक देता है: आपने आखिरी बार बैकअप कब रिस्टोर किया था?

"बनाया" नहीं। "देखा कि फाइल है या नहीं" नहीं। सच में रिस्टोर किया, खोला, डेटा देखा, और पक्का किया कि सब कुछ वहीं था।

बिना टेस्ट किया बैकअप एक धार्मिक आस्था है। मैंने ऐसी एक्सपोर्ट रूटीन पकड़ी है जो आठ महीने से चल रही थी और 0 KB की फाइल बना रही थी, क्योंकि API का पासवर्ड एक्सपायर हो गया था और एरर वाला ईमेल कोई पढ़ता नहीं था। मैंने डेटाबेस का ऐसा डंप भी देखा है जो एकदम सही, पूरा और भरोसेमंद था, पर उसमें अटैचमेंट वाला फोल्डर गायब था: सारे साइन किए हुए कॉन्ट्रैक्ट PDF में, सारी प्रोडक्ट तस्वीरें, इनमें से कुछ भी बैकअप में नहीं था। डेटाबेस में फाइलों का रास्ता था। फाइलें नहीं थीं।

यह हर तिमाही में एक बार कीजिए। सबसे नया बैकअप लीजिए, उसे किसी अलग माहौल में रिस्टोर कीजिए, और तीन आसान सवालों के जवाब देने की कोशिश कीजिए:

1. पिछले सात दिनों का डेटा वहां है?
2. अटैचमेंट और इमेज खुलती हैं?
3. इसमें कितना समय लगा, शून्य से चालू होने तक?

तीसरा जवाब आपका असली रिकवरी टाइम है। अगर वह आठ घंटे है और आपका बिजनेस दो घंटे भी नहीं झेल सकता, तो आपके पास बैकअप की समस्या नहीं है, आर्किटेक्चर की समस्या है। और यह संकट के बजाय टेस्ट में पता चले, वही बेहतर है।

आप कितना समय और कितना डेटा खोना झेल सकते हैं

दो सवाल 90% प्लानिंग हल कर देते हैं, और इनमें से कोई भी तकनीकी नहीं है।

बिजनेस कितनी देर ठप रहना झेल सकता है? एक घंटा? एक दिन? एक हफ्ता? एक दिन बंद रही ऑनलाइन दुकान बिक्री खोती है और फिर उबर जाती है। एक दिन बिना रिकॉर्ड वाला क्लिनिक पूरा शेड्यूल रद्द करता है और अपनी साख को चोट पहुंचाता है।

बिजनेस कितना डेटा खोना झेल सकता है? अगर बैकअप हर रात चलता है और समस्या शाम पांच बजे होती है, तो आप पूरे दिन का काम खो देते हैं। हर ऑर्डर, हर दर्ज की गई कॉल, हर सर्विस। कुछ बिजनेस के लिए यह स्वीकार्य है। दूसरों के लिए यह नामंजूर है, और तब बैकअप लगातार चलना चाहिए।

इन दोनों का जवाब एक संख्या में दीजिए और बाकी सब सिर्फ अमल रह जाता है। इनके बिना, कोई भी जो समाधान आपको बेचेगा, वह बिल के साथ आया अंदाजा भर है।

और हां, खर्च होता है। पर लोग जितना सोचते हैं उससे बहुत कम। दूसरे क्लाउड में कोल्ड स्टोरेज पर 500 GB रखने का खर्च महीने में लगभग 10 से 25 रियाल है। जो ऑटोमेशन इसे रोज कॉपी करता है, टेस्ट करता है और फेल होने पर आपको बताता है, वह कॉन्फिगरेशन का काम है, कोई हमेशा चलने वाली सदस्यता नहीं। इसकी तुलना एक हफ्ते ठप रहने की कीमत से कीजिए, हिसाब अपने आप बैठ जाएगा।

इस हफ्ते क्या करें

आपको छह महीने का प्रोजेक्ट नहीं चाहिए। एक दोपहर चाहिए।

उन सभी सिस्टम की सूची बनाइए जहां आपका बिजनेस कुछ अहम रखता है। मैनेजमेंट सिस्टम, फाइनेंस, CRM, ईमेल, फाइलें, वेबसाइट। हर एक के लिए तीन चीजें लिखिए: डेटा कहां है, ऑटोमैटिक एक्सपोर्ट है या नहीं, और उस एक्सपोर्ट तक किसकी पहुंच है। सिर्फ यह टेबल बनाने से ही आम तौर पर दो या तीन ऐसे छेद दिख जाते हैं जिनके बारे में किसी को पता नहीं था।

उसके बाद सबसे अहम सिस्टम चुनिए और मूल प्रोवाइडर से अलग किसी जगह रोजाना एक्सपोर्ट सेट कीजिए। सिर्फ एक। उसी से शुरू कीजिए जिसे खोना सबसे ज्यादा चुभेगा।

AWS वाली खबर नाटकीय है क्योंकि उसमें मिसाइलें हैं, पर सीख बहुत साधारण है और उन लोगों के लिए भी काम की है जो कभी किसी युद्ध क्षेत्र के पास नहीं जाएंगे। हर वह निर्भरता जिसे आप बदल नहीं सकते, इस बात पर लगाया गया दांव है कि कुछ गलत नहीं होगा। और होता है, आज नहीं तो कल, आम तौर पर शुक्रवार दोपहर को।

अगर आप दूसरी राय चाहते हैं कि आपके सेटअप में छेद कहां हैं, तो बताइए आज यह कैसे चलता है। आम तौर पर आसान ऑटोमेशन से हल हो जाता है, और जो आप पहले से इस्तेमाल करते हैं उसे बदले बिना।

AWS ने ग्राहकों को बताया कि कुछ डेटा बस वापस नहीं आएगा। "देर लगेगी" नहीं। वापस नहीं आएगा।

मैं जिन ज्यादातर कंपनियों के साथ काम करता हूं, उनके पास बैकअप नहीं है। बैकअप का एहसास भर है।

क्लाउड इंफ्रास्ट्रक्चर संभालता है। आपका डेटा आपकी ही जिम्मेदारी रहती है, यह कॉन्ट्रैक्ट में लिखा है।

और वह सवाल जो लगभग हमेशा मीटिंग रोक देता है: आपने आखिरी बार बैकअप सच में कब रिस्टोर किया था? बनाया नहीं। रिस्टोर किया, खोला और जांचा।

मैंने ऐसी रूटीन पकड़ी है जो आठ महीने से चल रही थी और 0 KB की फाइल बना रही थी, क्योंकि API का पासवर्ड एक्सपायर हो गया था और एरर वाला ईमेल कोई पढ़ता नहीं था।

जो बैकअप ओरिजिनल के साथ ही मर जाए, वह कभी बैकअप था ही नहीं। वह तो जोखिम की दूसरी कॉपी थी।

चाहें तो बताइए आपका सेटअप आज कैसा है। आम तौर पर आसान ऑटोमेशन से हल हो जाता है, और जो आप पहले से इस्तेमाल करते हैं उसे बदले बिना।

#बैकअप #क्लाउडकंप्यूटिंग #जोखिमप्रबंधन #टेक्नोलॉजी #लघुउद्यम