Synology-Forum.nl
Hardware ondersteuning => NAS hardware vragen => Topic gestart door: Asterixxx op 20 februari 2019, 11:01:53
-
Hi,
Ik heb een DS414 NAS. Daarin zaten 4x4TB disks.
Nu was er één van mijn disks stuk.
Ik wou de gelegenheid te baat nemen en verving deze disk met een 10TB disk.
Dit leverde geen winst op in plaats (normaal).
Toen ik echter bij de derde disk kwam en deze wou vervangen maakte het systeem mij erop attent dat de DS414 een 16bits systeem is en dat dit geen volumes ondersteunt die groter zijn dan 16TB. Dat was ik vergeten.
Ik heb dus 'vlug' een laatste backup genomen, heb dan ineens ook de vierde disk vervangen, en maakte een diskgroep aan met de vier nieuwe disks en twee volumens van rond de 16TB.
DSM gaf mij wel een keuze,...
Een diskgroep met één volume omwille van de snelheid, of een diskgroep geschikt om meerdere volumes te huisvesten maar dan 'iets' trager.
Gezien ik toch steeds een backup heb van de files op deze NAS heb ik redondantie gekozen (RAID0).
Nu ben ik de backups aan het terugzetten, en dit gaat uitermate traag. ipv gemiddelde overdrachtsnelheden van 60MB/s krijg ik gemiddelde overdrachtsnelheden van 25MB/s. (MB, geen Mbits).
Kan iemand mij zeggen of dit normaal is, en waaraan dit zou kunnen liggen ?
- Aan het feit van een diskgroep met twee volumes? (noch het volume noch de diskgroep blijken buitengewoon hard belast te worden door het terugzetten van de backup, wel integendeel).
- Aan de backupsoftware (Hyper Backup) zelf? Dat deze wel snel wegschrijft maar traag terug zet?
- Of misschien aan het feit dat ik geen redondantie gekozen heb ik de vorm van een Raid 5 of SHR?
Of is dit helemaal niet normaal en moet ik op zoek naar een andere oorzaak ?
ps: the backup NAS is not the issue. It hardly registers the transfers at all, and I can run a simultanious backup from a second nas that clocks at between 60 and 120MB/s simultaniously without the backup NAS breaking a sweath...
mvg,
Wim
-
Ik denk:
Aan de backupsoftware (Hyper Backup) zelf? Dat deze wel snel wegschrijft maar traag terug zet?
Echter, als je dit niet eerder hebt moeten doen of je hebt nooit een test restore gedaan, dan is dit niet te bewijzen.
-
Hoi,
jouw antwoord gaf mij een idee.
Ik probeerde dus om eens van het ene volume naar het andere te kopiëren terwijl de restore nog liep.
Onmiddellijk schoot de overdracht-rate de hoogte in...
Vermoedelijk heb je dus gelijk.
Ik zoek dit nog uit en deel mee wat de resultaten zijn...
-
Hyper backup terugzetten duurt inderdaad langer dan over het netwerk kopiëren, dan is (volgens mij) de CPU van het apparaat wat de restore doet de bottleneck.
-
ik denk niet dat dit het geval is, want die wordtbamper aangesproken, en deze nas is de zwaarste die ik heb.
-
HyperBackup heeft ook nog een administratie laag. Hij slaat de file op plus de erna komende verschillen. Bij sommige files moet hij dan de eerste versie combineren met de verschil-files om de laatste versie te genereren. En ook als er maar 1 versie is, moet hij dat toch eerst controleren.
-
en deze nas is de zwaarste die ik heb.
Ik heb dus 'vlug' een laatste backup genomen
Was dit naar de DS414 waarop ook de restore plaats vond ?
Of heb je nog een NAS waarop de backup is gemaakt.
-
Wat ik ook gemerkt heb (tot mijn grote ergernis) is dat het terugzetten van data niet incremental of differential gebeurd.
Ik wou de backup van mijn data van mijn werk-pc terugzetten om data die al gearchiveerd waren terug op de server staan te hebben, maar daarbij overschreef deze restore ook alle recent gebackupte data. Dat had ik nu niet verwacht.
Persoonlijk vind ik dat een groot gemis...
Ook als Hyper Backup alle data van de verschillende scholen moet vergelijken en dat dit de reden van de vertraging zou zijn, zou je dit moeten merken aan de stress indicator van de processor... Deze blijft rustig doordraaien op onder de 10%, en als ik naar het detail ga kijken is er maar 0.XX% van de recources die naar het backup proces gaat (incl de admin processen).
-
Het is van een andere NAS uit dat de backup teruggeplaatst wordt. (wel afgeroepen met Hyper Backup op de DS414. Op mijn andere NAS draait de Hyper backup Vault.
De Backup NAS is een DS1815+ met quad 2.4 GHz processor, 6GB geheugen en 32bits (of is het 64bits).
Tesamen met de restore had ik van mijn derde NAS ook nog een backup proces lopen en dat liep gemiddeld aan 60MB/s (Pieken tot 135MB)
Op dat ogenblik kwam het volume soms wel even onder druk te staan. Maar de Processoren gaven geen krimp...
-
De DS1815+ zelf kan idd niet de bottleneck zijn. ;)
-
Ik zag nu pas je scherts met mijn zwaarste en "nog even snel"... :-)
Het was in mijn DS414 dat de disks compleet fout liepen. Daarmee begon het allemaal.
Maar toen plots ook in mijn DS916+ en bijna tegelijk in mijn DS1815+. Dilemma dus !!!
Waar is de tijd van de DAT-tape streamers... ;)
Toen was alles nog zo eenvoudig... :o
-
De DS1815+ zelf kan idd niet de bottleneck zijn. ;)
Kan het aan het verschil liggen dat de DS414 16 bits is en de DS1815+ 32bits ?
-
Jij kunt het wel een persoonlijk gemis vinden maar je snap toch wel dat als je gelijktijdig uit twee verschillende bronnen een restore gaat doen dat het dan een zooitje wordt.
Hoe zou hyperbackup nu kunnen weten welke versie jij wilt laten staan.
Verder vermoed ik dat zoals in alles het netwerk de bottleneck is en dat er heel veel kleine data pakketjes over het netwerk moeten om all die administratie en die vergelijkingen goed te doen.
Het is net zoals gewoon een folder kopieren, een groot bestand gaat vele malen sneller dan 100 kleine die in totaal minder data bevatten.
Ook zal zo'n restore op een lage prioriteit draaien vermoed ik, om er voor te zorgen dat de Nas ook gewoon gebruikt kan worden.
Verder nog een laatste opmerking over je configuratie.
Ik vermoed dat jij de eerste bent die een diskgroep van vier disken in Raid 0 hebt aangemaakt, realiseer je je wel dat als er een disk defect gaat je dan altijd alles kwijt bent en je alleen nog een tijdrovend proces van restore kan gaan doen?
Ik heb zelfs geen idee hoe DSM dat doet met 2 disken van 4TB en 2 van 10TB
-
Ik heb zelfs geen idee hoe DSM dat doet met 2 disken van 4TB en 2 van 10TB
In RAID0 krijg je gewoon 28TB ;)
-
Ik bedoel technisch gezien.
Raid 0 schrijf naar disk 1 een blok, dan naar disk 2 dan naar disk 3 en dan naar disk 4 en begint dan weer van voor af aan.
Echter als je twee disken hebt van 4TB en 2 van 10TB zijn op een gegeven moment die 4TB disken vol.
Gaat hij dan verder met RAID 0 op twee disken.
Of maakt hij tevoren eerst een set van vier maal 4TB en een van 2 maal 6TB net zoals hij dat met SHR doet?
-
Oei, ..., slechte communicatie blijkbaar...
Enkele misverstanden.
De test met de restore was zonder tweede process (backup).
Om te testen of het idd aan netwerk of... kon liggen een tweede proces gestart met een backup vanop de tweede nas. De restore was onbeinvloed en bleef voort op rond de 25MB/s terugschrijven.
Als je op je 'Server-nas' een versie staan hebt, maar je wil van op je backup nas een oudere versie terugschrijven zou je dit incremental kunnen doen. Daarbij negeert het restore process dus alle nieuwere files op de Server en laat deze ongemoeid. Dan schrijft hij enkel de oudere mappen en documenten terug. Maar dit kan blijkbaar niet bij Hyperbackup.
Je hebt wel gelijk in het feit dat het niet slim is om de twee zaken tegelijk te laten draaien, omdat de arm van de disk dan constant heen en weer moet zitten scrollen. Ook komt dat de ordelijke handhaving van data op de schijven niet ten goede. idd geen goed idee dus. Maar wat doe je als één van je backups tussen de zes en de zeven dagen nodig heeft en je tussendoor data nodig hebt... ?
Het punt van de kleinere pakketjes is ook een zeer goed punt. Maar dit zou gestreamlined kunnen worden. Wanneer je een restore begint (of een backup) heeft de NAS eerst (soms) minuten nodig om de data te zoeken, vergelijken, ..., om dan te beginnen lezen en schrijven. Als op dat ogenblik ook deze data wordt gesorteerd zouden deze pakketjes niet zo klein zijn (zoals bijvoorbeeld het verschil tussen gewoon kopieren van kleine bestandjes en het kopieren met bijvoorbeeld Teracopy)
Je opmerking over mijn vier disken in RAID0.
Je hebt daar volledig gelijk. Ik was vergeten dat de DS414 een 16bits systeem is en dus geen grotere volumes kan hanteren dan 16MB. Bij het vervangen van de defecte disk 4TB door een nieuwe disk 8TB ging alles goed. Ook bij het vervangen van de tweede disk.
Toen ik echter de derde disk wou vervangen kreeg ik de melding dat het volume slechts 16TB kon zijn en het systeem dus de nodige aanpassingen zou doen. Dit betekende dat ik dan slechts een klein deel van de derde disk kon gebruiken, en dat de vierde disk dan waarschijnlijk in een tweede volume zou terecht komen. Alleen kan je geen tweede volume bij maken als je een diskgroep gemaakt hebt voor slechts één volume.
en zelfs moest je deze kunnen maken kan je met 1 disk geen raid bouwen... dus what to do...
Well, dat is dus wat ik deed. Ik haalde de drie vernieuwe disks er uit, stak deze in andere volgorde terug, verving de vierde disk, en startte opnieuw.
Ik maakte een diskgroep aan voor meerdere volumes, en maakte een eerste volume op 16MB en een tweede op wat over bleef. Beiden op raid 0.
Ik ben mij zeer bewust van de kwetsbaarheid van de data op deze nas. maar wat is uiteindelijk het nut van data op pc's, backup op server, deze server SHR of Raid5, en dan nog eens een backup van deze backup op backup server SHR of Raid5 ?
Ergens houdt het op toch... ?
Deze nas is voor internet, none essential data, temporary data, sharing, ...
De enige data die ik kwijt ben op het ogenblik dat deze crasht is de data tot de laatste backup.
en het restaureren van data op een NAS met een SHR of Raid5 is ook geen kort proces.
Wat daarover geschreven wordt moet je dan ook eens lezen. Op het ogenblik dat één van de disks versleten is en dat je op dat ogenblik het zéér intensieve proces van het herstellen van de data op één disk start loop je een groot risico dat één van de andere disks het begeeft tijdens deze operatie en je daarbij alsnog je data verliest. Dan heb ik liever véél meer plaats en een redundante backup met SHR.
Is dat zo fout?
ps: Ik had alleen graag de volumes zo gemaakt dat ze exact telkens twee disks in beslag namen, maar dat kan niet denk ik...
-
@Ben(V)
Volgens pakt RAID0 de eerste HD die beschikbaar is (BAY1), dan de 2e....enz.
Dus, afhankelijk hoe de HD's zijn geplaatst, worden de HD's in die volgorde gebruikt.
Denk niet dat er sprake is van: Of maakt hij tevoren eerst een set van vier maal 4TB en een van 2 maal 6TB net zoals hij dat met SHR doet?
-
@Asterixxx
ps: Ik had alleen graag de volumes zo gemaakt dat ze exact telkens twee disks in beslag namen, maar dat kan niet denk ik...
Ja hoor, dat kan wel.
-
Ik oordeel niet over goed of fout.
Alleen is een backup wat anders dan raid en hebben beiden hun eigen nut.
En een disk vervangen in een raid set mag dan lang duren, maar je hoeft er in tegenstelling tot een restore niet op te wachten, dat gebeurd gewoon in de achtergrond en je kunt je Nas gewoon blijven gebruiken.
Wat je schrijft over files netjes in volgorde op een disk en de arm bewegingen is gewoon onzin.
Geen enkel filesysteem weet waar de data fysiek op de schijf terecht komt, dat ligt een aantal lagen dieper.
En Hyperback werkt gewoon met z'n eigen administratie en als jij daar wat anders tussen door gooit werkt het uiteraard niet meer, wat je er ook van vind.
Als je een backup systeem gebruikt die tijdens een restore ook nog in de gaten gaat houden wat er ergens anders vandaan komt vrees ik dat je systemen in een eindeloze deadlock kunt krijgen.
Iedereen weet dat je tijdens een restore de data met rust moet laten.
-
Volgens pakt RAID0 de eerste HD die beschikbaar is (BAY1), dan de 2e....enz.
Dus, afhankelijk hoe de HD's zijn geplaatst, worden de HD's in die volgorde gebruikt.
Denk niet dat er sprake is van: Of maakt hij tevoren eerst een set van vier maal 4TB en een van 2 maal 6TB net zoals hij dat met SHR doet?
Ik snap de volgorde wel maar de eerste twee disken zijn maar 4TB groot als die vol zijn kan hij geen blokken over vier disken verdelen.
Dan zou hij ergens bij moeten houden dat na 4TB er ineens een raidset van 2 disken zijn in plaats van 4 disken en ik betwijfel of het raidsysteem dat kan.
Het basis concept van raid is vier gelijke disken.
-
Oeps...ik haalde RAID0 en JBOD doorelkaar ::)
RAID0 is striping dus, ik ben nu ook wel benieuwd hoe dat gaat met 2x4 + 2x10TB ;)
-
"Als je een backup systeem gebruikt die tijdens een restore ook nog in de gaten gaat houden wat er ergens anders vandaan komt vrees ik dat je systemen in een eindeloze deadlock kunt krijgen."
De backup is van één nas en van één directory terwijl de restore vanuit een tweede nas komt en over andere files gaat van een hele andere backup uit een andere backup directory...
-
@Asterixxx
ps: Ik had alleen graag de volumes zo gemaakt dat ze exact telkens twee disks in beslag namen, maar dat kan niet denk ik...
Ja hoor, dat kan wel.
En hoe weet je dan hoe groot je je eerste volume moet maken zodat dit alleen over de twee eerste disks loopt?
-
Oeps...ik haalde RAID0 en JBOD doorelkaar ::)
RAID0 is striping dus, ik ben nu ook wel benieuwd hoe dat gaat met 2x4 + 2x10TB ;)
Wat bedoel je? Het resultaat is normaal gesproken hetzelfde. Dan krijg je de volledige 20TB mits een kleine afhouding voor de werking... of begrijp ik de vraag verkeerd ?
-
Jbod plakt twee disken achter elkaar.
Raid0 is striping, die hakt de data in blokken en verdeelt die over de beschikbare schijven.
Misschien wil @Asterixxx wel even kijken op de command prompt.
Even het volgende commando geven
cat /proc/mdstat
Als je het zelf in de hand had willen houden had je een diskgroep in Raid 0 met een enkel volume van de twee 4TB disken moeten maken en een tweede diskgroep in Raid 0 voor meerdere volumes met daar op een 16TB volume plus een 4TB volume ( of twee maal 8TB of welke verhouding je ook wilt).
Overigens zie ik het nut daar niet van in, in mijn optiek was het veel slimmer om all disken in een SHR diskgroep te hangen die dan 18TB groot was geweest en daar had je dan twee volumes op kunnen maken.
-
Nou, ik heb even getest RAID0 > 2x80GB + 2x500GB in de DS411Slim. ;D
[attachimg=1]
root@DS411Slim:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid0 sdd3[3] sdc3[2] sdb3[1] sda3[0]
1113786496 blocks super 1.2 64k chunks [4/4] [UUUU]
md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
2097088 blocks [4/4] [UUUU]
md0 : active raid1 sda1[0] sdb1[1] sdc1[3] sdd1[2]
2490176 blocks [4/4] [UUUU]
unused devices: <none>
root@DS411Slim:~#
-
En wat levert dit commando op?
sudo mdadm --detail /dev/md2
-
root@DS411Slim:~# mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Feb 23 13:44:17 2019
Raid Level : raid0
Array Size : 1113786496 (1062.19 GiB 1140.52 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Sat Feb 23 13:44:17 2019
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
Name : DS411Slim:2 (local to host DS411Slim)
UUID : 745eef26:413db23d:897801a2:6fc7e31a
Events : 0
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3
root@DS411Slim:~#
Gelijk ook maar even gedaan md1:
root@DS411Slim:~# mdadm --detail /dev/md1
/dev/md1:
Version : 0.90
Creation Time : Sat Feb 23 13:14:10 2019
Raid Level : raid1
Array Size : 2097088 (2048.28 MiB 2147.42 MB)
Used Dev Size : 2097088 (2048.28 MiB 2147.42 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sat Feb 23 16:38:33 2019
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
UUID : 5c564047:b5ab232e:ad7e347f:026e0df3 (local to host DS411Slim)
Events : 0.18
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
2 8 34 2 active sync /dev/sdc2
3 8 50 3 active sync /dev/sdd2
root@DS411Slim:~#
En md0
root@DS411Slim:~# mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sat Jan 1 01:00:08 2000
Raid Level : raid1
Array Size : 2490176 (2.37 GiB 2.55 GB)
Used Dev Size : 2490176 (2.37 GiB 2.55 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sat Feb 23 16:42:10 2019
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
UUID : 7e277d97:97af4ff4:ad7e347f:026e0df3 (local to host DS411Slim)
Events : 0.13496
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 49 2 active sync /dev/sdd1
3 8 33 3 active sync /dev/sdc1
root@DS411Slim:~#
-
En nu nog even de details voor de vier onderdelen van de md2.
Dus deze commandos:
mdadm --examine /dev/sda3
mdadm --examine /dev/sdb3
mdadm --examine /dev/sdc3
mdadm --examine /dev/sdd3
-
root@DS411Slim:~# mdadm --examine /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 745eef26:413db23d:897801a2:6fc7e31a
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 13:44:17 2019
Raid Level : raid0
Raid Devices : 4
Avail Dev Size : 146657440 (69.93 GiB 75.09 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 406e7194:227b4991:710be066:f20367cd
Update Time : Sat Feb 23 13:44:17 2019
Checksum : 812b5f46 - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing)
root@DS411Slim:~#
root@DS411Slim:~# mdadm --examine /dev/sdb3
/dev/sdb3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 745eef26:413db23d:897801a2:6fc7e31a
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 13:44:17 2019
Raid Level : raid0
Raid Devices : 4
Avail Dev Size : 146657440 (69.93 GiB 75.09 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : ac795151:0cac55f1:5556169a:6fd3aca7
Update Time : Sat Feb 23 13:44:17 2019
Checksum : ab93b5fe - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing)
root@DS411Slim:~#
root@DS411Slim:~# mdadm --examine /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 745eef26:413db23d:897801a2:6fc7e31a
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 13:44:17 2019
Raid Level : raid0
Raid Devices : 4
Avail Dev Size : 967129120 (461.16 GiB 495.17 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : ed025900:de9b79ed:52b136cb:a37335ed
Update Time : Sat Feb 23 13:44:17 2019
Checksum : fe4f91c3 - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing)
root@DS411Slim:~#
root@DS411Slim:~# mdadm --examine /dev/sdd3
/dev/sdd3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 745eef26:413db23d:897801a2:6fc7e31a
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 13:44:17 2019
Raid Level : raid0
Raid Devices : 4
Avail Dev Size : 967129120 (461.16 GiB 495.17 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 16137703:40227046:af549b82:291a9b5d
Update Time : Sat Feb 23 13:44:17 2019
Checksum : 822e7231 - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing)
root@DS411Slim:~#
-
Hmm daar worden we ook niets wijzer van.
Ik had gehoopt dat hij informatie zou geven over hoe hij het doet.
Op een gegeven moment is de ruimte op de kleine disken op en moet hij dus overgaan van de blokken verdelen over vier disken naar verdelen over drie disken.
Het oogt in ieder geval niet als hybrid raid zoals met SHR, maar kan het onder water natuurlijk nog steeds wel zijn.
Misschien eens een Raid 0 maken met twee kleine en een grote disk.
(Alleen als je het zelf ook interessant vind, want echt nut heeft het natuurlijk niet)
-
Misschien eens een Raid 0 maken met twee kleine en een grote disk.
(Alleen als je het zelf ook interessant vind, want echt nut heeft het natuurlijk niet)
Natuurlijk vind ik het interessant, daar heb ik TEST DSsen voor, Lucky me ;D 8)
Ben zo terug.
-
[attachimg=1]
root@DS411Slim:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid0 sdc3[2] sdb3[1] sda3[0]
630221952 blocks super 1.2 64k chunks [3/3] [UUU]
md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
2097088 blocks [4/4] [UUUU]
md0 : active raid1 sda1[0] sdb1[1] sdc1[3] sdd1[2]
2490176 blocks [4/4] [UUUU]
unused devices: <none>
root@DS411Slim:~#
root@DS411Slim:~# mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Feb 23 20:04:59 2019
Raid Level : raid0
Array Size : 630221952 (601.03 GiB 645.35 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Sat Feb 23 20:04:59 2019
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
Name : DS411Slim:2 (local to host DS411Slim)
UUID : 816e2254:6fe272a5:8e56e987:3dede531
Events : 0
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/hda3
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/sdc3
root@DS411Slim:~#
root@DS411Slim:~# mdadm --detail /dev/md1
/dev/md1:
Version : 0.90
Creation Time : Sat Feb 23 13:14:10 2019
Raid Level : raid1
Array Size : 2097088 (2048.28 MiB 2147.42 MB)
Used Dev Size : 2097088 (2048.28 MiB 2147.42 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sat Feb 23 20:23:50 2019
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
UUID : 5c564047:b5ab232e:ad7e347f:026e0df3 (local to host DS411Slim)
Events : 0.18
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
2 8 34 2 active sync /dev/sdc2
3 8 50 3 active sync /dev/sdd2
root@DS411Slim:~#
Vreemd om te zien:
Active Devices : 4
Working Devices : 4
3 8 50 3 active sync /dev/sdd2
root@DS411Slim:~# mdadm --examine /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 816e2254:6fe272a5:8e56e987:3dede531
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 20:04:59 2019
Raid Level : raid0
Raid Devices : 3
Avail Dev Size : 146657440 (69.93 GiB 75.09 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 83f1316f:c33bf50c:01d296d2:f0578eb7
Update Time : Sat Feb 23 20:04:59 2019
Checksum : bf50293a - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 0
Array State : AAA ('A' == active, '.' == missing)
root@DS411Slim:~#
root@DS411Slim:~# mdadm --examine /dev/sdb3
/dev/sdb3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 816e2254:6fe272a5:8e56e987:3dede531
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 20:04:59 2019
Raid Level : raid0
Raid Devices : 3
Avail Dev Size : 146657440 (69.93 GiB 75.09 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 15b41c74:4f8903e7:483ebff4:6c5bef7c
Update Time : Sat Feb 23 20:04:59 2019
Checksum : 85d2a91d - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 1
Array State : AAA ('A' == active, '.' == missing)
root@DS411Slim:~#
root@DS411Slim:~# mdadm --examine /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 816e2254:6fe272a5:8e56e987:3dede531
Name : DS411Slim:2 (local to host DS411Slim)
Creation Time : Sat Feb 23 20:04:59 2019
Raid Level : raid0
Raid Devices : 3
Avail Dev Size : 967129120 (461.16 GiB 495.17 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1035a3c8:ac2e2861:73de2282:b23f51dd
Update Time : Sat Feb 23 20:04:59 2019
Checksum : 732abb67 - correct
Events : 0
Chunk Size : 64K
Device Role : Active device 2
Array State : AAA ('A' == active, '.' == missing)
root@DS411Slim:~#
mdadm --examine /dev/sdd3
mdadm: No md superblock detected on /dev/sdd3.
root@DS411Slim:~#
Dit klopt dus.
-
Schiet mij maar lek.
Met drie disken waarvan 2 kleine kun je onmogelijk de volledige capaciteit in RAID 0 maken.
Enige conclusie is dat hij als de kleine disken vol raken hij gewoon overgaat op alleen die grote disk.
De enige reden waarom normaal gesproken Raid 0 gebruikt wordt, is performance en in een thuis Nas kun je dat nauwelijks meten, want daar is altijd het netwerk de bottleneck.
Ik heb zelf een externe behuizing met twee disken en een eSata aansluiting.
Die kun je met dipswitches in RAID 0 zetten en dan merk je echt performance winst.
Wel bijzonder is dat wat jij ook al opmerkte dat de systeem partitie en de swap partitie ( md0 en md1) nog steeds denken dat er een raid1 set van vier disken is.
Zal wel komen doordat je vast niet terug gegaan bent naar fabrieksinstellingen, want dan worden die partities pas echt verwijdert, nu zal alleen DSM het waarschijnlijk bijhouden, want anders zou hij gaan zeuren dat er een systeem partitie ontbreekt.
-
Zal wel komen doordat je vast niet terug gegaan bent naar fabrieksinstellingen
Klopt, ik heb alleen Volume/Pool verwijderd en nieuw gemaakt.
Ik ga niet terug gaan naar fabrieksinstellingen en weer testen met 3 HD's, de resultaten zullen wel dezelfde zijn m.u.v. de gemaakte opmerkingen. ;)
-
Je hebt helemaal gelijk.
-
Even terug op het oorspronkelijke onderwerp. Ik kan me zo maar voorstellen dat Synology in de restore functie een bandbreedte limiet heeft ingesteld.
Als je er van uitgaat dat de vault server meerdere backup en restore operaties tegelijk aan moet kunnen dan mag het natuurlijk niet zo zijn dat één cliënt alle bandbreedte opsnoept.
Er zijn op meerdere plekken op fora klachten te vinden dat Hyperbackup restore traag is. Men meldt zelfs dat het terugzetten van grote hoeveelheden data sneller gaat als je het via de Windows Hyperbackup explorer doet.