क्लाउड एप्लिकेशन रिकवरी के लिए 33 मिलियन डॉलर की सीड फंडिंग के साथ Dreeze ने स्टील्थ मोड से बाहर आने की घोषणा की

Dreeze 33 मिलियन डॉलर की सीड फंडिंग के साथ स्टील्थ मोड से बाहर आ रही है। कंपनी का प्रस्ताव क्लाउड कंप्यूटिंग की सबसे निराशाजनक विफलताओं में से एक को दूर करने पर केंद्रित है: डेटा तो बहाल हो जाए, लेकिन उस पर निर्भर व्यावसायिक एप्लिकेशन बहाल न हो।

इस फंडिंग राउंड का नेतृत्व Norwest और Bessemer Venture Partners कर रहे हैं, जबकि Claltech भी इसमें शामिल है। फंडिंग की घोषणा के साथ ही, तेल अवीव की यह कंपनी अपना Application Revival प्लेटफ़ॉर्म लॉन्च कर रही है। इसे उन संसाधनों का नक्शा बनाने, उनकी सुरक्षा करने, उन्हें फिर से तैयार करने और उनकी जाँच करने के लिए बनाया गया है, जिनकी पूरी क्लाउड एप्लिकेशन को दोबारा चालू करने के लिए ज़रूरत होती है।

Dreeze की स्थापना 2025 में Ziv Kedem, Oded Kedem और Avi Raichel ने की थी। ये बैकअप और रिकवरी उद्योग के अनुभवी लोग हैं और Zerto तथा Kashya में काम कर चुके हैं। कंपनी के अनुसार, इज़राइल और संयुक्त राज्य अमेरिका में उसके 70 कर्मचारी हैं। वह इस फंडिंग का इस्तेमाल उत्पाद विकास तेज़ करने, बिक्री और मार्केटिंग का विस्तार करने और अधिक बड़े उद्यमों को ग्राहक बनाने के लिए करेगी।

जब डेटा बहाल हो जाए, लेकिन एप्लिकेशन फिर भी बंद रहे

Dreeze जिस समस्या को हल करना चाहती है, वह सफलतापूर्वक बैकअप बहाल होने और सेवा के काम करने के बीच की कड़ी है। किसी क्लाउड एप्लिकेशन की निर्भरता बुनियादी ढाँचे, कॉन्फ़िगरेशन सेटिंग्स, पहचान-संबंधी जानकारियों, सीक्रेट्स, एन्क्रिप्शन कुंजियों और अन्य संसाधनों से जुड़ाव पर हो सकती है। उसका डेटाबेस वापस लाने से इस व्यवस्था का केवल एक हिस्सा बहाल होता है।

अगर सहायक घटक उपलब्ध न हों या गलत क्रम में बहाल किए जाएँ, तो आईटी टीमों को निर्भरताएँ अब भी हाथ से फिर से जोड़नी पड़ सकती हैं। Dreeze इस प्रक्रिया को “रिकवरी की आपाधापी” कहती है: वह दौर जब डेटा तो लौट आया हो, लेकिन एप्लिकेशन इस्तेमाल के लायक न हो।

घोषणा में Dreeze के सह-संस्थापक और सीईओ Ziv Kedem ने कहा, “कंपनियाँ वर्षों से डेटा का बैकअप लेने में बेहतर होती आई हैं, लेकिन डेटा वापस मिल जाने का मतलब यह नहीं कि कारोबार भी फिर से शुरू हो गया है।”

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

एप्लिकेशन को फिर से चालू करने के चार चरण

Dreeze अपने प्लेटफ़ॉर्म को चार क्षमताओं के आधार पर व्यवस्थित करती है। इनमें खोज और सुरक्षा के साथ रिकवरी को अंजाम देना और उसकी जाँच करना भी शामिल है।

जानें: सेवा बाधित होने से पहले निर्भरताओं का नक्शा बनाएँ

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

यही इस तरीके की बुनियाद है: स्वचालित रिकवरी क्रम उतना ही पूरा हो सकता है, जितनी पूरी जानकारी उसे इस बारे में हो कि क्या-क्या बहाल करना ज़रूरी है। व्यवधान आने से पहले निर्भरताओं की पहचान करने से यह काम घटना के समय के बजाय पहले ही हो जाता है।

सुरक्षा करें: सहायक संसाधनों का बैकअप लें

Dreeze का कहना है कि उसका सुरक्षित बैकअप डेटा के साथ कॉन्फ़िगरेशन, कुंजियों और एप्लिकेशन की अन्य निर्भरताओं को भी सुरक्षित रखता है। घोषणा में अपरिवर्तनीय, नेटवर्क से अलग रखे गए वॉल्ट और अलग-अलग क्षेत्रों में वैकल्पिक प्रतिकृति की सुविधा का उल्लेख है।

समन्वय करें: निर्भरताओं के क्रम में सब कुछ फिर से तैयार करें

Dreeze के अनुसार, प्लेटफ़ॉर्म की Revival Automation क्षमता रिकवरी योजना को लागू करती है और निर्भरताओं के क्रम में डेटा, बुनियादी ढाँचे, कॉन्फ़िगरेशन, पहचान-संबंधी जानकारी तथा कनेक्शन को फिर से तैयार करती है।

समन्वयन का लाभ इन घटकों के बीच काम के हस्तांतरण को व्यवस्थित करने में है। उदाहरण के लिए, ज़रूरी संसाधन उपलब्ध होने से पहले किसी सेवा को बहाल करने पर टीमों को आंशिक रूप से फिर से तैयार किए गए परिवेश की समस्याएँ सुलझानी पड़ सकती हैं। निर्भरताओं को ध्यान में रखकर बनाई गई योजना का लक्ष्य क्रम तय करने के इस मैन्युअल काम को कम करना है।

सत्यापित करें: पूरी रिकवरी योजना की जाँच करें

Dreeze अपनी सत्यापन क्षमता को एक स्वचालित, शुरू से अंत तक चलने वाली जाँच के रूप में पेश करती है, जो काम करने लायक एप्लिकेशन को फिर से तैयार करती है। कंपनी का कहना है कि ये जाँचें उत्पादन परिवेश पर असर डाले बिना और बाद में हाथ से सफ़ाई किए बिना चलती हैं।

उत्पाद के व्यावसायिक तर्क में जाँच की अहम भूमिका है। दस्तावेज़ में दर्ज योजना बताती है कि क्या होना चाहिए; सफल पूर्वाभ्यास इस बात का प्रमाण देता है कि जाँचे गए परिवेश में वास्तव में क्या होता है। घोषणा में स्वतंत्र बेंचमार्क, रिकवरी समय के माप या सभी सुविधाओं और सेवाओं की व्यापक सूची का खुलासा नहीं किया गया है।

AWS पर उपलब्धता, Azure पर बाद में

Dreeze का कहना है कि AWS पर उसकी सेवा आम तौर पर उपलब्ध है। Microsoft Azure के लिए उसका उत्पाद प्रारंभिक पहुँच चरण में है और आम तौर पर उपलब्धता 2027 की शुरुआत में नियोजित है। दोनों क्लाउड परिनियोजन की योजना बना रहे उद्यमों के लिए यह अंतर अहम है: घोषणा में उपलब्धता के अलग-अलग चरण बताए गए हैं।

Coravant के संस्थापक और सीईओ Jeremy Miller ने विज्ञप्ति में कहा कि ग्राहक पूरे एप्लिकेशन को उसकी निर्भरताओं समेत सही क्रम में बहाल करना चाहते हैं। Dreeze इसी परिचालन कमी को दूर करना चाहती है: व्यवधान के दौरान अधूरे हिस्सों का पता चलने से पहले ही वापसी का पूरा रास्ता तैयार करना।

यह फंडिंग क्यों मायने रखती है

Dreeze ऐसे बाज़ार में कदम रख रही है जहाँ रिकवरी के लिए सुरक्षित डेटा की मात्रा से अधिक बातों का ध्यान रखना ज़रूरी है। जैसे-जैसे ऐप्लिकेशन में सेवाएँ, अनुमतियाँ और इन्फ्रास्ट्रक्चर पर निर्भरताएँ बढ़ती हैं, रिकवरी का काम केवल स्टोरेज की समस्या नहीं, बल्कि समन्वय की समस्या भी बन जाता है।

AI उद्यमों के लिए रिकवरी की तैयारी को स्पष्ट रूप से तय करने की एक और वजह पेश करता है। AI एजेंटों में बैकअप के प्रति जागरूकता पर Unite.AI की कवरेज उन जोखिमों की पड़ताल करती है जो तब पैदा होते हैं जब स्वचालित सिस्टम पुनर्स्थापना की पर्याप्त तैयारी के बिना परिवेशों में बदलाव करते हैं। Dreeze की घोषणा व्यवधान के बाद ऐप्लिकेशन को फिर से तैयार करने के व्यापक परिचालन संबंधी सवाल को संबोधित करती है; इससे यह साबित नहीं होता कि यह प्लेटफ़ॉर्म एजेंटों की असुरक्षित कार्रवाइयों को रोकता है।

सीड फंडिंग से Dreeze को ऐप्लिकेशन-स्तर की रिकवरी संबंधी इस पेशकश को एक व्यापक एंटरप्राइज़ कारोबार में बदलने के लिए संसाधन मिलते हैं। अब उसकी अगली चुनौती यह दिखाना है कि निर्भरताओं की पहचान, सुरक्षा, समन्वय और परीक्षण—ये सभी ग्राहकों के वास्तविक परिवेशों में एक साथ कारगर ढंग से काम करते हैं। खरीदारों के लिए इसका आकर्षक नतीजा सीधा है: किसी अहम सेवा के ठप होने पर ऐप्लिकेशन को फिर से उपयोगी बनाने का एक ऐसा रास्ता, जिसका परीक्षण किया जा चुका हो।