Dotaz: Jak přenést Linux z jednoho serveru na druhý?

[Martin H.]

Uvažuji, jak nejlépe (ne zbytečně komplikovaně) udělat zálohu serveru a přenést jí na druhý server.

Napadlo mě zazálohovat oddíl / DDčkem na jiný disk a z něj případně zase DD obnovit - ale jak Partitions?

Případně, jak řešit 100% repliku serverů mezi sebou?

Jde mi o to, že pokud by náhodou "padnul" ten server, abych byl schopen během krátké doby obnovit server na jiném železe. Na serveru jsou aplikace, jejichž nejsem autor a tak trošku nevím, jak je případně znovurozchodit jen za pomocí záloh -a apokud by autor nebyl k dispozici, aby to tzv. "nahodil" ...

Díky za případné náměty.

Odpovědi

[Radek Hladik]

Pomocí dd je možné přenést celý disk, případně jen začátek (partition table) a pak vlastní partitions zvlášť. Ale na diferenciální přenos je spousta různých toolů, například rsync... A nebo se dá použít třeba iSCSI a mirroring disku po síti...

Možností je opravdu hodně a mají různá pro a proti. Pro zmíněný problém bych navrhoval udělat jednou dd celého disku a pak v pravidelných intervalech rsync. Jinak pokud je rozumně nastavený systém, tak pokud "padne" server, ale ne disk, tak stačí přendat disk a voilááááá

[VK]

Přesně tak. Tedy možná bych to upravil na: pv /dev/sda | dd of=... , abych věděl, jak dlouhou si mohu dát pauzu. A u GPT tabulky je možné přenést jen začátek, ale pak je třeba ji na cílovém disku opravit...

[Jendа]

abych věděl, jak dlouhou si mohu dát pauzu

kill -USR1 dd

[VK]

Jo, to by taky šlo, ale je to jen statistika, kdežto pv mi napíše hezky pro blbce odhad v h:m:s do konce bez toho, že bych se musel zamyslet

[Jendа]

Osobně kopíruji systémy především rsyncem.

Na serveru jsou aplikace, jejichž nejsem autor a tak trošku nevím, jak je případně znovurozchodit jen za pomocí záloh

Pokud zálohu uděláš tak, že zkopíruješ celé /, tak by s tím neměl být problém. Možná bude potřeba před zálohou udělat něco s databází, aby byla v konzistentním stavu.

[Jardík]

Např. já kopíroval systém z laptopu na PC přes tar, výstup na stdout, přes rouru na stdin druhého taru s rozbalováním do nového rootu. Je to rychlé, rychlejší než třeba obyčejné cp, protože komprese+dekomprese probíhá +- paralelně, narozdíl od sériového cp.

Před tím vším jenom vytvoříš nové oddíly a připojíš nový / se zbytkem. DDčkem jenom na disk se stejnou kapacitou.

[pavele]

Tar už umí ACL a SELinux? Osobně jsem přes ty různé rsyncy, rdiffy, fsarchivery, dumpy, PartImagy, dd, caty, partclony, ddrescuy, Idera Hot Copy a další skončil u cp.

[R]

dd nie je problem aj na vacsi disk, staci potom zvacsit particiu a filesystem. Ale na mensi to nejde, musel by sa najprv zmensit filesystem.

[NN]

Tak od toho mame uz nejaky patek virtuialici..

[lertimir]

Clonezilla udělá obraz disku. včetně MBR, tabulky oddílu a jednotlivých oddílů. Na rozdíl od dd zná (některé) filesystémy a kopíruje jen data ne prázdné místo a může je i kompresovat. Nevýhoda je, že je to bootovací systém, tedy server při kopii stojí.

[Max]

Záleží, jaký rollback dat je přípustný? Pokud chceš vysokou dostupnost, můžeš to řešit na úrovni clusteru. Dva servery, na nich lvm + drbd (primary - secondary). Data se pak replikují v téměř reálném čase na vzdálený server. Pokud potřebuješ mít nějakou zálohu, tak si na vzdáleném serveru dělej lvm snapshoty.
Zdar Max

[R]

Ak to ma byt HA-cluster, tak aplikacie musia fungovat z oboch serverov sucasne - a to chce aj master-master replikaciu databazy a kontrolu/upravu aplikacie.

[pavlix]

Master-master na dvou serverech zavání splitem.

[Martin H.]

Je přípustný v nočních hodinách, kdy na něm uživatelé nepracují.

S LVM bohužel nemám zatím žádnou zkušenost.

V podstatě se mi jedná o to mít funkční zálohu někde - k určitému času funkční a zbytek asi RSYNC + replika DB. Jedná se o aplikaci, kde výpadek na 10-15 minut sice je blbý, ale ne kritický.

[R]

Davnejsie som robil jedno riesenie, kde sa subory na filesysteme menili len minimalne (len vtedy, ked som tam nieco upravoval), inak sa vsetko dialo v databaze MySQL.

Nainstaloval som druhy server (uplne iny HW - obycajne stare desktopove P3, primarny server je nejaky IBM low-end server s P4) s rovnakymi balikmi, v MySQL urobil master-slave replikaciu a na aplikacne subory (PHP) pridal do cronu skript s rsync. V pripade zlyhania hlavneho servera by sa fyzicky vymenil za zalozny. Za 5 rokov to ale nikto nevyskusal, oba servery bezia bez chyby.

[mhepp]

Ahoj,

zacal bych tim, ze bych zal nejake LiveCD, na cilovem sytemu rozdelil disk(y) a vytvoril FS a pomoci rsync udelal inicialni kopii, nainstaloval zavadec a overil, ze mi to bootuje jak potrebuji. Hlavne bych si overil, ze nastartuje s jinou IP dokud nebudu potrebovat. Pokud je stroj virtualni, muzes samozrejme klonovat.

Dalsi postup zalezi na vyuziti HW serveru a potrebach.

Pokud mas relativne nevytizeny disk nebo potrebujes OPRAVDU CO NEJAKTUALNEJSI kopii, tak bych vzal cyklicky rsync (neco jako while true; do rsync ...; done). Nevyhoda je v narocnosti na disk.

Pokud Ti staci mene aktualni kopie, pak rsync poustej v zadanych intervalech podle potreby. Snizi to zatez disku, ale nebudes mit tak aktualni zalohu.

Dalsi moznost by byla sitovy datovy disk, ktery muzes rychle pripojit na zalozni server, pripadne virtualizace.

[Erbureth]

Rsync se mi neosvědčil u MySQL, tam bych se raději spolehnul na snapshoty.

[pavlix]

Důvod?

[Erbureth]

Záloha byla corruptnutá (je pravda, že je to už celkem dávno) a nepovedlo se mi ji nahodit.

[pavlix]

Předpokládám, že se jednalo o zastavenou databázi. Potom by mě ovšem zajímalo, co přesvědčilo rsync, aby ji překopíroval špatně.

[Erbureth]

Což ale není vhodný přístup pro snapshot každou vteřinu.

[pavlix]

To v diskuzi ani nemůžu najít.

[Erbureth]

V kořenu vlákna se mluví o co nejaktuálnější kopii a cyklickém rsyncu...

[pavlix]

Je to tak, máš pravdu. Tvůj komentář o rsync dává v kontextu smysl, zmátlo mě to, že jsi ten kontext ve svém komentáři nepodržel. Já jsem pak reagoval spíše v obecném kontextu rsync a MySQL.

[Sten]

Žádnou běžící databázi není vhodné zálohovat kopírováním jejích souborů, protože databázový soubor nemusí být konzistentní (může se změnit v průběhu čtení) a transakční log je out-of-date (začne se kopírovat v jinou dobu).

[pavlix]

To beru jako samozřejmost.

[j]

Snap je ti naprd uplne stejne, musis zajistit konzistenci databaze (a je jedno jestli MySQL nebo jiny). Tzn, musis databazi rict, ze ma dokoncit transakci/vysypat log (uzij si to s myisam), pak skopirujes data, a pak zas databazi reknes, ze muze pokracovat. Mezi tim se zmeny zapisujou jen do logu, ale ne do dat.

Tim samo zajistis vyhradne databazove konzistentni stav. Aby byl konzistentni i datove, to uz je takova vyssi divci (pochopitelne zaklad je prace s transakcema na urovni aplikace).

BTW: U MYSQL se to velmi casto naprasaka resi tim, ze DB proste stopnes/pauznes/posles do offline ... a predpoklada se, ze appka to nejak rozdejcha.

[Max]

Osobně bych volil typ db, co umí transakce a splňuje normu přežití v případě pádu serveru (vypnutí proudu apod.).
V takovém případě bych se nebál udělat snapshot a ten pak odkopírovat, resp. použít třeba drbd i pro databázi.
Zdar Max

[pavlix]

+1

Taky bych šel cestou nějaké plnohodnotné databáze s touto vlastností, pokud bych už z toho chtěl dělat snapshot.

[mhepp]

Co takhle prepnout MySQL do rezimu clusteru? Master-Master replikace zajisti rozumne aktualni data pro pripad vypadku sama a v cene...

Navic, InnoDB uloziste pro mysql umoznuje nejake ty vlastnosti jako transakce a podobne.

Mate jeste nejaky jiny duvod proc nepouzit cyklicky rsync? Vazne se ptam.

[Max]

Když rsync v loopu, tak asi se snapshotama, tzn. vytvořit snapshot a poté rsync snapshotu a poté snapshot smazat. Tím se zajistí, že budou všechna data ze stejného času, čímž by se měla zlepšit i celková konzistence.
Každopádně jsou případy, kdy to tak není potřeba dělat, záleží na konkrétním případu a požadavcích.
Zdar Max
PS: osobně nemám zkušenosti s master-master clusterem u mysql, ale když jsem slýchával ty nářky jen u replikací v podobě master-slave, tak nevím, zda tomu už věřit, nebo to má ještě nějaké mušky ...

[pavlix]

+1

[Jendа]

Když rsync v loopu, tak asi se snapshotama, tzn. vytvořit snapshot a poté rsync snapshotu a poté snapshot smazat. Tím se zajistí, že budou všechna data ze stejného času, čímž by se měla zlepšit i celková konzistence.

To už radši to DRBD…

[R]

Master-slave v MySQL chodi pekne. Konfiguracia je jednoducha.

Master-master uz nie je taka sranda.

[Martin H.]

Ano, to by asi bylo řešení.

V podstatě jde o to, že data jsou v MySQL DB (tu už teď replikuju jinak, takže replikace na tento server by určitě nebyla problém).

Vlastní programy /php se mění velice málo, takže by na ně RSYNC stačil (koneckonců to tak dělám už teď, ale není to funkční kopie - zálohuju na svůj server jen pro obnovu, jen data SQL jsou OnLine).

Zkusím tedy přenos přes nějaké klonovadlo, díky za rady a názory.

PS: Virtuál by byl skvělý, ale železo je poněkud méně výkonné a nechce se mi do něj investovat. Ale budu o tom vážně uvažovat.