Kopírování dat z běžícího serveru

[fotka]

Server umístěný v cizině, s množícími se vadnými sektory (SMART hodnota, tzv "Offline_Uncorrectable"), na serveru jen jeden disk, žádný RAID. Jak se dá postupovat aby bylo dosaženo co nejnižšího výpadku a data byla překopírována na nový disk?

[Reklama]

[Lol Phirae]

Server umístěný v cizině, na serveru jen jeden disk, žádný RAID.

To je ale opravdu chytré řešení... 

[student]

Ked tam mate LVM, tak je kopirovanie vsetkych dat mozne (LVM snapshot a potom z neho); inak hrozi problem s rozbitymi suborami, ktore sa prave pridavali.

Ale ked su tie data len na 1 disku, tak snad ide o nieco docasne a to by bolo asi jednoduchsie spocitat znova.

[peter]

Ty pracuješ v HR ? Inak si neviem vysvetliť dlhodobý prístup k práci typu štátna sféra, a náplň práce aj s zodpovednosťou zo súkromnej sféry. Neverím, že si tak prehľadný troll. Aké máš teraz voľné pozície a za koľko?

[Mirek Prýmek]

Ked tam mate LVM, tak je kopirovanie vsetkych dat mozne (LVM snapshot a potom z neho); inak hrozi problem s rozbitymi suborami, ktore sa prave pridavali.

Bacha na to, ani snapshot nezaručuje konzistenci dat. Některé jednodušší databáze nezaručují konzistenci dat na disku v každém okamžiku.

Takže buď:
1. přenést snapshot
2. zdrojový server vypnout
3. zazálohovat _korektně_ všechna data z náchylných databází
4. obnovit databáze na cílovém serveru

Nebo udělat podobnou operaci rsyncem:
1. rsyncnout celý server
2. vypnout na zdrojovém serveru všechny služby
3. ještě jednou rsyncnout

Ale hlavně: zapsat si za uši, že server s jedním diskem není server.

[Reklama]

[Sten]

Server s vadnými sektory
co nejnižšího výpadku

Precondition failed.

Jakmile je tam jen jediný disk, který odchází, OKAMŽITĚ se musí server vypnout. Každé další používání dost razantně zvyšuje pravděpodobnost, že odejdou další a další data, až nakonec odejde něco důležitého a nedostanete z toho už vůbec nic.

[vana-hb]

Předně bych řekl že vědomně používat počítač kde se "množí" vadné sektory je něco k čemu neexistuje neofenzivní komentář.

A druhá věc je, že bych o tom co chceš dělat asi nepůjde. Ono áleží co je to za počítač a co vlastně dělá, ale pokud to má jeden disk a necháváš to v chodu s vadným diskem tak to nebude nic důležitého. Tak že máš několik možností:
1. nechat nějakou místní počítačovou firmu ať ten disk oghostují a vymění a třeba to půjde i když i při úspěšném pokusu tě může čekat pozdější nekonzistence dat.
2. dojet tam a na místě vyměnit disk to znovu nainstalovat s čímž budeš trávit čas na místě.
3. postavit nový pc, nainstalovat ho doma a tam ho jen dovést (poslat) a jen zapojit.

[JardaP .]

Server s vadnými sektory
co nejnižšího výpadku

Precondition failed.

Jakmile je tam jen jediný disk, který odchází, OKAMŽITĚ se musí server vypnout. Každé další používání dost razantně zvyšuje pravděpodobnost, že odejdou další a další data, až nakonec odejde něco důležitého a nedostanete z toho už vůbec nic.

To je blbost. Po zastaveni ten disk uz take nemusi najet. Nejlepe zastavit aplikace, rsyncnout do zalohy. A pak eventuelne rebootnout do live distra a udelat dd, pokud to ten disk jeste zkousne.

[student]

Ked tam mate LVM, tak je kopirovanie vsetkych dat mozne (LVM snapshot a potom z neho); inak hrozi problem s rozbitymi suborami, ktore sa prave pridavali.

Bacha na to, ani snapshot nezaručuje konzistenci dat. Některé jednodušší databáze nezaručují konzistenci dat na disku v každém okamžiku.

To ano; zabudol som, ze je na to treba podmnozina ACID.

Ale tak mimochodom - taka DB neprezije tvrdy vypadok prudu a je dobra leda tak ako docasne ulozisko. Kto to ma, nech sa mu oblukom vyhnem?
Viem o tom, ze taka databaza-nedatabaza redis ma moznost syncovat len raz za niekolko sekund, ale to syncnute by uz malo prezit...

[Lol Phirae]

Ale tak mimochodom - taka DB neprezije tvrdy vypadok prudu a je dobra leda tak ako docasne ulozisko. Kto to ma, nech sa mu oblukom vyhnem?

Bože bože... server s jedním diskem a navrch bez UPS? 

To je blbost. Po zastaveni ten disk uz take nemusi najet.

Přesně. Viděl jsem již mnohokrát, i u disků, které žádné vady ve S.M.A.R.Tu najevo nedávaly.

[Mirek Prýmek]

Ale tak mimochodom - taka DB neprezije tvrdy vypadok prudu a je dobra leda tak ako docasne ulozisko. Kto to ma, nech sa mu oblukom vyhnem?

Vicemene vsechny aplikace pouzivajici takovety male embedded databaze - pokud se nemylim, tak treba BDB, takze napr. ldap s timhle backendem. A nezachranit zrovna ldap by mohlo byt dost nemile prekvapeni...

[student]

Ale tak mimochodom - taka DB neprezije tvrdy vypadok prudu a je dobra leda tak ako docasne ulozisko. Kto to ma, nech sa mu oblukom vyhnem?

Vicemene vsechny aplikace pouzivajici takovety male embedded databaze - pokud se nemylim, tak treba BDB, takze napr. ldap s timhle backendem. A nezachranit zrovna ldap by mohlo byt dost nemile prekvapeni...

Fuj, to vypada dost zle - narychlo som si nasiel, ze SQLite je ACID, takze tu snad problem nie je.
A v BDB sa oprava podla http://doc.gnu-darwin.org/transapp/recovery.html zda byt rozumna - kedze su tam zvlast log subory, tak by to mohlo fungovat. Ale neveril by som tomu.

Bože bože... server s jedním diskem a navrch bez UPS? 

Nie nutne - mne sa za nieco ako 8 rokov v serverovni uz 3x stalo, ze UPS nepomohlo / nestacilo. Islo sice o chyby personalu serverovne a chybu, ze nenabehol diesel-agregat, ale stratit kvoli chybe v dodavke elektriny celu databazu sa mi zda byt v principe tak zle, ze by som takemu programu velmi neveril.

[Mirek Prýmek]

Ale neveril by som tomu.

No prave.

ale stratit kvoli chybe v dodavke elektriny celu databazu sa mi zda byt v principe tak zle, ze by som takemu programu velmi neveril.

Tak od toho jsou zalohy zejo.

[student]

ale stratit kvoli chybe v dodavke elektriny celu databazu sa mi zda byt v principe tak zle, ze by som takemu programu velmi neveril.

Tak od toho jsou zalohy zejo.

Tjn, mozno som predpokladal zlyhanie nejaky "zlym" sposobom. Ten najhorsi sposob je, ze sa o to aplikacia nestara, ono to nejaky cas (mesiac? Rok?) na pohlad funguje a potom napr. zalozenie uzivatela pouzije nejaky blby offset v DB, takze je DB FUBAR. Zaloha v takom pripade nemusi zachranit.

Zalohy si sice robim, ale velmi nerad ich obnovujem - typicky to znamena stratu novsich dat, dlhsi vypadok + je treba prist na to, kde je tam chyba a reagovat na to obnovou dat => z principu radovo dlhsia reakcna doba ako pri automatickom prehrani logov.

[Sten]

Server s vadnými sektory
co nejnižšího výpadku

Precondition failed.

Jakmile je tam jen jediný disk, který odchází, OKAMŽITĚ se musí server vypnout. Každé další používání dost razantně zvyšuje pravděpodobnost, že odejdou další a další data, až nakonec odejde něco důležitého a nedostanete z toho už vůbec nic.

To je blbost. Po zastaveni ten disk uz take nemusi najet. Nejlepe zastavit aplikace, rsyncnout do zalohy. A pak eventuelne rebootnout do live distra a udelat dd, pokud to ten disk jeste zkousne.

To je otázka, ono to taky nemusí přežít vypínání těch aplikací, pokud budou hodně zapisovat. Ale point taken, takže asi nejrozumnější by bylo všechno vynuceně přepnout na read-only pomocí Magic SysRq:

Kód: [Vybrat]

echo u >/proc/sysrq-triggera potom ve stále běžícím systému to vykopírovat.