Ubuntu server klónozás

UNIX kezdő

Mi a leghatékonyabb módszer egy futó Ubuntu olyan klónozására, ami nem igényel leállítást és 2 órás kiesést?

  • 3224 megtekintés

Bocsánat, kicsit időhiányban vagyok, most jutottam újra géphez.

PCIe kártyák miatt a virtuális gép nem megoldható sajnos, ezért fizikai. Ubuntu 14.04.2 és nem gond a leállás csak macera és egy up-to-date klónra van szükségem, nem szeretnék egy folyamatosan változó adatállománnyal minden nap két órát klónozni. LVM nincs...
Az adatmennyiség kb 5-600Gb.
Amire gondoltam az egy kezdeti klónozás és akkor két HDD-val a rendszerben valahogyan naprakészen kell tartani a második HDD tartalmát, egy éjszakai átmásolós szkripttel??

A macera az, hogy nem vagyok kezdő linuxban, de haladónak sem mondanám magam. Nem okoz gondot egy dmesg, de ha már backup meg scripting, abban kicsit elvesznék. Ezért kérem a tisztelt nagyérdemű véleményét.

A hozzászólások nagyon konstruktívak, köszönöm! :-D

A cél nem egy új vas klónozása, csak egy tartalék és up-to-date HDD megléte....

A legrövidebb leállást azzal éred el, ha feltérképezed a már nem változó állományokat (ebből lesz a több), valamint azokat, amelyek folyamatosan keletkeznek/változnak. Mivel nem részletezted, milyen szolgáltatások futnak, feltételezek most egy olyan szervert amilyent az alább leírt módszerrel 30 perces leállás mellett be tudtam izzítani.

A szerveren futó szolgáltatások: sendmail, apache2 vhostokkal, mysql, ftp és kb. 100 user.

A költöztetni kívánt mennyiség: 600Gb, ebből állandó "mozgásban" napi 10Gb (+/-)

A folyamat:

Az új vason felépítettem az új szervert, áthoztam és aktualizáltam az /etc megfelelő állományait, vele együtt a userekre vonatkozó passwd és shadow fájlokat is, majd a működő szerveren leltárt készítettem, és rsync segítségével áthoztam mindent, ami kellett.
Következő nap szintén rsynccel áthoztam a különbözetet, harmadik nap óránként lefutott az rsync (egyre gyorsabban, mivel egyre kevesebb változás keletkezett).
Nap végén fogtam az új vasat, bevittem a szerverparkba, kikértem a régi vasat (elkezdett ketyegni az idő), elindítottam úgy, hogy csak az SSH működjön, rsynceltem 15 perc alatt, amint végzett leállítottam a régit, aktualizáltam az új vas IP-jét, elindítottam, minden működni kezdett, shutdown, majd bevitettem az új vasat a helyére (újabb 15 perc).

Bekapcsolták, ott maradtam még konzolközelben, átnéztem mindent, amikor minden szolgáltatás maximálisan működni látszott, elköszöntem, és eljöttem.

A userek semmit nem vettek észre, (szombat este 11 óra volt) habár a tervezett leállásról kaptak értesítőt.

Update: ez 325 napja volt...

15:58:26 up 325 days, 7:38, 13 users, load average: 0.07, 0.20, 0.22

--
Coding for fun. ;)

Ez jól hangzik, az én esetemben annyival más, hogy mint említettem, csak HDD klónozásról van szó. Az updatek miatt nem is jó ha azonnali a szinkronizáció, legjobb, ha reggel rendelkezésre áll a klón és ha napközben valami agyoncsapja, pl. egy update (ami nem Ubuntu update), akkor csak kicserélem a boot hdd-t és megy tovább.

Egyébként elég jól behatárolható, hogy mi a változó állomány és nincs is user data. Csak konfigállományok változnak egy adott szoftver esetén és néhány médiaállomány.
Ezeket hogyan tudom legjobban szinkronizálni? Van valakinek erre kvázi kész scriptje amit cron-ba tehetek?

A lényeg:

Adott egy tvheadend server, ami átlag napi 1x frissül, és ha kernel update is van, néha meghülyül az egész mert a kártyák driverét agyoncsapja. A gond nem a driver, mert azt újratelepítem, de van úgy, hogy a tvheadend már nem indul el, egy frissítés után, mert érzékeny a lelkem. Ez ritka, de azért előfordul. Ez napi 24-ben fut, tehát nagy leállás nem lehet, de vannak időszakok amikor belefér, csak a macera minimalizálása végett ilyenkor egyszerűbb lenne az életem, ha visszatérhetnék az előző állapothoz.
Ha ez eutomatikusan követi a live hdd tartalmát, akkor a PVR által rögzített tartalmak is a helyükön vannak és az összes bosszúság annyi, hogy a második HDD bootnál kiírja, hogy nem jó az ID vagy mi.
Tehát van egy olyan backupom amihez nyúlhatok és az nem egy fél éves verzió. A tartalom nem kritikus, mert nincs rajta érzékeny adat, de egy ilyen szerver beállítása, finomhangolása nekem kb 2-3 hét, amíg minden a szájam íze szerinti.

Ami fut rajta:
Postfix relay, Tvheadend, Oscam, Apache, Samba, miniDLNA, Transmission, és még egy pár dolog, ebből a három hétből 99 % a Tvheadend konfigurációja. Csatornahangolás, ikonok, csoportosítás, sorrend, etc.

Remélem így már tisztább a kép.

Ehhez lehet felesleges az egész rendszert klónozni, és elég lehet naponta resync-elni egy másik könyvtárba a tvheadend könyvtárat, ha meg gáz van, a rossz, élest letörlöd és átnevezed a 'backupot' az élesre. Csomagból meg visszateszed az eggyel korábbit, ez így 5 perc.
Egyébként van igazi értelme az unstable/napi buildot használni? Tudom, hogy a stable már viszonylag régi, de van kézzelfogható előnye? ( Ezt úgy kérdezem, hogy én a stable-t használom, és nem néztem még utána, mi van az újban, tényleg kíváncsi vagyok.)

Van, rengeteg apróság belekerült, javult jópár funkció. Nekem az IPTV funkció miatt fontos. Egy ideje ffmpeg-gel megy a hls stream is.
stabil egyébként. Van egy tesztszerverem amin tesztelem az új verziókat, de egy ideje már csak az éles megy. Semmi gond. A legutóbb csak az Oscam állt le állandóan. Ma frissítettem és most jó.

Értem. Én dvb-s-hez használom a 'stable'-t. Tény, hogy néha szarakodik ( pl van, hogy elveszti a xbmc a kapcsoaltot csatornaváltások, akkor újra rá kell nyomni, a csatorna kiválasztására. Vagy felvételekben időnként nem hajlandó beletekerni, ilyenkor vagy nagyon lassan csinálja, vagy kilép a lejátszásból) de eddig bírtam még idegekkel, mint az unstable-t rakjak fel:-). Bár abban sem vagyok biztos, hogy a tvheadend a ludas és nem a az xbmc/kodi-s gép. Oscam-et én egyszer fordítottam lassan 2 éve, azóta nem nyúltam hozzá, nekem nem volt bajom vele eddig.
Illetve tvheadend olyat csinál kb 3-4 havonta, hogy hirtelen elkezdenek 'kiesni' csatronák, amit azután nem hajlandó lejátszani tovább, és ezek szaporodnak.
Két tuner van a gépben, ilyenkor letörlöm az egyikről a multiplexer listát, a másikról átmásolom rá (ugyanazt), aztán a másikról is letörlöm és arra is visszamásolom az elsőről ugyanazt, és megjavul:-).

Szerintem ilyen, neked testre szabott scriptje senkinek sincs. Rakd össze, mit szeretnél menteni a másik gépre, melyik könyvtárak tartalmát szeretnéd szinkronban tartani, és utána rsync üzemidőn kívül az adott könyvtárakra. Ha a céldiszk ugyanabban a gépben van, és ugyanakkora, mint az üzemi diszk, akkor indulásként lehet akár egy teljes dd-s másolást csinálni ("kályha"), majd felbootolni az "üzemi" diszkről, a "klón" megfelelő partícióit felcsatolni, rsync, lecsatol, örül. Következő mentési/másolási körben felcsatol, rsync, lecsatol, örül. Persze annyira azért nem szabad örömködni, mert rsync közben ha egy fájl masszívan írás alatt van, akkor annak a másolata kellőképp inkonzisztens lesz.

Akkor gyorsan "újratervezés", egy backup, és a másolaton már LVM-re pakolni a motyót úgy, hogy legyen bőven fel nem használt helyed a diszkeken arra, hogy LVM-snapshot-ot csinálj. De lehet, hogy elég lenne egy normális backup/restore megoldást implementálni, amihez három dolog kell: tanulni, tanulni, tanulni - és persze negyediknek kipróbálni a dolgokat.

( STP | 2015. 05. 19., k – 11:53 )

Hogyan tudnék gyorsan kereket cserélni?

Leállás nélkül? Keresel egy kamiont, Knight Rider stílusban felgurulsz rá, leállítod az autót, kicseréled a kereket közben üvöltözve a sofőrrel, hogy "ne arra! NE ARRA!", majd a sofőrfülkén keresztül padlógázzal kihajtasz a kamionból (ha tolatva mennél, akkor ha egy pillanatra is, de meg kellene, hogy állj)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem kell megállni tolatva sem. Miért kéne? A kamion és a rámpa meg előre 150-nel (legalább, különben semmi izgi nem lenne benne). Te lehajtasz hátra, abban a pillanatban, amikor leérsz az útra kb 150-nel fogsz menni te is. Annyi történik, hogy a keréknek elég hirtelen kell 150-es tempóhoz felforogni, úgyhogy egy kicsit csikorogni és füstölni fog. De ubuntut használva nem probléma.

Jogos, viszonyítási pont kérdése (abban a pontban, amikor a hátramenetből előre váltasz az, amikor "önmagát tekintve" az autó tényleg nem mozog, de az úthoz képest valóban).

De ubuntut használva nem probléma.

:D

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igaz, de Te is tudod, hogy szokott menni.

Egy virtualizált környezet segíthet ebben de én inkább szolgáltatás oldalon fognám meg a dolog és a nulláról telepíteném át darabonként mindent, hogy a dolog "kívülről" ne legyen leállásszagú, max egy dns ttl-en belüli.

Pontnem... Meg kell nézni, milyen alkalmazások futnak, milyen a hardver, és utána lehet megoldást adni. Lehet, hogy egy csomagszinten azonosra felrakott rendszerre ésszel rátolt rsync, lehet, hogy lvm-es snapshot javasolt, lehet, hogy "sima" mentésből visszaállás a leginkább alkalmas. A dd csak az n+2. lehetőség, és nagyon sok feltétele és hátránya van.

( freeoli v | 2015. 05. 19., k – 12:39 )

Elvileg az új vason létrehozott live rendszer alá felcsatolt fájlrendszerre rsync-el online másolt terület majd a leálláskor leállított szolgáltatásokkal egy frissítő jellegű szinkronizálás. Ezt előtte is ki lehet próbálni, plusz a rendszerindítót is meg kell oldani de azt a végleges sync előtt is helyre lehet tenni.
Ha már költözés és általánosítás. Tudni kell a sok kérdésre a választ.