LVM Linux – це шар керування дисковим простором між фізичними дисками та файловою системою. У практичному сценарії він потрібен не для “краси”, а щоб без перевстановлення системи розширити том, вивести диск з масиву обслуговування або перенести дані на новий носій з мінімальним простоєм.
Для homelab це один з небагатьох інструментів, який реально спрощує життя, коли місце закінчилося не там, де очікувалося. Статична розбивка диска швидко впирається в межі. LVM дозволяє перекидати ємність між томами, але тільки якщо схема зібрана акуратно і є розуміння, де саме можна зламати дані.
Нижче – практичний розбір: як підготувати LVM Linux, як безпечно розширити том, як замінити диск без копіювання всього сервера наново, що перевіряти після змін і де ця схема вже починає програвати іншим підходам.
Де LVM справді виручає
LVM має сенс там, де дискове навантаження живе окремо від початкової розмітки. Найтиповіший випадок – сервер, де root, дані контейнерів, backup і медіатека ростуть нерівномірно. У такій схемі не доводиться вгадувати розмір кожного розділу наперед.
У homelab це часто виглядає так: система стоїть на одному диску, потім додається другий, далі третій, і в якийсь момент починається ручне латання розділів. Якщо основа побудована на LVM, новий диск додається у volume group, після чого ємність віддається саме тому логічному тому, який уперся в стелю.
Ще один сильний сценарій – заміна старого диска на більший. На практиці це зручніше, ніж повний rsync або перевстановлення, якщо треба пересунути extents між physical volumes. Але тут є межа: LVM не замінює backup і не лікує проблеми з самими дисками.
Схема LVM без якої далі буде боляче
У LVM Linux є три базові сутності: physical volume, volume group і logical volume. Диск або розділ стає physical volume, кілька physical volumes складаються у volume group, а вже з неї нарізаються logical volumes під файлові системи.
Теорія проста. Помилки починаються на рівні планування. Найгірший варіант – віддати у volume group всі диски без розуміння, де лежать критичні дані. Коли extents розмазуються по кількох носіях, вихід з ладу одного диска може покласти весь logical volume, навіть якщо за обсягом втрачена лише частина.
Тому для домашньої інфраструктури працює жорстке правило: LVM – це не RAID. Якщо потрібна відмовостійкість, її треба будувати нижче або вище: mdadm, апаратний RAID, ZFS, btrfs чи окремий backup-контур. Сам по собі LVM вирішує задачу керування ємністю, а не збереження даних.
Як налаштувати LVM Linux з нуля
Базове налаштування LVM Linux складається з трьох кроків: ініціалізувати диск як physical volume, створити volume group і виділити logical volume під файлову систему. Після цього том форматується, монтується і вже працює як звичайний блоковий пристрій.
- Перевірити, який саме диск буде використано.
- Створити physical volume.
- Зібрати volume group.
- Створити logical volume потрібного розміру.
- Створити файлову систему.
- Змонтувати том і додати його в автозавантаження.
lsblk sudo pvcreate /dev/sdb sudo vgcreate vg_data /dev/sdb sudo lvcreate -L 200G -n lv_media vg_data sudo mkfs.ext4 /dev/vg_data/lv_media sudo mkdir -p /srv/media sudo mount /dev/vg_data/lv_media /srv/media
Після цього варто отримати UUID і додати запис у
/etc/fstab
через блочний пристрій LVM, а не через фізичний диск. Якщо том потрібен для Docker, VM-образів або backup, краще одразу виносити його в окремий logical volume. Це спрощує подальше розширення і зменшує радіус ураження при помилках.
Як розширити логічний том без простою
Найцінніший сценарій для LVM Linux – розширення тому на живій системі. Якщо у volume group є вільне місце, logical volume збільшується за кілька команд, а потім дорощується файлова система. Для ext4 і XFS це стандартна операція, але порядок дій відрізняється при зменшенні.
Спочатку треба подивитися, чи є free extents у volume group:
sudo vgs sudo lvs sudo pvs
Якщо місце є, логічний том можна розширити так:
sudo lvextend -L +100G /dev/vg_data/lv_media sudo resize2fs /dev/vg_data/lv_media
Для XFS замість resize2fs використовується зростання змонтованої файлової системи через точку монтування:
sudo lvextend -L +100G /dev/vg_data/lv_media sudo xfs_growfs /srv/media
Якщо вільного місця немає, додається новий диск:
sudo pvcreate /dev/sdc sudo vgextend vg_data /dev/sdc
Після цього том розширюється звичайним способом. На практиці саме тут LVM економить найбільше часу: не треба переносити дані вручну лише тому, що один розділ виріс швидше за інші.
Як замінити диск і перенести дані всередині VG
LVM вміє переносити extents з одного physical volume на інший. Це зручно, коли старий диск треба вивести з сервера без міграції всього тома. Ключова команда тут – pvmove. Вона не магічна, але дозволяє замінити носій набагато акуратніше, ніж ручне копіювання з простоєм сервісів.
Типовий порядок такий:
- Додати новий диск у volume group.
- Перенести дані зі старого physical volume.
- Виключити старий диск з group.
sudo pvcreate /dev/sdc sudo vgextend vg_data /dev/sdc sudo pvmove /dev/sdb /dev/sdc sudo vgreduce vg_data /dev/sdb sudo pvremove /dev/sdb
Нетривіальний момент тут такий: pvmove сильно залежить від стану I/O і може тягнутися довго на перевантажених вузлах з VM або контейнерами. На слабких homelab-серверах це не проблема функціональності, а проблема latency. Саме тому перенесення краще не запускати під час backup-вікна або масового запису.
Чому зменшення тому – найнебезпечніший крок
Розширення в LVM Linux зазвичай безпечніше, ніж зменшення. Причина проста: при shrink треба спочатку зменшити файлову систему, і тільки потім – logical volume. Якщо переплутати порядок, нижній шар стане меншим за дані, які на ньому вже лежать.
Для ext4 схема така:
sudo umount /srv/media sudo e2fsck -f /dev/vg_data/lv_media sudo resize2fs /dev/vg_data/lv_media 150G sudo lvreduce -L 150G /dev/vg_data/lv_media sudo mount /dev/vg_data/lv_media /srv/media
З XFS історія інша: штатне зменшення файлової системи не підтримується. І це одна з причин, чому окремі XFS-томи під швидко зростаючі дані зручні, а під експерименти з перерозподілом диска – вже не дуже. Якщо shrink потенційно знадобиться, ext4 у такому сценарії часто практичніший.
Перевірка після змін: що дивитись насправді
Після будь-яких маніпуляцій з LVM перевірка не зводиться до того, що том змонтувався. Треба звірити стан physical volumes, volume group, logical volumes, розмір файлової системи і реальну точку монтування. Інакше можна пропустити ситуацію, де LV виріс, а filesystem – ні.
sudo pvs sudo vgs sudo lvs -a -o +devices lsblk -f df -h
Особливо корисний вивід
lvs -a -o +devices
. Він показує, на яких дисках реально лежить logical volume. Це швидко ловить конфігурації, де дані вже розподілені між кількома носіями, хоча це не планувалося.
Після переносу або shrink має сенс також перевірити автозавантаження, перезмонтування після reboot і журнали systemd. Часто проблема не в самому LVM, а в старому записі fstab або зміні UUID після переформатування.
Помилки, які ламають LVM у homelab
Найчастіше LVM Linux ламають не команди, а неправильні очікування. Люди сприймають volume group як щось на кшталт безпечного пулу, а потім дивуються, що втрата одного диска виносить весь logical volume. Якщо дані розкладені по кількох PV, поломка будь-якого з них стає проблемою всього LV.
- Зменшення LV до shrink файлової системи.
- Використання одного VG для всього підряд – root, VM, backups, media.
- Відсутність резерву вільного місця у volume group.
- Запуск pvmove під піковим навантаженням.
- Віра в те, що snapshot замінює backup.
Окремо про snapshots. У LVM вони корисні для коротких технічних вікон, наприклад перед ризикованим оновленням або узгодженим backup-процесом. Але довго жити з ними небажано: при активному записі вони роздуваються, додають I/O overhead і в маленькому homelab швидко перетворюються на сюрприз з нестачею місця.
Коли LVM вже не найкращий вибір
LVM добре закриває задачу керування блоковим простором. Але якщо потрібні checksums, наскрізна перевірка цілісності, вбудовані snapshots іншого класу або реплікація, дивитися треба ширше. У таких сценаріях чистий LVM Linux часто стає проміжним шаром, а не основним інструментом.
Для медіатеки, Docker volumes, каталогів backup або VM-образів у невеликому homelab LVM зазвичай достатньо. Якщо ж вузол росте, а дані стають критичнішими за гнучкість перерозподілу ємності, увага зміщується до ZFS або btrfs. Не через моду, а через іншу модель цілісності даних.
У підсумку LVM найкраще працює там, де треба швидко і контрольовано рухати межі томів. Як тільки від нього починають чекати властивостей файлової системи або RAID, схема стає крихкою. Офіційна документація LVM доступна на сайті LVM2.