​​Периодически вижу в комментариях к статьям по Linux вопросы на тему того, зачем использовать LVM (Logical Volume Management, Управление Логическими Томами) во время разметки диска. Якобы это лишний слой абстракции, даёт замедление и лучше без него. Я не буду рассказывать, что такое LVM и как с ним работать. Напишу своё мнение на тему использования этой технологии в рабочих виртуальных машинах.

Начну с того, что я нигде не видел информации о том, что использование LVM даёт сколь-нибудь заметное замедление, выходящее за погрешность измерения. Тем не менее, лет 5 и более назад я сам LVM использовал очень редко, потому что считал, что лучше в самом деле обойтись без лишних абстракций, когда нет особой необходимости.

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

Тем не менее, всё равно иногда возникают ситуации, когда тебе надо увеличить корневой раздел. И если не используется LVM, то это проблема, которую не всегда можно решить. Если же использовать LVM, то проблемы вообще никакой нет. Можно корень / расширить на ходу без перезагрузки. Когда в очередной раз у меня возникла в этом потребность, я решил, что буду использовать LVM всегда.

Подводя итог, мне LVM нужен только чтобы иногда увеличить какой-то раздел: расширяем диск виртуалки или подключаем новый, добавляем его в группу томов, расширяем нужный раздел, расширяем файловую систему. И всё. Больше никаким функционалом не пользуюсь.

А вы используете LVM в своих виртуалках?

#linux #lvm

В ОС на базе Linux существуют несколько наиболее популярных программных решений для построения отказоустойчивого дискового хранилища, или по простому - софтовых рейдов:

◽️Mdadm
◽️LVM Raid
◽️ZFS

Про Mdadm рассказывать особо нечего. Это самый популярный программный рейд, которому сто лет в обед. Он очень прост в настройке и эксплуатации, про него масса статей с инструкциями. Я использую его повсеместно и проблем с ним никогда не знал. Много писал про него на канале.

Про ZFS тоже рассказывать большого смысла нет. Известная и проверенная временем технология. Я ещё на Freebsd её использовал и очень радовался, когда корень системы можно было поставить на ZFS. Она спокойно переживала аварийные выключения сервера, в отличие от UFS, которая была файловой системой по умолчанию и постоянно ломалась после аварийных отключений.

А вот про LVM Raid и информации немного, и практического применения я не видел. Мне не очень понятно, почему. Я немного поигрался с этим рейдом на тестах. Выглядит интересно. Сразу скажу, почему я решил обратить на него внимание. LVM Raid поддерживает технологию DM-integrity (device mapper integrity), с помощью которой можно контролировать целостность хранимой информации с помощью дополнительного хранения и проверки метаданных (checksum) файлов. Это то, что ZFS делает по умолчанию. Поясню, зачем это надо.

В современных дисках, как HDD, так и SSD, очень высокая плотность записи. Это делает сохранение заряда в ячейках менее надёжным и долговременным. Допустим, у вас на дисках долго хранится какой-то объём информации. В каких-то ячейках изменились записанные биты либо из-за ошибок при записи, либо возникли во время хранения. При этом диски полностью исправны и ошибок чтения нет. То есть технически всё в порядке. Но во время чтения вы можете получить битые файлы, которые при этом успешно прочитаются. Но информация будет разрушена.

При использовании Mdadm и поверх него ФС EXT4 или XFS, никакой защиты от подобных ошибок у вас не будет. Если не делать регулярное сопоставление записанных файлов с каким-то другим хранилищем таких же файлов, то о битых файлах вы не узнаете, пока явно не наткнётесь на них во время проверки. В LVM Raid с поддержкой DM-integrity часть хранилища выделяется под хранение метаданных файлов. Я не нашёл точно информации, сколько конкретно % от общего объёма тратится. Но там немного, не более 10%.

При использовании LVM Raid + DM-integrity вы узнаете о битых файлах при очередной проверке файлов с тем, что записано ранее в хранилище метаданных. Это происходит как минимум во время чтения. Я так понимаю, что процесс этот может происходить и в фоне, можно и принудительно запускать и смотреть результаты. CLI от LVM даёт такие возможности. При обнаружении повреждённых файлов, они будут автоматически восстановлены с других носителей в рейд массиве.

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

Если кто-то использовал LVM Raid, поделитесь опытом и впечатлениями. Особенно интересно, если дополнительно включали DM-integrity. Без неё я не вижу смысла использовать рейд LVM, а не Mdadm. LVM хоть и даёт бОльшую гибкость в управлении. Например, можно на лету изменить уровень рейда, увеличить или уменьшить тома. Но на практике это не особо нужно. Mdadm проще и более предсказуем, интуитивен в управлении. Технически DM-integrity можно включить и для дисков в составе Mdadm, но там нет нативной поддержки, как в LVM. Битые файлы будут помечаться как ошибки чтения диска и Mdadm будет пытаться их синхронизировать с других дисков. Это тоже рабочий вариант, но не такой удобный в плане управления и отслеживания ошибок.

#lvm #raid

Шпаргалка на тему создания LVM Raid. Создаём RAID1.

# apt install lvm2
# pvcreate /dev/sdb /dev/sdc
# vgcreate vgroup /dev/sdb /dev/sdc
# lvcreate --type raid1 -l 100%FREE -n lvraid1 vgroup

Проверяем:

# lvs -o+segtype

Создаём файловую систему и монтируем:

# mkfs.ext4 /dev/vgroup/lvraid1
# mkdir /mnt/lvraid1
# mount /dev/vgroup/lvraid1 /mnt/lvraid1

Смотрим, что в итоге получилось:

# lsblk

Скопируем туда что-нибудь, дождёмся полной синхронизации и удалим один из дисков.

# cp -r /var/log/* /mnt/lvraid1/

Диск отключил. Проверяю данные, всё на месте. То есть LV работает как и прежде. Проверяю статус:

# lvs -a -o name,devices vgroup

Вижу, что одно устройство в статусе [unknown]. Добавляю в систему новый диск. Не тот же самый, что я отключил.

# lsblk

Вижу, что он подключился на /dev/sdd. Добавляю его в VG:

# pvcreate /dev/sdd
# vgextend vgroup /dev/sdd

Удаляем вывалившийся диск:

# vgreduce --removemissing vgroup --force

Проверяем:

# lvs -a -o name,devices vgroup

Устройства в статусе [unknown] больше нет. Добавляем в наш LV новый диск:

# lvconvert --repair vgroup/lvraid1
# lvconvert -m1 vgroup/lvraid1 /dev/sdd

На все вопросы отвечаем утвердительно. Смотрим результат и наблюдаем за синхронизацией:

# lvs -a -o name,devices vgroup
# lvs -o+segtype

Пошла синхронизация, данные все на месте. Замена прошла без остановки системы. Диски убирал и добавлял наживую. В целом, ничего сложного. Вполне понятный и логичный набор команд. Один раз проверил, записал и воспроизвёл в случае выхода из строя диска.

Из особенностей LVM Raid - LV можно конвертировать налету в разные уровни рейдов, добавлять к ним диски. Можно из raid1 сделать raid5, добавить туда диски. Не думаю, что на практике это будет оправданно. А вот превратить raid1 в raid10 видится полезным. Было 2 диска, добавил ещё 2 и получил raid10. Для этого надо добавить 2 диска в VG и сконвертировать LV. Прямой конвертации из raid1 в raid10 нет. Нужно сначала сконвертировать в raid5, добавить туда 2 диска, дождаться синхронизации и сконвертировать в raid10:

# pvcreate /dev/sdc /dev/sde
# vgextend vgroup /dev/sdc /dev/sde
# lvconvert --type raid5_n vgroup/lvraid1
# lvresize -l5118 vgroup/lvraid1 # размер зависит от размера LV
# lvconvert --stripes 1 vgroup/lvraid1
# lvconvert --stripes 2 vgroup/lvraid1
# lvconvert --type raid10 vgroup/lvraid1
# lvconvert --type raid10 vgroup/lvraid1

На выходе получил из RAID1 ⇨ RAID10 без остановки и потери данных. Я по всем этим командам получал подсказки в консоли. Там и по размеру подсказки были, и по тому, что финальная конвертация проходит в 2 этапа, и что сначала надо в raid5_n сконвертировать.

Если делать с нуля RAID10, то команда простая. Сначала добавляем 4 одинаковых диска в VG, потом создаём LV:

# lvcreate --type raid10 -l 100%FREE -n lvraid10 vgroup

А теперь ради чего всё это затевалось. LVM Raid умеет вести контроль целостности файлов на основе хэшей. Реализуется это на базе технологии DM Integrity. Включаем её во время создания LV:

# lvcreate --type raid1 --raidintegrity y -L 9G -n lvraid1 vgroup

Размер нужно будет вычислять опытным путём. Я сначала указал размер 100% и получил ошибку, что для моих 10G дисков нужно 150 MiB под метаданные. В итоге указал 9G.

Если в VG есть свободное место, то добавить raidintegrity можно к существующему тому:

# lvconvert --raidintegrity y vgroup/lvraid1

При каждой операции чтения выполняется расчёт контрольной суммы файла. Если она не совпадает с сохранённой ранее, выполняется попытка восстановления файла из других копий в составе рейда.

Для каждого диска в составе LV с DM Integrity создаётся отдельный LV rimage для хранения метаданных. В нём можно посмотреть статистику по ошибкам:

# lvs -o+integritymismatches vgroup/lvraid1_rimage_0_imeta

Колонка IntegMismatches. Все события по DM Integrity будут в системном логе /var/log/syslog.

Всё, что я показал, подробно описано в руководстве по LVM от Red Hat.

#lvm #raid

Продолжу тему с LVM Raid, чтобы получить законченное решение, которое можно будет использовать в проде. Я хочу установить корень системы / на LVM Raid, чтобы в случае выхода из строя диска иметь полностью работающую систему.

Для этого взял виртуалку с Debian 12 и установил систему с ручным разбитием диска. Создал ровно один раздел /dev/sda1, на нём создал VG - vgroup и один LV - root на весь доступный объём. Больше не делал ничего. Раздел /boot не выносил отдельно. Всё только в корне. Grub уже давно умеет грузиться с LVM разделов.

Установил систему. Добавил туда ещё один диск /dev/sdb. Скопировал на него разметку с sda и добавил его в VG:

# sfdisk -d /dev/sda | sfdisk /dev/sdb
# pvcreate /dev/sdb1
# vgextend vgroup /dev/sdb1

Пробую сконвертировать корневой раздел в RAID1:

# lvconvert --type raid1 -m 1 vgroup/root

Получаю ошибку:

Insufficient free space: 1 extents needed, but only 0 available

Суть её в том, что при создании любого RAID необходимо создать отдельный малюсенький LV на 4 MiB для хранения метаданных массива. А я полностью весь VG во время установки отдал на LV root. Чтобы избежать этой ошибки, оставляйте во время установки немного места на VG.

Решить эту проблему не трудно. LV можно уменьшить вместе с ФС, если это ext4:

# lvreduce -l -1 --resizefs /dev/vgroup/root

Команда сработает, только если раздел размонтирован. А у меня это корень системы, так что получил ошибку. Решение простое. Загрузился с SystemRescueCD и выполнил её там. Откусил кусочек от LV, теперь конвертирую в RAID1:

# lvconvert --type raid1 -m 1 vgroup/root

Всё проходит без ошибок. Загружаю систему, проверяю массив:

# lvs -o+segtype
# lvs -a -o name,devices vgroup

Всё в порядке, оба диска на месте. Ставлю загрузчик на второй диск sdb:

# dpkg-reconfigure grub-pc

Теперь вынимаю первый диск sda, на который изначально ставилась система и перезагружаю её. Grub запускается со второго диска, а дальше вываливаюсь в initramfs. Система не грузится, пишет, что не видит диск /dev/mapper/vgroup-root. В консоли initramfs ввожу команду на активацию всех lvm томов:

# vgchange -ay

Находит VG vgroup, но ругается, что там нет sda. Логично, диск этот отключен. После этого выхожу из initramfs:

# exit

Так как LVM раздел активирован, грузится система со второго диска. То есть в целом всё в порядке. Система жива, загружается. Надо только разобраться с тем, чтобы initramfs автоматически активировал неактивный VG с raid1.

Как оказалось, проблема эта нередкая. Нашёл решение в интернете. Создаём файл /etc/initramfs-tools/scripts/local-top/forcelvm следующего содержания:

#!/bin/sh

PREREQ=""
prereqs()
  {
    echo "$PREREQ"
  }
case $1 in
  prereqs)
  prereqs
  exit 0
   ;;
  esac
. /scripts/functions
lvm vgchange -ay

Пересобираем initramfs:

# chmod +x /etc/initramfs-tools/scripts/local-top/forcelvm
# update-initramfs -u -k all

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

Заменяем выключенный диск новым. Смотрим, какие диски есть в системе:

# lsblk

У меня с данными диск стал sda, новый sdb. Копирую на него разметку, добавляю в VG и LV с raid1:

# sfdisk -d /dev/sda | sfdisk /dev/sdb
# pvcreate /dev/sdb1
# vgextend vgroup /dev/sdb1
# vgreduce --removemissing vgroup --force
# lvconvert --repair vgroup/root
# lvconvert -m1 vgroup/root /dev/sdb1

Ставим загрузчик на новый диск:

# dpkg-reconfigure grub-pc

Следим за синхронизацией:

# watch lvs -a

Когда закончится, перезагружаем систему и убеждаемся, что всё работает.

Получилась готовая инструкция по установке системы на LVM Raid1 и по замене вышедшего из строя диска. В целом, всё примерно то же самое, что и в mdadm со своими нюансами. При случае попробую на каком-нибудь железном сервере вместо mdadm - LVM. На вид выглядит удобнее и функциональнее.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm #raid

Я уже ранее делал заметку насчёт LVM, где пояснил, что чаще всего виртуалки делаю с LVM. Это добавляет некоторые удобства, которые по сути ничего не стоят. То есть не вижу смысла их не использовать. Хоть и не часто, но LVM может сильно выручить.

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

Расскажу про ещё одну фичу LVM, которую легко использовать, и которая в некоторых ситуациях может серьезно выручить. Речь пойдёт про снепшоты. Именно снепшот LVM спас Gitlab во время эпической аварии, когда они могли потерять все данные, но между делом сделанный снепшот их спас.

Снепшоты могут выручить, если у вас хранилище гипервизора без их поддержки, что не так уж редко бывает. Например, хранилище в Proxmox типа LVM, не LVMThin, снепшоты не поддерживает. Также актуально, если вы арендуете VPS без доступа к гипервизору. Обычно там можно только расширить диск, что достаточно для использования снепшотов.

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

Беру виртуалку, которая полностью установлена на LVM, что я чаще всего и делаю. На VG свободного места нет. Проверяем это:

# pvs

Добавляем в виртуальную машину ещё один диск, либо расширяем существующий. Принципиальной разницы нет. У вас либо появится новый диск, либо новый раздел на текущем диске. Их и используем для расширения VG. Я добавил диск sdb размером 10G. Расширяю им VG:

# vgextend vgroup /dev/sdb

По хорошему лучше сначала сделать раздел sdb1, и расширить уже им, но для краткости опускаю этот момент.

# pvs
PV      VG   Fmt Attr PSize   PFree  
/dev/sda1 vgroup lvm2 a-- <20.00g   0 
/dev/sdb  vgroup lvm2 a-- <10.00g <10.00g

Теперь могу создать снепшот корня. Делаю ему размер 9G:

# lvcreate -L 9G -s -n root_snap /dev/vgroup/root

Смотрю, что получилось:

# lvs

По сути появился ещё один LV. С ним можно работать, как с обычным разделом. Например, подмонтировать его:

# mount /dev/vgroup/root_snap /mnt

Увидим в /mnt состояние системы на момент создания снепшота.

Посмотрим, как снепшот работает. Полностью обновим систему и перезагрузимся:

# apt update && apt upgrade -y && reboot

После перезагрузки посмотрим на статус LV и на версию загруженного ядра:

# lvs
root    vgroup owi-aos--- <20.00g                           
root_snap vgroup swi-a-s---  9.00g   root  15.85   

# uname -a

Допустим, что-то пошло не так и нам надо откатиться на состояние до обновления. Восстанавливаем снепшот:

# lvconvert --merge /dev/vgroup/root_snap

Видим ошибку:

Delaying merge since origin is open.
Merging of snapshot vgroup/root_snap will occur on next activation of vgroup/root.

Это нормально, так как для восстановления нужно размонтировать LV. Наживую восстановить снепшот нельзя. Восстановление будет запущено после перезагрузки, во время активации LV. Текущий корневой LV будет помечен как (O)rigin with merging snapshot, это видно в lvs:

# lvs
root vgroup Owi-aos--- <20.00g

После первой перезагрузки начнётся восстановление из снепшота. Так как это корневой раздел, полностью всё перезаписать не получится, так как раздел системный, файлы заняты рабочими процессами. Делаем reboot ещё раз. После него система вернётся в состояние до снепшота. Можно проверить это по загруженному ядру:

# uname -a

Для несистемного раздела всё выполняется без перезагрузок. В случае, если всё ОК и снепшот не пригодился, удаляем его:

# lvremove /dev/vgroup/root_snap

💥 Обязательно удалите снепшот после того, как убедитесь, что он не нужен.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm

Продолжу вчерашнюю тему со снепшотами LVM, так как в публикации не хватило лимита по объёму. Работать со снепшотами можно как с обычными разделами. Его можно монтировать, сохранять в образ и передавать куда-то по сети. Либо без сохранения сразу по сети передать напрямую.

Допустим, вы сделали снепшот /dev/vgroup/root_snap. Можете его сразу передать на другой сервер:

# dd if=/dev/vgroup/root_snap | ssh root@10.20.1.36 "dd of=vgroup-root.img"

Получили живой бэкап. Его можно, к примеру, подмонтировать и посмотреть данные:

# mount vgroup-root.img /mnt

У нас копия сервера, подключенная к другому серверу. Точно так же можно сохранить снимок локально в файл. Только нужно иметь ввиду, что это должен быть другой раздел. Иначе вы снепшот в снепшот сохранять начнёте.

# dd if=/dev/vgroup/root_snap of=/mnt/backup/vgroup-root.img

Из этого снимка можно восстановить систему полностью. Для этого нужен будет какой-то загрузочный диск c Linux. Нужно будет восстановить данные из образа на какой-то диск и отдельно установить на него загрузчик grub. То есть это простой и гарантированный способ получить целостную копию работающей системы и спокойно передать её куда-то по сети.

☝️ Отмечу ещё раз отдельно, что снепшоты LVM – вполне стабильная и рабочая функциональность. Это не какой-то хак, трюк, костыль, который работает на свой страх и риск. Можно без особых опасений её использовать, главное понимать нюансы работы снепшотов. Они немного снижают производительность, их нельзя оставлять надолго, так как они начинают занимать место в VG, которое может кончиться. Могут возникнуть проблемы.

Снепшот делается по ситуации, проверяется работа после его создания. Потом он либо куда-то сохраняется, либо откатывается, либо сливается с текущим состоянием. Оставлять его не нужно. Слияние большого снепшота, особенно на нагруженной системе, может прилично нагрузить дисковую подсистему.

Вот ещё одно коротенькое руководство, как можно с помощью снепшотов безопасно обновить систему, которая установлена в VG vgroup на LV root.

Переименовываем текущий LV и создаём вместо него snapshot с таким же названием:

# lvrename vgroup root root-old
# lvcreate -n root -s /dev/vgroup/root-old -L 9G
# reboot

Перезагружаемся. Теперь у нас снепшот в роли корневого раздела. Мы можем выполнять какие-то действия с системой - обновлять, ломать, тестировать какую-то функциональность. Когда закончите, можно зафиксировать это. Переименовываем текущее состояние в виде снепшота в новое, а корень возвращаем обратно, как было:

 # lvrename vgroup root root-new
 # lvrename vgroup root-old root

Если изменения вам подошли и вы готовы их принять, то сливаем снепшот нового состояния с текущем корнем:

# lvconvert --merge /dev/vgroup/root-new
# reboot

После перезагрузки по lvs смотрим, когда слияние закончится и перезагружаемся ещё раз:

# lvs
# reboot

Чтобы все изменения применились, надо перезагрузиться 2 раза. Снепшот при слиянии удаляется автоматически, ничего для этого делать не надо.

Если же вам изменения не нужны, то просто удаляем снепшот:

# lvremove /dev/vgroup/root-new
# reboot

Инструкция 100% рабочая. Проверял несколько раз и на прошлой заметке, и на этой. Снепшоты, когда вся система вместе с /boot разделом на LVM работают без проблем.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm

У меня уже были заметки про фишки LVM, сегодня расскажу про ещё одну, которая может пригодиться. С помощью LVM и снепшотов можно делать консистентные бэкапы баз данных Mysql на уровне файлов, а не дампов, практически без простоя. Для таких задач в СУБД Percona есть инструмент под названием XtraBackup, а вот если у вас обычная бесплатная MySQL или MariaDB, то с бэкапами на уровне файлов там не так всё просто, особенно если вы уже не можете делать дампы из-за их больших размеров.

Идея там вот в чём. Мы закрываем все открытые таблицы, сбрасываем кэш, блокируем изменение данных, после этого делаем снепшот раздела с базами данных и сразу отключаем блокировки. Это занимает буквально пару секунд, на которые блокируются все базы, а потом спокойно копируем файлы сервера, примонтировав снепшот.

Это всё хорошо работало до появления движка InnoDB. У него есть нюансы, когда блокировки не предотвращают изменение данных в таблицах. Нужно дополнительно сбрасывать на диск так называемые dirty_pages. Покажу всё это на практике. Способ немного костыльный и вряд ли подойдёт для прода, так как есть много нюансов. Но в каких-то ситуациях может помочь быстро снять консистентную копию без остановки сервера.

Для того, чтобы всё получилось, раздел, где хранятся данные MySQL сервера, должен располагаться на LVM, а в Volume Group должно быть свободное место для снепшотов. Проверяем так:

# pvs

Если места нет, надо добавить. Не буду на этом останавливаться, рассказывал ранее. Первым делом заходим в консоль mysql, сбрасываем кэш и включаем блокировки:

> SET GLOBAL innodb_max_dirty_pages_pct = 0;
> FLUSH TABLES WITH READ LOCK;

Если база не сильно большая и нагруженная, кэш быстро сбросится. Наблюдать можно так:

> SHOW ENGINE INNODB STATUS\G;

Следим за значением Modified db pages. Оно должно стать 0. После этого можно делать снэпшот:

# lvcreate --size 5G --snapshot --name mysql_snapshot /dev/vgroup/root

После этого возвращаем обратно настройку с dirty_pages в исходное значение (по умолчанию 90) и снимаем блокировки:

> SET GLOBAL innodb_max_dirty_pages_pct = 90;
> UNLOCK TABLES;

Когда это делается автоматически скриптом, всё это происходит быстро. Но есть нюансы. Команда блокировки дожидается завершения всех запросов. Если у вас там есть какие-то очень длинные запросы, то вся база будет заблокирована, пока они не завершатся. Так что имейте это ввиду.

Монтируем снепшот и копируем данные:

# mkdir /mnt/mysql_backup
# mount /dev/vgroup/mysql_snapshot /mnt/mysql_backup
# rsync -avz --delete /mnt/mysql_backup/var/lib/mysql/ user@10.20.1.5:/mnt/backup/mysql/

После копирования снепшот надо обязательно удалить.

# umount /mnt/mysql_backup
# lvremove -f /dev/vgroup/mysql_snapshot

Получили консистентный бэкап всех баз данных практически без остановки сервера, но с кратковременной блокировкой изменений.

Я собрал всё это в скрипт и протестировал на сервере с MariaDB и Zabbix Server. Сохранил бэкап локально, потом остановил MariaDB, полностью удалил директорию /var/lib/mysql и восстановил из бэкапа. Потом запустил СУБД. Запустилось без проблем, никаких ошибок. Бэкап получается консистентный.

Скрипт особо не отлаживал, так что аккуратнее с ним. Просто убедился, что работает. Сначала немного накосячил, так как после включения блокировки закрывал сессию, делал снепшот и подключался снова. Так нельзя, потому что команда FLUSH TABLES WITH READ LOCK живёт, пока открыто соединение. Надо в рамках него делать всё необходимое. Запустил lvcreate через SYSTEM.

Такой вот небольшой трюк в копилку LVM, который можно применять не только к СУБД, но и другим данным.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm #mysql #backup