Migrace systému: praxe

9. 5. 2012 | Max Devaine

Články - Migrace systému: praxe  

Dnes se podíváme, jakým způsobem provést migraci systému, na co si dát pozor, pro jaké řešení se rozhodnout a jak migrovat vzdáleně.

Obsah

• Bitová kopie, nebo klasické kopírování dat?
• Konzistence dat
• Online/Offline migrace
• Ruční nebitová migrace
  • 1. Rozdělení disku a formátování
  • 2. Připojíme oddíl
  • 3. Kopírujeme data
  • 4. Dovytváříme adresářovou strukturu
  • 5. Úprava grubu a fstab
  • 6. Instalace zavaděče do MBR
• Migrace na vzdálený počítač
• Závěr

Bitová kopie, nebo klasické kopírování dat?

Pokud bychom chtěli provádět migraci v rámci bitové kopie, tzn., číst data od začátku do konce disku, přesně tak, jak jdou za sebou a ve stejném pořadí je zapisovat i na nový disk, tak si můžeme ušetřit několik problémů, jelikož všechno toto nemusíme dělat:

• rozdělení disku a formátování oddílů
• zápisu bootloaderu do MBR
• úprava nastavení bootloaderu úprava nastavení /etc/fstab

K tomuto se používá několik druhů řešení, zmiňme tři:

# ddrescue, který se dokáže převalit přes vadné sektory nebo navazovat přerušenou migraci:
ddrescue -f -n /dev/sda /dev/sdb log.txt
# klasické dd:
dd if=/dev/sda of=/dev/sdb
# ne moc ideální cat:
cat /dev/sda > /dev/sdb

Všechny tyto věci se udělají „sami“ (vše se zkopíruje). Ovšem má to i několik nevýhod:

• rozdělení disku bude stejné
• migrovat data takovým způsobem lze na disky stejné nebo větší velikosti
• není možno migrovat za běhu systému (je to sázka do loterie)
• při bitové kopii se kopíruje i volné místo, což je zbytečné a prodlužuje to čas migrace
• souborový systém bude stejný (u někoho je důvod migrace změna souborového systému)
• pokud migrujeme na SSD disk nebo disk se 4K sektory, nemusí být zarovnání oddílu v pořádku
• data budou zkopírována i s fragmentací souborů (Když migruji, tak proč se nějakých těch fragmentací nezbavit? Tedy za předpokladu, že nemám SSD disk, u kterého by mi to bylo jedno)

Naproti tomu, ruční migrace, tzn., rozdělení disku, formátování, kopírování vybraných dat, dotváření adresářové struktury, instalace zavaděče apod. je sice složitější, ale myslím si, že i mnohem výhodnější.

Konzistence dat

Konzistence dat je celkem problém. Jde nám o to, aby když provádíme migraci živého systému, jsme měli data z určitého času. Představme si, že kopírujeme několik TiB dat z běžícího systému. V takovém případě nemůžou být kopírovaná data nikdy konzistentní, jelikož zkopírování těch dat nějakou dobu trvá (třeba několik hodin) a mezitím se hodně věcí změní, takže soubory, které kopírujeme na začátku budou starší než soubory, jež kopírujeme ke konci a rozdíl může být i několik zmíněných hodin a náš nový systém nebude úplně v pořádku.

Online/Offline migrace

Nejideálnější způsob migrace je takový, kdy je systém vypnutý a migraci na jinou stanici/disk provádíme z jiného než migrovaného systému (třeba z Live CD). V takovém případě nemusíme hlídat nějakou konzistenci dat. Prostě PC vypneme, nabootujeme ze záchraného CD a data zkopírujeme na jiný disk.

Člověk je ale tvor lenivý a u pracovní stanice nebo malého serveru není důvod, proč neprovést migraci přímo za běhu. V takovém případě je vhodné stopnout nějaké služby, u kterých nám záleží na konzistenci dat. Takže třeba mailserver, webserver, databázový server apod. Grafické prostředí není třeba vypínat a při migraci si klidně můžete pouštět svou oblíbenou sbírku skladeb, dívat se na film, nebo na novinky na Internetu. Jen je potřeba si dávat pozor, abychom neupravovali nějaká důležitá data.

Ruční nebitová migrace

Jelikož nemigrujeme jen tak z nudy a chceme třeba přerozdělit disk, vyzkoušet jiný souborový systém nebo nasadit LVM, tak budeme provádět ruční migraci v rámci běžícího systému (chci se při migraci dívat na film a ne koukat na čáru života kopírovaných dat).

Zmigrovat běžící systém je celkem hračka. Řekněme, že jsme si do našeho počítače přidali disk (/dev/sdb) a systém migrujeme na něj.

1. Rozdělení disku a formátování

Nejdříve si nový disk vhodně rozdělíme a naformátujeme na – pro nás vhodný – souborový systém. Já si dost často vystačím s jednoduchým programem cfdisk:

cfdisk /dev/sdb

Osobně doporučuji pro desktop rozdělit disk minimálně na 3 oddíly: „/", “/home" a swap. Taktéž nezapomenout na možnost zarovnání: Optimalizace práce s SSD disky v Linuxu. Následně informujeme systém, aby si všiml nových změn (pokud tak již neučinil). K takovému účelu dobře postačuje program partprobe z balíku „parted“:

partprobe /dev/sdb

Partition naformátujeme (každý svým nej souborovým systémem) a nezapomeneme na swap:

mkreiserfs /dev/sdb1
mkreiserfs /dev/sdb2
mkswap /dev/sdb3

2. Připojíme oddíl

Nyní si připojíme oddíl do /mnt, abychom měli kam kopírovat data:

mkdir /mnt/newsys
mount /dev/sdb1 /mnt/newsys
mkdir /mnt/newsys/home
mount /dev/sdb2 /mnt/newsys/home

3. Kopírujeme data

Po zastavení služeb, u kterých nechceme, aby nám míchaly data, se pustíme do kopírování všeho, co nám přijde do cesty:

cp -av /bin/ /boot/ /dev/ /etc/ /home/ /lib/ /opt/ /root/ /sbin/ /srv/ /usr/ /var/ /mnt/newsys
# vytvoříme symlink "lib64 -> lib"
cd /mnt/newsys
ln -s lib lib64

Tady bych upozornil na jednu věc, v debianu squeeze je /lib64 hardlink na /lib a v případě, že bychom vše kopírovali najednou, tak dostaneme hlášku:
cp: pevný odkaz „/mnt/newsys/lib64“ na adresář „/mnt/newsys/lib“ nebude vytvořen

Hardlink na adresářích je nepodporovaná záležitost, nechápu tedy, kde se to v debianu vzalo. Známý má vytvořeny klasicky symlinky na všech debianech stejné verze. Já zkoušel čistou instalaci pomocí netinstall a vytvořil se mi hardlink. To, zda se jedná o hardlink lze zjistit např. pomocí utility „stat“:

root@debian:# stat /lib/
  File: „/lib/“
  Size: 12288           Blocks: 24         IO Block: 4096   adresář
Device: 801h/2049d      Inode: 40721       Links: 11
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-05-02 21:49:39.000000000 +0200
Modify: 2012-02-25 21:45:58.000000000 +0100
Change: 2012-02-25 21:45:58.000000000 +0100
root@debian:# stat /lib64/
  File: „/lib64/“
  Size: 12288           Blocks: 24         IO Block: 4096   adresář
Device: 801h/2049d      Inode: 40721       Links: 11
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-05-02 21:49:39.000000000 +0200
Modify: 2012-02-25 21:45:58.000000000 +0100
Change: 2012-02-25 21:45:58.000000000 +0100

Takže, tuto lehkou odbočku si nechám na jindy (až bude více času nebo se podělte v diskusi, jak si na tom stojí váš Debian), nyní jdeme dál.

Nekopírujeme jen tyto adresáře:
"/mnt" – nebudeme kopírovat „sami sebe do sebe“, když tam máme připojen nový disk
"/media" – podobně jako s „/mnt“, můžeme tam mít připojené nějaké medium apod. a zbytečně kopírovat něco, co nepotřebujeme, ba naopak
"/sys" a „/proc“ – obsah a hierarchii si vytváří jádro a s obsahem v těchto adresářích není, pro neznalé, dobré nijak mainupulovat
"/tmp" – je zbytečné, né-li nežádoucí, kopírovat dočasná data, která se v tomto adresáři vytvářejí

Pokud jde o adresář „/dev“, tak ten se nemusí kopírovat celý, k funkčnosti nám postačí několik málo souborů a zbytek si dovygeneruje udev sám. Ale nemá to cenu řešit, jelikož zkopírování celého adresáře nevadí (udev si to už protřídí).

4. Dovytváříme adresářovou strukturu

Co jsme nezkopírovali, musíme dohonit. Takže začneme dovytvářet potřebné adresáře:

mkdir /mnt/newsys/tmp
chmod 1777 /mnt/newsys/tmp
mkdir /mnt/newsys/sys
mkdir /mnt/newsys/proc
mkdir /mnt/newsys/mnt
mkdir /mnt/newsys/media

5. Úprava grubu a fstab

Z minulého dílu víme, že je oddíly dobré připojovat pomocí LABEL nebo UUID. UUID se generuje automaticky, ale LABEL nikoli. Kdo používá LABEL, musí si nyní popsat unikátními názvy filesystémy na novém disku (vizte minulý díl). Námi vymyšlené a použité LABELy, nebo v mém případě UUID, přepíšeme v boot manageru (v našem případě grub1):

/mnt/newsys/boot/grub/menu.lst
...
# (0) Debian GNU/Linux
title  Debian GNU/Linux
root   (hd0,0)
kernel /boot/vmlinuz26 root=UUID=14640e9e-d1c3-0960-5b02-06071eecbc2b ro vga=795
initrd /boot/kernel26.img

a v konfiguračním souboru:

/mnt/newsys/etc/fstab
#
# <file system>                               <dir>    <type>   <options>    <dump> <pass>
devpts                                       /dev/pts  devpts    defaults        0      0
shm                                          /dev/shm  tmpfs     nodev,nosuid    0      0
UUID=14640e9e-d1c3-0960-5b02-06071eecbc2b    /         reiserfs  defaults        0      1
UUID=b35303fe-6ece-491b-8661-ded90e2f0bf8    /home     reiserfs  defaults        0      0
UUID=ac7b118b-f394-46bb-8a1d-458ae32b9e38    swap      swap      defaults        0      0

6. Instalace zavaděče do MBR

Jelikož jsme v běžícím systému a používáme GRUB stejné verze, tak netřeba dělat chroot a můžeme jej rovnou zapsat na druhý disk:

root@debian:# grub
    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]

grub> root (hd1,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd1)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd1)"...  17 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd1) (hd1)1+17 p (hd1,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.

grub> quit

Nyní stačí vypnout PC, vyndat první disk a voilá, fungujeme z nového disku .

Migrace na vzdálený počítač

Ne vždy je možné nebo nejjednodušší, připojit druhý disk do stejného počítače a provést migraci. Někdy třeba migrujeme i na jiný počítač. V takovém případě stačí na druhém počítači nabootovat nějaké Live CD (pokud migrujeme 64bit systém, tak nějaké 64bit Live CD kvůli pozdějšímu chrootu), na kterém lze spustit ssh. Poté si na vzdáleném PC provedeme úpravu a připojení partition dle bodů 1. a 2. Kopírování dat na takové PC bude vypadat následovně (kopírujeme z počítače, kde nám běží systém, nejsme tedy již přihlášeni přes ssh na systém livecd):

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 -"

Jedná se tedy o klasický „tar over ssh“. Poté se na vzdálený pc opět přihlásíme přes ssh, dovytvoříme adresářovou strukturu (dle bodu 4.), upravíme menu.lst a fstab (dle bodu 5.). Doposud je tedy vše stejné, jako v bodech, jež jsme si uvedli. Jediný rozdíl nastává u posledního bodu, kterým je instalace zavaděče do MBR. Jelikož Live CD obsahuje jiný systém, tak bude potřeba, abychom se chrootli do zkopírovaného systému a provedli instalaci zavaděče z něj. Chroot provedeme takto:

mount -o bind /dev/ /mnt/newsys/dev
mount -o bind /proc/ /mnt/newsys/proc
mount -o bind /sys/ /mnt/newsys/sys
chroot /mnt/newsys/

Nebo takto:

mount -t proc none /mnt/newsys/proc/
mount -t sysfs none /mnt/newsys/sys/
mount -o bind /dev/ /mnt/newsys/dev
chroot /mnt/newsys/

Dále zápis GRUBu (máme jeden disk, takže hd0,0):

root@debian:# grub
    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd1)"...  17 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.

grub> quit

To je vše, nyní by měl systém bez problémů nabootovat.

Závěr

Jak lze vidět, ve finále to není nic zabijáckého. Šest drobných kroků a je zmigrováno. Některé věci si lze dokonce i ulehčit. Třeba bod 3. a 4. lze trochu zkrátit tak, že si root oddíl připojíme do nějakého jiného adresáře a odsud root oddíl zkopírujeme na nový disk, čímž by nám vypadl bod 4.

Pro migraci lze využít i sofistikované nástroje, jakými je "partimage", nebo Clonezilla. Nejvíce napřed je CloneZilla, ale ani ta nezvládá migraci disku z většího na menší (pouze na stejně velký nebo větší).

Seriál Migrace systému (dílů: 2)

První díl: Migrace systému: bootovací proces, poslední díl: Migrace systému: praxe.
Předchozí díl: Migrace systému: bootovací proces

Diskuse k tomuto článku

[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