Synology 4x3TB RAID5 osszeborult (kidobott 2 lemezt, habar 100%-osak), mdadm HELP:(

( Konflikt | 2018. 09. 27., cs - 11:08 )
Linux-kezdő

sziasztok
inkabb ide nyitnam, talan ez jobban porog mint a HW resz/halado linux/etc.
hardware
Synology SHR tomb (RAID5), 4db WD30EFRX lemezzel, UPS-el, utolso DSM 6.2-23739 U2, DS1812+ (8 helyes, de az elso 4 hasznalt)

mi tortent?
kb. 5 eve hibatlan, minden lemez SMART-ja 100% (hetente fut check amirol mail is jon) mig ket napja reggel: degraded-e valt tomb, disk3 kiesett. majd fel ora mulva a disk1 is, a tomb crashed.
adatokat nem erek el , nem javithato GUI-rol
habar mentesem van az adatok egy reszerol, megis inkabb visszallitanam mert van amirol nincs

amit eddig neztem
synology mdadm-et hasznal a raid-hez es mivel az SSH nyitva lehet vizsgalodni.
mind a 4 lemez elejen van egy RAID1 tomb, amin a DSM fut, igy a NAS elerheto (hiszen 4 lemezes RAID1-bol 2 lemezzel meg megy a felulet)
a 4 lemez vegen van az adat, sd[a-d]5 neven.
amire jutottam, hogy a disk1 es disk3 kiesett a tombbol, az
ash-4.3# mdadm --examine /dev/sd[a-d]5
a kovetkezoket irja:

/dev/sda5:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 69622400:693b9a36:2af8228a:d0393314
Name : syno:2
Creation Time : Sat Jul 13 11:26:04 2013
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 5851063680 (2790.00 GiB 2995.74 GB)
Array Size : 8776594944 (8370.01 GiB 8987.23 GB)
Used Dev Size : 5851063296 (2790.00 GiB 2995.74 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=384 sectors
State : clean
Device UUID : 460bd27e:d09e1718:63d19454:bf277dff

Update Time : Tue Sep 25 07:29:34 2018
Checksum : 3efbb167 - correct
Events : 3057

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
ash-4.3#
ash-4.3# mdadm --examine /dev/sdb5
/dev/sdb5:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 69622400:693b9a36:2af8228a:d0393314
Name : syno:2
Creation Time : Sat Jul 13 11:26:04 2013
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 5851063680 (2790.00 GiB 2995.74 GB)
Array Size : 8776594944 (8370.01 GiB 8987.23 GB)
Used Dev Size : 5851063296 (2790.00 GiB 2995.74 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=384 sectors
State : clean
Device UUID : 723deeb7:c8dac42c:e3c5dc78:aaea39a8

Update Time : Mon Jan 1 01:01:44 2001
Checksum : 3871db71 - correct
Events : 3911

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 1
Array State : .A.A ('A' == active, '.' == missing, 'R' == replacing)
ash-4.3#
ash-4.3# mdadm --examine /dev/sdc5
/dev/sdc5:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 69622400:693b9a36:2af8228a:d0393314
Name : syno:2
Creation Time : Sat Jul 13 11:26:04 2013
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 5851063680 (2790.00 GiB 2995.74 GB)
Array Size : 8776594944 (8370.01 GiB 8987.23 GB)
Used Dev Size : 5851063296 (2790.00 GiB 2995.74 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=384 sectors
State : clean
Device UUID : e8c248ae:5952d338:eb00a42f:7e634431

Update Time : Tue Sep 25 07:36:48 2018
Checksum : 9c058cc8 - correct
Events : 3887

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 2
Array State : .AAA ('A' == active, '.' == missing, 'R' == replacing)
ash-4.3#
ash-4.3#
ash-4.3# mdadm --examine /dev/sdd5
/dev/sdd5:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 69622400:693b9a36:2af8228a:d0393314
Name : syno:2
Creation Time : Sat Jul 13 11:26:04 2013
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 5851063680 (2790.00 GiB 2995.74 GB)
Array Size : 8776594944 (8370.01 GiB 8987.23 GB)
Used Dev Size : 5851063296 (2790.00 GiB 2995.74 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=384 sectors
State : clean
Device UUID : 2e78b8f8:1c22e530:a920f401:3c2b218f

Update Time : Mon Jan 1 01:01:44 2001
Checksum : ed5af8da - correct
Events : 3911

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 3
Array State : .A.A ('A' == active, '.' == missing, 'R' == replacing)
ash-4.3#

amint latszik, az eventek nincsenek olyan messze egymastol 3 lemezen, mig a disk0 az nagyon lemaradt. allitolag 50 event kul. alatt meg osszerakhato
sda5: 3057
sdb5: 3911 ->3917
sdc5: 3887
sdd5: 3911 ->3917

a tomb allapota pedig:
ash-4.3# mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Jul 13 11:26:04 2013
Raid Level : raid5
Array Size : 8776594944 (8370.01 GiB 8987.23 GB)
Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
Raid Devices : 4
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Wed Sep 26 07:01:44 2018
State : clean, FAILED
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

Name : syno:2
UUID : 69622400:693b9a36:2af8228a:d0393314
Events : 3917

Number Major Minor RaidDevice State
- 0 0 0 removed
1 8 21 1 active sync /dev/sdb5
- 0 0 2 removed
3 8 53 3 active sync /dev/sdd5
ash-4.3#

kerdesem tehat
hogy raknatok ossze? a tomb /dev/md2 , neten tobbhelyen
mdadm --create -tel vagy
mdadm --assemble -vel csinaltak hasonlokat, de jelenleg nem mertem raengedni nem visszafordithato muveletet. habar a supportnak irtam reszeltesen, 2 nap alatt nem valaszoltak semmit:(

koszi elore is barmilyen segitseget

update 09.27:
ajanlasra veszek lemezeket, amire ki tudom menteni mind a 4 disk tartalmat. kozben a support is valaszolt, kertek remote hozzaferest (SSH-t is) de nem adtam meg nekik amig nincs a jelenlegi allapotrol mentesem. tovabba RAM tesztet, logokat, extended SMART testet is kert.
update 09.29:
2db 8TB-os lemez rendelve, kedden (10.02) lesznek nalam.
update 10.01:
a ket darab 8 TB-os lemez elobb erkezett egy nappal, mar megy a dd. ugynezki 6-7ora/lemez
update 10.02:
elso 3TBos lemez dd-je kesz, 7 ora alatt. fut a masodik.
update 10.03:
lementek a dd-k, support keresei is (full SMART teszt - kb 7ora/lemez, 4 oras RAM teszt - minden hibatlan)
update 10.04:
suppportra varok

update 10.08:
support osszerakta, megy a sync, reszeltek kesobb:)

  • 3634 megtekintés

( hawk | 2018. 09. 27., cs - 12:08 )

Kezd azzal, hogy...
1. DD/DDRESCUE programokkal minden diszkről egyesével készítesz mentést.
2. Az eredeti diszkeket felcimkézed és elteszed páncélszekrénybe :D
3. Az elkészült mentésekből csinálsz munka másolatot és azzal teszel bármit.

0 szavazat

10Tbyte diszk ~90-100e HUF.... a teljes művelethez ebből 2-3 db kell. össz költség 200-300e FT. (tömöríteni is lehet ám az imaget)
Számoljuk ki mennyit is veszít az ember ha mondjuk elveszik az adat? Mondjuk céges környezetben...
De akár csak otthoni környezetben is mondjuk a pótolhatatlan családi fotók..... amik a biztosnak hitt RAID 5-ben csücsülnek.....

0 szavazat

--create nem játszik, azzal új tömböket hozhatnál létre.
--assemble lesz amivel érdemes próbálkozni, ott majd kellhet egy --force, hogy a lemaradt diszket is beerőltesse. Próbálkozz akkor a kevésbé lemaradt diszkkel. Ha összeállt valami akkor arra mindenképpen menjen egy fsck...
Én is készítenék teljes image mentést mielőtt nekikezdenék.

0 szavazat

Adatmentés esetén a lemezek költsége elhanyagolható a mentendő adatokhoz képest.
Akinél ez nem így van, ott azok az adatok nem is annyira fontosak....

hint: az adatmentő cég sem fog neked ajándékba diszkeket venni, hogy megmentse a régiről az adataidat.
Ha viszel nekik cserediszkeket, utána is nagyon erősen a zsebedbe kell nyúlni, hogy visszakapd az adataidat.

szerintem.
--
zrubi.hu

0 szavazat

Hát nekem évekkel ezelőtt kb. 1,6 TB hiányzó adat "recovery"-ért, hosszas alkudozás után 400 ezer lett volna a munkadíj! (Syno, 5 lemez, RAID 6) - Persze 98% hogy menthető lett volna. - (Soha, azóta sem kellett azon elvesztett adatokból semmi.) Nem írtad, hogy ext4 v. btrfs partición volt-e?

0 szavazat

--assemble lesz amivel érdemes próbálkozni, ott majd kellhet egy --force, hogy a lemaradt diszket is beerőltesse.

Ha csak egy van lemaradva, nem kell azt egyből beleerőltetni. Hiszen 1 diszk kiesését még tolerálja a tömb. Összerakod a 3 másikból, ekkor van esély, hogy a filerendszer összeáll, és le tudod menteni.
Vagy ha tényleg nincs baja a diszkeknek, akkor majd a 4-et üres állapotban új diskként hozzáadhatod.

--
zrubi.hu

0 szavazat

( goodbyte (veterán) | 2018. 09. 27., cs - 16:10 )

subs.

------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

0 szavazat

Linkeljük már ezt is pls :)

https://www.zdnet.com/article/why-raid-5-still-works-usually/

Meg válasszuk szét az otthoni médiatárolást a bármi mástól

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

0 szavazat

( Konflikt (veterán) | 2018. 09. 27., cs - 16:36 )

na most 2 nap utan a support kert remote hozzaferest SSH-val.
nemet a srac, hat most jokerdes hogy mentes elott engedjem neki, de addig szereznem kene HDD(ke)-t meg kiirni 12TB adatot..

0 szavazat

( zeller | 2018. 09. 27., cs - 16:42 )

A RAID5 mentés nélkül orosz rulett, pláne egy kupacból beszerzésre került kommersz diszkekkel. Hot spare-rel esetleg lehet növelni a megbízhatóságot, de az sem életbiztostás.
Elvileg, ha minden diszk olvasható az elejétől a végéig, adatmentéssel foglalkozó cégek össze tudják neked rakni a tömböt, illetve le tudják róla menteni az adataidat, de ez nem home usereknek szánt árkategória, pláne ekkora méret, illetve raid-tömb esetén.

Ahogy előttem is írták, menteni a jelenlegi állapotot, és legalább egy példányban elrakni, mielőtt bármit is elkezdenél rajta módosítani. Az ehhez beszerzendő plusz diszkek meg jók lesznek a mostani raid5 tömbből valami értelmes/megbízható (raid10 vagy épp raid6) tömböt összerakni :-P

0 szavazat

lemezek 100%-osak tovabbra is, azt nem irtam talan a nyitoban de atraktam gepbe, a SMART hibatlan. egyszeruen kidobta a tombbol a lemezt, latszolag nincs HW problema. Hot spare se ert volna sokat, hiszen fel ora kul-el dobta ki a ket lemezt.
mentesem van, a fontos adatokrol (majdnem mindenrol) egy xpenology-n, de azt be nem kapcsolom most.
szoval kinek van 2x8TB lemeze elado?

0 szavazat

alaplapon nem csati van hanem egy backplane PCB amire ra lehet tolni a diskeket mint egy normalis storage eseteben.
ez szerintem nem tud kilazulni, eleg szoros es le is volt zarva a disk fiok.
synology se hw raid (nincs kulon RAID vezerlo RAMmal, CPU-val es BBU-val), hanem egyszeru SATA controller felett sw linux RAID-et keszit.

0 szavazat

Főként úgy orosz rulett, hogy az azonos szériából rakja össze az ember...
...még okosba rak hozzá hotspare-t is és azt gondolja ezek után, hogy minden szipiszupi....
diszkek pörögnek éveket ... 1 lehal és elkezd szinkronizálni a HotSpare-re ... Murhpy törvényei pedig előjönnek.

Jártam már így én is... tanulságos volt... azóta Raid 6 + külső merevlemezre backup (ami a mentést leszámítva offline)

- Raid az nem biztonsági mentés
- Raid 5 max veszthető adat alá
- terheléstől függően 1-2 évente 1-2 diszk cseréje újra, rotációban
- rendszeres biztonsági mentés

0 szavazat

ezekkel mind egyet is ertek es eszerint is jartam. (van ketnaponta mentesem a fontosakrol, nem backup-nak hasznalom, a lemezek cserejet a telre terveztem)
HS nem volt, mert otthonra luxus lenne, ill. nem segitett volna. 30perc volt a ket lemez kiesese kozott, nem lett volna eleg 3TB-nak.
egyedul a RAID5 mint nem "jo" RAID a kerdojeles, de most mar hogy a nagy kapacitasu lemezek is elerhetobbek valszeg ket lemezes RAID1 lesz.
az egy "alomrol" pedig tovabbra is: mindegyik lemez 100%-os, latszolag nincs disk hiba.

termeszetesen koszonom az eddigieket es a tovabbiakat is.

0 szavazat

gyenge tap, hibernalas issue-k nem lehettek? nekem nagyon gyanus hogy 5 ev alatt fel ora kul-el kivagott ket lemezt. nem hiszek a veletlenekben, itt szerintem nem disk hiba lesz. raadasul elozo nap este 11-kor mar kidobta az egy lemezes datastore-t, amire ket kamera rogzitett. azokert bar nem kar, de a lemez egy 250GB-os seagate, teljesen mas kategoria. de szinten 100%os a SMART-ja egy masik gepben.

0 szavazat

Ne ket ugyanolyan, eggyel eltero sorozatszamu cserediszket tegyel a RAID1-edbe. Mivel a teljes eletutuk megegyezik, pont mar nem lesz jo allapotban a masik sem, amikor az egyik kidol. Marpedig meg var ra egy nagy feladat, a szinkronizacio.

Ha a backupod nehezen elerheto (lassu offsite, vagy fizetni kell a visszatoltesert, stb.), akkor akar a harom labu RAID1 is megeri.

Es a RAID5-ot tenyleg sokan kiprobaljuk, hogy aztan rajojjunk, hogy koszi tobbet ne. Vagy adatvesztes, vagy performancia okokbol.

0 szavazat

Nekem ezért (is) lett unRAID 4 diszkre (4x3TB, 3x3TB usable), bármelyik diszk kiesik akkor a többi tartalma még elérhető, értelemszerűen 2 diszk kiesése esetén ez sem segít, de a maradék tartalma még mindig elérhető.

Szól még pár érv az unRAID mellett, de ez az ami témába vág.
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

0 szavazat

Raid 5,6 azért szerencsétlenebb picit mert ott nem tudod kinyerni az adataid egy részét se egyszerű eszközökkel.
Viszont egy Raid 1-es kötetből ha mindkét diszk kiesik, akkor is még egész jó sanszod van rá, hogy legalább
az adatok egy részét le tudod olvasni. Főleg akkor ha csak valami kisebb, átmeneti vezérlő gond volt a HDD-vel
és nem mondjuk méteres árkot vágott a leszakadt fej a tányérba.

0 szavazat

Két diszknél nincs vita, mit használ reduindancia növelésére :-) háromnál tripla tükör biztosabb, pláne nagy diszkeknél, ahol a rebuild (r5) sokáig tartana, négy diszk esetén lehet vita tárgya az összeállítás - másolat alapon működő megoldásnál sebességileg mindenképp a stripe+mirror kerül előtérbe, visszaállíthatóság okán viszont az összefűzött-tükrözött diszkeknél van az előny - miközben két diszkkiesését csak korlátozottan viseli el mindkettő; ugyanekkora nettót tud egy raid6 tömb négy diszken, két tetszőleges disz kiesését elviselve.
Ha megyünk a lemezek számában fölfelé, egyre összetettebb a sztori, egyre összetetteb kérdés a performancia, a nettó tárhely, illetve a hibatűrés közötti balanszírozás.

0 szavazat

alapbol ez az eles. innen megy xpenology-ra backup, a fontos adatokrol (de nem mindenrol). de a maradek az foleg olyan ami beszerezheto, tehat nem szemelyes content.
a backup NAS pihen, hozza sem nyulok amig itt at nem fut a mentes es a support - nyilvan az lenne az egyszerubb (es a zero adatvesztes) ha a RAID-et ossze lehetne rakni.

0 szavazat

Azt a két diszkes felállást gondold át - most is két diszked halt le... A melegtartalék csak akkor megoldás, ha sok kisebb diszked van, és ha van idő szinkronizálódni. Ez 2-3TiB diszkeknél már erősen necces.
A SMART adatok szerint nincs hiba az egy dolog, a vezérlő valamiért kihajította a diszkeket a tömbből. Ha kiderül, miért történt, talán okosabbak leszünk, bár az adatok szempontjából szinte mindegy.

Saját sztori. Intel szerver, hardveres raid-vezérlőn négy kommersz ssd, raid10-ben. Olyan 3-4 hetente egymás után kihajigálta a vezérlő az ssd-ket a tömbből (legfeljebb negyedórás időközökkel!), hogy hardver döglött, kuka. Sima reboot után se látta a raid bios a meghajtókat, csak táp ki/vissza után - akkor viszont simán össze lehetett rakni a ~10-15 perccel azelőtt a vezérlő szerint döglött meghajtókból a tömböt, amin gyakorlatilag egy fsck kellett, és nagyjából minden a helyére került. Volna, ha nem egy replikált adatbázis alatt történt volna mindez, mert a replikációból kieső idő (táp ki/vissza, tömb összerakás távolról ip-konzolon félgarfikus raid-biosban...) miatt érdemesebb volt a replikát ismét felépíteni nulláról.

Ott a megoldás az lett, hogy a kommersz ssd-ket kicserélték Intel meghajtókra...

Másik sztori: 8x2TiB, RAID5-ben (ez szoftveres raid volt), majdnem telepakolva logokkal. Egy diszk kiesett, hot spare volt, rebuild, aztán pár perc, és egy másik is kiesett, majd egy harmadik is, úgyhogy a tömb ment a kukába. A kiseő diszkek nem, tesztelés után prímán mentek még tán a gép évekkel későbbi "lebontásáig". Persze a RAID5 helyett RAID5 tömb lett összerakva - a kisebb kapacitás nem volt gond, mert nem volt olyan mentés (illetve az a gép volt a mentés...), amit vissza lehetett/kellett volna tölteni.

A legmorbidabb sztorit viszont a HP követte el: OS raid tükörbe rakott lemezeken. Az egyik lemez elkezdte szórni a hibákat, egyeztetett időpontbanjött a mérnök a cserediszkkel, elkezdte a munkát, aztán... a dolog vége egy újratelepítés lett, mert a csere folyamán a tükör még működő párján is megsérültek az adatok (ja... a szinkronizálást nem a régiről az új diszkre indította el...).

0 szavazat

tovabbra is nekem a sima ketlemezes raid1 visszallithatobb megoldasnak tunik, akkor is, ha mondjuk kivagja mindket lemezt a vezerlo. onmagaban jo esellyel barmelyik hasznalhato marad. most jo lemezeket vagott ki, (smart tesztek mentek) 4-bol 2db-t akkor reggel ill. megelozo nap este egy mezei 120GB-os sea-at, amire csak a kamerak anyagai mentek. 3 lemezt rakott ki 8 oran belul az 5-bol: szerintem kizart hogy lemezhiba legyen.

azota raktam ra egy masik tapot, azzal ment, de most ugyis le van allitva.

koszi a sztorikat is, az utolso valoban kellemetlen:)

frissitem a nyit hsz-t folyamatosan, most epp mennek a disk image dd mentesek. az elso lemez kb 7 ora alatt meglett, a masodik reggel indult.
utana raangedem majd a supportot.

0 szavazat

( Konflikt (veterán) | 2018. 10. 08., h - 15:38 )

support jelentkezett, osszeraktak a tombot a 3 kozeli lemezbol, a 4. most sync-el:)
nem voltak tul boszavuak es az SSH history sem latszik, szoval nemtudom mit csinaltak. direkt kerdesre is csak ennyit irtak:
"We remount the RAID System and mount back the Volume."

majd este meg alaposan korbenezek

0 szavazat