Dotaz: Ztrata dat po restartu serveru

[Jiřík 1435]

Dobrý den.

Na serveru Ubuntu 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux mam nainstalovany ftp server ProFTPD Version 1.3.5rc3. Souborovy system Ext4.

• V urcitem casove bode oznacenem jako T0 doslo k poskozeni UPS a server prisel o napajeni.
• Za 30 minut po obnoveni napajeni v case T0+30 server nabehnul a uzivatele dale pracovali se svymi soubory na FTP (vsechny soubory byly na miste).
• Po dvou dnech provozu, tj. v case T0+48:30 doslo k softwarovemu restartu serveru. Po tomto restartu zmizlo z disku cca 30 GB dat. V logach serveru nemohu nikde najit duvod proc k teto ztrate dat doslo.

Mohl by mi prosim nekdo rici co se mohlo s temi soubory stat ?

---

---

Odpovědi

[Martin]

Disky (SMART) a souborový systém jsou v pořádku? Nesmazal to uživatel?

[Jiřík 1435]

Server bezi ve VMWare. Souborovy system jsem po vypadku nijak nekontroloval a ani neopravoval. Po obnoveni napajeni nastartoval a vsechny soubory tam byly (uzivatele s nimi 2 dny pracovali). Po softwarovem restartu zmizly. Uzivatele je 100% nesmazali (po restartu zmizlo v souborech cca 30 GB dat).

[Prdelka]

Tak staci obnovit ze zalohy a je to ne ?

[Jiřík 1435]

Nelze, zalohuji co 24 hodin. Behem techto 24 hodin bylo modifikovano a uploadovano prilis mnoho souboru.

[Jiřík 1435]

Pro me je hlavni zjistiti proc se tak stalo. Aby se situace neopakovala.

[Petr Šobáň]

>Server bezi ve VMWare

Já si tipnu VMWare to neuložil na HDD, ale ukládal do cache.

A při výpadku se stratilo že cache není uložená a po startu pokračoval v ukládání do té cache kterou pak při legálním ukončení neuložil, ale zrušil.

Anebo to ukládal do poškozené cache a následný korektní restart tu poškozenou cache na fs opravil, smazal.

Aby se to nestalo? No proto mívají servery dva nezávislé napájecí zdroje atd.....

[Jiřík 1435]

Ano ale selhala centralni UPS. Ta napajela diskova pole i jednotlive servery. Porucha zpusobila ze behem sekundy se ztratilo napajeni vseho. 30GB dat je prilis na jakoukoliv cache.

Dva nezavisle napajeci zdroje je dobry tip ktery urcite zrealizujeme.

[Petr Šobáň]

Pokud jsou to hodně důležitá data měly by ty UPS být taky zálohované....

Ano je mi jasné že nelze ochránit vše.

30G je dost, ale kam se to potom stratilo?

[Jiřík 1435]

Příloha:

• Výstřižek.PNG (10368 bytů)

No to prave nevim, viz. priloha.

[GeorgeWH]

tak potom na co ti je ta zaloha?

[Jiřík 1435]

Pro pripad dissaster recovery.

[Jendа]

No a jak jinak se to dá dělat? Zálohovat každou minutu? Pokud je tohle velký problém, tak asi jedině online replikace.

[GeorgeWH]

tak to musi on vediet. ale pokial ma zalohu, ktora mu je prakticky na nic, tak potom na co mu to je?

ked sa data casto menia, tak urobim diff hoc aj kazdu hodinu, a na konci dna to zmazem, a necham si len koplet zalohu z celeho dna. moznosti je viac.

[Jiřík 1435]

Jak jsem jiz psal, zalohu mam pouze pro pripad disaster recovery. Nepotrebuji kazdou hodinu zalohovat data. Pouze potrebuji vedet co se stalo a jak tomu predejit.

[GeorgeWH]

zmizli vsetky data? nepripojil si nejaky disk do adresara, kde pred tym boli tie data? alebo ti chybaju len jednotlive subory/adresare? v akom stave je hw?

[Jiřík 1435]

Nezmizly vsechny data. Mam strukturu

/home/ftp/zakaznik1
/home/ftp/zakaznik2
/home/ftp/zakaznik3
/home/ftp/zakaznik...
/home/ftp/zakaznik300

Tretina jednotlivych adresaru byla prazdna (zmizly soubory i podadresare). Datum a cas posledniho pristupu dotechto adresaru byl nastaven na cca 2 minuty po restartu.
Zbyle dve tretiny dat zustali nedotcene. HW je v perfektnim stavu.

[GeorgeWH]

filesystem si kontroloval?

HW je v perfektnim stavu.

predpokladam, ze aj ta ups bola v perfektnom stave :)

[Jiřík 1435]

Ano po ztrate dat zkontroloval a vse je v poradku. Tim HW sem myslel diskove pole a servery. No UPS na druhy den zahlasila bad batery

[Petr Šobáň]

Pak mě napadá jenom jedna možnost diskové pole se rozpadlo a data jsou na jednom HDD a na druhý se to nezapsalo a pak když se to zaplo tak se to synclo z toho špatného hdd kde ty data nebyly zapsané?

Proskoumal bych datové pole zda něco neobjevíš.

Jinak pokud není nic v nějakém logu (když to vypadlo všechno naráz asi se nic nezapsalo) tak fakt nevím jak zjistit kde vznik problém....

Jediné řešení provádět častější zálohy, zdvojit napájení i s ups pokud je to životně důležité...

[Max]

Tak, tak , to je největší možný případ. Už jsem zažil, že nebylo zapnuté checkování mdadm pole + nastaveny eventy. Pole se rozpadlo a fungovalo jen z jednoho hdd, po regulérním rebootu se nabootovalo z toho druhého, neaktuálního hdd.
ESXi sw pole neumí, je tedy možné, že storage pro ESXi běží na jiném poli a to zazlobilo? Nebo se podělalo hw pole.
Nebo se šachovalo se snapshoty (třeba v době výpadku se vytvářel backup formou snapshotů a v tom to padlo a něco se podělalo).
Zdar Max

[Jiřík 1435]

To neni nas pripad. Nepouzivame sw raid. Diskove pole ma hw raid na kterem bezi dalsi virtualni stroje a ty jsou v poradku. Snapshot virtualniho stroje neprobihal.

[Max]

A v rámci toho virtuálu nemáš vytvořeno pole? Nemigroval jsi třeba fyzický server na virtuální a nezapomněl jsi na to, že to má sw pole? Nebo nějaký jiný důvod, proč by ho to mělo?
Můžeš to ověřit, že to tak 100% není?
Zdar Max

[Jiřík 1435]

V ramci virtualu pole vytvoreno nemam. Nic jsem nemigroval. Zadny duvod me nenapada

/dev/sda1 on / type ext4 (rw,errors=remount-ro)
/dev/sdb1 on /home/ftpuser type ext4 (rw,errors=remount-ro)

[Max]

A jakým způsobem je pole do ESXi připojeno? Přes NFS, nebo to je lokální storage v serveru? Nebo nějak jinak?
Zdar Max

[Jendа]

Pak mě napadá jenom jedna možnost diskové pole se rozpadlo

Pokud je to tento případ, tak by měl být v logu vidět resync. Teda jestli to není nějaký pochybný HW RAID a kdo ví, jak je to v VmWare.

Já jsem tu někde četl, že VmWare dělalo vlastní diskovou cache, a kecalo systému, že data zapsalo, i když je drželo v cache. A potom se při výpadku samozřejmě data ztratí. Na druhou stranu to znamená větší číslo v benchmarku, že jo.

[Jiřík 1435]

VMware je k diskovemu poli pripojen dvemi 10GbE SFP porty. Na te partition na diskovem poli jsou disky vice serveru a ty jsou zcela vporadku.

[Petr Šobáň]

Tak potom je to jasné moje první odpověď VMware si dělá cache která při výpadku se zahodila.

A že to bylo 30G no tak bylo......

[Max]

Provozuji ESXi od verze 3.5 a nikdy se mi nic podobného nestalo (několikrát odpojení od proudu za běhu apod.), ale to samozřejmě nemusí nic znamenat. Většinou to je local storage + HW RAID + cache na řadiči + baterie.
Cache na běžném řadiči bývá do 2GiB. Kdyby to nějak cachovat mělo, musel by mít na ESXi nastavenou SSD cache.
Osobně jsem zvědavý, na co se přijde.
Zdar Max

[Jendа]

Kdyby to nějak cachovat mělo, musel by mít na ESXi nastavenou SSD cache.

Ne, normálně v RAMce. Ale přišlo by mi divné že by to neflushlo několik hodin nebo kolik.

[fish]

Ta varianta s cache se mi moc nezda. Nikde jsem tu informaci nenasel, ale pusobi to na me, ze se ztratily nahodny soubory, ne jen ty, ktery byly od vypadku vytvoreny a upraveny. Plus na disku zustala struktura nadrazenych adresaru, ve kterych ty soubory byly, navic s casem modifikace po restartu. Ta chybejici cache by spis vedla k nahodne vadnym blokum dat v souborech, pripadne k poskozeni filesystemu, ktery by to bud vubec neprezil, nebo by fsck neco presunul do lost+found.

I kdyby VMWare udelal nejakou divocinu s automatickym obnovenim nejakeho starsiho snapshotu, porad by se do historyckyho stavu vratilo vsechno, ne jen cast dat.

btw co je v /var/log/fsck/ (pripadne jinde, kam prislusny server uklada vysledek fsck po bootu)?

[JaPe]

Dobrý den,

přesnou příčinu bude asi docela těžký zjisit. Nevím taky docela přesně, co si mám představit pod tím softtwarovým restartem - restart té virtuální mašinky z jejího operačního systému ? Restart virtuální mašinky přes vCentrum ? Sw restart celýho ESXka ? Nicméně můj velmi osobní názor - po tom prvním (hardwarovém) restartu ESXko tu mašinku tak úplně nestartovalo, ale obnovovalo, případně z jinejch důvodů byl ten FS připojenej s chybama. A při tom druhým restartu ext4 dojelo žurnál, jenže ten už byl divnej, takže to jeho dojetí tomu tentokrát spíš ublížilo. Do budoucna tomu asi těžko zabráníš - snad jedině ten FS nemountovat automaticky a po každým restartu ho nejdřív rukama zkontrolovat/opravit. Pole je v tom podle mě nevinně - kdyby bylo nabořený (třeba vyklepaná neuložená cache kontroleru) vypadalo by to IMHO jinak - a hlavně by si stěžovalo to ESXko při mountování toho datastoru - tedy pokud to je připojený jako datastore a ne jako raw lun nebo iscsi svazek rovnou do té virtuální mašinky.