DataCollector

Zuerst: Mache von allen Dir wichtigen Daten des Array Backups.
Sollte ab jetzt eine der Festplatten ein Problem haben sind die Daten darauf in Gefahr.
 
Dann kannst Du bedenkenlos weiter machen.

Die Parität enthält ja die "Quersumme" aller Sektoren/Bits aller Datenfestplatten (SSD), um im Falle eiens Ausfalles diese jederzeit rekonstruieren zu können.
Somit ist es wichtig, daß die Parität bei jeder veränderung irgendeiner Datenfestplatte(SSD) im Array aktualisiert wird, um jederzeiot den Ausfall eines datenträgers abfangen zu können.
 
Sollte man eine Prüfung ansetzen wachen alle Datenfestplatten und die Parität auf um sich eben zu prüfen und ggf. anzupassen.

Punkt 1: Festplatten über USB ist unter unraid nicht empfohlen.
Punkt 2: Mehrere Festplatten über ein und die selbe USB Verbindung ist noch weniger empfohlen.
Punkt 3: Energieeffizient ist die Verwendung mehrerer Netzteile (Minisforum PC + ext. Festplattenstapel) eher selten.
Punkt 4: Du kannst Dich entscheiden, ob Du die 4 Festplatten im Array verwenden willst oder in einem oder mehreren Pools, ob Du diese mit Parity verwenden willst oder nicht. Wenn Du die Festplatten als ein durchgehender Speicherplatz (Array oder Pool mit Raid0,1,5 oder 6) benutzen willst ---> Siehe Punkt 1 und 2.
Punkt 5: Im Regelfall werden die großen Festplatten im Array verwendet, wenn man Ausfallsicherheit haben will mit Parity. Da in Deiner Auflistung nicht erkennbar ist, ob Du den Speicherplatz dadurch bereitstellen willst oder nicht, kannst nur Du entscheiden, ob Du das machen willst.
Punkt 6: Für Docker, Images, VM sind SSDs zu bevorzugen. Die meisten machen das so. Ob Du auch hier Ausfallsicherheit haben willst oder nicht, kannst nur Du entscheiden.
Punkt 7: falls Du die iGPU des Ryzen in der VM verwenden/durchschleifen willst: Informiere Dich hier genauer, da nicht jeder mit AMD Hardware glücklich wird und dann die iGPU ggf. für unraid selber nicht mehr zu Verfügung steht.
 
Ich würde (wenn es nicht diese unsägliche ext. USB Festplattenlösung wäre) die Festplatten ins Array mit 3 Daten + 1 Parity legen, die Festplatten mit xfs (ggf. xfs enc) formatieren+betreiben.
Die größte SSD als seperaten Pool (ebenfalls xfs) für Cache verwenden (wird wohl de NVME SSD sein).
Eine der kleineren SSD als seperaten Pool (ebenfalls xfs) für die Systemverzeichnisse/Shares nehmen um Docker, Images der VM etc. zu betreiben.
Die letzte SSD würde ich als Pool oder UD (ebenfalls xfs) einbinden und als Backupziel der Dir wichtigen Daten der anderen kleinen SSDs verwenden (Cache braucht in der Regelfall keine Backups, da nur temporäre Daten drauf sind).
 
Letzter Punkt: Beachte, daß Ausfallsicherheit nicht unbedingt auch Datensicherheit mit einschließt: Mache von den Dir wichtigen Daten mindestens ein Backup.

Nichts ist schlimm, solange bei den Festplatten, die einem zu beschreibenden Share zugeordnet sind, irgendwo noch genug Platz für den nächsten Schreibvorgang frei ist.
Die Warnung ist durch einen von Dir zu wählenden Wert/Füllstand veranlasst.
Du kannst den Warnwert hoch setzen.
 
 

Starte unraid auf dem PC.
Ins Array hängst Du erst einmal nur die 8TB, die Du sowieso da haben willst. (Leider läuft unraid vollständig nur, wenn irgendetwas im Array ist).
 
Damit laufen dann auch die Plugins und Du kannst mit UD auf die anderen Platten schauen.
Alternativ ein geeignetes Linux von einem Live Bootstick.
 
 

Trenne Cache und die 4 unraid-typischen shares auf unterschiedliche SSD/Pools auf.
Wenn der Cache schreibend stark belastet wird, ist der dazu gehörende Datenträger ggf. nicht mehr in der Lage gleichzeitig die VM/Docker zu bedienen.
Im Normalfall sollte das kein Problem sein, habe ich aber auch gehabt. Seit ich den Cache auf einer SSD/Pool laufen lasse und der Rest auf einer anderen SSD/Pool habe ich das Problem nicht mehr.
Einen Versuch ist es wert.

Also ich nutze unraid seit einiger Zeit mit dem normalen Opera (aktuell: Version:102.0.4880.33) und kann im Dashboard keine solche Probleme beobachten.
Screenshot siehe unten
1. Screenshot UR-Tessa unraid 6.12.3
2. Screenshot UR-Shipon unraid 6.12.4
 

 

Dein Beitrag deutet an, daß Dir der Zusammenhang, Bedeutung und Nutzung dieser Verzeichnisse nicht klar ist.
Ich empfehle die Dokumentation mal zu überfliegen.
In Deinem Fall besonders diesen Teil:
https://docs.unraid.net/unraid-os/manual/shares
=======
Default Shares
If you have Docker or VMs enabled then a number of default shares are set up to support their use. It is not mandated that you use these shares (and the system will let you remove them if you do not want to use them for their standard purpose) but it is recommended as it tends to make it easier to support users who encounter problems.
The shares that fall into this category are:
appdata: this is the default location for storing working files associated with docker containers. Typically there will be a sub-folder for each docker container.
system: this is the default location for storing the docker application binaries, and VM XML templates
domains: this is the default location for storing virtual disk images (vdisks) that are used by VMs.
isos: this is the default location for storing CD iso images for use with VMs.
=======
 
Falls Dein English nicht so weit reicht:
adppdata: HIer werden ggf. Dateien zu Docker abgelegt.  (bedeutet: solange der Dockerservice läuft ist das Verzeichnis blokciert/nicht verschiebbar).
system: Das hängt auch mit Docker zusammen. Auch blockiert, wenn Docker läuft.
domains: Hier liegen die Virtuellen Disk für Virtuelle Maschinen. Wenn der VM Manager aktiviert ist blockiert er das Verzeichnis.
isos: hier können ISO Dateien für installationen abgelegt werden.  In der Regel ist das nicht blockiert.
 
Bedeutet: solange Du die Docker- und VM-Funktion nicht abschaltest, kannst Du nicht all diese Verzeichnisse ins Array "moven" lassen.
 
Und da kommen wir zum zweiten Teil Deiner Frage: ja genau. deaktiviere die beiden Funktionen und dann solltest Du die Verzeichnise mit dem Mover ins Array verschieben können.
 
Achtung: wenn Du danach Docker und/oder VM wieder aktivierst, laufen die dann vom Array und das ist für eine VM eher "grottenlangsam".
Es ist sehr zu empfehlen diese Docker udn VM relevanten Verzeichnisse auf einer flotten SSD zu haben.
 

Unraid ist eben kein Raid. Raid1 in Deinem Syno beschreibt parallel auf 2 Disks und diese mit jeweils maximaler Geschwindigkeit.
 
Bei unraid hast Du ein anderes Konzept. Sobald Du ein Array mit mehr als 1+1 Daten/Paritätsdisk hast: werden erst die Daten der Parität, der betreffenden Stelle gelesen, dann im RAM verändert und dann auf die selbe Stelle geschrieben.
Es muss also erst die korrekte Position der Disk unter dem Lese/Schreibkopf ankommen um sie zu lesen,
dann werden die Daten im RAM verändert.
Leider ist die Stelle der Disk ja schon wieder wegrotiert, weshalb gewartet wird, bis die wieder da ist. Dann wird die Stelle geschrieben.
Daraus ergibt sich, daß bei diesem dieses Konzept die Paritydisk der bremsende Faktor ist und somit das Schreiben Deiner Nutzdaten auf 1/2 bis 1/3 Ihrer Transfergeschwindigkeit reduziert ist.
Das wird dann noch schlimmer wenn man SMR Disks einsetzt, die nach kurzer Zeit ihre Transfergeschwindigkeit stark senken und somit auch das längerfristige Schreiben ins Array ebenfalsl stark absinkt.
Solltest Du also auch SMR Disks als Parity einsetzen wäre das ein möglicher Gurnd für Transferraten um die 10MByte/s und zu überdenken.
24TB Nutzkapazität bei 3 Datendisks = 8TB.   bei den 8TB Disks ist SMR noh recht verbreitet. Welche Disks setzt Du ein (vor allem für Deine Parität)?
 
Die von Dir erwähnten 45MByte/s sind realistisch für CMR Festplatten der 8TB Leistungsklasse in einem Array mit mehr als 1 Datendisk und Parität.
 
Zu den weiteren 50TB:
Solange Du ein Backup Deiner Daten hast macht es Sinn, die Parität erst nachträglich zu aktivieren, ja.
Ohne Parität hast Du auf dem Array keinen Schutz gegen Festplattenausfall.
 
P.S.: Da Dir die Technik der unraid Parity anscheinend noch nicht klar ist, wäre es ratsam sich das durchzulesen oder eines der Erklärvideos bei youtube mal anzuschauen.
 
EDIT: Hier ist das Video von SI1. Ab ca. 09:28 Min:Sec ist Parity in unraid gut erklärt.
https://www.youtube.com/watch?v=HybwCOVDg9k
 

Lege die Shares auf Datenträger, die eben einen Schutz haben.
Im Array wäre das eben eine Parityfestplatte/SSD.
Bei einem Pool sollte dieser dann mindestens eine Mirror/Raid1 Funktion aufweisen.
 
Mit Schutz ist hier keine Sicherheit gegen Datendiebstahl gemeint, sondern, dass sie nicht geschützt sind gegen den Ausfall des Datenträgers, auf dem das Share liegt.
 
Ich schätze diese Shares liegen eben auf einem Pool, der nur aus einer einizigen SSD besteht.
 

Du hast zwar sehr viel Hardware ausgetauscht.
Nur als ganz blöde Frage: Ist das Gehäuse (und sein Powertaster) das Alte geblieben?
 
Idee dahinter:
Ein Powertaster (dessen Verkabelung) die vielleicht einen Schaden hat und bei Vibration oder so ab und zu selber kontaktiert würde zumindest bei Windows einen geregelten Shutdown/Standby verursachen.
Ich habe noch nie probiert/getestet ob unraid auch auf kurzes drücken/kontaktieren des Tasters entsprechend geordnet herunter fährt, aber vielleicht ist eine der noch nicht gewechselten Komponenten verantwortlich?
 
Hintergrund:
Ich hatte mir zu meiner PC Anfangszeit einen PC von einer kleine Computerklitsche zusammenschrauben lassen (BigTower). Die haben mir den als getestet ausgehändigt.
Bei mir aufgestellt und der ging sporadisch aus.
Zurück zur Klitsche: die haben ihn in ihre Werkstatt nach hinten (ausser Sicht) getragen und dort getestet, kein Problem.
Dann bin ich mit nach hinten gegangen und habe gesehen: die testeten den BigTower im Liegen.
Habe gebeten den mal hinzustellen und zu testen. Widerwillig haben sie es getan und da war der Fehler.
Nachgesehen: beim Zusammenbau hatte jemand einmal das Kabel des Powerknopfes eingeklemmt und dabei die Isolieung beschädigt. Und somit hat der vibrationsabhängig ab und zu mal Kontakt zum Gehäuse bekommen und damit das Ding ausgeschaltet.
 

Gratuliere.
Das klingt mir, als hast Du SATA zu SAS Kabel gekauft und genau die erwischt, die falsch herum verkabelt sind.
Ich vermute Du nutzt SATA Steckverbinder auf Mainboard und Kontrollerseite und eben den SAS Anschluß auf der Backplane der Festplatten.
Die Kabel sind Richtungsabhängig.
Du brauchst 3 Stück die genau dafür ausgelegt sind. Deine dürften vermutlich für SAS Kontroller und HDD SATA Fanout gedacht sein.
 
Hier wirst Du fündig:
https://www.ebay.de/itm/165496212270
"80cm SFF-8643 Target HD Mini SAS 36pin Connector 4 SATA 7pin host Reverse Kabel...
Specification:
internal mini-SAS HD to SATA Reverse Breakout cable used for connecting a host-controller or M/B with 4 SATA 7Pin connectors to a 12Gb/s mini-SAS HD backplane with an internal SFF-8643 connector."
 
ca. 19 - 20 Euro pro Kabel. Ich vermute 80cm sind lang genug.
 

12TB Festplatte als UD einbinden und als Ziel nutzen: ja, das geht.
Das Risiko ist genau so groß, wie der umgekehrte Weg.
 
Und das Array zu löschen macht man mit dem Tool "New Config", welches man unter den .... naja "Tools" findet.
 
Ob die Daten im Anschluß erhalten bleiben: sofern man nichts falsch macht: ja.

Moderne Festplatten mit hoher Kapazität arbeiten mit sehr winzigen magnetisierten Bereichen. Daß sich auch diese Materialiern bei Temperaturschwankungen verschieben ist Physik. Dieser Anzeige zeigt eben nur, daß der Kopf entsprechend anders positionieren mußte um die Datenspuren wiederzufinden.
Die Werte selber kann nur der Hersteller (und die Firmware) korrekt interpretieren.
Somit können die bei Dir ganz normal sein.
Ignorieren, solange keine wirklichen Proleme oder Fehler auftauchen (Pending Sectors, Reallocated Sectors/Events, etc...).
 
P.S.: Seit einiger Zeit scheint die Forumssoftware bei mir kein sonst übliches Schreiben zwischen den Zeilen zu ermöglichen ( so daß der Quotekasten mit Returntaste unterbrochen werden kann. Deshalb habe ich im Kasten den gequoteten Text mit einem > versehen.

Das Bild zeigt nur die Shareeinstellung, aber auch da würde ich die Minimum free Space auf mindestens die Groesse der aufzunehmen Datei einstellen.
Wenn Du Dateien mit jeweis maximal 80GB Größe dort einbringen willst, sollte also der Minimum free Space etwas größer ausfallen, damit das Share eben nicht voll läuft.
 
Und gleiches gilt auch für die Cacheeinstellungen.
Wenn Du im Cache ebenfalls 0kb stehen hast, ist es logisch daß er voll läuft. Somit bricht die Datei, die zuletzt aufgespielt werden soll ab, weil unraid die Dateien nicht zerteilt, sondern immer in einem Stück zu belassen versucht.
 
Wenn Dein Backup/Image aus ein einer einzigen Datei besteht, die 1000,01GB groß ist und Dein Cache 1000GB Kapazität hat (und da geht noch Platz für das Dateisystem ab), dann ist es logisch, daß das Backup bei ca. 1TB abbricht.
Deshalb erzeuge ich Backups/Images sowieso in der Regel in kleinen 1,99GB großen Häppchen, damit es einerseits kein Problem mit solchen Grenzen gibt und andererseits ich die sogar mit simplen FAT32 formatierten Datenträger transferieren kann.
 
Das passiert auch, wenn einerseits kein Datenträger absolut randvoll geschrieben wird (stelle den Free Space im Cache und Share ein!) und wenn eben keine Datei dabei zerstückelt werden müßte.
 
Das läßt sich bei divesren Backup-/Imageprogrammen einstellen.
Wie erwähnt, ich stelle in der Regel 1,99GB als Zielgröße der Backupdateien ein.
 
Hier kommen wir nun zu einem kleinen Problem:
Es scheint, als wenn die Minimum Free Space Einstellung in unraid 6.12.0-rc6 und rc7 im cache nicht mehr im GUI einstellbar zu sein scheint.
Ich weiß, daß es vorher möglich war (unraid 6.11.x Cache/Pools mit xfs und BTRFS betrieben).
Nun wollte ich Dir gerade Screenshots davon machen, doch diese Einstellungsoptionen habe ich unter 6.12.0-RC6 und RC7 nicht mehr. Der Punkt wird noch dargestellt, aber es ist bei mir daneben nichts mehr einstellbar.
Somit kann ich Dir erst einmal nur raten: stelle in Deinem Backupprogramm ein, daß es eben kleine Backuphäppchen macht.
 
 
Abgesehen von einem einzigen Fall, den ich bald auch austausche, haben alle meine SSD Pools mindestens ca. 2TB.
 

War das nicht so, dass er bei Prefer Cache umzieht, aber Only Cache nicht wegbewegt?
 
Edit:
Ich scheine recht zu haben:
 
https://docs.unraid.net/unraid-os/manual/storage-management#moving-files-between-a-pool-and-the-array
 
"Moving files from array to pool
The commonest Use Cases for this is when you have either used the above steps to get files off the cache and now want them back there or if you have newly added a cache drive and want the files for selected shares (typically appdata and system) to be moved to the cache. The steps are:
- Disable the Docker and VM services under Settings. This is done to ensure that they will not hold any files open as that would stop mover from being able to move them.
- Go to the Shares tab and for each share you want to be moved from the array to the cache ensure that the Use Cache setting is set to Prefer.
- Go to the Main tab and manually start the mover process so that it starts transferring the files from the array to the cache."

...
Sofern Du alles richtig eingestellt hast, kann es unter Windows schon mal 'ne Viertelstunde dauern, bis es klappt.
 
Aber nur zur Sicherheit hier mal ein Screenshot, wie es bei mir funktioniert zum Vergleich:
 
 

Nicht wirklich, wenn das BIOS alles anzeigt und unraid nicht, kann ich mir nur vorstellen, daß das BIOS die Festplatte irgendwie maskiert/versteckt.
Das sollte aber per Default nicht der Fall sein.
 
Steck das Kabel der 'unsichtbaren' Festplatte mal an einan anderen SATA Port auf dem Mainboard und prüfe auch, ob der Stromanschluß wirklich richtig aufgesteckt ist.

Wie groß ungefär?
Ich lasse mit Absicht Acronis die Zieldateien immer auf 1,9GB splitten. Somit habe ich zwar dann einige Dutzend/hunderte Imagedateien, aber die lassen sich problemlos in Häppchen sogar mit einem FAT32 USB Stick transferieren.
(Ich darf gerne Leuten mit älterer Hardware helfen, wobei sich die eigentlich schon lange obsolte FAT32 2GB Grenze auch heute noch zeigt).
 
50MByte/s ist okay, 8MByte/s ist sehr langsam für ein Array.
 
In einem vorherigen Durchlauf oder in diesem beanstandeten MoverDurchlauf?
 
Soweit ich richtig sehe:
2x2TB Daten und 1x 2TB Parity Festplatten im Array.
 
Die Western Digital WD Blue Mobile 2TB, 7mm, 128MB, SATA 6Gb/s 5400Rp (WD20SPZX)
sind 2,5inch SMR Festplatten.
 
2,5inch ist (in diesem Fall) schon langsamer als 3,5inch
5400Rpm ist langsamer als 7200RPM
und durch SMR sackt nach kurzer Schreibdauer die Datenrate zusätzlich massiv ein.
 
Im Array als Datenfestplatte ist das vielleicht noch zu ertragen,
als Parityfestplatte sind diese Festplattentypen (meiner unmaßgeblichen Meinung nach) vollkommen falsch (=bremsend) platziert.
 
Von den 3 Festplatten im Array sollte die Western Digital WD Red Plus 2TB, SATA 6Gb/s, 3,5inch, CMR (WD20EFRX) die Parität machen.
Das redzuiert die negativen Auswirkungen der SMR Technik etwas.
 
Marvelkontroller und unraid...    Ich sage mal ganz vorsichtig: nicht mein Favorit.
Und an PCIe 2.0 x1 mehr als 2 Festplatten zu betreiben ist auch irgendwie nicht unbedingt (für performante aktuelle Festplatten) nicht die Beste Idee.
Deine dort angeschlossenen Festplatten hingegen sind schon eher die gemächlicheren Typen, wodurch sich an dem Kontroller in dieser Situation zumindest kein Flaschenhals zeigen dürfte (abgesehen davon daß Marvel und unraid.... naja, ich sagte ja schon, nicht mein Favorit).
 
Gute Entscheidung, weil diese WD etwas flotter als die anderen beiden Arrayfestplatten ist, sollte sie auch den performantesten Kontrollerport bekommen.
Wenn ich es richtig lese scheint Dein Mainboard für einen AMD Ryzen oder so gedacht zu sein.
Diese Boards haben meist mehr als nur 1 OnBoard SATA Steckplatz. Wenn es möglich ist, würde ich den Marvel entfernen und die Festplatten intern anschließen.
Das spart Strom und vielleicht auftretende Probleme durch den Marvel unter unraid.
 
Also ich befürchte SMR, 5400Rpm und sehr ungünstige Parityeinstellung (falsche Festplatte) haben die Transferrate über die erwähnte Zeit (20-18 Uhr) so weit einbrechen lassen, daß der Mover sich an der größten Datei noch die Zähne ausgebissen hat und noch mitten im Prozess des Kopierens war.
Du erwähntest, daß der Mover wegen Problemen von Dir manuel gestoppt wurde.
Gerade bei ausgelasteten SMR Festplatten kann der Mover so erscheinen, als wenn er eingefrohren ist, weil er eben auf die SMR Festplatte wartet, die sich mit sich selbst beschäftigt.
Könnte es das gewesen sein, weshalb Du ihn abgebrochen hast?
 
Bezogen auf kleine Dateien im KB oder wenige MB Bereich hast Du vollkommen recht.
a) 600GB in 10 kb Stücken verschieben: die Kiste wird wohl Tage brauchen.
b) 600GB in beispielsweise 1-5 GB Stücken: wird weniger brauchen als a).
c) 600GB an einem 600 GB großen Stück: wird ähnlich wenig brauchen wie b).
 
Aber alle 3 Szenarien rennen vor die 5400RPM SMR Wand der langsamen 2,5inch Paritätsfestplatte.
 
Wenn der Mover aber bei c) hängt/abgebrochen wird, hat er natürlich auf dem Pool/Cache noch nichts gelöscht, weil die Datei ja noch nicht fertig überrragen ist.
Wenn der Mover bei a) oder b) an einer Datei dran ist und Du brichst ab, wird er aber die kopieren Dateien auf den Pool/Cache schon gelöscht haben, wodurch sich ein Erfolg durch weit mehr freien Platz auf dem Pool/Cache sehen läßt.
 

Das kenne ich nur zu gut, und stoerte mich bei 24 Disks auch.
Hat einige Zeit gebraucht, bis ich das manuell wieder sortiert hatte. Ich bevorzuge es die oberen paar Verzeichnisse alphabetisch aufsteigend zu haben.
Die automatisierten Splitmöglichkeiten von unraid helfen mir leider nicht, weshalb ich nun vom Cache ab und zu manuell selber einsortiere.
 
Wenn Du nicht alles von Quelle (anderer PC/NAS) neu kpieren willst: sortiere es manuell (ich nehme mc oder krusader/ich777 dazu).
 
Okay, unbalance geht auch. Ist mir aber zuviel klickerei.
 
oder eben mc oder krusader...
 
Wenn Du sie anders verteilen willst, schiebe sie dort hin, wo Du sie haben willst.
 
Das erfordert aber, daß Du den doppelten Speicherplatz hast.
Ich nutze den mc 8weil er meist auch nicht bloede nachfragt ob er in ein verzeichnis schreiben soll), wobei dieser beim verschieben erst das jeweilig angewählte Verzeichnis komplett kopiert und erst im Anschluss die Quelle löscht. Somit hat man im Falle eines Festplattenschadens auf dem Ziel, das gerade angefangene Quellverzeichnis immer noch existent.
 
Nicht, wenn Du nicht zwischen Shares, sondern Disks verschiebst (so mache ich es). Man darf nur nicht von Shares auf Disks oder umgekehrt verschieben/kopieren, das kann arg in die Hose gehen. Aber von einer Disk1 auf eien Disk2 zu verschieben ist ein wirklich physikalisches Lesen und Schreiben. (siehe Screenshot 1)
 
Kopiere/verschiebe doch ueber Disks und nicht Shares.
Aber beachte, dann hast Du wirklich die Kapazitätsgrenze der jeweiligen Festplatte/Datenträger zu beachten. Aber krusader zeigt ja an, wieviel zu kopieren ist.
mc kann es auch anzeigen (Strg-Space) (Siehe Screenshot 2)
 
 
Wenn du kopierst und es die selbe Datei auf 2 Disks in der selben Ordnerstruktur gibt wird es noch verwirrender, weil man nicht weiss, mit welcher man gerade arbeitet.
 

Da ich auf dem Stick eher selten etwas ändere: ab und zu (einmal im Monat oder so) Flash Backup über die dafür vorgesehen Funktion.
EInfach im Main Tab auf "Flash" klicken und dann das Flash Backup ausführen.
Die dann entstandene Datei irgendwo gut (extern) ablegen.
 

 
 
 

Laut dem MSI Z170-A Pro Handbuch PDF Seite 15 für den europaeischen Bereich würde
 - eine M.2 SATA SSD im M.2 Steckplatz die SATA Ports 1 und 2 abschalten.
 - eine M.2 PCIE/NVME SSD im M.2 Steckplatz die SATA Ports 3 und 4 abschalten.
 
Handbuch:
https://www.msi.com/Motherboard/Z170-A-PRO/support#manual
 
Screenshot hier:

Es zeigt Raid1 an, ja, dann ist es Raid 1.

Das PreClear Plugin ist nicht (mehr) notwendig. Unassigned Devices hat diese Funktion seit einiger Zeit eingebaut.
Ganz rechts auf das Zahnrad: "Destructive Mode" enablen und danach DONE.
Dann sollten neben den Festplatten Symbole erscheinen um auch Preclear auszuführen und damit Daten auf den Datenträgern zu überschreiben.
Man 'kann' die Datenträger ganz damit 'Nullen' doch das dauert je nach Größe und Geschwindigkeit recht lange.
Wenn man den Preclear nur so 10 Minuten laufen läßt wird schon genug des Dateninhalts gekillt, so daß unraid die Festplatten als leer ansieht.
Aber dennoch wird unraid die Datenträger im Array dann einmal selber nullen. Also nicht wundern. Du wirst einmal das Durchnullern abwarten müssen.

nein