hawihoney

Hatte ich das nicht geschrieben?

Die Fehler sind doch dann erst im letzten Lauf korrigiert worden. Wenn der letzte Check mit Korrektur war, und alle anderen davor ohne Korrektur, dann würde der nächste Lauf keinen Fehler mehr melden.

Nur zur Klarstellung: Es sind zwei Platten gleichzeitig während eines Parity-Builds ausgestiegen - Disk6 und Parity2 - wobei letztere gerade aufgebaut wurde? Das ist eine Situation die mir noch nie untergekommen ist. Wie ist denn jetzt der Status (Screenshots!)? Was zeigt denn Unraid an? Theoretisch kann Disk6 mit Parity1 emuliert werden. Da Parity2 keine Kopie von Parity1 ist, sondern separat u.a. aus dem Inhalt von Parity1 berechnet wird, ist m.E. noch nichts passiert. Da ich aber nicht an Zufälle glaube würde ich mal recherchieren ob es nicht Kabel oder sonstige Probleme gibt. Was sagt denn das syslog?

Sorry, nein. Im Moment nutze ich weder Nextcloud noch eine Alternative. Hatte irgendwann die Nase voll von Nextcloud und dem ewigen Gefrickel. Als extrem ungeduliger Mensch ziehe ich schnell den Stecker ohne über den Rest nachzudenken. Da ich alle Dokumente, Bilder, etc. schon immer sauber organsiert und benannt hatte, klappt das im Moment ganz gut über das Dateisystem und VPN.

Ich habe das immer mit den Bordwerkzeugen gemacht. Je nach Version Deiner MariaDB Installation musst Du mit "mysqldump" oder "mariadb-dump" exportieren - es hat bei den Namen der Tools einen Wechsel gegeben. Alle Parameter für den Dump findest Du in u.a. aufgeführten Link. ### docker stop alle Container die auf MariaDB zugreifen docker stop <Name des MariaDB Containers> ### Deprecated docker exec -i mysqldump --user=<Benutzername> --password=<Passwort> <Datenbankname> > <Wohin mit dem Dump?> docker exec -i mariadb-dump --user=<Benutzername> --password=<Passwort> <Datenbankname> > <Wohin mit dem Dump?> docker start <Name des MariaDB Containers> ### docker start alle Container die auf MariaDB zugreifen https://mariadb.com/kb/en/mariadb-dump/ In die neue MariaDB musst Du dann aber auf jeden Fall mit "mariadb" importieren: ### docker stop alle Container die auf MariaDB zugreifen docker stop <Name des MariaDB Containers> ### Deprecated docker exec -i mysql --user=<Benutzername> --password=<Passwort> <Datenbankname> < <Wo liegt der Dump?> docker exec -i mariadb --user=<Benutzername> --password=<Passwort> <Datenbankname> < <Wo liegt der Dump?> docker start <Name des MariaDB Containers> ### docker start alle Container die auf MariaDB zugreifen https://mariadb.com/kb/en/mariadb-command-line-client/ Ich nutze Nextcloud/MySQL/MariaDB seit kurzem nicht mehr, aber so habe ich es immer gemacht.

Winzinge Ergänzung zu @alturismo : Und die in den Plex Container gemappten Disks/Shares mit dem Content als readonly mappen. Dann bist Du auf der sicheren Seite:

Ich würde das Mounten über rclone empfehlen. Das Unassigned Devices Plugin stellt extra für eigene Anbindungen den Ordner /mnt/addons/ bereit. Das Einrichten ist relativ einfach: https://rclone.org/webdav/ https://rclone.org/commands/rclone_mount/ Ich kann mir nicht vorstellen, dass WebDAV jemals in Base Unraid integriert wird - passen würde es thematisch eher zu UD. Aber auch von UD würde ich einen Verweis auf rclone erwarten. Guck Dir mal die unfassbar lange Liste an unterstützten Services in rclone an. Da ist für jeden etwas dabei. Mit dem un-get Tool von @ich777 kannst Du rclone installieren.

^^^ Genau das ist meine Perspektive mit Unraid. Ich werde wohl auf nicht absehbare Zeit auf 6.11.5 bleiben.

Ich würde es machen. Auf fehlende Schreibzugriffe zu vertrauen wäre mir zu viel Toto/Lotto. Nur zur Erläuterung: In RAID Systemen haben die eigentlichen Daten Vorrang vor den Paritäts-Daten. Im Unraid Array bedeutet das "Die Datenplatten haben immer Recht". Wenn bei einem Crash zufällig die Daten-Platte aktualisiert wurde und die Paritäts-Platte noch nicht, dann besteht das Risiko, dass andere, bisher unbeteiligte, Platten beim nächsten Sync neue Fehler erhalten. Beispiel: Nehmen wir einmal an, ein Bit wurde noch nicht in der Parity-Platte vermerkt. Eine andere Datenplatte raucht jetzt vor dem notwendigen Parity-Sync ab. Du steckst eine Ersatzplatte rein und schwupps existiert ein 50% Risiko (even/uneven Parity), dass auf dieser bisher unbeteiligten Daten-Platte an der Stelle ein Fehler erzeugt wird, der vorher noch nicht da war. Und diese Platte kann das dann still und heimlich weitergeben. Der Spuk endet erst beim nächsten Parity-Sync. Dann hat aber die Parity-Disk diesen neuen Fehler bereits übernommen. Ab diesem Zeitpunkt werden keine neuen Fehler erzeugt, aber den bereits erzeugten Fehler merkst Du vielleicht erst in Jahren auf der unbeteiligten Platte. Das Risiko ist minimal aber ich lerne täglich wie unterschiedlich sorglos manche mit ihren Daten umgehen. Man sollte das Risiko zumindest kennen. Lange Rede kurzer Sinn: Mit einem Parity Check bist Du auf der sicheren Seite.

Du verstehst es einfach nicht, aber egal ... ... ich bezeichne das als mit fremden Federn schmücken - aber auch egal - gibt so ein nettes Feature hier in der Forums-Software.

Das sind zwei unterschiedliche Mechanismen. RAID (auch das parität-gestützte Unraid Array ist ein RAID-System) bietet Redundanz und somit Verfügbarkeit. RAID hilft beim Ausfall kompletter Platten, Backup sichert einzelne Ordner und Dateien. Wenn Du Dir eine Datei aus Versehen löschst, dann nutzt RAID nix. Dann brauchst Du ein Backup mit dieser Datei. Wenn Dir eine Platte ausfällt, dann bist Du ohne RAID erstmal offline. Mit RAID kannst Du trotz der fehlenden Platte weiter arbeiten. BTW, warum markierst Du eine Zusammenfassung der Hilfestellung anderer immer als Deine Solution. Nach meinem Verständnis "ehrt" man die hilfe-gewährenden mit der Solution und erhöht damit deren Reputation. Für die Freiwilligen Helfer hier - und das sind wir alle - ist das der Lohn des Aufwands und der von der Freizeit abgeknapsten Zeit um anderen unentgeltlich zu helfen. Wähle den Helfer, der Dir am ehesten zu Deinem Problem geholfen hat, und "spendiere" ihm die Solution. Wer über das selbe Problem wie Du stolpert findet dann auch seine Lösung in der Gesamtheit des jeweiligen Problem-Threads. Nur meine 0.02 Cent.

Arg. Sorry, my fault. Switching between boards and lost the language requirement within these. Thanks for this explanation.

Kurze Frage zu Deinem NZBGet Container. Nur so aus Interesse: Gibt es einen bestimmten Grund warum Du das appdata Verzeichnis im Container auf /nzbget mappst statt auf das sonst übliche /config? Vielen Dank.

Auch das hatte ich oben geschrieben - sogar mit Link zur Erläuterung.

Genau das hatte ich mehrfach oben geschrieben - sogar in meiner ersten Antwort. Importiere mit den mysql/mariadb executables. xxx-dump erzeugt wie der Name schon sagt einen Dump.

Geht das nicht mit dem mariadb executable? Einfach in der Container Konsole mit -u User -p aufrufen. Dann die beiden Zeilen aus dem Code oben. Schneller geht's nicht. Und es wurden nur Tabellen angelegt? Guck mal in die *.sql Datei. Hast vielleicht nur DDL (Data Description Language) und nicht DML (Data Manipulation Language) gesichert.

msql oder mysql? Im Übrigen: Versuchs mal mit mariadb statt mysql. Je nach Versionsstand sind das jeweils Symlinks: https://mariadb.com/kb/en/mariadb-command-line-client/

Und? Hast Du es in der Container Konsole probiert?

Die Fehlermeldung ist eindeutig. Ruf mal nur das mysql executable mit user und password in der Container Console auf. Wenn das klappt importiere einfach in der Container Console. mysql> use homeassistant; mysql> SET autocommit=0 ; source wo_auch_immer_das_im_container_gemappt_wurde.sql ; COMMIT ;

Das entspricht ~ 150 MB/s: https://docs.unraid.net/unraid-os/manual/storage-management

Ist das nur innerhalb von /mnt/user/system/ oder auch bei z.B. /mnt/disk1/ ?

Das alles ist völlig widersprüchlich. 1800 W sind im Moment weit davon entfernt sich Balkonkraftwerk zu nennen. Und wenn dann tatsächlich - ich vermute - erheblicher Überschuss produziert wird, dann soll abgeschaltet werden? Das ist doch Irrsinn.

Bei Preclear kein Problem - kann nix passieren. Mach ich z.B. zum Löschen von ausgetauschten Platten vor deren Verkauf dauernd. Aber niemals Array oder Pool Devices per USB anschließen.

Nur zur Beruhigung. Das habe ich bei allen M* Platten von Toshiba - und die sind teilweise seit mehreren Jahren in Betrieb: TOSHIBA_MG07ACA12TE_*-20230209-1124 disk9 (sdn).txt:220 Disk_Shift -O---- 100 100 000 - 1441792 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk20 (sde).txt:220 Disk_Shift -O---- 100 100 000 - 1703936 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk10 (sdt).txt:220 Disk_Shift -O---- 100 100 000 - 1179648 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk15 (sdy).txt:220 Disk_Shift -O---- 100 100 000 - 524288 TOSHIBA_MG07ACA12TE_*-20230209-1124 parity (sdj).txt:220 Disk_Shift -O---- 100 100 000 - 2228224 TOSHIBA_MG07ACA12TE_*-20230209-1124 parity2 (sdw).txt:220 Disk_Shift -O---- 100 100 000 - 1703936 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk5 (sdo).txt:220 Disk_Shift -O---- 100 100 000 - 917504 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk11 (sdz).txt:220 Disk_Shift -O---- 100 100 000 - 2228224 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk12 (sdg).txt:220 Disk_Shift -O---- 100 100 000 - 2228224 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk21 (sdk).txt:220 Disk_Shift -O---- 100 100 000 - 1966080 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk3 (sdab).txt:220 Disk_Shift -O---- 100 100 000 - 1572864 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk14 (sds).txt:220 Disk_Shift -O---- 100 100 000 - 1310720 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk16 (sdf).txt:220 Disk_Shift -O---- 100 100 000 - 1835008 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk18 (sdr).txt:220 Disk_Shift -O---- 100 100 000 - 202113039 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk1 (sdp).txt:220 Disk_Shift -O---- 100 100 000 - 262144 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk7 (sdaa).txt:220 Disk_Shift -O---- 100 100 000 - 34340868 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk22 (sdq).txt:220 Disk_Shift -O---- 100 100 000 - 1572864 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk8 (sdh).txt:220 Disk_Shift -O---- 100 100 000 - 186646531 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk13 (sdm).txt:220 Disk_Shift -O---- 100 100 000 - 1048576 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk19 (sdx).txt:220 Disk_Shift -O---- 100 100 000 - 2097152 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk2 (sdv).txt:220 Disk_Shift -O---- 100 100 000 - 655360 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk4 (sdi).txt:220 Disk_Shift -O---- 100 100 000 - 393216 TOSHIBA_MG07ACA12TE_*-20230209-1124 disk6 (sdu).txt:220 Disk_Shift -O---- 100 100 000 - 1703937

Das sind halt zwei Aufgaben die in ein Skript zu packen sind: 1.) Einen laufenden Mover erkennen (darum geht es hier gerade) und 2.) Reboot wenn kein Mover läuft (z.B. mit shutdown). Erst wenn beides gelöst ist kannst Du es in ein Skript packen welches zeitgesteuert startet. Das wäre dann mit dem User Script Plugin richtig einfach mit einem Custom Schedule zu lösen: Die Hilfe dazu findest Du im User Script Plugin selbst: