बैकअप आदेश के लिए BUFFERCOUNT, BLOCKSIZE, और MAXTRANSFERSIZE सेट करना

Question

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

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

• विभिन्न हार्डवेयर / लोड कारक क्या किया जाना चाहिए को प्रभावित करते हैं।
• क्या ऐसी परिस्थितियां हैं जिनमें इनमें से किसी भी मूल्य को ओवरराइड नहीं किया जाना चाहिए?
• क्या इनमें से किसी को भी ओवरराइड करने के नुकसान हैं जो तुरंत स्पष्ट नहीं हैं? बहुत अधिक मेमोरी और / या डिस्क I / O का उपयोग करना? पुनर्स्थापना कार्यों की शिकायत करना?
• यदि मेरे पास SQL ​​सर्वर के कई इंस्टेंस चल रहे हैं (एक डिफ़ॉल्ट इंस्टेंस और दो नामांकित इंस्टेंस), और अगर मैं सभी 3 इंस्टेंस के बैकअप को समवर्ती रूप से चलाता हूं, तो क्या यह प्रभावित करता है कि मैं इन मूल्यों को कैसे सामूहिक बनाने से परे सेट करता हूं ( BUFFERCOUNT* MAXTRANSFERSIZE) उपलब्ध रैम से अधिक नहीं है? संभव I / O विवाद?
• एक ही सर्वर पर तीन इंस्टेंसेस होने और फिर तीनों समवर्ती में बैकअप चलाने के एक ही परिदृश्य में, प्रत्येक इंस्टेंस के भीतर एक से अधिक डेटाबेस के लिए बैकअप को कैसे चलाना भी इन मूल्यों की सेटिंग को प्रभावित करेगा? मतलब, अगर तीनों इंस्टैंस में से प्रत्येक में 100 डेटाबेस हैं, तो प्रत्येक इंस्टेंस पर 2 या 3 बैकअप चल रहे हैं जैसे कि 6 और 9 बैकअप के बीच समवर्ती चल रहे हैं। (इस स्थिति में, मेरे पास कुछ बड़े लोगों के बजाय कई छोटे से मध्यम डेटाबेस हैं।)

मैंने अब तक क्या इकट्ठा किया है:

• BLOCKSIZE:

  • समर्थित आकार 512, 1024, 2048, 4096, 8192, 16384, 32768, और 65536 (64 KB) बाइट्स हैं। ^[1]
  • टेप डिवाइस और 512 अन्यथा के लिए डिफ़ॉल्ट 65536 है ^[1]
  • यदि आप एक बैकअप ले रहे हैं जिसे आप CD-ROM से कॉपी और रिस्टोर करने की योजना बना रहे हैं, तो BLOCKSIZE = 2048 ^{1 को} निर्दिष्ट करें।
  • जब आप एकल डिस्क पर लिखते हैं, तो 512 का डिफ़ॉल्ट ठीक है; यदि आप RAID सरणियों या SAN का उपयोग करते हैं, तो आपको यह देखने के लिए परीक्षण करना होगा कि क्या डिफ़ॉल्ट या 65536 बेहतर है। ^{[१३ (पृष्ठ १ 13)]}

  • यदि मैन्युअल रूप से सेट किया जाता है, तो मान होना चाहिए> = डेटा फ़ाइल बनाने के लिए उपयोग किया गया ब्लॉक आकार, अन्यथा आपको निम्नलिखित जानकारी मिलेगी:

    Msg 3272, स्तर 16, राज्य 0, पंक्ति 3
    'C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak' डिवाइस का हार्डवेयर क्षेत्र आकार 4096 है, लेकिन ब्लॉक आकार पैरामीटर निर्दिष्ट करता है 512 का एक असंगत ओवरराइड मान। संगत ब्लॉक आकार का उपयोग करते हुए कथन को फिर से प्रकाशित करें।

• BUFFERCOUNT:

  • डिफ़ॉल्ट ^{[2], [} : ^] :

    SQL सर्वर 2005 और बाद के संस्करण:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: इस मूल्य के बारे में कुछ असंगतता है। मैंने इसे 3 रूपों में व्यक्त किया है:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    परीक्षण जो गुणक को दिखाता है वह 3SQL Server 2005 SP2 ^[9] पर किया गया था ।

    SQL Server 2008 R2 और 2012 पर मेरा परीक्षण, और SQL Server 2014 ^{[8] के} संबंध में एक उपयोगकर्ता टिप्पणी , गुणक को दर्शाता है 4। मतलब, GetSuggestedIoDepth(सीधे नीचे) के लिए सूचित मूल्य दिया गया है :

    • GetSuggestedIoDepthअब है 4, या
    • गुणक अब है GetSuggestedIoDepth + 1
  • GetSuggestedIoDepth3DISK उपकरणों के लिए रिटर्न ^[9]
  • कोई कड़ी मेहनत से सेट की गई अधिकतम मूल्य है, लेकिन यह देखते हुए कि स्मृति की आवश्यकता = ( BUFFERCOUNT* MAXTRANSFERSIZE), यह प्रतीत होता है एक व्यावहारिक अधिकतम मूल्य होगा कि: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • संभावित मूल्य 65536 बाइट्स (64 KB) के गुणकों से 4194304 बाइट्स (4 एमबी) तक हैं। ^[1]
  • डिफ़ॉल्ट मान: यदि डिवाइस रीड मोड (रिस्टोर) में है या यह डेस्कटॉप या एक्सप्रेस एडिशन 64K का उपयोग करता है, तो 1 एमबी का उपयोग करें। ^[9]
• सामान्य / विविध:
  • अधिकतम आकार जो उपयोग किया जा सकता है वह है ( बफर पूल की भौतिक मेमोरी / 16 )। GlobalMemoryStatusEx (ullTotalPhys) API कॉल से लौटे । ^[9]
  • ट्रेस ध्वज 3213बैकअप / पुनर्स्थापना संचालन के दौरान बैकअप / पुनर्स्थापना कॉन्फ़िगरेशन पैरामीटर को 3605आउटपुट करता है , और ERRORLOG फ़ाइल को आउटपुट डंप करता है:DBCC TRACEON (3213, 3605, -1);
  • आप कुछ मेट्रिक्स के आसान परीक्षण के लिए (UNIX में DISK = N'NUL:'DOS / Windows समतुल्य /dev/null) का उपयोग कर सकते हैं (लेकिन कुल प्रक्रिया समय का अच्छा बोध नहीं मिलेगा क्योंकि यह I / O लिख रहा है)

साधन

1. T-SQL बैकअप आदेश के लिए MSDN पृष्ठ
2. KB904804: SQL Server 2000 में डेटाबेस का बैकअप लेने पर आपको धीमी कार्यक्षमता का अनुभव होता है
3. SQL सर्वर बैकअप प्रदर्शन में सुधार करने के लिए विकल्प
4. बैकअप और पुनर्स्थापना
5. SQL सर्वर बैकअप और पुनर्स्थापित का अनुकूलन
6. बैकअप प्रदर्शन का अनुकूलन
7. कैसे संपीड़न और ठोस राज्य डिस्क का उपयोग कर SQL डेटाबेस पूर्ण बैकअप गति को बढ़ाने के लिए
8. गलत BufferCount डेटा ट्रांसफर विकल्प OOM स्थिति को जन्म दे सकता है
9. यह कैसे काम करता है: कैसे SQL सर्वर बैकअप और पुनर्स्थापना का चयन करें स्थानांतरण आकार
10. यह कैसे काम करता है: SQL सर्वर बैकअप बफर एक्सचेंज (एक वीडीआई फोकस)
11. SQL बैकअप बड़े डेटाबेस ट्यूनिंग
12. बैकअप बफर के लिए SQL सर्वर मेमोरी
13. एक केस स्टडी: नेटवर्क (.docx फ़ाइल) पर VLDB का तेज़ और विश्वसनीय बैकअप और पुनर्स्थापना ।
14. बैकअप प्रदर्शन को बेहतर बनाने के लिए कितने बैकअप डिवाइस की सिफारिश की जाती है?

---

मैंने इसके साथ परीक्षण किया:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

---

अद्यतन करें

ऐसा लगता है कि मैं कभी-कभी कुछ जानकारी जोड़ना भूल जाता हूं जो मैं हमेशा दूसरों से पूछ रहा हूं कि मैं एक प्रश्न का उत्तर दे रहा हूं ;-)। मैंने अपनी वर्तमान स्थिति के बारे में कुछ जानकारी दी है, लेकिन मैं और अधिक विवरण प्रदान कर सकता हूं:

मैं एक क्लाइंट के लिए काम कर रहा हूं जो 24/7 / 365.25 SaaS एप्लिकेशन प्रदान करता है। इसलिए उपयोगकर्ताओं के लिए किसी भी बिंदु पर होने की संभावना है, लेकिन वास्तविक रूप से, उपयोगकर्ता सभी यूएसए-आधारित (अभी के लिए) हैं और ज्यादातर "मानक" घंटे काम करने की प्रवृत्ति रखते हैं: 7 बजे प्रशांत (यानी 10 बजे पूर्वी) से शाम 7 बजे तक प्रशांत (यानी 10 पीएम पूर्वी), लेकिन सप्ताह में 7 दिन, न केवल सोमवार - शुक्रवार, हालांकि सप्ताहांत लोड थोड़ा हल्का है।

उन्हें ऐसे सेट किया जाता है कि प्रत्येक ग्राहक का अपना डीबी हो। यह एक आला उद्योग है इसलिए संभावित ग्राहकों के हजारों (या अधिक) नहीं हैं। क्लाइंट डीबी की संख्या प्रति इंस्टेंस में बदलती है, जिसमें सबसे बड़ा इंस्टेंस 206 क्लाइंट्स का होता है। सबसे बड़ा DB लगभग है। 8 जीबी, लेकिन लगभग 30 डीबी 1 जीबी से अधिक हैं। इसलिए, मैं विशेष रूप से वीएलडीबी के प्रदर्शन को अधिकतम करने की कोशिश नहीं कर रहा हूं।

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

सेटअप अब प्रति दिन एक पूर्ण बैकअप और अन्य दिनों में DIFF बैकअप करने के लिए है; हर 10 मिनट में लॉग बैकअप लिया जाता है। मैं उन 3 विकल्पों के लिए डिफ़ॉल्ट मानों का उपयोग कर रहा हूं जिनके बारे में मैं यहां पूछताछ कर रहा हूं। लेकिन, यह जानते हुए कि वे कैसे सेट किए गए थे, मैं यह सुनिश्चित करना चाहता था कि मैं एक अनुकूलन को पूर्ववत नहीं कर रहा था (सिर्फ इसलिए कि पुरानी प्रणाली में कुछ प्रमुख दोष थे इसका मतलब यह नहीं है कि सब कुछगलत था)। वर्तमान में, 206 डेटाबेस के लिए, पूर्ण बैकअप के लिए लगभग 62 मिनट लगते हैं (सप्ताह में एक बार) और शेष दिनों में डीआईएफएफ बैकअप के लिए 7 और 20 मिनट के बीच (फुल के बाद पहले दिन, और अंतिम दिन 20 पहले अगले पूर्ण)। और वह उन्हें क्रमिक रूप से (एकल धागा) चला रहा है। लॉग बैकअप प्रक्रिया, कुल मिलाकर (सभी 3 उदाहरणों पर सभी DBs), हर बार (फिर से, हर 10 मिनट में) 50 से 90 सेकंड तक कहीं भी ले जाती है।

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

मुझे यह भी एहसास है कि मैं कम्प्रेशन को सक्षम कर सकता हूं (मेरी टेस्ट क्वेरी को जानबूझकर अक्षम कर दिया गया है), और मैंने टीम के लिए सिफारिश की थी, लेकिन यह मेरे ध्यान में लाया गया था कि अंतर्निहित संपीड़न थोड़े बेकार है। पुरानी प्रक्रिया का एक भाग प्रत्येक फ़ाइल को RAR में संपीड़ित करना था, और मैंने अपना परीक्षण किया और पाया कि हाँ, RAR संस्करण मूल रूप से संपीड़ित संस्करण की तुलना में कम से कम 50% छोटा है। मैंने चीजों को गति देने के लिए पहले देशी संपीड़न का उपयोग करने की कोशिश की और फिर फाइलों को RAR किया, लेकिन उन फ़ाइलों को, जबकि केवल मूल संपीड़ित की तुलना में छोटे थे, अभी भी RAR- केवल संकुचित संस्करण की तुलना में थोड़ा बड़ा था, और औचित्य के लिए पर्याप्त अंतर से देशी संपीड़न का उपयोग नहीं। बैकअप को संपीड़ित करने की प्रक्रिया अतुल्यकालिक है और हर X मिनट चलती है। अगर यह एक .bakया.trnफ़ाइल, यह इसे संपीड़ित करता है। इस प्रकार, बैकअप प्रक्रिया को प्रत्येक फ़ाइल को संपीड़ित करने में लगने वाले समय तक धीमा नहीं किया जाता है।

Comments

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

— परिजनों शाह

@ नहीं, बैकअप विशेष रूप से धीमा नहीं हैं। लेकिन, अगर कोई मामूली बदलाव करता है / उन्हें 20% (या अधिक) तेज कर सकता है, तो मैं निश्चित रूप से इसे ले जाऊंगा। 206 डेटाबेस के लिए, पूर्ण बैकअप के लिए लगभग 62 मिनट (सप्ताह में एक बार) और शेष दिनों में डीआईएफएफ बैकअप के लिए 7 से 20 मिनट लगते हैं। और वह उन्हें क्रमिक रूप से (एकल धागा) चला रहा है। जब मैंने इस क्लाइंट के साथ शुरुआत की, तो पहले सेटअप में मैक्सट्रांसफर के लिए ४ एमबी और बफ़रकेन्ट के लिए ५० का उपयोग करना था। वर्तमान में मैं केवल डिफॉल्ट्स का उपयोग कर रहा हूं, इसलिए यदि मैं प्रदर्शन लाभ को कम करता हूं तो अनिश्चित हो जाता हूं, इसलिए कोई भी बदलाव करने से पहले अधिक सीखना चाहता हूं।

— सोलोमन रटज़की

@srutzky आपकी पिछली टिप्पणी से बस एक त्वरित बिंदु है, मैंने एक ही वॉल्यूम में जाने वाली कई फाइलों में अपने बैकअप को तोड़ने में काफी समय बचाया। मैं सिर्फ यह साझा करना चाहता था कि अगर आपके द्वारा अभी तक ऐसा कुछ नहीं किया गया है। यदि आपके 206 DBs कई DBs के समानांतर में एक बैकअप चलाते हैं, हालांकि आपको मल्टी-थ्रेडिंग लाभ नहीं मिल सकता है।

— अली रज़ेगी

@MaxVernon "वर्चुअल डिवाइस इंटरफ़ेस (VDI) बैकअप SQL सर्वर के साथ एकीकृत करने के लिए 3rd पार्टी बैक-अप समाधान की अनुमति देता है।" जो कि मेरे प्रश्न :) में संसाधन # 10 से लिया गया था। मैं उस बहुत प्रयास से नहीं गुजरना चाहता था ;-)

— सोलोमन रटज़की

अगर आप कुछ मज़ा लेना चाहते हैं तो @srutzky: MSSQL Backups पढ़ें - HBA अधिकतम स्थानांतरण आकार की जाँच करें - आदमी शानदार है और वास्तव में पूरी तरह से उसके परीक्षणों में है। और ऐसा कुछ जो संभवतः आपके परीक्षणों से मेल खाता है: SirSQL की स्वचालित बैकअप ट्यूनिंग ।

— मैरियन

Answer 1

आपने अपने प्रश्न में आइटमों की एक नाव को संबोधित किया है। इतनी अच्छी तरह से होने के लिए धन्यवाद!

बस कुछ चीजें जो मैंने नोटिस की हैं:

• विभिन्न हार्डवेयर / लोड कारक क्या किया जाना चाहिए को प्रभावित करते हैं।

आप एक 24x7 उदाहरण चल रहे हैं? घड़ी के चारों ओर लोड क्या है? मुझे लगता है कि आपके पास बैकअप संपीड़न अक्षम है; क्या यह परीक्षण के लिए डिजाइन के द्वारा, या यह किसी कारण के लिए वांछनीय है जब आप इसे उत्पादन में डालते हैं? यदि आपके पास हार्डवेयर हेडरूम (CPU / RAM) है, और बैकअप को कम से कम समय में पूरा करना सर्वोपरि है, तो आप उस विशेष हार्डवेयर के लिए इन मापदंडों को ट्यून करना चाहेंगे जो आपके पास उस लक्ष्य को ध्यान में रखते हुए हों। यदि आप यह सुनिश्चित करना चाहते हैं कि OLTP वर्कलोड को घड़ी के आसपास सेवित किया जाए, और बैकअप को प्रभावित करने के लिए नहीं चाहिए, तो आपको इन मापदंडों को दूसरे तरीके से ट्यून करने की आवश्यकता होगी। आपने अपने डिजाइन लक्ष्यों की पहचान नहीं की है क्योंकि आप सामान्य मार्गदर्शन के लिए पूछ रहे हैं क्योंकि आप बहुत समझदारी से "यह निर्भर करता है ™"।

• क्या ऐसी परिस्थितियां हैं जिनमें इनमें से किसी भी मूल्य को ओवरराइड नहीं किया जाना चाहिए?

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

• क्या इनमें से किसी को भी ओवरराइड करने के नुकसान हैं जो तुरंत स्पष्ट नहीं हैं? बहुत अधिक मेमोरी और / या डिस्क I / O का उपयोग करना? पुनर्स्थापना कार्यों की शिकायत करना?

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

• अगर मेरे पास SQL ​​सर्वर के कई इंस्टेंस चल रहे हैं (एक डिफ़ॉल्ट इंस्टेंस और दो नामांकित इंस्टेंसेस), और अगर मैं सभी 3 इंस्टेंसेस का बैकअप समवर्ती रूप से चलाता हूं, तो यह प्रभावित करता है कि मैं इन मूल्यों को कैसे सुनिश्चित करने से परे सेट करता हूं कि कलेक्टिव (BUFFERCOUNT) * MAXTRANSFERSIZE) उपलब्ध RAM से अधिक नहीं है? संभव I / O विवाद?

आप अप्रत्याशित परिस्थितियों के लिए रैम को भरपूर छोड़ने के लिए सुनिश्चित करना चाहते हैं। मैं निश्चित रूप से बैकअप संचालन के लिए उपलब्ध राम के ६०% या available०% से अधिक उपयोग करने के बारे में चिंतित हूं जब तक कि मैं १००% निश्चितता के साथ नहीं जानता था कि बैकअप विंडो के दौरान कुछ और कभी नहीं होने जा रहा था।

मैंने कुछ कोड के साथ एक ब्लॉग-पोस्ट लिखी है जो दिखाता है कि मैं SQLServerScience.com पर बैकअप प्रदर्शन परीक्षण कैसे करता हूं

---

^{यह मेरे द्वारा लिखा गया सबसे अच्छा उत्तर नहीं हो सकता है, लेकिन जैसा कि द ग्रेट वन ™ ने एक बार कहा था, "आपको 100% शॉट्स याद नहीं हैं"}

Comments

उन संकेत के लिए धन्यवाद, मैक्स। उस के लिए +1 :)। मैंने अपने पहले से ही नहीं लघु-प्रश्न पर एक अद्यतन अनुभाग को जोड़ा, प्रश्न पर कुछ टिप्पणी और आपके प्रश्न के बारे में यहाँ सवाल यह है कि मैं संपीड़न का उपयोग क्यों नहीं कर रहा हूं। मेरा मानना ​​है कि मैंने आपके प्रश्न का उत्तर भी दिया कि मैं बैकअप कैसे चला रहा हूं :-)।

— सोलोमन रटज़की