Migrace systému: praxe (diskuse)

[mhepp]

Jde nám o to, aby když provádíme migraci živého systému, jsme měli data z určitého času.

Teda musím říct, že tato věta mi vyrazila dech. Nejsem češtinář, ale pár hrubek tu přímo bije do očí:

1. „aby ... jsme“ -- CO TO JE ZA PASKVIL? Správně je jedině „abychom“
2. když už snesu aby jsme, tak za aby patří čárka.
3. Nezněla by přirozeněji tato formulace: Jde nám o to, abychom měli data z určitého času, když provádíme migraci živého systému?

Ale abych nebyl jen kritik... Tento díl přinesl užitečné použití tar-u a ssh. Je to moc dobrý způsob, jak přenést velký objem malých souborů. Používám často. Tento způsob se dá použít i lokálně místo cp. Často dosahuje lepších výsledků:

cd source;
tar -c ./ | (cd dest/; tar -xvf -; ) 

Při migraci souborového systému jsem jednou použil i meziuložiště v podobě druhého disku. Operace pak vypadala následovně:

cd /data 
tar -c ./ > /dev/sdb
umount /data; mknovyfs /dev/sdaX; mount /dev/sdaX data/; cd /data/
tar -xvf /dev/sdb

Když jsem migroval data z datového úložiště, tak mi přišlo zbytečné, abych ukládal ohromný stream dat na souborový systém, když to není potřeba... Použít celý dosk bylo logické, navíc tím odpadla režie oprací FS vrstev...

[Petr Tomášek]

cd source;
tar -c ./ | (cd dest/; tar -xvf -; ) 

+1 (teda, az na to, ze "xvf" se pise bez "-" a mas tam navic zbytecne jeden strednik )

[.]

man tar

tar [-]

[mhepp]

No, na některých systémech, na kterých mám účty, to bez pomlčky (tar xvf) nefunguje. Naopak, s pomlčkou (tar -xvf) mi tar ještě nezařval nikde...

Ale to je jako s ps. Linux má zažitou konvenci bez pomlcky (ps afx), kdežto na Sun(?, myslím) zase bez pomlčky křičel... ale to jsou jen drobnosti...

[kos]

Ahoj, místo sekvence: cd /dest; do_something bych vřele doporučoval použít cd /dest && do_something. Ono se to cd nemusí vždy podařit .

U toho taru samozřejmě stačí tar c . | tar x -C dest/

[Ash]

...pokud vaše implementace taru podporuje -C

[Heron]

Pri kopirovani za behu je lepsi si vytvorit snapshoty a zkopirovat ty. Potom lze na systemu delat cokoliv a kopie bude stale konzistentni.

Dale misto cp radeji k tomuto ucelu pouzivam rsync. Snadno se necha navazat prerusene kopirovani.

Ten swap je tan jen pro s2disk?

[Max]

Po delším přemýšlení jsem je v článku nakonec nezmínil. Kdo ví, co dělá, tak o nich ví, kdo neví, tak bych dotyčné jen zašmodrchal do btrfs, nebo LVM.
rsync jsem zmínit zapomněl (na nějakou drobnost vždy zapomenu, ale naštěstíje tu diskuse, takže se to lidé stejně dozví :) ).

Pokud jde o swap, tak ten vytvářím preventivně. Na nových PC nikoho 4-8GiB nezabijou(nebo pro použití na zmíněný s2disk) a na starých systémech potřebujou lidi swapovat :). Pokud tedy narážíš nato, že swap není potřeba, tak nesouhlasím a odporuji :).
Zdar Max

[Heron]

Krom nějakých defaultních instalací (kde to vytvořil instalátor a admin do toho nezasahoval) jsem swap hodně dlouho (určitě pět let), nikde neviděl. Obzvláště dnes, kdy je cena paměti na úrovni 8GB / tisíc korun mi přijde swap vhodný tak akorát pro s2d. Ale nechám se poučit .

Jinak právě na nových PC s SSD diskem může 8GB ukrojeného třeba z 64GB disku někomu vadit může. Nehledě na zbytečné zápisy navíc. Obzvláště, když za tisícovku může mít o 8GB RAM víc.

[Ondrej 'SanTiago' Zajicek]

Jeden duvod pro swap je ten, ze kdyz uz pamet dojde, tak system bez swapu zacne thrashovat dost neprijemneji nez system se swapem. A pokud se jedna o interaktivni system, tak si toho clovek muze vsimnout a v te fazi jeste neco delat. Zatimco jakmile zacne thrashovat system bez swapu, tak zacne byt v podstate nepouzitelny az do chvile, nez se aktivuje OOM a neco zabije.

[Ondrej 'SanTiago' Zajicek]

Ale je pravda, ze osobne swap taky uz vubec nepouzivam.

[alkoholik]

Swap je dobry pro zjisteni, ze server potrebuje dalsi pamet.
Nastavis si swappiness treba 10 a jak se zacne plnit pres par procent, vis, ze mas pridat.

[Qaxi]

druhé použití pro swap je /tmp s tmpfs ...

má tu výhodu, že se po každém restartu smaže a nemusíte se o něj starat ...

[cita]

1000kc kdyby : )

slysel ste uz o ecc?

[Ash]

Osobně mám swap jen malý v souboru na disku (na systémové partition), a s2d dělám tamtéž, vyhrazovat extra partition jen na ten swap mi už nějaký ten rok připadá také zbytešné.

[iKoulee]

Osobne preferuji rsync az ve "druhem kole". Tzn na poprve pouzit cp nebo tar v pripade ze prenasim prez nezabezpecenou verejnou sit tak scp a az v pripade ze kopirovani spadlo v prubehu, nebo ze potrebuju sesynchronizovat zmeny od snapshotu do soucasnosti pouzivam rsync. Hlavne z duvodu rychlosti

Jinak par drobnosti k clanku:

v pripade bitove kopie rozhodne se vyplati u dd pouzit parametr bs protoze default je 512B a to je dost pomale optimalne pouzit nejaky nasobek velikosti bloku, osobne bez dlouheho zkoumani pouzivam 4k

Dal pokud jde o migraci za behu a chci minimalizovat offline stav, tak provedu prvni kopii necim rychlejsim tar/cp, pak provedu rsyncem synchronizaci, treba i nekolikrat po sobe (zalezi na tom jak moc se meni data na migrovanem stroji), tak az se cas behu rsyncu zkrati na akceptovatelnou dobu, pak se puvodni stroj odstavi, optimalne do jineho systemu provedu zaverecnou synchronizaci a spustim system na novem stroji/disku.

Dale pokud migruji data ze stroje na stroj, ktere maji soukromou sit je nejrychlejsi reseni dle meho nazoru tar/dd + netcat

# box 0
tar -cf | netcat -l -p 12345

# box 1
netcat box0 12345 | tar -xf -

# box 0
dd if=/dev/md0 bs=1480 | netcat -l -p 12345

# box 1
netcat box0 12345 | dd of=/dev/md1

[Mrkva]

tar cvf - /bin/ /boot/ /dev/ /etc/ /home/ /lib/ /opt/ /root/ /sbin/ /srv/ /usr/ /var/ | ssh root@192.168.1.1 "cd /mnt/newdisk && tar xvf -"

Taky jsem to tak dělal. Pak mi ve 2/3 kopírování 120GB disku spadnul net.

[Heron]

I proto bych doporučoval použít raději rsync.

[Ash]

když na druhé straně nic není, tak rsync není potřeba, ale pokud se něco stane, dá se s ním navázat. Jinak ale také raději používám rsync.

[Ash]

A jaký je v tom problém? Tak prostě zbytek dotlačím rsync-em a je to...

[pet]

Kdyz uz chci kopirovat root oddil, tak si jej proste primountuju:

# mount -o bind / /mnt/oldsys

a pak muzu vesele kopirovat, protoze vsechny adresare obsahuji pouze to co je opravdu na disku a nikoli na ruznych primountovanych filesystemech.

Napr.:

# cp -a /mnt/oldsys /mnt/newsys

nebo:

# tar cf - -C /mnt/oldsys . | tar xpf - -C /mnt/newsys

pripadne muzu i excludovat /tmp pokud ho nemam na tmpfs

[pet]

A jeste si dovolim upozornit, ze to p v tar xpf je dost dulezite, protoze rika taru, aby pri rozbalovani souborum nastavil stejna prava jako maji na puvodnim disku. Jinak (pri pouziti taru podle navodu v clanku) budou vsechny soubory patrit rootovi

[Max]

-p, --preserve-permissions, --same-permissions
   extract information about file permissions (default for superuser)

Toto je asi ten důvod, proč se tím člověk nezabývá, je to prostě default a pod rootem to není třeba.
Zdar Max

[pet]

Aha, to driv nebylo....

[alkoholik]

Neboj, jestli bude migrovat na vzadeleny pocitac nabootovany z Live CD, tak stejne dojede na ruzna uid a gid, protoze nepouziva --numeric-owner.
Typicky to rozesere postfix.

[Max]

Tento způsob zmiňuji v závěru.
Zdar Max

[pet]

Ktery, mountovani s -o bind?

# mount -o bind / /mnt/oldsys

[ja_kral_ll]

Hele, neni to cele pekna prasarna ? Kazdou masinu musim byt schopen kdykoli nainstalovat ze zaloh nebo dat k tomu urcenych a ne to takto bastlit.

Kdybych tohle zacal delat v praci tak mne pozenou svinskym krokem :D

[Max]

Není, je to standardní způsob migrace systému (ručně bez nějakého druhu automatizace). To, že použiješ nějaký nástroj třetí strany neznamená, že to dělá jinak, jen ti umožní toto všechno udělat na tři kliky myší, čímž toho můžeš méně zkazit :).
Zdar Max

[ja_kral_ll]

Nevim, delame to jinak. Vse je udelano ala cloud, takze si muzu lusknutim prstu nahodit novou pasinu ktera zastoupi jinou.

Podobne mirrorovnani disku jsem zazil a drive nebo pozdeji to vede k bordelu

[Max]

Tak to je jasné, že cloud, či virtualizace je zase někde jinde. Nebo profesionální řešení za nekřesťanský many. Takovým profi excht řešením je třeba Altiris, kdy kliknutím párkrát na myš lze obnovit image systém na vzdálený dekstop. Myslím, že toto používají/používali v řetězcích Macro.
V takových případech se problémy neřešení a IT Administrátor je spíš IT Technik, kdy v případě nějakého problému kašlou na řešení a prostě jen obnový image. V případě, že je desktop v jiné lokaci, tak to třeba hodinku, či dvě potrvá, no.
Zdar Max

[ja_kral_ll]

no nevim, furt se mi vic libi postup kdy se vse aplikuje na cistou instalaci.

Kdybys to takto mirroroval u vice serveru (>=100) tak se ti tam drive nebo pozdeji ukazi ruzne inkonsistence a zblaznis se z toho

[hq]

Ne, ze by to takto neslo. Ono migrace se da delat mnoha zpusoby, ale rekl bych, ze autor pouzil snad 2. nejhorsi moznost - prez cp (prvni je dd). Uz takovy rsync je o rad jinde a urcite, kdyz by se clovek zamyslel a trochu zagooglil, tak sezene jeste lepsi reseni.

[xvasek]

No a co, tak tam má cp, já zase migruju systémy přes snapshot ve vmware a "druhý nejhorší" mi přijde rsync. Každý má právo migrovat pomocí svého oblíbeného příkazu, máme demokracii.

[hq]

Tak ano, at si kazdy dela co chce. Ale pokud mam psat na abclinuxu pro (zacinajici) uzivatele, tak by to melo mit snad vyssi uroven .. nebo ne?

[xvasek]

Nemyslím si, že je potřeba čekat, než člověk dojde takového osvícení, aby mohl napsat článek. Prezentovaný postup funguje, je jednoduchý, používá známé nástroje - což naopak rsync nemusí nutně pro každého být - já to vidím jako zcela dostatečné. Eric S. Raymond píše "pokud si nejste jisti, použijte hrubou sílu" - takže použití cp pro migraci systému chápu jako schválené od jednoho z největších guru.

[2X4B-523P]

já žil v představě, že "hrubá" síla je migrovat přes cat /dev/sdx > /dev/sdy

[xvasek]

Nejhrubější síla je projet to přes uuencode, vytisknout to na tiskárně a pak to v cílové destinaci navádět přes OCR scannerem.

[mkoubik]

OT: demokracie a svoboda nejsou synonyma, naopak.

[alkoholik]

Ja bych autorovi doporucil nastudovat jeste prepinace taru --one-file-system a -C.

[pet]

No s --one-file-system jsem skarede narazil a byl bych opatrny. On totiz sice neprejde na jine primountovane svazky, ale do primountovanych virtualnich fs (devfs, tmpfs, sysfs, procfs,...) prechazi .

[alkoholik]

Tak to mate divny tar. Ten normalni slusny zahlasi:
tar: ./proc/: file is on a different filesystem; not dumped

[Numirium]

a je vymalovano, predpokladam, ze krome masochistu, vetsina lidi potrebuje migrovat na vetsi disk :) ... testovano na lidech a ok :)

[Kvakor]

Pokud jde o upgrade, tak téměř vždy se převádí na větší disk a dnes už dlouho není třeba řešit problémy s disky s rozdílnou geometrií (PATA pod 8GB). Ale v případě havári se často stane, že náhradní disk je od jiného výrobce nebo jen jiného typu a je ve skutečnosti o kapínek menší (třeba jen o pár MB). Obzvlášť problematické jsou SSD disky, kde z důvodů ukousnutí části kapacity pro wear leveling může být rozdíl v kapacitě i u jednoho modelu, pokud každý z nich používá jiný firmware.

Já osobně jsem se setkal s diskem, který hned po instalaci začal hlásit špatný stav přes SMART a jeho místo šel disk jiného výrobce, který měl místo 500.00něco GB přesných 500 GB. Naštěstí jsem v tomto případě měl na posledních GB disku swapovací oddíl, takže stačilo zrušit ho, překopíriovat disk jedna ku jedné a znova ho vytvořit.

[CIJOML]

Migrace po debianovsku:

dpkg --get-selections > seznam_baliku.out; dpkg --set-selections < seznam_baliku.out; apt-get dselect-upgrade

a potom jen prekopirovat /etc a nahrat znovu lilo hotovka a mam jistotu ze system je novy a bez zadnich vratek.

[j]

Vis, on je celkem rozdil mezi novym systeme vs migraci systemu. Vetsina lidi nechce prijit o /home, logy, ... proto system migruji. Pokud chteji cistej system, tak pouzijou seznam balicku a skopirujou jen tu konfiguraci.

BTW: Pokud se nekomu na tvem old systemu povedlo zapsat do etc akceptovany certifikat pro roota (napr) tak mu ho pekne skopirujes i na ten "system bez zadnich vratek" ... :D

[jan.xxx]

Já s oblibou používám FSARCHIVER

[rastakajakwanna]

Nebudu se radši zaplétat do rsync vs. cp (i když mi rsync přijde vhodnější) a rovnou přihodím utilitku která se může hodit při nutnosti migrovat live systém - HCP (URL= http://www.r1soft.com/tools/linux-hot-copy/?ls=LNXMNT&campaign_ID=70140000000QOL2&utm_source=linuxmint.com&utm_medium=banner&utm_campaign=LNXMNT_FTHotCopy ). S úspěchem použito všude, krom jednoho historického Debianu s 90MB volné operační paměti, který to neustál. Howk!

[covex]

Nekdo uz tady zminoval clonezillu, v podstate velmi podobny a starsi je partimage. Je mnohonasobne rychlejsi nez dd, protoze nekopiruje volne misto, muzete udelat image jen oddilu nebo oddilu i s partition tabulkou atd. Neni to vsespasne, protoze opet musite kopirovat na disk stejne velikosti. Pro extX filesystemy lze pouzit dump/restore. Nevyhody vsech cp/tar jsou uz zminovane pripojene souborove systemy a mnohdy take extended atributy, ACL ci selinux - na coz je potreba myslet zvlaste pokud pouzivate napr. livecd jine distribuce nez tu, kterou migrujete.

[Max]

Nekdo uz tady zminoval clonezillu

Ano, zmiňoval jsem jí já v článku :).
Zdar Max