madmin

Members
  • Posts

    57
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

madmin's Achievements

Rookie

Rookie (2/14)

7

Reputation

1

Community Answers

  1. @Joczek Not me. I have not tried to update the BIOS yet. I have very little time, my progress is really slow, and I have not yet gotten to the point of optimization. No, if you are not referring to optimization. I had to change one BIOS option for it to auto-boot without hitting enter on a keyboard. Other than that, it worked out of the box. But again, this is not advanced requirements level. I am still learning, it's been literally decades that I built mini tower PCs before, I always used notebooks ever since. From what I read at Amazon, the BIOS update archive is broken because of a wrong flash tool (which can be exchanged, appearently fpt.efi is wrong and fph.efi is right, but it is not clear where to get the fph.efi from the review). I will have to look at that myself, at some point. Sorry if that is not much help.
  2. Alles gut 🙂 Ich habe Unraid tatsächlich auch nicht gekauft, um der CLI vorgaukeln zu müssen, hier säße ein voller Linux-Admin. Aber an dieser Stelle muss die webGUI wohl noch etwas reifen (oder ich hätte halt das Skript von Spaceinvador One anwerden sollen...). Da ich gerade einsteige und 6.13 in den Startlöchern steht, wollte ich allerdings die Weichen richtig stellen, bevor ich dann wieder das ganze FS umstellen muss, und gleich ein stimmiges Konzept mit Snapshots usw. aufziehen. Aber stimmt, wer Teilimplementierungen nutzt, muss halt auch mit etwas ruckeligem Fahrwerk rechnen... 🤷‍♂️
  3. Solution: It works, even with chmod -R 775 - I realized that "users" is the GID and tried that. So Unraid does support user groups (sorry for the misinterpretation - The post I had that from was in 2018...). I do not know why shares are 777, and why newly created sub-datasets do not inherit the permissions of the share. But that seems to be how Unraid does things.
  4. @hawihoney Es tut mir leid, falls Du irgendwo rausgelesen hast, dass ich Dir ein single ZFS im Array aufschwatzen wollte, oder dass ich Dich nötigen wollte, über Unbekanntes zu spekulieren. Das war auch mehr an Leute gerichtet, die an ZFS Interesse haben, das schon für das Array probiert haben (Es gibt dazu Posts), über das recht offensichtliche Problem gestolpert sind, und vielleicht schon eine Lösung gefunden haben. Die lautet übrigens: Unraid macht Alles ein bisschen anders... Als ich den Besitzer nobody gesehen habe, wurde es mir dann klar: root@NAS:~# ls -la /mnt/user/media total 12 drwxrwxrwx 1 nobody users 4 Mar 5 14:32 ./ drwxrwxrwx 1 nobody users 9 Mar 3 12:09 ../ drwxr-xr-x 1 nobody users 2 Mar 5 14:31 audio/ drwxr-xr-x 1 nobody users 2 Mar 5 14:32 video/ root@NAS:~# chmod -R 775 /mnt/user/media/* Offenbar macht Unraid Shares mit 777 🤔 und regelt dann den Zugriff anders - Die sub-Datasets erben das aber nicht... Chmod 777 geht mir auch irgendwie gegen den Strich, also chmod 755. Dann läuft auch Alles wie erwartet 🙂
  5. @wohlben Glad it helped someone 👍 Just to be clear: "It's not worth it" referred to the modding effort - not to the case itself. You know, it really depends on your use case: If you want an straightforward, efiicient, low-noise design, with little cost and effort for modding, there are clearly better options out there. But if you look for a design for an inexpensive miniITX-combo that actually fits into a shelf*, while allowing for many HDDs, including hotswap for e.g. for offsite backup disks, then I would not know of any alternative (not talking about a better alternative, I did not find anything, but tbh, I am new to all this). The small depth of the two-level design being really key here, at the cost that it leaves not enough height for an ATX PSU. And PSX seems to be an area where most manufacturers do not exactly excel. But as @jit-010101 pointed out correctly, that can be solved with alternative power supplies, depending on your use case: The picoPSU would limit the drive options; however, there are reports of more than 4 disk builds powering up in parallel with a 160 W picoPSU, if that suffices - Going over peak for a short time works, appearently. Still: It's a 8 HDD +2 SSD bay case, and I did not want to have an external extra coltage converter / cable power supply. I have not looked if the HDPlex gan would fit, and only browsed the efficiency report superficially. But they look really promising, and with the new 500 W unit out, you should have enough power to support enough HDDs to populate the case. The hardest bullet to bite is the 100 or 92 cm double fan design - again, a tribute to the short depth, two-level design - I wondered if you can fit an external larger fan, but then I looked at the power cable and the network ports of the MoBo right in the middle of the back plane and realized there is no way around the design as it is. I bought two Arctic double bearing 92 mm fans with a daisy chain connector, and a fan controller for a few bucks that could control the fan speed via temperature - but it does not work well, the disk temperature sometimes exceeds 45 °C, and the fans do not react (the sensor is not attached to one drive, so it measures compartment instead of disk temperature). But it has a trim resistor for one fan connector, so I will try to find a sufficient smaller permanent speed for the disks inside. Maybe Jonsbo comes up with an even better short depth design where the MoBo is on the bottom or side, and there is only a partial second level for the HDDs (to allow a larger diameter fan in the back). But then they would have to figure out where to place the PSU... While I see many compromises in the design, Jonsbo has really drawn out a lot of a mini-cube/max-function concept. There is really not much freedom of design left, with such a compact 8 hotswap bay NAS case...
  6. @JorgeB I used the ZFS Master plugin: Main > ZFS Master > Create Dataset. e.g. "disk1/media/audio" (I left all defaults). Share security level "secure" was set in the share > SMB menu, with Read/Write user access to my main user. I had already deleted the datasets and created folders, but I reverted that for research here: root@NAS:~# ls -la /mnt/user/media total 12 drwxrwxrwx 1 nobody users 4 Mar 5 14:32 ./ drwxrwxrwx 1 nobody users 9 Mar 3 12:09 ../ drwxr-xr-x 1 nobody users 2 Mar 5 14:31 audio/ drwxr-xr-x 1 nobody users 2 Mar 5 14:32 video/ Looking at the owner "nobody" and the permission pattern, I start to wonder how one should specify write access other than chmod 777, actually - as Unraid does not seem to use permission groups to assign to users. The share has chmod 777, so it actually might be that the sub-datasets probably need that, too, then... So Unraid seems to manage permissions with a different mechanism, obviously...?
  7. Is it possible to write to nested / sub-datasets in a ZFS array disk via SMB? I chose ZFS for it (next to the parity drive), and I created a share / dataset "/media" and, below, sub-datasets "audio", "video", etc. (instead of folders). But while I can create files from Windows Explorer in the main share-dataset /media, I cannot in the sub-datasets (like in "/media/audio"). SMB security for all datasets is "secure", with additional write-permissions to the unraid-user (which is registered in windows and validated for the main share-datasets). But even if I change SMB security to "private" (with permissions for the Unraid user), it does not work... When researching before posting, I found a thread about the ZFS plugin in 2022 stating to chmod 777 the complete dataset - But I am not sure if removal of all access control is the intended design, or just a work-around at an early stage. I am aware that ZFS is waiting for a lot function to be implemented yet, so I wonder if I am doing it wrong, or if I have to wait for 6.13. The ZFS tutorials by Spaceinvader One to his scripts show that he actually created sub-datasets /appdata for each app - which makes sense to keep the snapshots scope small. A work-around would be to create parallel shares for each type of media (which seems not appropriate, though), or to use folders below the share-dataset and have the snapshots for the whole share for now. Another approach would be to simulate an array with a pendrive and make a full RAIDz pool, but I'd rather keep the flexibility of the Unraid array. I am aware the some advanced features will not work in a non-RAIDz Unraid array - So chosing ZFS for a one-disk plus parity array might seem odd. But I am really keen on the compression and snapshot features that XFS does not offer, and that should work even on a single ZFS disk (as I understand it). So even if ZFS is yet to be fully implemented, it seems to have benefits and no drawbacks I could see over XFS (for a single disk). But I might be on a completely wrong path here because I am pretty new to Unraid and ZFS.
  8. OK - Danke für die Einschätzung und den Link (Vieles dort kann ich noch nicht einordnen, aber das kommt wohl schon noch). Was ich verstehe: XFS reicht aus (logisch, hat es ja auch bisher), die zweite Hälfte von ZFS kommt mit Unraid 12.7 (wann auch immer, und was auch immer die enthält), und für "high-level features" braucht man mehr als eine ZFS Platte im RAIDZ-Verbund, also eher im Pool als im Array (Was auch immer high level ist, bei der Selbstheilung verstehe ich es zumindest). Was mir noch unklar ist: Hat ZFS für eine Einzelplatte ohne RAIDZ Nachteilem oder läuft da das UNRAID Array auch mit ZFS wie gedacht? Hat ZFS Vorteile über "reicht" hinaus? So wie ich Snapshots und Kompression verstehe, müssten die ja schon mit einer einzelnen Platte funktionieren, auch wenn die keine RAIDZ-Schwester hat. Sind nested Datasets high-level, kommen sie erst in 12.7, oder müssten sie funktionieren (wie bei Spaceinvader One , und ich mache etwas kritisches falsch)? Verbaue ich mir was, wenn ich - im Vorausgriff auf 12.7 - die Array-Platten als einzelne ZFS-HDDs betreibe (dann eben nur mit Datasets auf der Share-Ebene)?
  9. TL;DNR: Nach stundenlanger Doc- und Forensuche bin ich offenbar unfähig, nested ZFS-Datasets / Sub-Datasets unterhalb eines Shares in Windows zu beschreiben - und wäre Euch über Hinweise dankbar, wie es geht oder welche Infos ich übersehen habe. Langfassung: Ich habe mich nach Serverbau nun erst einmal für folgendes Setup entschieden: Array: 16 TB HDD = Partiy 16 TB HDD = ZFS (solo, also kein RAID-Z) Cache Pool: 1x 1 TB M.2 = ZFS (erst einmal auch solo ohne RAID-Z), als Primary für Shares mit den User- und Familien-Daten Wie ich die 2x 8 TB HDD nutze, entscheide ich noch. User Shares für die disk1 anlegen geht problemlos (Das ist dann ja auch automatisch gleich ein ZFS Dataset, was auch als solches angezeigt wird). Ich kann auch problemlos von meinem hinterlegten Unraid-User von Windows 11 aus auf die Netzwerk-Shares zugreifen und Dateien und Ordner direkt schreiben/löschen. Was allerdings nicht klappt, ist das Schreiben auf nested (also Sub-)Datasets: U.a. für Jellyfin habe ich ein share "media" auf disk1 angelegt (SMB-Typ "sicher", mit Schreibrechten für meinen Unraid-User). Anstatt von Unterordnern habe ich aber unterhalb dieses shares gleich Datasets angelegt (z.B. fotos, audio, video, ebooks, usw.). Da kann ich über Windows Netzlaufwerk aber nichts drauf kopieren... 🤔 ("keine Berechtigung"). Auch wenn ich auf SMB-Typ "privat" ändere: gleiches Ergebnis. Der User hat dabei jeweils explizit Schreibrechte auf das share. Username = Windowsuser, anderes Passwort, aber offenbar erfolgreich in Windows Anmeldeinformationen hinterlegt (sonst würde er ja auf das Haupt-Share nicht schreiben). Die einzige Lösung, die mir einfällt, ist, für jeden Zweck ein eigenes Share / Haupt-Dataset anzulegen. Das finde ich aber reichlich unübersichtlich und un-rekursiv. Aber das kann ja nicht "by design" so gedacht sein... Wenn ich die Tutorials von Spaceinvader One zu ZFS richtig verstehe, wandelt der ja mit seinem "auto-convert folders" script selbst unterhalb /appdata jeden App-Ordner (also nested Ordner) in Datasets um, damit Snapshots weitgehend unabhängig voneinander gemanaged werden. Snapshots sind neben der Kompression für mich der wesentliche Vorteile von ZFS (neben Selbstheilung, aber ich wollte mir noch nicht mit einem RAID-Z die Array-Flexibiltität einschränken). Diese quasi-Time-Machine-Funktion finde ich super gegen UTS-Fehler (überschreiben, engültig löschen) und Ransomware (Ich weiß, ersetzt kein Backup - ergänzt es aber). Deshalb möchte ich gern die großen Datasets gleich richtig anlegen (nicht für umganreiche Daten als Ordner).
  10. Puh, in der Tat... Zunächst hatte ich die Platten an FAN1 und FAN2 gesteckt und den ersten Dip hochgesetzt (Basis-Geschwindigkeit von 20 % auf 40 % hochgesetzt). Dip 2 und 3 hatte ich OFF gelassen, weil das schon das schnell hochlaufende Profil ist. Dip 4 und 5 (Warnung FAN läuft nicht) hatte ich auf ON gestellt. Beim Formatieren ging T dann hoch auf 47 °C, und da gab es Überhitzungswarnungen. Bei > 15 h (16 TB bei 250 MB/sec) war mir das nichts, also habe ich abgebrochen und die Lüfter zum Formatieren erst einmal wieder direkt rangeklemmt (100 % = ständiges Föhn-Rauschen, aber Plattentemperatur geht unter Dauerlast nur auf 40 °C, und wir haben noch nicht Sommer - Klimatisierte Räume haben wir nicht...). Aber ich habe ein Video gefunden, das diese PWM Fan Control Boards gut beschreibt: Fazit: Der Trick ist, dass nur FAN1 über die Temperaturreglung geht (Obwohl der Warner für FAN1 und FAN2 ist...). FAN2 und FAN3 haben je ein Trimm-Poti, dass die Geschwindigkeit fest einstellt. Für eine Temperaturregelung müssen also beide Lüfter an FAN1. Ich bräuchte also ein Y-Kabel, aber die Arctic CO (Hatte ich wegen der Doppel-Kugellager genommen) haben ja einen DaisyChain-Anschluss dran (d.h ein Lüfter kann direkt an den anderen rangekabelt werden). Und dann schaue ich mal, ob ich den Temp-Sensor halbwegs in die Region der Festplattentemperatur bekomme (Der berührt ja die HDDs nicht, sondern hängt etwas daneben, und misst also eher den Raum als die Platte). Dann kann ich hoffentlich bedarfsorientiert bei ~ 35 °C auf Ramp Up Speed und bei ~ 45 °C auf 100 % hochlaufen lassen. Im Notfall muss ich beide Lüfter dann an FAN2 und FAN3 über TrimPoti bei < 100 % einstellen und hoffen, dass ich einen Kompromiss an Lautstärke und Kühlleistung bekomme, der auch im Sommer taugt. Puh, das ist aber auch Alles kompliziert im Detail... 😁
  11. Sorry, ist ein JMB 585 Zusatzcontroller. Hm... Also dann doch eventuell die Synology als Backup weiterbetreiben. Ich denke drüber nach! Danke - Ich habe hier richtig viel gelernt!
  12. Man kann natürlich nichts vorhersehen, aber Überspannungsschutz ist im Schaltkasten (grob) und an der Dose (fein) vorhanden, und zumindest die Synology fühlt sich an einer Eaton USV per USB-Steuerung wohl. Das kann Unraid wohl laut Menü auch Und wenn wirklich die Bude raucht, dann ist wenigsens 98 % der persönlich-familiären Historie auf dem Monate alten Offsite Backup. Eventuell noch mehr aktuelles auf der externen Nextcloud. Mach ich - Danke! Das wäre auch noch eine Idee. Eigentlich wollte ich mich ja von der Synology unabhängig machen, und ein integriertes System. Aber die Überlegung einer separaten temporären laufenden Backup-Maschine ist natürlich nicht von der Hand zu weisen. Naja, das CWWK J6413 betreibt am 1. PCIe schon im Endeffekt einen internen JMB685 Port-Multiplikator. Insofern rechne ich da nicht mit besten C-States und Durchsätzen. Andererseits reden wir hier von einem niederschwelligen Familien-NAS ohne besondere Anforderungen wie Transcoding, der eine Datenplatte an einem nicht aufrüstbaren Marvell Armada 385 Dual-Core mit 512 MB RAM und USB-Nightly ablösen soll (Die Synologs 216j ist mir dann doch schon als Medienserver etwas lahm...). Maximalausbaustufe (neben M.2 Cache) wäre: 1x Data, 1x Parity, 1x Offsite Hotplug, eventuell 1...2 alte HDDs "weil's geht". OK, sehr verständlich zusammengefasst. Verstanden. HDDs nicht in einen Pool; aber Daten, die häufig geschrieben oder gelesen werden, dann darüber.
  13. OK, das ist schonmal eine super Zusammenfassung - Danke! Mit Bündeln meinst Du Drive-übergreifende Shares? Die brauche ich vermutlich nicht bei 18 TB Main drive bei meiner Nutzung. Also Alles XFS. Verstanden - Danke! Gemeint war, dass Unraid gegenüber RAID ja Vorteile hat. "RAID-Korsett": Ich hatte es so verstanden, dass im RAID alle Drives gleich groß sein müssen, und bei einer Vergrößerung dann eben auch Alles ausgetauscht werden muss, was teuer ist und Einiges an Datenlogistik abverlangt. Bei Unraid schaltet man beliebige (kleinere) Platten dazu, oder vergößert eine, und dazu halt die Parity - Das klingt halt freier. Nein. Gäbe es einen Cache-Pool, hätte ich es verstanden. Aber aufgrund der 30x30 Pool-Drives Werbung und Forenposts, in denen die Pools anders verwendet zu werden scheinen (Mag ich falsch verstanden haben), war ich verunsichert, wozu ich mehrere Pools haben kann oder möchte. Und deshalb hatte ich eine Grenze im Hirn, dass auch die Backup-Platten nicht im Array mitschwimmen, sondern einen eigenen Pool bekommen. Aber anscheinend gehören die ja doch in das Array. Irgendwie habe ich immer noch nicht ganz gerafft, wie ich Datenplatten handhabe, die für sich außerhalb des Verbunds stehen (z.B. eine Offsite-Sicherung, die ich gelegentlich per Hotplug einbinden will). Wahrscheinlich ist das für alte Hasen völlig logisch, für mich ist das eine neue Denkweise, unabhängige Platten in einem Verbund zu halten, und dann, ob Hotplug oder nicht, mit einer gemeinsamen Parity zu verrechnen. Das verstehe ich noch nicht so ganz. OK, Cache ist nicht nur für Tempo, sondern auch zum Schlafenlegen der energieintensiven HDDs. Verstanden, und auch, warum Cache-Platten auch eine sinnvolle größe haben sollten und offenbar gern mit einem Raid abgesichert werden. Auch neu für mich war, dass die Daten entweder im Cache, oder auf dem Array stehen, aber wie ein gemeinsames Laufwerk angesprochen werden (Also mir als User egal sein kann, wo sie momentan geparkt sind). Das erklärt, warum die nicht so schnell wie möglich weggeschrieben werden müssen, der Cache-Pool aber auch nicht riesig groß sein muss. Danke auch für die Hirn-Neuverkabelung. Sowas Alles lese ich halt nur begrenzt aus der Doku raus. Offen: Wieso drehen alle Platten, wenn ich Daten für alle Platten über den Cache leite? Werden die nicht nur dann hochgedreht, wenn auch Daten für die jeweilige Platte aus dem Cache geschrieben werden? OK, wäre dann also wie ein Array ohne Parity, oder eben ein zusätzliches Raid. Prioritätenfrage. Wobei eine zusätzliche 1 TB M.2 ja nicht die Welt kostet und sich bei Cache-Verweildauern in Tagen ja schon lohnen. OK. Freigeben möchte ich da eher nicht, also eine Push-Anwendung recherchieren und finden (FreeFileSync hatte ich früher schonmal benutzt). Den Nextcloud-Client wollte ich wie gesagt vermeiden, ich suche eher was wie Synology Drive (also Sicherung auf ein share, nicht in eine Nextcloud-MariaDB). So oder so: Danke für die Geduld. Wie gesagt, es liegt nicht am Unwillen zum Lesen der Doku, sondern an der Kombi aus deren Anschaulichkeit und meiner Vorstellungskraft.
  14. @DataCollector OK, schon einmal Danke für die ausführliche Antwort. Das hilft mir etwas, die Doku und die Foren-Beiträge besser zu verstehen. Ich habe die Doku tatsächlich gelesen, finde sie aber bei weitem nicht so selbsterklärend wie Ihr alte Hasen hier, und bringe auch Dinge mit manchen Foren-Beiträge nicht in Deckung (Daher die Fragen). Vielleicht mache ich es mir auch einfach nur zu kompliziert. Insbesondere verstehe ich den Mechanismus der Pools und die unterschiedlichen File Systems nicht im Detail. Da hat Dein Post schon einmal geholfen. Ich wollte hier auch nicht Alle mit einem Riesen-Post über Vorhaben und mein Arsenal konfrontieren, aber hier: Familien-NAS mit Alltags-Dokumenten und mit moderat Medien-Daten (Fotos/Familienvideos, digitalisierten CDs, wenig Movies - ohne UHD o.ä.). Im Alltag werden nur wenige Daten geschrieben, vieles ist eher archiviert, und das meiste steuerbar. Ich brauche daher keine Hoch-Verfügbarkeit (RAID, oder Unraid Parity), sondern vor Allem Datensicherheit (Backups). Backups dürfen auch Risiko- und zeitlich gestaffelt sein. Offsite-Backup reicht z.B. nur alle paar Monate als Baseline-Archiv. Aktuelles aber immer mindestens immer lokal auf dem Arbeitsrechner und auf dem NAS, sowie einem Nightly-Backup im Server. Wenn da mal was ausfällt, verliere ich also maximal Daten eines Tages. Das wäre bei Familienfotos blöd, aber im Regelfall nicht schlimm. Es wäre auch schön, wenn es etwas Schutz gegen überschreiben gäbe (z.B. 3 alte Dateiversionen wieder herstellbar - Eine alte Version ist ja dann immer im Nightly Backup, aber manchmal merkt man das Problem ja zu spät). Offene Ports möchte ich nicht, deshalb habe ich eine gehostete Nextcloud (1 TB) für unterwegs-Daten (Kalender, Adressbücher, etc.) und externes Share. Da könnte man das allerwichtigste Aktuelle (so 0,5 TB) auch hinsichern. Wenn ich also vom Arbeitsrechner Synce, soll das nicht an eine weitere Nextcloud gebunden sein, sondern auf einem normal lesbaren Share. Ich bin eventuell paranoid, was Ransomware auf einem Fast-Inselsystem angeht, aber idealerweise sollte die Backups außerhalb der Backup-Zeit mögilchst nicht eingehängt sein. Was ich habe: Unraid Basic, d.h. max. 6 Platten (inkl. Array, Pool und Hotplug-Offsite Backup HDD - zählt eine USB cradle auch rein?). Das Board kann ohne PCIe 6 SATA + 2 M.2. Aufpreis für nächste Stufe würde ich notfalls zahlen. Insgesamt ~3 TB Daten, Tendenz steigend. 2x Seagate Exos 18 (18 TB), neu (leider gleiche Quelle). Entweder als Array mit Parity (allerdings wüsste ich nicht, wofür), oder als Data + Backup. Soweit ich das jetzt verstehe, müsste aber auch eine Backup-Platte dann doch mit in das Array rein, nur dann eben nicht als Parity - Kann ich sie da für Backups ein- und wieder aushängen? 1x M.2 Samsung EVO 970 (1 TB) für Cache. Cache ist für mich schnellschreiben, dann moven. Doku spricht von Default tägliches moven nachts. Deine Antwort interpretiere ich so, dass dadurch die Platte energiesparend im spin-down bleiben soll. Das heißt aber, solange ich nicht > 1 TB am Tag schreibe, muss ich nicht für jedes Share einen eigenen Cache-Pool anlegen. Wofür brauche ich denn dann "bis zu 30 pools á 30 Platten" (Doku)? ca. 5 Jahre alt, optional / zusätzlich: 2x WD Red (8 TB) - bisher eine als Datengrab in der Synology, eine per USB-Cradle als Nightly Backup. Die könnte man nutzen: entweder als Backup mit Parity nutzen (wenn ich die Doku richtig verstehe, muss das dann aber in das Array, da kein Cache-Pool) oder als Erweiterung für weniger wichtige Daten oder eine davon als Offsite-Kopie, um die 4 TB zu ersetzen. 1x WD Green (4 TB) - bisher als Offsite-Backup, für die ich die USB-Cradle dann manuell umbestücke. Wo ich auch noch hänge: Preclear wird empfohlen, braucht aber ein Plugin, das erst nach Start des Arrays installiert werden kann, welches dann also doch nicht Pre-Cleared werden kann? Oder ist das am Ende gar nicht so wichtig?
  15. Nachdem mein CWWK J6413 im Jonsbo N3 build nun erstmal läuft, bräuchte ich etwas Orientierung zur Aufstellung der Festplatten. Es geht um die Wahl einer sinnvoller Verteilung der Platten zwischen Array und Pools und dem passenden File System. Ich habe schon Einiges gelesen, habe aber das Gefühl, das ist ein Kaninchenbau, aus dem ich in Wochen noch nicht wieder rausgefundenb habe... Fragen: 1) File System: Ich sehe hier gelegentlich erwähnt, dass XFS oder v.A. Btrfs systematisch Datenverluste haben (können). ZFS klang schon vor Unraid super, gerade das BitRot-Protect, und nun ist es ja auch hier verfügbar. Aber soweit ich verstehe, wäre ein Array mit Parity dann ja dann nur mit RAID umsetzbar - und ich wollte nicht auf das RAID-Korsett gleich großer Platten angeweisen sein (Umständlich bei Upgrades, und ich habe auch etliche Platten unterschiedlicher Größe übrig - wenn auch einige davon schon 5 Jahre alt sind, aber man kann ja steuern, das kritische Daten eher auf den neuen Platten landen sollen). 2) Generell brauche ich aber auch nicht zwingend eine Parity für Verfügbarkeit - Dann bringt ZFS ja auch nicht so viele Vorteile? Oder bringt das auch bei einem Array ohne RAID / Parity mehr Zuverlässigkeit? Muss denn dann überhaupt ein Array existieren - oder kann ich auch nur mit Pools arbeiten? Vieles scheint ja in der GUI erst verfügbar, wenn ein Array gestartet ist. 3) Ich verstehe den Cache Pool so, dass man den als Primary beschreibt, und das dann auf ein Secondary wegschreiben lässt. Was wird denn im Cache wie lange zwischengespeichert? Nur die Files mit Änderungen für ein paar Sekunden/Minuten? Dann könnte ich da ja Alles drüber laufen lassen (Array, Backup-Pools, etc.). Oder ist der Cache dann quasi die einzige aktuelle Vollkopie des aktuellen Stands, der dann nur einmal am Tag weggeschrieben wird? Dann kann ich ja nur Verzeichnisse von insgesamt max. Cache-Größe darüber laufen lassen. Soweit ich verstehe, ist Parity spätestens im Cache-Pool auch eher Luxus? 4) Welche Lösung ist empfehlenswert (Unraid-Einsteiger mit begrenzten Linux-Kenntnissen) für a) Sync der Arbeitsdaten vom Arbeitsrechner quasi in Echtzeit auf ein unkodiert lesbares Share (also nicht in die DB einer Nextcloud)? Oder macht man das am besten per SMB und Windows-Boardmitteln ("verfügbar machen" o.ä.)? b) HDD zu HDD Daily Backup (rollierend inkrementell, oder noch besser ähnlich einer Time Machine mit den z.B. drei letzten Dateiversionen). c) HDD zu Hotplug-HDD manuelles Offsite-Backup der selektiv wichtigsten Daten (rollierend inkrementell, oder bei den älteren Platten auch als voll-Backup alle paar Monate) d) HDD zu externer Nextcloud (Ich habe eine 1 TB Hosted Nextcloud, mit der ich die nötigsten Daten täglich syncen könnte). Ich habe öfter Lucky Backup als handhabungsfreundlich erwähnt gesehen.