QNAP TS-410, TS-412 data recovery

Sziasztok,
van valakinek tapasztalata QNAP TS-410 , 412-es NAS-ok valamelyikevel, hogy hogyan viselkednek aramszunet, vagy diszk kieses eseten?
Diszkeket raid5-be szeretnek ossze huzni (FS=ext3), de mivel fontos hogy a rajta levo adat valamilyen modon 1 diszk halala eseten tutira visszanyerheto legyen, gondoltam feldobom itt ezt a postot hogy van-e tapasztalat.

pl hogy viselkedik egy ilyen rendszer aramszunet eseten? (ok, lesz UPS, de megis... mire szamitsak?)

dolt mar be valakinek ilyen?

Hozzászólások

Backup nélkül ne indulj neki, bármekkora is a diszk tömböd. Ha lehet csekkold, hogy az ext3-at legalább ordered módon csatolja fel és ha paranoid vagy akkor kapcsold be a journal módot. RAID5-nél a papírforma, hogy egy diszk kiesését csak valamilyen értesítővel veszed észre. A spare diszk az kötelező, mert úgyis péntek este 11-kor fog kihalni, amikor igen nehéz csak úgy venni egyet a boltban, viszont ha van spare, akkor csak cseréled (a papírforma szerint) és újraépül a tömböd.

Hali, koszi! ezt az ordered mod opciot megnezem, bar nem lattam ilyet a config opciok kozott.
"kapcsold be a journal modot" alatt mit ertesz? eleve journaling fs az ext3. elvileg akkor fogok rola tudni ha mar megdoglott a diszk, tehat ha pirit a ledje. jo esellyel akkor lesz csere. spare alapveto, en is igy gondoltam.

--
{ Nem is kernel az, ami nem fut el egy quartz órán }

:) Igen csak a naplózásnak több szintje van. Van writeback (gyakorlatilag 0 napló), van ordered (metaadat napló) és van journal (ami a teljes journal).

http://en.wikipedia.org/wiki/Ext3

A disztrók az ordered-et szokták alapból választani, mert már alapvetően véd és a sebessége is jobb. Tehát a kérdés, hogy a QNAP-nál mi az alap, illetve ha iSCSI-n fogod használni, akkor te adod meg, hogy mi legyen.

na igen, a masik nagy kerdes... iSCSI. szep es jo, nagyon jol hasznalhato, csak ezzel sem tudom mi van ha pl megmekken a firmware valamiert a dobozon es hegeszteni kell. vajon mi lesz akkor az iscsi lun-jaimmal, es a rajtuk levo adattal. erosen gondolkodom azon hogy mielott prod-ba rakok egy ilyet, brutal mod le fogom tesztelni mindenfele katasztrofa esetere :) aztan lehet hogy kuka lesz a vegen a doboz :)

bájdövéj:

/dev/md0 on /share/MD0_DATA type ext3 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,acl)

--
{ Nem is kernel az, ami nem fut el egy quartz órán }

Ez engem is érdekel... csak nekem Synology DS-411j kapcsán ami ma este érkezik.

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

TS509-et ismerem.
Ott elindul a rebuild.
És van rajta -talán- Net-ups is, így a leállítás is könnyen megoldható.

Sajnos itt kicsit tobbrol van szo mint "elvileg" -rol. elvileg persze, rebuild-elodik egy raid5 diszkcsere utan, gyakorlatilag viszont olvastam par qnap-os cikket siro juzerekrol akiknel az "elvileg" nem jott be.
masreszrol meg anno olvastam zdnet-en egy cikket sata diszkekrol, es a sata szabvanyrol mint olyanrol, es arrol hogy bizonyos sata-ra jellemzo diszk hibak eseten 1 diszk kiesese eseten is fakereszt az adatodnak raid5-on..... majd megkeresem azt a cikket.

nu megtalaltam (ok, nem mai, de a szabvany nem sokat valtozott imho):

http://www.zdnet.com/blog/storage/raidfail-dont-use-raid-5-on-small-arr…

--
{ Nem is kernel az, ami nem fut el egy quartz órán }

Egy kicsit szenzációhajhásznak érzem ezt. Attól, hogy URE lesz, attól még újra fog próbálkozni a vezérlő és csak tényleges badblock esetén fogod bukni a raid-ed. Mivel 12,5TB-ot ír papíron 20% körüli esélyed van 2TB-os vinyóknál egy ilyenre futni.

A rendszeres backupot RAID-el még mindíg nem lehet kiváltani. Arra is elég naiv számítani, hogy tetszőleges storage-el sose, de sose lesz semmilyen diszktömb összeborulási probléma.

Egyébként a dolog elég egyszerű. Fogod a tömböd (persze mindezt teszt adatokkal és jeleggel) és kiszedsz egy vinyót. Írsz mindenfélét, törölsz mindenfélét és visszateszed a kivett diszket. Itt rögtön ki fog derülni, hogy rendben elindul-e, lefut-e és hogy mennyi idő alatt fut le a rebuild.

Ha nincs sok adat tudsz menteni külső diszkre, amit csak időszakosan indítasz el. Ha sok az adat akkor érdemes kettőzni az eszközt és akár néhány órás közökkel valamilyen módon szinkronizálni. A fontosabb adatokat pedig e mellett is lehet adott rendszereséggel külső vinyóra vagy DVD-re írni.

ok, ezzel en is tisztaban vagyok, epp ezert is irtam az "elvileg"-et az elozo postomban, es ezert is erdekel hogy valakivel tortent-e mar hasonlo, es akkor rendben volt-e a recovery. ha nem, milyen problemak leptek fel,es azokra mi volt a megoldas es hogy mire lehet szamitani. altalaban az elet felulirja a nagykonyvet ....
nyilvan en is fogok tesztelni go-live elott, de mindenre en se tudok felkeszulni. ez volt az ertelme ennek a postnak.

--
{ Nem is kernel az, ami nem fut el egy quartz órán }

Linuxos softraid-del már többször rebuildeltem mindenféle méretű tömböt (320GB-os RAID1-től a 6x2TB-os RAID5-ig) és még sosem sikerült ilyen SATA URE hibára futni. Olyan már volt, hogy hibás SATA kábel miatt nem ment a rebuild (adott %-nál megállt és kivágta a diszket), de kábelcsere után szépen elkészült a tömb.

koszonom. ez egy hasznos info.
en is buildeltem es recovereltem mar md-ket r1-et es r5-ot egyarant, es nem futottam problemaba. persze ez koszonheto a minosegi hardvernek is szerintem ami a diszkek alatt van. konkretan hogy ez a doboz hogy toleralja az ilyesmit, ez mostt itt a nagy kerdes.
--
{ Nem is kernel az, ami nem fut el egy quartz órán }

Ha már softraid, miért éri meg RAID1 "helyett" RAID5-öt használni? A softraid-et eleve olyan "semmilyen RAID-nek" érzem. Meg valaki írta a múltkor itt a fórumon hogy _szofvteres_ RAID-5tel "sikeres ember nem lehetsz".

Nem kötözködés, tényleg érdekelne! (ÉS nem mintha nekem lenne pénzem RAID kártyára.)

színes aláírás

itt megjegyeznem, hogy akkor ha raid5-ot akarsz, mindjart 2 raid-controllert veszel? :) ha megdoglik a meregdraga controllered, kb fakereszt a tombodnek :)
en szeretem az md-s megoldasokat, mert konnyeden lehet rola adatot visszanyerni,(ha esszel csinalja az ember) es kvazi controller fuggetlen.

--
{ Nem is kernel az, ami nem fut el egy quartz órán }

TS-410 van a kezeim ügyében.
Gyakorlatilag áramszünet esetén kicsit tovább tart a boot, ennyi amennyit észlelek. Ha sikeresen eltalálod a diszket nem hiszem hogy probléma lesz. Jól nézd meg a kompatibilitási listát mielőtt diszket választasz bele.
Összegezve nekem pozitiv tapasztalataim vannak velük eddig. Ha a legkisebb diszkprobléma is van (pl. SMART realloc) monitoring jelez, döglött diszk kihúz, keret átrak, jó diszk be, felpörög és pár mp múlva elkezdi a rebuildet. Közben a NAS végig online, tartalék diszk van polcon mindig 1-2.

Kb. 4-5 perc körül van a normál boot ha már megtörtént az initial striping. HD204UI-val nekem ez kicsivel több mint 1 napot jelentett mindegyik TS410-nél, ezalatt folyamatosan ment. Egyébként a hdparm 80MB/s a kötetre, ez az idő azért annyi amennyi mert az md max rebuild speed le van limitálva 20MB/s-re. Ezzel már végzett?

A HD204UI-hoz feltetted az írási problémákat okozó firmware frissítést?

Nálam a boot idő nem gond, 7/24-ben mennek.

Hali, hat, nem raktam fel a frissitest mert sajna csak most ertesultem rola hogy van ilyen. van egy spare diszkem a polcon, gondoltam hogy arra felteszem aztan egyesevel kicserelgetem a diszkeket es mindegyikre felrakom. kerdes hogy erdemes-e. eddig meg nem volt adatvesztesem a hianya miatt. ha a sebessegre is hatassal van, akkor mindenkepp erdemes volna amugy. te mit gondolsz?
ami azt illeti nekem is 7x24-ben megy, csak akkor lovom le ha elutazok.

rebuild speed-et hol limitaltad le? nekem mirrorrol raid5-re konvertalas kb 10-12 oras tortenet volt, de nem volt kecmec ki kellett varni. a boot viszont kegyetlen lassu.... nekem ez a 8-10 perc kicsit scary.
masik nyugom hogy samba share-ek adott timeout utan leszakadnak w7 alatt ha nem hasznalom oket. ez persze lehet hogy w7 beallitas kerdes, csak neha idegesito hogy egy share-hez csatlakozni 2-3 sec-be is beletelik.

--update : most nezem hogy az en diszkjeim HD204UI 1AQ1 az issue pedig elvileg csak az F4EG -t erinti.

--
{ Nem is kernel az, ami nem fut el egy quartz órán }

Ha a QNAP azt mondja (lásd Note 10) hogy rakd fel a firmware patch-et mert csak így működik a cuccommal rendesen, valamint vannak akik szerencsétlenül jártak a patch nélkül, én bizony frissítek. Nagyobb hezitálás nélkül.
Az 1AQ1 a firmware verzió, az F4EG azonban a modell afféle belső gyári jelölése. Az 1AQ1 biztosan patchelendő amennyiben 2011 január előtti a gyártási dátuma, azonban olvastam már hogy a januáriak között is volt bugos. Sajnos a firmware verziót nem emelték a patchelt firmware-en, ezért annak meg- vagy nemtörténtét utólag nem lehet megállapítani. A jó hír az, hogy ha bugos ha nem, ha frissítve volt ha nem, az fwpatch akár ismételt futtatása nem árt a meghajtónak. Természetesen backup mindig legyen.

Az említett rebuild speed limit a hivatalos QNAP firmware-ben van benne, azt nem én határoztam meg. Egyébként a dm egyik standard szolgáltatása, valahogy így lehet játszani vele.

Windows 2008 R2-vel én nem tapasztaltam problémát SMB használatakor, gondolom Windows 7 alatt sem kellene, mondjuk az otthoni csoport feature nem tudom mennyire zavarhat be.