Odoo 19 बैकअप और आपदा पुनर्प्राप्ति: एक व्यावहारिक गाइड

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

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

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

एक पूर्ण Odoo बैकअप में क्या होता है

Odoo डेटाबेस केवल एक PostgreSQL डेटाबेस नहीं है। अपलोड किए गए दस्तावेज़, इमेज और अन्य बाइनरी सामग्री जैसे अटैचमेंट उस जगह फ़ाइलों के रूप में संग्रहीत होते हैं जिसे Odoo फ़ाइलस्टोर कहता है, और उन तक पहुँच को Odoo नियंत्रित करता है। जिस बैकअप में केवल डेटाबेस डंप होता है, वह आपके रिकॉर्ड तो रीस्टोर कर देगा लेकिन अटैचमेंट गायब रहेंगे।

Odoo.sh के दस्तावेज़ बताते हैं कि उसके बैकअप में डेटाबेस डंप, फ़ाइलस्टोर (अटैचमेंट और बाइनरी फ़ील्ड), लॉग और सेशन शामिल होते हैं। किसी भी होस्टिंग प्रकार पर पूर्ण बैकअप कैसा दिखना चाहिए, इसके लिए यह एक उपयोगी संदर्भ है।

• डेटाबेस डंप: सभी रिकॉर्ड, कॉन्फ़िगरेशन, यूज़र, अकाउंटिंग एंट्री और सेटिंग्स।
• फ़ाइलस्टोर: अटैचमेंट और बाइनरी फ़ील्ड, जैसे स्कैन किए गए बिल, उत्पाद इमेज और हस्ताक्षरित PDF।
• कस्टम कोड: Odoo.sh और ऑन-प्रिमाइस पर आपके कस्टम मॉड्यूल आपकी कोड रिपॉज़िटरी में रहते हैं, जिसकी अपनी अलग सुरक्षा आवश्यक है।
• कॉन्फ़िगरेशन: ऑन-प्रिमाइस में Odoo कॉन्फ़िगरेशन फ़ाइल और सर्वर सेटअप का भी दस्तावेज़ीकरण होना चाहिए और उन्हें सुरक्षित रखा जाना चाहिए।

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

होस्टिंग प्रकार के अनुसार बैकअप

बैकअप की ज़िम्मेदारी इस पर निर्भर करती है कि आपका डेटाबेस कहाँ चलता है। Odoo Online और Odoo.sh को Odoo होस्ट करता है और इनमें स्वचालित बैकअप शामिल हैं, जबकि ऑन-प्रिमाइस सर्वर में पूरी ज़िम्मेदारी आपकी अपनी टीम की होती है। Community एडिशन आमतौर पर सेल्फ़-होस्टेड होता है, इसलिए नीचे वर्णित ऑन-प्रिमाइस ज़िम्मेदारियाँ उस पर लागू होती हैं।

Odoo Online: डेटाबेस मैनेजर

Odoo Online पर आधिकारिक दस्तावेज़ों के अनुसार डेटाबेस का Odoo Cloud Hosting SLA के तहत प्रतिदिन बैकअप लिया जाता है। प्लेटफ़ॉर्म बैकअप होने के लिए आपको कुछ भी शेड्यूल करने की ज़रूरत नहीं है।

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

• Download Backup डेटाबेस की एक ZIP फ़ाइल बनाता है जिसे आप अपने संग्रह में रख सकते हैं।
• यदि Download Backup निष्क्रिय है, तो डेटाबेस मैनेजर के लिए बहुत बड़ा है, और डाउनलोड के किसी अन्य तरीके के लिए Odoo सपोर्ट से संपर्क करना चाहिए।
• Duplicate डेटाबेस की एक कॉपी बनाता है; For testing purposes विकल्प डिफ़ॉल्ट रूप से सक्षम रहता है और ईमेल, भुगतान और डिलीवरी ऑर्डर जैसे बाहरी ऐक्शन को निष्क्रिय कर देता है।
• Delete डेटाबेस को सभी यूज़र्स के लिए तुरंत हटा देता है और इसे पूर्ववत नहीं किया जा सकता, इसलिए पहले बैकअप डाउनलोड करें।

दस्तावेज़ों के अनुसार Odoo Online पर डुप्लिकेट 15 दिनों के बाद समाप्त हो जाते हैं और हर डेटाबेस के अधिकतम पाँच डुप्लिकेट हो सकते हैं। डुप्लिकेट को अल्पकालिक टेस्ट वातावरण मानें, बैकअप रणनीति नहीं।

Odoo.sh: स्वचालित और मैनुअल बैकअप

Odoo.sh पर प्रोडक्शन डेटाबेस का हर दिन अपने-आप बैकअप लिया जाता है। दस्तावेज़ों के अनुसार सात दैनिक, चार साप्ताहिक और तीन मासिक बैकअप रखे जाते हैं, और मासिक कॉपियाँ समर्पित बैकअप सर्वर पर रखी जाती हैं। उन मासिक बैकअप को रीस्टोर या डाउनलोड करने के लिए Odoo सपोर्ट से संपर्क करना पड़ता है।

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

जब कोई मर्ज किया गया कमिट मॉड्यूल संस्करण या जुड़ी हुई Python निर्भरताएँ बदलता है, तो Odoo.sh एक स्वचालित बैकअप भी बनाता है, जिसे Update बैकअप के रूप में चिह्नित किया जाता है। यदि कोई मर्ज इन्हें नहीं बदलता, तो कोई बैकअप ट्रिगर नहीं होता, इसलिए प्रोडक्शन में महत्वपूर्ण बदलावों से पहले मैनुअल बैकअप लें।

• बैकअप की समीक्षा करने, उन्हें डाउनलोड करने या रीस्टोर करने के लिए प्रोडक्शन ब्रांच के Backups टैब का उपयोग करें।
• जब आप वास्तविक डेटा पर परीक्षण करना चाहें, तो प्रोडक्शन बैकअप को किसी स्टेजिंग ब्रांच में रीस्टोर करें।
• मानक डेटाबेस मैनेजर, Odoo Online डेटाबेस मैनेजर, Backups टैब या किसी बिल्ड के Download DB dump विकल्प से आए आर्काइव लाने के लिए Import Database सुविधा का उपयोग करें।

ऑन-प्रिमाइस: हर चीज़ आपकी टीम की ज़िम्मेदारी

आपके अपने सर्वर पर तब तक कुछ भी बैकअप नहीं होता जब तक आप उसे सेट अप न करें। आधिकारिक डिप्लॉयमेंट मार्गदर्शन सीधा है: अपने डेटाबेस और फ़ाइलस्टोर डेटा के दैनिक बैकअप सेट अप करें, और उन्हें ऐसे रिमोट आर्काइविंग सर्वर पर कॉपी करें जो स्वयं उस सर्वर से सुलभ न हो।

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

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

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

डेटाबेस की सुरक्षित डुप्लिकेट बनाना: न्यूट्रलाइज़ेशन

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

टेस्ट डेटाबेस हमेशा न्यूट्रलाइज़ किए जाते हैं, जिनमें बैकअप कॉपियाँ, डुप्लिकेट, और Odoo.sh के स्टेजिंग तथा डेवलपमेंट डेटाबेस शामिल हैं। दस्तावेज़ों में निष्क्रिय की जाने वाली चीज़ों की सूची स्पष्ट रूप से संपूर्ण नहीं है, और इसमें निम्नलिखित शामिल हैं।

• शेड्यूल्ड ऐक्शन, जैसे स्वचालित सब्सक्रिप्शन इनवॉइसिंग और मास मेलिंग।
• बाहर जाने वाले ईमेल, जो Odoo.sh स्टेजिंग पर भेजे जाने के बजाय एक मेल कैचर द्वारा रोक लिए जाते हैं।
• बैंक सिंक्रोनाइज़ेशन, पेमेंट प्रोवाइडर और डिलीवरी विधियाँ।
• IAP टोकन, और सर्च इंजनों के लिए वेबसाइट की दृश्यता।

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

रिटेंशन, ऑफ़साइट कॉपियाँ, RPO और RTO

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

दो सरल माप यह तय करने में मदद करते हैं कि आपको कितनी सुरक्षा चाहिए। Recovery Point Objective, या RPO, यह है कि आप हाल का कितना डेटा खोना सहन कर सकते हैं; दैनिक बैकअप का अर्थ है कि आप एक दिन तक का काम खो सकते हैं। Recovery Time Objective, या RTO, यह है कि सिस्टम के रीस्टोर होने के दौरान व्यवसाय उसके बिना कितनी देर तक काम कर सकता है।

इन लक्ष्यों पर प्रबंधन से सहमति लें, फिर जाँचें कि क्या आपका मौजूदा सेटअप इन्हें पूरा करता है। यदि पूरे दिन के सेल्स ऑर्डर खोना अस्वीकार्य है, तो केवल दैनिक बैकअप पर्याप्त नहीं हैं, और आपको अपने होस्टिंग प्रदाता या IT टीम से अधिक बार स्नैपशॉट या अन्य उपायों पर चर्चा करनी चाहिए।

रीस्टोर परीक्षण और एक व्यावहारिक चेकलिस्ट

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

• पुष्टि करें कि आप किस होस्टिंग प्रकार का उपयोग करते हैं और बैकअप की ज़िम्मेदारी किसकी है।
• सत्यापित करें कि बैकअप में डेटाबेस डंप और फ़ाइलस्टोर दोनों शामिल हैं।
• डाउनलोड की गई एक स्वतंत्र कॉपी किसी अलग, सुरक्षित स्थान पर रखें।
• अपग्रेड, बड़े इम्पोर्ट या प्रमुख कॉन्फ़िगरेशन बदलावों से पहले मैनुअल बैकअप लें।
• सभी परीक्षणों के लिए न्यूट्रलाइज़ किए गए डुप्लिकेट या स्टेजिंग ब्रांचों का उपयोग करें।
• नियमित रूप से किसी बैकअप को टेस्ट वातावरण में रीस्टोर करें और परिणाम दर्ज करें।
• अपने RPO और RTO लक्ष्यों का दस्तावेज़ीकरण करें और हर वर्ष उनकी समीक्षा करें।
• ऑन-प्रिमाइस में सार्वजनिक डेटाबेस मैनेजर को निष्क्रिय करें और मास्टर पासवर्ड को सुरक्षित रखें।

1CBMS कैसे मदद कर सकता है

1CBMS मिस्र और इराक में Odoo 19 परियोजनाओं के लिए Odoo Online, Odoo.sh और ऑन-प्रिमाइस सर्वर पर बैकअप और पुनर्प्राप्ति दिनचर्याएँ डिज़ाइन करता है और उनकी समीक्षा करता है। हम आपके मौजूदा सेटअप का ऑडिट कर सकते हैं, आपके प्रबंधन के साथ यथार्थवादी RPO और RTO लक्ष्य तय कर सकते हैं, न्यूट्रलाइज़ किए गए टेस्ट वातावरण सेट अप कर सकते हैं, और आपकी टीम के साथ एक दस्तावेज़ीकृत रीस्टोर परीक्षण चला सकते हैं, ताकि पुनर्प्राप्ति एक आपात स्थिति के बजाय एक अभ्यास की हुई प्रक्रिया हो।