_alo_

dann füge in deinem BackupSkript am Ende einfach den Mover-Aufruf vor dem Runterfahren ein, also in etwa: rsync <Optionen> <Profuktiv-Server-Share(s)> <Backup-Server-Share(s)> ## als Beispiel für dein Backup-"Skript" mover start ## Mover manuell starten halt ## HerunterfahrenBedenke beim Cachen der Shares auf dem Backup-Server, wie viel Daten Du da hin sichern möchtest und ob der Cache dafür ausreichend groß ist. Wen du z.B. eine 1TB SSD als Cache verbaust, aber regelmäßig z.B. 6TB sichern möchtest, macht das wenig Sinn, weil Dir dann der Cache überläuft. Daher hab ich z.B. keinen Cache im BackupServer, trotz 2,5G 😉 P.S.: laut rsync schreibt mein Array ohne Parity(!) im BackupServer immerhin mit >130MB/s statt nur 80M/s

Ok, dann muss es ja ein 7.2.2 bug sein oder warum habe ich das Problem sonst nicht?

Ok, das scheint dann wohl ein Windoof Thema zu sein?

Deinem letzten Satz stimme ich ja vollkommen zu, aber ob es im Umkehrschluss problematisch ist, das Feature aktiviert zu haben, wenn man nur eine Netzwerkkarte nutzt, würde ich dagegen so nicht sagen... Ich erreiche hier als Gegenbeispiel nämlich volle 10G und das bei einer großen Datei auch dauerhaft über z.B. 2min 😉 (will sagen, dass der RAM-Cache hierbei irrelevant ist, da die NVMe inkl. Anbindung schnell genug ist) und das mit einem Standard-MacOS Sequoia als client (wo das Feature standardmäßig aktiv ist) und einem unraid 6.12.15 mit aktiviertem SMB Multichannel. 🤔 Das Problem sollte also woanders zu finden sein. Oder hat das Ausschalten bei Dir was bewirkt und hast Du jetzt mehr als 420MB/s?

Ja verstehe ich schon, aber im Doku-Link wird nur auf die möglichen Filesysteme eingegangen für Array und Pool nicht wie der Pool aufgebaut wird. JBoD ist ja kein Filesystem und muss auch nicht vom FS unterstützt werden. Man kann ja (theoretisch, wahrscheinlich eben nicht bei unraid, oder nur über Konsole) auch ein JBoD aus mehreren XFS erstellen, die in sich keine Redundanz bieten 😉

ich meinte mit JBoD eher ein /dev/md aus mehreren Filesystemen (egal welche) nicht ein großes Filesystem, was verschiedene RAID-Level unterstützt.... so ähnlich: mdadm --create /dev/md2 --level=linear --raid-devices=2 /dev/sda1 /dev/sdb1quasi so wie das Array bei unraid. Aber sind wir wohl eher wieder bei der Frage, wann unraid mal mehrere Arrays unterstützt 😉

Von zfs hab ich bewusst nichts geschrieben, weil ich hier auch einfach keine Erfahrung habe was unraid da so beherrscht. Was @Razam möchte, ist eigentlich ein JBoD mit unterschiedlich grossen Platten, aber kann unraid das im Pool? K.A.🤷🏻‍♂️

Nein, pro Share kannst Du nur einen Pool als primären "cache"-Speicher angeben, secondary ist dann immer das Array. Da hilft wahrscheinlich nur das Kaufen einer größeren SSD, wenn du mehr Cache für ein bestimmtes Share brauchst. den integrierten Weg über die Main-Gui hast Du ja schon gefunden, ansonsten gibt es diverse Dateimanager docker-Container in de Community Apps dazu, z.B. den Krusader.

unterschiedlich große Datenträger in einem klassischen RAID wird schonmal nicht funktionieren. Du könntest getrennte Pools bauen...

Genau: du hast raid0 nicht verstanden. Nachdem er zwei TB auf die beiden disks aufgeteilt hat, kann er das für weitere Daten nicht machen, da die kleinere Platte schon voll ist. Erwartest du dass das dritte TB ohne striping gefüllt wird? Wohin kopierst du? Aufs Array (dann sind 140mb/s ja nicht soo schlecht) oder auf den vollen Cache? Für die Prozentangabe: von wie viel Daten reden wir denn?

Du kannst natürlich Backups einrichten mit einem Tool deiner Wahl aber eine Spiegelung von Daten eines Pools ins Array ist nicht vorgesehen!

und da meinst du on-the-fly transcodieren, wobei das für mich bedeutet: runterrechnen und anschließend aufs Handy kopieren und offline schauen das kann ja irgendein Rechner tun und es ist dann auch (fast) egal, wie lange das dauert, oder? Also demnach würde ich auch sagen: entsorg/verkauf den alten, stromhungrigen Gaming-PC und hol dir was Stromsparendes (N100) als NAS. wobei: wenn das so bleibt, ist Stromsparen wiederum auch egal - wieso dann überhaupt was neues (Hardware/Software)?

geh mal davon aus, dass das zusammenhängt 🤣 Wenn Du auf eine Datei zugreifst, die auf der Platte liegt (das lässt sich ja prüfen, wo die Folge liegt), muss diese anlaufen, das sollte klar sein. Die Parity muss wie gesagt beim Lesen nicht anlaufen (solange alle Platten intakt sind und nichts emuliert werden muss). Wenn du den Zugriff (die Wiedergabe der Folge) stoppst, zählen die 15min bzw. der eingestellten Wert für Spindown eben runter......

Dann musst Du schauen, was das für container sind und warum die die Platten aktiv halten. Die Parity läuft übrigens nur, wenn auch was geschrieben wird - für das reine Lesen bleibt die aus. Also was wird von den Containern geschrieben außerhalb von appdata? Ziel sollte ja eigentlich sein, dass sich das array möglichst dauerhaft schlafen legt. Klar für bestimmte Tasks wachen dann einzelne Platten auf, aber ansonsten sollte es schlafen. Wenn die Platten im SpinUp sind, brauchen wir hier gar nicht nach Stromsparmöglichkeiten suchen, das beginnt erst im spindown 😉

Achso ok, wenn deine Eltern auch eigene Daten darauf produzieren, würde ich diese andersrum zu deinem Hauptserver sichern. Backup/restore würde ich Share-weise über rsync machen. Damit werden vorhandene Daten übersprungen und nur neue gesichert bzw. fehlende restored. Die Parity sorgt ja nur für eine höhere Verfügbarkeit (eben bei Defekt einer Platte). Wenn die Daten bei deinen Eltern auch immer alle zur Verfügung stehen müssen, dann mit parity, sonst vielleicht ohne🤷🏻‍♂️

Volle Zustimmung, aber um vielleicht Kosten zugunsten größerer Platten (oder anderem) zu sparen würde ich mir nochmal überlegen ob es beim Backupsystem wirklich eine parity Platte sein soll/muss?

Gerade wenn du beim Login normalerweise 2FA benutzt, MUSST du ein App-Passwort nutzen. Ist 2FA nicht bei GMX auch quasi schon Pflicht? Das App-Passwort umgeht diese zusätzliche Sicherheit einfach (damit das hier überhaut funktionieren kann - wie/wo solltest Du den 2Faktor auch eingeben?). Diese App-Kennwort-Zugange sind somit erstmal "unsicherer" und daher sollte man diese Kennwörter auch für jeden Dienste separat anlegen/nutzen und am besten nicht selbst irgendwo speichern oder nutzen, dann können sie auch fast nicht abgegriffen werden. Zum Einloggen im Webmailer dürften sie (im Falle von 2FA) natürlich auch nicht funktionieren. Weil es bei allen geht, nur gerade bei Dir nicht? ich denke nicht 😉 Daher kamen wir noch auf das Thema Firewall und DNS: per Firewall-Regel darf der Zugriff auf die nötigen IP:Port-Kombinationen natürlich nicht geblockt sein, und per DNS muss mail.gmx.net natürlich auch auflösbar sein, also am Besten kein DNS-Blocker o.ä. dazwischen. Das einfachste ist, hier zum Testen eben mal öffentliche wie 8.8.8.8 einzutragen. Wenn Du die Notifications von unraid testest, muss natürlich auch unraid den Server auflösen können! Da reicht die Anpassung im luckybackup natürlich nicht. Mit den richtigen Optionen (SSL/TLS) und dem korrekten Login-Daten sollte ein Versenden dann eigentlich möglich sein. Theoretisch könnte natürlich GMX auch Deine IP blockieren....aber dann bekämst Du wahrscheinlich eine andere Fehlermeldung. Daher der Tipp mal einen anderen Provider zu testen... Teste auch ruhig mal ein "telnet mail.gmx.net 587" auf der unraid Konsole und poste hier die Ausgabe. (Die Hilfeseiten bei GMX oder hier hast Du ja wahrscheinlich alle schon durch und alles mehrfach gecheckt?) Versuche doch, die Tipps hier am besten erstmal alle umzusetzen und entsprechende Rückmeldung zu geben... Klar, dass 1&1 hier heute parallel eine Störung hatte, ist/war doof für die Fehlersuche, aber Du hattest das Problem ja nicht nur heute morgen, sondern schon seit Tagen...ich denke, das wäre schon irgendwo zu lesen gewesen, wenn GMX seit Tagen/Wochen nicht liefe und nebenbei: bei den anderen hier geht's ja auch 🤷‍♂️ Also: welche Kombinationen (Port, Sicherheit) hast Du jetzt alle schon durch? nutzt du auch wirklich ein App-Passwort? funktioniert das im Thunderbird o.ä. anderen eMail-Clients? hast Du testweise schonmal eine neues angelegt? vielleicht ein einfacheres bzgl. Sonderzeichen (könnte ja theoretisch noch ein Zeichensatzproblem sein)? hast Du dir mittlerweile vielleicht deinen Zugang wegen zu vieler Fehlversuche komplett gesperrt? Kannst Du dich mit der normalen 2FA noch im Webmailer anmelden? kannst Du den Mailserver erreichen? connected sich telnet auf der Konsole? was sagt das unraid-Log im Fehlerfall? hast Du schon einen anderen eMailprovider in unraid-notifications und/oder luckybackup getestet?

Ja genau, denn dann hättest du durch das Spiegeln auf der neuen 2TB SSD ja auch nur eine 1TB Partition. Du müsstest diese dann nachträglich irgendwie vergrößern und ich glaube, dann ist das obige der bessere/sichere Weg.

Erst dachte ich, der Server ist falsch, aber nein: GMX gibt ihn zwar mit mail.gmx.net an, aber smtp.gmx.net löst auf die gleichen beiden IPs (212.227.17.190, 212.227.17.168) auf... Sieht also eigentlich erstmal richtig aus (sofern das richtige App-Passwort verwendet wurde). Aber wie hier auch schon erwähnt, kannst Du auch den Port 465 mit SSL testen, siehe obigen Hinweis. Auch wenn es sehr unwahrscheinlich ist, das unraid einen so alten Mail Client (mit TLS<1.2) unraid verwendet. Sorry, ich kann das alles nicht (mehr) testen, GMX hat meine alte Adresse vor Jahren wegen Inaktivität komplett gelöscht und ich werde mir bei dem Laden wohl auch keine neue mehr einrichten 😉 Nochmal die Frage: hast Du eine Firewall dazwischen, die irgendwas blockt? Kannst du diese beiden Namen/IPs überhaupt anpingen aus deinem Netz? Hast Du den vor eingestellten Dienst "Benutzerdefiniert" mal auf "GMX.com" geändert und mit den Vorgaben getestet? Hast Du mal mit einer anderen Adresse (Gmail, Microsoft, ISP,....) getestet? Bei mir sieht das im Log für den erfolgreichen Notification-Test zu Gmail übrigens so aus (mit 587/STARTTLS oder auch 465/SSL): Nov 19 09:13:48 NUC sSMTP[1268961]: Creating SSL connection to host Nov 19 09:13:48 NUC sSMTP[1268961]: SSL connection using TLS_AES_256_GCM_SHA384 Nov 19 09:13:50 NUC sSMTP[1268961]: Sent mail for [***]@googlemail.com (221 2.0.0 closing connection a640c23a[***]-b734fb12d55s[***]6b.33 - gsmtp) uid=0 username=root outbytes=760ohne STARTTLS sieht der nicht erfolgreiche Versuch mit Port 587 so aus: Nov 19 09:16:31 NUC sSMTP[1275729]: Creating SSL connection to host Nov 19 09:16:31 NUC sSMTP[1275729]: Cannot open smtp.gmail.com:587Kannst Du mal im Log (Tools --> SystemLog) schauen, was dort so an Ausgaben zu deinem GMX-Test dokumentiert wurden?

Sorry aber scroll mal hoch, ich hatte dir doch sogar mal ein Foto des boards gepostet mit den verschiedenen Anschluss- und Kombinationsmöglichleiten von SATA-Ports bzw. NVMes.

?? Und funktionieren die unraid notifications über diesen GMX Server? Teste das doch erstmal und dann kümmerst du dich um luckybackup! Momentan ist doch noch unklar ob es am docker oder an gmx liegt, oder?? Dann wäre m.M.n. Das sinnvollste nach und nach eins auszuschließen: versuchen ob gmx woanders läuft oder versuchen ob andere Adresse in luckybackup läuft. Und nur sagen „geht nicht“ bringt uns nicht weiter. Was hast du denn getestet?

es gibt ja zwei Versionen der MG09ACA18T, Du hast schon die günstig(er)e rausgesucht 😉 P.S.: im Januar 2023 kostete die MG09ACA18TE noch 100€ weniger als in obigem Screenshot (da hatte ich welche gekauft), seitdem sind Angebote unter 15€/TB seehr rar

die Preise steigen doch schon länger und seit Anfang September so richtig...

Ich würde behaupten (ohne einen Link zu diesem Adapter zu haben), dass das nicht funktioniert, weil das Board iirc zum einen keine bifurcation für zwei PCIe Devices am PCIe-Slot kann und im anderen Fall der ASM1166 kein SATA-Device ist. Ob der abgebildete jetzt 2x NVMe unterstützt (geht bei dem Board nicht) oder nur NVMe+SATA (geht bei den zwei gleichen Adaptern also auch nicht), kann ich nicht erkennen.... Es gibt solche Adapter nämlich auch einfach für 2x M.2, dabei aber einmal eine NVMe über den PCIe Slot und einmal eine SATA-SSD, deren Anschluss über den SATA-Stecker rausgeführt wird.

Ja genau, dann wird eben der DNS Server von Google gefragt statt deines pihole