[megoldva] clonezilla: LVM / tárhelyigény / tömörítés / ssh kapcsolat / ellenőrzés

Fórumok

Bocsánat a tömörített címért. Május végén a clonezilla-live listán feltettem néhány kezdő kérdést, mielőtt legelőször használnám a clonezilla-t. Nem kaptam választ. Tudtok segíteni (esetleg ha lefordítom a kérdéseket magyarra)? Köszi.

http://sourceforge.net/mailarchive/message.php?msg_id=29340275

[megoldva] mindenkinek kösz a segítséget, a megoldás az lett, hogy nem kellett költöztetni a rendszert :)

Hozzászólások

Ha jól értem, az egész rendszert át akarod másolni egy másik gépre. Miért nem egy sima tarpipe-al csinálod? Sokkal gyorsabb.

Az alaprendszernek része? Nem. Hivatalos repókban ott van? Nincs. Akkor miről beszélünk? 3rd party cuccal bármit meg lehet csinálni, és ez gyakorlatban annak számít.

Oké, rosszul írtam, Linuxhoz van, de általában, ha telepítek egy Linuxot, nem része, külön kell beszerezni.

Ezek jórészt _alkalmazások_ nem pedig alapvető eszközök, amiket már az őskorban is tartalmaztak a normálisabb rendszerek. Illendő lenne egy OS-nek _önmagában_ képesnek lennie arra, hogy saját magát lementse és szükség esetén a mentésből az üres vasra visszapakolja. Ebben pl. hasonlít a Linux a Windows-ra, tudtommal az sem képes ilyesmire, ellentétben például az AIX-szel, ami meg igen.

És? Attól, hogy a Linux ingyenes, attól még lehetne benne... Az 123456 darab egyéb, 123-féle scriptnyelven tákolt szutykok mellett/helyett.

Tehát a kérdés: Van egy repóból telepített Linux, hogyan mented le saját magával úgy, hogy a mentést a storage totális megdöglése és cseréje után kényelmesen és gyorsan vissza tudd rakni? Lehetőleg minél kevesebb emberi beavatkozással - hiszen abban lehet hibázni.

Sajnos a heterogén környezet ennek nem tesz jót. Egyrészt a hw is kissé ziláltabb mint az IBM, másrészt pl. egy debian /usr könyvtára lehet a /dev/sda6 is vagy akár a /dev/debvg/nyunyulv is. Persze lehetne csinálni szigorú disztribúciót (nem ismerem pl. a RHEL felépítését), de amíg az nincs, addig a két rendszer nem összemérhető.

Aminek vannak előnyei és hátrányai is.

A dd nem jól csinálja meg, k. sok fölösleges lomot (adatnak nem nevezhető üres terület pl.) mozgat meg, ráadásul ha nem azonos méretű a túloldalon a diszk, akkor még azt is helyre kell kalapálni. És ha netán élő rendszerről van szó, akkor konzisztenciáról sem lehet beszélni.

Ha elo rendszerrol van szo, akkor konzisztenciarol beszelni _barmilyen_ backup megoldas eseten felesleges. Meg ha snapshottal csinalsz backupot, akkor sem tudod garantalni, hogy az alkalmazasok nem eppen egy muvelet kellos kozepen vannak-e. Egyebkent meg el lehet donteni, hogy mi a tobb melo: keresni egy tokeletes megoldast, vagy dolgozni vele 15 percet, hogy jo legyen. En szemely szerint atmasolnam a particios tablat sfdiskel, megformaznam a particiokat, majd egy tarpipe-al attolnam a rendszert, leven hogy ez valszeg a legkevesebb melo.

A konzisztencia valóban érdekes kérdés, ha adatokra is kell a konzisztens állapot, nem csak a rendszer többi részére (os, alkalmazás, konfigok), akkor azt tényleg át kell gondolni, hogyan lehet biztosítani, de ez a jelenleg felmerült, sima "mentsük le a teljes OS-t, majd máshova rakjuk vissza a mentésből" feladaton túlmutat.

En szemely szerint atmasolnam a particios tablat sfdiskel, megformaznam a particiokat, majd egy tarpipe-al attolnam a rendszert

Az eredeti követelmények szerint a mentésnek akár hetekig is egy köztes tárhelyen kellett volna lennie. Az adatokhoz nem kellett volna hozzáférni, azonban a "zárt jelleg" elvárás volt. A forrásdiszken jelenleg 4 operációs rendszer van; mindegyikre egyedileg jellemző, hogy az LV-kből és a partíciókból mit csatol fel (és hova). A tar-nak még egy meglehetős hátránya, hogy nem igazán tud a blokkok fizikai elhelyezkedése szerint sorban haladni, magyarán rengeteg apró file esetén (egész /usr fa) seek time-ban fog fuldokolni a diszk, a tömörítő meg 3-4 százalék CPU-n fog szunyókálni.

A clonezilla-tól elvárja az ember, hogy a használt blokkokat az fs-től lekérve "sorban" haladjon, amelynek (lineáris, nem ezerfelé szétszabdalt LV-nél és ext[234]-nél) azt kellene eredményeznie, hogy a diszken is sorban haladunk, és a tömörítő kihajtja az összes magot.

sok fölösleges lomot (adatnak nem nevezhető üres terület pl.) mozgat meg

+1, konkrét esetben kb. 465 GB kontra 136 GB.

Tömörítés mindkettőhöz kell, természetesen, de minek pocsékoljam az időmet kb. 330 GB felesleges adat tömörítésével? Melynek jó része nem is 0x00, hanem régi (elavult, referencia nélküli) adatblokk, tehát rendesen megdolgoztatja a tömörítőt, és igazi helyet foglal a backup-ban.

A dd mióta backup-eszköz? Mióta tud fájlszinten menteni? Mióta képes bootolható iso-t/szalagot kreálni?
Amit kell tudnia egy jó, beépített backup-eszköznek, az annyi, hogy képes legyen olyan mentést előállítani, aminek a birtokában minden egyéb szoftver, telepítőmédia nélkül visszaállítható legyen a gép mentéskori állapota - rendszerbetöltővel, partíciókkal, lvm-mel, szoftveres raid-tömbökkel, fájlokkal tok-vonó. Lehetőleg minimalizálva a felhasználói beavatkozás mennyiségét.
Erre van-e beépített eszköz, vagy "vadászni" kell valahol a neten - pl. Mondo Rescue-t?

Meddig tart egy sfdisk dumppal attolni a particios tablat es megcsinalni az LVM koteteket?

Bizonyára nem túl sokáig, de most szerettem volna csak felhasználó maradni. Elindítom a clonezilla live CD-t, enter, enter, enter, célgéphez ssh adatokat megad, elmegy ebédelni. Visszaállításnál szintén ennyi munka.

Egyébként mások is az sfdisk-et ajánlották, ill. a vgcfgbackup/vgcfgrestore párost.

Amire tudok, megprobalok valaszolni, bar ilyen formaban nem nagyon hasznaltam.

> (1) Is this layout fully supported by Clonezilla Live 1.2.12-60? (I intend
to use the Debian-based stable release). Does it matter if a logical
volume is "linear" (ie. one contiguous chunk in a PV) or not?

_Nekem_ mukodik LVM-mel, de azon az egy helyen van 2 LV es semmitobb.
Nincs lehetoseged kiprobalni?

> (2) How much space am I going to need approximately, before compression? I
reckon Clonezilla will copy the partitioning / LVM metadata, and the
non-free blocks in the ext3 filesystems I have. So about 136 GB in total.
Does that seem correct?

Ezt a reszet nem ertem. Hogy jon a tomorites a kepbe? A transfer utan ugyanugy tomoritve lesznek az adatok (le akarsz masolni egy HDD-t), nem?

> (3) I'd like to specify a non-default compression method, eg. pigz. Where
do I pass the "--smp-gzip-compress" option?

Ezt sem igazan ertem. Az elobbi alapjan. Ha viszont arra keszulsz, h a cel HDD-n tomoritve, image formajaban legyen a stuff, extra opciot nem tudom, hogy kell megadni, ha amugy az advanced mode-ban nem engedi. Biztos nem default?
Alternativ lehetoseg egy wrapper irara a pigz binaris-at lecserelve.

> (4) The receiving end will be an adjacent SSH server. Can I make sure,
from the Clonezilla side, that the ssh connection itself won't use
compression or a CPU-hungry cipher? (aes128-cbc is good for me, for
example.) I could do this on the Clonezilla side, by editing
"$HOME/.ssh/config" before the ssh connection is started. Is this
supported?

Passz, de ez az elgondolas mukodhet.

> (5) After the backup process finishes, can I somehow verify the archive's
integrity / completeness (without a full restore)? The source disk will be
irrevocably gone at "real restore" time.

Van image integrity check (md5 es/vagy sha), ha erre gondolsz, de ezt alapbol fel is ajanlja.
Ha validalni viszont csak visszallitassal tudod, szerintem.

tompos

How much space am I going to need approximately, before compression?

Itt azt próbáltam meg kiszámolni a táblázat adatai alapján, hogy mennyi az összes foglalt hely, ill. erre kértem volna ellenőrzést. A tömörítés pedig úgy jön képbe, hogy a foglalt helyet foglaló adatok :) a célgépen tömörítve fognak ülni. Engem a tömörítés előtti (nyers) adatmennyiség ellenőrzése érdekelt volna (a tömörítés minimális mértékben ezt növelte volna, legrosszabb esetben, úgyhogy ez jó becslés a backup max helyigényére.)

Nem biztos, hogy ez közvetlenül válasz bármely kérdésedre, de segítség lehet:
Az LVM layoutot a /etc/lvm/backup -ban lévő backupok és az elmentett MBR alapján mindig vissza fogod tudni állítani, legrosszabb esetben kézzel.