SQL DB का अधिक बार बैकअप लेना


10

मेरा वर्तमान में एक निर्धारित कार्य है जो प्रत्येक रात 2 बजे बंद हो जाता है जो SQLCMD.exe को कॉल करता है और इसे बैकअप के लिए चलाने के लिए .sql स्क्रिप्ट पास करता है (नीचे दिखाया गया है)। हम एक बहुत छोटी कंपनी है, जो व्यवसाय की ओर से प्रमुख विकास के कारण बढ़ती जरूरतों के साथ है। इस बिंदु पर 1 दिन का डेटा खोने से पिछले साल इस बार एक सौ सौ बनाम दसियों डॉलर खर्च होंगे। जब तक मैं इस डीबी प्लेटफॉर्म को एक अलग समाधान पर स्थानांतरित नहीं कर सकता, जहां एसक्यूएल अज़ूर जैसे प्रमुख अतिरेक के साथ डेटा मिररिंग होता है, तो सबसे अच्छी बात यह है कि मैं अधिक लगातार बैकअप प्राप्त करने के लिए क्या कर सकता हूं? क्या यह स्क्रिप्ट डीबी को ऑफ़लाइन होने के लिए मजबूर करती है? क्या मैं डीबी के साथ बातचीत करने वाले उपयोगकर्ताओं के साथ इस स्क्रिप्ट को चला सकता हूं?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

अपडेट करें

वाह, स्पष्ट रूप से एसओ की तुलना में यहाँ पर अधिक समर्पित डीबीए समुदाय है। अब तक की प्रतिक्रिया के लिए धन्यवाद। केवल एक चीज गायब है "कैसे।" मैंने ऊपर SQL कमांड दिखाया है कि मैं दैनिक बैकअप करने के लिए उपयोग कर रहा हूं, लेकिन वृद्धिशील लॉग बैकअप उदाहरण MIA हैं। यह एक बड़ा DB नहीं है, यह वर्तमान में SQLExpress पर चलता है। जब मैं हा या एसक्यूएल अज़ूर कहता हूं, तो मैं विशेष रूप से उस जगह की वास्तुकला की बात कर रहा हूं जो हमारे पास एक छोटे व्यवसाय के रूप में नहीं है। यह उदाहरण वर्तमान में हमारे केवल सर्वर पर चल रहा है। यदि वह सर्वर क्रैश हो जाता है, तो रिकवर करने का हमारा समय एक स्टिकिंग पॉइंट बन जाता है। यही कारण है कि SQL Azure आकर्षक हो जाता है।


आपके अपडेट के लिए मेरे जवाब को संपादित किया, आशा है कि यह मदद करता है

जवाबों:


5

EDIT, आपके अपडेट से

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

चूँकि यह आपका एकमात्र सर्वर है, जिससे मैं यह सुनिश्चित करूँगा कि आप डेटाबेस के विरुद्ध DBCC CHECKDB चला रहे हैं। जब आप पता लगाते हैं कि वे भ्रष्ट हैं तो बैकअप अच्छा नहीं लगता (मुझे लगता है कि किसी ने भी इसका उल्लेख किया है)। आप किसी भी त्रुटि को पकड़ने के लिए DBCC संदेश के लिए SQL ERRORLOG की जांच करने के लिए एक निर्धारित कार्य को सेटअप करने के लिए कुछ स्क्रिप्ट्स को खोज सकते हैं। SQL सर्वर आपको मूल रूप से DBCC संदेशों से लौटाए गए त्रुटियों की चेतावनी नहीं देगा, इसलिए जब तक आप प्रत्येक बार एक स्क्रिप्ट की जांच नहीं करते हैं जो ऐसा करती है।

अंतर बैकअप कमांड:


USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

1
@ शॉन: ओपी ने कहा कि "इस बिंदु पर 1 दिन का डेटा खोने से पिछले साल इस बार सौ डॉलर बनाम एक जोड़े का खर्च आएगा", जहां उसने कहा था कि वह 1 दिन का डेटा खो सकता है !!!
मैरियन

8
  • एसक्यूएल सर्वर में बैकअप न होने से खलल पड़ता है। यानी डेटाबेस चालू रहता है। प्रलेखन पढ़ें।
  • हर दिन एक पूर्ण बैकअप करें, उसके बाद शिप किया गया (कॉपी किया हुआ) लॉग बैकअप (फिर से, प्रलेखन है ... प्रलेखन) और अधिक नियमित रूप से - हर 15 मिनट या तो।

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

2
बहुत बुरा है कि मैं इस साइट पर जवाब नहीं दे सकता ...
RSolberg

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

2
@ रोलबर्ग: आपको पेशाब करने के लिए खेद है। यह इरादा नहीं है। लेकिन इस समुदाय ने कैसे मदद नहीं की? आपके पास अच्छे और मान्य उत्तर (और टिप्पणियां) हैं। आपका खुद का संदेश था: "इस बिंदु पर 1 दिन का डेटा खोने पर पिछले साल इस बार एक सौ सौ बनाम दस लाख डॉलर खर्च होंगे।" इसलिए आपको एक ठोस बैकअप और पुनर्स्थापना रणनीति की आवश्यकता है ताकि आप वहां न पहुंचें। एक ठोस रणनीति बहुत अच्छी तरह से मूल बातें जानने से आती है। जो मैनुअल पढ़ने और समझने से आते हैं। क्षमा करें यदि आप कुछ और समझते हैं!
मैरियन

2
मैं @Rolberg से सहमत हूँ कि यहाँ अधिकांश उत्तर "कैसे" नहीं दिखाते हैं, लेकिन यह भी है क्योंकि प्रश्न में कुछ विस्तार से कमी थी "क्या" आप रसेल को नहीं समझ पाए। आपको हमें थोड़ा और बताना होगा कि आपको क्या चाहिए, लेकिन मैं आपसे सहमत हूं कि यहां की साइट "RTFM n00b" के बारे में नहीं है। इसके अलावा, जैसा कि आपने बताया, आपके पास स्टैक ओवरफ्लो पर 10k है , इसलिए आप निश्चित रूप से फ्लैगिंग टिप्पणियों को समझते हैं जो असभ्य या विघटनकारी हैं। भविष्य में, आपको निराशा में उबालने के बजाय जल्द से जल्द ऐसा करना चाहिए।
jcolebrand

6

पहली चीज जो आपको करने की ज़रूरत है वह यह पता लगाना है कि आप कितना डेटा खो सकते हैं। तब तक आपको पता नहीं चलेगा कि डेटाबेस का बैकअप लेने के लिए कितनी बार। यह एक संख्या नहीं है जिसे आपको लेकर आना चाहिए। यह कुछ ऐसा है जो व्यवसाय (या एक छोटी कंपनी में सीईओ) को तय करना होगा। पहला नंबर वे 0 मिनट के साथ वापस आने वाले हैं। जो किया जा सकता है, लेकिन ऐसा करना बहुत महंगा होगा। वास्तव में डेटा की सबसे छोटी राशि है कि आप के लिए बैकअप ले सकते हैं हर 2 मिनट के बारे में है। यदि सिस्टम में डेटा की मात्रा काफी कम है तो आप हर मिनट में बैकअप कर सकते हैं।

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

यदि आप 5 मिनट के डेटा को खोने का जोखिम उठा सकते हैं तो आप शायद प्रतिदिन पूर्ण बैकअप करना चाहेंगे, और हर 5 मिनट में लॉग बैकअप लेना होगा। यदि आप 15 मिनट का डेटा खो सकते हैं तो आप हर 15 मिनट में पूर्ण बैकअप और लेन-देन लॉग बैकअप करना चाहेंगे।

एक अन्य विकल्प साप्ताहिक पूर्ण बैकअप, दैनिक अंतर बैकअप और लेनदेन लॉग बैकअप हर एक्स मिनट में करना होगा जैसा कि मैं ऊपर बात करता हूं।

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

सभी बैकअप जो BACKUP डेटाबेस और BACKUP लॉग स्टेटमेंट का उपयोग करते हैं, वे ऑनलाइन किए जाते हैं और उपयोगकर्ताओं को डेटाबेस तक पहुंचने से नहीं रोकते हैं।


मैं वास्तव में यह आकलन करने में सक्षम हूं कि हम कितना डेटा खो सकते हैं। छोटे व्यवसायों को लोगों को कई टोपी पहनने की आवश्यकता होती है, क्योंकि CIO मैं रोज़ाना व्यापार निर्णयों की लाइन में शामिल होता है।
आरएसबर्गबर्ग 27'11

1
यह चर्चा को बहुत कम कर देगा।
मर्दानी

3

कहते हैं कि आपके व्यस्ततम समय के साथ आपके पास एक सामान्य व्यवसाय परिदृश्य है: 9 am-5pm सोमवार-शुक्रवार। तब मैं सुझाव दूंगा: रविवार रात को पूर्ण बैकअप। अंतर बैकअप सुबह 8 बजे, शाम 6 बजे और 1 बजे (रिकवरी टाइम कम करने के लिए)। हर घंटे या अपने व्यवसाय की आवश्यकता के आधार पर बैकअप लॉग करें।

आपकी अवधारण अवधि के आधार पर, पुरानी बैकअप फ़ाइलों को खाली करने के लिए आपके पास एक स्वचालित सफाई कार्य होना चाहिए। इन सभी को SQL रखरखाव योजनाओं का उपयोग करके बनाया जा सकता है। SQL 2005 के लिए इस लिंक को देखें

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


2

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


टैग खो गए थे, यह एक बड़ा डेटाबेस नहीं है। यह वर्तमान में एक SQLExpress उदाहरण पर चल रहा है।
RSolberg

1
एक्सप्रेस पर चल रहा है दसियों हज़ार डॉलर? दिलचस्प!
आंद्रेई रोनेया

ज़रुरी नहीं। निर्भर करता है कि आप क्या स्टोर करते हैं (कोई ग्रंथ नहीं, कोई बायनेरी नहीं) - यह डेटा का 10 गीगाबाइट है। आप 10 गीगाबाइट में एक बड़ी कंपनी - गंभीर बड़ी कंपनी के लिए - एक लेखा प्रणाली चला सकते हैं। प्रति दिन 100.000 आदेश के साथ एक ऑनलाइन दुकान आसानी से 10 गीगाबाइट में दुकान की ओर कर सकती है।
टॉमॉम

1

क्या आप ऑफ-साइट स्टोरेज प्राप्त करने के लिए रात में अपने बैकअप फ़ोल्डर को क्लाउड कर सकते हैं? चूंकि मुझे पूरा यकीन है कि यह एक स्वास्थ्य देखभाल कंपनी के लिए है, क्या कोई ऐसा है जो HiPA के अनुपालन के लिए पर्याप्त सुरक्षित है? या हो सकता है बस उन्हें सुपर एन्क्रिप्ट करें?

क्या स्क्रिप्ट कम से कम बैकअप की एक प्रति नेटवर्क शेयर पर डालती है? इस तरह अगर भौतिक बॉक्स ऊपर उड़ जाता है ...


हाँ ऊपर के सभी के लिए। हम वास्तव में एक नेटवर्क ड्राइव के लिए बैकअप लेते हैं जो कि प्रतिबिंबित होता है और हम उस वातावरण से डेटा को सुरक्षित डेटा सेंटर में कॉपी करते हैं।
RSolberg
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.