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 :)
- 5177 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
Mert a tarpipe nem tartja meg a gondosan kialakított partícióimat, logikai köteteimet és boot loader-eimet.
- A hozzászóláshoz be kell jelentkezni
No igen, úgy tűnik, hogy normális backup még nincs a Linuxhoz... Ezeket szépen kézzel megkreálod a túloldalon, aztán mehetnek a fájlok. Esetleg lehet scriptelni a partíciók/lvm adatok mentését és visszarakását...
- A hozzászóláshoz be kell jelentkezni
Mibol szurted le, h nincs normalis backup LINUX-hoz? A clonezilla-bol?
tompos
- A hozzászóláshoz be kell jelentkezni
Normális backup: berakok egy üres DVD-t, elindítom, aztán kiköp egy bootolható lemezt, amit bebootolva visszaállítható az aktuális állapot. De felőlem bootolható tape is lehet...
- A hozzászóláshoz be kell jelentkezni
Mondorescue (http://www.mondorescue.org/) Ez tud boot-olható CD/DVD-t készíteni neked. Szerintem vess rá egy pillantást. Bár én nem rendszerek "átköltöztetésére" használtam régebben, hanem visszaállításra.
- A hozzászóláshoz be kell jelentkezni
Köszi, kár, hogy normál repóban nem nagyon találtam meg :)
- A hozzászóláshoz be kell jelentkezni
Kb 7 éve létező projekt. Nem egyedüli.
- A hozzászóláshoz be kell jelentkezni
Megha a clonezilla nem is tudna, mibol jott le, h nincs mas alkalmas eszkoz linux-ra?
Ebben a formaban ez FUD, mint ahogy egyebkent lentebb meg is irtak.
tompos
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Tovabba nincs linux-ra skype, java, egy vagon ingyombingyom jatek, oracle, db2, SAP, zfs es meg sorohatnank.
tonmpos
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Mennyibe is kerul egy AIX licensz?
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
Van ilyen szoftver, a Bacula tud ilyet. Igaz, nem egy kattintassal, mert a Linux nem tipikusan egy kattintasos rendszer.
- A hozzászóláshoz be kell jelentkezni
Azért az mksysb -m /dev/rmt0 picit egyszerűbb - valami ilyesmi lenne jó Linuxon is...
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A Bacula doksijára ránéztem (még mielőtt a kérdést feltettem), és rögtön láttam, hogy annak a telepítése-beállítása kéthetes vállalati projekt. Nekem 1 db diszk egyszeri mentésére és visszaállítására lett volna szükségem.
- A hozzászóláshoz be kell jelentkezni
Neked igazabol nem backup, hanem koltozteto szoftverre van szukseged. Szerintem a DD teljesen jol megcsinalja, amit szeretnel, plane hogy at tudod pipeolni a halozaton.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A sfdisk meg mindig (vagy sosem fogja tudni?) nem kezel 2TB-nal nagyob HDD_ket, igaz?
tompos
- A hozzászóláshoz be kell jelentkezni
Passz, de pont a particios tabla masolasara van kismillio utility.
- A hozzászóláshoz be kell jelentkezni
Ez így pontatlan.
2TB-nál nagyobb partíciót nem kezel, illetve egyik partíció kezdőcíme sem eshet a 2TB-os címtartományon kívülre.
(Ha jól emlékszem.)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A bare metal backup nem alapveto.
En ugy latom, a kozponti configuracio kezelo rendszerek terhoditasaval egyre kevesbe lesz az.
tompos
- A hozzászóláshoz be kell jelentkezni
Neked. Másnak meg igen.
- A hozzászóláshoz be kell jelentkezni
OK, akkor a LINUX nem tudja, mert zeller nem tudja, h kell hasznalni a dd-t, vagy mert idokozben keszit szabalyokat, csak hogy tudja bizonyitani a sajat igazat, vagy ki tudja miert.
Ehh, nagyon unod a hetfot?
tompos
ui.: Tudtommal a bacula is tudja.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, h van-e pont ilyen. Vannak meg ujabb igenyek, vagy ez A jo beepitett backup eszkoz definicioja?:)
BTW, erdekel, miert jobb, ha beepitett, miert faj, ha 3rd party?
t
- A hozzászóláshoz be kell jelentkezni
Meddig tart egy sfdisk dumppal attolni a particios tablat es megcsinalni az LVM koteteket?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni