VPN के लौटने के बाद भी आपका NAS बैकअप विफल रहा

VPN 06:10 बजे फिर से जुड़ता है, डैशबोर्ड टनल को हरा दिखाता है, और रात का बैकअप अभी भी बिना नए रिकवरी पॉइंट के है। यह विरोधाभास नहीं है; ये दो समय-सारणियाँ हैं जिन्हें कभी समन्वित नहीं किया गया। ठीक होने वाली टनल एक नेटवर्क घटना है। पूरी होने वाली बैकअप एक एप्लिकेशन घटना है जिसकी अपनी स्टेट मशीन है, और बाधित रन को निलंबित, रद्द या पूरी तरह किसी और चीज़ के पीछे कतार में रखा जा सकता है।

विंडो को पूर्ण हुए रिकवरी पॉइंट के आसपास योजना बनाएँ, टनल के सूचक लैंप के आसपास नहीं।

शुरुआत के समय से नहीं, रिकवरी पॉइंट से शुरू करें

आवश्यकता को स्वीकृत संस्करण के लिए समय-सीमा के रूप में लिखें: एक नया रिकवरी पॉइंट जो निर्धारित समय तक कार्य की अपनी अखंडता जाँच पास कर ले। फिर अपेक्षित अवधि, सामान्य भिन्नता और एक बाधित प्रयास से होकर पीछे काम करें। लॉन्च समय कोई प्रतिबद्धता नहीं है; यह केवल वह क्षण है जब शेड्यूलर ने प्रयास किया। समय-सीमा को चैट संदेश में नहीं, बैकअप नीति में रखें। केवल किसी की स्मृति में जीवित संख्या निगरानी सीमा नहीं है।

अवधि अनुमान के लिए कार्य के इतिहास का उपयोग करें। चंक प्रोसेसिंग, डिडुप्लिकेशन और इंडेक्स कार्य रन का हिस्सा हैं, इसलिए बदले हुए बाइट्स को लिंक गति से विभाजित करना विंडो को कम आँकता है, जो बाद में नेटवर्क समस्या जैसा दिखता है।

रुकावट कार्य के साथ क्या करती है

Hyper Backup उस काम में अंतर करता है जो फिर से शुरू हो सकता है और जो नहीं हो सकता: प्रलेखित व्यवहार यह है कि कनेक्शन टूटने पर फिर से शुरू होने योग्य कार्य निलंबित हो जाते हैं और न होने योग्य कार्य रद्द हो जाते हैं। दोनों में से कोई भी स्थिति VPN क्लाइंट से दिखाई नहीं देती, और किसी को भी टनल फिर से जोड़कर ठीक नहीं किया जाता। अगला निर्धारित रन वहीं से शुरू होगा जहाँ पुराना रुका था, यह मानने से पहले कार्य की स्थिति और उसका दर्ज कारण पढ़ें।

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

गंतव्य की अपनी आवश्यकताएँ हैं

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

यदि गंतव्य NAS स्वयं रीबूट हुआ है, तो बैकअप कार्य शुरू होने के समय उसकी सेवाएँ अभी भी शुरू हो रही हो सकती हैं। छोटी तैयारी जाँच विफल रन और पुनः प्रयास से सस्ती है।

अखंडता जाँचें उन्हीं घंटों के लिए प्रतिस्पर्धा करती हैं

अखंडता जाँच बिना किसी नेटवर्क विफलता के विंडो को खा सकती है। DSM प्रति कार्य एक सक्रिय प्रक्रिया प्रलेखित करता है, और निर्धारित बैकअप उस कार्य की अखंडता जाँच के पीछे प्रतीक्षा कर सकता है और फिर लगभग तीन घंटे की अधिकतम प्रतीक्षा के बाद छोड़ दिया जा सकता है। अवलोकित अवधियों के अनुसार दोनों समय-सारणियों में अंतर रखें, और छूटे हुए रन को VPN के फिर विफल होने का प्रमाण नहीं, बल्कि शेड्यूलिंग संबंधी निष्कर्ष मानें।

वास्तविक डिलीवरी विधि के साथ सूचनाएँ सक्षम करें, फिर उन्हें पढ़ने के लिए किसी को नियुक्त करें। जो कार्य कभी शुरू नहीं हुआ और जो आधे रास्ते विफल हुआ, वे समान चेतावनी नहीं दे सकते।

सुबह की जाँच प्रति बनाएँ

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

समय-चिह्नों को एक ही समय क्षेत्र में दर्ज करें, जिसमें शेड्यूलर का क्षेत्र, गंतव्य का क्षेत्र और डैशबोर्ड पढ़ने वाले व्यक्ति का क्षेत्र शामिल है। इन जाँचों में से एक से अधिक नेटवर्क खराबी के बजाय घड़ी के अंतर पर समाप्त होती हैं, और नोट ही उसे अगली बार दृश्यमान बनाता है।