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:)
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.
ahh, 4db 3TB-os plusz lemezem sajna nincs. de futok egy kort vele. ezesetben valtoznak a disk UUID-k is nem, az jelentene tovabbi komplikaciot?
Ha nagyon spórolós vagy akkor csinálhatod úgy is, hogy a lementett imageket rakod el páncélba
és az éles diszkeken játszol ... ha elszúrod akkor az image-ből helyreállítasz....
...de akkor ugyebár egy picit nő a lehetséges adatvesztésre a sansz
Csak előtte mindehhez vegyél kb. 30TB HDD-t is.
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.....
lepjunk tul ezen a kerdesen, hogy lemez beszerzes (egyebkent otthoni NAS, csaladi fotok is..) - tegyuk fel hogy van extra 4db 3TB-os lemezem. hogyan tovabb mdadm oldalrol?
--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.
koszi.
vennem kell mondjuk 4x3, v 2x8, 4x4 TB-nyi lemezt. vagy lehet erdemes probalkozni adatmento ceggel? (mert a lemezek koltsege alaphangon nem keves)
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
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?
btrfs
Én adatmentő céghez sem adnám le a diszkeket mentés nélkül. A legolcsóbb megoldás sztem 3db 3TB-os diszk, erre lementheted azt a 3-at amivel éppen próbálkozol.
Ha a lemezek neked drágák, akkor az adat sem fontos. Sajna ez ilyen.
lesz lemez.
--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
koszi! amint lesz dd a lemezekrol.
Ott van, hogy 2db van szinkronban, 1db kicsit lemaradva, 1db meg nagyon, tehát nincs 3db azonos event szinten. Viszont a kicsit lemaradtnál lehet próbálkozni a --force-al.
igen, koszi, ez a terv. most futnak a disk image mentesek
subs.
------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
A legközelebbi storage tervezés előtti olvasmány:
https://www.zdnet.com/article/raidfail-dont-use-raid-5-on-small-arrays/
--
zrubi.hu
Szertintem jó nagy baromság,
But SATA drives are spec'd at one Unrecoverable Read Error (URE) every ~12.5 TB.
Akkor megismétli az olvasást, aztán megy tovább. Nekem már állt vissza pár RAID5 tömb legalábbis, biztos szerencsém volt csak.
A technikai indolklás lehet nem állja meg a helyét, viszont a végeredményt (adatvesztés) biztosan alátámasztja a statisztika az ilyen megoldások esetén ;)
--
zrubi.hu
Ha van mentésed, akkor tök mindegy, min vannak az adatok. A raid5-nek simán megvan a létjogosultsága.
Ha nincs mentésed, akkor hiába van raid6-ot spare lemezzel, úgyis besz*pod majd.
+1
koszi, egyebkent az ev vegere terveztem a diskek cserejet, 2 lemezes setupra. 5 ev alatt mar elerhetobbek lettek a nagyobb kapacitasok, nem kell sok lemez. de majd akkor ha ez megoldodik.
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."
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..
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
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?
Nálam volt már ilyen, hogy jó lemezt kivágott. Kiderült, hogy a csati volt kilazulva az alaplapon.
Mondjuk az nem synology volt hanem csak egy kis sima egyszerű softwares raid egy mezei alaplappal.
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.
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
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.
Most kidőlt két lemez, és ezért küzdesz hogy újra menjen a RAID5. Ha a kétlemezes RAID1-nél kiesik két lemez, akkor az mennyivel lesz jobb?
akkor mit javasolsz. otthonra HA clustert csak nem epithetek
Vagy három lemezes tükör, vagy négy diszkre raid6 - nettóban ugyanannyi, mint a raid10, viszont raid6 esetén két tetszőleges diszked kieshet.
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.
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.
miert nem? veszel 4db valami kis linuxot futtato, SATA portos bizbaszt, raraksz 1-1 db HDD-t, aztan ceph ra 3xos replikacioval, es voila, van teljesen HA clustered
ha esetleg tudnál mondani olyan megoldást, ami kb lemezdokkoló kivitel és gigabit port van rajta (amit ki is tud hajtani) megköszönném!
ha oke az USB2 vinyo speed: banana pi m64? amugy odroid-xu4 usb3<>sata atalakitoval?
nincsen valamelyik hasonló boardon "natív" sata port?
Egyelőre amit láttam, az max. usb-sata volt ezeken a kis vackokon - gondolom nem véletlenül...
Odroid-HC1 és -HC2-n van sata port. Bár ezeknél is USB3.0-to-SATA megoldás van.
Teves. HC2 eseten nem.
http://archive.is/r8kK8
Valami ilyesmi. Magamnak gondoltam egy nagyobbacska tarhelyet osszerakni, kereses kozben ebbe botlottam.
Most perpil encfs/gdrive(fizetos) verzi van rclone es egyeb syncel.
Tudom encfs nem szupi, de a nem szupi is tobb mint a semmi...
Nincs ilyenem, de:
„JMicron JMS578 USB 3.0 to SATA Bridge with UAS capability to archive over ~300MB/sec transter speed”
(https://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472)
Jah, 2.0 volt fentebb.
Egyebinrant 3 eseten ugyis a 1Gbps lesz a szuk keresztmetszet.
Szerintem.
LattePanda Alpha core m3 - bar egy pottyet draga, de neki lehet nativ a sata...
Ha mondjuk van egy NAS otthon és adatot RPI, BPI fajta gépekkel mentek mondjuk USB-s külső HDD-re, éjszaka főleg, automatizáltan, akkor nem mindegy hogy 30MB/s vagy 100MB/s amivel átmegy a mentett adat éjjel?
nem, egyreszt a synology cuccait megszoktuk (csalad is)
masreszt kell a savszel mert asztali gepekrol is megy image backup oda, nagyobb fileok mozgatasa is gyakori (kamera videok)
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."
Azaz dettó mint a raid5 nettója/hibatűrése - csodák nincsenek, nevezhetjük akárhogy a dolgot.
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.
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.
mas kerdes, h miert lemezben gondolkozik meg mindig a nep adat redundancia helyett...... 3par pl egesz intelligensen csinalja.
"3par pl egesz intelligensen csinalja"
Otthonra nem lenne kicsit erős?
Rendes helyes van spejz, ott elfer.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Nekem a kepernyo melett duruzsol, na nem 3par . :D
itt mire gondolsz pontosan?
synology maradna a mostani szituacio ellenere, a sok szolgaltatast megszoktuk (de foleg a csalad pl. photo station-t, stb) biztos mindenre lenne alternativa, (akar jobb is) de most ezen nem varialnek. tulsok ido.
Ok, ok, de akkor ez most egy backupszerver vagy egy eles adatokat tarolo szerver?
Ha az elso, max. bukod a backupokat, nabumm, eles adat megvan.
Ha a masodik (is?), akkor meg visszaallsz backupbol es kesz vagyunk.
Ha nem volt backup, az az adat nem volt fontos. :)
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.
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...).
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.
+1
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
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