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

Branislav Blaskovic blaskovic.branislav at gmail.com
Thu Jul 28 20:59:50 CEST 2016


Taktiez pouzivam ten NAS na owncloud. Mam tam ale hromadu dat, takze si
platim rozsirenie na 500G. Ani som nevedel, ze je mozne rozsirit disk
VPSky, ako tu niekto pisal a mal by som to so zalohami a rychlejsie. Vzdy
sa tu pisalo, ze je to vsetko robene tak, ze sa to da lrn nasobit, ale
uprimne 4x viac cpu/ram nepotrebujem, stacil by disk :)

Takze aka je cena rozsirenia na 500G?

Alebo kde prevadzkujete owncloud vy? Som to mal predtym na wedos disku a
bolo to priserne pomale.

Brano

Dňa 28.7.2016 17:16 používateľ "Jiří Pucherna" <pucherna at reklalink.cz>
napísal:

> Tak ja osobne nevidim duvod proc nemit na tom NASu treba prave ten
> owncloud. Pokud to slouzi treba jako u nas pouze k synchronizaci a stejne
> mam celej ten obraz na kazdem pc kde to pouzivam tak me vypadak nebo i
> smazani nejak zavazne nezasahne.
>
> J.
>
> Dne 28.7.2016 v 15:36 Pavel Snajdr napsal(a):
>
> 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> <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> <%2B420%20608960987> | Email:
>     michal at zobec.net <mailto:michal at zobec.net> <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> <community-list-bounces at lists.vpsfree.cz>
>     [mailto:community-list-bounces at lists.vpsfree.cz <community-list-bounces at lists.vpsfree.cz>
>     <mailto:community-list-bounces at lists.vpsfree.cz> <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> <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> <knyttl at goout.cz>
>     >
>     > +420 607 008 510 <tel:%2B420%20607%20008%20510> <%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> <community-list at lists.vpsfree.cz>
>     >> <mailto:community-list at lists.vpsfree.cz <community-list at lists.vpsfree.cz>
>     <mailto:community-list at lists.vpsfree.cz> <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> <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz> <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> <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz> <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> <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz> <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> <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz <Outage-list at lists.vpsfree.cz>
>     <mailto:Outage-list at lists.vpsfree.cz> <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> <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> <Community-list at lists.vpsfree.cz>
>     http://lists.vpsfree.cz/listinfo/community-list
>
>
>
> _______________________________________________
> Community-list mailing listCommunity-list at lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
>
>
>
> _______________________________________________
> Community-list mailing listCommunity-list at lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
>
>
>
> --
> -------------------------------------------------
> Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01
> Telefon: +420 724 330 493 | Web: http://www.reklalink.cz
>
>
> _______________________________________________
> 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/dc2fd737/attachment-0002.html>


More information about the Community-list mailing list