🥇एलवीएम और मैत्रियोश्का में क्या समानता है?

गुड डे.
मैं समुदाय के साथ md RAID + LVM का उपयोग करके KVM के लिए डेटा भंडारण प्रणाली बनाने का अपना व्यावहारिक अनुभव साझा करना चाहता हूं।

कार्यक्रम में शामिल होंगे:

NVMe SSD से md RAID 1 का निर्माण।
SATA SSD और नियमित ड्राइव से md RAID 6 को असेंबल करना।
SSD RAID 1/6 पर ट्रिम/डिस्कार्ड ऑपरेशन की विशेषताएं।
डिस्क के सामान्य सेट पर बूट करने योग्य md RAID 1/6 सरणी बनाना।
BIOS में कोई NVMe समर्थन न होने पर NVMe RAID 1 पर सिस्टम इंस्टॉल करना।
LVM कैश और LVM थिन का उपयोग करना।
BTRFS स्नैपशॉट का उपयोग करना और बैकअप के लिए भेजना/प्राप्त करना।
बीटीआरएफएस स्टाइल बैकअप के लिए एलवीएम थिन स्नैपशॉट और थिन_डेल्टा का उपयोग करना।

यदि आप रुचि रखते हैं, तो कृपया बिल्ली देखें।

Заявление

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

कुरकुरा-तले हुए NVMe SSDs।
पूरी तरह से रिकॉर्डिंग संसाधन का उपयोग और एसएसडी ड्राइव की विफलता।
बैकअप प्रतियों सहित सभी ड्राइव पर सभी डेटा का पूर्ण नुकसान।
दोषपूर्ण कंप्यूटर हार्डवेयर.
समय, स्नायु और पैसा बर्बाद किया।
कोई अन्य परिणाम जो ऊपर सूचीबद्ध नहीं हैं।

लोहा

उपलब्ध थे:

Z2013 चिपसेट के साथ 87 के आसपास का मदरबोर्ड, इंटेल कोर i7 / हैसवेल के साथ पूरा हुआ।

प्रोसेसर 4 कोर, 8 धागे
32 जीबी डीडीआर3 रैम
1 x 16 या 2 x 8 PCIe 3.0
1 एक्स 4 + 1 एक्स 1 पीसीआईई 2.0
6 x 6 जीबीपीएस SATA 3 कनेक्टर

SAS एडाप्टर LSI SAS9211-8I IT/HBA मोड पर फ्लैश हुआ। RAID-सक्षम फ़र्मवेयर को जानबूझकर HBA फ़र्मवेयर से बदल दिया गया है:

आप इस एडॉप्टर को किसी भी समय फेंक सकते हैं और इसे आपके सामने आए किसी अन्य एडॉप्टर से बदल सकते हैं।
TRIM/Discard डिस्क पर सामान्य रूप से काम करता है, क्योंकि... RAID फ़र्मवेयर में ये कमांड बिल्कुल भी समर्थित नहीं हैं, और HBA, सामान्य तौर पर, इस बात की परवाह नहीं करता है कि बस पर कौन से कमांड प्रसारित किए जाते हैं।

हार्ड ड्राइव - लैपटॉप के लिए 8 फॉर्म फैक्टर में 7 टीबी की क्षमता के साथ एचजीएसटी ट्रैवलस्टार 1000के1 के 2.5 टुकड़े। ये ड्राइव पहले RAID 6 ऐरे में थे। नई व्यवस्था में इनका भी उपयोग होगा। स्थानीय बैकअप संग्रहीत करने के लिए.

इसके अतिरिक्त जोड़ा गया:

6 टुकड़े SATA SSD मॉडल सैमसंग 860 QVO 2TB। इन SSDs के लिए बड़ी मात्रा की आवश्यकता थी, SLC कैश की उपस्थिति, विश्वसनीयता और कम कीमत वांछित थी। त्याग/शून्य के लिए समर्थन की आवश्यकता थी, जिसे dmesg में लाइन द्वारा जांचा जाता है:

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD मॉडल सैमसंग SSD 2 EVO 970GB के 500 टुकड़े।

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

8 x NVMe SSD के लिए StarTech PEX2M2E2 एडाप्टर PCIe 3.0 8x स्लॉट में स्थापित किया गया है। यह, फिर से, सिर्फ एक एचबीए है, लेकिन एनवीएमई के लिए। यह सस्ते एडेप्टर से इस मायने में भिन्न है कि इसमें अंतर्निहित PCIe स्विच की उपस्थिति के कारण इसे मदरबोर्ड से PCIe द्विभाजन समर्थन की आवश्यकता नहीं होती है। यह PCIe के साथ सबसे प्राचीन प्रणाली में भी काम करेगा, भले ही यह X1 PCIe 1.0 स्लॉट हो। स्वाभाविक रूप से, उचित गति से। वहां कोई छापेमारी नहीं होती. बोर्ड पर कोई अंतर्निहित BIOS नहीं है। तो, आपका सिस्टम जादुई रूप से NVMe के साथ बूट करना नहीं सीखेगा, इस डिवाइस के लिए NVMe RAID तो बिल्कुल भी नहीं सीखेगा।

यह घटक पूरी तरह से सिस्टम में केवल एक मुफ़्त 8x PCIe 3.0 की उपस्थिति के कारण था, और, यदि 2 मुफ़्त स्लॉट हैं, तो इसे आसानी से दो पैसे वाले PEX4M2E1 या एनालॉग्स से बदला जा सकता है, जिसे 600 की कीमत पर कहीं भी खरीदा जा सकता है। रूबल.

सभी प्रकार के हार्डवेयर या अंतर्निहित चिपसेट/BIOS RAID की अस्वीकृति जानबूझकर की गई थी, ताकि सभी डेटा को संरक्षित करते हुए, SSD/HDD को छोड़कर, पूरे सिस्टम को पूरी तरह से बदलने में सक्षम बनाया जा सके। आदर्श रूप से, ताकि आप पूरी तरह से नए/अलग हार्डवेयर पर जाते समय स्थापित ऑपरेटिंग सिस्टम को भी सहेज सकें। मुख्य बात यह है कि इसमें SATA और PCIe पोर्ट हैं। यह एक लाइव सीडी या बूट करने योग्य फ्लैश ड्राइव की तरह है, केवल बहुत तेज़ और थोड़ा भारी।

हास्यअन्यथा, आप जानते हैं कि क्या होता है - कभी-कभी आपको तत्काल संपूर्ण सरणी अपने साथ ले जाने की आवश्यकता होती है। लेकिन मैं डेटा खोना नहीं चाहता। ऐसा करने के लिए, सभी उल्लिखित मीडिया मानक केस के 5.25 बे में स्लाइड पर सुविधाजनक रूप से स्थित हैं।

खैर, और, ज़ाहिर है, लिनक्स में एसएसडी कैशिंग के विभिन्न तरीकों के साथ प्रयोग करने के लिए।

हार्डवेयर छापे उबाऊ हैं. इसे चालू करें। यह या तो काम करता है या नहीं करता है। और mdadm के साथ हमेशा विकल्प होते हैं।

मुलायम

इससे पहले, डेबियन 8 जेसी को हार्डवेयर पर स्थापित किया गया था, जो ईओएल के करीब है। RAID 6 को LVM के साथ जोड़े गए उपर्युक्त HDD से असेंबल किया गया था। यह kvm/libvirt में वर्चुअल मशीनें चलाता था।

क्योंकि लेखक के पास पोर्टेबल बूट करने योग्य SATA/NVMe फ्लैश ड्राइव बनाने का उपयुक्त अनुभव है, और साथ ही, सामान्य उपयुक्त टेम्पलेट को न तोड़ने के लिए, Ubuntu 18.04 को लक्ष्य प्रणाली के रूप में चुना गया था, जो पहले से ही पर्याप्त रूप से स्थिर हो चुका है, लेकिन अभी भी 3 साल का है भविष्य में समर्थन.

उल्लिखित सिस्टम में वे सभी हार्डवेयर ड्राइवर शामिल हैं जिनकी हमें आवश्यकता है। हमें किसी तृतीय-पक्ष सॉफ़्टवेयर या ड्राइवर की आवश्यकता नहीं है।

स्थापना की तैयारी

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

हम इससे खुश नहीं हैं.

क्यों?दुर्भाग्य से, UEFI बूट बूट सॉफ़्टवेयर RAID के साथ बेहद खराब संगत है, क्योंकि... कोई भी हमें यूईएफआई ईएसपी विभाजन के लिए आरक्षण प्रदान नहीं करता है। ऑनलाइन ऐसे नुस्खे हैं जो ईएसपी विभाजन को यूएसबी पोर्ट में फ्लैश ड्राइव पर रखने का सुझाव देते हैं, लेकिन यह विफलता का बिंदु है। मेटाडेटा संस्करण 1 के साथ सॉफ्टवेयर mdadm RAID 0.9 का उपयोग करने वाले व्यंजन हैं जो UEFI BIOS को इस विभाजन को देखने से नहीं रोकते हैं, लेकिन यह उस सुखद क्षण तक रहता है जब BIOS या कोई अन्य हार्डवेयर OS ESP को कुछ लिखता है और इसे अन्य के साथ सिंक्रनाइज़ करना भूल जाता है दर्पण.

इसके अलावा, यूईएफआई बूट एनवीआरएएम पर निर्भर करता है, जो डिस्क के साथ नए सिस्टम में नहीं जाएगा, क्योंकि मदरबोर्ड का हिस्सा है.

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

उबंटू का डेस्कटॉप संस्करण भी लिगेसी बूटलोडर के साथ ठीक से स्थापित नहीं किया जा सकता है, लेकिन यहां, जैसा कि वे कहते हैं, कम से कम विकल्प हैं।

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

हम डेस्कटॉप वातावरण में जाते हैं, टर्मिनल एमुलेटर लॉन्च करते हैं, और आगे बढ़ते हैं:

#sudo bash

कैसे…?उपरोक्त पंक्ति सुडो के बारे में होलीवारों के लिए विहित ट्रिगर है। सी बीоअधिक से अधिक अवसर आते हैं औरоअधिक जिम्मेदारी. सवाल यह है कि क्या आप इसे अपने ऊपर ले सकते हैं। बहुत से लोग सोचते हैं कि सूडो का इस तरह से उपयोग करना कम से कम सावधान नहीं है। तथापि:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

ZFS क्यों नहीं...?जब हम अपने कंप्यूटर पर सॉफ़्टवेयर इंस्टॉल करते हैं, तो हम अनिवार्य रूप से अपने हार्डवेयर को इस सॉफ़्टवेयर के डेवलपर्स को चलाने के लिए उधार देते हैं।
जब हम अपने डेटा की सुरक्षा के लिए इस सॉफ़्टवेयर पर भरोसा करते हैं, तो हम इस डेटा को पुनर्स्थापित करने की लागत के बराबर ऋण लेते हैं, जिसे हमें किसी दिन चुकाना होगा।

इस दृष्टिकोण से, ZFS एक फेरारी है, और mdadm+lvm एक साइकिल की तरह है।

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

फिर बीटीआरएफएस क्यों...?ऑपरेटिंग सिस्टम को बूट करने के लिए, हमें एक फ़ाइल सिस्टम की आवश्यकता है जो लिगेसी/BIOS GRUB आउट ऑफ़ द बॉक्स में समर्थित हो, और साथ ही लाइव स्नैपशॉट का भी समर्थन करता हो। हम इसका उपयोग /boot विभाजन के लिए करेंगे। इसके अलावा, लेखक इस एफएस का उपयोग / (रूट) के लिए करना पसंद करता है, यह ध्यान रखना नहीं भूलता कि किसी भी अन्य सॉफ़्टवेयर के लिए आप एलवीएम पर अलग-अलग विभाजन बना सकते हैं और उन्हें आवश्यक निर्देशिकाओं में माउंट कर सकते हैं।

हम इस एफएस पर वर्चुअल मशीन या डेटाबेस की कोई भी छवि संग्रहीत नहीं करेंगे।
इस एफएस का उपयोग केवल सिस्टम के स्नैपशॉट को बंद किए बिना बनाने के लिए किया जाएगा और फिर इन स्नैपशॉट को सेंड/रिसीव का उपयोग करके बैकअप डिस्क में स्थानांतरित किया जाएगा।

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

हार्डवेयर पर केवल डेटा भंडारण, वर्चुअलाइजेशन और बैकअप ही बचे हैं।

यदि आप ZFS पर अधिक भरोसा करते हैं, तो, सिद्धांत रूप में, निर्दिष्ट एप्लिकेशन के लिए वे विनिमेय हैं।

हालाँकि, लेखक जानबूझकर ZFS, BRTFS और LVM में मौजूद अंतर्निहित मिररिंग/RAID और अतिरेक सुविधाओं को अनदेखा करता है।

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

आइए सभी डिवाइसों को पुनः स्कैन करें:

#udevadm control --reload-rules && udevadm trigger

आइए चारों ओर एक नज़र डालें:

#lsscsi && nvme list [0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda [1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb [2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc [3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd [4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde [5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf [6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg [6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh [6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi [6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj [6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk [6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl [6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm [6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn Node SN Model Namespace Usage Format FW Rev ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- -------- /dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7 /dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7

डिस्क लेआउट

एनवीएमई एसएसडी

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

SATA HDD

यहां कुछ खास आविष्कार करने की जरूरत नहीं है. हम हर चीज़ के लिए एक अनुभाग बनाएंगे. हम एक विभाजन बनाएंगे क्योंकि BIOS इन डिस्क को देखता है और उनसे बूट करने का प्रयास भी कर सकता है। हम बाद में इन डिस्क पर GRUB भी स्थापित करेंगे ताकि सिस्टम अचानक ऐसा कर सके।

#cat >hdd.part << EOF label: dos label-id: 0x00000000 device: /dev/sdg unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable EOF #sfdisk /dev/sdg < hdd.part #sfdisk /dev/sdh < hdd.part #sfdisk /dev/sdi < hdd.part #sfdisk /dev/sdj < hdd.part #sfdisk /dev/sdk < hdd.part #sfdisk /dev/sdl < hdd.part #sfdisk /dev/sdm < hdd.part #sfdisk /dev/sdn < hdd.part

सैटा एसएसडी

यहीं पर चीजें हमारे लिए दिलचस्प हो जाती हैं।

सबसे पहले, हमारी ड्राइव का आकार 2 टीबी है। यह एमबीआर के लिए स्वीकार्य सीमा के भीतर है, जिसका हम उपयोग करेंगे। यदि आवश्यक हो, तो GPT से बदला जा सकता है। जीपीटी डिस्क में एक संगतता परत होती है जो एमबीआर-संगत सिस्टम को पहले 4 विभाजनों को देखने की अनुमति देती है यदि वे पहले 2 टेराबाइट्स के भीतर स्थित हैं। मुख्य बात यह है कि इन डिस्क पर बूट विभाजन और बायोस_ग्रब विभाजन शुरुआत में होना चाहिए। यह आपको GPT लिगेसी/BIOS ड्राइव से बूट करने की भी अनुमति देता है।

लेकिन ये हमारा मामला नहीं है.

यहां हम दो सेक्शन बनाएंगे. पहला 1 जीबी आकार का होगा और RAID 1/बूट के लिए उपयोग किया जाएगा।

दूसरे का उपयोग RAID 6 के लिए किया जाएगा और ड्राइव के अंत में एक छोटे से असंबद्ध क्षेत्र को छोड़कर शेष सभी खाली स्थान ले लेगा।

यह अचिह्नित क्षेत्र क्या है?नेटवर्क के सूत्रों के अनुसार, हमारे SATA SSDs में 6 से 78 गीगाबाइट आकार का एक गतिशील रूप से विस्तार योग्य SLC कैश है। ड्राइव की डेटा शीट में "गीगाबाइट्स" और "गीबाइट्स" के बीच अंतर के कारण हमें 6 गीगाबाइट "मुफ़्त में" मिलते हैं। शेष 72 गीगाबाइट अप्रयुक्त स्थान से आवंटित किए गए हैं।

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

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

इस प्रकार, हम कुल मिलाकर छह ड्राइव से प्रभावी रूप से 312 गीगाबाइट एसएलसी कैश प्राप्त करेंगे। सभी ड्राइव में से 2 का उपयोग अतिरेक के लिए RAID में किया जाएगा।

कैश की यह मात्रा हमें वास्तविक जीवन में बहुत कम ही ऐसी स्थिति का सामना करने की अनुमति देगी जहां कोई लेख कैश में नहीं जाता है। यह QLC मेमोरी की सबसे दुखद कमी के लिए बहुत अच्छी तरह से क्षतिपूर्ति करता है - जब कैश को बायपास करते हुए डेटा लिखा जाता है तो बेहद कम लिखने की गति। यदि आपका लोड इसके अनुरूप नहीं है, तो मेरा सुझाव है कि आप डेटा शीट से टीबीडब्ल्यू को ध्यान में रखते हुए, इस बारे में गहराई से सोचें कि आपका एसएसडी ऐसे लोड के तहत कितने समय तक चलेगा।

#cat >ssd.part << EOF label: dos label-id: 0x00000000 device: /dev/sda unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable /dev/sda2 : start= 2099200, size= 3300950016, type=fd EOF #sfdisk /dev/sda < ssd.part #sfdisk /dev/sdb < ssd.part #sfdisk /dev/sdc < ssd.part #sfdisk /dev/sdd < ssd.part #sfdisk /dev/sde < ssd.part #sfdisk /dev/sdf < ssd.part

सारणियाँ बनाना

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

#mcedit /etc/hostname #mcedit /etc/hosts #hostname vdesk0

एनवीएमई एसएसडी

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

क्यों -मानो-साफ़...?सरणियों को आरंभ करने से बचने के लिए। RAID स्तर 1 और 6 दोनों के लिए यह मान्य है। यदि यह एक नई सरणी है तो सब कुछ आरंभीकरण के बिना काम कर सकता है। इसके अलावा, निर्माण पर SSD सरणी को प्रारंभ करना TBW संसाधन की बर्बादी है। जहां संभव हो हम असेंबल किए गए SSD सरणियों को "इनिशियलाइज़" करने के लिए TRIM/DISCARD का उपयोग करते हैं।

SSD सरणियों के लिए, RAID 1 DISCARD बॉक्स से बाहर समर्थित है।

SSD RAID 6 DISCARD सरणियों के लिए, आपको इसे कर्नेल मॉड्यूल पैरामीटर में सक्षम करना होगा।

यह केवल तभी किया जाना चाहिए जब इस सिस्टम में लेवल 4/5/6 सरणियों में उपयोग किए जाने वाले सभी SSDs के पास त्याग_शून्य_डेटा के लिए कार्यशील समर्थन हो। कभी-कभी आपके सामने अजीब ड्राइव आती हैं जो कर्नेल को बताती हैं कि यह फ़ंक्शन समर्थित है, लेकिन वास्तव में यह वहां नहीं है, या फ़ंक्शन हमेशा काम नहीं करता है। फिलहाल, समर्थन लगभग हर जगह उपलब्ध है, हालांकि, त्रुटियों के साथ पुरानी ड्राइव और फर्मवेयर भी हैं। इस कारण से, RAID 6 के लिए DISCARD समर्थन डिफ़ॉल्ट रूप से अक्षम है।

ध्यान दें, निम्न आदेश "शून्य" के साथ सरणी को "आरंभ" करके एनवीएमई ड्राइव पर सभी डेटा को नष्ट कर देगा।

#blkdiscard /dev/md0

यदि कुछ गलत होता है, तो एक चरण निर्दिष्ट करने का प्रयास करें।

#blkdiscard --step 65536 /dev/md0

सैटा एसएसडी

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

इतना बड़ा क्यों...?खंड-आकार बढ़ाने से खंड-आकार सहित ब्लॉकों में यादृच्छिक पढ़ने की गति पर सकारात्मक प्रभाव पड़ता है। ऐसा इसलिए होता है क्योंकि उचित आकार या छोटे आकार का एक ऑपरेशन पूरी तरह से एक ही डिवाइस पर पूरा किया जा सकता है। इसलिए, सभी उपकरणों से IOPS का सारांश दिया गया है। आँकड़ों के अनुसार, 99% IO 512K से अधिक नहीं है।

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

हमने अभी तक RAID 6 के लिए DISCARD को सक्षम नहीं किया है। इसलिए हम अभी इस ऐरे को "इनिशियलाइज़" नहीं करेंगे। ओएस स्थापित करने के बाद हम इसे बाद में करेंगे।

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

एनवीएमई RAID पर एलवीएम

गति के लिए, हम रूट फ़ाइल सिस्टम को NVMe RAID 1 पर रखना चाहते हैं जो कि /dev/md0 है।
हालाँकि, हमें अभी भी अन्य जरूरतों, जैसे स्वैप, मेटाडेटा और एलवीएम-कैश और एलवीएम-थिन मेटाडेटा के लिए इस तेज़ सरणी की आवश्यकता होगी, इसलिए हम इस सरणी पर एक एलवीएम वीजी बनाएंगे।

#pvcreate /dev/md0 #vgcreate root /dev/md0

आइए रूट फ़ाइल सिस्टम के लिए एक विभाजन बनाएँ।

#lvcreate -L 128G --name root root

आइए रैम के आकार के अनुसार स्वैपिंग के लिए एक विभाजन बनाएं।

#lvcreate -L 32G --name swap root

ओएस स्थापना

कुल मिलाकर, हमारे पास सिस्टम को स्थापित करने के लिए आवश्यक सभी चीजें हैं।

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

/dev/md1, - माउंट प्वाइंट /बूट, एफएस - बीटीआरएफएस
/dev/root/root (उर्फ /dev/mapper/root-root), - माउंट पॉइंट / (रूट), FS - BTRFS
/dev/root/swap (उर्फ /dev/mapper/root-swap), - स्वैप विभाजन के रूप में उपयोग करें
बूटलोडर को /dev/sda पर स्थापित करें

जब आप रूट फ़ाइल सिस्टम के रूप में BTRFS का चयन करते हैं, तो इंस्टॉलर स्वचालित रूप से / (रूट) के लिए "@" और /home के लिए "@home" नामक दो BTRFS वॉल्यूम बनाएगा।

आइए इंस्टालेशन शुरू करें...

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

#sudo bash

संस्थापन जारी रखने के लिए एक क्रोट वातावरण बनाएँ:

#mkdir /mnt/chroot #mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot #mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home #mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot #mount --bind /proc /mnt/chroot/proc #mount --bind /sys /mnt/chroot/sys #mount --bind /dev /mnt/chroot/dev
आइए चेरोट में नेटवर्क और होस्टनाम को कॉन्फ़िगर करें:

#cat /etc/hostname >/mnt/chroot/etc/hostname #cat /etc/hosts >/mnt/chroot/etc/hosts #cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf
आइए चिरोट वातावरण में चलें:

#chroot /mnt/chroot
सबसे पहले, हम पैकेज वितरित करेंगे:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

आइए उन सभी पैकेजों की जाँच करें और उन्हें ठीक करें जो अपूर्ण सिस्टम इंस्टॉलेशन के कारण टेढ़े-मेढ़े तरीके से इंस्टॉल किए गए थे:

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq) #apt-get install --reinstall $CORRUPTED_PACKAGES
यदि कुछ काम नहीं करता है, तो आपको पहले /etc/apt/sources.list को संपादित करने की आवश्यकता हो सकती है

आइए ट्रिम/डिस्कार्ड को सक्षम करने के लिए RAID 6 मॉड्यूल के मापदंडों को समायोजित करें:

#cat >/etc/modprobe.d/raid456.conf << EOF options raid456 devices_handle_discard_safely=1 EOF
आइए अपनी सारणियों में थोड़ा बदलाव करें:

#cat >/etc/udev/rules.d/60-md.rules << EOF SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768" SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000" SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000" EOF #cat >/etc/udev/rules.d/62-hdparm.rules << EOF SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k" EOF #cat >/etc/udev/rules.d/63-blockdev.rules << EOF SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k" SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k" EOF
यह क्या था..?हमने udev नियमों का एक सेट बनाया है जो निम्नलिखित कार्य करेगा:

RAID 2020 के लिए ब्लॉक कैश आकार को 6 के लिए पर्याप्त सेट करें। ऐसा लगता है कि डिफ़ॉल्ट मान लिनक्स के निर्माण के बाद से नहीं बदला है, और लंबे समय से पर्याप्त नहीं है।
सरणी जांच/सिंक्रनाइज़ेशन की अवधि के लिए न्यूनतम IO आरक्षित करें। यह आपके एरेज़ को लोड के तहत शाश्वत सिंक्रनाइज़ेशन की स्थिति में फंसने से रोकने के लिए है।
सरणियों की जाँच/सिंक्रनाइज़ेशन के दौरान अधिकतम IO को सीमित करें। यह आवश्यक है ताकि SSD RAID को सिंक्रोनाइज़/चेक करने से आपकी ड्राइव खराब न हो जाए। यह एनवीएमई के लिए विशेष रूप से सच है। (रेडिएटर के बारे में याद रखें? मैं मजाक नहीं कर रहा था।)
एपीएम के माध्यम से डिस्क को स्पिंडल रोटेशन (एचडीडी) को रोकने से रोकें और डिस्क नियंत्रकों के लिए स्लीप टाइमआउट को 7 घंटे पर सेट करें। यदि आपकी ड्राइव ऐसा कर सकती है (-बी 255) तो आप एपीएम को पूरी तरह से अक्षम कर सकते हैं। डिफ़ॉल्ट मान के साथ, ड्राइव पांच सेकंड के बाद बंद हो जाएगी। फिर ओएस डिस्क कैश को रीसेट करना चाहता है, डिस्क फिर से घूम जाएगी, और सब कुछ फिर से शुरू हो जाएगा। डिस्क में स्पिंडल घुमावों की अधिकतम संख्या सीमित होती है। ऐसा सरल डिफ़ॉल्ट चक्र कुछ वर्षों में आपकी डिस्क को आसानी से ख़त्म कर सकता है। सभी डिस्क इससे प्रभावित नहीं हैं, लेकिन हमारी डिस्क उपयुक्त डिफ़ॉल्ट सेटिंग्स के साथ "लैपटॉप" हैं, जो RAID को मिनी-MAID जैसा बनाती हैं।
डिस्क पर रीडहेड स्थापित करें (घूर्णन) 1 मेगाबाइट - दो लगातार ब्लॉक/चंक RAID 6
सरणियों पर स्वयं रीडहेड अक्षम करें।

आइए /etc/fstab संपादित करें:

#cat >/etc/fstab << EOF # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # file-system mount-point type options dump pass /dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1 UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2 /dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2 /dev/mapper/root-swap none swap sw 0 0 EOF
ऐसा क्यों..?हम UUID द्वारा /boot विभाजन की खोज करेंगे। सरणी नामकरण सैद्धांतिक रूप से बदल सकता है।

हम शेष अनुभागों को /dev/mapper/vg-lv नोटेशन में LVM नामों से खोजेंगे, क्योंकि वे विभाजनों की पहचान काफी विशिष्ट ढंग से करते हैं।

हम LVM के लिए UUID का उपयोग नहीं करते क्योंकि LVM वॉल्यूम और उनके स्नैपशॉट का UUID समान हो सकता है।माउंट /dev/mapper/root-root.. दो बार?हाँ। बिल्कुल। बीटीआरएफएस की विशेषता. इस फ़ाइल सिस्टम को अलग-अलग सबवोल के साथ कई बार माउंट किया जा सकता है।

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

आइए mdadm कॉन्फ़िगरेशन को पुन: उत्पन्न करें:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf
आइए LVM सेटिंग्स समायोजित करें:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation { thin_pool_autoextend_threshold=90 thin_pool_autoextend_percent=5 } allocation { cache_pool_max_chunks=2097152 } devices { global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1 } EOF
यह क्या था..?हमने वॉल्यूम के 90% तक कब्जे वाले स्थान के 5% तक पहुंचने पर एलवीएम पतले पूल के स्वचालित विस्तार को सक्षम किया है।

हमने LVM कैश के लिए कैश ब्लॉक की अधिकतम संख्या बढ़ा दी है।

हमने LVM को LVM वॉल्यूम (PV) की खोज करने से रोक दिया है:

एलवीएम कैश युक्त डिवाइस (सीडेटा)
कैश को बायपास करते हुए LVM कैश का उपयोग करके डिवाइस को कैश किया गया ( _कोरिग). इस मामले में, कैश्ड डिवाइस को अभी भी कैश के माध्यम से स्कैन किया जाएगा (बस ).
LVM कैश मेटाडेटा (cmeta) युक्त डिवाइस
छवियों नाम के साथ वीजी में सभी डिवाइस। यहां हमारे पास वर्चुअल मशीनों की डिस्क छवियां होंगी, और हम नहीं चाहते कि होस्ट पर एलवीएम अतिथि ओएस से संबंधित वॉल्यूम को सक्रिय करे।
बैकअप नाम के साथ वीजी में सभी डिवाइस। यहां हमारे पास वर्चुअल मशीन छवियों की बैकअप प्रतियां होंगी।
सभी डिवाइस जिनका नाम "जीपीवी" (अतिथि भौतिक वॉल्यूम) से समाप्त होता है

हमने LVM VG पर खाली स्थान खाली करते समय DISCARD समर्थन सक्षम किया है। ध्यान से। इससे SSD पर LV को हटाने में काफी समय लगेगा। यह विशेष रूप से SSD RAID 6 पर लागू होता है। हालाँकि, योजना के अनुसार, हम पतले प्रावधान का उपयोग करेंगे, इसलिए यह हमारे लिए बिल्कुल भी बाधा नहीं बनेगा।

आइए initramfs छवि को अपडेट करें:

#update-initramfs -u -k all

ग्रब स्थापित और कॉन्फ़िगर करें:

#apt-get install grub-pc #apt-get purge os-prober #dpkg-reconfigure grub-pc

कौन सी डिस्क चुनें?वे सभी जो एसडी* हैं। सिस्टम को किसी भी कार्यशील SATA ड्राइव या SSD से बूट करने में सक्षम होना चाहिए।

उन्होंने ओएस-प्रोबर क्यों जोड़ा..?अत्यधिक स्वतंत्रता और चंचल हाथों के लिए.

यदि कोई RAID खराब स्थिति में है तो यह सही ढंग से काम नहीं करता है। यह उन विभाजनों पर OS की खोज करने का प्रयास करता है जिनका उपयोग इस हार्डवेयर पर चलने वाली वर्चुअल मशीनों में किया जाता है।

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

इसके साथ ही हमने शुरुआती इंस्टालेशन पूरा कर लिया है. नए स्थापित ओएस में रीबूट करने का समय आ गया है। बूट करने योग्य लाइव सीडी/यूएसबी को हटाना न भूलें।

#exit #reboot

बूट डिवाइस के रूप में किसी भी SATA SSD का चयन करें।

SATA SSD पर LVM

इस बिंदु पर, हमने पहले से ही नए ओएस में बूट किया है, नेटवर्क कॉन्फ़िगर किया है, एपीटी, टर्मिनल एमुलेटर खोला है, और चलाया है:

#sudo bash

हम जारी रखते हैं।

SATA SSD से सरणी को "प्रारंभ करें":

#blkdiscard /dev/md2

यदि यह काम नहीं करता है, तो प्रयास करें:

#blkdiscard --step 65536 /dev/md2
SATA SSD पर LVM VG बनाएं:

#pvcreate /dev/md2 #vgcreate data /dev/md2

एक और वीजी क्यों..?वास्तव में, हमारे पास पहले से ही रूट नाम का एक वीजी है। सब कुछ एक वीजी में क्यों नहीं जोड़ते?

यदि एक वीजी में कई पीवी हैं, तो वीजी को सही ढंग से सक्रिय करने के लिए, सभी पीवी मौजूद (ऑनलाइन) होने चाहिए। अपवाद LVM RAID है, जिसका हम जानबूझकर उपयोग नहीं करते हैं।

हम वास्तव में चाहते हैं कि यदि RAID 6 सरणियों में से किसी पर विफलता (डेटा हानि पढ़ें) हो, तो ऑपरेटिंग सिस्टम सामान्य रूप से बूट होगा और हमें समस्या को हल करने का अवसर देगा।

ऐसा करने के लिए, अमूर्तता के पहले स्तर पर हम प्रत्येक प्रकार के भौतिक "मीडिया" को एक अलग वीजी में अलग कर देंगे।

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

"हार्डवेयर" स्तर पर एलवीएम की उपस्थिति हमें विभिन्न RAID सरणियों के टुकड़ों को अलग-अलग तरीकों से संयोजित करके मनमाने ढंग से काटने की अनुमति देगी। उदाहरण के लिए - भागो एक साथ bcache + LVM thin, bcache + BTRFS, LVM कैश + LVM thin, कैश के साथ एक जटिल ZFS कॉन्फ़िगरेशन, या यह सब आज़माने और तुलना करने के लिए कोई अन्य नारकीय मिश्रण।

"हार्डवेयर" स्तर पर, हम अच्छे पुराने "मोटे" एलवीएम वॉल्यूम के अलावा किसी अन्य चीज़ का उपयोग नहीं करेंगे। इस नियम का अपवाद बैकअप विभाजन हो सकता है.

मुझे लगता है कि इस क्षण तक, कई पाठकों को घोंसला बनाने वाली गुड़िया के बारे में कुछ संदेह होना शुरू हो गया था।

SATA HDD पर LVM

#pvcreate /dev/md3 #vgcreate backup /dev/md3

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

LVM कैश सेट करना

आइए इसे कैशिंग डिवाइस के रूप में उपयोग करने के लिए NVMe RAID 1 पर एक LV बनाएं।

#lvcreate -L 70871154688B --name cache root

इतना कम क्यों है...?तथ्य यह है कि हमारे एनवीएमई एसएसडी में एसएलसी कैश भी है। 4-बिट एमएलसी में खाली स्थान के कारण 18 गीगाबाइट "फ्री" और 3 गीगाबाइट डायनामिक है। एक बार जब यह कैश समाप्त हो जाता है, तो NVMe SSDs कैश के साथ हमारे SATA SSD से अधिक तेज़ नहीं होंगे। दरअसल, इस कारण से, हमारे लिए LVM कैश विभाजन को NVMe ड्राइव के SLC कैश के आकार से दोगुने से अधिक बड़ा बनाने का कोई मतलब नहीं है। प्रयुक्त NVMe ड्राइव के लिए, लेखक 32-64 गीगाबाइट कैश बनाना उचित मानता है।

64 गीगाबाइट कैश, कैश मेटाडेटा और मेटाडेटा बैकअप को व्यवस्थित करने के लिए दिए गए विभाजन आकार की आवश्यकता होती है।

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

आइए इसे कैश्ड डिवाइस के रूप में उपयोग करने के लिए SATA RAID 6 पर एक LV बनाएं।

#lvcreate -L 3298543271936B --name cache data

तीन टेराबाइट ही क्यों..?ताकि जरूरत पड़ने पर आप कुछ अन्य जरूरतों के लिए SATA SSD RAID 6 का उपयोग कर सकें। कैश्ड स्थान का आकार सिस्टम को रोके बिना, तुरंत, गतिशील रूप से बढ़ाया जा सकता है। ऐसा करने के लिए, आपको अस्थायी रूप से कैश को रोकने और पुन: सक्षम करने की आवश्यकता है, लेकिन उदाहरण के लिए, bcache की तुलना में LVM-कैश का विशिष्ट लाभ यह है कि यह तुरंत किया जा सकता है।

आइए कैशिंग के लिए एक नया वीजी बनाएं।

#pvcreate /dev/root/cache #pvcreate /dev/data/cache #vgcreate cache /dev/root/cache /dev/data/cache

आइए कैश्ड डिवाइस पर एक LV बनाएं।

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

यहां हमने तुरंत /dev/data/cache पर सभी खाली जगह ले ली ताकि अन्य सभी आवश्यक विभाजन तुरंत /dev/root/cache पर बनाए जा सकें। यदि आपने गलत जगह पर कुछ बनाया है, तो आप इसे pvmove का उपयोग करके स्थानांतरित कर सकते हैं।

आइए कैश बनाएं और सक्षम करें:

#lvcreate -y -L 64G -n cache cache /dev/root/cache #lvcreate -y -L 1G -n cachemeta cache /dev/root/cache #lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache #lvconvert -y --type cache --cachepool cache/cache cache/cachedata
ऐसा खंड आकार क्यों..?व्यावहारिक प्रयोगों के माध्यम से, लेखक यह पता लगाने में सक्षम था कि सबसे अच्छा परिणाम तब प्राप्त होता है जब एलवीएम कैश ब्लॉक का आकार एलवीएम पतले ब्लॉक के आकार से मेल खाता है। इसके अलावा, आकार जितना छोटा होगा, रैंडम रिकॉर्डिंग में कॉन्फ़िगरेशन उतना ही बेहतर प्रदर्शन करेगा।

64k LVM थिन के लिए अनुमत न्यूनतम ब्लॉक आकार है।

वापसी में सावधान रहें..!हाँ। इस प्रकार का कैश कैश्ड डिवाइस पर राइट सिंक्रोनाइज़ेशन को विलंबित करता है। इसका मतलब यह है कि यदि कैश खो जाता है, तो आप कैश्ड डिवाइस पर डेटा खो सकते हैं। बाद में, लेखक आपको बताएगा कि इस जोखिम की भरपाई के लिए एनवीएमई RAID 1 के अलावा कौन से उपाय किए जा सकते हैं।

इस कैश प्रकार को RAID 6 के खराब यादृच्छिक लेखन प्रदर्शन की भरपाई के लिए जानबूझकर चुना गया था।

आइए देखें कि हमें क्या मिला:

#lvs -a -o lv_name,lv_size,devices --units B cache LV LSize Devices [cache] 68719476736B cache_cdata(0) [cache_cdata] 68719476736B /dev/root/cache(0) [cache_cmeta] 1073741824B /dev/root/cache(16384) cachedata 3298539077632B cachedata_corig(0) [cachedata_corig] 3298539077632B /dev/data/cache(0) [lvol0_pmspare] 1073741824B /dev/root/cache(16640)
केवल [cachedata_corig] /dev/data/cache पर स्थित होना चाहिए। अगर कुछ गलत है तो pvmove का उपयोग करें।

यदि आवश्यक हो तो आप एक आदेश से कैश को अक्षम कर सकते हैं:

#lvconvert -y --uncache cache/cachedata

यह ऑनलाइन किया जाता है. LVM बस कैश को डिस्क से सिंक करेगा, उसे हटाएगा, और कैशेडेटा_कोरिग का नाम बदलकर वापस कैशेडेटा कर देगा।

एलवीएम पतला सेट करना

आइए मोटे तौर पर अनुमान लगाएं कि एलवीएम पतले मेटाडेटा के लिए हमें कितनी जगह चाहिए:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

4 गीगाबाइट तक पूर्णांक: 4294967296बी

दो से गुणा करें और LVM PV मेटाडेटा के लिए 4194304B जोड़ें: 8594128896B
आइए LVM पतली मेटाडेटा और उस पर उनकी बैकअप प्रतिलिपि रखने के लिए NVMe RAID 1 पर एक अलग विभाजन बनाएं:

#lvcreate -L 8594128896B --name images root

किस लिए..?यहां सवाल उठ सकता है: एलवीएम पतले मेटाडेटा को अलग से क्यों रखें अगर यह अभी भी एनवीएमई पर कैश किया जाएगा और जल्दी से काम करेगा।

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

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

इसके अलावा, यदि पहले एक पतली मात्रा का स्नैपशॉट लिया गया था, और उसके बाद कैश को कम से कम एक बार पूरी तरह से सिंक्रनाइज़ किया गया था, तो, एलवीएम थिन के आंतरिक डिजाइन के कारण, कैश हानि की स्थिति में स्नैपशॉट की अखंडता की गारंटी दी जाएगी .

आइए एक नया वीजी बनाएं जो पतले प्रावधान के लिए जिम्मेदार होगा:

#pvcreate /dev/root/images #pvcreate /dev/cache/cachedata #vgcreate images /dev/root/images /dev/cache/cachedata
आइए एक पूल बनाएं:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
क्यों -Z yइसके अलावा यह मोड वास्तव में किसके लिए अभिप्रेत है - अंतरिक्ष को पुनर्वितरित करते समय एक वर्चुअल मशीन से डेटा को दूसरी वर्चुअल मशीन में लीक होने से रोकने के लिए - 64k से छोटे ब्लॉक में यादृच्छिक लेखन की गति को बढ़ाने के लिए शून्यकरण का अतिरिक्त उपयोग किया जाता है। पतली मात्रा के पहले से असंबद्ध क्षेत्र में 64k से कम का कोई भी लेखन कैश में 64K किनारे-संरेखित हो जाएगा। यह कैश्ड डिवाइस को दरकिनार करते हुए ऑपरेशन को पूरी तरह से कैश के माध्यम से निष्पादित करने की अनुमति देगा।

आइए एलवी को संबंधित पीवी में ले जाएं:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata #pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images #pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images
चलो देखते है:

#lvs -a -o lv_name,lv_size,devices --units B images LV LSize Devices [lvol0_pmspare] 4294967296B /dev/root/images(0) thin-pool 274877906944B thin-pool_tdata(0) [thin-pool_tdata] 274877906944B /dev/cache/cachedata(0) [thin-pool_tmeta] 4294967296B /dev/root/images(1024)
आइए परीक्षणों के लिए एक पतला वॉल्यूम बनाएं:

#lvcreate -V 64G --thin-pool thin-pool --name test images

हम परीक्षण और निगरानी के लिए पैकेज स्थापित करेंगे:

#apt-get install sysstat fio

इस प्रकार आप वास्तविक समय में हमारे भंडारण कॉन्फ़िगरेशन के व्यवहार का निरीक्षण कर सकते हैं:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

इस प्रकार हम अपनी कॉन्फ़िगरेशन का परीक्षण कर सकते हैं:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1 --name=4kQD32read --bs=4k --iodepth=32 --rw=randread --name=8kQD32read --bs=8k --iodepth=32 --rw=randread --name=16kQD32read --bs=16k --iodepth=32 --rw=randread --name=32KQD32read --bs=32k --iodepth=32 --rw=randread --name=64KQD32read --bs=64k --iodepth=32 --rw=randread --name=128KQD32read --bs=128k --iodepth=32 --rw=randread --name=256KQD32read --bs=256k --iodepth=32 --rw=randread --name=512KQD32read --bs=512k --iodepth=32 --rw=randread --name=4Kread --bs=4k --rw=read --name=8Kread --bs=8k --rw=read --name=16Kread --bs=16k --rw=read --name=32Kread --bs=32k --rw=read --name=64Kread --bs=64k --rw=read --name=128Kread --bs=128k --rw=read --name=256Kread --bs=256k --rw=read --name=512Kread --bs=512k --rw=read --name=Seqread --bs=1m --rw=read --name=Longread --bs=8m --rw=read --name=Longwrite --bs=8m --rw=write --name=Seqwrite --bs=1m --rw=write --name=512Kwrite --bs=512k --rw=write --name=256write --bs=256k --rw=write --name=128write --bs=128k --rw=write --name=64write --bs=64k --rw=write --name=32write --bs=32k --rw=write --name=16write --bs=16k --rw=write --name=8write --bs=8k --rw=write --name=4write --bs=4k --rw=write --name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite --name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite --name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite --name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite --name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite --name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite --name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite --name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite | grep -E 'read|write|test' | grep -v ioengine
सावधानी से! संसाधन!यह कोड 36 अलग-अलग परीक्षण चलाएगा, प्रत्येक 4 सेकंड के लिए चलेगा। आधे परीक्षण रिकॉर्डिंग के लिए हैं। आप NVMe पर 4 सेकंड में बहुत कुछ रिकॉर्ड कर सकते हैं। प्रति सेकंड 3 गीगाबाइट तक. इसलिए, प्रत्येक लेखन परीक्षण आपसे 216 गीगाबाइट एसएसडी संसाधन तक खा सकता है।

पढ़ना और लिखना मिश्रित?हाँ। पढ़ने और लिखने के परीक्षण को अलग-अलग चलाना समझ में आता है। इसके अलावा, यह सुनिश्चित करना समझ में आता है कि सभी कैश सिंक्रनाइज़ हैं ताकि पहले से किया गया लेखन पढ़ने को प्रभावित न करे।

पहले लॉन्च के दौरान और बाद के लॉन्च के दौरान परिणाम काफी भिन्न होंगे क्योंकि कैश और पतली मात्रा भर जाती है, और यह इस पर भी निर्भर करता है कि सिस्टम अंतिम लॉन्च के दौरान भरे गए कैश को सिंक्रनाइज़ करने में कामयाब रहा या नहीं।

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

इन दोनों सुविधाओं का उपयोग आपके लाभ के लिए किया जा सकता है।

"सुसंगत" स्नैपशॉट को कैश करें

कैश क्षति/हानि के मामले में डेटा हानि के जोखिम को कम करने के लिए, लेखक इस मामले में उनकी अखंडता की गारंटी के लिए घूर्णन स्नैपशॉट की प्रथा शुरू करने का प्रस्ताव करता है।

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

निम्नलिखित स्नैपशॉट रोटेशन चक्र कैश हानि के मामले में स्नैपशॉट के अंदर डेटा की अखंडता की गारंटी देता है:

<name> नाम वाले प्रत्येक पतले वॉल्यूम के लिए, <name>.cached नाम से एक स्नैपशॉट बनाएं
आइए माइग्रेशन सीमा को उचित उच्च मान पर सेट करें: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
लूप में हम कैश में गंदे ब्लॉकों की संख्या की जाँच करते हैं: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' जब तक हमें शून्य न मिल जाए. यदि शून्य बहुत लंबे समय से गायब है, तो इसे अस्थायी रूप से कैश को राइटथ्रू मोड में स्विच करके बनाया जा सकता है। हालाँकि, हमारे SATA और NVMe SSD सरणियों की गति विशेषताओं, साथ ही उनके TBW संसाधन को ध्यान में रखते हुए, आप या तो कैश मोड को बदले बिना तुरंत क्षण को पकड़ने में सक्षम होंगे, या आपका हार्डवेयर इसके संपूर्ण संसाधन को पूरी तरह से खा जाएगा। कुछ दिन। संसाधन सीमाओं के कारण, सिस्टम, सिद्धांत रूप में, हर समय 100% राइट लोड के अंतर्गत रहने में असमर्थ है। 100% राइट लोड के तहत हमारे एनवीएमई एसएसडी संसाधन को पूरी तरह से समाप्त कर देंगे 3-4 दिन. SATA SSDs केवल दोगुने समय तक ही चलेंगे। इसलिए, हम मान लेंगे कि अधिकांश भार पढ़ने में चला जाता है, और हमारे पास लेखन के लिए औसतन कम भार के साथ संयुक्त रूप से अत्यधिक उच्च गतिविधि के अपेक्षाकृत अल्पकालिक विस्फोट हैं।
जैसे ही हमने शून्य पकड़ा (या बनाया), हम <name>.cached का नाम बदलकर <name>.committed कर देते हैं। पुराना <name>.committed हटा दिया गया है।
वैकल्पिक रूप से, यदि कैश 100% भरा हुआ है, तो इसे एक स्क्रिप्ट द्वारा फिर से बनाया जा सकता है, इस प्रकार इसे साफ़ किया जा सकता है। आधे-खाली कैश के साथ, लिखते समय सिस्टम बहुत तेजी से काम करता है।
माइग्रेशन सीमा को शून्य पर सेट करें: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata यह अस्थायी रूप से कैश को मुख्य मीडिया से सिंक्रनाइज़ होने से रोक देगा।
हम कैश में बहुत सारे परिवर्तन जमा होने तक प्रतीक्षा करते हैं #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' या टाइमर बंद हो जाएगा.
हम फिर से दोहराते हैं.

प्रवासन सीमा को लेकर कठिनाइयाँ क्यों...?बात यह है कि वास्तविक व्यवहार में, एक "यादृच्छिक" रिकॉर्डिंग वास्तव में पूरी तरह से यादृच्छिक नहीं होती है। यदि हमने 4 किलोबाइट आकार के किसी सेक्टर के लिए कुछ लिखा है, तो इस बात की बहुत अधिक संभावना है कि अगले कुछ मिनटों में उसी या पड़ोसी (+-32K) सेक्टरों में से किसी एक सेक्टर के लिए एक रिकॉर्ड बनाया जाएगा।

माइग्रेशन थ्रेशोल्ड को शून्य पर सेट करके, हम SATA SSD पर राइट सिंक्रोनाइज़ेशन को स्थगित कर देते हैं और कैश में एक 64K ब्लॉक में कई बदलाव एकत्र करते हैं। यह SATA SSD के संसाधन को महत्वपूर्ण रूप से बचाता है।

कोड कहां है..?दुर्भाग्य से, लेखक खुद को बैश स्क्रिप्ट के विकास में अपर्याप्त रूप से सक्षम मानता है क्योंकि वह 100% स्व-सिखाया गया है और "Google"-संचालित विकास का अभ्यास करता है, इसलिए उसका मानना है कि उसके हाथों से निकलने वाला भयानक कोड किसी के द्वारा उपयोग नहीं किया जाना चाहिए अन्यथा।

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

इस तरह की एक सरल स्नैपशॉट रोटेशन योजना हमें न केवल SATA SSD पर एक स्नैपशॉट को पूरी तरह से सिंक्रनाइज़ करने की अनुमति देगी, बल्कि thin_delta उपयोगिता का उपयोग करके हमें यह पता लगाने की भी अनुमति देगी कि इसके निर्माण के बाद कौन से ब्लॉक बदले गए थे, और इस प्रकार क्षति को स्थानीयकृत किया जा सकेगा। मुख्य वॉल्यूम, पुनर्प्राप्ति को बहुत सरल बनाते हैं।

libvirt/KVM में ट्रिम/डिस्कार्ड करें

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

यह वर्चुअल डिस्क पर TRIM/DISCARD समर्थन का अनुकरण करके किया जाता है। ऐसा करने के लिए, आपको नियंत्रक प्रकार को virtio-scsi में बदलना होगा और xml को संपादित करना होगा।

#virsh edit vmname <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/> <source dev='/dev/images/vmname'/> <backingStore/> <target dev='sda' bus='scsi'/> <alias name='scsi0-0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk>

<controller type='scsi' index='0' model='virtio-scsi'> <alias name='scsi0'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </controller>
अतिथि OSes से ऐसे DISCARD को LVM द्वारा सही ढंग से संसाधित किया जाता है, और ब्लॉक को कैश और थिन पूल दोनों में सही ढंग से मुक्त किया जाता है। हमारे मामले में, यह मुख्य रूप से विलंबित तरीके से होता है, जब अगला स्नैपशॉट हटा दिया जाता है।

बीटीआरएफएस बैकअप

इसके साथ तैयार स्क्रिप्ट का उपयोग करें крайней सावधानी और अपने जोखिम पर. लेखक ने यह कोड स्वयं और विशेष रूप से अपने लिए लिखा है। मुझे यकीन है कि कई अनुभवी लिनक्स उपयोगकर्ताओं के पास समान उपकरण हैं, और किसी और की नकल करने की कोई आवश्यकता नहीं है।

आइए बैकअप डिवाइस पर एक वॉल्यूम बनाएं:

#lvcreate -L 256G --name backup backup

आइए इसे BTRFS में प्रारूपित करें:

#mkfs.btrfs /dev/backup/backup

आइए माउंट पॉइंट बनाएं और फ़ाइल सिस्टम के रूट उप-अनुभागों को माउंट करें:

#mkdir /backup #mkdir /backup/btrfs #mkdir /backup/btrfs/root #mkdir /backup/btrfs/back #ln -s /boot /backup/btrfs # cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2 /dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2 EOF #mount -a #update-initramfs -u #update-grub
आइए बैकअप के लिए निर्देशिकाएँ बनाएँ:

#mkdir /backup/btrfs/back/remote #mkdir /backup/btrfs/back/remote/root #mkdir /backup/btrfs/back/remote/boot
आइए बैकअप स्क्रिप्ट के लिए एक निर्देशिका बनाएं:

#mkdir /root/btrfs-backup

आइए स्क्रिप्ट को कॉपी करें:

बहुत सारे डरावने बैश कोड। अपने जोखिम पर उपयोग करें। लेखक को क्रोधित पत्र न लिखें...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF #!/bin/bash PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"


SCRIPT_FILE="$(realpath $0)"

SCRIPT_DIR="$(dirname $SCRIPT_FILE)"

SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"
LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"

DATE_PREFIX='%Y-%m-%d'

DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'

DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'

BASE_SUFFIX=".@base"

PEND_SUFFIX=".@pend"

SNAP_SUFFIX=".@snap"

MOUNTS="/backup/btrfs/"

BACKUPS="/backup/btrfs/back/remote/"
function terminate ()

{

echo "$1" >&2

exit 1

}
function wait_lock()

{

flock 98

}
function wait_lock_or_terminate()

{

echo "Wating for lock..."

wait_lock || terminate "Failed to get lock. Exiting..."

echo "Got lock..."

}
function suffix()

{

FORMATTED_DATE=$(date +"$DATE_FORMAT")

echo "$SNAP_SUFFIX.$FORMATTED_DATE"

}
function filter()

{

FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")

echo "$SNAP_SUFFIX.$FORMATTED_DATE"

}
function backup()

{

SOURCE_PATH="$MOUNTS$1"

TARGET_PATH="$BACKUPS$1"

SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"

TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"

TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"

SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"

TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"

if [ -d "$SOURCE_BASE_PATH" ]
then

echo "$SOURCE_BASE_PATH found"

else

echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"

btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH

sync

if [ -d "$TARGET_BASE_PATH" ]
then

echo "$TARGET_BASE_PATH found out of sync with source... removing..."

btrfs subvolume delete -c $TARGET_BASE_PATH

sync

fi

fi

if [ -d "$TARGET_BASE_PATH" ]
then

echo "$TARGET_BASE_PATH found"

else

echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"

btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR

sync

fi

if [ -d "$SOURCE_PEND_PATH" ]
then

echo "$SOURCE_PEND_PATH found removing..."

btrfs subvolume delete -c $SOURCE_PEND_PATH

sync

fi

btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH

sync

if [ -d "$TARGET_PEND_PATH" ]
then

echo "$TARGET_PEND_PATH found removing..."

btrfs subvolume delete -c $TARGET_PEND_PATH

sync

fi

echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"

btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR

sync

TARGET_DATE_SUFFIX=$(suffix)

btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"

sync

btrfs subvolume delete -c $SOURCE_BASE_PATH

sync

btrfs subvolume delete -c $TARGET_BASE_PATH

sync

mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH

mv $TARGET_PEND_PATH $TARGET_BASE_PATH

sync

}
function list()

{

LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"

LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"

LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"

find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"

}
function remove()

{

REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"

REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"

btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2

sync

}
function removeall()

{

DATE_OFFSET="$2"

FILTER="$(filter "$DATE_OFFSET")"

while read -r SNAPSHOT ; do

remove "$1" "$SNAPSHOT"

done < <(list "$1" | grep "$FILTER")
}
(

COMMAND="$1"

shift
 case "$COMMAND" in

"--help") 

echo "Help"

;;

"suffix") 

suffix

;;

"filter") 

filter "$1"

;;

"backup") 

wait_lock_or_terminate

backup "$1"

;;

"list") 

list "$1"

;;

"remove") 

wait_lock_or_terminate

remove "$1" "$2"

;;

"removeall") 

wait_lock_or_terminate

removeall "$1" "$2"

;;

*)

echo "None.."

;;

esac

) 98>$LOCK_FILE

EOF

यह करता भी क्या है..?इसमें बीटीआरएफएस स्नैपशॉट बनाने और बीटीआरएफएस सेंड/रिसीव का उपयोग करके उन्हें दूसरे एफएस में कॉपी करने के लिए सरल कमांड का एक सेट शामिल है।

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

एक और स्क्रिप्ट जिसे हम क्रॉन में डालेंगे:

कुछ और बैश कोड#cat >/root/btrfs-backup/cron-daily.sh << EOF #!/bin/bash PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"


SCRIPT_FILE="$(realpath $0)"

SCRIPT_DIR="$(dirname $SCRIPT_FILE)"

SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh" RETENTION="-60 day" $BACKUP_SCRIPT backup root/@ $BACKUP_SCRIPT removeall root/@ "$RETENTION" $BACKUP_SCRIPT backup root/@home $BACKUP_SCRIPT removeall root/@home "$RETENTION" $BACKUP_SCRIPT backup boot/ $BACKUP_SCRIPT removeall boot/ "$RETENTION" EOF

इससे क्या होता है..?बैकअप एफएस पर सूचीबद्ध बीटीआरएफएस वॉल्यूम के वृद्धिशील स्नैपशॉट बनाता है और सिंक्रनाइज़ करता है। इसके बाद यह 60 दिन पहले बनाई गई सभी तस्वीरें डिलीट कर देता है। लॉन्च के बाद, सूचीबद्ध वॉल्यूम के दिनांकित स्नैपशॉट /बैकअप/बीटीआरएफएस/बैक/रिमोट/ उपनिर्देशिकाओं में दिखाई देंगे।

आइए कोड निष्पादन अधिकार दें:

#chmod +x /root/btrfs-backup/cron-daily.sh #chmod +x /root/btrfs-backup/btrfs-backup.sh
आइए इसे जांचें और इसे क्रॉन में डालें:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup #cat /var/log/syslog | grep btrfs-backup #crontab -e 0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup

LVM पतला बैकअप

आइए बैकअप डिवाइस पर एक पतला पूल बनाएं:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

आइए ddrescue इंस्टॉल करें, क्योंकि... स्क्रिप्ट इस टूल का उपयोग करेंगी:

#apt-get install gddrescue

आइए स्क्रिप्ट के लिए एक निर्देशिका बनाएं:

#mkdir /root/lvm-thin-backup

आइए स्क्रिप्ट कॉपी करें:

अंदर बहुत सारा हंगामा...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF #!/bin/bash PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"


SCRIPT_FILE="$(realpath $0)"

SCRIPT_DIR="$(dirname $SCRIPT_FILE)"

SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"
LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"

DATE_PREFIX='%Y-%m-%d'

DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'

DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'

BASE_SUFFIX=".base"

PEND_SUFFIX=".pend"

SNAP_SUFFIX=".snap"

BACKUPS="backup"

BACKUPS_POOL="thin-pool"
export LVM_SUPPRESS_FD_WARNINGS=1
function terminate ()

{

echo "$1" >&2

exit 1

}
function wait_lock()

{

flock 98

}
function wait_lock_or_terminate()

{

echo "Wating for lock..."

wait_lock || terminate "Failed to get lock. Exiting..."

echo "Got lock..."

}
function suffix()

{

FORMATTED_DATE=$(date +"$DATE_FORMAT")

echo "$SNAP_SUFFIX.$FORMATTED_DATE"

}
function filter()

{

FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")

echo "$SNAP_SUFFIX.$FORMATTED_DATE"

}
function read_thin_id {

lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'

}
function read_pool_lv {

lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'

}
function read_lv_dm_path {

lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'

}
function read_lv_active {

lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'

}
function read_lv_chunk_size {

lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'

}
function read_lv_size {

lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'

}
function activate_volume {

lvchange -ay -Ky "$1/$2"

}
function deactivate_volume {

lvchange -an "$1/$2"

}
function read_thin_metadata_snap {

dmsetup status "$1" | awk '{print $7}'

}
function thindiff()

{

DIFF_VG="$1"

DIFF_SOURCE="$2"

DIFF_TARGET="$3"

DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)

DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)
if [ "$DIFF_SOURCE_POOL" == "" ]
then

(>&2 echo "Source LV is not thin.")

exit 1

fi
if [ "$DIFF_TARGET_POOL" == "" ]
then

(>&2 echo "Target LV is not thin.")

exit 1

fi
if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ]
then

(>&2 echo "Source and target LVs belong to different thin pools.")

exit 1

fi
DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)

DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)

DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)

DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"

DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta

DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)
if [ "$DIFF_POOL_METADATA_SNAP" != "-" ]
then

(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")

sleep 5

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

fi
dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap

DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)
if [ "$DIFF_POOL_METADATA_SNAP" == "-" ]
then

(>&2 echo "Failed to create thin pool metadata snapshot.")

exit 1

fi
#We keep output in variable because metadata snapshot need to be released early.

DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'
}
function thinsync()

{

SYNC_VG="$1"

SYNC_PEND="$2"

SYNC_BASE="$3"

SYNC_TARGET="$4"

SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)

SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)

SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)
activate_volume $SYNC_VG $SYNC_PEND
while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do

SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))

SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))

if [ "$SYNC_ACTION" == "copy" ]
then

ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"

fi
if [ "$SYNC_ACTION" == "discard" ]
then

blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"

fi

done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")

}
function discard_volume()

{

DISCARD_VG="$1"

DISCARD_LV="$2"

DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")

if [ "$DISCARD_LV_PATH" != "" ]
then

echo "$DISCARD_LV_PATH found"

else

echo "$DISCARD_LV not found in $DISCARD_VG"

exit 1

fi

DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)

DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")

lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1

lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1

}
function backup()

{

SOURCE_VG="$1"

SOURCE_LV="$2"

TARGET_VG="$BACKUPS"

TARGET_LV="$SOURCE_VG-$SOURCE_LV"

SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"

TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"

SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"

TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"

SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")

TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")

TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
if [ "$SOURCE_BASE_LV_PATH" != "" ]
then

echo "$SOURCE_BASE_LV_PATH found"

else

echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"

lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1

SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."

SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)

SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

sync

if [ "$TARGET_BASE_LV_PATH" != "" ]
then

echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."

lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1

TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")

sync

fi

fi

SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$TARGET_BASE_LV_PATH" != "" ]
then

echo "$TARGET_BASE_LV_PATH found"

else

echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."

lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1

echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"

activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)

SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)

TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)

TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")

echo "Discarding target at $TARGET_BASE_LV_PATH"

discard_volume "$TARGET_VG" "$TARGET_BASE_LV"

sync

fi

if [ "$SOURCE_PEND_LV_PATH" != "" ]
then

echo "$SOURCE_PEND_LV_PATH found removing..."

lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1

sync

fi

lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1

SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")

sync

if [ "$TARGET_PEND_LV_PATH" != "" ]
then

echo "$TARGET_PEND_LV_PATH found removing..."

lvremove -y --quiet $TARGET_PEND_LV_PATH

sync

fi

lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1

TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")

lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"

activate_volume "$TARGET_VG" "$TARGET_PEND_LV"

echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"

thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1

sync
TARGET_DATE_SUFFIX=$(suffix)

lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1

sync

lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1

sync

lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1

sync

lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1

lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1

sync

deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"

deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

}
function verify()

{

SOURCE_VG="$1"

SOURCE_LV="$2"

TARGET_VG="$BACKUPS"

TARGET_LV="$SOURCE_VG-$SOURCE_LV"

SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"

TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"

TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")

SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$SOURCE_BASE_LV_PATH" != "" ]
then

echo "$SOURCE_BASE_LV_PATH found"

else

echo "$SOURCE_BASE_LV_PATH not found"

exit 1

fi

if [ "$TARGET_BASE_LV_PATH" != "" ]
then

echo "$TARGET_BASE_LV_PATH found"

else

echo "$TARGET_BASE_LV_PATH not found"

exit 1

fi

activate_volume "$TARGET_VG" "$TARGET_BASE_LV"

activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"

cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"

echo Done...

deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"

deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

}
function resync()

{

SOURCE_VG="$1"

SOURCE_LV="$2"

TARGET_VG="$BACKUPS"

TARGET_LV="$SOURCE_VG-$SOURCE_LV"

SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"

TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"

TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")

SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$SOURCE_BASE_LV_PATH" != "" ]
then

echo "$SOURCE_BASE_LV_PATH found"

else

echo "$SOURCE_BASE_LV_PATH not found"

exit 1

fi

if [ "$TARGET_BASE_LV_PATH" != "" ]
then

echo "$TARGET_BASE_LV_PATH found"

else

echo "$TARGET_BASE_LV_PATH not found"

exit 1

fi

activate_volume "$TARGET_VG" "$TARGET_BASE_LV"

activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)

SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"
CMP_OFFSET=0

while [[ "$CMP_OFFSET" != "" ]] ; do

CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )

if [[ "$CMP_MISMATCH" != "" ]] ; then

CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))

SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))

SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))

echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"

ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"

else

CMP_OFFSET=""

fi

done

echo Done...

deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"

deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"

}
function list()

{

LIST_SOURCE_VG="$1"

LIST_SOURCE_LV="$2"

LIST_TARGET_VG="$BACKUPS"

LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"

LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"

lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"

}
function remove()

{

REMOVE_TARGET_VG="$BACKUPS"

REMOVE_TARGET_LV="$1"

lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"

sync

}
function removeall()

{

DATE_OFFSET="$3"

FILTER="$(filter "$DATE_OFFSET")"

while read -r SNAPSHOT ; do

remove "$SNAPSHOT"

done < <(list "$1" "$2" | grep "$FILTER")
}
(

COMMAND="$1"

shift
 case "$COMMAND" in

"--help") 

echo "Help"

;;

"suffix") 

suffix

;;

"filter") 

filter "$1"

;;

"backup") 

wait_lock_or_terminate

backup "$1" "$2"

;;

"list") 

list "$1" "$2"

;;

"thindiff") 

thindiff "$1" "$2" "$3"

;;

"thinsync") 

thinsync "$1" "$2" "$3" "$4"

;;

"verify") 

wait_lock_or_terminate

verify "$1" "$2"

;;

"resync") 

wait_lock_or_terminate

resync "$1" "$2"

;;

"remove") 

wait_lock_or_terminate

remove "$1"

;;

"removeall") 

wait_lock_or_terminate

removeall "$1" "$2" "$3"

;;

*)

echo "None.."

;;

esac

) 98>$LOCK_FILE

EOF

इससे क्या होता है...?इसमें पतले स्नैपशॉट में हेरफेर करने और thin_delta के माध्यम से प्राप्त दो पतले स्नैपशॉट के बीच अंतर को ddrescue और blkdiscard का उपयोग करके किसी अन्य ब्लॉक डिवाइस में सिंक्रनाइज़ करने के लिए कमांड का एक सेट शामिल है।

एक और स्क्रिप्ट जिसे हम क्रॉन में डालेंगे:

थोड़ा और प्रहार#cat >/root/lvm-thin-backup/cron-daily.sh << EOF #!/bin/bash PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"


SCRIPT_FILE="$(realpath $0)"

SCRIPT_DIR="$(dirname $SCRIPT_FILE)"

SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"
BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"

RETENTION="-60 days"
$BACKUP_SCRIPT backup images linux-dev

$BACKUP_SCRIPT backup images win8

$BACKUP_SCRIPT backup images win8-data

#etc
$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"

$BACKUP_SCRIPT removeall images win8 "$RETENTION"

$BACKUP_SCRIPT removeall images win8-data "$RETENTION"

#etc

EOF

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

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

आइए अधिकार दें:

#chmod +x /root/lvm-thin-backup/cron-daily.sh #chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

आइए इसे जांचें और इसे क्रॉन में डालें:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup #cat /var/log/syslog | grep lvm-thin-backup #crontab -e 0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
पहला लॉन्च लंबा होगा, क्योंकि... उपयोग किए गए सभी स्थान की प्रतिलिपि बनाकर पतले वॉल्यूम को पूरी तरह से सिंक्रनाइज़ किया जाएगा। एलवीएम पतले मेटाडेटा के लिए धन्यवाद, हम जानते हैं कि कौन से ब्लॉक वास्तव में उपयोग में हैं, इसलिए केवल वास्तव में उपयोग किए गए पतले वॉल्यूम ब्लॉक की प्रतिलिपि बनाई जाएगी।

एलवीएम पतले मेटाडेटा के माध्यम से ट्रैकिंग में बदलाव के कारण बाद के रन डेटा को क्रमिक रूप से कॉपी कर देंगे।

देखते है क्या हुआ:

#time /root/btrfs-backup/cron-daily.sh real 0m2,967s user 0m0,225s sys 0m0,353s


#time /root/lvm-thin-backup/cron-daily.sh

real 1m2,710s

user 0m12,721s

sys 0m6,671s
#ls -al /backup/btrfs/back/remote/*

/backup/btrfs/back/remote/boot:

total 0

drwxr-xr-x 1 root root 1260 мар 26 09:11 .

drwxr-xr-x 1 root root 16 мар 6 09:30 ..

drwxr-xr-x 1 root root 322 мар 26 02:00 .@base

drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]

drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]

...

/backup/btrfs/back/remote/root:

total 0

drwxr-xr-x 1 root root 2820 мар 26 09:11 .

drwxr-xr-x 1 root root 16 мар 6 09:30 ..

drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base

drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base

drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]

drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]

...

drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]

drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]

...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup LV LSize linux-dev 128,00g linux-dev.base 128,00g thin-pool 1,38t win8 128,00g win8-data 2,00t win8-data.base 2,00t win8.base 128,00g LV LSize backup 256,00g images-linux-dev.base 128,00g images-linux-dev.snap.2020-03-08-10-09-11 128,00g images-linux-dev.snap.2020-03-08-10-09-25 128,00g ... images-win8-data.base 2,00t images-win8-data.snap.2020-03-16-14-11-55 2,00t images-win8-data.snap.2020-03-16-14-19-50 2,00t ... images-win8.base 128,00g images-win8.snap.2020-03-17-04-51-46 128,00g images-win8.snap.2020-03-18-03-02-49 128,00g ... thin-pool <2,09t

इसका घोंसला बनाने वाली गुड़िया से क्या लेना-देना है?

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

पुनश्च

अगले लेख में, हम होम डेस्कटॉप, होम इंटरनेट और पी2पी नेटवर्क का उपयोग करके कई महाद्वीपों पर अतिरेक के साथ भू-वितरित स्टोरेज/वीएम क्लस्टर बनाने के लिए आधार के रूप में कई समान मोबाइल स्टोरेज सिस्टम/केवीएम का उपयोग करने का प्रयास करेंगे।

स्रोत: www.habr.com

एलवीएम और मैत्रियोश्का में क्या समानता है?

Заявление

लोहा

उपलब्ध थे:

इसके अतिरिक्त जोड़ा गया:

मुलायम

स्थापना की तैयारी

डिस्क लेआउट

एनवीएमई एसएसडी

SATA HDD

सैटा एसएसडी

सारणियाँ बनाना

एनवीएमई एसएसडी

सैटा एसएसडी

SATA HDD

एनवीएमई RAID पर एलवीएम

ओएस स्थापना

SATA SSD पर LVM

SATA HDD पर LVM

LVM कैश सेट करना

एलवीएम पतला सेट करना

"सुसंगत" स्नैपशॉट को कैश करें

libvirt/KVM में ट्रिम/डिस्कार्ड करें

बीटीआरएफएस बैकअप

LVM पतला बैकअप

देखते है क्या हुआ:

इसका घोंसला बनाने वाली गुड़िया से क्या लेना-देना है?

पुनश्च

एक टिप्पणी जोड़ें उत्तर रद्द