Drie schijven samenvoegen, wat is wijsheid?

[Tim.k]

Tweakers,

Mijn oude harde schijf loopt langzaamaan uit zijn voegen. Mijn serie en film collectie blijft maar groeien en daarom heb ik drie nieuwe 3TB disks gekocht.

Deze drie schijven wil ik samenvoegen, de schijven los gebruiken is geen optie ivm automatisch downloaden van series, indexeren etc.

Maar hoe? Wat is wijsheid?

De fysieke PC draait Proxmox, een virtualisatieplatform, met daarop o.a. Windows Server 2016, de media server.

Nu ben ik op twee opties gekomen, RAID0 en JBOD.

De extra performance van RAID0 heb ik niet nodig maar een groot voordeel tegenover JBOD is dat de schijven gelijk belast worden en dus ook de "ouderdoms-schade" delen (lijkt mij). Nadeel is dat alles foetsie is mocht een schijf de geest geven maar dat vind ik niet zo erg aangezien het maar series en films zijn.

Met JBOD worden de schijven pas gevuld wanneer de ander vol zit waardoor de een meer ouderdoms-schade heeft dat de ander maar als ik het internet mag geloven is er een mogelijkheid om de data van de disks die niet kapot zijn te halen. Dit lijkt mij in mijn situatie nogal sterk aangezien er twee bestandssystemen (op fysiek niveau en virtueel niveau) aanwezig zullen zijn? Of zit ik hier mis?

Wat vinden jullie wijsheid? Voor JBOD of voor RAID0 gaan? Dat de data eventueel verloten gaat is geen ramp, er is geen budget voor parity maar als ik bij JBOD (met mijn configuratie) eventueel nog wat kan redden is dat natuurlijk mooi meegenomen. Ook vraag ik mij af in welke opstelling de schijven het langst mee zullen gaan? RAID0 waar alles gebalanceerd wordt of JBOD die een voor een vult? Een fail zit in een klein hoekje, dat weet ik maar theoretisch gezien?

Of is er nog een hele andere oplossing waarbij er een disk verloren kan gaan maar de data op de andere nog bruikbaar is?

Alvast bedankt.

[Tortelli]

Raid 0 is niet erg slim om te doen, 1 schijf kapot en je bent al je data kwijt. JBOD is de way to go in dit geval denk ik.

[Tim.k]

Tortelli schreef op woensdag 02 november 2016 @ 19:41:
Raid 0 is niet erg slim om te doen, 1 schijf kapot en je bent al je data kwijt. JBOD is de way to go in dit geval denk ik.

Zou je dit kunnen toelichten? In mijn situatie, twee filesystems een fysiek en een virtueel lijkt mij praktisch onmogelijk om te recoveren met JBOD.

[Mijzelf]

Met JBOD worden de schijven pas gevuld wanneer de ander vol zit waardoor de een meer ouderdoms-schade heeft dat de ander

Dat is volgens mij niet waar. Alle moderne systemen zetten de files zoveel mogelijk verspreid over de schijf (of, bij JBOD, de schijven) om fragmentatie te voorkomen.

maar als ik het internet mag geloven is er een mogelijkheid om de data van de disks die niet kapot zijn te halen. Dit lijkt mij in mijn situatie nogal sterk aangezien er twee bestandssystemen (op fysiek niveau en virtueel niveau) aanwezig zullen zijn? Of zit ik hier mis?

Er is maar 1 filesysteem, op een virtuele partititie die uit verschillende schijven of partities bestaat. Als je daar een schijf uittrekt, is het filesysteem kapot. Maar de data is er gedeeltelijk nog, en kan mogelijk met een low-level recovery worden gered.
Overigens kun je soms het filesysteem nog (gedeeltelijk) benaderen, als de headers en root directory nog bestaan.

Wat voor OS gebruik je? Als hij fuse ondersteund zou je naar mhddfs kunnen kijken.

[Tim.k]

Wat ik op Google kan vinden over hoe JBOD de schijven vult dan vind ik bij zowel mdadm als LVM dat de schijven een voor een gevuld worden.

Hoe kan ik slechts 1 filesystem hebben / krijgen? Op de fysieke server, worden de schijven als EXT 3 / 4 gemount waar vervolgens een qemu bestand op wordt gezet als verituele schijf voor Windows die nog gepartitioneerd dient te worden in Windows zelf. Of je dan 3 losse volumes aan windows koppelt en die in JBOD zet of dat je de JBOD op Linux niveau maakt blijf je toch altijd met twee filesystems onder elkaar zitten wat het praktisch onmogelijk maakt om ooit te restoren?

De fysieke server draait op Debian, de virtuele machine waar de opslag voor nodig is is Windows Server 2016. mhddfs kan op Debian (de fysieke server) maar dit zal hoe dan ook nog steeds het filesystem van Windows breken heb ik het dan correct dat indien een schijf kapot gaat ik alleen het filesystem van Windows moet zien te restoren om bij mijn data te kunnen?

[PilatuS]

Waarom heb je niet gewoon een 6TB of 8TB schijf gekocht ? Persoonlijk vind ik RAID of JBOD niet erg handig.

[dcm360]

Welke versie van Proxmox gebruik je? Want Proxmox kan ook ZFS vanaf ergens in de 3.x reeks. Dan zou je kunnen overwegen om ze in raid-z1 te plaatsen en via een block-device of nfs de ruimte aan de Windows-vm beschikbaar te maken.

[Tim.k]

PilatuS schreef op woensdag 02 november 2016 @ 21:40:
Waarom heb je niet gewoon een 6TB of 8TB schijf gekocht ? Persoonlijk vind ik RAID of JBOD niet erg handig.

Erg handig is het inderdaad niet maar deze oplossing was 110 euro goedkoper t.o.v. een enkele 8TB HDD waar ik nu zelfs nog een extra TB er bij heb.

dcm360 schreef op woensdag 02 november 2016 @ 21:44:
Welke versie van Proxmox gebruik je? Want Proxmox kan ook ZFS vanaf ergens in de 3.x reeks. Dan zou je kunnen overwegen om ze in raid-z1 te plaatsen en via een block-device of nfs de ruimte aan de Windows-vm beschikbaar te maken.

4.3, maar met raid-z1 verlies ik de capaciteit van een schijf. Zoals ik al zij maakt het eventueel verliezen dan de data mij niet zo veel uit dus daar 3TB voor opofferen is het niet waard.

[WouterG]

Ik gebruik voor zoiets drivepool, alleen hyper-v als virtualisatie. Lekker eenvoudige oplossing en werkt erg goed hier.

[dcm360]

Tim.k schreef op woensdag 02 november 2016 @ 22:35:
[...]

4.3, maar met raid-z1 verlies ik de capaciteit van een schijf. Zoals ik al zij maakt het eventueel verliezen dan de data mij niet zo veel uit dus daar 3TB voor opofferen is het niet waard.

In dat geval kan je ook stripen met ZFS. Ik zou het niet aanraden, maar als jij er geen problemen mee hebt...

[RGAT]

Een 3TB disk kost net 100 euro, wat voor data is minder dan 100 euro waard

[Mijzelf]

Tim.k schreef op woensdag 02 november 2016 @ 21:37:
Wat ik op Google kan vinden over hoe JBOD de schijven vult dan vind ik bij zowel mdadm als LVM dat de schijven een voor een gevuld worden.

Bij LVM ben ik niet geheel zeker, maar mdadm heeft geen enkele controle over hoe en waar de array wordt gevuld. Er is een vaste mapping van array sectoren naar disk sectoren. Dus de volgorde waarop de schijven worden gevuld is geheel in handen van het filesysteem.
Ik *denk* dat dat bij LVM ook het geval is, maar die zou misschien dynamisch kunnen remappen. Maar waarom zou hij dat doen?

Hoe kan ik slechts 1 filesystem hebben / krijgen? Op de fysieke server, worden de schijven als EXT 3 / 4 gemount waar vervolgens een qemu bestand op wordt gezet als verituele schijf voor Windows die nog gepartitioneerd dient te worden in Windows zelf.

Ja sorry, daar had ik even overheen gelezen. Je heb inderdaad 2 filesystemen, waarbij het binnenste filesysteem zich in een file in het buitenste bevind. Die file zou ook nog wel eens een sparse file kunnen zijn, wat inderdaad de kans op recovery behoorlijk verkleint.

De fysieke server draait op Debian, de virtuele machine waar de opslag voor nodig is is Windows Server 2016. mhddfs kan op Debian (de fysieke server) maar dit zal hoe dan ook nog steeds het filesystem van Windows breken heb ik het dan correct dat indien een schijf kapot gaat ik alleen het filesystem van Windows moet zien te restoren om bij mijn data te kunnen?

Het werkt anders. Bij mhddfs hebben alle 3 schijven hun eigen filesysteem, en mhddfs legt daar een virtueel filesysteem overheen. De files die je wegschijft worden via een load-balancing systeem naar een van de schijven geschreven. Als er een schijf sneuvelt, lijkt het dus of at random 1/3 van de files zijn verdwenen, maar de rest is gewoon in orde.
Consequentie is dat je nooit een file kwijt kunt die groter is dan de vrije ruimte op 1 van de schijven.
Als jouw virtuele server dus de gezamenlijke ruimte nodig heeft als lokale schijf, gaat het niet werken. Maar als je de gezamenlijke ruimte via Samba aan kunt bieden wel.