🥇Какво общо имат LVM и матрьошките?

Добър ден.
Искам да споделя опит с общността относно изграждането на система за съхранение на данни за KVM с md RAID + LVM.

В програмата ще бъде:

Сглобяване на md RAID 1 от NVMe SSD.
Сглобяване на md RAID 6 от SATA SSD и обикновени дискове.
Характеристики на TRIM/DISCARD в SSD RAID 1/6.
Създаване на зареждащ md RAID 1/6 масив на общ набор от дискове.
Инсталиране на система на NVMe RAID 1 при липса на поддръжка на NVMe в BIOS.
Използване на LVM cache и LVM thin.
Използване на BTRFS снимки и send/receive за резервно копиране.
Използване на LVM thin снимки и thin_delta за резервно копиране в стил BTRFS.

Ако вдъхновява, моля, под кат.

Декларация

Авторът не носи никаква отговорност за последствията от използването или неизползването на материали/примери/код/съвети/данни от тази статия. Четейки или по какъвто и да е начин използвайки този материал, поемате отговорността за всички последствия от тези действия. Възможните последствия включват:

Изпържени до хрупкавост NVMe SSD.
Напълно изчерпан ресурс на запис и отказ на SSD устройства.
Пълна загуба на всички данни на всички устройства, включително резервни копия.
Невалидно компютърно оборудване.
Изразходвано време, нерви и средства.
Всички други последствия, които не са изброени по-горе.

Желязо

Имаше налично:

Основна платка от някъде през 2013 г. на чипсет Z87 с Intel Core i7 / Haswell.

Процесор с 4 ядра, 8 потока
32 Гигабайта DDR3 оперативна памет
1 x 16 или 2 x 8 PCIe 3.0
1 x 4 + 1 x 1 PCIe 2.0
6 x 6 GBps SATA 3 порта

SAS адаптер LSI SAS9211-8I, флашнат в IT / HBA режим. Фърмуерът с поддръжка на RAID е заменен с HBA фърмуер заради:

Да може по всяко време да се изхвърли този адаптер и да бъде заменен с произволен друг.
TRIM/Discard работеше нормално на дисковете, тъй като в RAID фърмуера тези команди не се поддържат изцяло, а HBA в крайна сметка няма значение какви команди се предават по шина.

Хардуерни дискове — 8 броя HGST Travelstar 7K1000 с капацитет 1 TB в 2.5 форм-фактор, както за лаптопи. Тези дискове преди бяха в RAID 6 масив. В новата система също ще намерят приложение. За съхраняване на локални резервни копия.

Допълнително бяха добавени:

6 броя SATA SSD модел Samsung 860 QVO 2TB. Изискваше се голям капацитет от тези SSD, наличие на SLC кеш, желателна надеждност, и разумна цена. Поддръжката на discard/zero беше задължителна, която се проверява с ред в dmesg:

ядро: ata1.00: Активиране на discard_zeroes_data

2 броя NVMe SSD модели Samsung SSD 970 EVO 500GB.

За тези SSD е важна скоростта на произволно четене/запис и ресурсът да отговори на вашите нужди. Радиатор е задължителен. Напълно задължителен. В противен случай, — ще ги запечете до хрупкава коричка при първата синхронизация на RAID.

Адаптер StarTech PEX8M2E2 за 2 x NVMe SSD с монтаж в PCIe 3.0 8x слот. Това е, отново, просто HBA, но за NVMe. Различава се от евтините адаптери с отсъствието на изискване за поддръжка на PCIe bifurcation от дънната платка заради вграден превключвател PCIe. Ще работи дори в най-старата система, където има PCIe, дори ако това е x1 PCIe 1.0 слот. Разбира се, със съответната скорост. Няма RAID там. Няма вграден BIOS на борда. Така че, вашата система магически няма да научи да се зарежда от NVMe, камо ли да прави NVMe RAID благодарение на това устройство.

Този компонент беше обусловен изключително от наличието на само един свободен 8x PCIe 3.0 в системата, и, при наличието на 2 свободни слота, лесно се заменя с два евтини PEX4M2E1 или аналози, които могат да се купят навсякъде на цена от 600 рубли.

Отказът от всякакви хардуерни или вградени в чипсет/Bios RAID-и беше направен осъзнато с целта да можем напълно да заменим цялата система, с изключение на самите SSD/HDD, като запазим всички данни. В идеалния случай, за да можем да запазим дори инсталираната операционна система при преместването на съвсем ново/друго желязо. Основното е да има SATA и PCIe портове. Това е като live CD или бутуема флашка, само че много бърза и малко обемна.

ХуморЗнаете как е, — понякога е нужно спешно да вземете цялото хранилище на износ. И не искате да губите данни. Заради това всички споменати носители удобно се подреждат по шини в отсек 5.25 от стандартен корпус.

И, разбира се, за експерименти с различни методи на SSD кеширане в Linux.

Хардуерните рейдове са скучни. Включваш. Или работи, или не. А с mdadm винаги има варианти.

Софт

По-рано на хардуера беше инсталиран Debian 8 Jessie, който е близък до EOL. Беше събран RAID 6 от по-горе споменатите HDD в комбинация с LVM. На него работеха виртуални машини в kvm/libvirt.

Тъй като авторът има подходящ опит в създаването на портативни зареждащи SATA/NVMe флашки и не искаме да нарушаваме познатия apt шаблон, за целева система бяха избрани Ubuntu 18.04, която вече е достатъчно стабилна, но все още има 3 години поддръжка в перспектива.

В споменатата система са налични всички необходими драйвери за хардуер от кутията. Никакъв външен софтуер и драйвери няма да ни трябват.

Подготовка за инсталация

За инсталацията на системата ни е необходимо изображение на Ubuntu Desktop. Серверната система притежава ядрен инсталатор, който проявява излишна нежелана самостоятелност, задължително вмъквайки UEFI системен дял на един от дисковете, разваляйки цялата красота. Съответно, инсталацията може да се извърши само в UEFI режим. Няма предложения.

Това не ни удовлетворява.

Защо?За съжаление, UEFI зареждането е изключително слабо съвместимо с софтуерен RAID, тъй като резервни опции за UEFI ESP дяла не се предлагат. В мрежата има рецепти, които предлагат да се разположи ESP дял на флашка в USB порта, но това е точка на отказ. Има рецепти с използване на софтуерен mdadm RAID 1 с метаданни версия 0.9, които не пречат на UEFI BIOS да вижда този дял, но това издържа до щастливия момент, когато BIOS или друга ОС на хардуера запише нещо в ESP, забравяйки да синхронизира на другите огледала.

Освен това, UEFI зареждането зависи от NVRAM, която не ще премине заедно с дисковете в новата система, тъй като е част от дънната платка.

Така че, няма да изобретяваме нов велосипед. Вече имаме готов, проверен с години дедовски велосипед, известен днес като Legacy/BIOS boot, носещ гордото име CSM на UEFI-съвместими системи. Просто ще го извадим от рафта, смажем, наддуем колелата и избършем с влажен парцал.

Desktop версията на Ubuntu също не може да се инсталира нормално с Legacy зареждача, но тук, както се казва, поне има опции.

Така че, събираме хардуера и зареждаме системата от зареждащата флашка Ubuntu Live. Ще е необходимо да изтеглим пакети, така че настройваме мрежата, каквато и да е работеща. Ако не работи, необходимите пакети могат да бъдат предварително качени на флашката.

Влизаме в Desktop средата, стартираме емулятор на терминал и, да започваме:

#sudo bash

Как…?Горният ред е каноничен тригер за холивари относно sudo. С бопо-големи възможности идва и по-голямаоотговорност. Въпросът е дали можете да я поемете. Много хора смятат, че използването на sudo по този начин е поне неразумно. Въпреки това:

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

Защо не ZFS…?Когато инсталираме софтуер на компютъра си, по същество наемаме железата си на разработчиците на този софтуер.
Когато се доверяваме на този софтуер за съхранение на нашите данни, поемаме кредит, равен на стойността за възстановяване на тези данни, който един ден ще трябва да платим.

От тази гледна точка ZFS е Ферари, а mdadm+lvm повече наподобява велосипед.

Субективно авторът предпочита да наема на неизвестни лица взетия на кредит велосипед, вместо Ферари. И цената не е висока. Няма нужда от права. Правилата за движение са по-прости. Паркингът е безплатен. Проходимостта е по-добра. Винаги можете да добавите крака на велосипеда, а и можете да го поправите сами.

Защо тогава BTRFS…?За да заредим операционната система, ще ни е нужна файлова система, поддържана от Legacy/BIOS GRUB от самото начало и едновременно с това, поддържаща моментни снимки на живо. Ще я използваме за /boot дяла. Освен това авторът предпочита да използва тази файлова система за / (корен), без да забравя да отбележи, че за всеки друг софтуер могат да се създадат отделни дялове на LVM и да се монтират в нужните директории.

Нито изображения виртуални машини, нито бази данни няма да съхраняваме на тази файлова система.
Тази файлова система ще се използва само за създаване на мигновени снимки на системата без нейното изключване, последвано от прехвърляне на тези снимки на резервен диск с помощта на send/receive.

Освен това, авторът изобщо предпочита да държи минимум софтуер директно на железото и да изпълнява целия останал софтуер във виртуални машини, използвайки такива неща като пренасочване на GPU и PCI-USB хост контролери в KVM чрез IOMMU.

На железото остават само — съхранение на данни, виртуализация и резервно копие.

Ако повече доверявате ZFS, то в принципе те са взаимозаменяеми за указаното приложение.

Въпреки това, авторът съзнателно игнорира вградените функции за огледално копиране/ RAID и излишно свързване, които съществуват в ZFS, BRTFS и LVM.

Като допълнителен аргумент, BTRFS има свойството да превръща случайно записаните данни в последователни, което е много положително за скоростта на синхронизация на снимки / резервни копия на HDD.

Нека отново сканираме всички устройства:

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

Нека се огледаме:

#lsscsi && nvme list [0:0:0:0] диск ATA Samsung SSD 860 2B6Q /dev/sda [1:0:0:0] диск ATA Samsung SSD 860 2B6Q /dev/sdb [2:0:0:0] диск ATA Samsung SSD 860 2B6Q /dev/sdc [3:0:0:0] диск ATA Samsung SSD 860 2B6Q /dev/sdd [4:0:0:0] диск ATA Samsung SSD 860 2B6Q /dev/sde [5:0:0:0] диск ATA Samsung SSD 860 2B6Q /dev/sdf [6:0:0:0] диск ATA HGST HTS721010A9 A3J0 /dev/sdg [6:0:1:0] диск ATA HGST HTS721010A9 A3J0 /dev/sdh [6:0:2:0] диск ATA HGST HTS721010A9 A3J0 /dev/sdi [6:0:3:0] диск ATA HGST HTS721010A9 A3B0 /dev/sdj [6:0:4:0] диск ATA HGST HTS721010A9 A3B0 /dev/sdk [6:0:5:0] диск ATA HGST HTS721010A9 A3B0 /dev/sdl [6:0:6:0] диск ATA HGST HTS721010A9 A3J0 /dev/sdm [6:0:7:0] диск ATA HGST HTS721010A9 A3J0 /dev/sdn Възел SN Модел Име на пространството Използване Формат Версия на FW ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- -------- /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

Разпределение на „дисковете“

NVMe SSD

Тук няма да правим разпределение. Все пак нашият BIOS не разпознава тези устройства. Така че те просто ще отидат в софтуерния RAID. Дори няма да създаваме дялове. Ако искате по „канона“ или „принципно“ — създайте един голям дял, както при HDD.

SATA HDD

Тук не трябва да изобретяваме колелото. Ще създадем един дял за всички. Дялът ще бъде създаден, защото BIOS разпознава тези дискове и дори може да опита да зареди от тях. По-късно дори ще инсталираме GRUB на тези дискове, за да може системата да успее.

#cat >hdd.part << EOF етикет: дялове ид-етикет: 0x00000000 устройство: /dev/sdg единица: сектори

/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

SATA SSD

Тук имаме най-интересното.

На първо място, устройствата са с размер 2 TB. Това е в рамките на допустимото за MBR, което ще използваме. При необходимост може да се замени с GPT. GPT дисковете имат слой на съвместимост, който позволява на MBR-съвместими системи да виждат първите 4 дяла, ако те са разположени в пределите на първите 2 терабайта. Важно е само, зареждащият дял и дялът bios_grub на тези дискове да бъдат в началото. Това позволява дори зареждане по Legacy/BIOS от GPT дискове.

Но, това не е нашият случай.

Тук ще създадем два дяла. Първият ще бъде с размер 1 GB и ще се използва за RAID 1 /boot.

Вторият ще се използва за RAID 6 и ще заема всичкото останало свободно пространство, с изключение на малка неразпределена област в края на устройството.

Какво е тази неразпределена област?Според източници в интернет, нашите SATA SSD имат динамично разширяем SLC кеш с размер от 6 до 78 гигабайта. 6 гигабайта получаваме „безплатно“ заради разликата между „гигабайти“ и „гибибайти“ в техническата документация на устройството. Останалите 72 гигабайта се предоставят благодарение на неизползваното пространство.

Тук е важно да се отбележи, че кешът ни е SLC, а мястото се използва в режим 4 bit MLC. Което за нас ефективно означава, че за всеки 4 гигабайта свободно пространство ще получим само 1 гигабайт SLC кеш.

Умножаваме 72 гигабайта по 4 и получаваме 288 гигабайта. Това е свободното пространство, което няма да разпределяме, за да позволим на устройствата да използват на пълно SLC кеша.

По този начин, ние ще получим ефективно до 312 гигабайта SLC кеш, общо от шестте устройства. От всички устройства, 2 ще бъдат използвани в RAID за излишък.

Такова количество кеш ще ни позволи рядко в реалната практика да срещаме ситуация, в която записът не влиза в кеша. Това изключително добре компенсира най-печалния недостатък на QLC паметта - изключително ниската скорост на запис, когато данните се записват извън кеша. Ако вашите натоварвания не съответстват на това, то препоръчвам да се замислите сериозно колко дълго ще служат вашите SSD под такова натоварване, в контекста на TBW от спецификациите.

#cat >ssd.part << EOF етикет: дялове ид-етикет: 0x00000000 устройство: /dev/sda единица: сектори

/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

NVMe SSD

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

Защо -assume-clean…?За да не инициализираме масивите. За двата нива RAID 1 и 6, това е допустимо. Всичко може да работи и без инициализация, ако е нов масив. Освен това, инициализацията на SSD масив при създаване е напълно безсмислена за изразходване на ресурса TBW. Използваме TRIM/DISCARD, където е възможно, на създадените SSD масиви, за да ги 'инициализираме'.

При SSD RAID 1 DISCARD е поддържан от самото начало.

При SSD RAID 6, DISCARD трябва да бъде включен в параметрите на ядрения модул.

Това трябва да се направи само ако всичките SSD, използвани в масивите на нива 4/5/6 в тази система, имат работеща поддръжка на discard_zeroes_data. Понякога срещаме странни устройства, които съобщават на ядрото за поддръжка на тази функция, но всъщност не я имат или функцията работи не винаги. В момента поддръжката е практически навсякъде, но стари устройства и грешни фърмуери все пак се срещат. Поради тази причина, поддръжката на DISCARD по подразбиране е изключена за RAID 6.

Внимание, следната команда ще унищожи всички данни на NVMe устройствата, 'инициализирайки' масива 'с нули'.

#blkdiscard /dev/md0

Ако нещо се обърка, опитайте да зададете стъпка.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#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

Защо такъв голям…?Увеличаването на chunk-size положително влияе на скоростта на случайно четене с блокове до включително chunk-size. Това се дължи на факта, че една операция от съответния размер или по-малко може да бъде напълно изпълнена на едно устройство. Поради това, IOPS от всички устройства се сумира. Според статистиката, 99% от IO не надвишават 512K.

При RAID 6 IOPS на запись винаги меньше или равно IOPS у одного накопителя. В то время как при случайном чтении IOPS может быть больше, чем у одного накопителя в несколько раз, и здесь размер блока имеет ключевое значение.
Автор не видит смысла в попытках оптимизировать параметр, который плох у RAID 6 по умолчанию, и вместо этого улучшает то, в чем RAID 6 показывает себя хорошо.
Плохую случайную запись RAID 6 мы будем компенсировать кэшем на NVMe и приемами с thin-provisioning.

Мы пока не включили DISCARD для RAID 6. Поэтому «инициализировать» этот массив пока не будем. Сделаем это позже, — после установки ОС.

SATA HDD

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

LVM на NVMe RAID

Для скорости мы хотим разместить корневую файловую систему на NVMe RAID 1, который находится по адресу /dev/md0.
Тем не менее, этот быстрый массив нам еще понадобится для других нужд, таких как swap, метаданные и кэш LVM-cache, а также метаданные LVM-thin, поэтому мы создадим LVM VG на этом массиве.

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

Создадим раздел для корневой файловой системы.

#lvcreate -L 128G --name root root

Создадим раздел для подкачки, равный размеру оперативной памяти.

#lvcreate -L 32G --name swap root

Инсталация на ОС

Итак, у нас есть все необходимое, чтобы установить систему.

Запускаем мастер установки системы из окружения Ubuntu Live. Обычная установка. Только на этапе выбора дисков для установки нужно указать следующее:

/dev/md1, — точка монтирования /boot, ФС — BTRFS
/dev/root/root (a.k.a /dev/mapper/root-root), — точка монтирования / (корень), ФС — BTRFS
/dev/root/swap (a.k.a /dev/mapper/root-swap), — использовать как раздел подкачки
Установить загрузчик на /dev/sda

При выборе BTRFS в качестве корневой файловой системы, установщик автоматически создаст два BTRFS-тома с именами "@" для / (корня) и "@home" для /home.

Запускаем установку…

Установка завершится модальным диалоговым окном с сообщением об ошибке установки загрузчика. К сожалению, выйти из этого диалога стандартными средствами и продолжить установку не получится. Выходим из системы и снова логинимся, попадая в чистый рабочий стол Ubuntu Live. Открываем терминал и снова:

#sudo bash

Создаем окружение chroot, чтобы продолжить установку:

#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
Настроим сеть и hostname в chroot:

#cat /etc/hostname >/mnt/chroot/etc/hostname #cat /etc/hosts >/mnt/chroot/etc/hosts #cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf
Заходим в окружение chroot:

#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, чтобы включить TRIM/DISCARD:

#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 6 на 2020 год. Значение по умолчанию, похоже, не изменялось со времён создания Linux и уже давно не актуально.
Резервируйте минимум IO во время проверок/синхронизаций массивов. Это необходимо, чтобы ваши массивы не застревали в состоянии бесконечной синхронизации под нагрузкой.
Ограничьте максимум IO во время проверок/синхронизаций массивов. Это поможет избежать перегрева ваших накопителей во время синхронизации/проверки SSD RAID. Особенно актуально для NVMe. (Не забывайте про радиаторы? Я не шутил.)
Запретите дискам через APM останавливать вращение шпинделя (HDD) и установите таймаут для сна контроллеров дисков на 7 часов. Можно полностью отключить APM, если ваши диски это поддерживают (-B 255). При значении по умолчанию диски останавливаются через пять секунд. Затем ОС попытается сбросить дисковый кэш, и диски снова раскрутятся, и так по кругу. У дисков ограничено максимальное количество раскручиваний шпинделя. Такой простой цикл по умолчанию может легко убить ваши диски за пару лет. Это касается не всех дисков, но наши «ноутбучные» несомненно пострадают из-за соответствующих настроек по умолчанию, которые делают из RAID кривое подобие mini-MAID.
Установите readahead на вращающихся дисках в 1 мегабайт — два последовательных блока/chunk RAID 6.
Запретите readahead на самих массивах.

Подредактируем /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
Почему так..?Раздел /boot мы будем искать по UUID, так как именование массивов теоретически может измениться.

Остальные разделы мы будем искать по LVM именам в нотации /dev/mapper/vg-lv, так как они достаточно уникально идентифицируют разделы.

Не используем UUID для LVM, так как UUID у LVM томов и их снапшотов может совпадать.Дважды монтируем /dev/mapper/root-root..?Да. Именно так. Это особенность BTRFS. Эту файловую систему можно монтировать несколько раз с разными subvol.

В связи с этой же особенностью, рекомендую никогда не создавать LVM снапшоты активных BTRFS томов. Вы можете получить сюрприз при перезагрузке.

Перегенерируем конфиг 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

Что это было..?Активирахме автоматично разширяване на LVM thin пулове при достигане на 90% заето пространство с 5% от обема.

Увеличихме максималното количество кеш блокове за LVM cache.

Забранихме на LVM да търси LVM томове (PV) на:

устройства, съдържащи LVM cache (cdata)
устройства, кеширани с помощта на LVM cache без кеша (<lv_name>_corig). Все пак, самото кеширано устройство ще бъде сканирано през кеша (просто <lv_name>).
устройства, съдържащи метаданни LVM cache (cmeta)
всички устройства в VG с име images. Тук ще имаме образи на дисковете на виртуални машини и не искаме LVM на хоста да активира томове, принадлежащи на гост OS.
всички устройства в VG с име backup. Тук ще имаме резервни копия на образи на виртуални машини.
всички устройства, чиито имена завършват на «gpv» (guest physical volume)

Активирахме поддръжка на DISCARD при освобождаване на свободно пространство на LVM VG. Бъдете внимателни. Това ще направи изтриването на LV на SSD достатъчно дълго. Особено това се отнася за SSD RAID 6. Въпреки това, по план ще използваме thin provisioning, така че това не би ни попречило.

Актуализирайте образа на initramfs:

#update-initramfs -u -k all

Инсталирайте и конфигурирайте grub:

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

Какви дискове да изберем?Всички, които са sd*. Системата трябва да може да се зареди от всеки работещ SATA диск или SSD.

Защо спираме os-prober..?Заради прекалена самостоятелност и шаловливи ръце.

Не работи коректно, ако един от RAID-овете е в деградирано състояние. Опитва се да търси ОС на дялове, които се използват в виртуални машини, работещи на това оборудване.

Ако ви е нужен, можете да го оставите, но имайте предвид всичко по-горе. Препоръчвам ви да потърсите рецепти за избавяне от шаловливите ръце в мрежата.

Тук приключихме началната инсталация. Време е да се рестартираме в именно инсталирания ОС. Не забравяйте да извадите загрузъчния Live CD/USB.

#exit #reboot

За устройство за зареждане избираме който и да е от SATA SSD.

LVM на SATA SSD

Към този момент вече сме се заредили в новата ОС, настроили сме мрежата, apt, отворили емулатор на терминал и стартирали:

#sudo bash

Да продължим.

«Инициализираме» масив от SATA SSD:

#blkdiscard /dev/md2

Ако не проработи, пробвайте:

#blkdiscard --step 65536 /dev/md2
Създаваме LVM VG на SATA SSD:

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

Защо още един VG..?Всъщност, вече имаме VG с име root. Защо да не добавим всичко в един VG?

Ако в VG има няколко PV, то за правилна активация на VG всички PV трябва да присъстват (онлайн). Изключение прави LVM RAID, който умишлено не използваме.

Много искаме, когато настъпи срив (чети загуба на данни) на който и да е от RAID 6 масивите, операционната система да стартира нормално и да ни позволи да решим проблема.

За това, на първото ниво на абстракция ще изолираме всеки тип физически 'носител' в отделна VG.

Научно казано, различните RAID масиви принадлежат на различни 'домейни на надеждност'. Не е разумно да създаваме обща точка на отказ, събирайки ги в една VG.

Наличието на LVM на 'железен' ниво ще ни позволи произволно да нарязваме парчета от различни RAID масиви, комбинирайки ги по различен начин. Например, - да стартираме в същото време bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, сложна конфигурация ZFS с кешове или каквато и да е друга комбинация, за да можем да експериментираме и сравняваме.

На 'железен' ниво не смеем да използваме нищо друго освен старите добри 'дебели' LVM томове. Изключение от това правило, възможно, ще бъде дял за резервно копиране.

Мисля, че до този момент много читатели вече започват да подозират нещо относно матрешката.

LVM на SATA HDD

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

Още една нова VG..?Много искаме, когато се срине масивът от дискове, който ще използваме за резервно копиране на данни, нашата операционна система да продължава да работи нормално, като същевременно запази достъпа до нерезервираните данни. Затова, за да избегнем проблеми с активация на VG, - създаваме отделна VG.

Настройка на LVM кеш

Ще създадем LV на NVMe RAID 1, за да го използваме като кеш устройство.

#lvcreate -L 70871154688B --name cache root

Защо толкова малко…?Фактът е, че нашите NVMe SSD също имат SLC кеш. 4 гигабайта 'безплатни' и 18 гигабайта динамични благодарение на свободното пространство, заето в 3-bit MLC. След изчерпването на този кеш NVMe SSD ще станат незначително по-бързи от нашите SATA SSD с кеш. Всъщност, по тази причина няма смисъл да правим LVM кеш дяла значително по-голям от два пъти обема на SLC кеша на NVMe носителя. За използваните NVMe носители авторът смята, че е разумно да се направи кеш от 32-64 гигабайта.

Посоченият размер на дяла е необходим за организиране на 64 гигабайта кеш, разполагане на метаданните на кеша и резервна копия на метаданните.

Допълнително ще спомена, че след неочаквано изключване на системата LVM ще маркира целия кеш като мръсен и ще синхронизира отново. Освен това, това ще се повтаря при всяко използване на lvchange на това устройство до ново рестартиране на системата. Затова, препоръчвам веднага да се пресъздаде кеша с подходящ скрипт.

Нека създадем LV на SATA RAID 6, за да го използваме като кеширано устройство.

#lvcreate -L 3298543271936B --name cache data

Защо само три терабайта..?За да може, при необходимост, SATA SSD RAID 6 да се използва за други нужди. Размерът на кешираното пространство може да бъде увеличен динамично, без да се спира работата на системата. За целта е необходимо временно да спрем и отново да пуснем кеша, но отличителното предимство на LVM-cache пред, например, bcache, е, че това може да се направи на летящо.

Нека създадем нова VG за кеширане.

#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
Защо такъв chunksize..?Чрез практически експерименти авторът установи, че най-добри резултати се постигат, когато размерът на блока LVM кеш съвпада с размера на блока LVM thin. В същото време, колкото по-малък е размерът, толкова по-добре конфигурацията се представя при случайна запис.

64k е минималният размер на блока, допустим за LVM thin.

Внимание с writeback..!Да. Този тип кеш отлага синхронизацията на записа на кешираното устройство. Това води до факта, че в случай на загуба на кеша, могат да се загубят данни на кешираното устройство. По-късно авторът ще разкаже какви мерки, освен NVMe RAID 1, могат да се предприемат за компенсиране на този риск.

Този тип кеш е избран целенасочено, за да компенсира ниската производителност на RAID 6 при случайна запис.

Нека проверим какво сме постигнали:

#lvs -a -o lv_name,lv_size,devices --units B cache Устройства LV LSize [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)
На /dev/data/cache трябва да се намира само [cachedata_corig]. Ако нещо не е наред, използвайте pvmove.

Можете да изключите кеша при необходимост с една команда:

#lvconvert -y --uncache cache/cachedata

Това се прави on-line. LVM просто синхронизира кеша на диска, изтрива го и преименува cachedata_corig обратно на cachedata.

Настройка на LVM thin

Приблизително ще оценим колко пространство ще ни е необходимо за метаданните на LVM thin:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes thin_metadata_size - 3385794560 байта приблизителен размер на метаданните за "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

Закръгляме до 4 гигабайта: 4294967296B

Умножим на две и добавим 4194304B за метаданни на LVM PV: 8594128896B
Създайте отделен дял на NVMe RAID 1, за да разположите метаданните LVM thin и техния резервен копие:

#lvcreate -L 8594128896B --name images root

Защо..?Тук може да възникне въпросът, защо да разполагаме метаданните LVM thin отделно, ако те пак ще бъдат кеширани на NVMe и ще работят бързо.

Скоростта тук е важна, но не е основната причина. Работата е там, че кешът е точка на отказ. Нещо може да се случи с него и, ако метаданните LVM thin са кеширани, това ще доведе до пълна загуба на всичко. Без целостта на метаданните свързването на тънките томове ще бъде практически невъзможно.

Като преместим метаданните на отделен некеширан, но бърз том, гарантираме запазването на метаданните в случай на загуба или повреда на кеша. В този случай всички повреди, причинени от загубата на кеша, ще бъдат локализирани вътре в тънките томове, което значително ще улесни процедурата по възстановяване. С голяма вероятност тези повреди могат да бъдат възстановени с помощта на журналите на ФС.

Освен това, ако предварително е направен моментен снимка на тънкия том и след това кешът е бил напълно синхронизиран поне веднъж, то поради особеностите на вътрешната структура на LVM thin, целостта на снимката ще бъде гарантирана в случай на загуба на кеша.

Създайте нова VG, която ще отговаря за thin-provisioning:

#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Освен за каквото е предназначен този режим, — да не позволява данни от една виртуална машина да изтекат в друга виртуална машина при преразпределение на пространството, zeroing допълнително се използва за увеличаване на скоростта на произволно записване на блокове по-малки от 64k. Всяко записване по-малко от 64k в преди това неразпределена област на тънкия том ще бъде преобразувано в 64K, подравнени по границата на кеша. Това ще позволи операцията да бъде изпълнена изцяло чрез кеша, пропускайки кешираното устройство.

Преместете LV на съответните PV:

#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 [lvol0_pmspare] 4294967296B /dev/root/images(0) тънък пул 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 секунди. Половината от тестовете са за запис. За 4 секунди на NVMe можете да запишете много. До 3 гигабайта в секунда. Така че всеки път, когато се стартират тестовете за запис, можете да консумирате до 216 гигабайта от SSD ресурса.

Четене и запис заедно?Да. Тестовете за четене и запис има смисъл да се стартират поотделно. Освен това, важно е да се уверите, че всички кешове са синхронизирани, така че предишният запис да не влияе на четенето.

Резултатите ще варират значително при първото стартиране и последващите в зависимост от запълнеността на кеша и тънкия том, а също и в зависимост от това дали системата е успяла да синхронизира кешовете, запълнени при предишното стартиране.

В допълнение, препоръчвам да измерите скоростта на вече запълнен тънък том, от който току-що е направен моментна снимка. Авторът наблюдава, че случайният запис рязко се ускорява веднага след създаването на първата моментна снимка, особено когато кешът все още не е напълно запълнен. Това се случва благодарение на семантиката copy-on-write на записа, подравняването на блоковете на кеша и тънкия том, както и на факта, че случайният запис на RAID 6 се преобразува в случайно четене с RAID 6 следваща запис в кеша. В нашата конфигурация случайното четене с RAID 6 е до 6 пъти (броят SATA SSD в масива) по-бързо от записа. Тъй като блоковете за CoW се разпределят последователно от тънкия пул, записът, в голяма степен, също се преобразува в последователен.

И двете тези характеристики могат да се използват изгодно.

Кеш-«кохерентни» моментни снимки

За да намалим риска от загуба на данни в случай на повреда/загуба на кеша, авторът предлага да се въведе практика на ротация на моментни снимки, гарантираща тяхната целостност в този случай.

На първо място, благодарение на факта, че метаданните на тънките томове се намират на некеширано устройство, метаданните ще бъдат целостни и възможните загуби ще бъдат изолирани в рамките на блоковете данни.

Следващият цикъл на ротация на моментни снимки гарантира целостта на данните в рамките на моментните снимки в случай на загуба на кеша:

За всеки тънък том с име <имя> създаваме моментна снимка с име <имя>.cached
Нека зададем migration threshold на разумно висока стойност: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
В цикъла проверяваме броя на мръсните блокове в кеша: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' дотигнем нула. Ако нула няма твърде дълго, може временно да се създаде, като кеша се преведе в режим writethrough. Въпреки това, вземайки под внимание скоростните характеристики на нашите масиви SATA и NVMe SSD, както и техния ресурс TBW, или ще можете да уловите момента достатъчно бързо без промяна на режима на кеша, или вашето оборудване напълно ще изразходи целия си ресурс за няколко дни. Поради ограниченията на ресурса системата по принцип не е способна да бъде под 100% натоварване на записа постоянно. Нашите NVMe SSD при 100% натоварване на записа напълно изразходват ресурса за 3-4 дни. SATA SSD ще живеят приблизително два пъти по-дълго. Затова, ще считаме, че основната част от натоварването идва от четене, а по отношение на записа имаме относително краткосрочни изблици на изключително висока активност в съчетание с ниско средно натоварване.
След като уловим (или направим) нолица — преименуваме <име>.cached на <име>.committed. Старото <име>.committed в този случай изтриваме.
Опционално, ако кеша е запълнен на 100%, може да бъде преосновен с помощта на скрипт, така че да бъде изчистен. С полупразен кеш системата работи много по-бързо по отношение на записа.
Ще настроим migration threshold на нула: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata Това временно ще забрани синхронизирането на кеша с основния носител.
Чакаме, докато в кеша се натрупат достатъчно много промени #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' или да сработи таймера.
Повтаряме отново.

Защо сложността с migration threshold…?Работата е там, че в реалната практика „случайният“ запис всъщност не е съвсем случаен. Ако сме записали нещо в сектор с размер 4 килобайта, голяма е вероятността в близките няколко минути да се направи запис в същия или един от съседните (+- 32K) сектори.

Като зададем migration threshold на нула, отлагаме синхронизацията на записа на SATA SSD и агрегатираме няколко промени на един блок от 64K в кеша. По този начин значително спестяваме ресурса на SATA SSD.

А кодът къде..?За съжаление, авторът счита себе си недостатъчно компетентен в разработването на bash скриптове, тъй като е на 100% самоук и практикува „google”-ориентирано развитие, затова смята, че онзи ужасен код, който излиза от ръцете му, е по-добре да не се използва от никого друг.

Мисля, че професионалистите в тази област също могат сами да реализират цялата описана по-горе логика при необходимост и, може би, даже да я оформят красиво във вид на systemd сервиз, както авторът опита да направи.

Тази неусложнена схема за ротация на снимки ни позволява не само постоянно да имаме една напълно синхронизирана снимка на SATA SSD, но и с помощта на утилитата thin_delta да разберем кои блокове са били променени след създаването ѝ, и по този начин да локализираме повредите на основните томове, значително опростявайки възстановяването.

TRIM/DISCARD в libvirt/KVM

Тъй като хранилището на данни ще се използва за KVM под управлението на libvirt, би било добре да научим нашите VM не само да заемат свободно място, но и да освобождават ненужното.

Това се прави чрез емулация на поддръжката на 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'/>


 </disk>

</controller>

Подобни DISCARD команди от гостови ОС се обработват коректно от LVM, и блоковете се освобождават както в кеша, така и в тънкия пул. В нашия случай, това се случва, основно, отложено, при изтриване на следващата снимка.

Резервно копие на BTRFS

Използвайте готови скриптове с крайна внимателност и собствен риск. Авторът е написал този код сам и изключително за себе си. Уверен съм, че много опитни потребители на Linux имат подобни костеливи решения и копирането на чужди не е необходимо.

Създаваме том на резервното устройство:

#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

Копираме скрипта:

Много страшен bash код. Използвайте на собствен риск. Не пратете гневни писма на автора...#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 "Чакам за заключване..."
wait_lock || terminate "Неуспех при получаване на заключване. Излизам..."
echo "Получено заключване..."
}

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" ]
тогава
echo "$SOURCE_BASE_PATH намерено"
else
echo "$SOURCE_BASE_PATH Файл не найден, создается снимок $SOURCE_PATH в $SOURCE_BASE_PATH"
btrfs подтом Snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ]
тогава
echo "$TARGET_BASE_PATH найден, не синхронизирован с источником... удаление..."
btrfs подтом удалить -c $TARGET_BASE_PATH
sync
фи
фи
if [ -d "$TARGET_BASE_PATH" ]
тогава
echo "$TARGET_BASE_PATH найден"
else
echo "$TARGET_BASE_PATH не найден. Синхронизация с $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
фи
if [ -d "$SOURCE_PEND_PATH" ]
тогава
echo "$SOURCE_PEND_PATH найден, удаление..."
btrfs подтом удалить -c $SOURCE_PEND_PATH
sync
фи
btrfs подтом Snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ]
тогава
echo "$TARGET_PEND_PATH найден, удаление..."
btrfs подтом удалить -c $TARGET_PEND_PATH
sync
фи
echo "Отправка $SOURCE_PEND_PATH в $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs подтом Snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs подтом удалить -c $SOURCE_BASE_PATH
sync
btrfs подтом удалить -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 подтом удалить -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 "Помощь"
;;
"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 "Ничего.."
;;
esac
) 98>$LOCK_FILE

EOF

Что хоть оно делает..?Содержит набор простейших команд для создания снимков BTRFS и их копирования на другую ФС посредством BTRFS send/recieve.

Первый запуск может быть относительно долгим, т.к. в начале будут скопированы все данные. Дальнейшие запуски будут очень быстрыми, т.к. копироваться будут только изменения.

Еще один скрипт который запихнем в cron:

Еще немного bash-кода#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 дн."
$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

Что оно делает..?Создает и синхронизирует на backup ФС инкрементальные снимки перечисленных BTRFS-томов. После этого удаляет все снимки созданные 60 дней назад. После запуска в подкаталогах /backup/btrfs/back/remote/ появятся датированные снимки перечисленных томов.

Дадим коду права на выполнение:

#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 thin

Создадим тонкий пул на резервном устройстве:

#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

Копирайте скриптовете:

Много bash вътре...#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 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" == "" ]
тогава
(>&2 echo "Source LV is not thin.")
exit 1
фи

if [ "$DIFF_TARGET_POOL" == "" ]
тогава
(>&2 echo "Target LV is not thin.")
exit 1
фи

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ]
тогава
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
фи

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" != "-" ]
тогава
(>&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
фи

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" == "-" ]
тогава
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
фи

#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" ]
тогава
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
фи

if [ "$SYNC_ACTION" == "discard" ]
тогава
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
фи
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" != "" ]
тогава
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
фи
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" != "" ]
тогава
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" != "" ]
тогава
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
фи
фи
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ]
тогава
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
фи
if [ "$SOURCE_PEND_LV_PATH" != "" ]
тогава
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
фи
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" != "" ]
тогава
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
фи
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" != "" ]
тогава
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
фи
if [ "$TARGET_BASE_LV_PATH" != "" ]
тогава
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
фи
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" != "" ]
тогава
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
фи
if [ "$TARGET_BASE_LV_PATH" != "" ]
тогава
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
фи
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=""
фи
готово
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 "Помощь"
;;
"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 "Ничего.."
;;
esac
) 98>$LOCK_FILE

EOF

Какво прави…?Съдържа набор от команди за манипулиране на тънки снимки и синхронизиране на разликите между две тънки снимки, получени чрез thin_delta, на друго блочно устройство с помощта на ddrescue и blkdiscard.

Още един скрипт, който ще поставим в cron:

Още малко bash#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 дни"

$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
Първоначалното изпълнение ще бъде дълго, тъй като тънките томове ще бъдат напълно синхронизирани чрез копиране на цялото използвано пространство. Благодарение на метаданните на LVM thin знаем кои блокове действително се използват, така че ще се копират само реално използваните блокове на тънките томове.

Следващите изпълнения ще копират данни инкрементално благодарение на проследяването на промените през метаданните на LVM thin.

Нека видим какво се получи:

#time /root/btrfs-backup/cron-daily.sh реални 0м2,967с потребител 0м0,225с система 0м0,353с

#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 .@snap.2020-03-06-09-39-37
drwxr-xr-x 1 root root 516 мар 6 09:39 .@snap.2020-03-06-09-39-57
...
/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 @home.@snap.2020-03-06-09-39-35
drwxr-xr-x 1 root root 22 мар 6 09:39 @home.@snap.2020-03-06-09-39-57
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @.@snap.2020-03-06-09-39-26
drwxr-xr-x 1 root root 240 мар 6 09:39 @.@snap.2020-03-06-09-39-56
...

#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 LV могат да бъдат физически тома LVM PV за други VG. LVM може да е рекурсивен, подобно на матрьошките. Това дава на LVM изключителна гъвкавост.

P.S.

В следващата статия ще опитаме да използваме няколко подобни мобилни СХД/KVM като основа за изграждане на гео-распределен storage/vm-клъстер с резервиране на няколко континента чрез домашни десктопи, домашен интернет и P2P мрежи.

Източник: habr.com