यह प्रश्न तीन अलग-अलग बातों को छूता है, और इनके उत्तर भी अलग-अलग हैं। ऐप के अंदर की गई कोई भी डिलीट वापस ली जा सकती है: कोई भी डेटा वास्तव में मिटाया नहीं जाता, बल्कि पंक्ति एक कचरा पेटी में चली जाती है, जहाँ से एक बटन के ज़रिए उसे पुनर्स्थापित किया जा सकता है। आप अपने डेटा को जब चाहें बाहर निकाल सकते हैं, हर सूची के लिए अलग से एक्सपोर्ट का विकल्प होता है। लेकिन किसी डिप्लॉय की गई ऐप के डेटाबेस का कोई स्वचालित बैकअप उत्पाद की डिप्लॉयमेंट श्रृंखला में कहीं भी प्रदान नहीं किया जाता, डिप्लॉयमेंट कोड में कोई बैकअप कमांड नहीं है, और इसकी व्यवस्था होस्टिंग प्रदाता की ज़िम्मेदारी है सरल शब्दों में कहें तो: एक गलत क्लिक खुद-ब-खुद ठीक हो जाता है, लेकिन एक खोया हुआ डेटाबेस कभी वापस नहीं आता। यह पृष्ठ स्पष्ट रूप से बताता है कि यह सीमा कहाँ खींची गई है, ताकि आप वास्तविक डेटा डालने से पहले सही प्रश्न पूछ सकें।
आपकी ऐप के अंदर डिलीट करने से कुछ भी नष्ट नहीं होता
‘डिलीट’ बटन कोई डेटा मिटाता नहीं, बल्कि एक विशेष कॉलम के ज़रिए उस पंक्ति को ‘डिलीट किया गया’ के रूप में चिह्नित कर देता है। इसके बाद वह पंक्ति सूचियों, कुल योग और सूचकों से गायब हो जाती है, लेकिन डेटाबेस में वह अभी भी मौजूद रहती है। जैसे ही कोई पंक्ति डिलीट की जाती है, सेटिंग्स में एक ‘कचरा पेटी’ कार्ड दिखाई देता है, जिस पर ‘पुनर्स्थापित करें’ बटन होता है। यह डिलीवर किए गए कोड में जाँचा जा सकता है: उत्पन्न हुई किसी भी रूट में डेटाबेस की स्थायी डिलीट कमांड नहीं है।
इसके अतिरिक्त, डिलीट की पुष्टि के लिए दो-चरणीय प्रक्रिया है, पहला क्लिक डिलीट को ‘सक्रिय’ करता है, और दूसरा क्लिक उसे अंतिम रूप देता है, ब्राउज़र के सामान्य पुष्टि डायलॉग के बजाय। इसलिए दिन के अंत में गलती से एक अतिरिक्त क्लिक करने का सबसे आम मामला मात्र तीस सेकंड में ठीक किया जा सकता है, और किसी को फ़ोन करने की भी आवश्यकता नहीं होती। यह तीनों परतों में से एकमात्र परत है जिसे ऐप पूरी तरह स्वतंत्र रूप से संभालती है, और इसीलिए यह सबसे पहले आती है।
जब चाहें, अपने डेटा को बाहर निकालें
हर सूची के लिए CSV एक्सपोर्ट का एक बटन होता है। यह वे पंक्तियाँ एक्सपोर्ट करता है जो आप *देखते* हैं, जो वर्तमान खोज और सक्रिय फ़िल्टर्स के अनुसार फ़िल्टर की गई हों, और बटन के लेबल पर जाने वाली पंक्तियों की संख्या भी दिखाई जाती है। ऐसा कभी नहीं होता कि आपकी स्क्रीन पर न दिख रहे डेटा को चुपचाप एक्सपोर्ट कर दिया जाए। यह फ़ाइल फ्रेंच भाषा के स्प्रेडशीट में सही ढंग से खुलने के लिए बनाई गई है, जिसमें आमतौर पर एक्सपोर्ट्स में आने वाली टूटी हुई एक्सेंट्स की पंक्ति नहीं होती।
यह एक प्रति है जो आपके पास है, और इसे उसी नाम से जाना जाना चाहिए जो यह है: यह तकनीकी रूप से कोई ‘बैकअप’ नहीं है। एक CSV ऐप को पुनर्स्थापित नहीं कर सकता, इसमें आपकी टेबल्स के बीच के लिंक नहीं होते, न ही कोई इतिहास होता है, न ही वह कुछ भी होता है जो डिलीट किया गया हो। इसका उद्देश्य आपको नियंत्रण वापस देना है: अपने आँकड़ों को स्प्रेडशीट में खोलना, अपने लेखापरीक्षक को भेजना, या किसी अन्य उपकरण को डेटा देना। यह आपको बंद करने से रोकता है, लेकिन किसी विफलता से आपकी रक्षा नहीं करता।
जो काम नहीं किया जाता, और जिस पर आपको निर्णय लेना होगा
जब आपकी ऐप डिप्लॉय की जाती है, तो उसे अपना स्वतंत्र PostgreSQL डेटाबेस मिलता है। लेकिन डिप्लॉयमेंट चेन में उसका कोई बैकअप नहीं लिया जाता: ऐप्स को डिप्लॉय करने वाले कोड में कोई भी बैकअप कमांड नहीं है। यह कोई छुपाया हुआ भूल नहीं है, बल्कि एक स्पष्ट सीमा है, बैकअप का निर्धारण इस बात पर निर्भर करता है कि ऐप कहाँ चल रही है, इसलिए यह उस व्यक्ति की ज़िम्मेदारी है जो उसे होस्ट कर रहा है, चाहे वह आप हों, आपका सेवा प्रदाता हो, या हम जब हम उसे होस्ट कर रहे हों।
इसे स्पष्ट करने के लिए केवल तीन प्रश्न पर्याप्त हैं, और ये प्रश्न आपको वास्तविक डेटा डालने से पहले पूछने चाहिए। कौन बैकअप की प्रति बनाता है, और कितनी बार? वह प्रति कहाँ संग्रहित है, क्या वह ऐप चलाने वाली मशीन से अलग कहीं रखी गई है, अन्यथा एक ही विफलता दोनों को नष्ट कर देगी? और सबसे महत्वपूर्ण: क्या किसी ने उस प्रति से कभी *पुनर्स्थापना* की है? तीसरा प्रश्न वह है जिसे अक्सर भूल जाया जाता है, और यही एकमात्र प्रश्न है जो कुछ साबित करता है: कोई भी बैकअप जिसकी कभी पुनर्स्थापना नहीं की गई, वास्तव में कोई बैकअप नहीं है, बल्कि यह एक अनुमान मात्र है।
आप जो भी डालते हैं, उसके आधार पर यह क्या बदलता है
सब कुछ एक जैसी व्यवस्था की आवश्यकता नहीं रखता। एक ऐसे उपकरण के लिए, जिसका सामग्री फिर से बनाई जा सकती है, जैसे साप्ताहिक शेड्यूल या एक हल्का ट्रैकिंग जिसे आप एक घंटे में फिर से टाइप कर सकते हैं, कहीं रखा गया मासिक एक्सपोर्ट पर्याप्त है। दूसरी ओर, एक ऐसे रिकॉर्ड के लिए जिसे फिर से नहीं बनाया जा सकता, जैसे आपके सदस्य, आपके सेवा कॉल्स का इतिहास, या आपके चल रहे मामलों की फाइलें, डेटाबेस का स्वचालित बैकअप एक अनिवार्य शर्त है, न कि कोई वैकल्पिक सुविधा: कोई भी तीन साल का इतिहास याद से फिर से नहीं लिख सकता।
अच्छी खबर यह है कि इसमें कोई तकनीकी बाधा नहीं है: उत्पन्न कोड मानक Next.js और Prisma है, जो PostgreSQL डेटाबेस पर चलता है, और इसमें कोई प्रॉपराइटरी फॉरमैट नहीं है जिसे बाईपास करने की आवश्यकता हो। PostgreSQL डेटाबेस का बैकअप लेना एक ऐसा कार्य है जो कोई भी सेवा प्रदाता कर सकता है। इसलिए प्रश्न कभी भी ‘क्या यह संभव है?’ नहीं है, बल्कि ‘इसे कौन करता है, कब से कर रहा है, और क्या इसे कभी जाँचा गया है?’ है।