नेटवर्क बैकअप के लिए विकल्प


11

हमारे वातावरण में हमारे पास कुछ सर्वर हैं जो हमेशा ऑन उपलब्धता समूह में हैं, और कुछ ऐसे हैं जो स्टैंडअलोन हैं।

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

Ola Hallengren की स्क्रिप्ट का उपयोग संपीड़न के साथ किया जा रहा है और बैकअप फ़ाइलों को विभाजित करने में भी। मैं केवल दैनिक "पूर्ण" बैकअप कर रहा हूं। बैकअप नेटवर्क शेयर EMC isilon ड्राइव पर जा रहे हैं।

मैं ईएमसी डीडी बूस्ट के साथ कभी भी सहज नहीं हूं। एकमात्र विकल्प एक स्थानीय बैकअप करना और फिर उसी नेटवर्क शेयर की प्रतिलिपि बनाना है।

क्या उपरोक्त के अलावा कोई कुशल तरीका है?


एक बार डेटाबेस एक निश्चित आकार के लिए बैकअप डेटा के लिए एकमात्र संभव तरीका हो जाता है प्रतिकृति के माध्यम से है। लेकिन ऐसा लग रहा है कि आपकी स्थिति अभी तक नहीं है। फिर भी, प्रतिकृति के बारे में अभी कोई शोध नहीं हुआ है
slebetman

जवाबों:


10

आपके द्वारा बताया गया विकल्प सबसे अच्छा विकल्प लगता है।

आप क्या कर सकते हैं एक 2 कदम प्रक्रिया है:

  • स्थानीय रूप से ओला के बैकअप समाधान का उपयोग करके संपीड़न के साथ मूल एसक्यूएल सर्वर बैकअप लें।
  • नेटवर्क शेयर में स्थानान्तरण करने के लिए रोबोकॉपी का उपयोग करें। यह डिकोड किया गया है और विंडोज शेड्यूल किए गए कार्य के रूप में चल सकता है।

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

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

इसके अलावा, नियमित रूप से अपने रिस्टोर का परीक्षण करें क्योंकि यदि आप बैकअप को बहाल नहीं कर सकते हैं - तो यह किस उद्देश्य से काम करता है!

इसके अलावा, SQL बैकअप ट्यूनिंग बड़े डेटाबेस के लिए मेरे जवाब का संदर्भ लें


15

MAXTRANSFERSIZE या BUFFERCOUNT जैसे अलग-अलग नॉब के साथ मैसेज करके या फ़ाइल को स्ट्रिप करने के तरीके बैकअप हैं (या आपने जो नोट किया है, वह पहले ही कर चुके हैं)।

समस्या यह है कि उन knobs को छूने से अभी भी आपके नेटवर्क और / या स्टोरेज की सीमाएं प्रभावित हो सकती हैं, और बैकअप समय पर उनका कोई वास्तविक प्रभाव नहीं पड़ता है।

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

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

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


9

संभावित समाधानों की एक जोड़ी:

  1. पूर्ण से केवल एक साप्ताहिक पूर्ण बैकअप और रात के अंतर पर जाना एक आसान समाधान हो सकता है।
  2. कई प्रदर्शन-संबंधित पैरामीटर हैं जिन्हें आप ओला की लिपियों में ट्विक कर सकते हैं, आप जो चाहें वो प्रदर्शन प्राप्त करने के लिए इनका उपयोग कर सकते हैं:


    • ब्लॉकसाइज़ बाइट्स में भौतिक अवरोधन निर्दिष्ट करें।

      DatabaseBackup में BlockSize ऑप्शन BLOCKSIZESQL Server BACKUP कमांड में विकल्प का उपयोग करता है ।

    • BufferCount
      बैकअप ऑपरेशन के लिए उपयोग किए जाने वाले I / O बफ़र्स की संख्या निर्दिष्ट करें।

      DatabaseBackup में BufferCount विकल्प BUFFERCOUNTSQL सर्वर BACKUPकमांड में विकल्प का उपयोग करता है ।

    • MaxTransferSize SQL सर्वर और बैकअप मीडिया के बीच उपयोग करने के लिए, बाइट्स में स्थानांतरण की सबसे बड़ी इकाई निर्दिष्ट करें।

      DatabaseBackup में MaxTransferSize विकल्प MAXTRANSFERSIZESQL सर्वर BACKUPकमांड में विकल्प का उपयोग करता है ।


5

कई संभावित विकल्प हैं, लेकिन जैसे-जैसे डेटाबेस बड़े होते जाते हैं और पूरा बैकअप लंबा होता जाता है, आपको संभवतः अंतर बैकअप को शामिल करना होगा , अगर आपने पहले से नहीं किया है:

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

मेरी समझ यह है कि ओला की लिपियों को एक पूर्ण या अंतर बैकअप के बीच भी तय किया जा सकता है, जो कि संशोधन के आधार पर डेटाबेस में बदलाव की मात्रा के आधार पर किया जाता है ।

हम EMC DD Boost का उपयोग करते हैं, और आप इसके बारे में अपनी राय में आपका स्वागत करते हैं, लेकिन हमने पाया है कि क्लाइंट-साइड डी-डुप्लीकेशन विधियों के कारण, यह उपयोग करता है, यहां तक ​​कि मल्टी-टीबी डेटाबेस का भी पूर्ण बैकअप बहुत तेज़ हो सकता है, इस बिंदु पर कि हमें SQL सर्वर अंतर बैकअप के बारे में चिंता करने की ज़रूरत नहीं है। EMC DD का उपयोग करके आप अंतर बैकअप कर रहे हैं, SQL सर्वर में नहीं। डीडीबोस्ट पर भी कई डेस्टिनेशन फाइल्स का इस्तेमाल करने से स्पीड में काफी सुधार होता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.