mgutt

Script is fixed. Released version 1.4 in the first post.

Das nützt nur eben Null, wenn der Intervall zB auf alle 2 Wochen steht und das erst 2 Wochen nach dem Crash durchgeführt wird. Ich halte auch rein gar nichts davon einen scrub ohne Reporting auszuführen. Dann findet scrub zwar Fehler, aber wissen tut man trotzdem nichts davon. scrub ist die Reparatur. Dazu müsste ich tatsächlich mal solche syslog-Einträge sehen. Am Ende ist mein Skript ja nur ein einfache Wort-Suche. Ergänzt man eben das entsprechende Wort.

Dann bliebe eigentlich nur noch ASPM, aber das sollte AER Fehler in den Logs auslösen: https://forums.unraid.net/topic/121146-nvme-aer-corrected-error-und-pcie-bus-error/#comment-1225469 Oder du hast mal durch einen Absturz oder harte Abschaltung das Dateisystem des Pools beschädigt und keinen scrub danach gemacht.

Nutzt du denn Stromsparmechanismen wie zb powertop? Wie gesagt würde ich mich mit dem Skript über alle syslog Fehler informieren lassen. Also Skript über User Scripts schedulen und dann den Pool neu machen, wieder befüllen und dann schauen wann / ob wieder Fehler kommen. Backups sollten natürlich so oder so gemacht werden.

Da du das häufiger erwähnt hast: Du kannst keine Daten auf den Platten löschen, in dem du einen neu erstellten unRAID Stick verwendest. Das wäre wohl auch nicht das was sich jemand wünschen würde, dessen USB Stick kaputt geht. Soll heißen du änderst durch den neuen Stick nichts, außer dass deine Änderungen auf den Einstellungsseiten verloren gehen und die bisher ausgewählten Plugins weg sind. unRAID wird übrigens bei jedem Booten neu in den RAM installiert.

Als Trick nehme ich gerne, dass ich hinter den Link noch ein "?Blabla" packe und beim nächsten Versuch ein "?Blub" usw. Oder was auch gehen sollte, ist die Dev Ansicht in Chrome einzuschalten und den Cache dort zu deaktivieren.

Kann der kein IPv4 über einen Wireshark Tunnel routen, der über IPv6 aufgebaut wurde?!

Besagte XML Dateien sichert übrigens das VM Backup Plugin.

Diese Info wird meine ich nicht auf dem USB Stick, sondern in einem Browser Cookie gespeichert. Bliebe also nur ein Feature Request zu starten.

Das steht komischerweise auch nur im Text vom Foto: Aber selbst wenn das so wäre, hätte man ja theoretisch 500 MB/s pro ASM1064 und könnte so bis zu 250 MB/s erreichen, wenn man nur 2 HDDs pro Controller anklemmt. Nur diese Theorie passt dann nicht zu dem Satz: Das klingt dann eher so, als sei die komplette Karte nur PCIe 2.

Du könntest jetzt noch mal mit dem defekten Riegel im memtest Modus neu starten. Dann sollte das dabei auch auffallen. Könnte man auch noch mal ein Foto für den Händler machen

Häh? Das File Manager Plugin erweitert die Browser GUI, mc startet man über das Terminal und Krusader ist ein Docker Container, den man ebenfalls per Browser bedient. Übrigens ist Putty überflüssig. Einfach ssh root@tower im Terminal eingeben. Oder nutzt du noch Windows 7?!

Die ist viel zu groß. Da scheint irgendwas massig Fehler zu produzieren. Mach cp /var/log/syslog /mnt/cache/isos/ und lade sie dir vom Cache runter. Also du bastelst dir einen eigenen Mount und dann schmiert dir beim Kopieren was ab? Passiert das überhaupt bei normaler Nutzung? Warum mountest du von Hand statt mit dem UD Plugin?

File Manager Plugin, oder "mc" im Terminal oder Krusader Docker installieren... Ich nutze halt einfach rsync.

Der sollte nicht mehr nötig sein. Das macht die neue Unraid Version mittlerweile automatisch. Wie gesagt mal ohne Plugins testen und alternativ auch mal ein Backup vom Stick machen und vielleicht mal mit Unraid 6.9 testen. Ich nutze nach wie vor die Version, da mich die Meldungen zu den Schwankungen davon abhalten.

squid hat heute mitgeteilt, dass es bei Github vereinzelte Probleme gab/gibt, wo die Unraid Plugins gehostet werden. Ich selbst habe noch nichts festgestellt. Keine Ahnung ob es jetzt daran liegt. Plugins landen normalerweise in /boot/config/plugins Schau mal in den Ordner wegen dem Sprachpaket und ob in dem entsprechendne Unterordner eine txz oder tgz Datei gelandet ist.

Es gibt von Syba eine SATA Karte, die durch einen ASM2806 PCIe Switch insgesamt 4x ASM1064 mit Bandbreite versorgt und die wiederum jeweils 16 SATA Ports: https://www.sybausa.com/index.php?route=product/product&product_id=1087 Diese gibt es auch als Delock Re-Brand: https://www.delock.de/produkt/90073/merkmale.html Das wäre im Gegensatz zu vielen anderen SATA-Karten, die bei mehr als 6 Ports nur mit langsamen Port Multipliern arbeiten, eine denkbare Alternative, wäre da nicht ein Haken: Der ASM1064 ist eigentlich ein PCIe 3 X1, aber laut Beschreibung nur mit PCIe 2 X1 angebunden. Und ich vermute genau deswegen kann die Karte insgesamt, also für alle 16 Ports, nur 850 MB/s liefern (oder eben 50 MB/s pro HDD bei paralleler Belastung). Denn eigentlich ist der ASM2806 mit PCIe 3.0 X2 angebunden, also grob 2000 MB/s. Und laut hier liefern 4-Port SATA Karten mit ASM1064 normalerweise bis zu 1000 MB/s (4x 250 MB/s bei parallelem Zugriff). Aber selbst wenn ich die nun auf PCIe 2 X1 halbiere, blieben ja immer noch 500 MB/s pro Controller und damit wieder ingesamt 2000 MB/s. 🤔 @DataCollector Was meinst du was bei der Karte falsch läuft? 😅 Vielleicht ist der ASM2806 auch nur mit PCIe 2 angebunden? Das wäre ja echt der totale Fail.

Ah ok. Dann ist in dem Backup natürlich auch alles was auf dem anderen Pool liegt ^^ Ändert aber nichts an meiner Fragestellung. Sind die VM-Dateien auf dem VM-Pool alle genauso vorhanden wie im Backup, nur dass sie einfach neuer sind? Dann können die aus dem Backup ignoriert werden. Die Im VM Pool sind dann ja neuer.

Nein. Im Gegenteil. Für Tests, würde ich eher mit nur einem Modul testen. Einmal das eine und einmals das andere. Das hat nichts mit Unraid zu tun, sondern ist eine Standardfunktion von Linux. Und da läuft nichts voll in dem Sinne. Jeglicher RAM, der fürs Caching verwendet wird, ist zu 100% frei für alle anderen Prozesse. Das Caching nutzt also nur freien RAM und blockiert diesen nicht. Ich muss mal blöd fragen. Aber du bist sicher, dass du die Dateien auf einen Datenträger schreibst und nicht versehentlich in den RAM oder gar auf den USB-Stick? Also der RAM bleibt laut Dashboard immer frei und der Share ist auch keine selbst gebastelte SMB Extra Config, sondern ganz normal von Unraid über die Share-Seite freigegeben?

Ist das Unraid Dashboard währenddessen offen? Dann laufen mehrere Prozess im Intervall. Diese werden erst beendet, wenn du den Browser schließt (musst ca 1 Minute warten).

This bug is still present. In the last weeks there were 2 german users, which wanted to empty their SSD through the Mover, but it fails, because the Mover can't move symlinks. Example: https://forums.unraid.net/topic/134766-cache-uncorrectable-errors/#comment-1226519

Das ist vermutlich dieser Bug: https://forums.unraid.net/bug-reports/prereleases/690-rc2-mover-file-does-not-exist-r1232/ Du hast nun zwei Optionen: - von Hand verschieben - den Ordner /mnt/user/system/docker komplett löschen Keine Angst, dann ist die Seite "Docker" erst mal komplett leer. Einfach wieder über Add Container aus dem Dropdown die Container auswählen und wieder hinzufügen. Die eigentliche Docker-Umgebung, also alles was in /mnt/user/system/docker ist vom Prinzip irrelevant. Falls du von Hand über die Kommandozeile Netzwerke erstellt hattest, musst du dir nur wieder erstellen.

Nein, ich meinte, dass du VM und Docker in Unraid abschalten sollst. Nicht nur die VMs stoppen, sondern in den Einstellungen komplett deaktivieren. Brauchst du ja nicht, weil er hat ja laut deinem Log keine einzige Datei in diesen Unterordnern überschreiben wollen. Nur das Datum der Ordner selbst will er aktualisieren, deswegen ".d..t" in der Log-Ausgabe (d = Directory, t = Timestamp). Der ist auch nicht identisch root@unraid:~# rsync -a --itemize-changes --dry-run /mnt/disks/BackupHDD/domains/ /mnt/cache/domains .d..t...... ./ cd+++++++++ Bareos-Backup/ >f+++++++++ Bareos-Backup/vdisk1.img cd+++++++++ Debian/ >f+++++++++ Debian/vdisk1.img cd+++++++++ PBS/ >f+++++++++ PBS/vdisk1.img >f+++++++++ PBS/vdisk1_bak.img cd+++++++++ Windows 10/ >f+++++++++ Windows 10/vdisk1.img cd+++++++++ edomi/ >f+++++++++ edomi/vdisk1.img cd+++++++++ pve4/ >f+++++++++ pve4/vdisk1.img Was ist denn in /mnt/cache/domains? Sind da diese ganzen .img Dateien drin und er will sie aktualisieren? Oder ist der Ordner quasi leer und er will sie neu erstellen? Wenn sie bereits da sind: Liefen die VMs als Disk1 tot war? Dh ja, dass die Dateien in /mnt/cache/domains neuer sind als in deinem Backup. In dem Fall würde ich nur kurz vergleichen, ob im Backup noch Dateien sind, die in /mnt/cache/domains fehlen. Fehlt keine Datei, würde ich den Ordner /mnt/disks/BackupHDD/domains/ schon mal komplett löschen/ignorieren. Der enthält dann ja nur veraltete Dateien.

Ein so harter Crash kann eigentlich nur physische Ursachen haben. Nicht wegen dem Absturz, sondern vor allem weil die Kiste dann komplett stromlos gemacht werden muss. Solche Sachen resultieren beispielsweise durch falsch sitzende CPU / verbogene PINs, falsch sitzender Kühler (mal die CPU Temps beobachtet?!), defektem RAM oder Netzteil bzw nicht ordentlich sitzenden Stromkabeln. Ich würde in den sauren Apfel beißen und Komponenten durchtauschen. Vielleicht ist es auch der Supergau und das Board hat eine Macke. Ohne durchtauschen aller Komponenten wirst du das nicht herausfinden.

Ich sehe das wie alturismo. Die Frage musst du durch ausprobieren und messen selbst beantworten. Im ersten Schritt könntest du aber über Main > Flash > Boot-Modus den Safe Mode auswählen und damit mal neu starten. Dann läuft die Kiste komplett ohne Plugins. Auch kann es hilfreich sein mit "htop" im Terminal die Prozess zu beobachten.