pingvin1.jpg

Linuxos gép mentése és klónozása LVM Snapshot használatával

Írta: Torig on . Beküldve: Linuxos dolgok

A napi informatikai üzemeltetési feladatok egyik leghangsúlyosabb része a mentések elkészítése. Ha van mentésed, akkor biztonságban vagy. Legalábbis azt hiszed, mert csak akkor vagy biztonságban, ha a mentésedből vissza is tudsz állítani. Az a mentés amiből sosem készítettél helyreállítási tesztet, az egy fabatkát sem ér. Fájlokról, adatokról viszonylag egyszerű mentést készíteni. Kicsit leegyszerűsítve csak annyi a feladat, hogy valamilyen módon készítesz egy másolatot az adatokról és azokat jól elrakod valami biztos helyre és már kész is vagy. De mi a helyzet egy éles rendszerrel? Mi van akkor amikor egy futó rendszerről kell olyan mentést készítened, amit bármikor vissza tudsz állítani egy szűz vasra? Vagy mi van akkor, ha klónoznod kell egy gépet? Urambocsá' virtualizálni kell egy fizikai vasat. Vagy fordítva. Egy virtuálgépből kell fizikai vasra migrálni egy rendszert. Ebben a cikkben ezekre a problémákra mutatok egy lehetséges megoldást.

Feladat a következő. Van egy szerverünk amit nem állíthatunk le. Konzisztens mentést kell készíteni a teljes gépről a gép leállítása nélkül, mégpedig oly módon, hogy az elkészített mentést bármikor vissza lehessen állítani egy szűz gépre, vagy virtuálgépre. A mentésnek az adatokon felül a teljes működő rendszert is tartalmaznia kell.

A cikkben bemutatott módszer Ubuntu Linux 12.04 LTS rendszeren lett kidolgozva!

A nehézséget az okozza, hogy futó rendszer esetén nagyon nehéz konzisztens mentést készíteni. Ha le lehetne állítani a gépet, akkor viszonylag egyszerű lenne a dolgunk. Egy boot lemezzel bebootolva felcsatolnánk a partíciókat és azokról fájl szintű mentést készítenénk. Ezzel csak annyi a probléma, hogy ettől még a lementett adatokból nem egyszerű indítható gépet varázsolni. Továbbá mi van akkor, ha a gépet nem lehet leállítani tíz percre sem, nemhogy egy fél napra? Ha előrelátó voltál, akkor nincs probléma, mert segít, ha a szerver kiépítésekor a jövőre gondolva rugalmas kötetkezelő megoldásként LVM-et használtunk. Ha nincs LVM, akkor nehezebb dolgunk van. Most ebben a cikkben LVM-es megoldást fogom bemutatni.

Az itt bemutatott megoldás csak akkor működőképes, ha LVM kötetek vannak a merevlemezen és van a lemezen mentéshez szükséges üres tárterület. Ha nincs üres terület, akkor az LVM megfelelő bővítésével meg lehet oldani a feladatot, de erre most itt nem térek ki. Maradjunk annyiban, hogy példámban, van LVM és van elegendő üres tárterület is.

Az LVM-ről nagyon röviden

Mire jó az LVM? Azért jó mert rugalmas. Számos lehetőséget biztosít, hogy utólag, vagy menet közben módosítsuk a kötetek konfigurációját. A teljesség igénye nélkül. Az LVM-el felépített kötetek bármikor átméretezhetőek. Növelhető, csökkenthető igény szerint. Össze lehet vele fűzni több merevlemezt úgy mintha egy kötet lenne. Utólag hozzá lehet adni a kötetekhez tárterületet, vagy éppen el lehet venni belőle. Pl elfogy a hely a /var köteten, de nincs gond, mert a /home alatt bőven áll még rendelkezésre felhasználatlan terület. Akkor a /home alól el lehet venni területet és át lehet adni a /var-nak. Az LVM kötetek bármikor átméretezhetőek. Az LVM egyik kellemes szolgáltatása, hogy egyszerűen lehet egy létező kötetről tükörképet úgynevezett Snapshotot készíteni. Ebben a leírásban az LVM Snapshot lehetőségét felhasználva mutatom be a rendszer mentésének vagy klónozásának lehetőségét.

A rendszer felmérése

Első lépésként lépj be egy terminálon, aztán válts át rendszergazdai konzolra.

sudo su

Fel kell mérni az éles rendszer lemezeit. Meg kell határozni, hogy mekkora tárterületre van szükség a mentések létrehozásához.

root@teszt:/# df -h
Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
/dev/mapper/szerver_vg-root_lv 11G 4,2G 6,6G 39% /

udev 746M 4,0K 746M 1% /dev
tmpfs 302M 376K 301M 1% /run
none 5,0M 0 5,0M 0% /run/lock
none 754M 0 754M 0% /run/shm
/dev/mapper/szerver_vg-tmp_lv 3,8G 33M 3,7G 1% /tmp
/dev/mapper/szerver_vg-boot_lv 948M 216M 732M 23% /boot
/dev/mapper/szerver_vg-home_lv 3,8G 83M 3,7G 3% /home
/dev/mapper/szerver_vg-usr_lv 3,8G 1,3G 2,5G 33% /usr
/dev/mapper/szerver_vg-var_lv 38G 9,5G 28G 26% /var
/dev/mapper/szerver_vg-var_log_lv 3,8G 112M 3,7G 3% /var/log

A fenti lekérdezésből a következőt tudjuk megállapítani. Látszik, hogy mekkora partíciók vannak és azok mennyi adatot tartalmaznak, valamint látszik az egyes partíciók csatolási pontja.

Listázzuk ki a logikai köteteket (Logical Volume - LV) is.

root@teszt:/# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
boot_lv szerver_vg -wi-ao 952,00m
home_lv szerver_vg -wi-ao 3,72g
root_lv szerver_vg -wi-ao 10,72g
swap_lv szerver_vg -wi-ao 3,72g
tmp_lv szerver_vg -wi-ao 3,72g
usr_lv szerver_vg -wi-ao 3,72g
var_log_lv szerver_vg -wi-ao 3,72g
var_lv szerver_vg -wi-ao 37,25g

A fenti lekérdezésből látható az LVM kötetek mérete és kihasználtsága.

Kérdezzük le az Volume Grouppot (VG).

root@teszt:/# vgdisplay
--- Volume group ---
VG Name szerver_vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 29
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 8
Open LV 8
Max PV 0
Cur PV 1
Act PV 1
VG Size 148,87 GiB
PE Size 4,00 MiB
Total PE 38111
Alloc PE / Size 17284 / 67,52 GiB
Free PE / Size 20827 / 81,36 GiB
VG UUID UXBkg4-f3rO-rfPS-dM0b-KvYu-r82M-Vk4log

Látható, hogy a kötetek a szerver_vg Volume Groupban (VG) vannak. Látható a VG mérete, és hogy mennyi terület van belőle felhasználva. Azt is látható, hogy van elegendő kihasználatlan terület a VG-ben. Itt kell majd létrehozni az LVM Snapshotokat.

LVM Snapshot készítés az éles rendszerről

Fontos! Csak akkor tudsz Snapshotot készíteni a partíciókról, ha a Volume Groupban (VG) rendelkezésre áll a Snapshotok létrehozásához szükséges terület. Ezt úgy tudod biztosítani, hogy a rendszer tervezésekor és kiépítésekor kalkulálsz a Sanpshotok létrehozásának lehetőségével és a VG-ben hagysz megfelelő üres területet. Ha nincs elegendő területed. akkor utólag hozzá lehet adni a VG-hez lemezeket. Ezzel a lehetőséggel  itt most nem foglalkozom. Ha erre van szükséged, nézz utána, hogy tudod megcsinálni. Példámban előrelátó módon maradt üres terület a VG-ben, így nincs akadálya a Snapshotok létrehozásának. Ökölszabály, hogy a létrehozott snapshot mérete nem lehet kisebb mint a partíción lévő adatok mérete. Továbbá minden LV-ről külön Snapshotot kell készíteni. A felmérés során mért értékek figyelembe vételével hozd létre a Snapshotokat! A Sanpshot mérete legalább akkora kell legyen, mint amennyi adatot tartalmaznak. A fenti adatok alapján lássunk egy példát.

A /dev/mapper/szerver_vg-home_lv 3,8G méretű és ebből csak 83M adatot tartalmaz, tehát a Snapshot méretére elegendő 100 Mb-ot megadni. Legjobb, ha az adatok 1,2-szeresét adjuk meg méretnek a következő módon.

lvcreate -s -n backup_NÉV -L MÉRET /dev/VGNÉV/LVNÉV

A parancs magyarázata. Hozz létre egy lvm sanpshotot, backup_NÉV néven, -L mérettel, erről a VG-ben lévő LV kötetről.

Az LVM Snapshotnak megvan az a jó tulajdonsága, hogy segítségével gyakorlatilag elkészíthetjük a partíció tükörképét. Az elkészített tükörkép azt a pillanatot fogja tükrözni, amikor kiadtuk a parancsot. Mintegy befagyasztjuk azt az állapotot, amiben az adott partíció abban a pillanatban van. Ettől lesz a mentésünk konzisztens. Sok adatot tartalmazó kötetek esetén egy kis időt vehet igénybe az adatok szinkronizálása az éles kötet és a Snapshot között.

Hozzuk létre a mentéshez szükséges Snapshotokat. A példában szereplő szerveren az egyes rendszer könyvtárak külön köteteken vannak elhelyezve. A kötetek kialakítása szerverenként eltérő lehet.

lvcreate -s -n bck_boot_lv -L 500M /dev/szerver_vg/boot_lv
lvcreate -s -n bck_home_lv -L 200M /dev/szerver_vg/home_lv
lvcreate -s -n bck_root_lv -L 6G /dev/szerver_vg/root_lv
lvcreate -s -n bck_usr_lv -L 2G /dev/szerver_vg/usr_lv
lvcreate -s -n bck_var_log_lv -L 1G /dev/szerver_vg/var_log_lv
lvcreate -s -n bck_var_lv -L 11G /dev/szerver_vg/var_lv

Megjegyzés. A TMP és SWAP kimarad, mert nincs benne értékelhető adat. Arról nem készítünk mentést.

Kérdezzük le az lvs paranccsal az LVM köteteket. Ellenőrizzük, hogy minden szükséges kötet létrejött-e.

root@teszt:/# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
bck_boot_lv szerver_vg swi-a- 500,00m boot_lv 0,00
bck_home_lv szerver_vg swi-a- 200,00m home_lv 0,01
bck_root_lv szerver_vg swi-a- 6,00g root_lv 0,01
bck_usr_lv szerver_vg swi-a- 2,00g usr_lv 0,00
bck_var_log_lv szerver_vg swi-a- 1,00g var_log_lv 0,01
bck_var_lv szerver_vg swi-a- 11,00g var_lv 0,00
boot_lv szerver_vg owi-ao 952,00m
home_lv szerver_vg owi-ao 3,72g
root_lv szerver_vg owi-ao 10,72g
swap_lv szerver_vg -wi-ao 3,72g
tmp_lv szerver_vg -wi-ao 3,72g
usr_lv szerver_vg owi-ao 3,72g
var_log_lv szerver_vg owi-ao 3,72g
var_lv szerver_vg owi-ao 37,25g

Minden Snapshot kötet létrejött. Készíteni kell egy mount pontot minden egyes kötethez, amibe fel kell csatolni a Sanpshotokat. A mount pont könyvtárait az /mnt alá hozzuk létre. Persze megadhatunk bármely más könyvtárat is, lényeg, hogy a csatoláshoz a könyvtárnak léteznie kell.

cd /mnt
mkdir bck_boot_lv
mkdir bck_home_lv

mkdir bck_root_lv
mkdir bck_usr_lv
mkdir bck_var_log_lv
mkdir bck_var_lv

Ahhoz, hogy az adatok szinkronizálva legyenek az LVM Snapshotokat fel kell csatolni. Itt megjegyzem, hogy a minta szerveren XFS fájlrendszert használok, ezért szükséges az XFS mountolásához a -onouuid,ro paraméter. Sima ext4 fájlrendszer esetén elegendő -o ro paraméter is.

Tehát csatoljuk fel a Snapshotokat a könyvtárakba.

mount -onouuid,ro /dev/szerver_vg/bck_boot_lv /mnt/bck_boot_lv/
mount -onouuid,ro /dev/szerver_vg/bck_home_lv /mnt/bck_home_lv/
mount -onouuid,ro /dev/szerver_vg/bck_root_lv /mnt/bck_root_lv/
mount -onouuid,ro /dev/szerver_vg/bck_usr_lv /mnt/bck_usr_lv/
mount -onouuid,ro /dev/szerver_vg/bck_var_log_lv /mnt/bck_var_log_lv/
mount -onouuid,ro /dev/szerver_vg/bck_var_lv /mnt/bck_var_lv/

Ezzel kész is vannak a Snapshotok amelyek a rendszerünk pillanatnyi állapotát tükrözik. Az egész hercehurca azért kellett, mert így nem fordulhat elő az a csúfság, hogy egy fájlt azért nem tudunk menteni, mert a rendszer éppen ír bele valamit. A Snapshotok segítenek nekünk a konzisztens mentés létrehozásában, mert a létrejött Snapshot a létrehozás pillanatának állapotát tartalmazza. A Snapshotok ára mindössze annyi, hogy lassul a szerverünk IO írási sebessége, ezért a mentés végeztével tanácsos a Snapshotokat megszüntetni.

Virtualizálás, klónozás

Most már csak át kell vinni az adatokat az másik vasra. Példámban nem egy fizikai gépre állítom vissza az adatokat, hanem egy virtuális gépre hozom létre a mentett rendszer tükörképét. Magyarán ezt a módszert akkor is használhatjuk, ha virtualizálni szeretnénk egy fizikai gépet. A virtualizációra tetszőleges szoftvert használhatunk, mert az eljárás működőképességét nem befolyásolja. A példa alapján egy másik fizikai gépre is helyreállíthatjuk a rendszert, vagy egy virtualizált rendszert fizikai gépre is visszaállíthatunk. Az eljárás mindegyik esetben ugyanaz. A mentett adatokat archiválhatjuk más adathordozón is anélkül, hogy a helyreállítást végrehajtanánk. Ez utóbbi esetben el kell mentenünk az eredeti gép LVM konfigurációját. Hogy miért, erről később lesz szó.

Fontos! Az új virtuális gépnek legalább akkora lemez területtel kell rendelkeznie amekkorára felférnek az adatok. A virtuálhoston állítsuk be, hogy a virtuálgép lemezképről (ISO) bootoljon. Értelemszerűen fizikai gép esetén az iso-t ki kell írni valamilyen adathordozóra (cd, dvd, usb) és a BIOS beállításokban be kell állítani, hogy a gép a bootolható iso-ról induljon. A rendszer helyreállításához igénybe veszünk egy egyszerű de negyszerű eszközt a GRML-t.

Pár szó a GRML-ről.

A GRML egy Debian alapú Linux Live rendszer amely számos rendszerdiagnosztikához és rendszermentéshez szükséges programot tartalmaz. Ezt fogom használni a gép elindításához. Fontos, hogy ugyanolyan ISO-t használj, mint amilyen rendszert mentesz. Ha 64 bites, akkor 64 bites iso kell. Ha 32 akkor 32 bites iso-t kell használnod!

Virtuális gép konfigurálása

Tehát letöltöttem a GRML iso-t és becsatoltam a virtuálgépre, hogy a virtuálgép aGRML iso-ról bootoljon. A virtuálgépen a hálózatot BRIDGE-re állítottam, hogy automatikusan kapjon IP címet egy külső DHCP szervertől. Szerintem a DHCP a legegyszerűbb megoldás. Így nem kell a fix IP címes beállításokkal vacakolni.

A GRML indítása után a kezdő képernyőn be kell állítani pár paramétert.

A Boot options for grml32-full menüben válasszuk a full – Disable Framebuffer lehetőséget.

Ha elindult a rendszer, akkor állítsuk át magyar billentyűzetet.

loadkeys hu

Be kell állítani a root  jelszót, hogy SSH-val tudjunk csatlakozni a géphez. Adjunk meg valami nem túl bonyolultat. Úgyis csak addig kell amíg a live rendszer fut.

passwd root

Indítsuk el az SSH szervert.

service ssh restart

Határozzuk meg a gép IP címét.

ip addr show

Innen már egy másik gépről SSH-val rá is csatlakozhatunk a gépre és sokkal kényelmesebben dolgozhatunk egy terminál ablakban. Persze ez a lépés simán kihagyható, ha inkább konzolon akarod bepötyögni a beállításokat. Mindegy. Az is működik, én jobban szeretem a terminált.

ssh root@<ip cím>

Particionálás és LVM létrehozása

Kérdezzük le a partíciókat.

root@grml ~ # cat /proc/partitions
major minor #blocks name
8 0 167772160 sda
11 0 366592 sr0
7 0 336816 loop0

Ebből láthatjuk, hogy a gép lemeze a /dev/sda alatt található. A használathoz particionálni kell a lemezt. Fontos, hogy a partíció méretek megfelelőek legyenek. Lehetőleg ugyanakkora vagy nagyobb mérettel hozzuk létre, mint az eredeti gépen volt.

fdisk /dev/sda
n
+200G

Típus Linux LVM
t

8e Linux LVM

Mentés és kilépés a w-vel.

Particionálás végeztével legjobb ha újraindítjuk a gépet és újra bebootolunk a GRML-ről és végigcsináljuk a belépési procedúrát. (Magyar billentyű, root jelszó, ssh szerver indítás, ip cím ellenőrzés)

Hozzuk létre az LVM-et az új lemezen. Az LVM konfiguráció meg kell egyezzen a mentett gép LVM konfigurációjával. Magyarul ugyanazokat a neveket kell használni mint amit a menteni kívánt gép is használ. Ettől lesz egyszerű ez a módszer. Ugyanis ha az fstabban az LVM kötetnévvel vannak a csatolások (/dev/mapper), akkor a fájlok átmásolása után a gép simán el fog indulni. Ellenben ha az fstabban UUID-vel vannak megadva a kötetnevek, akkor az UUID-ket módosítanunk kell. Megoldás lehet az is, ha a kötetekről DD-vel készítnük mentést, mert az tartalmazza az UUID-t is és később a DD-vel létrehozott mentést DD-vel állítjuk vissza a köteteken, de ezt ebben a leírásban nem fogom kifejteni. Példámban pont az LVM kötetek nevének egyezőségét használom ki. Megjegyzem, hogy a partícionálás során akár Raid tömböket is használhatunk, az LVM-nek mindegy, hogy Raid kötet felett vagy csak simán egy lemezen vagy több lemezen helyezkedik-e el. Ha Raid-re van szükség, akkor csináljunk Raid köteteket az LVM előtt. Itt a Raid kötetek létrehozásával nem foglalkozunk.

Első lépésként a Fizikai kötetet (PV) kell létrehozni.

pvcreate /dev/sda1

Hozzuk létre a kötetcsoportot (VG).

vgcreate szerver_vg /dev/sda1

Hozzuk létre a logikai köteteket (LV). A tmp és a swap partíciót is létre kell hozni!

lvcreate -L 1G -n boot_lv szerver_vg
lvcreate -L 4G -n home_lv szerver_vg
lvcreate -L 11G -n root_lv szerver_vg
lvcreate -L 4G -n tmp_lv szerver_vg
lvcreate -L 4G -n swap_lv szerver_vg
lvcreate -L 4G -n usr_lv szerver_vg
lvcreate -L 4G -n var_log_lv szerver_vg
lvcreate -L 38G -n var_lv szerver_vg

Formázás XFS-re. Formázhatjuk ext4-re is, de akkor mkfs.ext4 parancsot kell használni. Igény szerint használhatunk bármilyen fájlrendszert, de akkor az fstabban is módosítani kell a fájlrendszer formátumának beállításait. A legtisztább, ha hagyjuk az eredeti fájlrendszer formátumot. Itt azért xfs formátumú, mert a mentett gépen is xfs partíciók voltak.

mkfs.xfs /dev/mapper/szerver_vg-boot_lv
mkfs.xfs /dev/mapper/szerver_vg-home_lv
mkfs.xfs /dev/mapper/szerver_vg-root_lv
mkfs.xfs /dev/mapper/szerver_vg-tmp_lv
mkfs.xfs /dev/mapper/szerver_vg-usr_lv
mkfs.xfs /dev/mapper/szerver_vg-var_log_lv
mkfs.xfs /dev/mapper/szerver_vg-var_lv

El kell készíteni a swap fájlrendszert is.

mkswap -f /dev/mapper/szerver_vg-swap_lv

Hozzuk létre a csatolási pontokat.

cd /mnt
mkdir boot_lv
mkdir home_lv
mkdir root_lv
mkdir usr_lv
mkdir var_log_lv
mkdir var_lv

Csatoljuk fel az LVM köteteket külön-külön egy-egy könyvtárba.

mount /dev/szerver_vg/boot_lv /mnt/boot_lv/
mount /dev/szerver_vg/home_lv /mnt/home_lv/
mount /dev/szerver_vg/root_lv /mnt/root_lv/
mount /dev/szerver_vg/usr_lv /mnt/usr_lv/
mount /dev/szerver_vg/var_log_lv /mnt/var_log_lv/
mount /dev/szerver_vg/var_lv /mnt/var_lv/

Ezzel a virtuálgép előkészítését befejeztük. Most következik az éles rendszer mentése a virtuálgépre.

Mentés az éles rendszerről

Ezen a ponton a virtuálgép felcsatolt köteteibe át kell másolni a menteni szándékozott adatokat. Az adatátvitelre az rsync programot használom. Miért éppen rsync? Mert ha beszakad a másolás, akkor is lehet folytatni és simán átviszi a jogosultságokat is. Ha csak archiválni szeretnék a konfigurációt, akkor a mentést nem muszáj működő rendszerbe menteni. Menthetjük bárhová máshová, például külső adathordozóra is. Mint fentebb írtam, ez esetben ne felejtsük el az LVM konfigurációját is elrakni egy biztos helyre, mert kelleni fog a helyreállításhoz.

Fontos, hogy az éles gép a hálózaton keresztül elérje a cél gépet. A másolást a mentett gépről célszerű indítani a következőképpen. A másolás időtartama a sávszélességtől és a mentett adatoktól függ. Lehetőleg olyan időpontban végezzük a műveletet, amikor a hálózatunk és szerverünk terheltsége alacsony.

rsync -avz /mnt/bck_boot_lv/* Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.:/mnt/boot_lv/
rsync -avz /mnt/bck_home_lv/* Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.:/mnt/home_lv/
rsync -avz /mnt/bck_root_lv/* Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.:/mnt/root_lv/
rsync -avz /mnt/bck_usr_lv/* Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.:/mnt/usr_lv/
rsync -avz /mnt/bck_var_log_lv/* Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.:/mnt/var_log_lv/

Ha az rsync másolás sikeresen befejeződött, akkor a rendszer átvitele gyakorlatilag megtörtént. Na! Azért még nem vagyunk kész.

Grub telepítés, chroot, restart,

Az adatmásolás végeztével az adataink már biztonságban vannak a virtuálgépen. Viszont a Grubnak meg kell mondani, hogy milyen köteteket kell elindítson. A problémát az okozza, hogy a Grub konfigurációjában nem /dev/mapper hivatkozásokkal, hanem UUID-vel van megadva a kötetek elérési útvonala, ezért frissíteni kell a Grub konfigurációját. A Grub frissítése átírja a Grub konfigurációban lévő UUID-ket az aktuálisra. A frissítéshez Chrootolni kell a rendszert.

A sikeres rsync adatmásolás után a  / (root) kötet kivételével le kel mountolni a köteteket.

umount /mnt/boot_lv
umount /mnt/home_lv
umount /mnt/usr_lv
umount /mnt/var_log_lv
umount /mnt/var_lv

Tipp! Ha valamiért újraindításra van szükség akkor GRML újraboottolás után a VG-t az alábbi parancscal indíthatod. Persze újra létre kell hozni a csatolási pontokat és a csatolásokat. Szerencsés esetben erre a parancsra nem lesz szükséged.

vgchange -ay

A / (root) könyvtár alatt levő megfelelő könyvtárakba pedig fel kell csatolni a megfelelő LVM köteteket. Figyeljük meg, hogy ezek a csatolások már a mentett rendszer alkönyvtáraiba történnek!

mount /dev/szerver_vg/boot_lv /mnt/root_lv/boot
mount /dev/szerver_vg/home_lv /mnt/root_lv/home
mount /dev/szerver_vg/usr_lv /mnt/root_lv/usr
mount /dev/szerver_vg/var_lv /mnt/root_lv/var
mount /dev/szerver_vg/var_log_lv /mnt/root_lv/var/log

Csatoljuk a rendszert Chroot-hoz. Fel kell mountolni a lvm-be a futó GRML rendszer folyamatainak könyvtárait. Ez azért kell, hogy a futó GRML rendszer a Chroot miatt a sajátjának lássa az idemásolt adatokat tartalmazó felcsatolt könyvtárakat. Ezzel a művelettel a Chroot segítségével gyakorlatilag el tudjuk indítani a felmásolt rendszert. Másik előnye a műveletnek, hogy használni tudjuk a mentett rendszeren lévő parancsokat, amire most szükségünk is lesz.

mount -o bind /proc /mnt/root_lv/proc
mount -o bind /dev /mnt/root_lv/dev
mount -o bind /sys /mnt/root_lv/sys

Chroot-al bele kell lépni a rendszerbe. Ettől a felcsatolt rendszer elindul és a futó rendszert fogja látni a /proc /dev és /sys mappák felcsatolása miatt.

chroot /mnt/root_lv /bin/bash

Telepítsük a Grubbot az sda kötetre. A grub-install parancs már a mentett rendszer parancsai közül fog futni.

root@grml:/# grub-install /dev/sda
Installation finished. No error reported.

Mivel a Grub UUID-t használ ezért az Update megváltoztatja a konfigurációs fájlban lévő UUID-ket. Ez nekünk pont jó, mert arra van szükségünk, hogy a felmásolt konfigurációban megváltozzanak a UUID-k az aktuális gép UUID-ire. Ez az a lépés amit nem lehetséges kihagyni, különben nem fog elindulni a rendszerünk.

root@grml:/# update-grub
Generating grub.cfg ...
/var/lock/lvm: mkdir failed: No such file or directory
File-based locking initialisation failed.
done

A hibaüzenettel nem kell foglalkozni. Jó így.

Ellenőrizni kell az fstab-ot, hogy a kötetek hogy vanank megadva benne. Ha /dev/mapper van az fstab-ban, akkor jó a konfiguráció, és nincs vele több dolgunk. Ha UUID van megadva az fstabban, akkor módosítani kell az fstab konfigurációját is úgy, hogy az fstab a megfelelő UUID-ket tartalmazza. Ez itt most nem írom le, mert az egy másik módszer lenne, de a blkid paranccsal le tudod kérdezni a kötetek UUID-jét és annak megfelelően el tudod végezni a beállításokat.

Hálózati interfész beállítása

Fontos, hogy az eredeti gépen a hálózati kártya beállításai a /etc/udev/rules.d/70-persistent-net.rules fájlban vannak elmentve. Ebben van meghatározva, hogy a eth0 eszköz melyik MAC addresshez tartozik, ezért ezt a fájlt át kell írni. Ugyanis ha korábban eth0-ra volt beállítva, akkor az új gép hálózati kártyáját indítás után eth1-ként fogja felismerni, mert a fájlban rögzítve van, hogy az eth0 interfészhez milyen MAC cím tartozik.. Ha van olyan szolgáltatás aminél az interfész neve be van konfigurálva (pl tűzfal), akkor az a szolgáltatás nem fog indulni, mert az eth0 interfész nem létezik. Ezért indításkor a gép elég sokat fog várni a hálózati kapcsolat felépítésére, aztán időtúllépéssel megáll. A hálózat jó eséllyel nem fog működni. Írjuk át az eth0 interfész mac címét a jelenlegi gépnek megfelelően. (Lásd korábban Ip cím lekérdezése). Ha csak egy interfész van a mentett gépben, akkor megoldás az, ha töröljük a fájlt. Induláskor a Linux létre fogja hozni a fájlt és a létező hálózati kártyának az első szabad nevet (eth0) fogja adni. Az is megoldás, ha a fájlból csak a problémás sort töröljük. Ha a gép indulása után problémás a hálózat működése, akkor is módosíthatjuk utólag a konfigurációt.

Befejező műveletek

Ha mindezzel megvagyunk akkor ki kell lépni a chroot-ból

exit

Mountoljuk le a a meghajtókat.

umount /mnt/root_lv/usr
umount /mnt/root_lv/boot
umount /mnt/root_lv/proc
umount /mnt/root_lv/dev
umount /mnt/root_lv/sys
umount /mnt/root_lv/home
umount /mnt/root_lv/var/log
umount /mnt/root_lv/var
umount /mnt/root_lv

Állítsuk le szabályosan az LVM köteteket.

root@grml ~ # vgchange -an
0 logical volume(s) in volume group "szerver_vg" now active

Indítsuk újra a virtuálgépet.

reboot

Ne felejtsük el kivenni a GRML lemezt a gépből. Újraindítás után a gépnek el kell indulnia. Ha nem indul, akkor valamelyik lépésnél probléma van. Előfordulhat hogy pár alkalmazás nem működik, vagy néhány jogosultság nem megfelelő de ezeket a hibákat még mindig egyszerűbb javítani, mint nulláról újraépíteni a teljes szervert szolgáltatásokkal együtt.

Hibák

A példában lévő lépések végrehajtása után a MySQL szerver nem indult el. A hibát az okozta, hogy a /tmp könyvtár jogosultsága nem volt megfelelő, ezért a MySQL nem tudott írni bele. Egyszerűen megoldható.

chmod 1777 /tmp

MySQL restart és minden ok.

service mysql restart

Előfordulhat, hogy bizonyos programok nem fognak elindulni. Ennek az oka általában az, hogy a másolás során a fájlrendszerben a jogosultságok nem mindegyike jön létre megfelelően. Például újraindítás után a Clamav antivírus sem működött azonnal, mert a /var/log/clamav könyvtáron elállítódtak a tulajdonosi jogosultságok. Ezek a hibák a chown parancs segítségével gyorsan orvosolhatóak. Ha vannak is jogosultság hibák, akkor is sikerült átvinni a rendszert, ami el tud indulni, és a felmerülő problémákat meg lehet benne oldani. A fájlok megvannak, a mentés gyakorlatilag sikeres.

Befejező műveletek a mentett gépen

Már csak pár befejező művelet kell végrehajtani a mentett gépen. Meg kell szüntetni a Snapshotokat. A Snapshotokra csa addig van szükség amíg a mentést el nem végezzük. Ha megmaradnak a Snapshotok, akkor a lemez IO műveletek ideje is nagyobb lesz. Nincs már szükség a Snapshotokra. Töröljük őket!

Kötetek lecsatolása.

root@teszt:/# umount /mnt/bck_boot_lv
root@teszt:/# umount /mnt/bck_home_lv
root@teszt:/# umount /mnt/bck_root_lv
root@teszt:/# umount /mnt/bck_usr_lv
root@teszt:/# umount /mnt/bck_var_log_lv
root@teszt:/# umount /mnt/bck_var_lv

Snapshotok eltávolítása

lvremove /dev/szerver_vg/bck_boot_lv
lvremove /dev/szerver_vg/bck_home_lv
lvremove /dev/szerver_vg/bck_root_lv
lvremove /dev/szerver_vg/bck_usr_lv
lvremove /dev/szerver_vg/bck_var_lv
lvremove /dev/szerver_vg/bck_var_log_lv

Törüljük a /mnt alatt a felesleges könyvtárakat. Ha nincs ott semmi más, akkor *-al.

cd /mnt
rm -r *

Vagy ha van ott más is amit nem szeretnénk törölni akkor töröljük egyenként a köteteket és ne használjuk a *-ot.

rm -r bck_boot_lv
rm -r bck_home_lv
rm -r bck_root_lv
rm -r bck_usr_lv
rm -r bck_var_log_lv
rm -r bck_var_lv

 

Kész vagyunk. Van egy működő éles rendszerünk amivel azt csinálhatunk amit akarunk és létrehoztuk annak az éles rendszerként működni képes klónját.