तुमच्या अ‍ॅप डेटाबेसचा बॅकअप कसा घ्यावा (आणि तो खरोखर रिस्टोअर कसा करावा)

तुमच्या अ‍ॅप डेटाबेसचा बॅकअप घेण्यासाठी, तो ठरावीक वेळापत्रकानुसार एका फाइलमध्ये एक्सपोर्ट करा (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 नियम सहसा असा म्हटला जातो: तुमच्या डेटाच्या तीन प्रती, दोन वेगवेगळ्या प्रकारच्या स्टोरेजवर, आणि एक प्रत साइटबाहेर. छोट्या अ‍ॅपसाठी व्यावहारिक रूप असे आहे:

• लाइव्ह डेटाबेस
• प्रोव्हायडरचे स्वतःचे स्वयंचलित बॅकअप
• तुमचे स्वतःचे डंप, वेगळ्या खात्यातील object storage बकेटसारख्या वेगळ्या स्टोरेजमध्ये

याशिवाय:

• प्रवेश मर्यादित ठेवा. बॅकअपमध्ये प्रत्येक वापरकर्त्याचा डेटा असतो. त्याला लाइव्ह डेटाबेसप्रमाणे वागवा.
• धारणा धोरण (retention policy) ठेवा. उदाहरणार्थ, दोन आठवडे दैनिक बॅकअप आणि एक वर्ष मासिक बॅकअप. जुने बॅकअप जाणूनबुजून हटवा, आणि लक्षात ठेवा की गोपनीयता कायद्यांनुसार विनंती केल्यावर वैयक्तिक डेटा हटवावा लागू शकतो.
• बॅकअप कधीही Git मध्ये commit करू नका. रिपॉझिटरीमधील डंप म्हणजे डेटा गळतीची वाट पाहणारी गोष्ट.

पायरी 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 डेटाबेस असू शकतो, आणि त्याचे कनेक्शन तपशील workspace आणि प्रकाशित अ‍ॅपमध्ये इंजेक्ट केले जातात. Mythex डॉक्समध्ये डेटाबेस बॅकअप किंवा रिस्टोअर फीचरचे वर्णन नाही, त्यामुळे स्वतःची योजना करा: एजंटला डंप तयार करायला सांगा, तो डाउनलोड करा आणि सुरक्षित ठिकाणी ठेवा, विशेषतः मोठ्या बदलांपूर्वी. प्रोजेक्ट एक्सपोर्ट (Pro) मध्ये तुमचा कोड असतो, सिक्रेट्स आणि node_modules वगळून; त्यात डेटाबेसच्या रो नसतात. डॉक्समध्ये Database आणि Data ownership पाहा. डेटाबेसबद्दल अधिक माहितीसाठी Postgres म्हणजे काय वाचा.

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

• तुम्ही किती डेटा गमावू शकता आणि किती वेळ बंद राहू शकता हे ठरवले
• तुमचा डेटाबेस होस्ट कोणते स्वयंचलित बॅकअप देतो ते तपासले
• तुमचा स्वतःचा डंप ठरावीक वेळापत्रकानुसार चालतो, आणि अपयशाची सूचना मिळते
• प्रती डेटाबेसपासून वेगळ्या ठिकाणी, मर्यादित प्रवेशासह ठेवल्या आहेत
• धारणा धोरण लिहून ठेवले आहे
• अपलोड केलेल्या फाइल्सचाही डेटाबेसइतकाच बॅकअप घेतला जातो
• रिस्टोअर रिकाम्या डेटाबेसमध्ये तपासला, रो ची संख्या पडताळली
• प्रत्येक धोकादायक बदलापूर्वी बॅकअप घेतला जातो

प्रश्न