सहायता से संपर्क करें

हम ईमेल से जवाब देते हैं, आम तौर पर दो दिन के अंदर।

Google reCAPTCHA दुरुपयोग से बचाव के लिए इस सबमिशन की जाँच करता है; इसके लिए डेटा Google को भेजा जाता है। स्क्रिप्ट तभी लोड होती है, जब यह फ़ॉर्म खोला जाता है।

← सभी पोस्ट

बैकअप को शुरू से आखिर तक रीस्टोर किया गया

यह सर्वर 11 अगस्त से हर रात अपना बैकअप लेता आ रहा है। लॉग में 163 लाइनें हैं। उनमें से किसी में भी “restore” शब्द नहीं है, क्योंकि हर लाइन लिखने के बारे में है।

आज पढ़ने वाले आधे हिस्से को भी पूरा चलाकर देखा गया।

रात का बैकअप क्या जाँचता है एग्ज़िट कोड · कम से कम 1 MB · दूसरे छोर पर बाइट · लॉग में एक लाइन क्या इसे वापस पढ़ा जा सकता है? — 163 लॉग लाइनें, एक बार भी नहीं आज रीस्टोर किया गया: 437 MB के डंप में से 104 MB काउंटर डेटा 38 में से 38 टेबल, पंक्तियों की संख्या 03:00 बजे के डंप से मेल खाती है एक मिनट चवालीस सेकंड, एक अस्थायी डेटाबेस में, फिर हटा दिया गया

यह बैकअप ज़्यादातर बैकअप से बेहतर है

यह सुबह तीन बजे चलता है, हर डेटाबेस का डंप बनाता है, वेब रूट को पैक करता है, दोनों को एक ऐसे पासफ़्रेज़ से एन्क्रिप्ट करता है जो स्टोरेज प्रदाता के पास नहीं है, और उन्हें अपलोड करता है। फिर यह तीन ऐसे काम करता है, जिन्हें बहुत-सी बैकअप स्क्रिप्ट छोड़ देती हैं।

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

और यह काम भी करता है। 26 अगस्त को 03:05 बजे आर्काइव करने वाला चरण विफल हुआ, स्क्रिप्ट रुक गई और लॉग में यह बात दर्ज की, और उसी सुबह रन को हाथ से दोहराया गया। बाईस बार शुरू हुआ, उन्नीस बार पूरा हुआ, और यह अंतर चुपचाप छिपा नहीं, बल्कि साफ़ दिखता है। ज़ोर से बताकर रुकने का पूरा मकसद यही है।

इनमें से कुछ भी रीस्टोर नहीं है

इनमें से हर जाँच लिखने वाले रास्ते के बारे में है: क्या डंप बना, क्या उसका आकार विश्वसनीय था, क्या बाइट पहुँचे। जिस बैकअप को वापस पढ़ा न जा सके, वह भी इन सभी जाँचों में पास हो जाता है।

इसलिए आज पिछली रात के डंप का काउंटर वाला आधा हिस्सा एन्क्रिप्टेड रिमोट स्टोरेज से उतारा गया, डिक्रिप्ट किया गया, 437 मेगाबाइट की पूरी फ़ाइल में से काटकर निकाला गया, और लाइव डेटाबेस के बगल में एक डेटाबेस में लोड किया गया। कुल 104 मेगाबाइट। शुरू से अंत तक एक मिनट चवालीस सेकंड।

बैकअप में अड़तीस टेबल। लाइव डेटाबेस में अड़तीस। हर जगह पंक्तियों की संख्या लाइव से कुछ सौ कम, जो उस डंप के लिए बिल्कुल सही है जो सुबह तीन बजे ऐसी सेवा पर लिया गया हो, जो पूरे दिन गिनती करती रही है।

दो बातें, जो सिर्फ़ यह अभ्यास ही पकड़ सकता था

जो यूज़र बैकअप ढूँढ़ने जाएगा, वह उसे पढ़ ही नहीं सकता। रात का जॉब root के रूप में चलता है। सामान्य लॉग इन खाते से वही फ़ाइलें माँगने पर स्टोरेज टूल बताता है कि उसका एक्सेस टोकन अब वैध नहीं है। संदेश ऑथेंटिकेशन के बारे में है, पर जल्दबाज़ी में, गलत वक्त पर, वह बिल्कुल “यहाँ कुछ नहीं है।” जैसा ही लगता है।

बैकअप में कोई खराबी नहीं है। उसे चलाने वाला खाता भी ठीक है। लेकिन आपात स्थिति में कोई भी सबसे पहले देखता है, और गलत यूज़र के रूप में देखने पर ऐसा जवाब मिलता है जो किसी को बहुत गलत रास्ते पर भेज सकता है। यह बात अब रीस्टोर के निर्देशों के साथ लिख दी गई है।

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

क्या अब भी जाँचा नहीं गया है

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

तो आज के बाद ईमानदार स्थिति यह है: एन्क्रिप्टेड स्टोरेज से काम करते डेटाबेस तक की कड़ी एक बार, शुरू से अंत तक, चलाकर देखी गई है, और इसमें दो मिनट से कम लगे। जले हुए घर से काम करते डेटाबेस तक की कड़ी नहीं।

आम सबक

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

इस अभ्यास को लिखने में लगभग दस मिनट लगे और चलाने में दो से कम, और इसने एक ऐसा तथ्य सामने रखा जो लॉग की कितनी भी हरी लाइनें नहीं दे सकती थीं: कि रिकवरी के रास्ते में ऑथेंटिकेशन का एक ऐसा कदम है, जिससे कोई गुज़रा नहीं था। दूसरे अभ्यास में दो मिनट लगेंगे, क्योंकि स्क्रिप्ट अब मौजूद है। इसे करने का तर्क यही है — यह नहीं कि बैकअप पर शक था, बल्कि यह कि “हमारे पास बैकअप हैं” और “हमने रीस्टोर किया है” दो अलग वाक्य हैं, और उनमें से सिर्फ़ एक माप है।

विज्ञापन