Synology DS212j zmena raidu

[Robert8]

Ahojte,
potreboval by som poradiť s úpravou RAID nastavenia na mojom staršom NAS Synology DS212j.

Momentálne mám v ňom 2 disky po 2TB nastavené v zrkadlení (RAID 1). Rád by som to zmenil na rozšírenie (JBOD alebo RAID 0), aby som mal k dispozícii celú kapacitu 4TB – viem, že tým prídem o ochranu dát, ale v tomto prípade mi ide skôr o priestor.

Vie mi niekto poradiť, ako to spraviť? Je vôbec možné zmeniť typ RAID bez toho, aby som prišiel o dáta, alebo budem musieť všetko zálohovať, resetnúť pole a nastaviť nanovo?

Ďakujem.

[zoom]

Synology vie zmenit typ RAIDu za behu a bez straty dat, ale len v specifickych pripadoch, popisane tu. Cize vies ist z Basic (JBOD) na RAID1 alebo RAID5, vies ist z RAID1 na RAID5, ale nevies downgradovat z RAID1/RAID5 na JBOD.

Najlacnejsie a najhorsie riesenie: Na debila vytiahnes jeden disk z toho Synology. Pripojis ho niekde do PC alebo USB boxu, odohras tam data zo Synology. Potom ten jeden disk v Synology znovu inicializujes, aby tam bolo iba JBOD a nahras data naspat. Nasledne ten vybraty disk pripojis naspat a rozsiris JBOD kapacitu. Pri kopirovani by som pouzil nieco rozumne, aby to verifikovalo zapisane data a zachovalo timestampy na suboroch aj adresaroch (napr. command-line prikaz robocopy.exe <Folder_odkial> <Folder_kam> /COPY:DAT /DCOPY:T /E). Pokial mas niekde v byte ulozisko, kam vies docasne ulozit tie data, tak samozrejme kolotoc s vyberanim disku odpada.

Riesenie, ktore uznava ujo zoom: Pohybujes sa v tak malych kapacitach, ze kupit dva vacsie disky stoji doslova par desiatok eur. Napriklad tento inzerat (najdeny namatkou, cloveka nepoznam). Dva 6TB WD Red disky, CMR zaznam, 5400 rpm, fajn akustika. Za 60,-€ obidva. Takto si zvacsis pole este viac, nez by si dosiahol s JBOD a navyse ti ostane redundancia dat. Win-win pre mnozstvo aj integritu dat.

Edit: K tomu druhemu (spravnemu) rieseniu som chcel este napisat, ze je to aj najjednoduchsie. Prinesies dva disky, strcis jeden do Synology, rebuildnes pole. Strcis druhy do Synology, rebuildnes pole. Hotovo. Tie vyhody ukrutne prevazuju nad nevyhodami a ta jedina nevyhoda je zaplatit ~60,-€.

[HellAngel]

to posledne riesenie co pise @zoom je cesta ako by si mal vydat

[mp3turbo]

ja by som si tak trosku tipol, ze cena 60 eur je za jeden kus.

[shiro]

Pri tom rebuildovani pola, pocitaj ze to potrva na vykopavkovom DS212j so slabuckym ARM CPU, par dni...
Na DS720+, 4TB disky, cca 600GB dat RAID1 a pri poruche + vymene jedneho z nich mi pole rebuildovalo cca 10h.

[mp3turbo]

nevadi, casu dost.

Navyse, je vysoko pravdepodobne, ze v tvojom pripade napriek 600GB dat doslo k rebuildovaniu celeho Raid1 pola, teda 4TB.

[michalesku]

Sektorovy rebuild bez ohladu na zapisane data bezi v pripade Synology vzdy..

[shiro]

Takze to pracuje podobne ako linuxovy dd?

[michalesku]

Je to tak..

[mp3turbo]

Synology nepoznam, takze som dobre tipol. Tympadom aj autorovi temy, ktory ma presne rovnake 4TB, bude rebuild bezat "overnight" cize radovo do 12 hodin.

[shiro]

No neviem, s tym ARM CPU z roku 2012....
Mne to bezalo na J4120 CPU, tak len aby nebol prekvapeny.
Maniaci, co maju v Syno nastrkane 18TB HDD robia rebuild kludne tyzden

[michalesku]

Ano, radovo urcite nieco nad 12 hodin.. Pridaval som 4TB do RAID5 v DS1515+ a rozsirenie volume bolo cez 24 hodin..

Kazdopadne je to cinnost celkom nenarocna na CPU, takze zalezi hlavne na rychlosti radica a diskov..

[SKiLEX]

To som chcel povedat, ze ked som robil rebuild tak CPU vpodstate idloval, len disky sli niekolko dni na 100%

[mp3turbo]

tak tak

>> Maniaci, co maju v Syno nastrkane 18TB HDD robia rebuild kludne tyzden

dolezite je, ci maju Raid1, Raid5, Raid6 alebo co.
pri Raid1 je cpu dost nepodstatne bez ohladu na kapacitu diskov.

Zober to takto : 4TB disk je 4000 GB, priemernu rychlost dosiahne cojaviem snad aj 120MB/s cize to mame 4.000.000 MB / 120 MB/s = 33.333 sekund = 9.3 hodiny matematicky. Jednoducho rychlejsie to nejde. Samozrejme k tomu pride este akakolvek realna zataz pocas toho rebuildu, disk musi lietat hlavickami, prenosova rychlost pada na uroven jednotiek MB/s atd, atd, cize rekonstrukcia / rebuild 4TB disku za 10 az 12 hodin je uplne normalna vec. Procesor neprocesor.

Ak zoberieme hypermoderny 14 az 20TB disk, ich priemerna rychlost je volakde v okoli 200MB/s : https://realhardwarereviews.com/seagate ... it_content a ukazuje to v principe kazdy takyto test.
To znamena, ze v klasickom Raid poli NIE JE MOZNE zrekonstruovat 18TB rychlejsie nez za 18.000.000 (MB kapacita) deleno 200 (MB/s rychlost) = 25 hodin, a to bez zohladnenia akychkolvek vonkajsich vplyvov (realne operacie citania zapisu na tom políčku atd). Bez ohladu na procesor. Situacia sa samozrejme strasne komplikuje, ked namiesto Raid1 mame styri, sest, osem diskov v Raid5 alebo Raid6, pretoze tam tie disky musia pracovat nejako spriahnuto, existuje tam tzv. read/write amplification ratio (na to, aby som zapisal 1MB na vymeneny disk, potrebujem precitat X krat 1MB zo zivych diskov, aby som vypocital kontrolnu sumu ktoru treba volakde na tie disky zapisat, cim sa zase stazuje celkova praca a znizuje vysledny vykon).

Vedecky zaver : rekonstrukcia 4TB disku v Raid1 je uplne v pohode za 10 hodin.
Rekonstrukcia 18TB disku pod 25 hodin nie je mozna v akomkolvek poli, a tri dni v Raid5/Raid6 neznamenaju absolutne ziadny problem. Je to tak.


Prave kvoli tomuto vznikli rozlicne pokrocile algoritmy, pracujuce na inych principoch nez standartne Raid polia - napriklad Netapp pouziva tzv. DDP (dynamic disk pools), HP pouziva tzv. CPG (common provisioning group) atd, atd. V principe ide o to, ze sa vykaslali na fyzicke disky, data si na nich usporaduvaju nie na sektorovej urovni (Raid1) alebo na urovni stripe (Raid5/6), ale spravili si svoje vlastne rozdelenie dat. To im umoznuje opustit "uroven fyzickeho disku" - akurat si niekde musia uchovavat bitmapu, musia mat prehlad ktore "oblasti" su pouzite a ktore nie su.

Tento faktor umoznuje rekonstruovat len tolko dat, kolko je realne pouzitych. Nahodim 20TB disky, zapisem tam 5GB dat, disk sa pokazi, vymenim a rekonstruuje sa len tychto 5GB zapisanych dat (s tym, ze vacsia cast z nich zostava ziva na funkcnych diskoch), takze za tridsat sekund je hotovo. Seriozne. Ked zapisem 1TB dat, tak to bude trvat len tolko, kolko treba na 1TB a nie cely 20TB disk (cize povedzme dve hodiny namiesto troch dni).

Jo a pridruzena sranda je, ze ked sa nejaky disk pokazi, tieto diskove polia okamzite [!] obnovuju stratene data na existujuce disky - do volneho miesta. Cize sa vobec necaka na vymenu pokazeneho disku, ale okamzite sa obnovuje plna redundancia. A ked sa ti pokazi druhy disk, zase to iste, ked sa ti pokazi treti disk, to iste, v principe dokolecka pokial mas volne miesto (pripadne podla nastavenych parametrov, keby administrator potreboval inak). Cize je mozna aj situacia, kedy sa ti v "Raid5 poli" pokazia styri disky a vobec nic sa nestrati, vsetko v pohode : jedina kriticka podmienka je, aby "medzi pokazenim jednotlivych diskov" prebehol dostatok casu na to, aby sa data vypocitali a zapisali na zive disky.

Vyborny vymysel. Absolutna nutnost v enterprise prostredi.


Rovnako aj ZFS suborovy system uz pristupuje k datam a ich rekonstrukcii inak, nez na celkovej sektorovej urovni celeho pola.
Je to vyvolane presne tymto casovym tlakom...

[werwest]

Sektorovy rebuild bez ohladu na zapisane data bezi v pripade Synology vzdy..

Od dsm7 su prazdne bloky skipnute