LVM srozumitelně: logické svazky, snapshoty — a co dělat, když se LVM rozpadne

Odpověď hned: Při obnově dat z LVM nerozhoduje rychlost, ale pořadí kroků. Nejdřív zastavte zápis a zjistěte, ve které vrstvě je závada — chybí fyzický disk, PV hlavička, metadata VG, thin pool, nebo jen neprojde souborový systém? Když disk hlásí I/O chyby, pracujte výhradně nad sektorovou kopií: vgcfgrestore umí vrátit mapování LVM, ale nevrátí obsah chybějícího disku ani neopraví metadata thin poolu.

LVM je pro spoustu administrátorů černá skříňka, která se roky tiše chová správně — a v den, kdy přestane, se s ní člověk seznamuje pod tlakem. Tenhle text je zaprvé srozumitelné vysvětlení, co se pod /dev/mapper/ vlastně děje, a zadruhé rozhodovací vodítko pro chvíli, kdy server hlásí Couldn't find device with uuid a vy nevíte, jestli sáhnout po vgcfgrestore, nebo po vypínači.

LVM hlásí chybu: co udělat jako první

Server nenaběhne, chybí datový svazek, nebo vgs vypíše partial. Než začnete něco opravovat:

1. Zastavte zápis na dotčené disky. Odmountujte, co jde odmountovat, a nenechte službu bušit do svazku, který se chová divně.
2. Nerestartujte server opakovaně „na zkoušku”. U odcházející mechaniky je každé roztočení hazard, u virtuálu vám restart může spustit další automatiku.
3. Nespouštějte pvcreate, vgcfgrestore, lvconvert --repair, fsck -y ani xfs_repair, dokud nemáte kopii médií. Všechny čtyři zapisují.
4. Uložte výstupy diagnostiky a systémové logy — ale mimo postižené úložiště.
5. Jakmile se objeví I/O chyby, končí čas na experimenty s LVM a začíná čas na sektorovou kopii. LVM se řeší až nad ní.

U virtuálního serveru zastavte automatické snapshoty a replikaci — všechno, co samo mění obraz disku. U fyzického serveru si poznamenejte sériová čísla disků, porty a pořadí v řadiči, dokud to ještě jde přečíst.

LVM není souborový systém ani záloha. Je to překladová vrstva mezi fyzickým úložištěm a logickými blokovými svazky. Opravovat ji naslepo, bez znalosti původního uspořádání, je jako přepisovat obsah knihy podle poškozeného rejstříku.

Jak LVM funguje, bez zbytečné teorie

Běžné uspořádání linuxového serveru vypadá takhle:

HDD / SSD / RAID / virtuální disk
                │
        PV – Physical Volume
                │
        VG – Volume Group
          ┌─────┴─────┐
          │           │
       LV data     LV systém
          │           │
      ext4/XFS     ext4/XFS
          │
       soubory

Dvě věci z toho plynou a obě jsou v krizi zásadní. Jeden LV může ležet na více discích — ztráta jediného PV proto typicky poškodí několik logických svazků najednou, ne jen ten „na tom vadném disku”. A naopak: chybějící LV vůbec nemusí znamenat zničená data. LVM často jen nenajde zařízení kvůli přejmenování, filtru v lvm.conf, multipathu nebo seznamu zařízení spravovanému přes lvmdevices.

LVM samo o sobě neposkytuje odolnost proti selhání disku — leda byste použili redundantní typ, tedy LVM RAID. Jestli je pod LVM klasický Linux MD RAID nebo hardwarový řadič, musí se nejdřív správně sestavit spodní vrstva; teprve pak má smysl řešit PV a VG. Proč se rebuild degradovaného pole neobejde bez kopie, rozebíráme v článku proč rebuild zabíjí RAID pole, a celý postup u serveru v textu o záchraně dat ze serveru.

Co lidé označují jako „rozpadnuté LVM”

Stejný symptom má několik odlišných příčin — a každá chce jiný postup:

Klíčová je hranice mezi třemi druhy metadat, protože právě tady vzniká většina fatálních omylů:

• Metadata VG popisují PV, LV a jejich mapování.
• Metadata thin poolu evidují, které bloky patří kterému thin svazku.
• Metadata ext4, XFS nebo btrfs popisují soubory a adresáře.

vgcfgrestore sahá jen na první vrstvu. Neopraví thin pool a už vůbec ne souborový systém. Kdo si to neuvědomí, „opraví” LVM a diví se, že svazek pořád nejde připojit.

Bezpečná diagnostika: co si nechat vypsat

Následující příkazy jen čtou stav. Výstup ukládejte mimo postižené úložiště:

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

Hledejte hlavně:

• UUID, které se objevuje v chybové hlášce — a na kterém zařízení (ne)sedí,
• unknown device nebo atribut partial u VG,
• I/O chyby, resety SATA/SAS zařízení a hlášení o vadných blocích v dmesg,
• hodnoty Data% a Meta% u thin poolu,
• typ LV: linear, striped, raid, thin, thin-pool nebo snapshot.

Ten poslední bod rozhoduje o šancích. Chybějící PV pod linear LV znamená díru v datech, ale zbytek svazku může být čitelný. Pod striped LV je rozprostřený každý soubor — chybějící PV znamená, že v každém větším souboru chybí pravidelně se opakující bloky.

Podívejte se taky do /etc/lvm/backup/ a /etc/lvm/archive/. Jsou tam textové zálohy konfigurace VG, které LVM zapisuje automaticky při každé změně. Neobsahují uživatelská data ani metadata thin poolu — jen mapu.

A pozor na jednu věc: má-li disk fyzické chyby, každé další skenování může počet nečitelných sektorů zvyšovat. V takovém případě se čte řízeně, například nástrojem GNU ddrescue, který pracuje s mapovacím souborem a umí v přerušeném čtení pokračovat. Cílem musí být jiný, dostatečně velký disk nebo image. Souvislosti kolem fyzicky poškozených médií rozebírá text jak dostat data z poškozeného HDD.

Rozhodovací postup podle typu závady

Jsou na disku I/O chyby?
├─ ano → sektorová kopie → práce pouze s kopií
└─ ne
   ├─ chybí celý PV → ověřit zařízení, RAID, multipath a UUID
   ├─ PV je vidět, VG ne → prověřit LVM hlavičku a archiv metadat
   ├─ VG je partial → zjistit, které extenty ležely na chybějícím PV
   ├─ thin pool nejde aktivovat → odděleně řešit metadata thin poolu
   └─ LV funguje → kontrolovat souborový systém bez zápisu

Zmizelo zařízení, ale disk je v pořádku

Nejčastější „rozpad LVM”, který žádný rozpad není. Po aktualizaci systému, migraci virtuálního stroje nebo změně na SAN hledá LVM správné UUID na cestě, kde už není. Prověřuje se multipath, filtrace v lvm.conf, seznam zařízení spravovaný přes lvmdevices (výchozí od LVM2 verze 2.03.17) a to, jestli hypervizor vůbec připojil všechny virtuální disky.

Zápis opravné LVM struktury je tady zbytečný a nebezpečný. Data nikam nezmizela — systém jen neprohledává správné zařízení.

Je poškozená LVM hlavička

Existuje-li správná archivní konfigurace, dá se na pracovní kopii obnovit původní PV UUID a pak metadata VG:

pvcreate --uuid <PŮVODNÍ_PV_UUID> \
  --restorefile <SPRÁVNÝ_ARCHIV_VG> <ZAŘÍZENÍ_KOPIE>

vgcfgrestore --file <SPRÁVNÝ_ARCHIV_VG> <NÁZEV_VG>

Obojí zapisuje. Chybné zařízení, špatné UUID nebo archiv z jiného období můžou přepsat právě to, co potřebujete k obnově. Na jediném originálu je nespouštějte.

A hlavně: obnovení hlavičky nevrátí obsah ztraceného disku. Vytvořit PV se stejným UUID na prázdném disku znamená obnovit označení a mapu, ne datové extenty. Mapa bez území.

VG je dostupná jen částečně

Aktivace v režimu partial zpřístupní ty LV, jejichž potřebné extenty přežily. U LV rozprostřeného přes chybějící PV budou některé bloky nečitelné — výsledkem jsou poškozené soubory a další chyby souborového systému.

Pokud je částečná aktivace pro extrakci nutná, dělá se nad kopiemi a svazek se připojuje jen pro čtení, s potlačením přehrání žurnálu: ext4 přes ro,noload, XFS přes ro,norecovery. Samotné mount -o ro u některých souborových systémů zápis do žurnálu nezastaví.

Snapshot není záloha

Klasický LVM snapshot si ukládá původní podobu bloků, které se po jeho vytvoření změnily — takzvaný copy-on-write. Jakmile vyhrazený COW prostor dojde, snapshot se stane neplatným. Původní LV to samo o sobě neničí, ale snapshot už jako bod obnovy nepoužijete.

Thin snapshoty fungují jinak: sdílejí bloky v thin poolu a závisí na jeho datové i metadatové kapacitě. Metadata LV thin poolu bývá řádově malé proti datové části — a jeho poškození nebo zaplnění může zasáhnout obrovský objem dat naráz. To je ten nepříjemný nepoměr, kvůli kterému má smysl hlídat Meta% stejně pečlivě jako Data%.

Ke kontrole metadat thin poolu slouží thin_check a thin_dump z balíku nástrojů device-mapperu. Příkaz:

lvconvert --repair <VG>/<THIN_POOL>

sestaví opravenou kopii metadat a při úspěchu ji nasadí místo původní. Je to změnová operace. Patří na kopii úložiště, ne na jediný produkční exemplář. A ani úspěšně vrácený pool nezaručuje, že jsou souborové systémy uvnitř thin svazků konzistentní.

Ještě jedna past: vgcfgbackup metadata thin poolu nezálohuje. Proto samotný soubor z /etc/lvm/archive/ u thin provisioningu nestačí — máte mapu VG, ale ne mapu bloků uvnitř poolu.

Kdy už obnovu nedělat svépomocí

Profesionální zásah dává smysl, pokud:

• některý disk hlásí I/O chyby nebo se odpojuje,
• VG stojí na více PV a jeden chybí,
• pod LVM je rozpadlý RAID,
• nevíte, který archiv metadat odpovídá poslední funkční konfiguraci,
• jde o thin pool s poškozenými metadaty,
• někdo už stihl spustit pvcreate, vgcfgrestore, lvconvert --repair nebo opravu souborového systému,
• data mají vyšší hodnotu než odstávka a pokusy metodou pokus–omyl.

Cena se neurčuje podle kapacity LV, ale podle vrstvy závady, počtu médií, jejich fyzického stavu a toho, kolik mapování je nutné rekonstruovat. Rozumná nabídka odděluje diagnostiku, práci s vadnými médii, rekonstrukci LVM a cílové úložiště pro zachráněná data. Obecný rozbor cenotvorby najdete v článku kolik stojí záchrana dat z disku.

Poznávací znamení dobrého dodavatele: nejdřív vytváří kopie, umí vysvětlit pořadí RAID → LVM → thin pool → souborový systém a zapisuje výhradně do pracovních obrazů. Před obnovou si nechte potvrdit zacházení s daty, možnost NDA, způsob předání a to, jestli dostanete seznam skutečně ověřených souborů — ne jen faktu­ru za „pokus”.

Jak snížit riziko dalšího rozpadu

• Zálohujte /etc/lvm/backup/, /etc/lvm/archive/ a výstupy pvs, vgs a lvs mimo daný server. Textový soubor o pár kilobajtech může rozhodnout o tom, jestli je rekonstrukce hodina, nebo týden.
• Sledujte kapacitu VG i hodnoty Data% a Meta% thin poolu — zaplněný thin pool není varování, je to výpadek.
• Nenahrazujte zálohu snapshotem. Snapshot leží ve stejné VG a padá s ní.
• Testujte obnovu souborů na jiný server, ne na ten původní.
• Evidujte vrstvy úložiště: řadič, RAID, šifrování LUKS, PV, VG, LV a souborový systém. Až to bude hořet, nebudete si to pamatovat.
• Uchovávejte recovery klíče a konfiguraci šifrování odděleně od serveru — u zašifrovaného svazku bez klíče nepomůže ani perfektně obnovené LVM.
• U virtuálních serverů zálohujte i konfiguraci virtuálních disků, nejen obsah operačního systému.

Časté dotazy

Lze obnovit LVM bez souboru z /etc/lvm/backup/?

Někdy ano. Kopie metadat VG se ukládají i do metadata oblasti dostupných PV a dají se z nich vyčíst nástroji LVM. Bez správné mapy je ale rekonstrukce výrazně rizikovější — zvlášť u více disků a striped LV, kde záleží na pořadí a offsetech.

Smaže pvcreate data?

Běžné použití zapíše nové LVM hlavičky a metadata, tedy přepíše označení svazku. Recovery varianta s přesným UUID a správným --restorefile je určená přímo k rekonstrukci PV, ale při chybné konfiguraci může obnovu poškodit. Na jediném originálu ji nespouštějte.

Mohu použít fsck, když LV nejde připojit?

Nejdřív ověřte, že je LV úplný a správně namapovaný. fsck opravuje souborový systém, ne LVM. Nad neúplným LV umí odstranit odkazy na data, která jen momentálně nejsou dostupná — a tím z dočasného problému udělá trvalý.

Co znamená Volume group is missing PV?

VG očekává fyzický svazek s konkrétním UUID, který LVM nevidí. Příčinou bývá vadný disk, rozpadlý RAID, nepřipojený virtuální disk, změna multipathu nebo poškozená PV hlavička. Než začnete zapisovat, zjistěte, která z těch pěti možností to je.

Zachrání data LVM snapshot?

Snapshot vrátí starší stav bloků, dokud zůstane platný a dokud funguje podkladové úložiště. Nechrání před ztrátou disků, poškozením celé VG ani selháním thin poolu — proto nenahrazuje oddělenou zálohu.