ऐसे बैकअप जो सच में रिस्टोर होते हैं

वे विफलताएँ जिन्हें कोई टेस्ट नहीं करता

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

इंसानी चूकें भी उतनी ही आम हैं: बैकअप बकेट के क्रेडेंशियल्स महीनों पहले एक्सपायर हो चुके हैं, या रिस्टोर तकनीकी रूप से चलता तो है लेकिन पूरा दिन लेता है क्योंकि किसी ने उसे प्रोडक्शन-आकार के डेटा पर कभी मापा ही नहीं। ये सभी 'क्या हमारे पास बैकअप हैं?' वाली चेकलिस्ट पास कर लेते हैं। रिस्टोर इनमें से कोई पास नहीं करता।

हम क्या बैकअप करते हैं, और कितनी बार

Anested Cloud पर हर मैनेज्ड डेटाबेस — PostgreSQL, MongoDB और MySQL — का रोज़ाना स्नैपशॉट अपने आप बनता है, बिना किसी कॉन्फ़िगरेशन के। रिटेंशन विंडो आपके प्लान के साथ बढ़ती है, ताकि ज़रूरत बढ़ने पर आप इतिहास में और पीछे तक जा सकें, और शेड्यूल कभी इस पर निर्भर नहीं करता कि किसी को क्रॉन जॉब याद रहे।

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

रिस्टोर एक प्रोडक्ट फ़ीचर है, रनबुक नहीं

बहुत सारे स्टैक में 'रिस्टोर' का मतलब है दो साल पुराना विकी पेज, तीन ssh सेशन और एक दुआ। हम रिस्टोर को पहले दर्जे का प्रोडक्ट फ़ीचर मानते हैं: डैशबोर्ड से स्नैपशॉट चुनें और एक क्लिक में उसे नए डेटाबेस पर रिस्टोर करें, जबकि मूल डेटाबेस बिना छुए चलता रहता है।

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

• हमेशा नए इंस्टेंस पर रिस्टोर — मौजूदा को कभी ओवरराइट नहीं
• चेकसम और रो-काउंट रिपोर्ट से पुष्टि करें
• मूल डेटाबेस 7 दिनों तक सुरक्षित रहता है

आपका हिस्सा: एक रिस्टोर टेस्ट करें

मशीनरी हम संभालते हैं, लेकिन आपके डेटा के लिए 'सही' कैसा दिखता है, यह सिर्फ़ आप जानते हैं। सबसे अच्छी आदत है तिमाही रिस्टोर ड्रिल: ताज़ा बैकअप को स्टेजिंग डेटाबेस में लाएँ और जाँचें कि आँकड़े तर्कसंगत हैं। इसमें लगभग 10 मिनट लगते हैं, और यह आपके बैकअप को उम्मीद से सबूत में बदल देती है।

PostgreSQL डेटाबेस के लिए पूरी ड्रिल तीन लाइनों में समा जाती है। इसे एक स्क्रिप्ट में रखें, कैलेंडर में रिमाइंडर लगाएँ, और हर तिमाही एक बार चलाएँ:

# restore drill
pg_dump "$PROD_URL" | psql "$STAGING_URL"
psql "$STAGING_URL" -c "select count(*) from users;"

फ़ाइलों के लिए भी बैकअप

सुरक्षा के लायक़ सिर्फ़ डेटाबेस ही नहीं हैं। Nest Storage पर यूज़र अपलोड और स्टैटिक एसेट को ऑब्जेक्ट वर्ज़निंग से सुरक्षित किया जा सकता है, ताकि ग़लती से हुआ ओवरराइट या डिलीट पिछले वर्ज़न को हमेशा के लिए मिटाने के बजाय रिकवर करने लायक़ छोड़ जाए।

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