अपने ऐप डेटाबेस का बैकअप कैसे लें (और उसे सच में रिस्टोर कैसे करें)

अपने ऐप डेटाबेस का बैकअप लेने के लिए, उसे तय समय पर एक फ़ाइल में एक्सपोर्ट करें (Postgres के लिए मानक टूल pg_dump है), कॉपियाँ डेटाबेस से अलग जगह रखें, और नियमित रूप से किसी एक बैकअप को खाली डेटाबेस में रिस्टोर करके साबित करें कि वह काम करता है। किसी भी जोखिम भरे बदलाव से ठीक पहले एक अतिरिक्त बैकअप लें। आपका कोड बैकअप, चाहे वह GitHub रिपॉज़िटरी हो या एक्सपोर्ट, आपका डेटा शामिल नहीं करता।

यह गाइड उन लोगों के लिए है जो एक छोटा ऐप चलाते हैं और चाहते हैं कि उसे खोने की चिंता खत्म हो। उदाहरणों में Postgres का उपयोग किया गया है, क्योंकि ज़्यादातर AI से बने ऐप्स इसी का इस्तेमाल करते हैं, लेकिन ये सिद्धांत किसी भी डेटाबेस पर लागू होते हैं।

बैकअप में क्या शामिल होना चाहिए

एक ऐप सिर्फ़ उसके डेटाबेस से बढ़कर होता है। जानें कि हर बैकअप किस हिस्से की रक्षा करता है।

डेटा वह हिस्सा है जिसे दोबारा नहीं बनाया जा सकता। कोड फिर से लिखा जा सकता है और सेटिंग्स दोबारा भरी जा सकती हैं, लेकिन आपके ग्राहकों के ऑर्डर नहीं।

चरण 1: तय करें कि आप कितना खो सकते हैं

दो सवाल आपकी बैकअप योजना तय करते हैं:

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

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

चरण 2: देखें कि आपका होस्ट पहले से क्या करता है

कई मैनेज्ड डेटाबेस प्रोवाइडर अपने आप बैकअप लेते हैं। पता करें:

• क्या आपके प्लान में बैकअप चालू हैं, और वे कितनी बार चलते हैं?
• उन्हें कितने समय तक रखा जाता है?
• क्या आप किसी पॉइंट-इन-टाइम तक रिस्टोर कर सकते हैं, या सिर्फ़ रोज़ के स्नैपशॉट तक?
• क्या आप बैकअप डाउनलोड कर सकते हैं, या उसे सिर्फ़ उनके सिस्टम के अंदर ही रिस्टोर किया जा सकता है?

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

चरण 3: pg_dump से डंप बनाएँ

pg_dump Postgres डेटाबेस को एक फ़ाइल में एक्सपोर्ट करता है। यह एक सुसंगत स्नैपशॉट पढ़ता है, इसलिए काम करते समय ऐप चलता रह सकता है।

एक सामान्य कमांड, जो उस कनेक्शन स्ट्रिंग का उपयोग करता है जो आपके ऐप के पास पहले से एक एनवायरनमेंट वेरिएबल में है:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

विकल्प क्या करते हैं:

• --format=custom एक कम्प्रेस्ड फ़ाइल लिखता है जिसे pg_restore पढ़ सकता है, और बाद में अलग-अलग टेबल रिस्टोर करने देता है। अगर आप पढ़ी जा सकने वाली .sql फ़ाइल चाहते हैं, तो --format=plain इस्तेमाल करें।
• --no-owner ओनरशिप कमांड छोड़ देता है, जिससे किसी दूसरे डेटाबेस में रिस्टोर करना आसान होता है।
• फ़ाइल के नाम में तारीख बैकअप को अलग-अलग रखती है।

pg_dump का संस्करण आपके डेटाबेस के Postgres संस्करण जितना, या उससे नया होना चाहिए। पुराना pg_dump चलने से मना कर सकता है।

अगर आप AI से ऐप बनाते हैं और कमांड लाइन छूना नहीं चाहते, तो आप यह पूछ सकते हैं:

ऐप के डेटाबेस का pg_dump से custom फ़ॉर्मेट में बैकअप बनाओ, फ़ाइल के नाम में आज की तारीख रखो। कोई कनेक्शन स्ट्रिंग या सीक्रेट प्रिंट मत करना। पूरा होने पर मुझे फ़ाइल का नाम और उसका साइज़ बताओ।

चरण 4: इसे स्वचालित करें

मैन्युअल बैकअप अक्सर भूल जाए जाते हैं। उन्हें अपने सेटअप के हिसाब से स्वचालित करें:

• आपके डेटाबेस प्रोवाइडर के तय बैकअप, अगर वह देता है।
• एक शेड्यूल्ड जॉब किसी सर्वर या CI सेवा पर, जो pg_dump चलाती है और फ़ाइल को स्टोरेज पर अपलोड करती है।
• एक होस्टेड बैकअप सेवा जो आपके डेटाबेस से जुड़ती है।

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

चरण 5: कॉपियाँ कहीं और रखें

नियम को अक्सर 3-2-1 कहा जाता है: आपके डेटा की तीन कॉपियाँ, दो अलग प्रकार के स्टोरेज पर, और एक कॉपी किसी दूसरी जगह। एक छोटे ऐप के लिए एक व्यावहारिक रूप यह है:

• लाइव डेटाबेस
• प्रोवाइडर के अपने स्वचालित बैकअप
• आपके अपने डंप, किसी अलग खाते के ऑब्जेक्ट स्टोरेज बकेट जैसे अलग स्टोरेज में

इसके अलावा:

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

चरण 6: रिस्टोर का परीक्षण करें

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

1. एक नया, खाली डेटाबेस बनाएँ। परीक्षण के लिए लाइव डेटाबेस के ऊपर कभी रिस्टोर न करें।
2. नवीनतम बैकअप को उसमें रिस्टोर करें:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

सादी .sql फ़ाइल के लिए इसके बजाय psql "$TEST_DATABASE_URL" -f backup.sql इस्तेमाल करें।

1. जाँचें कि हर टेबल मौजूद है, पंक्तियों की गिनती लाइव डेटाबेस से मिलाएँ, और कुछ हाल के रिकॉर्ड देखें।
2. अगर संभव हो, ऐप की एक कॉपी को उससे जोड़कर लॉग इन करें।
3. लिख लें कि रिस्टोर में कितना समय लगा। वही आपका असली रिकवरी समय है।

चरण 7: जोखिम भरे बदलावों से पहले बैकअप लें

हर बार इनसे ठीक पहले ताज़ा बैकअप लें:

• कोई डेटाबेस माइग्रेशन चलाना जो कॉलम हटाता या नाम बदलता है
• बड़ी मात्रा में डेटा इंपोर्ट करना
• AI एजेंट को डेटा मॉडल में बड़े बदलाव करने देना
• पुराने रिकॉर्ड हटाना

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

आम गलतियाँ

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

बैकअप और Mythex

Mythex प्रोजेक्ट्स में एक समर्पित Postgres डेटाबेस हो सकता है, और उसके कनेक्शन विवरण वर्कस्पेस और प्रकाशित ऐप में इंजेक्ट होते हैं। Mythex के दस्तावेज़ों में डेटाबेस बैकअप या रिस्टोर फ़ीचर का वर्णन नहीं है, इसलिए अपना बैकअप खुद योजना बनाएँ: एजेंट से डंप बनवाएँ, उसे डाउनलोड करें और सुरक्षित जगह रखें, खासकर बड़े बदलावों से पहले। प्रोजेक्ट एक्सपोर्ट (Pro) में आपका कोड होता है, जिसमें सीक्रेट्स और node_modules नहीं होते; उसमें डेटाबेस की पंक्तियाँ नहीं होतीं। दस्तावेज़ों में Database और Data ownership देखें। डेटाबेस के बारे में ज़्यादा जानने के लिए Postgres क्या है पढ़ें।

बैकअप चेकलिस्ट

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

सवाल