[kurask]

mul on 8 tki 4 TBsed kettad
need lähevad varunduspinnaks NASi, mis oskab kõiki põhilisi raide

*nüüd oleks vaja seadistada mingi kombo et saaks võimalikult palju pinda, aga et vähemalt osaliselt oleks raid1 või raid10
*ja ühe varundatava asja suurus on hetkel 1,3-1,6 TB
*tuleb arvestada, et võib ka üle 2-e TB minna, üle 4ja TB ei lähe ühe varundatava asja suurus
*backup teeb kord nädalas full
*eraldi hoida vaja 1x "kvartal" ning 1x "aasta"
*samuti on mõned välised hdd "kvartal" seifis.
*samuti on üks teine nas, kuhu jookseb weekly/montly üks koopia.


ma ise mõtlesin, et teeks
*raid1 4 TB (2 ketast) "kvartal"
*raid1 4 TB (2 ketast) "aasta"
*raid5 12 TB (4 ketast) "weekly" nii, et kui raid5st üks ketas failib, siis rebuildi ei hakka tegema, vaid uue ketta saabumisel lõhun vana raidi ning loon uue raid5.

[mikk36]

Milleks Raid5, kui ei huvita selle rebuildimine? Sama hästi võid juba 16 GB JBOD teha nendest.

Isiklikult on küll lahendatud kogu backup süsteem teisiti.
Peamine NAS jooksutab ZFS'i, kus on kõik andmed snapshotitud kuni kahe kuu pikkuselt (erinev tihedus ja kestus eri andmekogudel).
See NAS sünkroniseerib kõik oma snapshotid teise NAS'i, mis asub füüsiliselt natuke erinevas kohas.
Miski ei piiraks ka kolmandat või järjenumbriga n masinat püsti panemast, kuhu veel lisaks sünkroonida.

Selliselt saaks x ajavahemikus suvalisest punktist info välja võtta, ajavahemikuks x on enda määratud aeg kaua snapshote alles hoitakse, kuid igas serveris on sama info (full backup) nii olemas.
Kui tahta tõesti aastakaupa backupe luua, võib seda erakorras käsitsi tekitada a'la iga aasta alguses näiteks ja jätta seisvale kettale, kuid ega see kuidagi turvalisem pole, kui juba jooksvas masinas olev ketas, kus näiteks iga nädal või iga kuu täies mahus lugemiskontroll tehakse.

[kurask]

16 gb jbod võtab katki minnes weekly kaasa, see ka põhiprobleem (+failure rate korda 4).
Et kui raid5 failib, siis viimase weekly tõstan välisele hdd-le/mujale seniks kuni uus ketas saabub.

Edit: tegin prooviks sinna ära raid5e, 4 kettaga, praegu teeb esimest tühjade ketastega rebuildi, estimated : 11h.

[ThedEviL]

ei saa aru, mille poolest on nüüd jbod kehvem kui raid 5 kui sa nagunii rebuildida ei kavatse?
raid5 oleks siis jbod - 1 ketas....

[Sahasrahla]

Nalja pärast küsin,
kas andmete taastamisel omavad andmete omadused ka tähtsust?

[kurask]

[XR]

Kuidas selle pinna masinale ette annad?
Otse OS-ile, mis pole virtualiseeritud?

[Markos]

Anna inmesele võimalused ja ta ei suuda enam valida. Esialgne plaan on ju ketaste raiskamine, kui kardad raid5's ühe ketta failimist, siis tee raid6, hoiad ikka ühe ketta kokku. Stripeseti kasutamise ainus põhjendus saaks olla performance ja kui tuleb pisar silma 1 ketast raid5'le kinkida. Seda pead ka arvestama, et raid5 performance on igal juhul parem peeglipakkide omast, st algne plaan näeb ette mingil hetkel backupiga toimetamise aeglust. Kui weekly ja monthly tehakse näiteks nas'i siseselt, siis ühelt volüümilt teise kopitamine või liigutamine on igal juhul aeglasem, kui sama volüümi (ja fs) piires liigutamine, mis käib murdosa sekundiga.

[kurask]

[Markos]

Miks raid1 ? sellise kettahulgaga saad sa 10, aga see ei ole mahu poolest otstarbekas, ning stripingu performancet ilmselt ka ei ole vaja. Pane ikka raid5'te ja unusta.

[kurask]

raid5e rebuild on mul juba selline sõber, et ei suuda unustada (pisar).

[Markos]

Ülikehv protsessor siis ? Ma ei tea, mis NAS'ga tegemist on, enamikes SOHO asjades on softiraidid, aga päris kontrolleritel põhinevad asjad on tänapäeval juba piisavalt kärmed, et io performib rahuldavalt edasi. Peab ikka väga raske koormus olema, et rebuild probleemiks osutuks. 10 puhul peegeldub tõesti üks span ja arvutusvõimsust sinna ei lähe, kuid mahukadu on 2x, mis backup- pinna puhul tundub ikka räige raiskamisega.

[XR]

[Pailaps]

Tee kaks Raid 5-te ja siis 0-iga kokku software tasemel. ZFS/XFS , mida iganes eelistatud.
Samuti ei ole Sa öelnud, mis asju varundama hakatakse. Kas persetäis väikseid failikesi või suuri?

Ma saan aru, et taaste kiirus on samuti oluline. Sellisel juhul RAID 50/60, juhul, kui raud toetab. SSD ketas cache tarbeks. Kui on säätulahendus, siis loe ülevalt.

See tagab, et taastamisel end vigaseks ei ootaks. Väldi odavaid Toshiba kettaid, Hitachi, RE4 vms. Kui rahamuret pole, siis paremaid kettaid.

Loe tabelit.
http://publib.boulder.ibm.com/infocenter/eserver/v1r2/index.jsp?topic=/diricinfo/fqy0_cselraid_copy.html

[mikk36]

[Pailaps]

[Markos]

[kevku]

RAID5/6/7 kohta lugemist http://queue.acm.org/detail.cfm?id=1670144

Küsimus just kui suurt töökindlust tarvis?
RAID1 või 10 kõige lollikindlam lahendus

[kurask]

kui kedagi huvitab, siis seade on STDP32000200.

[Pailaps]

Seade ei võimalda, kahju. Iseenesest kõige parema tulemuse saaks RAID50-ga. Tagatud andmete kättesaadavus ja optimaalne kiirus. RAID-60 on overkill.

RAID-5 ja LVM failisüsteemi peale mõtlesin ma juba alguses, kuid Markos formuleeris mõistetavasse vormi.

[RCC]

loogika on lihtne, sa kas saad käideldavuse või kiiruse, sõltuvalt sellest mida sul vaja on, sellest tulenevalt pead valima ka leveli. mitut asja korraga oskavad ehk märksa kõrgema hinnaklassi pillid. speci järgi annab see seakatla kopsik "impressive" transfer rate 200MB/s, mis oleks täidetud juba kahe cheetah 15k.7 ketta poolt. seega kiirus jääb sellel kopsikul ilmselt tahaplaanile. alguses võid ju teha mitmeid erinevaid teste, sest seadmete tegelik võimekus ilmeb ikka töö käigus

[kurask]

tegin nii nagu enda plaan ette nägi, raid1 (tähtis data), raid1 (tähtis data) ja raid5( vähetähtis data st raid1-de jaoks cache suht :7 ning seda ma rebuildima ei hakka kui feilib). Kiirused ületavad ootusi (sest kiiruste jaoks polnudki erilisi ootusi). Seadmel endal muidugi juba üke toiteplokkidest feilis ja läks garantiisse.

[Le Inc]

RAID 10 tundub et on parim mis hetkel pakkuda on kiiruse/ketta mahu/turvalisuse suhtes. RAID 5 võib olla problemaatiline just rebuild'imise osas. Tagavarakoopiad peab nii või naa tegema, seega päeva lõpuks pole vahet mida sa kasutad. Kui on ülioluline info võib ju alati n+1 ketast RAID 1 pressida ...

[kurask]

Andruse silmade sära synology teemas ärgitas bumpima teemat.

[mahno]

Ei saa n+1 ketast panna näiteks raid5 massiivi, sest see suudab üle elada max 1 ketta surma korraga. Piisavalt suure ketaste arvu juures tekib liig suur tõenäosus, et sul võib kooleda teine ketas ennem, kui esimene rebuildi ära lõpetab.

[kurask]

Upitan vana teemat, kuna hetkel tuli Synology Nas ds2015xs samal eesmärgil 8x6 Tb kettaga,
ning hetkel on plaan teha 2 kettaga mirror + 6 kettaga raid5 (mida ka taastama ei hakka kui faileb).

Eesmärk on sellel raid5 pinnal olla secondary backup target, ning raid1l yearly arhiivi koopia

Äkki kellelgi on vahepeal uusi mõtteid tekkinud.

[Markos]

Kui nagunii taastama pole plaanis hakata, võib ju lihtsalt linear md volume olla, ei lähe ruumi raisku. Või on see siiski oluline, et ketta faili korral saaksid asjad sealt kätte, enne, kui array õhku lased ?

[ThedEviL]

kurask, esmalt peab kohe ütlema, et kettad on odavad, peegel oleks mõistlik.

Kas synologil saab raid5 massiivist failid kätte enne rebuildimist kui ketas sureb? On reaalselt keegi proovinud? Kui saab ja kõik jääb tööle, siis soovitav enne rebuildimist hoopis andmed maha kopeerida, kuna buildimise ajal järgmise ketta surm pole harv juhus.
Või siis sinu variant, et taastama ei hakka, tähendab, et kettad utiili, uued sisse ning uus massiiv?

[Markos]

Miks ei peaks saama ? aeglane on, aga kasutatav. Teise ketta "surm" on enamasti seotud SATA võimalike lugemisvigadega (URE). Kettal endal ei pruugi tegelikult otseselt midagi viga olla, kuid ketas märgitakse pahaks ja kahe failinud kettaga enam RAID5't kokku ei pane. Peegel on mõistlik ainult siis, kui ühe ketta kiirus rahuldab, kui on palju paralleelseid kirjutamisi/lugemisi, siis võib väheks jääda. Omaette ooper on taastusaeg, 6TB ketastega RAID5 rebuild kestab ca nädala.

[kurask]

[ThedEviL]

[warwas]

Kusjuures seda rebuild'imise kiirust annab juurde kruttida. Vaikimisi konfis on see ikka ajuvabalt aeglane.
http://www.pro-blog.com/fix-synology-long-raid-rebuild-times/

Eelmise aasta lõpus tegin kodus 2 -> 4 bay migreerimist. 3 terased kettad.
Ma täpselt enam ei mäleta, kui kiireks ma selle sättisin aga lõppkokkuvõttes kukkus ühe ketta lisamise ja massiivi laiendamine (Syno enda SHR) aeg 2 päevalt umbes 6..7 tunni peale. Ja ei saa öelda, et see suurenenud taustakoormus kuidagi üleüldist kasutuselamust rikkunud oleks.