hawihoney

Ich muss Dir dringend empfehlen Dich ein wenig in Unraid einzulesen. Ich empfehle die ersten Schritte. Ein Array ohne Daten-Disk kann man nicht starten. Wieso auch? Auf Parity-Platten befinden sich i.d.R. keine verwertbaren Benutzerdaten. Diese liegen im Array ausschließlich auf Daten-Platten: https://docs.unraid.net/unraid-os/getting-started/quick-install-guide/#assigning-devices-to-the-array-and-pools Ich entnehme dem Thread hier, dass Dir der Unterschied zwischen einer Parity-Disk und einer Daten-Disk noch nicht klar ist. Fang bitte in Deinem eigenen Interesse mit der Schnelleinführung an. ... und da denkt man, man hättet schon alles supported ...

Der Unraid Cache ist ein Schreib-Cache und kein Lese-Cache. Unter anderem deshalb wurde der Begriff Cache kürzlich eliminiert. Heißt jetzt Primary-/Secondary-Storage. Mit Bordmitteln lässt sich Dein Wunsch nicht erfüllen. https://docs.unraid.net/unraid-os/release-notes/6.12.0/#share-storage-conceptual-change

Ich sehe in den syslogs nicht. Kein crash, kein error. Ich kenne nur den "plugin running anonymous" nicht. Heißt aber nichts. In solchen Fällen lautet die Empfehlung: Unraid komplett ohne Plugins (kein einziges Plugin) starten und warten.

Nach der Original Doku. In einfachen Worten: Rechner runterfahren, alte bzw. defekte Platte ausbauen, Austauschplatte einbauen, Rechner hochfahren, Array startet in diesem Fall nicht, in GUI die neue Platte im Slot der alten Platte in der Dropdown Liste auswählen, Nachfrage vor dem Arraystart abnicken, Array starten, Rekonstruktion der neuen Platte startet. Kannst direkt parallel weiter arbeiten - Performance ist nur etwas gebremst. Einzige Bedingung beim Austausch der Parity-Platte: Sie muss gleich groß oder größer als die größte Daten-Platte sein. Und auf keinen Fall formatieren. Es wird auch nix durch Unraid formatiert. Parity-Platten enthalten keine Formatierung, Die Formatierung von Daten-Platten wird beim Austausch von defekten Daten-Platen rekonstruiert. Wenn Du alles richtig gemacht hast, dann ist das die Nachfrage vor dem Arraystart: Und lesen was Unraid meldet und lesen vor dem Abnicken der Nachfrage vor dem Arraystart. Im Zweifel Doku lesen und hier fragen. Zur Doku gelangst Du über den Link in der Unraid GUI unten rechts:

Ist immer so, egal ob eine Parity- oder eine Daten-Platte ausgetauscht wird. Der alte Inhalt der defekten Platte wird aus den Werten der anderen Platten rekonstruiert - natürlich muss das immer errechnet werden - wie soll es denn auch sonst gehen. Mich störte die Aussage von Dir "warum 2x auf die Parity warten". Niemand muss 2x auf irgendetwas warten. Ich tausche gerade alle Platten in einer Unraid VM aus. Begonnen habe ich mit den beiden Parity-Platten, danach ging es mit den Daten-Platten weiter.

Das ist falsch, so was von falsch. Der Austausch einer Parity-Platte unterscheidet sich durch nichts vom Austausch einer Daten-Platte. Der Inhalt einer Daten-Platte wird aus der/den Parity-Platte(n) und den anderen Daten-Platten rekonstruiert. Der Inhalt einer Parity-Platte wird aus allen Daten-Platten und, wenn vorhanden, der zweiten Parity-Platte rekonstruiert. Wie gesagt: Alte Platte raus, neue Platte rein und machen lassen. Egal ob Daten- oder Parity-Platte.

Verstehe ich nicht. Wie in der Original Doku beschrieben: Rechner runter, alte Platte raus, neue Platte rein, Rechner hoch, in GUI die neue Platte im Slot der alten Platte in der Dropdown Liste auswählen, Nachfrage abnicken, Starten, Rekonstruktion der neuen Platte startet. Kannst direkt parallel weiter arbeiten. Bei der Rekonstruktion wird die neue Platte genau 1x komplett beschrieben und alle anderen Platten werden dabei genau 1x gelesen. Wie kommst Du auf 2x auf Parity warten? Hab im Laufe der Jahre bestimmt schon 200 Platten in Unraid auf diese Weise ausgetauscht. War nie anders. ... wo gerade zuvor eine Platte ausgefallen ist ...

Hab ich natürlich auch (Supermicro BPN-SAS2-846EL1 Backplanes). Ist aber hier in den Forums nicht unbedingt die Norm. Als alter Sack, der ich nun mal bin, verlasse ich mich da eher aufs 1. Lesen und 2. der Original Dokumentation. Ich habe Deine Liste auch nicht ganz verstanden. Warum empfiehlt man einer Person, die Ausfallsicherheit in Form von Parity-Platten gewählt hat, auf diese Ausfallsicherheit während des Syncs zu verzichten? Klar, Du weist darauf hin, aber wer eine solche Frage stellt ist kein erfahrener Unraider. Dem würde ich immer den sicheren Weg empfehlen. Wer mehr Erfahrung hat, kann dann natürlich über die Konsequenzen selbst entscheiden. Das sehe ich hier noch nicht.

Hier wird der offizielle Weg beschrieben. Ist ganz einfach: https://docs.unraid.net/unraid-os/manual/storage-management/#normal-replacement

ata/sata im syslog bedeutet meist Motherboard. Hängt ein HBA dazwischen, dann steht dort meist scsi/ata.

99:100 (nobody:users). Ist bei den Containern aus dem Unraid Store meist schon berücksichtigt. Z.B. so oder so ähnlich: Bei anderen Containern gibt es aber so gut wie immer einen entsprechenden Mechanismus.

Ohne das von Dir modifizierte Script, oder einen Link auf das von Dir 1:1 eingefügte Script, wird Dir vermutlich niemand helfen können. Das offizielle Format für ein Device Skript findest Du im ersten Beitrag in diesem Thread:

Nein, nein. Du formatierst i.d.R. nix selber. Die Fehlermeldungen von Unraid genau lesen, die Hilfe '?' einschalten und auch diese lesen. Im Zweifel hier fragen. Meine persönliche Meinung: Finger weg von den Youtube Videos (ausgenommen SpaceInvaderOne). Denn es ist nicht garantiert, dass alle diese Nasen Unraid verstanden haben. Es gibt nichts, was nicht im Unraid Forum (englisch oder deutsch) geklärt werden kann. Hier findest Du die Developer, Community Developer und freiwillige Helfer mit teilweise vielen Jahren Erfahrung. Diese Unsupported Filesystem Meldungen kenne ich hier aus dem Forum eigentlich nur nach harten Abstürzen (größtenteils BTRFS Pools). Ansonsten habe ich keinen Schimmer und kann nur auf Hardware, z.B. Verkabelung, tippen.

Die Kardinalfrage ist aber, war sie beim Formatieren im Array oder nicht. Wenn ja, dann wurde die Formatierung dieser Platte bit für bit auch in die Parity gespiegelt. Die Platte ist dann formatiert, leer und kann auch nicht mehr mit den alten Inhalten emuliert werden.

Und das verwirrt mich jetzt. Wenn Du sagst, dass die alte und vor Dir formatierte Platte wieder im parity-geschützten Array ist, und wenn dann alle Platten im Array grün sind (nicht emuliert), und die Inhalte der alten Platte noch vorhanden sind (auf /mnt/diskx/ prüfen), dann hast Du etwas anderes gemacht als oben beschrieben.

Das ist falsch. Da wird nix formatiert. Wenn eine Platte im parity-geschützten Array defekt ist dann wird sie von Unraid emuliert. Dann stoppt man das Array, fährt den Rechner runter, baut die alte Platte aus, baut die neue Platte ein, startet den Rechner, wählt in der GUI in der Dropdownliste des Slots der alten Platte die neue Platte. Unraid will dann eine Bestätigung beim Start des Arrays. Dann wird die neue Platte komplett mit jedem Bit der alten Platte beschrieben. Der alte Inhalt beinhaltet ja bereits die Formatierung der alten Platte. Deshalb wird beim Rekonstruieren nicht formatiert. Wenn man selbst formatiert ist alles verloren. Die Warn-Hinweise weisen auch darauf hin. Bitte lies Dir in Deinem eigenen Interesse meinen Link oben durch. Ich entnehme Deinen Aussagen, dass Dir noch nicht klar ist wie das Unraid Array und die Parity funktionieren. Wenn Du die alte Platte formatieren willst um sie dann Unraid wieder als Neu zu verkaufen, dann darfst Du das nicht im laufenden Array machen. Die Platte muss dann außerhalb des Arrays formatiert werden (Stichwort: Unassigned Devices). Also: Wie bist Du GENAU vorgegangen?

Wenn die Daten-Platte mit aktiver Parity-Platte im Array formatiert wurde, dann ist die Formatierung auch in der Parity abgebildet worden. Da kann man nix mehr wiederherstellen. Alle Änderungen an Daten-Platten im Array werden in Echtzeit zusätzlich in der Parity-Platte durchgeführt. Ggfs. könntest Du noch versuchen Daten aus der Daten-Platte zu rekonstruieren. Recovery Werkzeuge könnten da vielleicht noch etwas retten. Mit denen kenne ich mich aber nicht aus. Da müsste dann jemand anderes helfen. https://docs.unraid.net/legacy/FAQ/Parity/#how-parity-works

Nein, bitte nicht. Deine Frage wurde ja beantwortet:

Weiß ich nicht. Das sieht bei mir im Linuxserver.IO Container so aus. Da der Homeassistant Container bestimmt schon 200 mal ohne Probleme neu gestartet wurde, sehe ich da keine Probleme. Reboots kommen hier nur beim Unraid Update vor - auch das war bisher kein Problem - dafür gibt's ja die serial. Aber wer fährt schon seinen Homeassistant Server für Stunden runter? Meine Variante könnte ich noch optimieren (s. oben) aber es läuft, so oder so.

Anderes Thema - hier geht es nicht um NGINX. Mach einen eigenen Thread auf.

Aber so was von. Poste mal diagnostics. So sieht das aus: [...] ata4.00: ATA-11: ST4000NE001-**** [...] ata5.00: ATA-11: ST4000NE001-**** [...]

Stimmt nicht. Bridging ist bei Dir on:

Fehler ist eindeutig. Release Notes zu 6.12.4-6 abarbeiten: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

Warum HA nicht als Docker Container. Es gibt nur ganz wenige Situationen in denen VMs für HA notwendig werden: Unsere Zigbee Devices am Conbee II Stick im HA Container. Jede Nacht wird der HA Container über das User Script Plugin runter gefahren, gesichert und wieder hoch gefahren: ... ... #!/bin/bash #arrayStarted=true #backgroundOnly=true #clearLog=true #noParity=true docker stop homeassistant rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/homeassistant/ /mnt/disk1/Backup/Tower/system/appdata/homeassistant/ docker start homeassistant

Bei mir natürlich nicht. Wie gesagt, solche Fehler gab und gibt es hier nicht. Parity Check läuft hier nur alle 3-6 Monate und findet grundsätzlich NULL Fehler. Wenn meine Systeme aber so "wackelig" wären wie ich hier von Euren lese, dann würde ich es wahrscheinlich auch regelmäßiger machen.