[vpsFree.cz: community-list] NAS read-only, poskozeny filesystem

Thu Jul 28 16:59:24 CEST 2016

10Gbit

Mám tam jednu z destinací crashplanu, přišel bych nejspíše o X
předchozích verzí souborů dozadu + smazaných, co jsem neposlal do
crashplaního cloudu - ale orig data mám, takže krom mrzení s
přenastavením crashplanu bych asi ani moc nebrečel...

J

Dne Čt, 28. červenec 2016 v 16:25 h uživatel David Kopecký napsal:
> Ahoj,
>
> rozhodne puvodni plan, 10Gbit. I kdyz jsem se chystal vyuzit NAS na
> trochu citlivejsi "produkcni" veci v nasledujici dobe, tak kdyz to
> nebude rychle pristupne, je to stejne prd platne.
>
> Dik,
> David
>
> čt 28. 7. 2016 v 15:54 odesílatel <kuba at ufiseru.cz> napsal:
>> Za mě momentálně raději síť, ale redundantní NAS hned po tom. A
>> důležité je to slovo "redundantní", aby si to někdo omylem nevyložil
>> jako "zálohovaný" :)
>>
>> -m.
>>
>>
>>
>> July 28 2016 3:37 PM, "Pavel Snajdr" <snajpa at snajpa.net> wrote:
>> > Samozrejme, ze to demokraticky nakonec rozhodne ten, kdo to
>> > odmaka a ma
>> > se o to pak starat, to je jasne :)
>> >
>> > Chtel jsem spis vedet, jak moc velky hlad je po redundantnim
>> > storage
>> > mimo VPS tak, aby mohl byt napr. sdileny mezi vice VPS pro
>> > produkcni data.
>> >
>> > Zatim to az tak nevypada.
>> >
>> > Napriklad mne zajimal prave nazor Igora, jelikoz ti tam maji, o
>> > cem vim,
>> > nejprodukcnejsi vec - kdyz nepocitam nejake ty firemni owncloudy,
>> > kterezto ale klidne mohly bezet rovnou z lokalnich disku u VPS
>> > (ale to
>> > by si ti dotycni museli priplatit za zalohovany disk space, ze...).
>> > Igor Szoke ma realny duvod nemit to lokalne, protoze je to hodne
>> > dat a
>> > kdyz ani on nema tezkou preferenci smerem k redundanci NASu,
>> > je, rekl
>> > bych, vcelku jasno, kterym smerem jit.
>> >
>> > /snajpa
>> >
>> > On 07/28/2016 03:30 PM, Miroslav Šedivý wrote:
>> >
>> >> Ahoj, za me urcite 10Gbit. Preci jen NAS je bonusova vec a
>> >> ucpana sit
>> >> postihne vsechny. Neni to tak? Nejsem proti zálohování dat na
>> >> NASu, ale
>> >> urcite az po upgrade sítě. Takovahle anketa je super, ale navzdory
>> >> demokratickým pravidlům, ktera ve vpsfree panuji by se to melo
>> >> rozhodnout s nadhledem a ne podle preferenci par diskutujících.
>> >>
>> >> Míra
>> >>
>> >> Dne 28. 7. 2016 15:23 napsal uživatel "Michal Zobec (ZOBEC
>> >> Consulting)"
>> >> <michal.zobec.news at gmail.com
>> >> <mailto:michal.zobec.news at gmail.com>>:
>> >>
>> >> Mě by se taky hodilo zajistit bezpečnost dat na NAS. Sice si toho
>> >> jsem vědom, že teď nejsou zálohována, ale kapacita NAS se mi hodně
>> >> líbí (i když tak intenzivně ji nepoužívám).
>> >>
>> >> …
>> >>
>> >> s přátelským pozdravem | best regards
>> >>
>> >> Michal Zobec | Senior IT Consultant, Project Manager
>> >> Mobil: +420 608960987 <tel:%2B420%20608960987> | Email:
>> >> michal at zobec.net <mailto:michal at zobec.net>
>> >> LinkedIn | Na volne noze
>> >>
>> >> ZOBEC Consulting | Renneska trida 393/12, 63900 Brno, Czech
>> >> Republic
>> >> web | blog | virtuální pc
>> >> Facebook | Twitter | LinkedIn | Google+
>> >>
>> >> Plánovaná nepřítomnost | Planned absence
>> >> (none)
>> >> …
>> >>
>> >> -----Original Message-----
>> >> From: community-list-bounces at lists.vpsfree.cz
>> >> <mailto:community-list-bounces at lists.vpsfree.cz>
>> >> [mailto:community-list-bounces at lists.vpsfree.cz
>> >> <mailto:community-list-bounces at lists.vpsfree.cz>] On Behalf Of
>> >> Pavel
>> >> Snajdr
>> >> Sent: Thursday, July 28, 2016 2:54 PM
>> >> To: vpsFree.cz Community list <community-list at lists.vpsfree.cz
>> >> <mailto:community-list at lists.vpsfree.cz>>
>> >> Subject: Re: [vpsFree.cz: community-list] [vpsFree: outage-
>> >> list] NAS
>> >> read-only, poskozeny filesystem
>> >>
>> >> Jo, ale to mas pravdu, ze je to za tebe, na ukor rychle site pro
>> >> vsechny (a s tim spojene vyhody, ze budeme konecne tusit, proc nam
>> >> server umrel v kernel panicu a podobne, protoze budeme mit kdump).
>> >>
>> >> Jak jsem psal, NAS od zacatku nemel byt redundantni, takze
>> >> pokud ho
>> >> prave ted vyuzivas na produkcni data, delas to spatne a tenhle
>> >> hlas
>> >> bych tedy vubec nemel pocitat.
>> >>
>> >> A tak uvidime, co reknou dalsi :)
>> >>
>> >> /snajpa
>> >>
>> >> On 07/28/2016 02:29 PM, Vojtěch Knyttl wrote:
>> >>> Za mě určitě platí, že data bez redundance (ať produkční nebo
>> >>> neprodukční), jako by jich nebylo. Za mě klidně budu mít míň
>> >>> storage,
>> >>> ale bezpečnou.
>> >>>
>> >>> Vojtěch Knyttl
>> >>>
>> >>>
>> >>> knyttl at goout.cz <mailto:knyttl at goout.cz>
>> >>>
>> >>> +420 607 008 510 <tel:%2B420%20607%20008%20510>
>> >>>
>> >>> https://goout.cz
>> >>>
>> >>>
>> >>> On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:
>> >>>
>> >>>> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny
>> >>>> prepneme
>> >>>> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
>> >>>> bezpecnejsi konfiguraci.
>> >>>> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
>> >>>> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a
>> >>>> uvidime, co z toho vyleze, stejna konfigurace se potom casem
>> >>>> pouzije
>> >>>> i pro backuper, abychom se vyhnuli stejne situaci v budoucnu na
>> >> backuperu.
>> >>>>
>> >>>> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie.
>> >>>> 3-diskove
>> >>>> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox
>> >>>> vznikly s malo disky a ZFS neumi reshape poli, pridavanim
>> >>>> bezpecnejsich VDEVu bychom nic neziskali, protoze ten VDEV,
>> >>>> ktery se
>> >>>> rozbil, byl hned ten druhy v poradi, ktery tam byl uz pri prvnim
>> >> vyrobeni pole.
>> >>>>
>> >>>> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by
>> >>>> tragicky nestihalo na IOPS.
>> >>>>
>> >>>> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam
>> >>>> prebylo
>> >>>> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror
>> >>>> zaloham a nechteli jsme ho nechat valet jen tak, proto jsme ho
>> >>>> zpristupnili vsem a od zacatku rikali, ze neni zalohovane -
>> >>>> mysleli
>> >>>> jsme si, ze to pole vyuzijete na zalohy domacich dat a podobne,
>> >>>> coz
>> >>>> tedy vetsina udelala, ale...
>> >>>>
>> >>>> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni
>> >>>> data a
>> >>>> ted je cekalo velmi neprijemne prekvapeni.
>> >>>>
>> >>>> Cili ted stojime pred rozhodnutim, jestli investovat do
>> >>>> redundance
>> >>>> NASu (a backuperu s tim), nebo jit podle puvodniho planu a
>> >>>> upgradovat
>> >>>> sit na 10Gbit (coz je potreba pro lepsi debugovatelnost
>> >>>> clusteru,
>> >>>> kvuli kdumpu; a taky jsem se chystal nejak vyresit replikaci dat
>> >> mezi nody).
>> >>>>
>> >>>> Co si o tom myslite? Investovat do storage a nechat to zatim na
>> >>>> 2Gbit
>> >>>> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s
>> >> propustnosti)?
>> >>>>
>> >>>> Poznamecka: prosim ujistete se, ze v odpovedi je To:
>> >>>> community-list at lists.vpsfree.cz
>> >> <mailto:community-list at lists.vpsfree.cz>
>> >>>> <mailto:community-list at lists.vpsfree.cz
>> >> <mailto:community-list at lists.vpsfree.cz>>, na outage-list se musi
>> >>>> prispevky schvalovat a mely by tam jit jenom relevantni
>> >>>> informace o
>> >>>> vypadcich, ne diskuze.
>> >>>>
>> >>>> /snajpa
>> >>>>
>> >>>> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
>> >>>>> Je odkopirovano 9.5 TB z 22 TB.
>> >>>>>
>> >>>>> /snajpa
>> >>>>>
>> >>>>> On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
>> >>>>>> Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11
>> >>>>>> hodin,
>> >>>>>> odhadem to znamena, ze se bude syncovat jeste cca dalsich 30
>> >>>>>> hodin.
>> >>>>>>
>> >>>>>> Behem toho je NAS dostupny jenom jako read-only.
>> >>>>>>
>> >>>>>> Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz
>> >>>>>> uz by
>> >>>>>> melo jit rychleji (backuper ma vic disku, nez na kolika ma
>> >>>>>> data
>> >>>>>> soucasny nasbox, cili zpatky to pojede rychleji).
>> >>>>>>
>> >>>>>> Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo
>> >>>>>> vsechna data zahodit a vyrobit na nem pool znova - a to, i
>> >>>>>> kdyz
>> >>>>>> vsude piseme, ze neni zalohovany, nam prislo jako mnohem horsi
>> >>>>>> varianta, nez ho odstavit na par dni jako read-only.
>> >>>>>>
>> >>>>>> Odkopirujte si prosim data na VPSky, pokud je aplikace
>> >>>>>> potrebuji,
>> >>>>>> kdo kvuli tomu potrebujete docasne zvednout misto na disku,
>> >>>>>> napiste
>> >>>>>> na podporu a pokusime se to nejak vyresit.
>> >>>>>>
>> >>>>>> Pokud ta data nepotrebuji aplikace k behu, tak na to prosim
>> >>>>>> nesahejte, od toho to syncujeme na backuper, abychom
>> >> zachranili, co se da.
>> >>>>>>
>> >>>>>> Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda
>> >>>>>> se,
>> >>>>>> opravdu jenom 58 souboru (a to jeste ne uplne, ale maji
>> >>>>>> poskozenych
>> >>>>>> par bitu, coz se napr. u obrazku da jeste prezit - vs. ztratit
>> >> je uplne).
>> >>>>>>
>> >>>>>> /snajpa
>> >>>>>>
>> >>>>>> On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
>> >>>>>>> Ahojte,
>> >>>>>>>
>> >>>>>>> na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu
>> >> s daty.
>> >>>>>>>
>> >>>>>>> Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-
>> >>>>>>> pole) po
>> >>>>>>> umrti jednoho disku, kdy dalsi disk ze stejneho vdevu zacal
>> >>>>>>> hlasit
>> >>>>>>> chyby pri cteni. Evidentne od posledniho scrubu (cca mesic
>> >>>>>>> zpatky)
>> >>>>>>> na nem vznikly neopravitelne oblasti, ktere nejdou precist.
>> >>>>>>>
>> >>>>>>> Zatim vime o 58 neobnovitelnych souborech, je to ve stavu,
>> >>>>>>> kdy ten
>> >>>>>>> disk dava nejaka data, cili to nevypada ze by bylo po datech,
>> >>>>>>> ale
>> >>>>>>> vic se dozvime, jakmile dobehne sync z nasboxu na backuper.
>> >>>>>>>
>> >>>>>>> Prepnul jsem nasbox do readonly rezimu, aby se predeslo
>> >>>>>>> dalsimu
>> >>>>>>> poskozovani dat a mezi tim se data syncuji na backuper
>> >>>>>>> (aktualne
>> >>>>>>> to jede okolo 150MB/s a je to 22TB dat).
>> >>>>>>>
>> >>>>>>> Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s
>> >>>>>>> bezpecnejsi konfiguraci, aby se podobne situaci predeslo a
>> >>>>>>> pool
>> >>>>>>> vydrzel umrti vic disku ve vsech pripadech.
>> >>>>>>>
>> >>>>>>> Tem, co se jich poskozena data tykaji, napiseme behem dne
>> >>>>>>> mail se
>> >>>>>>> seznamem poskozenych souboru.
>> >>>>>>>
>> >>>>>>> Budu dal updatovat o prubehu, jakmile bude dalsi progress.
>> >>>>>>>
>> >>>>>>> /snajpa
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> Outage-list mailing list
>> >>>>>>> Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>
>> >> <mailto:Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>>
>> >>>>>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Outage-list mailing list
>> >>>>>> Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>
>> >> <mailto:Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>>
>> >>>>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Outage-list mailing list
>> >>>>> Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>
>> >> <mailto:Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>>
>> >>>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>> _______________________________________________
>> >>>> Outage-list mailing list
>> >>>> Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>
>> >> <mailto:Outage-list at lists.vpsfree.cz
>> >> <mailto:Outage-list at lists.vpsfree.cz>>
>> >>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Community-list mailing list
>> >>> Community-list at lists.vpsfree.cz
>> >> <mailto:Community-list at lists.vpsfree.cz>
>> >>> http://lists.vpsfree.cz/listinfo/community-list
>> >>>
>> >>
>> >> _______________________________________________
>> >> Community-list mailing list
>> >> Community-list at lists.vpsfree.cz <mailto:Community-
>> >> list at lists.vpsfree.cz>
>> >> http://lists.vpsfree.cz/listinfo/community-list
>> >>
>> >> _______________________________________________
>> >> Community-list mailing list
>> >> Community-list at lists.vpsfree.cz
>> >> http://lists.vpsfree.cz/listinfo/community-list
>> >
>> > _______________________________________________
>> > Community-list mailing list
>> > Community-list at lists.vpsfree.cz
>> > http://lists.vpsfree.cz/listinfo/community-list
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
> _________________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20160728/539019e4/attachment-0002.html>