Основы LVM: физические тома, группы томов и логические тома¶

LVM (Logical Volume Manager) отделяет «какого размера эта файловая система» от «на каком физическом диске она находится». Именно поэтому можно увеличить файловую систему на продакшн-сервере без простоя, добавить новый диск и расширить на него существующий том, или сделать атомарный снапшот перед рискованным обновлением.

О примерах на этой странице

Команды ниже — корректный синтаксис LVM, безопасный для запуска на отдельном диске или одноразовой виртуальной машине — практическое задание ниже использует файл-образ через loopback, а не ваш продакшн-диск с корневой системой. Ни один вывод на этой странице не получен запуском этих команд на инфраструктуре этой вики.

Как это устроено¶

У LVM три слоя:

Physical Volume (PV)  →  Volume Group (VG)  →  Logical Volume (LV)
  (реальный диск/           (пул, объединяющий    (изменяемый по размеру
   раздел)                   один или несколько    «виртуальный раздел»,
                             PV)                    выделенный из VG)

Файловая система (ext4, XFS и т.д.) создаётся поверх Logical Volume — точно так же, как она бы создавалась поверх обычного раздела. LVM — это слой ПОД файловой системой, а не замена ей.

Создание стека¶

# Превратить сырое блочное устройство в Physical Volume
sudo pvcreate /dev/sdb

# Объединить его в Volume Group по имени "data"
sudo vgcreate data /dev/sdb

# Выделить Logical Volume на 20G из этой группы
sudo lvcreate -n app_lv -L 20G data

# Создать на нём файловую систему
sudo mkfs.ext4 /dev/data/app_lv

# Смонтировать
sudo mkdir -p /mnt/app
sudo mount /dev/data/app_lv /mnt/app

pvcreate записывает метку и метаданные LVM на устройство — это разрушительно для того, что было на нём раньше. vgcreate <name> <device(s)> может сразу принять несколько PV, объединяя их ёмкость. -L 20G запрашивает фиксированный размер; -l 100%FREE вместо этого выделяет всё оставшееся свободное место в VG.

Онлайн-расширение Logical Volume¶

Это флагманская возможность LVM — расширение файловой системы без размонтирования:

sudo lvextend -L +10G /dev/data/app_lv
sudo resize2fs /dev/data/app_lv        # ext4; для XFS — `xfs_growfs /mnt/app`

lvextend увеличивает блочное устройство; сама файловая система всё ещё думает, что она старого размера, пока не выполнить команду расширения конкретно для неё (resize2fs для ext2/3/4, xfs_growfs для XFS — учтите, XFS умеет только расти, никогда не сжиматься, тогда как ext4 умеет и то, и другое в офлайне).

Что у вас есть¶

$ lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   40G  0 disk
├─sda1            8:1    0    1G  0 part /boot
└─sda2            8:2    0   39G  0 part
  └─ubuntu--vg-root 253:0 0   39G  0 lvm  /
sdb               8:16   0   50G  0 disk
└─data-app_lv     253:1  0   30G  0 lvm  /mnt/app

lsblk показывает весь стек одним взглядом: физические диски (sda, sdb), разделы, и логические тома LVM поверх них (с отступом, с префиксом имени VG).

Снапшоты¶

sudo lvcreate -s -n app_lv_snap -L 2G /dev/data/app_lv

Снапшот — это копия на момент времени, доступная на запись, которая хранит только отличия от оригинала (copy-on-write). Полезно перед миграцией схемы БД или рискованным обновлением — если что-то пойдёт не так, lvconvert --merge откатит оригинал к состоянию снапшота. -L 2G здесь — это собственное место снапшота для хранения изменённых блоков, а не размер снапшотируемых данных — если изменится больше 2G блоков до удаления снапшота, он переполнится и станет непригодным, так что размер нужно выбирать с запасом относительно ожидаемого объёма записи за время жизни снапшота.

Программный RAID с mdadm (альтернатива/дополнение к LVM)¶

Сам LVM — это не избыточность: падение PV роняет его VG, если только само устройство не избыточно. mdadm строит программные RAID-массивы Linux, которые затем можно использовать как PV:

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc /dev/sdd
sudo pvcreate /dev/md0
sudo vgcreate data /dev/md0

--level=1 — зеркалирование (каждая запись идёт на оба диска); --level=5 — чередование с чётностью, нужно минимум 3 диска, обменивает часть ёмкости на возможность пережить отказ одного диска. Проверка здоровья массива: cat /proc/mdstat или mdadm --detail /dev/md0.

После создания массива запишите его в конфигурацию, чтобы он собирался при загрузке: sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf, затем sudo update-initramfs -u (Debian/Ubuntu; в RHEL-подобных системах файл /etc/mdadm.conf и команда sudo dracut --force). RAID — это доступность, а не резервная копия: случайный rm он честно отзеркалит на все диски.

Различия Ubuntu/Debian и RHEL-подобных систем¶

Команды и поведение LVM идентичны — это один и тот же пакет lvm2 в обеих семьях. Основное практическое различие — в настройках инсталлятора по умолчанию: инсталляторы RHEL-семейства по умолчанию кладут корневую файловую систему на LVM (видно как VG/LV в стиле rhel-root), так же делает и управляемая установка Ubuntu Server (ubuntu-vg). Управляемая разметка Debian по умолчанию использует обычные разделы, если не выбрать схему с LVM.

Практическое задание¶

Используйте loopback-файлы вместо настоящих дисков — полностью безопасно, без реального железа:

sudo dd if=/dev/zero of=/tmp/disk1.img bs=1M count=512
sudo losetup -fP /tmp/disk1.img
losetup -a                     # посмотрите, какой /dev/loopN назначен

sudo pvcreate /dev/loopN
sudo vgcreate test_vg /dev/loopN
sudo lvcreate -n test_lv -L 200M test_vg
sudo mkfs.ext4 /dev/test_vg/test_lv

Закончив, разберите лабораторию в обратном порядке (замените /dev/loopN на устройство из losetup -a):

sudo lvremove test_vg/test_lv
sudo vgremove test_vg
sudo pvremove /dev/loopN
sudo losetup -d /dev/loopN
rm /tmp/disk1.img

Как проверить, что всё сделано правильно¶

sudo vgs должен показать test_vg с VSize около 512M и VFree, уменьшенным примерно на 200M.
sudo lvs должен показать test_lv с LSize равным 200.00m.
lsblk должен показать loop-устройство с вложенным в него LV.

Типичные ошибки¶

Забыть расширение на уровне файловой системы после lvextend — блочное устройство выросло, df -h всё ещё показывает старый размер, потому что метаданные самой файловой системы об этом не узнали.
Занизить собственный размер снапшота, из-за чего он молча становится Invalid, как только изменится достаточно блоков — всегда проверяйте lvs на предмет Data% снапшота, а не только факт его создания.
Запуск vgextend/pvcreate не на том устройстве. pvcreate по умолчанию без интерактивного подтверждения стирает суперблок существующей файловой системы — всегда проверяйте lsblk и трижды перепроверяйте имя устройства.

⚠ Опасные команды¶

pvcreate / vgcreate / mkfs.* на устройстве, которое реально используется (смонтированная файловая система, не тот loop-девайс, диск, который вы хотели не трогать), уничтожает данные на нём без возможности отмены. Всегда сначала проверяйте через lsblk и mount.
lvremove немедленно удаляет логический том и всё на нём — есть флаг -y/force, пропускающий даже интерактивное подтверждение «вы уверены»; никогда не скриптуйте этот флаг против того, что не проверили дважды.
mdadm --create на устройствах, уже содержащих данные от предыдущего массива, обычно спрашивает про существующие суперблоки — не игнорируйте этот запрос без чтения; часто это единственное предупреждение перед молчаливой пересборкой не того массива.

Связанные статьи¶

Иерархия файловой системы Linux и базовые понятия

Контрольные вопросы¶

Какова реальная связь между Physical Volume, Volume Group и Logical Volume?
Почему расширение Logical Volume через lvextend не расширяет файловую систему на нём автоматически?
В чём практическая разница между RAID 1 и RAID 5 по ёмкости и отказоустойчивости?
Что происходит со снапшотом LVM, если объём изменённых данных превышает выделенное под него место?