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:)
- 3737 megtekintés
Hozzászólások
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Csak előtte mindehhez vegyél kb. 30TB HDD-t is.
- A hozzászóláshoz be kell jelentkezni
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.....
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
--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.
- A hozzászóláshoz be kell jelentkezni
koszi.
vennem kell mondjuk 4x3, v 2x8, 4x4 TB-nyi lemezt. vagy lehet erdemes probalkozni adatmento ceggel? (mert a lemezek koltsege alaphangon nem keves)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
btrfs
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
Ha a lemezek neked drágák, akkor az adat sem fontos. Sajna ez ilyen.
- A hozzászóláshoz be kell jelentkezni
lesz lemez.
- A hozzászóláshoz be kell jelentkezni
--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
- A hozzászóláshoz be kell jelentkezni
koszi! amint lesz dd a lemezekrol.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
igen, koszi, ez a terv. most futnak a disk image mentesek
- A hozzászóláshoz be kell jelentkezni
subs.
------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
akkor mit javasolsz. otthonra HA clustert csak nem epithetek
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
ha oke az USB2 vinyo speed: banana pi m64? amugy odroid-xu4 usb3<>sata atalakitoval?
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Egyelőre amit láttam, az max. usb-sata volt ezeken a kis vackokon - gondolom nem véletlenül...
- A hozzászóláshoz be kell jelentkezni
Odroid-HC1 és -HC2-n van sata port. Bár ezeknél is USB3.0-to-SATA megoldás van.
- A hozzászóláshoz be kell jelentkezni
Teves. HC2 eseten nem.
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...
- A hozzászóláshoz be kell jelentkezni
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=G15150517…)
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Azaz dettó mint a raid5 nettója/hibatűrése - csodák nincsenek, nevezhetjük akárhogy a dolgot.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
mas kerdes, h miert lemezben gondolkozik meg mindig a nep adat redundancia helyett...... 3par pl egesz intelligensen csinalja.
- A hozzászóláshoz be kell jelentkezni
"3par pl egesz intelligensen csinalja"
Otthonra nem lenne kicsit erős?
- A hozzászóláshoz be kell jelentkezni
Rendes helyes van spejz, ott elfer.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
Nekem a kepernyo melett duruzsol, na nem 3par . :D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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...).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni