बैकअप 1s करने में विफल। पूर्ण बैकअप और डिफ बैकअप की परस्पर संबंधित आवधिकता

परंपरागत रूप से, 1C उपयोगकर्ताओं को दो श्रेणियों में विभाजित किया जाता है: वे जो बैकअप प्रतिलिपियाँ बनाते हैं *, और वे जो उन्हें करना शुरू करते हैं। अपनी गलतियों से न सीखने के लिए, आइए अभी से बैकअप बनाना शुरू करें।

*यदि आप पहले से ही बैकअप कर रहे हैं, तो यह लेख अभी भी आपके लिए उपयोगी होगा, क्योंकि आप इंटरनेट पर बैकअप के बारे में जो कुछ भी पा सकते हैं और पढ़ सकते हैं, वह आपके डेटा की सुरक्षा के लिए गलत और बहुत खतरनाक है। यदि आप एक आईटी विशेषज्ञ हैं, तो "एसक्यूएल का उपयोग करके 1 सी इन्फोबेस का बैकअप लेना" अनुभाग को पढ़ना जारी रखें।

क्या यह वास्तव में इस पर समय बिताने लायक है?

क्या हमारे समय में 1C सूचना आधार किसी तरह टूट सकता है? सब कुछ टूट जाता है: चायदानी और हवाई जहाज, एक स्टूल लेग और एक इलेक्ट्रॉन माइक्रोस्कोप। कच्चे लोहे की गेंद की तरह केवल कुछ बहुत ही सरल तोड़ना मुश्किल है। लेकिन 1C सूचना आधार एक जटिल वस्तु है और एक जटिल तकनीकी वातावरण में काम करता है। जल्दी या बाद में, कुछ होगा, पहले काफी महत्वहीन, और फिर "ढीला पेंच" सॉफ्टवेयर और हार्डवेयर विफलताओं की एक कैस्केड प्रतिक्रिया का कारण होगा, जो अंततः बड़ी परेशानियों और सूचना आधार के नुकसान में समाप्त हो जाएगा।

इन्फोबेस का फ़ाइल संस्करण

आइए सबसे सरल उदाहरण से शुरू करें। एक छोटे संगठन में, एक 1C कॉन्फ़िगरेशन एक फ़ाइल इंफोबेस के साथ काम करता है, जिसे एक आने वाले सिस्टम व्यवस्थापक द्वारा बनाए रखा जाता है, जो शायद सब कुछ सेट कर देता है। परंतु! संदेशों की अनुपस्थिति "बैकअप कॉन्फ़िगर नहीं किया गया" का अर्थ यह नहीं है कि यह अब कॉन्फ़िगर किया गया है। इसका मतलब यह भी हो सकता है कि संदेश केवल दिखाया नहीं गया है। इसलिए, हमारे काम के परिणामों की विश्वसनीयता और सुरक्षा की जिम्मेदारी लेते हुए, पहले सुनिश्चित करें कि इन्फोबेस एक फाइल है। यह कैसे करें नीचे दिए गए उदाहरण में स्पष्ट रूप से दिखाया गया है। यदि यह फ़ाइल = के बजाय Srv = कहता है, तो यह एक SQL डेटाबेस है और बैकअप सेट करने के लिए अपने DBA से संपर्क करें। यदि डेटाबेस फ़ाइल है, तो आप मैन्युअल या स्वचालित प्रतिलिपि का उपयोग कर सकते हैं।

मैनुअल तरीका- चित्र में दिखाए अनुसार एक बैकअप कॉपी बनाएं। उतारने से पहले, सभी उपयोगकर्ताओं को इन्फोबेस के साथ काम पूरा करना होगा। अपलोड .dt एक्सटेंशन वाली एकल बैकअप फ़ाइल बनाता है जिसमें शामिल है लगभग सभी(इस पर बाद में), इन्फोबेस में वर्तमान में क्या है, और इसके बाद क्या दर्ज किया जाएगा। फ़ाइल को एक सार्थक नाम दें (उदाहरण के लिए, "2017-10-31 पर व्यापार नियंत्रण बैकअप") और इसे सहेजने के लिए एक विशेष फ़ोल्डर चुनें (उदाहरण के लिए, "मेरे दस्तावेज़" फ़ोल्डर में "बैकअप" फ़ोल्डर)। इस फ़ाइल का उपयोग करके, आप बाद में इन्फोबेस को अनलोड करने से पहले की स्थिति में पुनर्स्थापित कर सकते हैं। पुनर्स्थापित करने के लिए, "इन्फोबेस लोड करें" ऑपरेशन का उपयोग करें।

एक विशिष्ट बैकअप सेटअप चित्रण में दिखाया गया है। यह सेटिंग मानती है कि प्रशासनिक अधिकारों वाला उपयोगकर्ता कार्य दिवस के अंत में प्रोग्राम को खुला छोड़ देता है (अन्यथा बैकअप नहीं किया जाएगा), और अन्य सभी उपयोगकर्ता प्रोग्राम को बंद कर देते हैं। एक वैकल्पिक विकल्प शटडाउन पर बैकअप करना है (यदि बैकअप की आवश्यकता है तो आपको पुष्टि करने के लिए कहा जाएगा)।

जब पहले मामले में बैकअप समय आता है, या जब प्रशासनिक अधिकारों वाला अंतिम उपयोगकर्ता दूसरे मामले में बाहर निकलता है, तो सिस्टम इन्फोबेस को लॉक कर देगा और सभी उपयोगकर्ताओं को बंद कर देगा। यह एक जटिल प्रक्रिया है जो काम नहीं कर सकती है, जिसके परिणामस्वरूप बैकअप त्रुटि होती है (नीचे दिखाया गया है)। आप हमारी वेबसाइट पर इसके बारे में एक विशेष लेख पढ़ सकते हैं।

इसलिए, यह अपने आप को एक बार की स्वचालित बैकअप सेटिंग तक सीमित करने के लिए काम नहीं करेगा; आपको अभी भी नियमित रूप से बैकअप के निर्माण की निगरानी करनी होगी।

और अब कुछ प्रश्न जो बैकअप विषय पर लोकप्रिय लेखों में शामिल नहीं हैं।

• क्या सब कुछ बैकअप हो जाएगा?

नहीं। आप काम के इतिहास को खो सकते हैं या भ्रष्ट कर सकते हैं (जिसने और कब कार्यक्रम में प्रवेश किया और बाहर निकला), वस्तु का इतिहास बदलता है (डेटा किसने और कब बदला)। यह जानकारी इन्फोबेस के बाहर संग्रहीत की जाती है, और इसके भंडारण और सही पुनर्प्राप्ति के लिए विशेष क्रियाओं की आवश्यकता होती है। आप वस्तुओं (दस्तावेज़ स्कैन, फ़ोटोग्राफ़, आदि) से जुड़ी 1C फ़ाइलों को खो या क्षतिग्रस्त कर सकते हैं। सेटिंग्स के आधार पर, यह डेटा इन्फोबेस के अंदर या बाहर संग्रहीत किया जा सकता है; बाद के मामले में, इसे सही ढंग से सहेजने और पुनर्स्थापित करने के लिए भी विशेष क्रियाओं की आवश्यकता होती है। बैकअप उपयोगकर्ताओं द्वारा किए गए प्रबंधित प्रपत्र अनुकूलन को भी सहेजता नहीं है।

• क्या काम के दौरान बैकअप कॉपी बनाना संभव है?

मानक तंत्र पहले उपयोगकर्ताओं को समाप्त करने का प्रयास करता है। हालांकि, यह हमेशा संभव नहीं होता है, इसलिए जब उपयोगकर्ता चल रहे हों तो बैकअप ऑपरेशन किया जा सकता है। इस मामले में, यह माना जाता है कि ये उपयोगकर्ता डेटा को संशोधित नहीं करते हैं। लेकिन अगर ऐसा नहीं है, तो इस बात की कोई गारंटी नहीं है कि बैकअप सही है। तो इस सवाल का जवाब है नहीं, आप नहीं कर सकते।

• बैकअप कितनी बार बनाया जाना चाहिए?

डेटा प्रविष्टि की तीव्रता और उनके नुकसान की गंभीरता पर निर्भर करता है। एक या दो 1C उपयोगकर्ताओं वाले छोटे व्यवसाय के लिए, हम इसे कम से कम दैनिक रूप से करने की सलाह देते हैं। 20 उपयोगकर्ताओं के साथ, हम एक व्यावसायिक दिन के दौरान एक रात्रिकालीन बैकअप और एकाधिक बैकअप बनाने की अनुशंसा करते हैं। जैसा कि आपको याद है, यह उपयोगकर्ताओं के काम में एक अस्थायी तकनीकी विराम की आवश्यकता होगी।

• हमारे पास डेटा हानि के मामले हैं, और हम इन्फोबेस के SQL संस्करण पर स्विच करना चाहते हैं, लेकिन यह बहुत महंगा है ...

आप एमएस एसक्यूएल के मुफ्त संस्करण का उपयोग करना चाह सकते हैं। सलाह के लिए हमसे संपर्क करें।

इन्फोबेस का SQL संस्करण

लेख का यह हिस्सा विशेषज्ञों और उन लोगों के लिए दिलचस्पी का होगा जो अभी एक बनने वाले हैं।

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

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

तथ्य यह है कि SQL वातावरण में बैकअप बटन प्रेस का एक क्रम नहीं है, बल्कि जटिल वस्तुओं पर नियमित घटनाओं का एक सेट है। और यह परिसर बहुत ही जटिल वातावरण में बना है।

"सब कुछ कैसे काम करता है" को समझने के लिए, हम एक बार फिर अपने कार्यों के लक्ष्य को इंगित करेंगे - विफलता से पहले दूसरे तक डेटा का पूर्ण बैकअप (या अवांछित परिवर्तन करने का क्षण) और एक मनमाना बिंदु पर वापस रोल करने की क्षमता दूसरे के लिए सटीक समय।

क्या डेटा रिकवरी दूसरे के लिए सही है वास्तव में इतना महत्वपूर्ण है?

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

"विस्फोट से एक सेकंड पहले" सिस्टम में मौजूद सभी डेटा के साथ डेटाबेस की एक प्रति कैसे प्राप्त करें

लेन-देन लॉग (टीएलओजी)

उन सभी क्रियाओं को लॉग करना आवश्यक है जो हम डेटाबेस के साथ करने जा रहे हैं, साथ ही उनका सटीक समय (माइक्रोसेकंड तक), और उसके बाद ही उन्हें निष्पादित करें। इस तरह के एक लॉग (एक बहुत ही विश्वसनीय और तेज़ माध्यम पर संग्रहीत, आवश्यक रूप से डेटाबेस से अलग) होने से, हम माइक्रोसेकंड परिशुद्धता के साथ एक मनमाना पुनर्स्थापना क्षण तक डेटाबेस के अस्तित्व में आने के समय से सभी कार्यों को दोहरा सकते हैं। लेकिन लेन-देन लॉगिंग में दो कमियां हैं: कुछ समय बाद, जैसे-जैसे डेटाबेस बढ़ता है, TLog बहुत अधिक स्थान लेगा (क्योंकि यह लगातार बढ़ता है), और समय पर "शून्य" बिंदु से पुनर्प्राप्ति में बहुत लंबा समय लगेगा।

लेन-देन लॉग बैकअप (TLog बैकअप)

लाक्षणिक रूप से बोलते हुए, हम नियमित रूप से लॉग से सभी शीट लेंगे और उन्हें अगले कमरे में ले जाएंगे (चलिए जब्त शीट को टीएलओजी बैकअप कहते हैं), और लॉग में ही नई खाली चादरों का एक पैकेट डाल दें ताकि नया रिकॉर्ड करने के लिए जगह हो आधार के साथ कार्रवाई। तकनीकी रूप से, यह निम्नानुसार किया जाता है: TLog फ़ाइल से एक प्रतिलिपि बनाई जाती है और संग्रह डिस्क पर लिखी जाती है, जिसके बाद TLog में सभी प्रविष्टियाँ "मिट जाती हैं" (मुफ्त के रूप में चिह्नित, लॉग फ़ाइल का आकार नहीं बदलता है), नए लेनदेन के बारे में जानकारी "मिटाए गए" स्थान पर लिखी जाती है। यह समझना बहुत जरूरी है कि चादरों का प्रत्येक फटा हुआ पैक, हालांकि इसे स्थापित शब्दावली में ट्रांजेक्शन लॉग बैकअप कहा जाता है, केवलइस अवधि के लिए आधार के साथ कार्यों के बारे में जानकारी का वाहक, और अब यह जानकारी लॉग में ही नहीं है। इसलिए, एक भी "फटी हुई शीट" का नुकसान फिलहाल बिल्कुल अस्वीकार्य है, और शब्द टीलॉग बैकअपइस जानकारी के सार और उद्देश्य को चालाकी से छुपाता है। याद रखें - यह बैकअप नहीं है!हमने लॉग को कई फाइलों में विभाजित किया है और उनमें से प्रत्येक में जानकारी कहीं भी डुप्लीकेट नहीं है। लेकिन ट्रांजेक्शन लॉग बैकअप शब्द को आम तौर पर स्वीकार किया जाता है, इसलिए हम भविष्य में इसका इस्तेमाल करना जारी रखेंगे।

अब TLog अनिश्चित काल तक नहीं बढ़ता है, लेकिन एक नियमित कार्य उत्पन्न होता है - TLog का अनुसूचित बैकअप।

पूर्ण डेटाबेस बैकअप (पूर्ण बैकअप)

यदि आप समय-समय पर पूरे डेटाबेस की प्रतियां बनाते हैं, तो पुनर्प्राप्ति के लिए समय के संदर्भ में सबसे उपयुक्त प्रतिलिपि लेना संभव होगा और सभी कार्यों को शून्य बिंदु से समय पर नहीं दोहराया जाएगा, लेकिन केवल उस समय से संचालन जब यह प्रतिलिपि बनाई गई थी बहाली के क्षण तक (जैसा कि वे कहते हैं, "एक पूर्ण बैकअप लें और उस पर टीलॉग रोल करें")।यह पुनर्प्राप्ति समय को काफी कम कर देता है, खासकर यदि डेटाबेस 5 वर्षों से मौजूद है। इसके अलावा, अब हमारे पास पुराने पूर्ण बैकअप और TLog बैकअप को हटाने की क्षमता है। वास्तव में, निकटतम सेकंड में वापस आना अक्सर केवल थोड़े समय के लिए आवश्यक हो सकता है (उदाहरण के लिए, दो महीने पहले वर्तमान क्षण से कुछ घटनाओं की जांच करने के लिए या अवांछित परिवर्तनों के दुखद परिचय से एक सेकंड पहले डेटाबेस को पुनर्स्थापित करने के लिए)। इस अवधि के दौरान, हम TLog बैकअप की एक अटूट श्रृंखला संग्रहीत करेंगे। इस अवधि के बाहर, आप पूर्ण बैकअप के रूप में केवल पुनर्प्राप्ति बिंदुओं को संग्रहीत कर सकते हैं (और फिर भी सभी नहीं, लेकिन उदाहरण के लिए, केवल महीने के पहले दिनों के लिए अंक)। अवधि के बाहर TLog बैकअप अब बिल्कुल भी हटाया जा सकता है (जाहिर है, अवधि के बाहर उनका चयनात्मक विलोपन और चयनात्मक संग्रहण TLog श्रृंखला के व्यवधान के कारण पूरी तरह से व्यर्थ है)। एक तरह से या किसी अन्य, बुद्धिमान विलोपन का नियमित कार्य उत्पन्न होता है।

यहाँ निम्न समस्या उत्पन्न होती है। बड़ी संख्या में उपयोगकर्ताओं और परिवर्तन की उच्च दर वाले डेटाबेस की कल्पना करें। सशर्त - 33% समय लिखने में और 67% पढ़ने में व्यतीत होता है, कोई डाउनटाइम नहीं है। जब हम डेटाबेस को पुनर्स्थापित करते हैं, तो हम लगभग 100% समय लिख सकते हैं, अर्थात। तीन गुना तेज। इसका मतलब है कि हम प्रति घंटे लॉग से डेटाबेस के साथ तीन घंटे के काम को बहाल कर सकते हैं। और यह घंटा रिकवरी के लिए अधिकतम डाउनटाइम है जिसके लिए व्यवसाय सहमत है। मान लें कि दिन में एक बार फुल बैकअप किया जाता है। यदि विफलता अब से 21 घंटे बाद होती है, तो हमें लॉग रिकवरी पर 7 घंटे खर्च करने होंगे, जो बिल्कुल अस्वीकार्य है। तो, 3 घंटे में 1 बार फुल बैकअप लेना चाहिए? काश, यह हमेशा संभव नहीं होता: डेटाबेस इतने बड़े होते हैं (सैकड़ों गीगाबाइट और यहां तक ​​​​कि टेराबाइट्स) कि ऐसे समय में पूर्ण बैकअप बनाना असंभव है। इसके अलावा, काम के घंटों के दौरान एक पूर्ण बैकअप का बार-बार निर्माण एक अतिरिक्त भार देता है और उपयोगकर्ताओं के काम को धीमा कर देता है, और इतनी मात्रा में डेटा संग्रहीत करना बहुत महंगा है। लेकिन सिद्धांत रूप में, यह पर्याप्त है कि एक स्वीकार्य समय में पूर्ण बैकअप बनाने में असमर्थता पूरी तरह से हमारी बैकअप तकनीक को समाप्त कर देती है।

डिफरेंशियल बैकअप (डिफरेंशियल बैकअप, डिफ बैकअप)

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

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

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

• 5+7=3. इसका मतलब है कि फुल बैकअप 5 और डिफ बैकअप 7 होने पर, आप डेटाबेस को 3 स्थिति में पुनर्स्थापित कर सकते हैं। साथ ही, 6 की अनुपस्थिति किसी भी तरह से पुनर्प्राप्ति की संभावना को प्रभावित नहीं करेगी।
• 5+10+11=3. वही परिणाम (राज्य 3 को बहाल करना) प्राप्त किया जा सकता है यदि हम TLogBackup 10 और 11 में दर्ज सभी परिवर्तनों को पूर्ण बैकअप 5 पर लागू करते हैं। यह इस तथ्य के कारण 6 और 7 नहीं होने पर करना होगा। केवल सृजन 5 और 8 के लिए प्रदान किया गया है (या यदि 6 और 7 क्षतिग्रस्त हैं)। लेकिन अगर 7 है, तो 5+7 रास्ता 5+10+11 रास्ते से बहुत तेज है।
• यदि केवल 7 गायब है, तो आधार को 5+6+11 विधि का उपयोग करके 3 स्थिति में पुनर्स्थापित किया जा सकता है।
• यदि शेड्यूल ऐसा है कि 11 नहीं बनाया गया था, तो 12 की सामग्री होगी: "जोड़ा गया: टोपोरकोव, उफिमत्सेव, यशिन।"
• लेन-देन लॉग, पहली नज़र में, चित्र में नहीं दिखाया गया है, लेकिन जैसा कि आपको याद है, TLog बैकअप बिल्कुल भी बैकअप नहीं है, बल्कि एक निश्चित अवधि के लिए लेन-देन लॉग है। कृपया ध्यान दें कि जर्नल में नए नामों की उपस्थिति डेटाबेस में उनकी उपस्थिति से पहले होती है।
• यदि लेन-देन लॉग का बैकअप नहीं लिया जाता है, तो समय 12 पर टीएलओजी की सामग्री "जोड़ी गई:" होगी, उसके बाद अंतिम नामों की सूची 4 (यानी, सभी क्रियाएं लॉग की जाती हैं)। यदि बैकअप चित्र के रूप में बनाया गया है, तो समय 4 और साथ ही समय 8 पर लेन-देन लॉग की सामग्री निम्नलिखित होगी: "अभी तक कोई कार्रवाई नहीं की गई है।"

लेन-देन लॉग की पूंछ का बैकअप लेना

यदि हम उच्च-उपलब्धता प्रणालियों के बारे में बात नहीं कर रहे हैं, तो विफलता की स्थिति में, एक और मैनुअल ऑपरेशन की आवश्यकता होती है, जो अब नियमित नहीं है, बल्कि नवीनतम TLog बैकअप का निर्माण है। यदि यह संभव नहीं है, अर्थात्। लॉग डेटाबेस के साथ या सर्वर के साथ दूषित है - पुनर्प्राप्ति केवल अंतिम TLog बैकअप तक संभव है, न कि अंतिम सेकंड तक। वे। मूल लक्ष्य प्राप्त नहीं होगा।

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

यह एक ऐसी जटिल प्रणाली है जो यह सुनिश्चित करेगी कि हम शुरुआत में निर्धारित लक्ष्यों को प्राप्त करें और इसके विकास के दौरान खोजी गई समस्याओं से मुक्त हों।

पूर्ण पुनर्प्राप्ति मॉडल (केवल निर्धारित कार्यों के साथ और व्यवस्थापकों के नियंत्रण में काम करता है)

हमने पूर्ण डेटाबेस पुनर्प्राप्ति मॉडल - पूर्ण पुनर्प्राप्ति मॉडल का वर्णन किया है। एमएस एसक्यूएल सर्वर में विशेष मामलों के लिए एक साधारण रिकवरी मॉडल (सरल रिकवरी मॉडल) और अपूर्ण लॉगिंग वाला मॉडल (बल्क-लॉग) है। पूर्ण पुनर्प्राप्ति मॉडल डेटाबेस रखरखाव कार्यों के नियमित निष्पादन के साथ-साथ व्यवस्थापक द्वारा कार्य निष्पादन की नियमितता और परिणामों पर नियंत्रण प्रदान करता है। यह एक जटिल रखरखाव योजना डिजाइन टूलकिट के अस्तित्व का सुझाव देता है जिसे सीखने की जरूरत है।

आइए अभ्यास के लिए आगे बढ़ें

शायद आपके सामने पहली कठिनाई यह है कि आप एक नई रखरखाव योजना नहीं बना सकते हैं।

SQL स्क्रिप्ट निष्पादित करके इस कार्यक्षमता को सक्षम करना आवश्यक है (टूलबार पर नई क्वेरी, स्क्रिप्ट टाइप करें, टूलबार पर निष्पादित करें)। यदि स्क्रिप्ट को सफलतापूर्वक निष्पादित किया जाता है, तो आप विंडो के निचले भाग में स्क्रिप्ट के साथ संबंधित संदेश देखेंगे।

इस स्क्रिप्ट का टेक्स्ट कॉपी/पेस्ट करने के लिए:

वास्तविक रखरखाव योजना

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

ऑब्जेक्ट एक्सप्लोरर में, हम देख सकते हैं कि SQL सर्वर (मुख्य योजना, परीक्षण योजना) पर दो रखरखाव योजनाएँ कॉन्फ़िगर की गई हैं। मुख्य योजना में विभिन्न अनुसूचियों (अनुसूची) के साथ चार उप-योजनाएँ हैं:

• साप्ताहिक रखरखाव
• डिफरेंशियल बैकअप
• बैकअप ZhT

कार्य डिजाइन के क्षेत्र में, हम कार्यों को देखते हैं। योजना बनाने की प्रक्रिया में टूलबॉक्स पैलेट से कार्यों को खींचना, कार्य विकल्प सेट करना और कार्यों के बीच तीर खींचना शामिल है। डिज़ाइन क्षेत्र में कार्यों का एक मनमाना विवरण हो सकता है, योजना पर कार्य और पैलेट पर कार्य के बीच पत्राचार को आइकन द्वारा सेट किया जा सकता है। उदाहरण के लिए, "अखंडता त्रुटि" कार्य पैलेट ("व्यक्ति" आइकन) पर "संचालक कार्य को सूचित करें" कार्य है।

क्या यह एक ब्लॉक आरेख है?

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

समवर्ती और सीमाएं

केवल एक चीज जो उसे रोकती है वह है प्रतिबंधों की उपस्थिति। कार्य तब तक शुरू नहीं किया जा सकता जब तक कि यह "सच न हो जाए" भेजेइसमें तीर (प्रतिबंध, प्रतिबंध)। तीर का रंग प्रभावकारी कार्य के पूरा होने के प्रकार को इंगित करता है। आने वाला हरा तीर आश्रित कार्य के लिए इंगित करता है कि बाधा "केवल तभी चलती है जब प्रभावित करने वाला कार्य सफल होता है", काला वाला - "प्रभावकारी कार्य (पूर्णता) के पूरा होने के बाद ही चलाएं", लाल वाला - "केवल मामले में चलाएं" कार्य को प्रभावित करने में त्रुटि (विफलता)"।

लाइन का प्रकार (ठोस या धराशायी) कई आने वाले तीरों से अंतिम बाधा की गणना करने के लिए तार्किक AND या OR ऑपरेटर को दर्शाता है। यह ऑपरेटर वरीयता प्रतिबंध संपादक संवाद में बदल जाता है (किसी भी तीर पर डबल क्लिक करें)। ठोस तीर सभी सच होने चाहिए, कम से कम एक बिंदीदार वाला सच होना चाहिए - फिर आश्रित कार्य तुरंत शुरू किया जाएगा। प्रत्येक आने वाले तीर का रंग स्वतंत्र रूप से बदला जा सकता है (राइट क्लिक, सफलता/विफलता/पूर्णता)। लाइन प्रकार को केवल एक बार में आने वाले सभी तीरों के लिए बदला जा सकता है (डबल क्लिक, वरीयता प्रतिबंध संपादक संवाद)। सबसे पहले, वे सभी कार्य जिनमें कोई प्रतिबंध नहीं है, एक साथ चलने लगते हैं। जैसे ही अगला कार्य पूरा होता है, उस पर निर्भर सभी कार्यों की जाँच की जाती है और साथ ही वे कार्य जिनके लिए प्रतिबंधों का अंतिम मूल्य लॉन्च करने का निर्णय लेने के लिए पर्याप्त हो जाता है, निष्पादन के लिए लॉन्च किए जाते हैं।

पिछले पैराग्राफ में दी गई जानकारी सामान्य तंत्र को समझने के लिए पर्याप्त है जिसके द्वारा SQL सर्वर रखरखाव योजना कार्य करता है। आइए अब व्यावहारिक महत्व के प्रश्नों पर विचार करें।

अजीब कार्यक्रम

अजीब कार्य निष्पादन समय सर्वर समय क्षेत्र और डेवलपर्स समय क्षेत्र के बीच 4 घंटे के अंतर के कारण है। डेवलपर्स के लिए संभावित कामकाजी घंटों की सीमा 9:00 से 21:00 बजे तक है, इसलिए "बैकअप ZhT" सबप्लान को हर घंटे 10:00 से 21:00 बजे तक निष्पादित किया जाता है, हर घंटे में बदलाव को ठीक किया जाता है (9 बजे कोई बदलाव नहीं होता है: 00 अभी तक)। सर्वरों के समय क्षेत्र में अनुवादित, यह दोपहर 14:00 बजे से सुबह 01:00 बजे तक है, जो अनुसूची में इंगित किया गया है।

समय निर्दिष्ट करते समय, आप आधी रात को कूद सकते हैं, यह सही ढंग से काम करता है। थोड़ा अजीब लग रहा है। अन्य अनुसूचक, अगले दिन में समाप्ति समय को समझने में कठिनाइयों से बचने के लिए, कार्य की अवधि का अनुरोध करते हैं - "X घंटे के भीतर।"

यदि एक पूर्ण बैकअप के तुरंत बाद एक VT बैकअप आता है, तो आप 100% सुनिश्चित हो सकते हैं कि योजना रखरखाव योजना विज़ार्ड द्वारा बनाई गई थी (इसका कभी भी उपयोग न करें, यह कचरा के अलावा कुछ नहीं बनाता है) या एक कम-कुशल व्यवस्थापक द्वारा जो पूर्ण मानता है बैकअप + टीलॉग बैकअप जोड़ी, एक ही समय में, कुछ अनिवार्य पुनर्प्राप्ति किट द्वारा। लेकिन ये स्वतंत्र कार्य हैं जो अलग-अलग शेड्यूल पर चलते हैं।

लेकिन हमारी योजना एक अपवाद है, क्योंकि हमारा लक्ष्य एक उप-योजना में महत्वपूर्ण कार्यों (अखंडता, पूर्ण बैकअप, बैकअप वीटी) की सफलता के बारे में जानकारी एकत्र करना है, और केवल अगर वे सफल होते हैं, तो पुराने बैकअप को हटाने का आदेश दें।

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

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

*

*कार्य पर fx आइकन पर ध्यान दें

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

ऐसे कार्यों के लिए बाहरी उपकरणों की आवश्यकता नहीं होती है और मानक MS SQL उपकरण द्वारा हल किए जाते हैं। पहले दिनों के लिए पूर्ण बैकअप फ़ाइल का विस्तार MNT के साथ किया जा सकता है, और बाकी दिनों के लिए - BAK के साथ। इसका मतलब है कि सफाई कार्य 1 महीने से अधिक पुराने BAK को हटा सकता है, और MNT को अधिक समय तक संग्रहीत कर सकता है, उदाहरण के लिए, 1 वर्ष के बाद।

जब आप पूर्ण डेटाबेस बैकअप कार्य सेटअप संवाद खोलते हैं, तो आप आज की तारीख के आधार पर फ़ाइल एक्सटेंशन BAK या MNT देखेंगे।

1C अनुशंसाओं के अनुसार, आंकड़ों को प्रतिदिन अद्यतन किया जाना चाहिए, और सांख्यिकी अद्यतन की आवृत्ति पर प्रक्रियात्मक कैश को साफ़ किया जाना चाहिए। ये कार्य एक ओर काफी संसाधन-गहन हैं, और दूसरी ओर, वे विकास दल के सूचना आधारों के लिए मौलिक नहीं हैं। आखिरकार, ऐसे डेटाबेस में बहुत अधिक डेटा नहीं होता है, और प्रदर्शन के मुद्दे तीव्र नहीं होते हैं। इसलिए, इन कार्यों को साप्ताहिक उपयोजना में निष्पादित किया जाता है, जबकि वे दैनिक में अक्षम होते हैं (कार्य पर राइट क्लिक करें, अक्षम करें)। न केवल अनुपस्थित, बल्कि बनाया और प्रतिबंधित किया गया।

आइए एक स्वाभाविक प्रश्न पर विचार करें: क्या निषिद्ध समस्या में सब कुछ सही ढंग से काम करेगा? इस तरह के प्रतिबंध पर लाल, काले और हरे तीर कैसे प्रतिक्रिया देंगे?

जटिल रखरखाव योजनाएँ लिखते समय, डिबगिंग का कार्य और इससे उत्पन्न होने वाली व्यावहारिक आवश्यकताएँ उत्पन्न होती हैं:

• वास्तव में एक लंबा कार्य न करें, बल्कि अन्य कार्यों पर तीर के रूप में अपना प्रभाव बनाए रखते हुए इसे सशर्त रूप से पूरा करें;
• कार्य के गलत निष्पादन की मॉडलिंग करना।

पहले के लिए, MS SQL में कार्य के वास्तविक निष्पादन को रोकने के लिए एक तंत्र है: कार्य पर राइट-क्लिक करें, अक्षम करें। इस मामले में, कार्य ग्रे हो जाएगा, वास्तव में निष्पादित नहीं किया जाएगा, लेकिन पूर्ण और पूर्ण दोनों माना जाएगा (काले और हरे तीर काम करेंगे)। यदि हम एक गलत निष्पादन का अनुकरण करना चाहते हैं, तो कार्य गुण विंडो में हमें ForceExecutionResult कार्य गुण को विफलता पर सेट करने की आवश्यकता है। इस संपत्ति को किसी अन्य खंड में ForcedExecutionValue संपत्ति के साथ भ्रमित न करें।

कार्य बाधाओं या डमी कार्यों के लिए शर्त कार्यान्वयन ((ए या बी) और सी) जो बिल्कुल भी डमी नहीं हैं

बाधाओं को या तो AND ऑपरेटर या OR ऑपरेटर के साथ जोड़ा जा सकता है। इसका मतलब यह है कि नीचे दिए गए उदाहरण में, डॉटेड कंप्लीशन एरो को सीधे "त्रुटियों के साथ सूचना पूर्णता" कार्य के लिए नहीं खींचा जा सकता है। समाधान एक मध्यवर्ती कार्य "त्रुटियां थीं" बनाना है जो बिंदीदार काले तीरों के परिणाम को जमा करता है। कार्य सिंगल गो स्टेटमेंट से एक SQL स्क्रिप्ट है, अर्थात ऐसा लगता है कि यह कुछ भी उपयोगी नहीं है।

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

अतुल्यकालिक निष्पादन

उपरोक्त चित्रण में निर्माण में, "क्वांटम विरोधाभास" हो सकता है, जब प्रभाव कारण से आगे होता है। वास्तव में, यदि प्रभावित करने वाले कार्यों में से एक, उदाहरण के लिए, "अखंडता त्रुटि" ने आश्रित कार्य को शुरू करने के लिए एक संकेत दिया, तो अब बाकी प्रभावित कार्यों से परिणाम की प्रतीक्षा करने का कोई मतलब नहीं है, यह अभी भी इस तथ्य को प्रभावित नहीं करता है कि आश्रित कार्य "त्रुटियां थीं" चलाया जाना चाहिए। इसलिए इसे तुरंत अंजाम दिया जाएगा। कुछ समय बाद, ऐसा हो सकता है कि कार्य "ZT बैकअप त्रुटि" काम करेगा और समाप्त हो जाएगा। यह "त्रुटियां थीं" ट्रिगर हो सकता था, लेकिन यह घटना पहले भी हो चुकी है। यह हमारे उप-योजना में डिज़ाइन द्वारा है, लेकिन अप्रत्याशित परिणामों से बचने के लिए इस प्रकार के अतुल्यकालिक प्रभावों को ध्यान में रखा जाना चाहिए। उदाहरण के लिए, शुरुआत में और अंत में अलर्ट ऑपरेटर कार्य का उपयोग करके रखरखाव सबप्लान के कुल निष्पादन समय को मापते समय।

यह क्या है?

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

समानांतर या श्रृंखला

"दैनिक पूर्ण बैकअप" उपयोजना में, "ऑफ़लाइन गैर-बैकअप योग्य डेटाबेस" कार्य सबसे पहले किया जाना है, क्योंकि यह एकमात्र कार्य है जिसकी कोई सीमा नहीं है। इसके नीचे हम पंक्तिबद्ध देखते हैं परिणाम कोऐसे कार्य करना जो दैनिक पूर्ण बैकअप उपयोजना का मुख्य आधार हैं।

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

यहां दूसरा विकल्प है, जो पिछली योजना के बराबर है, लेकिन कार्यों की परिवर्तित व्यवस्था + ग्रे कार्यों को हटाने के कारण अधिक दृश्य है।

मानक बैकअप डेटाबेस के भीतर समानता और डेटाबेस अखंडता कार्यों की जाँच करें और उनके निष्पादन के परिणाम की व्याख्या

"बैकअप कॉपी बनाएं" और "डेटाबेस की अखंडता की जांच करें" कार्य आमतौर पर डेटाबेस की सूची के साथ काम करते हैं। क्या वे प्रत्येक डेटाबेस के साथ क्रमिक रूप से काम करेंगे, या प्रत्येक डेटाबेस के लिए कई समानांतर रखरखाव कार्य होंगे? आइए कार्य पर डबल-क्लिक करें, खुलने वाले संवाद में, "टी-एसक्यूएल देखें" बटन दबाएं। हम देख सकते हैं कि SQL सर्वर द्वारा उत्पन्न और निष्पादित स्क्रिप्ट में, बैकअप डेटाबेस बैकअप निर्देश GO निर्देशों द्वारा अलग किए जाते हैं, जिसका अर्थ है कि ये बैकअप प्रक्रियाएं समानांतर में चलेंगी। परिणाम पैकेजों को संदर्भित नहीं करता है, बल्कि समग्र रूप से कार्य को संदर्भित करता है। यदि कम से कम एक डेटाबेस वाले कार्य में कोई त्रुटि होती है, तो कार्य को आम तौर पर गलत तरीके से पूरा माना जाएगा; यदि कोई त्रुटि नहीं है, तो कार्य को सामान्य रूप से सफलतापूर्वक पूरा माना जाएगा।

शेड्यूलिंग रखरखाव कार्य (एक प्रमुख मुद्दा, जिसे अक्सर एक माध्यमिक माना जाता है)

आइए एक पूर्ण पुनर्प्राप्ति मॉडल डेटाबेस रखरखाव योजना के मुख्य कार्यों को फिर से देखें:

1. पूर्ण बैकअप कार्य
2. डिफ बैकअप कार्य
3. TLog बैकअप कार्य

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

शुरू करने के लिए मुख्य बात स्वीकार्य डेटा हानि विंडो (पुनर्प्राप्ति बिंदु उद्देश्य, आरपीओ) + पुनर्प्राप्ति समय (पुनर्प्राप्ति समय उद्देश्य, आरटीओ) है। ये संकेतक, बदले में, हार्डवेयर आर्किटेक्चर, उपयोग की जाने वाली तकनीकों और कार्य निष्पादन की आवृत्ति को निर्धारित करते हैं।

TLog बैकअप की आवृत्ति

TLog बैकअप की आवृत्ति RPO मान पर निर्भर करती है। उत्पादक डेटाबेस के लिए TLog बैकअप कार्य की विशिष्ट आवृत्ति डेटाबेस में परिवर्तन करने के लिए पूरे दैनिक समय अंतराल के लिए ½ से 1 RPO समय तक है (उस समय अंतराल सहित जिसके दौरान शेड्यूल किए गए कार्यों द्वारा परिवर्तन किए जाते हैं और बंद के दौरान एक बार प्रसंस्करण किया जाता है) -घंटे)। उत्पादक आधारों के लिए 24 घंटों के भीतर परिवर्तन करना विशिष्ट है। यदि ऐसे डेटाबेस के लिए आरपीओ = 1 घंटा, तो लेन-देन लॉग का बैकअप हर 30-60 मिनट में चौबीसों घंटे किया जाना चाहिए। लेकिन ऐसे मामले हैं, जब सिस्टम की बारीकियों के कारण, अपने आप को केवल काम के घंटों के अंतराल तक सीमित करना संभव है, उदाहरण के लिए, 10 से 18 तक, सोमवार से शुक्रवार तक, साथ ही कम या ज्यादा आवृत्ति।

अनुत्पादक डेटाबेस (विकास के माहौल में) के लिए, एक साधारण पुनर्प्राप्ति मॉडल का उपयोग करना अधिक उपयुक्त हो सकता है, जहां यह कार्य पूरी तरह से अनुपस्थित है। इस तथ्य के बावजूद कि कई साहित्य और आधिकारिक दस्तावेजों में यह घोषित किया गया है कि एक सरलीकृत मॉडल का उपयोग प्रदर्शन लाभ नहीं देता है (क्योंकि टीलॉग अभी भी बनाए रखा गया है), व्यवहार में ऐसा नहीं है।सरलीकृत पुनर्प्राप्ति मॉडल का उपयोग करते समय परिवर्तित 1C कॉन्फ़िगरेशन ऑब्जेक्ट को भंडारण में रखने के बार-बार किए गए संचालन का निष्पादन समय कई गुना कम हो जाता है, और समय में कुल लाभ नाटकीय रूप से विकास की गति को बढ़ाता है। उसी समय, ½ से 1 RPO समय की आवृत्ति के साथ, आपको पहले से ही एक डिफ बैकअप बनाना होगा। कम परिवर्तन दर वाले उत्पादक बैक ऑफिस सिस्टम के लिए उसी विधि का उपयोग किया जा सकता है, जहां डेटा को फिर से दर्ज करने की संभावना होती है जो आरपीओ विंडो में था और दुर्घटना के कारण खो गया था।

पूर्ण बैकअप और डिफ बैकअप की परस्पर संबंधित आवधिकता

दोनों कार्यों की आवृत्ति आम तौर पर इस तरह से चुनी जाती है कि आरटीओ को पूरा किया जा सके। यदि परिवर्तन करने की तीव्रता ऐसी है कि यह आपको महीने में एक बार पूर्ण बैकअप बनाने की अनुमति देता है, तो दिन में एक बार अंतर बैकअप, और साथ ही, 29 तारीख को, आरटीओ के भीतर बहाली होती है - क्यों नहीं। यदि परिवर्तनों की तीव्रता ऐसी है कि कार्यों की ऐसी आवधिकता के साथ, पुनर्प्राप्ति समय अस्वीकार्य हो जाता है, तो आपको दिन की शुरुआत में एक पूर्ण प्रति और दिन के दौरान कई अंतर बैकअप की आवश्यकता हो सकती है।

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

SQL बैकअप को कॉन्फ़िगर करने के बारे में आप इंटरनेट पर जो सलाह पढ़ सकते हैं, उसका पालन करना आपके डेटा के लिए परेशानी का स्रोत हो सकता है। आइए इस लेख के ज्ञान को कुछ विशेषज्ञों द्वारा दी गई सलाह पर लागू करें:

अक्सर अद्यतन किए गए डेटाबेस के लिए, रविवार को पूर्ण बैकअप और दिन में एक बार TLog बैकअप करने का सुझाव दिया जाता है। डेटा हानि की विंडो (आरपीओ) = 1 दिन अस्वीकार्य रूप से लंबा है। साथ ही, विशेषज्ञ का मानना ​​है कि किसी भी डेटा हानि को रोकने के लिए यह सबसे अच्छा तरीका है। शनिवार को पुनर्प्राप्ति समय भी अस्वीकार्य रूप से लंबा होगा, क्योंकि 6 दिनों के लिए पूर्ण बैकअप में परिवर्तन लागू करना आवश्यक होगा, और डेटाबेस में परिवर्तन की तीव्रता अधिक है।

यहां, सोमवार से शुक्रवार तक हर दिन, वीटी और श्रिंक वीटी का बैकअप बनाया जाता है ("विवरण" कॉलम में "डेटाबेस प्रतियां" पाठ एक स्पष्ट टाइपो है, क्योंकि ऑपरेशन "क्रियाओं" कॉलम में स्पष्ट रूप से इंगित किया गया है - वीटी का बैकअप)। यदि आप हमारी साप्ताहिक रखरखाव उप-योजना पर वापस जाते हैं, तो आप देखेंगे कि वीटी ट्रंकेशन कार्य को उपयुक्त रूप से "सिकोड़ो मत करो" नाम दिया गया है और यह एक निषिद्ध कार्य (ग्रे आउट) है। खोज क्वेरी "हटना चाहिए" जानकारी को स्पष्ट करने में मदद करेगा।

हम एक पंक्ति में नीचे जाते हैं और देखते हैं कि प्रत्येक डिफ बैकअप के बाद, TLog बैकअप हटा दिया जाता है - यह निरंतर प्रत्यक्ष पुनर्प्राप्ति (संपूर्ण बैकअप सिस्टम का मुख्य लक्ष्य) और बिंदुओं को पुनर्स्थापित करने के लिए संक्रमण की स्वैच्छिक अस्वीकृति है। अंक एक दूसरे से एक दिन में अलग हो जाते हैं। इसका मतलब है कि डेटा हानि विंडो 24 घंटे (आरपीओ = 24 घंटे) है।

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

ऊपर दिया गया उदाहरण मेंटेनेंस प्लान विजार्ड का उपयोग करके नौसिखिए द्वारा बनाई गई एक एंट्री-लेवल योजना है और यह किसी भी समस्या का समाधान नहीं करती है। इसमें एक सामान्य गलती है: आप एक पूर्ण बैकअप बनाने का कार्य एक अखंडता जांच के परिणामों पर निर्भर नहीं कर सकते। जब कोई डेटाबेस क्रैश हो जाता है, तो डेटाबेस में दो टूटे हुए लिंक के साथ बैकअप रखना बेहतर होता है। "दैनिक बैकअप" सबप्लान में जो किया गया था, उसकी तुलना करें - अखंडता उल्लंघन ऑपरेटर को सूचित करता है, लेकिन बैकअप के निर्माण को नहीं रोकता है।

पुनर्प्राप्ति की विशेषताएं - डेटा कैसे न खोएं

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

चूंकि इन "सुविधाओं" का कहीं भी वर्णन नहीं किया गया है, आइए इस अंतर को भरें। आइए कुछ समय के लिए उत्पादन आधार को बहाल करने के एक विशिष्ट कार्य पर विचार करें (स्रोत, चित्र में ZUP3ENERGO) प्रोग्रामर के व्यक्तिगत डेटाबेस (रिसीवर, चित्र में ZUP_SUV) को घटना की जांच करने के लिए। SQL सर्वर के विभिन्न संस्करणों के व्यवहार की विभिन्न "सुविधाओं" का वर्णन करते हुए, "नए संस्करण" शब्द से हमारा मतलब रिलीज़ 13.0.4457.0 है, और "पुराने संस्करण" शब्द से - रिलीज़ 11.0.3156.0।

पहली क्रिया- गंतव्य डेटाबेस, कार्य, पुनर्स्थापना, डेटाबेस पर राइट-क्लिक करें। और तुरंत डेटाबेस को पुनर्स्थापित करें संवाद (नीचे चित्रण) में, हम एक पीले खतरे का संकेत देखते हैं: स्रोत डेटाबेस के लेनदेन लॉग के अंतिम टुकड़े की एक बैकअप प्रतिलिपि बनाई जाएगी। बेशक, वास्तव में, हमें प्राप्त करने वाले आधार के बारे में बात करनी चाहिए, और यहां तर्क इस प्रकार होना चाहिए: वर्तमान सामग्री को पुनर्स्थापित करके नष्ट करने से पहले, आइए अंत में ठीक करें कि हमारे पास अभी क्या है, बस मामले में। यह आपको वर्तमान पुनर्स्थापना को वापस रोल करने की अनुमति देगा, बाद में पुनर्स्थापना से पहले बिंदु पर एक और पुनर्स्थापना करेगा। ऑपरेशन, ऐसा प्रतीत होता है, उपयोगी है और इसमें कुछ भी खतरनाक नहीं है, अगर यह वास्तव में रिसीवर के बारे में था। लेकिन यह केवल संदेश में एक त्रुटि नहीं है, स्रोत पर गलती से एक टेल-लॉग बैकअप किया जाता है। इसका परीक्षण स्क्रिप्ट बटन पर क्लिक करके और कोड को देखकर प्रयोगात्मक रूप से किया जा सकता है।

इसलिए, पांचवें चरण में, इस ऑपरेशन को रद्द किया जाना चाहिए (नीचे देखें)। रिसीवर में सबसे हाल के परिवर्तनों को ठीक करना (जो पिछले वीटी बैकअप के बाद से हो सकता था) मैन्युअल रूप से किया जाना चाहिए (उदाहरण के लिए, संबंधित कार्य के अनिर्धारित लॉन्च द्वारा)।

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

• स्रोत डेटाबेस - स्रोत डेटाबेस और उसके लॉग के बैकअप वाली फ़ाइलों का पूरा सेट बैकअप रजिस्ट्री के अनुसार,जिसे SQL सर्वर के सिस्टम टेबल में मेंटेन किया जाता है। "बैकअप रजिस्ट्री के अनुसार" संचालन तंत्र को समझने के लिए एक अत्यंत महत्वपूर्ण वाक्यांश है। इसका मतलब है कि भले ही कुछ फ़ाइल वर्तमान में डिस्क से गायब है, इसे पुनर्प्राप्ति योजना में ध्यान में रखा जा सकता है (क्योंकि यह रजिस्ट्री में तय है) और सूची को पुनर्स्थापित करने के लिए बैकअप सेट में दिखाई देता है। त्रुटि केवल पुनर्प्राप्ति चरण में होगी और यदि यह एक डिफ बैकअप या TLog बैकअप फ़ाइल है - आधार अनुपयोगी स्थिति में रहेगा।ऐसा होने से रोकने के लिए, पहले "बैकअप मीडिया सत्यापित करें" बटन के साथ पुनर्स्थापित करने की संभावना की जांच करें।
• डिवाइस स्रोत फ़ाइलों का एक मनमाना सेट है। तथ्य यह है कि बैकअप के इतिहास को साफ किया जा सकता है। या बैकअप किसी अन्य SQL सर्वर पर बनाए गए थे और इसलिए इस सर्वर पर बैकअप रजिस्ट्री में पंजीकृत नहीं हैं। इसलिए, फ़ाइलों का एक मनमाना सेट स्पष्ट रूप से निर्दिष्ट करना संभव है। आप फ़ाइलों का एक सेट निर्दिष्ट कर सकते हैं जो पुनर्प्राप्ति के लिए अनावश्यक है (उदाहरण के लिए, कई दिनों के लिए - अगले चरण में SQL सर्वर केवल आवश्यक लोगों का चयन करेगा)।

दूसरा अधिनियम- स्रोत का चयन करें, जो हमारे मामले में रिसीवर से अलग है। MS SQL सर्वर के नए संस्करण सामान्य रूप से इस पर प्रतिक्रिया करते हैं। पुराने संस्करणों का बुरा प्रभाव पड़ता है जिन्हें डेटा हानि से बचने के लिए सावधानीपूर्वक निगरानी करने की आवश्यकता होती है:

• प्रभाव 1. MS SQL तुरंत गंतव्य को स्रोत में निर्दिष्ट डेटाबेस में बदल देता है। इसलिए, गंतव्य वापस लौटाया जाना चाहिए। यदि आप इसे नोटिस नहीं करते हैं, तो डेटाबेस चुपचाप अधिलेखित हो जाएगा, और यहां तक ​​कि विकल्प टैब पर अनियंत्रित "मौजूदा डेटाबेस को अधिलेखित करें" ध्वज भी इसे सुरक्षित नहीं कर पाएगा;
• प्रभाव 2. फाइल टैब पर स्विच करें और देखें - रिसीवर के बजाय, एमएस एसक्यूएल सर्वर स्रोत को अधिलेखित करना चाहता है (निम्न चित्रण देखें)। प्राप्त करने वाले आधार और उसके लॉग की फ़ाइलों के नाम मैन्युअल रूप से दर्ज करना आवश्यक है, अन्यथा स्रोत खो जाएगा (नीचे चौथा चरण देखें)।

तीसरी क्रिया।स्रोत के रूप में फ़ाइलों के एक सेट का चयन करने के बाद, आपको समय में बिंदु निर्दिष्ट करने की आवश्यकता है (रिस्टोर टू, टाइमलाइन बटन)। समय में बिंदु निर्दिष्ट करना आपको स्रोत (स्रोत) द्वारा परिभाषित फ़ाइलों के मूल सेट से एक विशिष्ट सेट (पुनर्स्थापित करने के लिए बैकअप सेट) का चयन करने की अनुमति देता है, जो एक निर्दिष्ट समय पर पुनर्स्थापित करने के लिए आवश्यक है। एमएस एसक्यूएल के नवीनतम संस्करणों में भी मौजूद एक और बेतुकापन स्पष्ट हो जाता है: "रिस्टोर टू" विकल्प और टाइमलाइन बटन गलत जगह पर डायलॉग में खींचे गए हैं। वे निश्चित रूप से स्रोत का उल्लेख करते हैं, गंतव्य का नहीं। यह बग कभी ठीक नहीं होगा, यह 10 साल से अधिक पुराना है, इसलिए आपको बस इसकी आदत डालने की जरूरत है। साथ ही, शासक का उपयोग किए बिना मैन्युअल रूप से समय दर्ज करते समय बहुत सावधान रहें: यहां तक ​​​​कि SQL सर्वर के नवीनतम संस्करण भी महीने के दिन की पहली प्रविष्टि "खाते हैं", इसलिए संख्या को दो बार दर्ज करने की आवश्यकता होगी।

चौथी क्रिया।

पांचवी क्रिया।विकल्प टैब पर स्विच करें। डेटाबेस को अधिलेखित करने का विकल्प सेट करें, वीटी के अंतिम खंड को बनाने के विकल्प को अनचेक करें, यदि यह उपलब्ध हो तो "लक्षित डेटाबेस से मौजूदा कनेक्शन बंद करें" विकल्प को सक्षम करें:

छठा कर्म।"विदेशी स्रोत" से पुनर्स्थापित करने के बाद, पुनर्स्थापित आधार (ZUP_SUV) को एक विदेशी तार्किक नाम (ZUP3ENERGO) प्राप्त होगा। इसे डेटाबेस गुण संवाद में वापस लौटाया जाना चाहिए (डेटाबेस, गुणों पर राइट क्लिक करें)। यदि ऐसा नहीं किया जाता है, तो बहुत ही अप्रिय परिणाम होंगे।

आपको और आपके डेटा को शुभकामनाएँ!

1C 8.3 और 8.2 में बैकअप सबसे महत्वपूर्ण ऑपरेशन है जो प्रत्येक उपयोगकर्ता, प्रोग्रामर, व्यवस्थापक को करने में सक्षम होना चाहिए। सूचना प्रौद्योगिकी विशेषज्ञ भी अक्सर ऐसी प्रतिलिपि को 1C बैकअप कहते हैं। विचार करें कि यह क्या है और विस्तृत निर्देश।

लोगों को दो श्रेणियों में बांटा गया है: वे जो अभी तक बैकअप नहीं बनाते हैं, और जो पहले से ही करते हैं।- सिस्टम एडमिनिस्ट्रेटर का मजाक।

बैकअप लेना क्यों ज़रूरी है? सब कुछ बहुत सरल है, आपको क्षुद्रता के नियम को याद रखने की आवश्यकता है: सबसे बुरी चीजें गलत समय पर होती हैं.

कल्पना कीजिए - आप एक महीने के लिए अंतिम रिपोर्ट तैयार कर रहे हैं, गलतियों को सुधार रहे हैं, कार्यक्रम में प्राथमिक दस्तावेज के किलोग्राम चला रहे हैं। फिर हमने एक ब्रेक लेने, कुछ चाय डालने का फैसला किया। कार्यस्थल पर लौटने पर, आप पाते हैं कि सफाई करने वाली महिला ने आपके सिस्टम यूनिट के कॉर्ड को छुआ (बिजली की वृद्धि हुई, सहकर्मियों ने मशीन में कॉफी भर दी, आदि)। आप अपने कंप्यूटर को चालू करने की पूरी कोशिश करते हैं, लेकिन यह जवाब नहीं देता है। कल रिपोर्टिंग क्या करें?

ऐसी स्थिति में न आने के लिए, सप्ताह में कम से कम एक बार (या दिन में एक बार बेहतर) बैकअप लेने की जोरदार सिफारिश की जाती है। यह करना मुश्किल नहीं है, इसमें अधिकतम 10 मिनट लगेंगे, लेकिन यह एक कठिन परिस्थिति में जीवन को बहुत सुविधाजनक बनाएगा।

267 1सी वीडियो सबक मुफ्त में प्राप्त करें:

1सी . में बैकअप के लिए निर्देश

1C में डेटाबेस बैकअप को हटाने के लिए एक संक्षिप्त निर्देश पर विचार करें। निर्देश डेटाबेस के फ़ाइल मोड और क्लाइंट-सर्वर मोड दोनों के लिए उपयुक्त है।

फ़ाइल में डेटाबेस की एक प्रति अपलोड करना

प्रोग्राम को विन्यासकर्ता मोड में दर्ज करें। ऐसा करने के लिए, प्रोग्राम की प्रारंभ विंडो में, आवश्यक डेटाबेस का चयन करें और "कॉन्फ़िगरेटर" पर क्लिक करें:

आप डेटाबेस विकास और प्रशासन मोड में प्रवेश करेंगे। अगला, मेनू आइटम "प्रशासन - अनलोड इन्फोबेस ..." चुनें:

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

फ़ाइल को बाहरी मीडिया (उदाहरण के लिए, एक फ्लैश ड्राइव, एक बाहरी हार्ड ड्राइव) में सहेजना सबसे अच्छा है।

बैकअप से 1C 8.3 डेटाबेस को कैसे पुनर्स्थापित करें

किसी फ़ाइल से डेटाबेस को पुनर्स्थापित करने के लिए, आपको कॉन्फ़िगरेटर मोड में भी प्रवेश करना होगा, लेकिन "प्रशासन - लोड इन्फोबेस ..." आइटम का चयन करें:

बैकअप बनाने के कई तरीके हैं:

• डेटाबेस फ़ाइलों की प्रतिलिपि बनाना;
• फ़ाइल को .dt फ़ाइल में अपलोड करना;
• कॉन्फ़िगरेशन टूल 1C 8.3 का उपयोग करके बैकअप लें।

आइए 1C डेटाबेस के "बैकअप" बनाने के प्रत्येक तरीके पर अधिक विस्तार से विचार करें।

साधारण फ़ाइल कॉपी विस्तार के साथ " *.1सीडी"और यदि आवश्यक हो - 1सीवी8लॉग"आईबी निर्देशिका से :

ईवेंट लॉग सेटिंग के आधार पर सत्र के प्रवेश और निकास, डेटा परिवर्तन, लॉन्च और पृष्ठभूमि कार्यों के निष्पादन और अन्य जानकारी के बारे में जानकारी संग्रहीत करता है:

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

विन्यासकर्ता में 1C डेटाबेस को उतारना, जहाँ dt एक्सटेंशन के साथ एक संपीड़ित फ़ाइल बनाई जाती है। यदि आवश्यक हो, तो आप पंजीकरण लॉग को अलग से संग्रहित भी कर सकते हैं।

इन्फोबेस को उतारना

हम आईबी को मोड में शुरू करते हैं विन्यासकर्ता:

हम IB अनलोडिंग विज़ार्ड प्रारंभ करते हैं:

हम आईबी को अनलोड करते हैं, जहां हम बैकअप के स्थान को इंगित करते हैं:

पूरा होने पर, आईबी अनलोडिंग के पूरा होने पर एक संदेश दिखाई देगा:

एक प्रति बनाने के बाद, आपको प्रदर्शन की जांच (परीक्षण) करने की आवश्यकता है डीटीफ़ाइल - आईबी लोड करके, पहले परीक्षण के लिए आईबी बनाएं।

1C 8.3 बैकअप से डेटाबेस को कैसे पुनर्स्थापित करें

हम आईबी को मोड में शुरू करते हैं विन्यासक.

हम आईबी डाउनलोड विज़ार्ड लॉन्च करते हैं, जहां हम स्थान निर्दिष्ट करते हैं *.डीटीफ़ाइल:

1C बैकअप को पुनर्स्थापित करने के बाद, IB के सफल लोडिंग और पुनरारंभ करने के अनुरोध के बारे में एक चेतावनी दिखाई देगी विन्यासकर्ता:

इस बैकअप पद्धति को बनाते समय, यह आवश्यक है कि इस आईबी के सभी उपयोगकर्ता अपना सत्र समाप्त कर दें।

पहले से बनाई गई बैकअप कॉपी से डेटा को पुनर्स्थापित करने के तरीके के बारे में अधिक विवरण के लिए, जिसमें मौजूदा इन्फोबेस या नए बनाए गए इन्फोबेस में डेटा को पुनर्स्थापित करने का तरीका शामिल है, हमारा वीडियो देखें:

कॉन्फ़िगरेशन टूल का उपयोग करके 1C संग्रह बनाना और कॉन्फ़िगर करना

स्वचालित बैकअप , जो 1C:Enterprise उपयोगकर्ता मोड में कॉन्फ़िगर किया गया है। यह मोड डेवलपर्स द्वारा 1C:Enterprise 8.3 प्लेटफॉर्म (एंटरप्राइज अकाउंटिंग, रेव। 8.3, पेरोल और एचआर, रेव। 8.3, ट्रेड मैनेजमेंट, रेव। 11.2) पर कॉन्फ़िगरेशन में बनाया गया था:

आप यहाँ कर सकते हैं:

• एक बार का बैकअप चलाएँ:

• शेड्यूल बनाएं:

• बैकअप से पुनर्स्थापित करें:

सलाह:

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

यदि आपके पास अभी भी प्रश्न हैं, तो आप हमारे वीडियो को देख सकते हैं, जिसमें अधिक विस्तार से वर्णन किया गया है कि कॉन्फ़िगरेशन मोड में ही प्रौद्योगिकी प्लेटफॉर्म का उपयोग करके एक इन्फोबेस की एक संग्रह प्रतिलिपि कैसे बनाई जाए:

इस लेख को रेट करें:

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

मैन्युअल रूप से 1C बैकअप बनाना

हम 1C लॉन्च करते हैं और आपके इन्फोबेस के लिए कॉन्फिगरेटर मोड का चयन करते हैं:

विन्यासकर्ता में प्रवेश करने के बाद, व्यवस्थापन मेनू पर जाएं और "सूचना आधार अपलोड करें" आइटम का चयन करें

एक विंडो दिखाई देती है जिसमें आपको बैकअप सहेजने के लिए फ़ोल्डर निर्दिष्ट करने की आवश्यकता होती है (मेरे मामले में इसे अभिलेखीय प्रतियां 1C कहा जाता है, आप इसे जो चाहें नाम दे सकते हैं), बैकअप फ़ाइल का नाम (मेरे मामले में BP20082012, पहले दो अक्षर इन्फोबेस के नाम का पदनाम हैं, फिर तारीख को सेव करें, यानी 20 अगस्त, 2012) और सेव बटन पर क्लिक करें।

हम फ़ाइल को सहेजने के लिए प्रोग्राम की प्रतीक्षा कर रहे हैं। इस ऑपरेशन का निष्पादन विन्यासकर्ता विंडो के निचले बाएँ कोने में देखा जा सकता है:

पूरा होने पर, प्रोग्राम निम्न संदेश प्रदर्शित करेगा:

बैकअप बनाया गया है।

बैकअप से डेटाबेस को कैसे पुनर्स्थापित करें में वर्णित है।

शेड्यूल के अनुसार 1C में स्वचालित बैकअप सेट करना

यह मार्गदर्शिका आपको स्वचालित बैकअप सेट करने में सहायता करेगी। यह केवल 1C डेटाबेस में ऑपरेशन के फ़ाइल मोड के लिए उपयुक्त है। क्लाइंट-सर्वर मोड में कॉन्फ़िगर करने के लिए, 1C DBMS टूल्स - MS SQL, Postgre, आदि का उपयोग करके बैकअप बनाने की सिफारिश करता है।

कॉन्फ़िगर करने के लिए, "प्रशासन" टैब पर जाएं, "समर्थन और रखरखाव" आइटम:

आप अपने कंप्यूटर पर या बाहरी हार्ड ड्राइव पर डेटाबेस की प्रतियां संग्रहीत कर सकते हैं, और 1C क्लाउड आर्काइव सेवा का उपयोग करना भी संभव है।

मैन्युअल रूप से बैकअप शुरू करने और पुनर्स्थापित करने का कार्य यहां भी उपलब्ध है, लेकिन हम "बैकअप सेटिंग्स" आइटम में रुचि रखते हैं:

संभावित विन्यास विकल्प निर्धारित हैं और कार्यक्रम के साथ काम के अंत में। सबसे अच्छा, खासकर यदि आप एक से अधिक आधार पर काम करते हैं, तो "नियमित रूप से निर्धारित" विकल्प चुनें। इसे सेट करना बहुत आसान है। स्क्रीनशॉट में, मैंने एक दैनिक दिनचर्या स्थापित की है:

इन सेटिंग्स के अलावा, आपको प्रतियों को संग्रहीत करने के लिए निर्देशिका भी निर्दिष्ट करनी होगी (Google ड्राइव या यांडेक्स डिस्क का उपयोग करना सबसे अच्छा है) और कितने बैकअप स्टोर करने हैं:

इस निर्देश में, हम देखेंगे कि 1C फ़ाइल बेस बैकअप कैसे कॉन्फ़िगर किया गया है, कौन से बैकअप विकल्प हैं, और बनाए गए बैकअप की जांच कैसे करें।

यह निर्देश केवल फ़ाइल डेटाबेस के लिए प्रासंगिक है। यदि आपके पास क्लाइंट-सर्वर डेटाबेस है, तो इसका बैकअप या तो DBMS () का उपयोग करके या तृतीय-पक्ष प्रोग्राम का उपयोग करके कॉन्फ़िगर किया जाना चाहिए।

एक उदाहरण के रूप में, आइए एक विशिष्ट कॉन्फ़िगरेशन "एंटरप्राइज़ अकाउंटिंग संस्करण 3.0" लें।

1C फ़ाइल डेटाबेस बैकअप सेट करना

मेनू "प्रशासन" - "रखरखाव" पर जाएं:

"बैकअप और पुनर्स्थापना" अनुभाग का विस्तार करें

यहां हम "बैकअप विधि" क्षेत्र में रुचि रखते हैं।

2 विकल्प हैं: और "1C: क्लाउड आर्काइव"।

आइए प्रत्येक विकल्प पर विचार करें।

1सी: क्लाउड आर्काइव

यदि आपके पास ITS:Prof सदस्यता है और आप इसे मना नहीं करने जा रहे हैं, तो मैं इसका उपयोग करने की सलाह देता हूं "1C: क्लाउड आर्काइव", इसलिये यह सेवा आपके लिए निःशुल्क है। क्लाउड स्टोरेज का एक और प्लस यह है कि जब कंप्यूटर भौतिक रूप से नष्ट हो जाता है या आपकी हार्ड ड्राइव टूट जाती है तो आप डेटाबेस को पुनर्स्थापित कर सकते हैं। यदि आपके पास ITS नहीं है, तो अगले भाग पर जाएँ।

"1C: क्लाउड सेवा" चुनें और "कनेक्ट" पर क्लिक करें:

खुलने वाले फॉर्म में, ITS से अपना उपयोगकर्ता नाम और पासवर्ड दर्ज करें और "कनेक्ट" पर क्लिक करें:

तकनीकी सहायता के लिए एक पत्र तैयार किया जाएगा, और यह आपको पंजीकरण करने में मदद करेगा।

यदि कोई ITS:Prof सदस्यता नहीं है, तो क्लाउड की कीमत आपको लगभग 1000 रूबल / माह होगी। अब हम विश्लेषण करेंगे कि ऐसा कैसे करना है, लेकिन मुफ्त में।

"स्थानीय कंप्यूटर पर" विकल्प चुनें और "बैकअप सेटिंग्स" पर क्लिक करें:

"स्वचालित बैकअप निष्पादित करें" बॉक्स को चेक करें

बैकअप को सहेजने के लिए निर्देशिका निर्दिष्ट करें। यह बेहतर है कि यह एक अलग हार्ड ड्राइव हो। यदि कोई अलग हार्ड डिस्क नहीं है, तो उस डिस्क के विभाजन में निर्देशिका निर्दिष्ट करें जहां विंडोज स्थापित नहीं है। वे। ड्राइव "सी" के अलावा कोई अन्य:

बैकअप सहेजने के लिए निर्देशिका

"बैकअप रखें"- "पिछले 10 टुकड़े" निर्दिष्ट करें, आमतौर पर यह पर्याप्त है, साथ ही यह हार्ड ड्राइव पर ज्यादा जगह नहीं लेगा:

केवल अंतिम 10 प्रतियां ही रखें

अब हमें यह तय करने की आवश्यकता है कि बैकअप कैसे किया जाएगा: "नियमित अनुसूचित"या ।

चुनते समय, यह ध्यान में रखा जाना चाहिए कि दोनों ही मामलों में, बैकअप प्रतिलिपि बनाने के लिए 1C आधार के सभी उपयोगकर्ताओं को "निष्कासित" किया जाएगा।

विकल्प "नियमित रूप से निर्धारित"

यह विकल्प चुना जा सकता है यदि सभी उपयोगकर्ता एक ही समय पर निकलते हैं, उदाहरण के लिए, दोपहर के भोजन या चाय के लिए।

फिर “एक दिन; दिन में एक बार" और एक शेड्यूल चुनें। उदाहरण के लिए, सभी के दोपहर के भोजन के लिए जाने के 15 मिनट बाद (यदि किसी को देर हो जाए)

खुलने वाले मेनू में, "हर दिन दोहराएं" फ़ील्ड में "1" डालें और "हर दिन; दिन में एक बार":

"दैनिक" टैब पर जाएं और "प्रारंभ समय" फ़ील्ड में वह समय निर्दिष्ट करें जब आप बैकअप प्रतिलिपि बनाना चाहते हैं। फिर "ओके" पर क्लिक करें:

परिणाम इस तरह दिखना चाहिए:

कृपया ध्यान दें कि आपका पहला सत्र इस समय चल रहा होना चाहिए, अर्थात। दोपहर के भोजन के लिए निकलते समय, आपको 1s सक्षम छोड़ना होगा ताकि एक प्रति बनाई जा सके

विकल्प "शटडाउन पर"

यह विकल्प आपके लिए उपयुक्त है यदि आप कार्यालय छोड़ने वाले अंतिम व्यक्ति हैं (या कम से कम 1C छोड़ने के लिए अंतिम)।

इस विकल्प में, आपको अतिरिक्त रूप से कुछ भी कॉन्फ़िगर करने की आवश्यकता नहीं है। जब आप 1C को बंद करते हैं, तो सिस्टम आपको एक बैकअप प्रतिलिपि बनाने की पेशकश करेगा।

शटडाउन बैकअप कैसे काम करता है?

जब आप 1C से बाहर निकलते हैं, तो "शटडाउन पर बैकअप पूरा नहीं हुआ" विंडो दिखाई देगी:

शटडाउन पर बैकअप विफल रहा

यदि आप "शट डाउन" पर क्लिक करते हैं, तो 1C बिना बैकअप के बंद हो जाएगा।

जब आप 1C के निचले दाएं कोने में "जारी रखें" पर क्लिक करते हैं, तो निम्न विंडो दिखाई देगी:

एक विंडो आपसे बैकअप लेने के लिए कह रही है

इस विंडो को लाने के लिए उस पर क्लिक करें:

बैकअप चलाएँ

यह केवल "बैकअप निष्पादित करें" को अनचेक किए बिना "समाप्त करें" पर क्लिक करने के लिए बनी हुई है। उसके बाद, 1C एक बैकअप कॉपी बनाएगा और काम पूरा करेगा:

एक इन्फोबेस बैकअप बनाना

तो, सबसे महत्वपूर्ण काम किया गया है, बैकअप बनाए जा रहे हैं, यह डेटा को अप्रत्याशित घटना से बचाने के लिए स्वचालित रूप से क्लाउड पर प्रतियां अपलोड करने के लिए बनी हुई है।

क्लाउड पर 1C बैकअप अपलोड करना

अपने कंप्यूटर पर कोई भी क्लाउड सेवा एप्लिकेशन डाउनलोड करें। आमतौर पर वे Cloud mail.ru और Yandex.Disk के बीच चयन करते हैं। यदि आपका बैकअप 2 जीबी से कम "वजन" करता है, तो आप कोई भी चुन सकते हैं, यदि बैकअप का वजन 2 जीबी से अधिक है, तो आपको निश्चित रूप से Yandex.Disk लेने की आवश्यकता है। यदि आप कोई अन्य क्लाउड सेवा पसंद करते हैं - इसका उपयोग करें। मुख्य बात यह है कि यह सेवा सही आकार की फाइलों को स्वीकार करती है।

//help.mail.ru/cloud_web/confines

अपलोड की गई फाइलों पर प्रतिबंध:

तैयार! 1C फ़ाइल बेस बैकअप सेटअप अब पूरा हो गया है।

1C बैकअप बनाया जा रहा है

डेटाबेस के साथ फ़ोल्डर में जाएं और "1Cv8.1CD" फ़ाइल को हटा दें

डेटाबेस की एक प्रति के साथ अंतिम बनाए गए संग्रह को खोलें और वहां मौजूद फ़ाइल को नए डेटाबेस के साथ फ़ोल्डर में निकालें:

डेटाबेस फ़ाइल निकालना

नए डेटाबेस पर जाएं और जांचें कि आवश्यक डेटा है (उदाहरण के लिए, ताजा कार्यान्वयन)। यदि डेटाबेस शुरू हो गया है और डेटा जगह पर है, तो सब कुछ क्रम में है।