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 suFel 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 -hFá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% /devtmpfs 302M 376K 301M 1% /runnone 5,0M 0 5,0M 0% /run/locknone 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:/# lvsLV VG Attr LSize Origin Snap% Move Log Copy% Convertboot_lv szerver_vg -wi-ao 952,00mhome_lv szerver_vg -wi-ao 3,72groot_lv szerver_vg -wi-ao 10,72gswap_lv szerver_vg -wi-ao 3,72gtmp_lv szerver_vg -wi-ao 3,72gusr_lv szerver_vg -wi-ao 3,72gvar_log_lv szerver_vg -wi-ao 3,72gvar_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_vgSystem IDFormat lvm2Metadata Areas 1Metadata Sequence No 29VG Access read/writeVG Status resizableMAX LV 0Cur LV 8Open LV 8Max PV 0Cur PV 1Act PV 1VG Size 148,87 GiBPE Size 4,00 MiBTotal PE 38111Alloc PE / Size 17284 / 67,52 GiBFree PE / Size 20827 / 81,36 GiBVG 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ÉVA 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_lvlvcreate -s -n bck_home_lv -L 200M /dev/szerver_vg/home_lvlvcreate -s -n bck_root_lv -L 6G /dev/szerver_vg/root_lvlvcreate -s -n bck_usr_lv -L 2G /dev/szerver_vg/usr_lvlvcreate -s -n bck_var_log_lv -L 1G /dev/szerver_vg/var_log_lvlvcreate -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:/# lvsLV VG Attr LSize Origin Snap% Move Log Copy% Convertbck_boot_lv szerver_vg swi-a- 500,00m boot_lv 0,00bck_home_lv szerver_vg swi-a- 200,00m home_lv 0,01bck_root_lv szerver_vg swi-a- 6,00g root_lv 0,01bck_usr_lv szerver_vg swi-a- 2,00g usr_lv 0,00bck_var_log_lv szerver_vg swi-a- 1,00g var_log_lv 0,01bck_var_lv szerver_vg swi-a- 11,00g var_lv 0,00boot_lv szerver_vg owi-ao 952,00mhome_lv szerver_vg owi-ao 3,72groot_lv szerver_vg owi-ao 10,72gswap_lv szerver_vg -wi-ao 3,72gtmp_lv szerver_vg -wi-ao 3,72gusr_lv szerver_vg owi-ao 3,72gvar_log_lv szerver_vg owi-ao 3,72gvar_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_lvmkdir bck_root_lvmkdir bck_usr_lvmkdir bck_var_log_lvmkdir 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 huBe 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 rootIndítsuk el az SSH szervert.
service ssh restartHatározzuk meg a gép IP címét.
ip addr showInnen 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/partitionsmajor minor #blocks name8 0 167772160 sda11 0 366592 sr07 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/sdan
+200GTípus Linux LVM
t8e Linux LVM
Mentés és kilépés a w-vel.
w 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/sda1Hozzuk létre a kötetcsoportot (VG).
vgcreate szerver_vg /dev/sda1Hozzuk 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_vglvcreate -L 4G -n home_lv szerver_vglvcreate -L 11G -n root_lv szerver_vglvcreate -L 4G -n tmp_lv szerver_vglvcreate -L 4G -n swap_lv szerver_vglvcreate -L 4G -n usr_lv szerver_vglvcreate -L 4G -n var_log_lv szerver_vglvcreate -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_lvmkfs.xfs /dev/mapper/szerver_vg-home_lvmkfs.xfs /dev/mapper/szerver_vg-root_lvmkfs.xfs /dev/mapper/szerver_vg-tmp_lvmkfs.xfs /dev/mapper/szerver_vg-usr_lvmkfs.xfs /dev/mapper/szerver_vg-var_log_lvmkfs.xfs /dev/mapper/szerver_vg-var_lv
El kell készíteni a swap fájlrendszert is.
mkswap -f /dev/mapper/szerver_vg-swap_lvHozzuk létre a csatolási pontokat.
cd /mntmkdir boot_lvmkdir home_lvmkdir root_lvmkdir usr_lvmkdir var_log_lvmkdir 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_lvumount /mnt/home_lvumount /mnt/usr_lvumount /mnt/var_log_lvumount /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 -ayA / (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/bootmount /dev/szerver_vg/home_lv /mnt/root_lv/homemount /dev/szerver_vg/usr_lv /mnt/root_lv/usrmount /dev/szerver_vg/var_lv /mnt/root_lv/varmount /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/procmount -o bind /dev /mnt/root_lv/devmount -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/bashTelepí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/sdaInstallation 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-grubGenerating grub.cfg .../var/lock/lvm: mkdir failed: No such file or directoryFile-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
exitMountoljuk le a a meghajtókat.
umount /mnt/root_lv/usrumount /mnt/root_lv/bootumount /mnt/root_lv/procumount /mnt/root_lv/devumount /mnt/root_lv/sysumount /mnt/root_lv/homeumount /mnt/root_lv/var/logumount /mnt/root_lv/varumount /mnt/root_lv
Állítsuk le szabályosan az LVM köteteket.
root@grml ~ # vgchange -an0 logical volume(s) in volume group "szerver_vg" now active
Indítsuk újra a virtuálgépet.
rebootNe 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 /tmpMySQL restart és minden ok.
service mysql restartElő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_lvroot@teszt:/# umount /mnt/bck_home_lvroot@teszt:/# umount /mnt/bck_root_lvroot@teszt:/# umount /mnt/bck_usr_lvroot@teszt:/# umount /mnt/bck_var_log_lvroot@teszt:/# umount /mnt/bck_var_lv
Snapshotok eltávolítása
lvremove /dev/szerver_vg/bck_boot_lvlvremove /dev/szerver_vg/bck_home_lvlvremove /dev/szerver_vg/bck_root_lvlvremove /dev/szerver_vg/bck_usr_lvlvremove /dev/szerver_vg/bck_var_lvlvremove /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 /mntrm -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_lvrm -r bck_home_lvrm -r bck_root_lvrm -r bck_usr_lvrm -r bck_var_log_lvrm -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.