Nieuwe NAS aankopen, maar welke config kiezen voor 50TB?

[Neobahamuth]

Als RAID- en NAS- beginner, zoek ik graag even wat advies van de kenners ivm de aankoop en configuratie van een nieuwe NAS.
Ik heb ter voorbereiding heel wat instructievideo's gezien en hardware opgezocht.

TLDR: huidige JBOD opstelling fucked --> Synology aankopen maar welke instellingen kiezen (want ze nadien wijzigen is niet mogelijk.)

Huidige situatie:

• 50TB aan media op gewone consumenten HD's met wisselende grootte's (2-8TB)
• via HD-cages via USB aan een mini-pc (Win) en dan delen (SMB)
• JBOD (géén RAID)
• media afspelen via Kodi op Android box

---

Probleem:
Vaak reageert een schijf niet meer.
Na reboot is de MFT foetsie (Data staat er nog op want verkenner zegt dat HD vol is, maar geen bestanden te zien. Enkel via recovery software zijn de bestanden te zien.)
Na scannen met CrystalDiskInfo bleken 2 HD's ook effectief slecht te zijn volgens SMART.
(Sommige schijven waren 5-9j oud en gewone (niet-NAS) schijven!)

---

Aan te kopen oplossing:

• Synology DS1821+
• 8x 8TB Toshiba N300 HDWG480UZSVA*

(*)HD compatibiliteit getest op Synology-site.

---

Doelstellingen:

• betrouwbare opslag
• shares voor Android mediaspelers
• gecentraliseerde KODI dbase op NAS
• van buiten netwerk bereikbaar

De video's die ik al bekeken heb:

• Synology NAS Setup Guide First-time Synology NAS Installation & Setup Guide
• Synology NAS DSM 7 Setup Guide - ALL Parts Synology NAS Setup Guide Part I - 2021/2022 - DSM 7 - RAID - VOLUMES - SHARES - MAPPED DRIVES
• Setup a Synology Server with a Shared Database for Kodi - Complete Start to Finish Guide!

---

Vragen:

• 1. JBOD / RAID / SHR1?

Ik heb heel wat video's en site bekeken ivm de verschillen tussen deze opties.
Ik gebruikte vroeger altijd JBOD aangezien je enkel de data kwijt bent die enkel op die schijf stond.
Ik weet dat RAID 5 - of nog liever SHR1 - gewoon de meest logische en veiligste optie is. (Buiten RAID6 of hoger, en ja, ik weet dat RAID geen back-up is.)
Als ik gewoon die optie kies, zal ik met deze opstelling geen hoofdpijn hebben.

Maar .... Als het technisch mogelijk is (maar vooral ook praktisch is), zou ik graag willen checken of JBOD alsnog een optie is.
Bij RAID 5 is mijn capaciteit sowieso minder (n-1 schijven) en ik vrees dat wanneer een schijf zou uitvallen en een RAID-array van 50TB gerestored moet worden, de kans vele malen groter wordt dat nog een schijf dat extreem intensief lees- en schrijfproces niet zou overleven.
De schijven zullen namelijk allemaal even oud zijn en - normaal gezien - quasi identieke slijtage hebben.
Dus als er nog een schijf tijdens de rebuild faalt, dan ben ik alsnog alle data kwijt.
Liever geen vangnet (ja, ik weet dat RAID geen back-up is) dan een vals gevoel van veiligheid waarop ik zou rekenen.

Bij het initialiseren van je schijven in de NAS moet je pool(s) en volume(s) aanmaken, aldus de video.
Als ik één grote pool zou maken in JBOD, dan lees ik dat ik bij 1 schijf uitval alsnog alle data kwijt ben.

De vraag: Kan ik per schijf (8stuks) telkens een aparte pool maken met daarin telkens 1 volume?
Dus bv:

• pool 1: HD1, volume "media1"
• pool 2: HD2, volume "media2"
• pool 3: HD3, volume "media3"
• pool 4: HD4, volume "media4"
• pool 5: HD5, volume "media5"
• pool 6: HD6, volume "media6"
• pool 7: HD7, volume "media7"
• pool 8: HD8, volume "media8"

En klopt het dat bij uitval van één schijf alle andere data veilig is, zonder enige rebuild nodig?

Of denken jullie nu: "Neobadmuts, nou kappen met die onzin en kies gewoon SHR1 zoals een normale persoon. Van 1 schijf minder capaciteit ga je heus niet dood."

• 2. Btrfs vs EXT4?

Na wat gelezen te hebben, lijkt BTRFS de betere keuze qua veiligheid EXT4 zou iets sneller zijn, maar dat boeit mij niet zo.
Klopt dit?

• 3. Beginnen met lege HD's?

Volgens de video's worden HD's sowieso gewist bij het aanmaken van een pool of RAID/SHR1.
Moeten ze ook leeg zijn bij JBOD?
Kan ik dus maw volle HD's erin proppen? Maar dan zijn die NTFS ipv Btrfs?

• 4. Uitbreidingsmogelijkheden

Aangezien ik hoogstwaarschijnlijk 1 HD moet opgeven qua capaciteit bij RAID5/SHR1, ga ik snel tegen een probleem aanlopen qua capaciteit.
(Neen, ik wil voorlopig geen grotere HD's kopen dan 8TB.)
Synology biedt uitbreidingsmogelijkheden zoals de Synology DX517


--> Maar hoe exact verbind ik die met de Synology DS1821+? Ik weet dat er een aparte poort voor is, maar wat voor kabel heb je nodig?
--> Is dit het enige model (DX517) dat je als uitbreiding kan gebruiken, of is eenderwelk ander (goedkoper) model ook mogelijk te verbinden?
--> En hoe zit dat met je bestaande RAID5/SHR1 array wanneer je een schijf of 2 erbij prikt? Moet alles gerebuild worden of maakt dat niet uit als hij er plots een extra schijf bij ziet?

• 5. Data migratie

--> Wat is de snelste manier om mijn data op de NAS te krijgen?
--> Moet alles via het netwerk overgepompt worden?
--> Zit er in het DSM OS trouwens een gewone browser waarmee je kan surfen en iets downloaden?

• 6. Kodi

Volgens deze video kan ik 2 aagepaste bestanden (advancedsettings.xml en sources.xml) op de NAS bewaren en via KODI deze als source toevoegen.
Wanneer ik op Kodi mediaspeler 1 de hele bibliotheek laat scannen, dan kan de 2de Kodi mediaspeler gewoon deze dbase hergebruiken ipv ook alles te moeten scannen?
--> Maar waar wordt die dbase bewaard? Op de NAS of lokaal op Kodi mediaspeler 1?


Ja, een heleboel vragen dus. Maar eens ik bepaalde instellingen kies bij de configuratie van de NAS kan ik niet meer terug. Daarom wil ik mij eerst zo goed mogelijk informeren.

Alvast bedankt voor alle suggesties en advies!

[MarkyB]

1 en 2: Ik zou kiezen voor RAID op basis van BTRFS,schijf kapot, schijf vervangen, en door zonder dataverlies.

3: Schijven die je koopt zijn leeg, plaats ze dan in de nas en laat de nas de schijven formatteren.


4: Als je nu al tegen de capaciteitbeperking aan loopt kan je beter grotere schijven kopen dan een uitbreiding.

5: Helaas, pompen.

6: weinig verstand van kodi maar ik vermoed dat een opgebouwde database lokaal op kodi draait.

[platvoet]

Betrekking tot vraag 6, je kan een mariadb database draaien op je synology en daar de data van Kodi in plaatsen. Verder zou ik kiezen voor raid 5 of 6, synology noemt dit shr1 of shr2 volgens mij. Nooit gaan voor riad 0, als er een disk kapot ben je al je data kwijt.

Disken kies ik meestal voor Iron wolfs of iron wolfs pro's.

De DX unit verbind je met de meegeleverde kabel aan je nas, is volgens mij xsata, persoonlijk zou ik kiezen voor grotere schijven dan 8 tb, of een unit waar meer disken inkunnen.

[ Voor 3% gewijzigd door platvoet op 08-01-2023 10:04 ]

[Neobahamuth]

Bedankt voor de reacties tot nu toe.

1. Ik ga gewoon maar voor SHR1 kiezen met BTRFS. Minder gedoe.
2. Lege nieuwe schijven erin.
3. Enkele grotere HD's kopen
Stel ik dat ik deze schijven erin steek

• 2x 8 TB
• 5x 10 TB

--> Wat gebeurt er wanneer ik in vrije slot 8 in de toekomst een nieuwe schijf (bv 10TB) bij steek?
Wat gebeurt er met de huidige RAID-opstelling? Neem de NAS die nieuwe schijf gewoon mee als ik die aan de pool toevoeg of begint het rebuilden van de RAID helemaal opnieuw?

[Ben(V)]

Het meest verstandige is gewoon een storage pool van alle disken in SHR te maken.
Alle andere opties leveren of meer overhead op of beschermen je niet tegen disk uitval.
Met zoveel disken is het zelfs te overwegen om SHR-2 te gebruiken in plaats van gewoon SHR, SHR-2 bescherm tegen het gelijktijdig uitvallen van twee disken.

Btrfs heeft enkel voordelen als je de extra functionaliteit zoals het maken van snapshots wilt gebruiken, voor data zekerheid is de toegevoegde waar helemaal niets en alleen gebaseerd op "wishful thinking" en marketing.

Alle disken die je erin stopt worden door DSM van drie nieuwe partities voorzien, te weten een systeem partitie, een swap partitie en een data partitie.
De systeem en swap partitie staan op elek disk met elkaar in een mirror en die zijn via de gui of het netwerk niet zichtbaar.
Op de data partities worden de storage pool(s) aangemaakt en daarop de volumes(s).
Alleen volumes worden geformatteerd.

De uitbreiding unit wordt geleverd met een eSata kabel die je voor de verbinding met je Nas gebruikt.

De kodi database wordt uiteraard op de Nas geplaatst als je daar Kodi op installeert.

Data wordt via het netwerk gekopieerd.

[mrottjers]

Ik zou echt even kijken naar unraid. Kun je alle disks door elkaar gebruiken en je bestaande, nog werkende, gewoon onderdeel van de array maken. Een grote parity disk erbij en een paar nieuwe als toekomstige opslag.

[Flans]

Als je kodi normaal geïnstalleerd hebt dan wordt er lokaal een SQL database neergezet. Je kunt deze database ook op je nas zetten en die via het netwerk aanroepen. Doordat je database draait op je netwerk kun je dus 'verder kijken' wanneer je op een ander device inlogt.

Waarom synology gebruiken in dit geval? Het zou wellicht interessant kunnen zijn om zelf een server in elkaar te zetten met bijvoorbeeld unraid als OS. Dat geeft je extra vrijheid, uitbreidingsmogelijkheden en zal waarschijnlijk goedkoper zijn.

[Ben(V)]

Een disk vervangen door een grotere disk geeft je pas extra ruimte als je er twee vervangt.
Als je bijvoorbeeld twee 8TB disken vervangt door twee 10 TB dan zal SHR onder water van die overgebleven 2x 2TB een raid 1 set maken die netto dan 1 Tb oplevert.

En unraid heeft precies dezelfde mogelijkheden en beperkingen als DSM maar dan moet je alles zelf doen.

En kodi installeer je als je een Nas hebt natuurlijk op die Nas en niet meer op je PC of een andere client.

[ Voor 13% gewijzigd door Ben(V) op 08-01-2023 10:13 ]

[DVX73]

Waarom kies je niet voor grotere HDD's bijvoorbeeld: uitvoering: Seagate Exos X18 (SATA, Standard model), 18TB

Lagere kosten per TB, echter meer mogelijk dataverlies bij defect.

In het verlengde hiervan denk ook gelijk na over een backup strategie.
Op mijn eigen NAS maak ik enkel een online offsite backup van foto's.

[Dacuuu]

Is UNRAID wat voor je? Ik vind het heerlijk draaien. En je bent flexibel met je hardeschijven.

[DVX73]

Ten aanzien van je doelstellingen van buiten het netwerk benaderbaar, doe dit niet of veilig, bijvoorbeeld door een VPN verbinding op te zetten, de betere modems/routers bieden deze mogelijkheid.

[leonbong]

Koop een qnap die heeft ZFS modellen. Met zo’n grote opslag hoeveelheid zou ik niet gaan knoeien met mdam met btrfs er bovenop.

[pennywiser]

leonbong schreef op zondag 8 januari 2023 @ 10:24:
Koop een qnap die heeft ZFS modellen. Met zo’n grote opslag hoeveelheid zou ik niet gaan knoeien met mdam met btrfs er bovenop.

Waarom eigenlijk niet?

[leonbong]

Zfs is betrouwbaarder.

[Neobahamuth]

Wow, vele reacties, waarvoor dank.

1. Ik ben al 18jaar met mijn eigen hardware aan het klooien. Ik wil nu een kant-en-klare oplossing, geen gedoe.
Synology heeft een grote community en je kan veel info en tutorials vinden.
Daarom geen interesse meer in eigen creaties.

Grotere schijven blijken na inzien toch geen slecht idee. Die Seagate Exos X18 wordt echter niet officieel ondersteund door Synology. De X16 wel.

Als ik dit neem:
2 x 8TB
4x 16TB

Dan blijft er volgens de Synology RAID calculator nog netto 64TB over. Daar kom ik voorlopig wel even mee verder.

Qua beveiliging indien NAS via buiten bereikbaar; da's een zeer goeie tip. Ik ga dat zeer nauwkeuring nakijken.

[Sethro]

Waarom niet gewoon 5 of 6x 16GB?

[Neobahamuth]

Sethro schreef op zondag 8 januari 2023 @ 10:31:
Waarom niet gewoon 5 of 6x 16GB?

Omdat ik een spinternieuwe 8TB heb liggen (ongeopend) + eentje die nog maar 13389 uren gedraaid heeft.

[Ernemmer]

Neobahamuth schreef op zondag 8 januari 2023 @ 10:34:
[...]

Omdat ik een spinternieuwe 8TB heb liggen (ongeopend) + eentje die nog maar 13389 uren gedraaid heeft.

Verkopen in de V&A en gewoon met 100% nieuwe schijven beginnen.

6x18 er in en je hebt de aankomende 5+ jaar weer genoeg opslagruimte

[ Voor 10% gewijzigd door Ernemmer op 08-01-2023 10:36 ]

[DVX73]

Synology heeft een tool om je NAS goed te kunnen beveiligen de zgn securityscan https://kb.synology.com/n...curityscan_desc?version=7

Mijn advies is de aanbevelingen hieruit op te volgen voordat je data ga overzetten.

[ Voor 4% gewijzigd door DVX73 op 08-01-2023 10:38 ]

[Neobahamuth]

DVX73 schreef op zondag 8 januari 2023 @ 10:36:
Synology heeft een tool om je NAS goed te kunnen beveiligen: https://kb.synology.com/n...curityscan_desc?version=7

Mijn advies is de aanbevelingen hieruit op te volgen voordat je data ga overzetten.

Top tip, bedankt! Bookmarked.

[pennywiser]

leonbong schreef op zondag 8 januari 2023 @ 10:27:
Zfs is betrouwbaarder.

Waaruit blijkt dat?

[Neobahamuth]

Ernemmer schreef op zondag 8 januari 2023 @ 10:35:
[...]


Verkopen in de V&A en gewoon met 100% nieuwe schijven beginnen.

6x18 er in en je hebt de aankomende 5+ jaar weer genoeg opslagruimte

Je hebt gelijk, maar heb niet zoveel zin om tijd te besteden aan verkoop van spullen.
Bovendien is 6x18TB een pak meer dan ik eigenlijk wou uitgeven.

[DVX73]

Neobahamuth schreef op zondag 8 januari 2023 @ 10:39:
[...]

Je hebt gelijk, maar heb niet zoveel zin om tijd te besteden aan verkoop van spullen.
Bovendien is 6x18TB een pak meer dan ik eigenlijk wou uitgeven.

Waarom koop je er dan niet 3 of 2?
Je kan er later altijd nog een paar bijzetten.

[Neobahamuth]

DVX73 schreef op zondag 8 januari 2023 @ 10:41:
[...]


Waarom koop je er dan niet 3 of 2?
Je kan er later altijd nog een paar bijzetten.

1. Officieel niet gecheckt op compatibiliteit bij Synology.
2. 3x 18TB is netto slechts 36TB bij SHR1.

4x16TB (zelfde type) + 2x8 zou wel even moeten voldoen.

[DVX73]

Neobahamuth schreef op zondag 8 januari 2023 @ 10:45:
[...]

1. Officieel niet gecheckt op compatibiliteit bij Synology.
2. 3x 18TB is netto slechts 36TB bij SHR1.

4x16TB (zelfde type) + 2x8 zou wel even moeten voldoen.

Ik bedoelde naast de HDD's die je al hebt.
Dan heb je meer dan 40TB.

[Neobahamuth]

DVX73 schreef op zondag 8 januari 2023 @ 10:49:
[...]


Ik bedoelde naast de HDD's die je al hebt.
Dan heb je meer dan 40TB.

Ah...
Ernaast zou wel kunnen, maar dan nog neem ik liever de X16 aangezien die wel 100% zeker comptaibel zijn.
En dan zou ik er nog steeds 4x X18 nodig hebben naast die 2x 8TB en dan wordt het totaalplaatje net iets te duur.

[sOid]

Er is al een hoop verstandigs geschreven maar heb nog een paar dingen toe te voegen.
- Verdiep je in Docker, als je dat nog niet kent. En kies een Syno die dat ondersteunt. Ongelooflijk fijn platform. Zo heb ik Sonarr en Radarr gekoppeld aan Qbittorrent en getunneld via een VPN-container. Daarnaast een VPN-container om ‘in te bellen naar huis’ via Wireguard. Minder geklooi dan VPN op je router.
- Vergeet niet om een UPS te nemen. Zeker met zulke enorme arrays. Hoeft het zaakje (wat mij betreft)) geen uren op te draaien, maar wel prettig als je NAS zichzelf bij stroomuitval netjes kan uitschakelen.

Tevens ben ik voorstander van mixen van verschillende schijven en in geval van dezelfde schijven kopen bij andere winkels. Op die manier doe je aan risicominimisatie als over een jaar blijkt dat er een catastrofe fout zit in een prodcutlijn/productiedatum.

Zelf heb ik WD en Seagate schijven in mijn Syno. Naar volle tevredenheid. Krijg ook netjes een seintje bij fouten in SMART-check.

[ Voor 24% gewijzigd door sOid op 08-01-2023 11:06 ]

[F_J_K]

Ben(V) schreef op zondag 8 januari 2023 @ 10:08:
bescherm tegen het gelijktijdig uitvallen van twee disken.

Inderdaad. Als alle schijven tegelijkertijd zijn gekocht, is het niet ondenkbaar dat bij uitval van 1 schijf de stress van het rebuilden een tweede schijf laat sneuvelen.

En/of koop een aantal schijven pas over een jaar of twee om zo de kans op gelijktijdige uitval wat te verminderen.

-

Er is nu 50TB, overwogen wordt ongeveer evenveel aan nieuwe schijven te kopen. Dat suggereert dat er geen data meer bij komt. Lijkt me stug. Is het niet beter op de groei te kopen?

[F_J_K]

sOid schreef op zondag 8 januari 2023 @ 11:02:
- Verdiep je in Docker, als je dat nog niet kent. En kies een Syno die dat ondersteunt. Ongelooflijk fijn platform.

Yep. De fout die ik maakte bij mijn Syno is dat die dat niet ondersteunt. Net even te duur om meteen een nieuwe te kopen, maar ik heb het heel even overwogen..

[Neobahamuth]

sOid schreef op zondag 8 januari 2023 @ 11:02:
[...]

Docker ken ik niet. Bedankt voor de tip. Ik ga wat opzoeken.
Verschillende schijven van verschillende bronnen klinkt als een goeie tip! Bedankt.

F_J_K schreef op zondag 8 januari 2023 @ 11:12:
[...]

SHR2/RAID6 heb ik overwogen, maar heb geen zin om n-2 schijven in te boeten. Dus liever niet.
Zoals in mijn OP geschreven, vrees ik bij een restore van een array op nog meer uitval van schijven.
Als er bij SHR2/RAID6 2 schijven falen en de restore molt er eentje door de zeer intensieve restore operatie, dan ben ik alsnog de sjaak.

Volgens deze lijst ondersteunt de DS1821+ Docker wel. Ik weet niet of ik het echter nodig heb.

[ Voor 4% gewijzigd door Neobahamuth op 08-01-2023 11:22 ]

[DVX73]

Ik gebruik zelf mijn NAS puur voor opslag en wil geeneens docker draaien ivm stabiliteit. Misschien voor mensen die veel met home automation in de weer zijn.
Maar ik gebruik de VPN van mijn router en een Raspberry Pi voor pi-hole.

[Ben(V)]

De kans op uitval tijdens een restore is net zo groot als tijdens normaal gebruik.
Je moet gewoon regelmatig een uitgebreide s.m.a.r.t. scan en een disk scrub laten uitvoeren door DSM, daarmee zorg je ervoor dat je probleem disken vroegtijdig kunt vervangen.
Als je wacht tot een disk echt de geest geeft loop je de kans dat intussen een andere disk ook op het randje staat en er over heen gaat op het moment dat de eerste echt defect gaat.
De rebuild maakt die kans niet groter of kleiner.

De kans dat gelijktijdig gekochte disken ook gelijktijdig uitvallen is helemaal niets groter dan als je verschillende disken en/of merken hebt.
Dat zijn allemaal natte vinger ideeën die nergens op gebaseerd zijn en voornamelijk gestoeld op ervaringen uit het verleden toen disk fabrikanten hun productie proces nog niet onder controle hadden.
Als dat zo is dan zit er een productie fout bij de fabrikant en die worden vrij snel ontdekt tegenwoordig.

[leonbong]

pennywiser schreef op zondag 8 januari 2023 @ 10:39:
[...]

Waaruit blijkt dat?

Zfs heeft o.a bit rot detectie. Btrfs in theorie ook echter als btrfs op mdam wordt gebruikt geïnstalleerd functioneert dat niet.
Bij het gebruik van hele grote schijven is dat eigenlijk we essentieel.

Waardoor bij dit soort grote volumes het eigenlijk noodzakelijk is om zfs toe te passen.

[ Voor 22% gewijzigd door leonbong op 08-01-2023 12:48 ]

[Ben(V)]

Onzin.
Zfs en Btrfs doen dat helemaal niets beter dan andere file systemen.

Bitrot detection wordt veel effectiever door de firmware van de disken zelf gedaan.
Elke moderne disk slaat tegenwoordig bij elk datablok een crc op en kan daarmee detecteren of die corrupt geraakt is en zal dit melden indien het niet in staat is dit zelf te recoveren en die sector te vervangen door een van z'n reserve sectoren.
Om hier wat mee te kunnen moet je uiteraard wel een vorm van raid redundancy hebben en uiteraard moet zo'n datablok gelezen worden, vandaar het belang van regelmatig scrubben van de raidsets.

[Flans]

DVX73 schreef op zondag 8 januari 2023 @ 11:49:
Ik gebruik zelf mijn NAS puur voor opslag en wil geeneens docker draaien ivm stabiliteit. Misschien voor mensen die veel met home automation in de weer zijn.
Maar ik gebruik de VPN van mijn router en een Raspberry Pi voor pi-hole.

De koppeling tussen geen docker willen draaien en stabiliteit snap ik niet. Kun je daar wat meer over vertellen?

[DVX73]

Flans schreef op zondag 8 januari 2023 @ 13:46:
[...]


De koppeling tussen geen docker willen draaien en stabiliteit snap ik niet. Kun je daar wat meer over vertellen?

Ik heb in het verleden dingen goed gesloopt omdat ik aan het experimenteren was.

Daarom heb ik dedicated hardware om mee te experimenteren.

[upje]

Ik snap de relatie tussen experimenteren & docker niet. Je kan vast experimenten met Docker, maar je kunt Docker prima stabiel gebruiken zonder te experimenteren. Jouw opmerking dat Docker voor instabiliteit zou zorgt is volgens mij niet terecht, en daarom zou ik mensen, zoals TS, die een NAS willen aanschaffen altijd een NAS met Docker mogelijkheid adviseren.

[sOid]

F_J_K schreef op zondag 8 januari 2023 @ 11:13:
[...]

Yep. De fout die ik maakte bij mijn Syno is dat die dat niet ondersteunt. Net even te duur om meteen een nieuwe te kopen, maar ik heb het heel even overwogen..

Weet je ook zeker dat het daadwerkelijk niet werkt dan? Want op mijn 418Play wordt het officieel niet ondersteund, maar werkt het prima. Laatst nog een docker-ce update gedaan via command line want die versie was nieuwer dan via Package Center. Daarnaast draait docker compose ook prima.

DVX73 schreef op zondag 8 januari 2023 @ 11:49:
Ik gebruik zelf mijn NAS puur voor opslag en wil geeneens docker draaien ivm stabiliteit. Misschien voor mensen die veel met home automation in de weer zijn.
Maar ik gebruik de VPN van mijn router en een Raspberry Pi voor pi-hole.

Waarom zou Docker niet goed zijn voor stabiliteit? Ik heb even gecheckt, en intussen 475 dagen uptime met een stuk of 10 containers.

Daarnaast heb ik een NUC waarop m'n domotica-meuk draait (ook in docker).

[DVX73]

sOid schreef op zondag 8 januari 2023 @ 15:01:
[...]

Weet je ook zeker dat het daadwerkelijk niet werkt dan? Want op mijn 418Play wordt het officieel niet ondersteund, maar werkt het prima. Laatst nog een docker-ce update gedaan via command line want die versie was nieuwer dan via Package Center. Daarnaast draait docker compose ook prima.


[...]

Waarom zou Docker niet goed zijn voor stabiliteit? Ik heb even gecheckt, en intussen 475 dagen uptime met een stuk of 10 containers.

Daarnaast heb ik een NUC waarop m'n domotica-meuk draait (ook in docker).

We gaan misschien een beetje offtopic...
Maar in mijn geval heb ik mijn NAS puur als opslag (met bijbehorende cpu + ram) als ik hierop docker zou draaien (wat wel kan) is het reëel dat het de performance raakt.
En door foutieve configuratie van docker (images) zou dit de betrouwbaarheid van het systeem kunnen aantasten.

Hoop mitsen en maaren. Het komt er op neer dat ik de kans dat ik foto's kwijtraak wil minimaliseren (en ja ik heb offsite, offline backup's)

[sOid]

@DVX73 Ik heb geen noemenswaardige performance loss gemerkt bij gebruik van Docker.
Grootste performance impact is SMART-scans en virusscans.

Maar vooral doen waar jij je goed bij voelt natuurlijk

[dcm360]

Ben(V) schreef op zondag 8 januari 2023 @ 13:06:
Onzin.
Zfs en Btrfs doen dat helemaal niets beter dan andere file systemen.

Bitrot detection wordt veel effectiever door de firmware van de disken zelf gedaan.
Elke moderne disk slaat tegenwoordig bij elk datablok een crc op en kan daarmee detecteren of die corrupt geraakt is en zal dit melden indien het niet in staat is dit zelf te recoveren en die sector te vervangen door een van z'n reserve sectoren.
Om hier wat mee te kunnen moet je uiteraard wel een vorm van raid redundancy hebben en uiteraard moet zo'n datablok gelezen worden, vandaar het belang van regelmatig scrubben van de raidsets.

Het jammere van klassiek raid is alleen wel dat de correctie van fouten 'dom' is, bij gebrek aan informatie om mee te bepalen wat de correcte data zou moeten zijn. BTRFS en ZFS kunnen bepalen welke schijven er correcte data teruggeven en welke niet, en aan de hand daarvan de correctie doorvoeren. En een losse schijf kan al helemaal niets meer corrigeren.
Los daarvan zijn moderne features als snapshots en subvolumes best nuttig, al wordt de meerwaarde daarvan vaak pas duidelijk als je er eens niet mee kan werken op een 'oud' systeem.

[F_J_K]

sOid schreef op zondag 8 januari 2023 @ 15:01:
[...]
Weet je ook zeker dat het daadwerkelijk niet werkt dan? Want op mijn 418Play wordt het officieel niet ondersteund, maar werkt het prima. Laatst nog een docker-ce update gedaan via command line want die versie was nieuwer dan via Package Center. Daarnaast draait docker compose ook prima.

offtopic:
Ugh, nooit aan gedacht te proberen Thx

[Ben(V)]

dcm360 schreef op zondag 8 januari 2023 @ 15:30:
[...]

Het jammere van klassiek raid is alleen wel dat de correctie van fouten 'dom' is, bij gebrek aan informatie om mee te bepalen wat de correcte data zou moeten zijn. BTRFS en ZFS kunnen bepalen welke schijven er correcte data teruggeven en welke niet, en aan de hand daarvan de correctie doorvoeren. En een losse schijf kan al helemaal niets meer corrigeren.
Los daarvan zijn moderne features als snapshots en subvolumes best nuttig, al wordt de meerwaarde daarvan vaak pas duidelijk als je er eens niet mee kan werken op een 'oud' systeem.

Ook weer onzin.
Als je een hogere raid dan raid 1 hebt wordt gewoon de boel netjes herstelt , een hogere raid kan de boel herstellen als een van de disken corrupt is, alleen een raid 1 kan dat niet.
En zoals ik al zei, als het bitrot is doet de firmware van de disk dat gewoon zelf en merk je er helemaal niets van.
Dat het bitrot verhaal is gewoon onzin bij de huidige disken.

En ja als je behoefte aan snapshot hebt dan hebt je zfs of btrfs nodig, maar dan zie ik verder geen verschil tussen die twee.

[dcm360]

Ben(V) schreef op zondag 8 januari 2023 @ 17:28:
[...]


Ook weer onzin.
Als je een hogere raid dan raid 1 hebt wordt gewoon de boel netjes herstelt , een hogere raid kan de boel herstellen als een van de disken corrupt is, alleen een raid 1 kan dat niet.
En zoals ik al zei, als het bitrot is doet de firmware van de disk dat gewoon zelf en merk je er helemaal niets van.
Dat het bitrot verhaal is gewoon onzin bij de huidige disken.

Een harddisk kan geen bitrot herstellen (tenminste, niet meer als dat op het punt is dat de controller of het filesystem zich er mee gaat bemoeien). Klassiek raid gaat er bij fouten altijd van uit dat de data-disks gelijk hebben (bij raid-1 de eerste disk), en schrijft naar de overige en parity-disks vervolgens gewoon weg wat er dan uit komt, ongeacht of dat eigenlijk correct is. Dit zijn gewoon problemen die algemeen bekend zijn, en onder andere de reden waarom ZFS gemaakt is.

[gastje01]

Wat ik nog mis in dit topic in het advies voor de schijven is het kopje energieverbruik. Ik heb zelf een 1817+ met 8 schijven en een ssd cache, en die lust zo’n 100-110W continue. Als je 24/7 wil draaien is het wellicht op de (met de huidige energieprijzen niet zo’n heel) lange termijn om minder, maar grote zuinige disken te nemen. Mijn NAS staat om deze reden voornamelijk uit en start ik met WOL als ik m nodig heb.

Verder het stukje Kodi, je kan relatief eenvoudig een docker containertje draaien met een database voor Kodi, zo blijven je spelers netjes in sync met alles wat je al bekeken hebt.

[biomass]

Neobahamuth schreef op zondag 8 januari 2023 @ 11:21:
[...]
SHR2/RAID6 heb ik overwogen, maar heb geen zin om n-2 schijven in te boeten. Dus liever niet.
Zoals in mijn OP geschreven, vrees ik bij een restore van een array op nog meer uitval van schijven.
Als er bij SHR2/RAID6 2 schijven falen en de restore molt er eentje door de zeer intensieve restore operatie, dan ben ik alsnog de sjaak.

Ik denk dat je hier even voorbij gaat aan de aanname dat je elke schijf zo goed als direct vervangt als hij kapot is. Wachten met wisselen tot je twee kapotte schijven hebt is met RAID-6/SHR-2 net zo 'handig' als 1 kapotte schijf wisselen met RAID5/SHR..

@Neobahamuth Als je wil gaan voor minder gedoe zou je ik toch sterk aanraden een SHR-2 opstelling te kiezen. Dan heb je tenminste nog bescherming als je array aan het rebuilden bent voor het falen van 1 disk. Het leuke van al die nieuwe grote disks is dat de technologie nog relatief nieuw is en dat je niet verbaasd mag zijn dat er een aantal falen. En als ze dat vlak na elkaar doen, ben je met RAID-5 of SHR gewoon ook de sjaak. Lees ook eens https://www.zdnet.com/art...-6-stops-working-in-2019/

Ik heb zelf gekozen voor 2 SHR-2 sets van elk vijf schijven, in een 5 bay NAS + expansie unit. 40% van mijn capaciteit is dus parity data. Als je in een 8-bay NAS met een 6 disk SHR-2 opstelling begint heb je 33% parity data, en als je die gaat vergroten naar 8 schijven zakt dat getal naar 25%. Voor het rebuilden van je array van 8 schijven moeten er dan dus 7 andere schijven flink aan het werk. Dat vergroten van de capaciteit door het toevoegen van twee disks gaat dan trouwens lang duren (meerdere dagen) en zet al je schijven onder flinke stress.

Misschien is het slimmer om voor een 5- of 6-bay NAS + expansie unit te gaan? Ik bedoel, je kunt in een 8-bay NAS een 8 disk SHR-2 volume maken omdat het kan, maar je kunt er ook 2 SHR-2 volumes van 4 disks in hangen. De beschikbare capaciteit en beschikbaarheid van je data zijn dan wel totaal anders bij het uitvallen van twee willekeurige disks.

[ Voor 19% gewijzigd door biomass op 08-01-2023 21:44 ]

[Ben(V)]

dcm360 schreef op zondag 8 januari 2023 @ 17:57:
[...]

Een harddisk kan geen bitrot herstellen (tenminste, niet meer als dat op het punt is dat de controller of het filesystem zich er mee gaat bemoeien). Klassiek raid gaat er bij fouten altijd van uit dat de data-disks gelijk hebben (bij raid-1 de eerste disk), en schrijft naar de overige en parity-disks vervolgens gewoon weg wat er dan uit komt, ongeacht of dat eigenlijk correct is. Dit zijn gewoon problemen die algemeen bekend zijn, en onder andere de reden waarom ZFS gemaakt is.

Je hebt blijkbaar geen idee wat een Raid 5 systeem is.
Een Raid 5 verdeelt de data plus checksum per blok over alle disken en op het moment er iets mis is met een van de disken kan met de data plus de checksum de totale data weer gereconstrueerd worden.

En wat bitrot betreft stel ik dat het normaal gesproken nooit op het filesystem aankomt omdat de disk dat zelf wel oplost en als hij dat niet meer kan kun je niet meer van bitrot spreken maar is die disk gewoon end of life en moet vervangen worden, wat bij een raidsyteem probleemloos kan.

[dcm360]

Ben(V) schreef op zondag 8 januari 2023 @ 18:59:
[...]


Je hebt blijkbaar geen idee wat een Raid 5 systeem is.
Een Raid 5 verdeelt de data plus checksum per blok over alle disken en op het moment er iets mis is met een van de disken kan met de data plus de checksum de totale data weer gereconstrueerd worden.

Raid 5 doet helemaal niets met checksums, zie Wikipedia over een uitleg hoe het wel werkt. Raid 5 heeft geen manier om vast te stellen of de parity (niet verwarren met een checksum) of de data gelijk heeft. Wil je wel checksums hebben (en vast kunnen stellen welke disks correcte data teruggeven), moet je kijken naar oplossingen als ZFS of BTRFS.

[Ben(V)]

Je begrijpt er echt niets van en een checksum en parity is in dit geval gewoon hetzelfde.
En de raid software (in geval van Synology mdadm) kan gewoon als een disk aangeeft corrupt te zijn de ders recoveren.
Om dat te detecteren moet de data wel gelezen worden, vandaar de noodzaak regelmatig te scrubben.
En zfs kan dat echt niet anders, maar wel kan dat ook zonder een raidset, dat is het enige verschil.
Al kan zonder raidset dat dan enkel als er al een copy beschikbaar is, het is tenslotte een Copy On Write filesystem.

[laurens0619]

Raid zou ik alleen overwegen voor hoge beschikbaarheid.

Als de data belangrijk is, dan zou ik sowieso zorgen dat de data offsite gebackuped wordt. Naar de cloud of een 2e synology ergens.

Als je dat al hebt en er gaat een schijf stuk, schijf vervangen en kopieren van de backup nas

[leonbong]

Ben(V) schreef op zondag 8 januari 2023 @ 13:06:
Onzin.
Zfs en Btrfs doen dat helemaal niets beter dan andere file systemen.

Bitrot detection wordt veel effectiever door de firmware van de disken zelf gedaan.
Elke moderne disk slaat tegenwoordig bij elk datablok een crc op en kan daarmee detecteren of die corrupt geraakt is en zal dit melden indien het niet in staat is dit zelf te recoveren en die sector te vervangen door een van z'n reserve sectoren.
Om hier wat mee te kunnen moet je uiteraard wel een vorm van raid redundancy hebben en uiteraard moet zo'n datablok gelezen worden, vandaar het belang van regelmatig scrubben van de raidsets.

Als sector defect gaat op een schijf kan met een beetje mazzel de schijf dat zelf herstellen.
Soms kan de schijf dat niet herstellen en dan heb je feitelijk incorrecte data. Zfs kan die situaties detecteren en fixen.
Waarbij mdam dat niet kan.

Echter er zijn situaties dat de schijf niet merkt dat data incorrect is, echter een systeem als zfs kan dat op OS nog herstellen waarbij bepaalde fouten niet door mdam worden opgemerkt.

[peter-rm]

laurens0619 schreef op zondag 8 januari 2023 @ 21:24:
Raid zou ik alleen overwegen voor hoge beschikbaarheid.

Als de data belangrijk is, dan zou ik sowieso zorgen dat de data offsite gebackuped wordt. Naar de cloud of een 2e synology ergens.

Als je dat al hebt en er gaat een schijf stuk, schijf vervangen en kopieren van de backup nas

als je de tijd hebt om enkele dagen zonder data te werken kan dat heel goed.

de back-up restoren van een grote disk (10T) kost met een gbit netwerk 30 uur in het optimale geval (geen packetloss, geen ander netwerkverkeer), in de praktijk waarschijnlijk 2-3 dagen.

ik wil die ellende in ieder geval niet
met een raid5 kun je tijdens het herstel de data gewoon gebruiken (read/write)

[laurens0619]

@peter-rm
Of je haalt even de disk op/ je gaat tijdje doordraaien op die backup nas terwijl de data terug wordt gesync

Maar ik snap je argument. Mijn punt is meer dat ik veel over raid hier lees maar geen backup.
Die offsite backup moet je sowieso hebben als je niet (1 dag) zonder je data kan. Anno 2023 durf ik echt niet alleen nog te leunen op raid zonder offsite data.
En als die offsite er is, heb je raid dan nog nodig? Soms wel, niet altijd

[ Voor 34% gewijzigd door laurens0619 op 08-01-2023 22:33 ]

[peter-rm]

@laurens0619 hangt ook sterk af hoe frequent er een back-up gemaakt wordt, en hoeveel (actuele) data er verloren mag gaan

dit zijn keuzes in Recovery Point Objective(RPO), hoeveel werk mag er verloren gaan, en Recovery Time Objective (RTO), hoelang kan ik zonder data.

Voor beide criteria zijn er verschillende oplossings alternatieven, met uiteraar ook verschillende kostenplaatjes

[ Voor 6% gewijzigd door peter-rm op 08-01-2023 22:42 ]

[laurens0619]

@peter-rm
Ja hoor helemaal eens mbt rto/rpo maar dat zijn termen die niets te maken hebben met raid, raid is geen backup.

Er zijn genoeg use cases waar de uptime belangrijk is en de data minder, bv een webserver. Dan wil je 100% raid en boeit een backup minder.
Alleen de TS kan het beantwoorden maar bij een nas vol media voor Kodi denk ik eerder aan een periodieke backup dan hoge uptime. Of zelfs helemaal niet als het louter “downloads” zijn

[ Voor 61% gewijzigd door laurens0619 op 08-01-2023 23:04 ]

[Neobahamuth]

Ter info:
Mijn "bedrijfskritische data" staat veilig op een professionele cloud-dienst.
Hier komt niets van op deze NAS.

Ik heb geen back-up van deze 50TB. Raid rebuild mislukt? --> Pech, alles weg.
(Ik heb niet de interesse, noch de financiële inspiratie om een 2de NAS met 50TB als backup te draaien.)

Ik heb dankzij jullie nu een veel duidelijker beeld van wat mogelijk is en waar ik op moet letten, waarvoor dank.

Nog 2 zaken waar ik niet 100% zeker van ben:

- Indien ik slecht 6 of 7 disks van de NAS vul en pas nadien een HD bij plaats, moet de SHR1-array volledig opnieuw gemaakt worden of wordt die gewoon mee geabsorbeerd in de pool en kan ik zonder problemen gewoon verder werken?

- Vergelijkbaar met bovenste vraag: als ik een expansion unit achteraf zou koppelen, dan is dat volgens één van de video's enkel JBOD? Klopt dat?

Sowieso al bedankt aan iedereen om te reageren. Het is een interessante discussie geworden en ik heb al een pak bijgeleerd.

[gastje01]

Neobahamuth schreef op maandag 9 januari 2023 @ 06:23:
- Indien ik slecht 6 of 7 disks van de NAS vul en pas nadien een HD bij plaats, moet de SHR1-array volledig opnieuw gemaakt worden of wordt die gewoon mee geabsorbeerd in de pool en kan ik zonder problemen gewoon verder werken?

Ja, zolang de schijf groter of even groot is als de grootste schijf die je geplaatst hebt. Eerst de schijf opnemen in je volume en dan je volume uitbreiden. Veel meer dan wachten hoef je niet zelf te doen. Vandaar ook mijn suggestie om, in verband met energieverbruik en uitbreidingsmogelijkheden, te beginnen zo groot mogelijke schijven, maar dan minder.

- Vergelijkbaar met bovenste vraag: als ik een expansion unit achteraf zou koppelen, dan is dat volgens één van de video's enkel JBOD? Klopt dat?

Hoe dit achteraf werkt durf ik niet met 100% zekerheid te zeggen, maar ik heb in een andere omgeving een RS815+ met een expansion unit draaien, en alle 8 de schijven zitten in 1 SHR, lijkt me sterk als dat dan hier niet kan.

[Tortelli]

Ik heb zelf al een jaar een DS1821+ draaien. Veel is al gezegd maar enkele tips:
Draai zelf met 8x10TB in SHR2 ivm mogelijke issues tijdens rebuild. Dit kost natuurlijk 2 hdd’s maar het risico is mij te groot af. In de tijd dat ik deze array opbouwde had ik nog een DS1815+ en was dit de beste optie (prijs per GB) . Prijs per GB zakt helaas niet hard meer de laatste jaren. Koop zo groot mogelijke hdd’s. Scheelt verbruik en je hebt uitbreidmogelijkheden in de toekomst.

Voor performance: 10Gbit is wel leuk met deze NAS!
Je kunt er 2x 32GB ram in drukken mocht je veel willen virtualiseren. Ga je de 10Gbit route is meer ram wel nodig om goede snelheden te halen. Ik heb 2x500GB ssd’s voor caching erin zitten.

Je kunt qua virtualisatie leuke dingen met deze NAS. De CPU is best vlot (en veel sneller dan in de oude modellen met een Intel C2538). Qua filesystem zou ik nu de BTFRS route gaan (dan kun je ook echt virtuele machine draaien, iets wat je met EXT4 niet kunt helaas).

gastje01 schreef op maandag 9 januari 2023 @ 08:54:
[...]

Ja, zolang de schijf groter of even groot is als de grootste schijf die je geplaatst hebt. Eerst de schijf opnemen in je volume en dan je volume uitbreiden. Veel meer dan wachten hoef je niet zelf te doen. Vandaar ook mijn suggestie om, in verband met energieverbruik en uitbreidingsmogelijkheden, te beginnen zo groot mogelijke schijven, maar dan minder.

[...]

Hoe dit achteraf werkt durf ik niet met 100% zekerheid te zeggen, maar ik heb in een andere omgeving een RS815+ met een expansion unit draaien, en alle 8 de schijven zitten in 1 SHR, lijkt me sterk als dat dan hier niet kan.

Ik loop wel eens met het idee de uitbreiding te kopen, maar hij is helaas erg duur. Zou er een paar SSD's in willen drukken om wat zaken te virtualiseren. Nu kan ik dit niet ivm EXT4 filesystem.

Is de xSATA verbinding geen beperking qua performance overigens?
De oude modellen van Synology hadden ook zo'n raar geintje: de HDD 7 en 8 op een DS1815+ liepen via SATA1 = max 150MB/s .

[ Voor 35% gewijzigd door Tortelli op 09-01-2023 15:30 ]

[gastje01]

Tortelli schreef op maandag 9 januari 2023 @ 15:28:
Ik loop wel eens met het idee de uitbreiding te kopen, maar hij is helaas erg duur. Zou er een paar SSD's in willen drukken om wat zaken te virtualiseren. Nu kan ik dit niet ivm EXT4 filesystem.

Is de xSATA verbinding geen beperking qua performance overigens?
De oude modellen van Synology hadden ook zo'n raar geintje: de HDD 7 en 8 op een DS1815+ liepen via SATA1 = max 150MB/s .

We gaan wel heel erg off-topic nu, maar dat is (in mijn situatie) geen beperking, dat is de 1gbps netwerkverbinding. Bij de 1817+ draaien alle interne schijven gewoon op SATA3. Zolang ik niet aan 10 gpbs ga beginnen thuis ga ik nooit tegen die bottleneck aanlopen. Het komt niet heel vaak voor dat ik meer dan 50 GB over moet zetten, dus de meerwaarde is voor mij ook zeer beperkt.

Of die snelheid voor de ts een factor is kan wellicht ook nog een verschil maken in config of extra uitbreidingen (ssd cache en/of 10gbps).

[Tortelli]

@gastje01 DS1817+ heeft het SATA probleem niet, is opgelost in dat model. Heeft verder wel dezelfde hardware als de 1815+.

Ik had toen de tijd een SSD in slot 8 zitten. Had (op IO na) niet heel veel zin. Interne copy / paste acties waren vooral relatief traag. Trager dan je met een normale HDD kunt halen zelfs.

[ Voor 43% gewijzigd door Tortelli op 09-01-2023 21:23 ]

[Neobahamuth]

UPDATE:

Zonet

• Synology DS1821+
• 5x Seagate 16TB Exos X16

besteld.

slik...

Updates van de installatie en configuratie volgen indien er interesse is.
(Doel: 5x16TB, SHR1 = 56TB netto. Nadien 1 of 2 16TB disks bij proppen.)

[sOid]

Neobahamuth schreef op dinsdag 10 januari 2023 @ 17:26:
UPDATE:

Zonet

• Synology DS1821+
• 5x Seagate 16TB Exos X16

besteld.

slik...

Updates van de installatie en configuratie volgen indien er interesse is.
(Doel: 5x16TB, SHR1 = 56TB netto. Nadien 1 of 2 16TB disks bij proppen.)

Ik zou wel aanraden er wat extra geheugen bij te prikken. 4GB is best wel weinig heb ik gemerkt.

Mooi ding verder, gefeliciteerd. En ik hoop dat je de rest van de maand geniet van je water met droog brood...

[tomic]

sOid schreef op dinsdag 10 januari 2023 @ 17:35:
[...]

Ik zou wel aanraden er wat extra geheugen bij te prikken. 4GB is best wel weinig heb ik gemerkt.

Mooi ding verder, gefeliciteerd. En ik hoop dat je de rest van de maand geniet van je water met droog brood...

Is er nog een specifiek DDR4 geheugen wat hiervoor gebruikt kan worden? Het gaat maar om 1 reepje toch?

[sOid]

tomic schreef op dinsdag 10 januari 2023 @ 17:40:
[...]


Is er nog een specifiek DDR4 geheugen wat hiervoor gebruikt kan worden? Het gaat maar om 1 reepje toch?

Het is een aantal jaar geleden dat ik dit heb moeten uitzoeken, maar voor mijn DS418Play werd wel nadrukkelijk het geheugen van Synology zelf aangeraden. Tegen een premium, natuurlijk...

Er waren wat horrorverhalen over gedoe met incompatibel standaardgeheugen. Daardoor toch maar het geheugen van Synology gekocht; betrouwbaarheid van een NAS vind ik het belangrijkst.

Check dus vooral de compatibility list.

[ Voor 8% gewijzigd door sOid op 10-01-2023 17:47 ]

[Dennism]

sOid schreef op dinsdag 10 januari 2023 @ 17:35:
[...]

Ik zou wel aanraden er wat extra geheugen bij te prikken. 4GB is best wel weinig heb ik gemerkt.

Mooi ding verder, gefeliciteerd. En ik hoop dat je de rest van de maand geniet van je water met droog brood...

Afhankelijk wat je gaat doen kan dit inderdaad flink schelen, als TS allerlei apps gaat gebruiken in containers bijvoorbeeld, zeker wat bij bijsteken, als ie echter enkel SMB shares gaat doen is 4GB in principe prima.

Let er ook op dat je niet zomaar ieder type geheugen kan bijsteken, deze nas gebruikt ECC.

[Dennism]

tomic schreef op dinsdag 10 januari 2023 @ 17:40:
[...]


Is er nog een specifiek DDR4 geheugen wat hiervoor gebruikt kan worden? Het gaat maar om 1 reepje toch?

Is afhankelijk van de NAS, sommige synology modellen slikken enkel Non-ECC geheugen, en dan moet je dat uiteraard ook hebben.

Meer recente modellen, zoals deze ondersteunen vaak ook ECC Ram (en het bijgeleverde ram is vaak standaard ook ECC), waardoor je eigenlijk liever ECC wil plaatsen (en doe je dit niet, kan je het meegeleverde geheugen niet meer gebruiken en moet je dat dus ook vervangen.

[Nielson]

Voor eventuele geheugenuitbreiding is dit wel een interessant topic:

[Synology] Geheugen upgrade ervaringen per model

[Neobahamuth]

Ik had inderdaad al gekeken naar de uitbreidingsmogelijkheden van die 1821+:

• geheugen uit te breiden (met inderdaad best eigen Synology ECC)
• 2x NVME SSD voor cache

Beide opties lijken voor mij voorlopig overkill.
Het gaat mij inderdaad puur om SMB/NFS. Verder ga ik (buiten zo veel mogelijk disk monitoring opties) niet veel draaien op die bak.

[Rolfie]

Ben(V) schreef op zondag 8 januari 2023 @ 17:28:
[...]


Ook weer onzin.
Als je een hogere raid dan raid 1 hebt wordt gewoon de boel netjes herstelt , een hogere raid kan de boel herstellen als een van de disken corrupt is, alleen een raid 1 kan dat niet.
En zoals ik al zei, als het bitrot is doet de firmware van de disk dat gewoon zelf en merk je er helemaal niets van.
Dat het bitrot verhaal is gewoon onzin bij de huidige disken.

En ja als je behoefte aan snapshot hebt dan hebt je zfs of btrfs nodig, maar dan zie ik verder geen verschil tussen die twee.

Ik zou je dan toch willen adviseren om je eens hierin meer te verdiepen. Bitrot komt nog steeds voor, zeker icm grote schijven is dit gewoon nog steeds een risico. Hoe groter de disk en hie meer disks, hoe groter het risico. Ik draai daarom nog steeds het liefst zfs of anders btrfs, wat ook op mijn synologie nas actief is.

Ik ben benieuwd hoe de firmware dit kan detecteren, heb je hiervan een linkje voor mij? Kan ik wat bij leren.

Ik zou trouwens altijd gaan voor btrfs op een nas als die dit ondersteund, voor sommige packages noodzakelijk en het file systeem heeft gewoon veel voordelen.

[ Voor 7% gewijzigd door Rolfie op 11-01-2023 09:32 ]

[Ben(V)]

Ik heb het al een keer voor je uitgelegd hoe een disk Bitrot detecteert, maar jij ziet blijkbaar alleen wat je wilt zien.
Dus nog maar een keer.

De firmware van de huidige disken schrijft per sector ook een checksum op de disk.
Als dan die sector gelezen wordt en de de data klopt niet meer met de checksum dan zal de disk dat een paar maal proberen, krijgt hij alsnog de data correct dan zal hij de sector re-alloceren, lukt dat niet dan meld hij dat als een error aan het OS als een unrecoverable error.
De statistieken daarvan kun je als s.m.a.r.t. data lezen.

Daarom is scrubben belangrijk, want dan wordt de hele disk gelezen en als de raidsoftware dan zo'n error van de disk krijgt kan hij dat recoveren met behulp van de data die op de andere disken staat.

Btrfs en ook Zfs doen precies hetzelfde alleen buiten de firmware van de disk om en dus gewoon dubbel.

[ Voor 5% gewijzigd door Ben(V) op 11-01-2023 13:28 ]

[Q]

Rolfie schreef op woensdag 11 januari 2023 @ 09:28:
[...]

Ik zou je dan toch willen adviseren om je eens hierin meer te verdiepen. Bitrot komt nog steeds voor, zeker icm grote schijven is dit gewoon nog steeds een risico. Hoe groter de disk en hie meer disks, hoe groter het risico. Ik draai daarom nog steeds het liefst zfs of anders btrfs, wat ook op mijn synologie nas actief is.

Ik ben benieuwd hoe de firmware dit kan detecteren, heb je hiervan een linkje voor mij? Kan ik wat bij leren.

Ik zou trouwens altijd gaan voor btrfs op een nas als die dit ondersteund, voor sommige packages noodzakelijk en het file systeem heeft gewoon veel voordelen.

Bit rot op schijven is een extreem klein risico. Zoals BenV uitlegt doet een schijf aan checksums enzo. Het risico is waanzinnig klein en met name statistisch relevant voor datacenters, niet voor consumenten.

De ZFS crowd hamert zo op silent data corruptie want ZFS kan er tegen bescherm. Maar de gewone consument hoeft zich daar echt niet zo druk over te maken.

Zorg dat je NAS 1x per maand of zo een scrub doet om bad sectors vroegtijdig op te sporen en alles is prima.

[ Voor 4% gewijzigd door Q op 11-01-2023 13:23 ]

[Neobahamuth]

De disks zijn al binnen.



(Die 8TB disk heb ik alsnog retour gestuurd.)

[HyperBart]

Q schreef op woensdag 11 januari 2023 @ 13:22:
[...]


Bit rot op schijven is een extreem klein risico. Zoals BenV uitlegt doet een schijf aan checksums enzo. Het risico is waanzinnig klein en met name statistisch relevant voor datacenters, niet voor consumenten.

De ZFS crowd hamert zo op silent data corruptie want ZFS kan er tegen bescherm. Maar de gewone consument hoeft zich daar echt niet zo druk over te maken.

Zorg dat je NAS 1x per maand of zo een scrub doet om bad sectors vroegtijdig op te sporen en alles is prima.

Ha die Q, neen inderdaad, disks doen het op zich prima maar jij en ik weten ook dat er meer als genoeg mis kan gaan voor data op die disks komt. Controllers, PSU, memory. En zonder die functies weet 99pct het gewoonweg niet.

En @Ben(V) : neen checksums en parity is niet hetzelfde. Door de discussie alleen op disks te voeren sus je NAS bouwers te in slaap met foute verhaaltjes.

@Neobahamuth : grote wuif van een oude bezoeker

[Ben(V)]

Mijn verhaal is niet fout en een parity is een vorm van checksum in dit geval.
En alleen maar roepen dat iets fout is zonder argumenten lijkt me helemaal niets bijdragen.

Maar misschien moet je gewoon beter lezen, ik zeg dat bitrot door de disk gedetecteerd wordt bij het lezen van de data en als je dat combineert met een raidset 5 (of hoger) samen met regelmatig scrubben ben je helemaal niks slechter af dan met zfs.
En btrfs al helemaal niet want de btrfs raid wordt en kan niet gebruikt worden dus zit je daar toch weer vast aan mdadm voor raid.
En ook btrfs heeft helemaal niets aan zijn checksum als er geen raidset is om te recoveren.

[Q]

HyperBart schreef op donderdag 12 januari 2023 @ 19:34:
[...]


Ha die Q, neen inderdaad, disks doen het op zich prima maar jij en ik weten ook dat er meer als genoeg mis kan gaan voor data op die disks komt. Controllers, PSU, memory. En zonder die functies weet 99pct het gewoonweg niet.

En @Ben(V) : neen checksums en parity is niet hetzelfde. Door de discussie alleen op disks te voeren sus je NAS bouwers te in slaap met foute verhaaltjes.

Voor veel van die andere oorzaken zoals Controllers, PSU, memory, daarom draai je als je werkelijk om dit soort onderwerpen geeft en werkelijk dit spelletje wilt spelen (data integriteit is super belangrijk) dan draai je met ECC. Controllers en PSUs, dat scenario zie ik niet realistisch gezien.

Ik heb wel eens gezocht op succesverhalen van ZFS waarbij silent data corruptie werd vastgesteld. In al deze voorbeelden was er spraken van hobbyisten die liepen te knoeien / fouten aan het maken waren en het had niets te maken met ZFS.

Zelf heeft ZFS mij na tientallen scrubs over 10+ jaar en petabyte+ aan data transfers nog nooit gered, nog nooit iets gevonden.

Storage is extreem betrouwbaar, mad respect. Silent data corruptie blijft iets wat vooral een statistisch ding is waar je mee rekening wilt houden als je racks vol schijven hebt.

Ik blijf bij mijn punt: consumenten hoeven zich niet druk te maken over silent data corruptie. De kans dat ze dit tegen komen is onwijs klein. Dus een Synology of QNAP is ook prima spul voor hen. Of iets zelfbouw met Unraid of vergelijkbare oplossingen.

Laat consumenten zich maar druk maken over backups en redundancy. Ik durf te wedden dat zoveel mensen een NAS draaien en dan de backups niet goed geregeld hebben, een 100x groter risico dan silent data corruptie.

Als iemand toch graag ZFS wil toepassen prima natuurlijk, moeten mensen zelf weten. Maar het moet allemaal een beetje in perspectief geplaatst worden.

[ Voor 4% gewijzigd door Q op 12-01-2023 20:14 ]

[Tortelli]

Neobahamuth schreef op woensdag 11 januari 2023 @ 06:32:
Ik had inderdaad al gekeken naar de uitbreidingsmogelijkheden van die 1821+:

• geheugen uit te breiden (met inderdaad best eigen Synology ECC)
• 2x NVME SSD voor cache

Beide opties lijken voor mij voorlopig overkill.
Het gaat mij inderdaad puur om SMB/NFS. Verder ga ik (buiten zo veel mogelijk disk monitoring opties) niet veel draaien op die bak.

Ik merkte een behoorlijke performance upgrade op 10Gbit snelheden toen ik van 4GB naar 36GB (4+32) geheugen ging.

[Neobahamuth]

Ik ga het gewoon simpel houden met SHR1 en BTRFS.

Ik merk nu pas dat er ook USB 3 poorten achteraan die Synology zitten.
Kan je dan bv via een aangesloten HD- dock data kopiëren naar de NAS?
Iemand die dit kan bevestigen?
Dat lijkt mij namelijk sneller dan over het netwerk te moeten pompen.
(Slechts gigabit.)

[Ben(V)]

Ja dat kan, maar reken niet op heel veel hogere snelheden.
Theoretisch kan USB 3.0 een snellheid van 5 Gbps halen, maar in de praktijk valt het vaak tegen, maar wel meestal meer dan via het 1 Gbps netwerk.

[Neobahamuth]

Schijven steken er in.
SHR1 is aan het builden. Nog 18u en 5min tot hij klaar is.

[leonbong]

Q schreef op donderdag 12 januari 2023 @ 20:12:
[...]


Voor veel van die andere oorzaken zoals Controllers, PSU, memory, daarom draai je als je werkelijk om dit soort onderwerpen geeft en werkelijk dit spelletje wilt spelen (data integriteit is super belangrijk) dan draai je met ECC. Controllers en PSUs, dat scenario zie ik niet realistisch gezien.

Ik heb wel eens gezocht op succesverhalen van ZFS waarbij silent data corruptie werd vastgesteld. In al deze voorbeelden was er spraken van hobbyisten die liepen te knoeien / fouten aan het maken waren en het had niets te maken met ZFS.

Zelf heeft ZFS mij na tientallen scrubs over 10+ jaar en petabyte+ aan data transfers nog nooit gered, nog nooit iets gevonden.

Storage is extreem betrouwbaar, mad respect. Silent data corruptie blijft iets wat vooral een statistisch ding is waar je mee rekening wilt houden als je racks vol schijven hebt.

Ik blijf bij mijn punt: consumenten hoeven zich niet druk te maken over silent data corruptie. De kans dat ze dit tegen komen is onwijs klein. Dus een Synology of QNAP is ook prima spul voor hen. Of iets zelfbouw met Unraid of vergelijkbare oplossingen.

Laat consumenten zich maar druk maken over backups en redundancy. Ik durf te wedden dat zoveel mensen een NAS draaien en dan de backups niet goed geregeld hebben, een 100x groter risico dan silent data corruptie.

Als iemand toch graag ZFS wil toepassen prima natuurlijk, moeten mensen zelf weten. Maar het moet allemaal een beetje in perspectief geplaatst worden.

Klopt echter voor hetzelfde geld als deze synology koop je een qnap model dat zfs kan.

[NaN]

Neobahamuth schreef op vrijdag 13 januari 2023 @ 18:21:
[Afbeelding]

[Afbeelding]

Schijven steken er in.
SHR1 is aan het builden. Nog 18u en 5min tot hij klaar is.

Geniet ervan, Synology is top spul!

[Reinier]

Neobahamuth schreef op vrijdag 13 januari 2023 @ 18:21:
[Afbeelding]

[Afbeelding]

Schijven steken er in.
SHR1 is aan het builden. Nog 18u en 5min tot hij klaar is.

Mooi spul! Bizar dat je zo veel opslag nodig hebt. Maar da's niet relevant verder. Nu even geduld hebben

Ben(V) schreef op vrijdag 13 januari 2023 @ 14:17:
Theoretisch kan USB 3.0 een snellheid van 5 Mbps halen,

5 Gbit/s

[Neobahamuth]

Ondertussen de NAS goed geconfigureerd.
(I DSM trouwens!)

Ben nog alle data aan het overpompen.(20% gedaan.)

Nog enkele vraagjes:

1. Ik kan booten/shutdowns in een schema gieten.
Dus bv shutdown wanneer ik op bureau zit en booten tegen dat ik weer thuis ben.

--> Wat is het beste voor de levensduur en stabiliteit van de hardware en data?
Gewoon 24/24 laten draaien of telkens booten/shutdown iedere dag?*
(*) Geen rekening houdend met de energieprijzen.


2. Ik krijg die gecentraliseerde dbase voor Kodi niet aan de praat.
Heb de instructies in deze video gevolgd.
Ik heb een iets afwijkende mappenstructuur, maar het lukt niet. (MariaDB10 + phpMyAdmin)

Ik vond na wat onderzoek op Reddit een andere optie:
- Embyserver op de NAS
- EmbyforKodi plugin op Kodi speler

Voor ik deze Emby probeer, wil ik graag weten of dat wel de beste van de twee opties is en of dat niet te veel resources gaat gebruiken op de Synology. Iemand ervaring met deze opstelling?

(Ik wil gerust een apart topic openen voor vraag 2.)

[Ben(V)]

Voor de levensduur van je hardware maakt het niet uit of je hem aanlaat of uitzet.
Wel voor je stroomverbruik.

[GarBaGe]

Neobahamuth schreef op woensdag 11 januari 2023 @ 06:32:
Ik had inderdaad al gekeken naar de uitbreidingsmogelijkheden van die 1821+:

• geheugen uit te breiden (met inderdaad best eigen Synology ECC)
• 2x NVME SSD voor cache

Beide opties lijken voor mij voorlopig overkill.

Ik heb 2x NVME SSD caching drives in mijn DS1621+.
Ik ben een beetje teleurgesteld in wat het betekent,
Ik dacht dat writes naar de NAS (via netwerk) zouden worden gecachet en daarmee sneller.
En eventueel veel gelezen bestanden ook gecachet zouden worden.
Helaas wordt alleen de metadata van ALLE bestanden op de NVME cache geplaatst.
Ik vind de performancewinst die daarmee wordt gehaald bijna verwaarloosbaar.

[M2M]

GarBaGe schreef op maandag 16 januari 2023 @ 14:12:
[...]

Ik heb 2x NVME SSD caching drives in mijn DS1621+.
Ik ben een beetje teleurgesteld in wat het betekent,
Ik dacht dat writes naar de NAS (via netwerk) zouden worden gecachet en daarmee sneller.
En eventueel veel gelezen bestanden ook gecachet zouden worden.
Helaas wordt alleen de metadata van ALLE bestanden op de NVME cache geplaatst.
Ik vind de performancewinst die daarmee wordt gehaald bijna verwaarloosbaar.

weet je het zeker? De syno hier zegt dat de cache vol zit (240GB). Lijkt mij sterk dat dat enkel metadata is...

[GarBaGe]

M2M schreef op maandag 16 januari 2023 @ 14:18:
[...]


weet je het zeker? De syno hier zegt dat de cache vol zit (240GB). Lijkt mij sterk dat dat enkel metadata is...

Nee.
Ik heb 2x 500GB SSDs en daarmee netto 500GB lees-schrijf cache. Er is nu 31GB in gebruik en 470GB ongebruikt.
Als ik over mijn 10G netwerk spullen kopieer, moet ik gewoon wachten tot de klassieke HDDs hun werk hebben gedaan. Snelheid komt nooit over de 2.0-2.5 Gbit heen.
Ik heb nu 2x16TB schijven, dus ongeveer 250MB/sec snelheid

[M2M]

De meeste info die ik kon vinden spreken over het cachen van kleine files en bijbehorende metadata, wellicht dat dat de reden is dat hier de cache wel vol zit en bij jouw niet?