Зачем LVM администратору: быстрые изменения диска без переустановок
LVM (Logical Volume Manager) — это слой абстракции между дисками/разделами и файловой системой. На практике LVM ценят за две вещи: возможность менять размеры томов (расширять и, иногда, уменьшать) и возможность делать снимки (snapshots) для быстрых откатов/бэкапов.
Ниже — типовые операции, которые чаще всего ищут как “lvm resize”: расширение/уменьшение logical volume (команды lvextend/lvreduce) и приведение в соответствие файловой системы (команды resize2fs для ext4 и xfs_growfs для XFS). Плюс — базовая диагностика и активация томов через vgscan/vgchange.
Уменьшение тома всегда рискованнее расширения. Особенно это касается XFS: XFS штатно не умеет уменьшаться. Для критичных данных заранее проверьте бэкапы и план отката.
Короткая шпаргалка по терминам: PV, VG, LV
Чтобы команды не выглядели магией, держим в голове простую модель:
- PV (Physical Volume) — диск или раздел, который LVM «взял под управление».
- VG (Volume Group) — группа томов, пул пространства, собранный из одного или нескольких PV.
- LV (Logical Volume) — логический том, похожий на раздел; на нём обычно лежит файловая система или LUKS.
Типовой путь: диск/раздел → PV → VG → LV → файловая система (ext4/XFS).
Диагностика и инвентаризация LVM: что есть в системе прямо сейчас
Перед любыми изменениями сначала фиксируем факты: какие устройства видны, какие группы активны, где смонтированы файловые системы и сколько в них места.
lsblk -f
pvs
vgs
lvs -a -o +devices
findmnt -rno SOURCE,TARGET,FSTYPE,SIZE,AVAIL,USED
Что полезно смотреть в выводах:
- в
vgs— свободное место в VG (поле VFree), чтобы понять, есть ли чем расширять LV; - в
lvs -o +devices— из каких PV собран LV (важно для понимания рисков и миграций); - в
lsblk -f— тип ФС (ext4/XFS) и точки монтирования.
Если вы расширяете диск на виртуализации, полезно держать под рукой пошаговый сценарий “увеличили диск → расширили раздел → pvresize → lvextend → grow FS”. Отдельно разобрано в материале: как безопасно увеличить диск и раздел на VDS.
Когда том «пропал» после загрузки: vgscan и vgchange
После аварийной перезагрузки, миграции или изменения порядка дисков группы LVM могут не активироваться автоматически, и LV не появляются в /dev/mapper/. Тогда помогают две классические команды: vgscan и vgchange.
vgscan
vgchange -ay
vgscan пересканирует PV и найдёт группы, а vgchange -ay активирует все найденные VG (и, соответственно, LV внутри них).
Если нужно активировать конкретную группу:
vgscan
vgchange -ay vg0
Проверяем, что устройства появились:
lvs
ls -l /dev/vg0
Расширение LVM (lvm resize) в правильном порядке: сначала «дать место», потом «растянуть ФС»
В расширении почти всегда участвуют два шага:
- увеличить размер LV (LVM-уровень) —
lvextend; - увеличить файловую систему (FS-уровень) —
resize2fsилиxfs_growfs.
Перед этим у VG должно появиться свободное место. Оно появляется либо после увеличения существующего PV (через pvresize), либо после добавления нового диска в VG.
Сценарий A: увеличили размер диска/раздела, теперь нужно pvresize
Частый кейс на виртуалках: вы увеличили виртуальный диск в панели, расширили раздел (если он есть), и дальше LVM нужно «увидеть» новый размер.
1) Убедитесь, что ядро видит новый размер устройства:
lsblk
blockdev --getsize64 /dev/sda
2) Если LVM стоит на разделе (например, /dev/sda3), расширьте раздел подходящим вам инструментом, затем обновите информацию о PV:
pvresize /dev/sda3
3) Проверьте, что свободное место появилось в VG:
vgs
pvs
Ключевой момент: без pvresize команда lvextend просто не из чего будет расширять LV.
Сценарий B: добавили новый диск и расширяем VG
Если подключили новый диск (например, /dev/sdb), делаем из него PV и добавляем в VG:
pvcreate /dev/sdb
vgextend vg0 /dev/sdb
vgs
Увеличиваем LV: lvextend
Когда в vgs есть свободное место, расширяем нужный LV. Два удобных варианта:
- добавить конкретный объём;
- занять всё свободное место VG.
lvextend -L +20G /dev/vg0/data
lvextend -l +100%FREE /dev/vg0/data
Проверяем новый размер LV:
lvs /dev/vg0/data
lsblk -f
Увеличиваем файловую систему: resize2fs для ext4 и xfs_growfs для XFS
Дальше команды зависят от типа файловой системы.
ext4: resize2fs
Для ext4 расширение обычно можно делать онлайн (на смонтированной ФС):
resize2fs /dev/vg0/data
Проверка:
df -hT /mountpoint
XFS: xfs_growfs
XFS расширяется только в смонтированном состоянии. Команда применяется к точке монтирования:
xfs_growfs /mountpoint
Проверка:
df -hT /mountpoint
Одна команда «всё сразу»: lvextend -r (осознанно)
Во многих дистрибутивах lvextend умеет сразу вызвать правильный resize для ФС через опцию -r (resizefs). Это удобно, но используйте, только если вы уверены в типе ФС и наличии нужных утилит.
lvextend -r -L +20G /dev/vg0/data
Если нужен максимально предсказуемый процесс — делайте расширение LV и ФС отдельными командами.
Уменьшение LVM: lvreduce и почему порядок действий обратный
Уменьшение — место, где чаще всего «стреляют в ногу». Нельзя сначала уменьшить LV, если файловая система всё ещё считает, что место есть. Иначе данные окажутся «за границей» устройства.
Правильный порядок для ext4:
- уменьшить файловую систему (как правило, offline — с отмонтированием);
- уменьшить LV командой
lvreduce; - смонтировать обратно и проверить.
ext4: пример безопасного уменьшения
Допустим, нужно уменьшить /dev/vg0/data до 50G.
1) Отмонтируем (если это не root и не критический сервис):
umount /mountpoint
2) Проверим ФС и уменьшим её до целевого размера:
e2fsck -f /dev/vg0/data
resize2fs /dev/vg0/data 50G
3) Уменьшим сам LV до 50G:
lvreduce -L 50G /dev/vg0/data
4) Смонтируем обратно и проверим:
mount /mountpoint
df -hT /mountpoint
Опция
lvreduce -rсуществует, но для уменьшения лучше контролировать шаги вручную и видеть ошибкиe2fsck/resize2fsотдельно.
XFS: штатно не уменьшается
Если на LV лежит XFS и нужно уменьшить объём, стандартный путь такой: создать новый LV меньшего размера, сделать новую XFS, скопировать данные (например, rsync), переключить точку монтирования. Прямого аналога resize2fs на уменьшение для XFS нет; xfs_growfs работает только на рост.
Если вы выбираете файловую систему под проект и заранее знаете, что могут понадобиться “поджатия”, полезно понимать практические ограничения ext4 и XFS. По теме — разбор различий и сценариев: ext4 vs XFS на VDS: настройка и эксплуатация.
LVM snapshot: как работает и когда полезен
LVM snapshot — это снимок LV на момент времени. Технически это copy-on-write: пока данные не меняются, snapshot почти не занимает места; как только блоки в исходном LV перезаписываются, старые версии блоков сохраняются в snapshot.
Практические выводы:
- snapshot нужно выделить место (COW-область). Если место закончится — snapshot станет непригоден и его придётся удалять;
- чем активнее запись в origin-LV, тем быстрее растёт snapshot;
- snapshot не заменяет нормальный бэкап, но отлично подходит для коротких рискованных операций: обновления, миграции, снятия консистентной копии.
Создание snapshot
Пример: делаем snapshot размера 10G для /dev/vg0/data:
lvcreate -s -L 10G -n data_snap_2026-01-17 /dev/vg0/data
lvs -a
После этого snapshot можно смонтировать read-only и снять файловый бэкап:
mkdir -p /mnt/data-snap
mount -o ro /dev/vg0/data_snap_2026-01-17 /mnt/data-snap
Проверить заполнение COW-области (это ключевой контроль):
lvs -a -o lv_name,lv_size,origin,data_percent,metadata_percent,lv_attr /dev/vg0/data_snap_2026-01-17
Если data_percent приближается к 100%, snapshot нужно увеличить или завершить операцию и удалить — иначе он переполнится.
Увеличение места snapshot (если не рассчитали)
Snapshot — это такой же LV, его можно расширять:
lvextend -L +5G /dev/vg0/data_snap_2026-01-17
lvs -a -o lv_name,lv_size,data_percent /dev/vg0/data_snap_2026-01-17
Удаление snapshot
Когда snapshot больше не нужен:
umount /mnt/data-snap
lvremove /dev/vg0/data_snap_2026-01-17
Откат на snapshot (rollback через merge)
Откат опаснее создания snapshot: вы возвращаете состояние origin-тома назад во времени и теряете изменения после момента снимка. Убедитесь, что сервисы остановлены и том не используется.
umount /mountpoint
lvconvert --merge /dev/vg0/data_snap_2026-01-17
После merge иногда требуется повторная активация тома или перезагрузка (зависит от того, где и как смонтирован том). Затем монтируем обратно и проверяем.
Частые ошибки и быстрые проверки
1) «Нет места», хотя диск увеличили
Почти всегда пропущен шаг pvresize (если расширяли существующий PV) или не добавили новый диск в VG (pvcreate + vgextend).
pvs
vgs
2) LV расширили, а df не изменился
Это ожидаемо: df показывает размер файловой системы, а не LV. Нужно выполнить resize2fs (ext4) или xfs_growfs (XFS).
3) Snapshot внезапно «сломался»
Чаще всего он переполнился. Смотрите data_percent. Для активной записи не экономьте размер snapshot и не держите снимок дольше необходимого.
4) Томов не видно после восстановления/миграции
Используйте связку vgscan и vgchange -ay, проверьте появление устройств, и только потом чините монтирование.
Мини-чеклист перед lvm resize в проде
- Понимаете тип ФС: ext4 или XFS.
- Есть актуальный бэкап или понятный план отката (snapshot подходит для «коротких работ», но не заменяет бэкап).
- Проверили свободное место в VG:
vgs. - Для расширения: сначала
lvextend, затемresize2fsилиxfs_growfs. - Для уменьшения ext4: сначала
e2fsckиresize2fs(обычно offline), затемlvreduce. - Для XFS: уменьшение делается только через перенос данных на новый меньший том.
- Для snapshot: мониторите
data_percentи не держите снимки дольше необходимого.
Итоги
LVM закрывает сразу несколько админских задач: гибкое управление дисковым пространством и быстрые снимки для безопасных операций. В большинстве случаев вам нужны несколько команд: pvresize, vgscan/vgchange, lvextend/lvreduce и корректный resize файловой системы (resize2fs или xfs_growfs). Главное — соблюдать порядок действий и помнить про ограничение XFS на уменьшение.
Для проектов на виртуальных серверах это особенно удобно: LVM позволяет без даунтайма (или с минимальным окном) добавлять место под базы, логи и медиа. Если вы выбираете площадку под такие задачи, смотрите тарифы VDS и планируйте дисковую схему с запасом под рост.
