Názory k článku Kvůli chybě v softwaru od HPE přišla japonská univerzita o 77 TB dat výzkumu

oni maju za "cely zivot minus 10 dni" toho superPC len 77TB dat? Ked to pritiahnem za vlasy, tak na zalohu staci 4diskove synology za 400€ (+ 4x20tb HDD), tak ale snad tam maju 1 blbu paskovu mechaniku a laduju zalohy na pasku, nie?

To budou nejspíše data pouze pro ten Cray, tzn. budou tam probíhat nějaké složité a časově náročné výpočty.
A data skutečná budou na ostatních serverech a ty nejspíše budou v pohodě.
Ale ty výpočty se budou muset udělat znova.

Ty kokos, ty specifikace... ta mašina je víc jak 1000x silnější než to, co mám doma, a to jsem si z mladické nerozvážnosti do kompu nacpal 128 GBR AM ????

A technická: ta vyjádření HP mi nedávají smysl. Kromě takové nepodstatnosti, že to nebyl "software" ale "skript" (naprasený za vlastního běhu (!)), jsem nepochopil to mazání "logů." Schválně jsem se kouknul i na zdroj, tam je to napsané úplně stejně blbě. Nedává smysl, aby výmaz aktivních logů "zrušil" samotnou zálohu. Takže to pravděpodobně bylo asi vše trochu jinak, respektive došlo k výmazu možná metadat, potřebných k práci s daty, případně ony "logy" byly defacto vlastními výstupy výpočtů a tedy daty onoho superpočítače, nebo zde došlo k efektu tiché pošty a výsledné mediální vyjádření je zcela zavádějící a skript jednoduše promazal běžná data místo adresáře s logy.

Co k tomu říct. Zálohovat, zálohovat, zálohovat. Podobně by jim data mohl smazat nějaký hacker, vir, požár, zemětřesení apod...

Možná by stálo za to článek doplnit o pár informací, například že se ztratila pouze data z úkolů řešených na onom jednom superpočítači od 3. do 16. prosince, že ze čtrnácti výzkumných okruhů jich deset lze obnovit z jiných záloh (takže jen čtyři se ztratily definitivně) a že celkový objem záloh na Todai je asi 25 PB, takže tamní admini nejsou žádní pitomci ;-)

Otázka je či sa robí aktualizácia hromadne alebo idú postupne a ako je nastavená redundancia dát a či nie je niekoľko separátnych serverov/clusterov na rozličné úlohy.

Ono to nebude tak jednoduché. Z popisu mně není jasné, jestli to sejmulo soubory starší, než mělo nebo "jen" jiných složkách. 77TB za 10 dnů - ok, ale je to tak vždy? Třeba to je jen nějaké slabší období nebo naopak silnější, kdo ví? Předpokládám, že nějaké zálohování tam mají, ale prostě nepočítalo s právě touto eventualitou.
Jo a těm NAS: mrkněte na konfiguraci té bestie. Fakt myslíte, že by zálohování toho drobečka daly NASky za 400€? A druhý pohled, ta mašina má makat, ne zálohovat, proč "plýtvat" cenným výkonem na zálohy?
Další věc, čas: páska má 30TB, rychlost 750MB/s, to je asi 12 hodin jedna páska, potřebujete víc než dvě. Opět, nedělal byste skoro nic jiného, než zálohoval. U těch NASek, kterými jste se úspěšně ztrapnil, je to ještě horší, ty mají mnohem menší přenosovku.

Pokud procházíš megakrutopřísnohustě velké úložiště (velmi pravěpodobně tierované) se ziliony souborů a promazáváš selektivně podle stáří, tak ano, to bude trvat dlouho.

Dát si do souvislosti chybnou implementaci skriptu a postupně mizející soubory v multiuživatelském systému taky není úplně triviální.

Hovada jsou v tomto případě jednoznačně HPE, protože zvrzali implementaci, zřejmě neměli vůbec change management (nebo byl jen na papíře) a hlavně práci skriptu nelogovali a nikdo to nemonitoroval, což je při takovém nasazení naprosto klíčové.

tak to je uz nieco ine ako ze stratili komplet data na celom superpocitaci a bolo ich 77TB :)

"Smazala téměř všechny soubory starší deseti dnů" = vsetky subory, v celom pocitaci okrem poslednych 10 dni. A nemyslim, ze by bolo vhodne zalohovat to na 400€ NAS, ale principialne by to islo, ked mam 77 TB dat a 4x20TB disk)

Tohle není vůbec žádný problém. Kdo kdy něco napsal v bashi, tak tyhle zákonitosti zná - subshelly, globální, lokální proměnné. Já třeba podobným způsobem měním konfiguraci jednoho svého "mediálního" skriptu aka démona, který tak není nutno přerušovat a díky tomu vše neustále běží bez přerušování a viditelné rekonfigurace.

Problém vidím ve vyjádření HPE, protože nedává smysl.

Jenže ona ta záloha většinou jedna nestačí, zálohy musíš rotovat, takže tohle asi fakt neklapne. Navíc je tu další problém, který už nastínil Libb - rychlost. Přenést taková kvanta dat je problém, tady už narážíš nejen na rychlost síťových rozhraní, ale typicky i rychlost diskových rozhraní.

to je Unix, tam je root absolutním pánem, a tak to je správně (je to mj. skvělá věc, jak je možné za běhu měnit parametry, patchovat apod. - jen se to kruciš musí umět!).

to chápu, nicméně pokud jsou logy v /LARGE0/log, jak je možné, že došlo dle textu ke smazání logů v /LARGE0, když jsou přece jinde? Navíc logfile je čistě utilitární věc, ne něco, z čeho se budeš střílet, když o to přijdeš.