Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem
28 Jul
2016
28 Jul
'16
12:29 p.m.
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(a)goout.cz
+420 607 008 510
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(a)lists.vpsfree.cz (mailto:community-list@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:
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
http://lists.vpsfree.cz/listinfo/outage-list
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:
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
http://lists.vpsfree.cz/listinfo/outage-list
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(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
http://lists.vpsfree.cz/listinfo/outage-list
28 Jul
28 Jul
12:54 p.m.
New subject: [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(a)goout.cz
+420 607 008 510
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(a)lists.vpsfree.cz
<mailto:community-list@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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
Je odkopirovano 9.5 TB z 22 TB.
/snajpa
On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list 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(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
12:57 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
Hele produkční data tam nemám, ale to neznamená, že o ty data chci přijít :-) Jakože pak
je tam vůbec ani nemusim dávat :-)
Vojtěch Knyttl
knyttl(a)goout.cz
+420 607 008 510
https://goout.cz
On Thursday 28. July 2016 at 14:54, Pavel Snajdr wrote:
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(a)goout.cz (mailto:knyttl@goout.cz)
+420 607 008 510
https://goout.cz
On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz (mailto:Community-list@lists.vpsfree.cz)
http://lists.vpsfree.cz/listinfo/community-list
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(a)lists.vpsfree.cz (mailto:community-list@lists.vpsfree.cz)
<mailto:community-list@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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz (mailto:Community-list@lists.vpsfree.cz)
http://lists.vpsfree.cz/listinfo/community-list
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(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> > http://lists.vpsfree.cz/listinfo/outage-list
> >
>
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list
>
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
1 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
A use-case, na jaky to bylo puvodne mysleny, jsi uplne odignoroval: ie.
tvoje zaloha-zalohy. Coz je btw, jak to vetsina clenu ted pouziva a je
to tak legit.
Cili pokud by vetsina byla ok s tim, ze se to bude pouzivat dal na
zalohy-zaloh podle clenova vlastniho gusta, neospravedlnilo by to
investici do redundance, naopak by to vsem takovym uskodilo, protoze by
to zpomalilo, co mohli mit driv - 10Gbit sit.
/snajpa
On 07/28/2016 02:57 PM, Vojtěch Knyttl wrote:
Hele produkční data tam nemám, ale to neznamená, že o
ty data chci
přijít :-) Jakože pak je tam vůbec ani nemusim dávat :-)
Vojtěch Knyttl
knyttl(a)goout.cz
+420 607 008 510
https://goout.cz
On Thursday 28. July 2016 at 14:54, Pavel Snajdr wrote:
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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
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(a)goout.cz <mailto:knyttl@goout.cz>
+420 607 008 510
https://goout.cz
On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list 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(a)lists.vpsfree.cz <mailto:community-list@lists.vpsfree.cz>
<mailto:community-list@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(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
>>> http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
>> http://lists.vpsfree.cz/listinfo/outage-list
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list 
1:02 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
No, podle me aspon - kdyz o data nechci prijit, tak je mam zalohovany a nedavam je nekam
co neni zalohovany a spoleham se na to ze to nepadne na hubu ne? :D alespon muj postoj k
tomu teda :)
h00ked
Odesláno z iPhonu
28. 7. 2016 v 14:57, Vojtěch Knyttl <knyttl(a)goout.cz>cz>:
Hele produkční data tam nemám, ale to neznamená, že o
ty data chci přijít :-) Jakože pak je tam vůbec ani nemusim dávat :-)
Vojtěch Knyttl
knyttl(a)goout.cz
+420 607 008 510
https://goout.cz
On Thursday 28. July 2016 at 14:54, Pavel Snajdr
wrote:
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
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 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(a)goout.cz
+420 607 008 510
https://goout.cz
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 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(a)lists.vpsfree.cz
<mailto:community-list@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(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
>>> http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
>> http://lists.vpsfree.cz/listinfo/outage-list
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 
1:22 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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 | Email: michal(a)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(a)lists.vpsfree.cz
[mailto:community-list-bounces@lists.vpsfree.cz] On Behalf Of Pavel Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)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(a)goout.cz
+420 607 008 510
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(a)lists.vpsfree.cz
<mailto:community-list@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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
Je odkopirovano 9.5 TB z 22 TB.
/snajpa
On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list 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(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list 
1:30 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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(a)gmail.com>gt;:
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 | Email: michal(a)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(a)lists.vpsfree.cz [mailto:
community-list-bounces(a)lists.vpsfree.cz] On Behalf Of Pavel Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
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(a)goout.cz
+420 607 008 510
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(a)lists.vpsfree.cz
> <mailto:community-list@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(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
>> http://lists.vpsfree.cz/listinfo/outage-list
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/outage-list
1:36 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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(a)gmail.com <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>
[mailto:community-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel
Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
<mailto:community-list@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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz>
> <mailto:community-list@lists.vpsfree.cz
<mailto:community-list@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(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>
http://lists.vpsfree.cz/listinfo/outage-list
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
1:54 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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(a)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(a)gmail.com <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>
[mailto:community-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel
Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
<mailto:community-list@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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz>
> <mailto:community-list@lists.vpsfree.cz
<mailto:community-list@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(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>
http://lists.vpsfree.cz/listinfo/outage-list
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 
2:25 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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(a)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(a)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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
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(a)gmail.com <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>
[mailto:community-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel
Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
<mailto:community-list@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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz>
> <mailto:community-list@lists.vpsfree.cz
<mailto:community-list@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(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>
http://lists.vpsfree.cz/listinfo/outage-list
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
> http://lists.vpsfree.cz/listinfo/outage-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 
3:08 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
Za me taky radsi driv sit
On Jul 28, 2016 16:26, "David Kopecký" <davidkopeckyy(a)gmail.com> wrote:
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(a)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(a)snajpa.net> wrote:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
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(a)gmail.com <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz
> <mailto:community-list-bounces@lists.vpsfree.cz>
> [mailto:community-list-bounces@lists.vpsfree.cz
> <mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel
> Snajdr
> Sent: Thursday, July 28, 2016 2:54 PM
> To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
> <mailto:community-list@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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz
> <mailto:community-list@lists.vpsfree.cz>
>>> <mailto:community-list@lists.vpsfree.cz
> <mailto:community-list@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(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> <mailto:Outage-list@lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>>
>>>>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Outage-list mailing list
>>>>> Outage-list(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> <mailto:Outage-list@lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>>
>>>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Outage-list mailing list
>>>> Outage-list(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> <mailto:Outage-list@lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>>
>>>> http://lists.vpsfree.cz/listinfo/outage-list
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> <mailto:Outage-list@lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>>
>>> http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Community-list mailing list
>> Community-list(a)lists.vpsfree.cz
> <mailto:Community-list@lists.vpsfree.cz>
>> http://lists.vpsfree.cz/listinfo/community-list
>>
>
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz <mailto:
Community-list(a)lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 
3:15 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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:
--
-------------------------------------------------
Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01
Telefon: +420 724 330 493 | Web: http://www.reklalink.cz
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(a)gmail.com <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>
[mailto:community-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel
Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
<mailto:community-list@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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz>
> <mailto:community-list@lists.vpsfree.cz
<mailto:community-list@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(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>
http://lists.vpsfree.cz/listinfo/outage-list
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
6:59 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
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(a)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(a)gmail.com <mailto:michal.zobec.news@gmail.com>
<michal.zobec.news(a)gmail.com>>m>>:
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(a)zobec.net <mailto:michal@zobec.net> <michal(a)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(a)lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>
<community-list-bounces(a)lists.vpsfree.cz>
[mailto:community-list-bounces@lists.vpsfree.cz
<community-list-bounces(a)lists.vpsfree.cz>
<mailto:community-list-bounces@lists.vpsfree.cz>
<community-list-bounces(a)lists.vpsfree.cz>] On Behalf Of Pavel
Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz>
<community-list(a)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(a)goout.cz <mailto:knyttl@goout.cz> <knyttl(a)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(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz> <community-list(a)lists.vpsfree.cz>
> <mailto:community-list@lists.vpsfree.cz
<community-list(a)lists.vpsfree.cz>
<mailto:community-list@lists.vpsfree.cz>
<community-list(a)lists.vpsfree.cz>>z>>, 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(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>>
>>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>>
>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>>
>>
http://lists.vpsfree.cz/listinfo/outage-list
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz <Outage-list(a)lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz> <Outage-list(a)lists.vpsfree.cz>>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz>
<Community-list(a)lists.vpsfree.cz>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
<Community-list(a)lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing
listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing
listCommunity-list@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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
6:41 p.m.
New subject: [vpsFree: outage-list] NAS read-only, poskozeny filesystem
Můj názor - NAS byl deklarován jako nezálohovaný, počítám tedy s tím, že
data co jsou na něm si musím buď zálohovat sám, nebo to má být právě
naopak záloha nějakých dat ležících jinde (tj. když to klekne, mám buď
zálohu nebo originál). Pokud si pamatuji, tak v diskusi zazněly dokonce
názory, že by bylo fajn, pokud by si mohl uživatel nastavit zda chce
prostor zálohovat nebo ne (a mít např. dvojnásobek prostoru).
Přidávám se tedy k táboru peníze investovat podle původního plánu do 10G
(a případně diskutovat o tom co s NASem dál).
Díky,
Štěpán.
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(a)gmail.com <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>
[mailto:community-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel
Snajdr
Sent: Thursday, July 28, 2016 2:54 PM
To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
<mailto:community-list@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:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz
<mailto:community-list@lists.vpsfree.cz>
> <mailto:community-list@lists.vpsfree.cz
<mailto:community-list@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(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>>
http://lists.vpsfree.cz/listinfo/outage-list
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
>>
http://lists.vpsfree.cz/listinfo/outage-list
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
<mailto:Outage-list@lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
3077
days inactive
3077
days old
community-list@lists.vpsfree.cz
14 comments
12 participants
participants (12)
-
Branislav Blaskovic -
David Kopecký -
Ghormoon -
Jiří Pucherna -
kuba＠ufiseru.cz -
Martin Malec | TIERRA VERDE -
Michal Zobec (ZOBEC Consulting) -
Miroslav Marcišin -
Miroslav Šedivý -
Pavel Snajdr -
Stepan Liska -
Vojtěch Knyttl