Відповідь одразу: У відновленні даних з LVM вирішує не швидкість, а порядок кроків. Спершу зупиніть запис і з’ясуйте, на якому рівні стався збій — відсутній фізичний диск, заголовок PV, метадані VG, thin pool, чи просто не монтується файлова система? Якщо диск видає помилки вводу-виводу (I/O), працюйте виключно з посекторною копією:
vgcfgrestoreвміє повернути мапування LVM, але не поверне вміст відсутнього диска і не виправить метадані thin pool.
Для багатьох адміністраторів LVM — це чорна скринька, яка роками мовчки поводиться правильно, а в той день, коли перестає, доводиться знайомитися з нею під тиском. Цей текст — по-перше, зрозуміле пояснення того, що насправді відбувається під /dev/mapper/, і по-друге, орієнтир для прийняття рішень у момент, коли сервер видає Couldn't find device with uuid, а ви не знаєте, чи братися за vgcfgrestore, чи за вимикач.
LVM видає помилку: що зробити насамперед
Сервер не завантажується, зник дисковий том, або vgs видає partial. Перш ніж щось виправляти:
- Зупиніть запис на постраждалі диски. Відмонтуйте все, що можна відмонтувати, і не давайте службі стукати в том, який поводиться дивно.
- Не перезавантажуйте сервер повторно «про всяк випадок». Для механіки, що відходить, кожне розкручування — це ризик, а для віртуальної машини перезавантаження може запустити додаткову автоматику.
- Не запускайте
pvcreate,vgcfgrestore,lvconvert --repair,fsck -yчиxfs_repair, поки не маєте копії носіїв. Усі чотири виконують запис. - Збережіть результати діагностики та системні логи — але поза постраждалим сховищем.
- Щойно з’являються помилки I/O, час на експерименти з LVM закінчується і настає час для посекторної копії. LVM вирішується вже над нею.
На віртуальному сервері зупиніть автоматичні знімки та реплікацію — усе, що саме змінює образ диска. На фізичному сервері запишіть серійні номери дисків, порти та порядок у контролері, поки це ще можна прочитати.
LVM — це не файлова система і не резервна копія. Це прошарок трансляції між фізичним сховищем і логічними блоковими томами. Виправляти його наосліп, не знаючи початкової структури, — все одно що переписувати зміст книги за пошкодженим покажчиком.
Як працює LVM, без зайвої теорії
Типова структура linux-сервера виглядає так:
HDD / SSD / RAID / віртуальний диск
│
PV – Physical Volume
│
VG – Volume Group
┌─────┴─────┐
│ │
LV дані LV система
│ │
ext4/XFS ext4/XFS
│
файли| Рівень | Що являє собою | Типовий приклад |
|---|---|---|
| Фізичний пристрій | Диск, RAID або віртуальний диск | /dev/sdb, /dev/md0, /dev/mapper/mpatha |
| PV | Пристрій, позначений для LVM | /dev/sdb2 |
| VG | Спільний простір, складений з одного чи кількох PV | vg_server |
| LV | Логічний блоковий том, створений у VG | vg_server/data |
| Файлова система | Структура файлів усередині LV | ext4, XFS, btrfs |
З цього випливають дві речі, і обидві є критично важливими в кризовій ситуації. Один LV може лежати на кількох дисках — тому втрата єдиного PV зазвичай пошкоджує одразу кілька логічних томів, а не лише той «на несправному диску». І навпаки: відсутність LV зовсім не обов’язково означає знищені дані. LVM часто просто не знаходить пристрій через перейменування, фільтр у lvm.conf, multipath або список пристроїв, керований через lvmdevices.
LVM саме по собі не забезпечує стійкості до відмови диска — хіба що ви використовуєте резервований тип, тобто LVM RAID. Якщо під LVM лежить класичний Linux MD RAID або апаратний контролер, спершу потрібно правильно зібрати нижній рівень; лише тоді має сенс займатися PV та VG. Чому відновлення (rebuild) деградованого масиву не обійдеться без копії, ми розбираємо в статті чому rebuild вбиває RAID-масив, а весь порядок дій для сервера — у тексті про порятунок даних із сервера.
Що люди називають «розваленим LVM»
Той самий симптом може мати кілька різних причин — і кожна вимагає іншого підходу:
| Прояв | Ймовірна область проблеми |
|---|---|
| VG взагалі не відображається | Відсутній PV, пошкоджений заголовок LVM, фільтр пристроїв |
VG у стані partial | Один або кілька PV недоступні |
| LV існує, але не активується | Відсутні екстенти, пошкоджений thin pool або конфлікт UUID |
| LV активується, але не монтується | Проблема файлової системи, не обов’язково LVM |
| Thin pool видає помилку метаданих | Пошкоджені метадані thin provisioning |
Знімок у стані Invalid | Заповнився виділений COW-простір класичного знімка |
| Після міграції зникли диски | Змінилися шляхи, multipath або список дозволених пристроїв |
| Після клонування є дублікати PV | Оригінал і клон з однаковим LVM UUID одночасно висять у системі |
Ключовою є межа між трьома видами метаданих, адже саме тут виникає більшість фатальних помилок:
- Метадані VG описують PV, LV та їхнє мапування.
- Метадані thin pool фіксують, які блоки належать якому thin-тому.
- Метадані ext4, XFS чи btrfs описують файли та каталоги.
vgcfgrestore торкається лише першого рівня. Він не виправить thin pool і тим більше не виправить файлову систему. Хто цього не усвідомлює, «виправляє» LVM і дивується, що том усе одно не монтується.
Безпечна діагностика: що варто вивести
Наведені нижче команди лише читають стан. Зберігайте вивід поза постраждалим сховищем:
lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MODEL,SERIAL
blkid
pvs -o pv_name,pv_uuid,vg_name,pv_size,pv_free,pv_attr,devices
vgs -o vg_name,vg_uuid,vg_attr,vg_size,vg_free,pv_count
lvs -a -o lv_name,vg_name,lv_uuid,lv_attr,segtype,devices,data_percent,metadata_percent
dmesg -TНасамперед шукайте:
- UUID, який фігурує в повідомленні про помилку, — і на якому пристрої він (не) збігається,
unknown deviceабо атрибутpartialу VG,- помилки I/O, скидання (reset) пристроїв SATA/SAS та повідомлення про пошкоджені блоки в
dmesg, - значення
Data%іMeta%у thin pool, - тип LV:
linear,striped,raid,thin,thin-poolабоsnapshot.
Саме останній пункт визначає шанси. Відсутній PV під LV типу linear означає діру в даних, але решта тому може бути читабельною. У LV типу striped кожен файл розподілений по дисках — відсутній PV означає, що в кожному більшому файлі регулярно бракує повторюваних блоків.
Загляньте також у /etc/lvm/backup/ та /etc/lvm/archive/. Там зберігаються текстові резервні копії конфігурації VG, які LVM автоматично записує при кожній зміні. Вони не містять користувацьких даних чи метаданих thin pool — лише мапу.
І зверніть увагу на одну річ: якщо диск має фізичні пошкодження, кожне наступне сканування може збільшувати кількість нечитабельних секторів. У такому разі читання виконується контрольовано, наприклад інструментом GNU ddrescue, який працює з мап-файлом і вміє продовжувати перерване читання. Метою повинен бути інший, достатньо великий диск або образ (image). Контекст навколо фізично пошкоджених носіїв розбирає текст як дістати дані з пошкодженого HDD.
Порядок прийняття рішень залежно від типу несправності
Чи є на диску помилки I/O?
├─ так → посекторна копія → робота лише з копією
└─ ні
├─ відсутній весь PV → перевірити пристрій, RAID, multipath і UUID
├─ PV видно, VG ні → перевірити заголовок LVM і архів метаданих
├─ VG у стані partial → з'ясувати, які екстенти лежали на відсутньому PV
├─ thin pool не активується → окремо вирішувати метадані thin pool
└─ LV працює → перевіряти файлову систему без записуЗник пристрій, але диск справний
Найчастіший «розвал LVM», який насправді не є розвалом. Після оновлення системи, міграції віртуальної машини чи зміни в SAN LVM шукає правильний UUID за шляхом, якого вже немає. Перевіряється multipath, фільтрація в lvm.conf, список пристроїв, керований через lvmdevices (за замовчуванням від LVM2 версії 2.03.17), і те, чи гіпервізор взагалі підключив усі віртуальні диски.
Запис «виправної» LVM-структури тут зайвий і небезпечний. Дані нікуди не зникли — система просто не шукає на правильному пристрої.
Пошкоджений заголовок LVM
Якщо існує правильна архівна конфігурація, на робочій копії можна відновити початковий PV UUID, а потім метадані VG:
pvcreate --uuid <ОРИГІНАЛЬНИЙ_PV_UUID> \
--restorefile <ПРАВИЛЬНИЙ_АРХІВ_VG> <ПРИСТРІЙ_КОПІЇ>
vgcfgrestore --file <ПРАВИЛЬНИЙ_АРХІВ_VG> <НАЗВА_VG>Обидві команди виконують запис. Неправильний пристрій, хибний UUID або архів з іншого періоду можуть перезаписати саме те, що потрібно для відновлення. Не запускайте це на єдиному оригіналі.
І головне: відновлення заголовка не поверне вміст втраченого диска. Створити PV з тим самим UUID на порожньому диску означає відновити позначення й мапу, а не дискові екстенти з даними. Мапа без території.
VG доступна лише частково
Активація в режимі partial робить доступними ті LV, чиї необхідні екстенти вціліли. У LV, розподіленому по відсутньому PV, деякі блоки будуть нечитабельними — результатом стають пошкоджені файли та інші помилки файлової системи.
Якщо часткова активація необхідна для вилучення даних, вона виконується над копіями, а том монтується лише для читання, з придушенням відтворення журналу: для ext4 через ro,noload, для XFS через ro,norecovery. Саме mount -o ro у деяких файлових системах не зупиняє запис у журнал.
Знімок (snapshot) — це не резервна копія
Класичний знімок LVM зберігає початковий вигляд блоків, які змінилися після його створення, — так званий copy-on-write. Щойно виділений COW-простір вичерпається, знімок стає недійсним. Сам початковий LV це не знищує, але знімок уже не можна використати як точку відновлення.
Thin-знімки працюють інакше: вони поділяють блоки в thin pool і залежать від його дискової та метаданої ємності. LV метаданих thin pool зазвичай на порядок менший за дискову частину — і його пошкодження чи заповнення може одразу вплинути на величезний обсяг даних. Це та неприємна диспропорція, через яку має сенс стежити за Meta% так само уважно, як за Data%.
Для перевірки метаданих thin pool служать thin_check і thin_dump з пакета інструментів device-mapper. Команда:
lvconvert --repair <VG>/<THIN_POOL>складає виправлену копію метаданих і в разі успіху розгортає її замість початкової. Це операція, що вносить зміни. Її місце — на копії сховища, а не на єдиному продуктивному екземплярі. І навіть успішно відновлений pool не гарантує, що файлові системи всередині thin-томів залишаються узгодженими.
Ще одна пастка: vgcfgbackup не резервує метадані thin pool. Тому для thin provisioning самого файлу з /etc/lvm/archive/ недостатньо — у вас є мапа VG, але немає мапи блоків усередині pool.
Коли відновлення вже не варто робити самотужки
Професійне втручання має сенс, якщо:
- якийсь диск видає помилки I/O або відключається,
- VG стоїть на кількох PV, і один із них відсутній,
- під LVM розвалений RAID,
- ви не знаєте, який архів метаданих відповідає останній робочій конфігурації,
- йдеться про thin pool з пошкодженими метаданими,
- хтось уже встиг запустити
pvcreate,vgcfgrestore,lvconvert --repairабо виправлення файлової системи, - дані мають вищу цінність, ніж простій і спроби методом проб і помилок.
Вартість визначається не за обсягом LV, а за рівнем несправності, кількістю носіїв, їхнім фізичним станом і тим, скільки мапувань потрібно реконструювати. Розумна пропозиція розділяє діагностику, роботу з пошкодженими носіями, реконструкцію LVM і цільове сховище для врятованих даних. Загальний розбір ціноутворення знайдете в статті скільки коштує порятунок даних з диска.
Ознака гарного постачальника: спершу створює копії, вміє пояснити порядок RAID → LVM → thin pool → файлова система і виконує запис виключно в робочі образи. Перед відновленням попросіть підтвердити порядок поводження з даними, можливість NDA, спосіб передачі та те, чи отримаєте ви список дійсно перевірених файлів — а не просто рахунок за «спробу».
Як знизити ризик наступного розвалу
- Резервуйте
/etc/lvm/backup/,/etc/lvm/archive/та вивідpvs,vgsіlvsпоза цим сервером. Текстовий файл на кілька кілобайт може визначити, чи буде реконструкція годиною роботи, чи тижнем. - Стежте за ємністю VG і значеннями
Data%таMeta%thin pool — заповнений thin pool це не попередження, а вже збій. - Не замінюйте резервну копію знімком. Знімок лежить у тій самій VG і падає разом із нею.
- Тестуйте відновлення файлів на іншому сервері, а не на початковому.
- Ведіть облік рівнів сховища: контролер, RAID, шифрування LUKS, PV, VG, LV і файлова система. Коли це загориться, ви цього не пам’ятатимете.
- Зберігайте ключі відновлення (recovery) та конфігурацію шифрування окремо від сервера — для зашифрованого тому без ключа не допоможе навіть ідеально відновлений LVM.
- На віртуальних серверах резервуйте також конфігурацію віртуальних дисків, а не лише вміст операційної системи.
Часті запитання
Чи можна відновити LVM без файлу з /etc/lvm/backup/?
Іноді так. Копії метаданих VG зберігаються також у зоні метаданих доступних PV, і їх можна прочитати інструментами LVM. Але без правильної мапи реконструкція значно ризикованіша — особливо при кількох дисках і LV типу striped, де важливі порядок і зсуви (offsets).
Чи видаляє pvcreate дані?
Звичайне використання записує нові заголовки та метадані LVM, тобто перезаписує позначення тому. Recovery-варіант з точним UUID і правильним --restorefile призначений саме для реконструкції PV, але при неправильній конфігурації може пошкодити відновлення. Не запускайте його на єдиному оригіналі.
Чи можу я використати fsck, якщо LV не монтується?
Спершу переконайтеся, що LV повний і правильно замапований. fsck виправляє файлову систему, а не LVM. На неповному LV він може видалити посилання на дані, які лише тимчасово недоступні, — і тим самим перетворити тимчасову проблему на постійну.
Що означає Volume group is missing PV?
VG очікує фізичний том з конкретним UUID, якого LVM не бачить. Причиною зазвичай буває несправний диск, розвалений RAID, непідключений віртуальний диск, зміна multipath або пошкоджений заголовок PV. Перш ніж починати запис, з’ясуйте, який із цих п’яти варіантів це насправді.
Чи врятує дані знімок LVM?
Знімок повертає попередній стан блоків, доки залишається дійсним і доки працює базове сховище. Він не захищає від втрати дисків, пошкодження всієї VG чи відмови thin pool — тому не замінює окрему резервну копію.