működő linux klónozása

 ( openstep | 2010. november 9., kedd - 10:07 )

Szeretnék tanácsot kérni, hogy működő linux rendszert, hogyan lehetne klónozni?
Kipróbált módszer érdekelne.
Még az is érdekelne, hogy egy belőtt rendszer alapján létrehozni egy telepítő lemezt, amivel ugyan olyan rendszert lehet létrehozni.

köszi

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

man dd

A napokban próbáltam és teljesen jól működik: Clonezilla

A clonezilla valóban jó cuucc. Lehet vele full lemezt clónozni, vagy csak particiót, kezeli az mbr-t. Én egyetlen dolgot nem találtam benne (lehet csak bamba vagyok) a partició atméretezését. Igy ha a forrás és a cél nem azonos méretű, akkor kiabál.

Van még olyan, aki nem LVM-et használ?

Nekem eddig még csak bajom volt LVM használatból, ezért ahol lehet, hanyagolom. Nem igazán értem, miért lenne nekem jó?
Csaba

Mert rugalmas és kényelmes. Meg ha kell még hely a /home alá, akkor pár másodperc alatt teszek. Ha máshová kell hely, akkor máshová teszek.

Pécén nevelkedett körökben valóban nehéz ráérezni az ízére... Egy csöpp tényleg komolyabb OS-en/környezetben szerzett gyakorlat/tapasztalat, és máris más a vélemény :-)

Soraidból irányomba mutató iróniát vélek kicsendülni, úgyhogy magyaráznám a bionyítványomat: Nem érzem átlagos, pécén nevelkedett körökbe tartozónak magamat, lévén, hogy igaz, hogy pécét használok hardvernek, ámde mintegy tíz éve azon csak linuxot.
Amiért nem teljesen fogom az LVM hasznosságát, az a következő szitu. Intézetünkben egy időben titokzatos módon sorozatban haláloztak el a desktop pécék. Mint kiderült, valaki kedvesen rendszeresen törölte a gépeinken pár harddisk partíciós tábláját. Szerencsére hamar rájöttünk, hogy (az akkor még létező) RIP linux CD-vel bebootolva helyre lehetett biccenteni a partíciós táblákat, kivéve, ha LVM volume-ok voltak rajta hagyományos partíciók és fájlrendszerek helyett. (Tény, hogy lehet, hogy az LVM-es diszkeket is fel lehetett volna éleszteni, csak talán a tudásom hiányzik ehhez.)
Miután az eset akkor mintegy heti gyakorisággal fordult elő, a gépekben levő harddiskeket viszont szinte soha nem bővítjük/méretezzük át, így alakult ki bennem a kép, hogy adatmentés szempontjából jobban járok, ha mellőzöm az LVM használatát.
És itt ragadnám meg az alkalmat, hogy Tőled, nálam tapasztaltabbtól kérdezzek: Olyan esetben, ha megsérül egy LVM-es rendszerbe becsatolt diszk, akkor hogyan álljak neki az adatmentésnek? Mert én hagyományosan megpróbálok olyankor live CD-t bootolni, és az adatparticiót mountolva menteni a menthetőt. Ha az adatpartíció LVM-es kötet, hogyan csináljak valami hasonlót?
Előre is köszönöm válaszod,
Csaba

Általában a Linux és a pécé világába későn érkezett meg a tényleg rugalmas tárolókezelés; nem csak te vagy egyedül azzal, hogy "deezmirejó". Amíg nem került a kezem alá élesben AIX, a maga igencsak szép diszkkezelésével, addig én is ebbe a körbe tartoztam (bár ez innen nézve marha régen volt...)

Röviden, címszavakban, emlékezetből a recovery:
lvm vgscan
lvm vgchange -ay
lvm lvs
e2fsck -f /dev/LV/VG

Egyébként man lvm

Part. tábla elhalálozásra csak tippelek: multiboot, és WinMe vagy hasonló ócskaság - az anno nálam is sikeresen képes volt a partíciós táblát agyonvágni egy-egy megborulás során.

Köszönöm a választ.
off: A part. táblák rendszeres (egyébként oprendszer független, win/lin vegyesen) elhalálozását nálunk egy vicces kedvű kolléga okozta, akinek nem tetszettek a kutatási eredmnyeink. Megfigyelő kamera és rendőrség segítségével sikerült véglegesen megoldani azt a problémát. :-(
Csaba

Egy láma szabotőr volt köztetek? A partíciós tábla törlésétől az adat még marad...


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Na ezért írtam pár topickal odébb, hogy a régi témákat ne lehessen felhozni...

Miért? Négy év távlatából megszépülnek az emlékek, vagy elévül a lámaság, netán a szabotőrködés? Nem igazán értem, miért kellene megakadályozni, ha valaki írni szeretne, valami érdekli. Számomra most is érdekes volt a történet. Ha nem hozták volna fel a topikot, lehet, sohasem olvasom, hogy valakivel ilyen történt. Határozottan jó, hogy ez feljött.

Olvasni meg nem kötelező. Elég sok tartalom van a neten, amit nem olvasunk, mert nem érdekel, nem tudunk róla, nincs rá időnk. Akit zavar, az ne olvassa.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

+1

---
| Dropbox | Wheezy-rider, öcsém! Wheezy-rider! :D

Egyébként azzal egyetértek, hogy a régi témák esetében legyen figyelmeztető üzenet, s ne fusson bele az ember abba, hogy nem nézi a dátumot, csak válaszol. Ugyanakkor, akinek ennek ellenére van kedve írni, az írjon, ezt nem kellene megakadályozni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem hiszem el hogy megint beszoptam ezt...

Mond te normálisnak találod hogy az ősrégi topikok közt keresgélsz és beböfögsz valami lényegtelent? Nem bírom felfogni hogy mi hajtja az ilyen embereket. Nem tűnt fel hogy a hupon nincs rank rendszer és a hozzászólások számát sem nézi senki?
ÉS még mindig tartom a véleményem hogy a topikokat örökre zárolni kéne.

Agyfaszt kell kapni!
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Ha már írsz valamit, tedd meggyőződéssel! Például nézd meg a dátumot. Ebből kiderült volna, hogy nem én hoztam fel, viszont, ha már felhozta valaki más, hozzászóltam.

Különben mi a problémád azzal, hogy egy régi topikhoz szól valaki hozzá? Te vagy a HUP cenzora? Úgy érzed, bizonyos témákhoz nem szabad hozzászólni, mert... miért is?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igazad van , bocsánatot kérek a posztom minden szavát muszasihoz kelett volna intéznem.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Oszt hozzám oszt meg minek? ...csak hogy csapkodjuk még itt tovább a híg fost a cerkával. :P:D
Továbbra sem én vagyok a címzett, nem én kotortam elő a postot, a főoldalról mentem...

Rózsár Gábor (muszashi)

Mindenkinek:
ez az user volt.
http://hup.hu/user/3469/track

Ahogynezem, par ilyen ezereves topicot meg felhozott +1/+2 dolgokkal.
Gondolom, valaki megszerezte a login/pass-t a joembertol (talan Gabu jatszik?)

--
http://www.micros~1

" ősrégi topikok közt keresgélsz és beböfögsz valami lényegtelent? Nem bírom felfogni hogy mi hajtja az ilyen embereket."
- nem ő hozta fel.
- nem a te problémád.
- az, hogy felhozzák, nem kerül pénzedbe, nem von el tőled semmit, nem okoz neked hátrányt.

"Agyfaszt kell kapni!" Hát ja, azt kell kapni egyesektől.

Nem tudom mire gondolt az illető, de tény, hogy így próbálkozott. Jó régi sztori :-)
Csaba

fsck -f /dev/VG/LV :)

> Van még olyan, aki nem LVM-et használ?
van...

az eredeti kérdésre a válasz: DD

A clonezilla rögtön egyik lemezről másikra tud másolni (ha cd-ről vagy usb-ről bootolva használod) vagy előbb le kell menteni valahova az image fájlt?

Mindkettőt tudja.

Mintha úgy olvastam volna a folyamat közben, hogy tudja állítani a méretet, de csak felfelé.

Ez így van.

+1

dd a keresett string.

Lósz@rt, már bocsánat. A dd nem erre való. Javasolt megismerkedni a cpio-val, az rsync-kel(!) - ezek fölösleges szemetet nem másolnak, és pont erre a célra találták ki őket.

Hát...ha le lehet egy dd erejéig állítani a klónozandó gépet, akkor én a dd-re szavazok. Egyszerű, nagyszerű és szárazabb és tisztább érzés.

De marhára nem arra való, viszi a szemtet, lehet probléma a naplózó fájlrendszerekkel estébé.

Nekem nem volt vele ilyen tapasztalatom. Ahol sikerült a dd, ott ment is a szekér utána. Ettől még lehet, hogy csak szerencsém volt.

Azonos geometriájú diszkek, nem naplózó fs esetén. De pölö egy swap partíciót, meg az üres helyet marhára fölösleges másolni... Normális unixokon az embernek eszébe nem jutna a dd-t mentésre/visszaállításra használni.

Ez lehet, de itt mentésről szó sem volt. Klónozás a feladat. A klónozás pedig bithű másolatot jelent nálam. Az pedig a dd. Ha csak mentés és visszaállás a feladat, akkor pl a dd már csak azért sem jönne szóba, mert nem is gondolnék azonos geometriájú diszkekre....hiszen adott esetben egy hidegtartalék vasra kéne visszaállni, ami általában gyengébb/kisebb konfig.

Az lehet a baj, hogy elolvastam a nyitó postot és nem gondoltam tovább, hanem írtam rá egy választ. De miért is ne tenném ezt? Ez nem Vágó István műsora, hogy kitaláljam egy versből a paksi atomerőmű műszaki paramétereit. Ha azt írja, hogy neki fehér kell, akkor fehér festéket javaslok és nem kezdek el filózni az összes világos árnyalaton, tapétán és miazmáson...

A nyitó postban csak a klónozás szerepel, azonos méretű/geometriájú diszkekről szó sincs. A klónozás számomra azt jelenti, hogy az értékes adatok a két rendszerben legyenek azonosak. Egy nem használt diszkblokk nem tartalmaz értékes adatokat, annak nem kell azonosnak lenni. És persze azoknak az adminisztrációs területeknek sem, ami a működés során változik (swap, naplózó fs naplózási területe), és a megtartása problémát okozHAT.
Normális rendszerben a rendszer klónozása egy mentés és annak a visszaállítása.

Ahhoz, hogy ext2-t, ext3-at, ext4-et vagy reiserfs-t klónozz, nem szükséges azonos geometria, elég, ha a célpartíció legalább akkora (bájtméretű), mint a forráspartíció. Sok egyéb linuxos fájlrendszerekre is valószínűleg igaz az állítás, de azokra nem próbáltam.

Sajnos a szavak egyértelműek. Klónozás=A megtévesztésig azonos, azaz teljesen azonos példány létrehozása. Az kényelmes lenne, ha minden szó értelmét a saját szájunk íze vagy az eddig bepostolt marhaságaink szerint alakíthatnánk és itt a HUP-on ez erősen divat is egy ideje, de akkor kezdj el társalogni mással. Nálam a klónozás nem az, hogy az értékes adatok vándorolnak, hanem az, hogy a klónozott és a klón teljesen egyforma. Ha ez nem igaz, akkor csak részlegesen egyforma másolatról beszélünk. És ha már ennyit lovagolsz a naplózó filerendszeren. Klónozásnál nem borul fel egyik sem. A részleges másolásnál pedig nem klónozásról, hanem backup&restore eljárásról beszélünk. Ott pedig pl. a rendszert én nem is menteném, az telepítve várná a restore procedúrát, amikor is az adatok és beállítások szépen bevándorolnak és huss, mehet a jöhet.

"Egy nem használt diszkblokk nem tartalmaz értékes adatokat, annak nem kell azonosnak lenni."

Sajnos de! KLÓN és nem logikai másolat.

Szerintem ne nyújtsuk, mi nem fogunk szót érteni, mert te azt hiszed, hogy a fogalmak a te elképzelésed szerint hol ezt, hol azt jelentik.

Egy gép klónozása nem teljesen ezt jelenti szerintem, de mindegy. Te használj dd-t, 1TB-os lemezen várj napestig - én maradok a jól bevált állományrendszer-szintű másolatnál - a többi szemétre ugyanis marhára nincs szükségem az új rendszerben.
Ha meg nem lehet leállítani a cuccot, akkor biza lvm snapshot játszik - ami korlátozásokkal, de átvihető másik vasra.

Egy kifejezés értelme nem a "szerintem" kategória. Látom, hogy kapaszkodsz a kötélbe, de értsed meg, nincs a másik vége odakötve semmihez.

Még annyit kérdeznék tőled, hogy mi az oka, hol látod az okát vagy a magyarázatát annak, hogy ha egy disk-et átDD-zek egy ugyanolyan geometriájú másikra úgy, hogy az input disk-en egy konzisztens, rendesen leállított operációs rendszer jó állapotú zsurnálozó filerendszere van, akkor az szétesik? Én gondolkodtam rajta, de sehol nem látok olyasmit, ami ezt okozná. Klónozni tehát a dd a legtutibb. Még az alacsonyabb szintű adminisztratív infókat is viszi file system és egyéb oldalon. Egyszerűen a DD-zett disket tedd egyszer vissza abba a gépbe, ahol a forrás disk volt és láss csodát!

/Elnézést a kihagyott betűkért, de csereérett billentyűzet előtt ülök!/

+1
En is mindig dd (vagy dd_rescue) hasznalok. Foleg, ha mar serult a wincsi, amirol jon a cucc :) Nem kulonosebben izgat az fs, megy az egesz wincsi, aztan utolag valami particionalo proggival legfeljebb "utanallitom" a particio meretet. Teny, hogy a badblock bejegyzesek is atmennek, de meg mindig jobb, mintha a serult fs-t kellene vinni.

--
http://www.micros~1

Működő Linux, nem leállított... Működés közben a dd meg pont nem jó. Normális oprendszer esetén az adminnak eszébe nem jutna erre a szintre süllyedni (dd) a rendszer másolásához - ott ugyanis vannak normális eszközök erre a célra.

Figyelj zeller! Egyszer már írtam, hogy zöldségeket hordasz össze, majd vissza...:) Olvass újra mindent, nem on the fly mirroring a feladat. Az ügyfél egy klónt akar, amin kísérletezhet. Az élessel mindenben megegyező klónt.

Normális admint meg nem is láthattál, hiszen normális admin kihajít a szobájából, ha nem tudod lényegretörően és teljesen egyértelműen kifejezni magadat és megérteni azt, amit mond. Ehhez pedig kell az, hogya klón szó értelmét megértsük és ne próbáljunk beleerőltetni valamit, amit a sok pizza okozta gyomorfájdalom juttat az eszünkbe.

Normális OS-t, normálius vasat látott-e kend? Mondjuk AIX-ot? Van-e a linuxon mksysb-nek megfelelő egyszerű tool? Mert most pont arra lenne szükség, de sebaj. Tudom, csináljak egyet...

Te a bitről bitre másolás híve vagy, én meg a funkcionálisan azonos másolat készítéséről beszélek, ugyanis a cél az. Persze akkor, ha valamilyen perverz app raw device-t igényel, akkor akár jó is lehet a dd, bár az ilyen perverz cuccoknak szokott lenni saját backup/restore eszköze...

Soha nem láttam normális vasat. Én eddig csak IBM/360, Siemens 7536 mainframeken, PDP 11, IBM AS/400 middleware-eken dolgoztam. Sajnos a PC - akkor is ha power - kategória nekem olyan, mint az XBOX. Jelenleg is csak terminálemulátor futtatására és az internet nevű játék futtatására használok PC-t hála az istennek és nekem érte!

"Te a bitről bitre másolás híve vagy, én meg a funkcionálisan azonos másolat készítéséről beszélek, ugyanis a cél az."

A célt meghatározta a "megrendelő", talán nem fogod felülbírálni. :)

És ki mondta, hogy másold a swap-et? Nem csak a disk-re, külön-külön partícióra is lehet dd-t mondani.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az üres helyet nem cél másolni, a journal területet sem biztos, meg egy csomó más dolgot sem - ráadásul az eltérő diszkgeometria is bekavarhat - még most is, nem csak 2010-ben, amikor azt a hozzászólást írtam, amire válaszoltál :-P

off

Valóban. Valaki felhozta, én meg nem néztem a dátumot. Attól még nem érzem úgy, hogy annyit változott volna a világ, hogy ne lehetne erről beszélni. Kellene figyelmeztetés, ha túl régi témához szólna hozzá az ember, de a válaszadás lehetőségének megtartása mellett.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miért lenne probléma a naplózó filerendszerrel bithű másolat esetén? Vagy az a cél, hogy a forrás oprendszernek működnie kell közben? Mert az kihívás, akármit is csinál az ember. Valami snapshot kellene, vagy ro mount.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

KOnzisztens állapotot működő OS-alatti fájlrendszerről csak snapshot-tal tudsz biztosan csinálni. Ez fájl szinten konzisztens lesz, ellenben alkalmazás oldalról meg nem biztos - eklatáns példa az adatbáziskezelők alatti fájlok esete: vagy DB-motor szintjén is "fagyasztod" az adatok írását a snapshot elkészítése előtt (utána rögtön mehet az írás), vagy nem lesz konzisztens DB-d a másolatban. Ez persze feltételezi azt, hogy minden LVM-en van - vagy vmware alatti virtuális gépről van szó, és vmware-es eszközzel állsz neki klónozni.

Ezt értem. Valójában futó oprendszer alatt ezt nem igazán szerencsés csinálni, vagy csak bizonyos megkötésekkel.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

vagy DB-motor szintjén is "fagyasztod" az adatok írását a snapshot elkészítése előtt (utána rögtön mehet az írás), vagy nem lesz konzisztens DB-d a másolatban.

Nos, nincs igazad. Ha az adatbázis összes fájlrendszerét egyszerre snapshotolod, akkor lényegtelen, hogy az adatbázis szintjén mit csinálsz. Persze feltételezve, hogy az adatbázis "ütésálló", azaz a 220 kihúzását elviseli (amelyik ezt nem viseli el, azt meg inkább ne is nevezzük adatbázisnak).

Azért ezt így én nem merném megcsinálni - nem véletlen az alter ... begin backup meg alter ... end backup plédául az Oracle esetében... Ekkor ugyanis az adatbázisfájlokból meg az archive logokból konzisztens DB-t tudsz rittyenteni. Mivel alapvetés, hogy a DB meg az archive log nem kerül azonos blokkdevice-ra, így de facto nem tudod egyszerre, egy atomi művelettel fagyasztani az adatbázisfájl és az archivelog állapotát, így az egyidejűség, mint feltétel nem teljesíthető.
A poweroff-ot elviseli, viszont nem tudod előre megmondani, hogy pontosan melyik állapotra fog rollback-kelni - ugyanígy egy valamilyen állapotú snapshot esetében majd-valahova-visszaáll állapotod lesz. Ha az archivelog ráadásul nem azonos időben lett fagyasztva, akkor meg... Gondold csak végig...

A backup mode azért van, mert sok esetben nincs fizikai mód az összes DB fájl egyidejű snapshotolására; ezt még intelligens storage-ok se gyakran tudják, és abban maximálisan igazad van, hogy enélkül nem lesz konzisztens. Tehát ez leginkább akkor biztosítható, ha egy szem diszken lakik az egész kóceráj, vagy kellően okos a storage.

Az, hogy alapvetés lenne, hogy egy pár raid-1 belső diszkre nem teszünk adatbázist, hát, én sok rendszert láttam már, aminél raktak. Nyilván performancia az nem volt, de ez nem is volt elvárás. Viszont a táp elvétele után legközelebb az adatbázis atombiztosan elindult.

A backup mód azért van, mert benne maradt. :)
Használj rman-t, akkor nem kell ezzel foglalkozni!

Viszont azzal a klón rendszeren restore-ral kell kezdeni. Mondjuk DB esetén ez a tiszta (száraz, biztonságos satöbbi) megoldás.
Benne maradt... Ja. De szükség volt rá, mert az ebu-nál minden jobb volt :-P

rman-nal nem lesz azonnal beindítható másolatod...

Igaz, az eredeti téma nálam kimaradt, csak az Oracle tűnt fel. :)

Ha aktív duplikálsz, akkor de. Viszont ez már off.

Nem kevered az archive és a redo logokat? Ha van egy mentésed és megvannak az archive logok, akkor az utolsó, commitolt tranzakcióig helyre tudod állítani a crash után az adatbázist egy incomplete recovery-vel. (Vagy én nem értem, miről beszélsz :))

cp -av

xcopy :-P

vagy 5 éve volt egy cikk a hwsw.hu-n, hogy miylen kapcsolókkal kell átmásolni egy egész merevlemezt egy másikra, hogy induljon a rendszer róla.
Off
Persze azóta sok idő eltelt én sem linuxozok már biztos létezik csillivilli ghost szerű programok linuxra
/off

..............................
"Herman Miller bútort követelünk a föld összes görbe hátú kompjúter zombijának"

Ahogy fentebb is írták, valóban elég egyszerű, én így szoktam:

- LiveCD bebootol.
- Új gépen partíció(k) elkészít, megformáz.
- Felcsatol az új és eredeti partíciót.
- cp -a eredeti uj.
- az új rednszeren fstab + grub-ba a partíció UUID-éket átírni.
- MBR-be be kell még írni a bootoló cuccot, ehhez chroot az új rendszerre, LILO-val rém egyszerű, GRUB esetén kicsit nehezebben installálod.

Ha több gépre kellet ugyanaz a rendszer, olyan is volt, hogy egy tar-ba mentettem le az élő rendszert és egyszerűen kicsomagoltam a 'cp' mozzanat helyett, de egyébként ugyanaz a metódus, csak esetleg könnyebben kezelhető (kb mint egy image).

+1

g4u
kickstart

Csak én értem úgy a "működő linux" kifejezést, hogy a szerve nem leállítható, tehát on-the-fly kell klónozni?

Na pl. erre jó az lvm (snapshot).

például.

Ezesetben "mount -o bind" majd "cp -a"? Nem teljesen elegáns, de gyakorlatilag működik.

Telepítőlemez készítése: Ebbe konkrétan nem másztam bele, de mindenképp distrib-függő.
Félbarkács módon én gentoo-nál a /etc-t meg a /var/lib/portage könyvtárat szoktam lementeni, ez önmagában nem sok. Majd ezekkel felülírom az új alaptelepítést aztán "emerge -e world"
De boztos más distribúcióknál is megoldható, hogy csak a configokat meg a csomaglistát mented le és azok alapján újraépítheted a rendszert.

subscribe

partimage
c

+1

"működő linux klónozása"

rsync -xav /* távoligép_ip:/leenedő_root

Nagyjából :-) De tényleg szép.

új gépen bebootolsz cd-ről, partícionálás, mkfs, mount, majd a meglevő gépről
ssh "tar cf -" | tar xf -
jelleggel lehet szépen a könyvtárakat átmásolni.
utána hostname, ip cím, stb. átírása, grub helyrerakás, majd reboot.

en igy sozktam:

mount / /mnt -o bind
mount ujdisk_vagy_nfs_share /mnt2

cd /mnt
cp -a -x * /mnt2/

masik verzio hogy tar+ssh:

uj gepen bebutulsz valami live cd-t, belepsz a felmountolt ures particiora, aztan:
ssh root@eles_gep_IP 'tar -cf - /' | tar --numeric-owner -xf -
(esteleg megcsinalhatod a bind-os mountot ott is, hogy a /dev /tmp /proc stb ne kavarjanak be)

A'rpi

Én már többször klónoztam működő Gentoo linuxot, nem olyan nehéz lemásolni egy linuxot futás közben. Én eddig a Midnight Commanderrel csináltam, mert az helyesen végzi el a másolást, kényelmesebb volt kihagyni a nem másolandó könyvtárakat: /proc, /sys, /tmp, /var/tmp
Ezeket csak üresen létre kell hozni a cél rendszeren.
Most nem emlékszem pontosan a /dev könyvtárral van-e probléma ha működik éppen a rendszer, azonban tartalmára mindenképpen szükség van ezt beszerezheted egy másik éppen nem futó linux telepítéstől is.
Ezután a klónhoz kell igazítani az fstab-ot és telepíteni a rendszerindítót és máris megy.
Ezt a nagyszerű Gentoo klónozó scriptet is többször használtam már, képes működő Gentoo-ról biztonsági másolatot készíteni, valószínüleg más disztrókkal is működhet:
http://blinkeye.ch/dokuwiki/doku.php/projects/mkstage4
Egyszerű módosítani, úgy hogy bizonyos könyvtárakat kihagyjon.
Az elkészült tar.bz2/gz csomagot csak ki kell csomagolni és elvégezni a szükséges beállításokat, majd rendszerindítót telepíteni.

Mondo Rescue: http://www.mondorescue.org/
Tökéletes megoldás. Röptében elkészíti a bootolható DVDt, amiről visszahúzhatod az eredeti rendszert.

Nem gondoltam, hogy ekkora vihart kavarok a kérdéssel, de örülök a sok hozzászólásnak.
Igazából amire készülök, hogy egy már kialakított linux rendszert szeretnék lemásolni (ha tetszik klónozni) egy új diskre azért, hogy legyen tartalékom. Tehát ha baj van akkor arról induljon a rendszer minden adatával (másik feladatom, hogy a lemásolt rendszeren kipróbáljak frissítéseket új dolgokat, amit az éles rendszeren nem merek megtenni) stb.

Köszi

Ez tuti működik:

rsync -avx / /ahova/a/cel/particiot/csatoltad/

Arra kell figyelni, hogy az fstab és a grub bejegyzések rendben legyenek ezek után (főleg ha uuid-vel tarkított a grub, és ugye ez mostanában jellemző)

----
Hol van a kígyónak farka? Minek annak az a nagy karkötő?

cd / && pax -rwpe . /mnt

--
NetBSD - Simplicity is prerequisite for reliability

+2

Mi fáj?

Ezért volt értelme upolni ezt a témát :D

Én le szoktam állítani, elvégre hosszú az éjszaka :)
Szoktam csinálni egy teljes diszk mentést: G4L disztribúcióval és mellette csinálok fájl szinten is egyet. Felbútulok valami live rendszerrel (sysres CD), felcsatolom a partíciókat, majd targz vel minden partíció tartalmát összecsomagolom egy szerver+partíció+dátum nevű tar.gz -be. Így rögtön van két másolatom is, mert egy mentés nem mentés. Igaz a fájlrendszer szintű igényel egy kis babrálást, hogy újra működjön ha vissza kell tolni, de az inkább arra van, ha mondjuk meghalna a winyó meg a raid párja is és esetleg egész más winyóra kéne visszarakni a rendszert. A diszk szintű meg akkor kellene, ha valami miatt ugyan arra vagy ugyan olyanra kellene visszatolni. ...persze a diszk mentés tovább tart, de addig is szoktam mást csinálni (másik szervereket is menteni vagy kliensekkel molyolni, szóval azt a pár órát úgy is ott tölteném)

Rózsár Gábor (muszashi)

Ezt miért nem 4 éve válaszoltad?

Mert most vettem észre. :) -mint ahogy a komment megírása után vettem észre, hogy múmia szál. :)

Rózsár Gábor (muszashi)

Kérdezd meg 4 év múlva. :D
Egyszer felhoztam egy kétéves témát, mert a track-emben piros "new" flag volt rajta. Aztán ment a csodálkozás.