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...
Topic: Eén diskgroep, twee volumes, snelheid duikt de kelder in... (gelezen 4161 keer)
Vergelijkbare onderwerpen (5)
20 december 2013, 16:22:37
