mgutt

Jo, das war vorher auch so.

Öffne mal die Konsole vom Container und führe das aus: mkdir /mnt/backup/BIT/test Wobei das Problem vermutlich doch was anderes ist. Und zwar steht ja da, dass rsync den Pfad "/root/"/mnt/backup/BIT/tmp_CPC2VV"" nicht erstellen kann. Ich frage mich woher das "/root/" vor dem Zielpfad herkommt. In dem eigentlichen Kommando sieht man ja nichts davon. Ich habe auch mal wie folgt getestet. /mnt/user/ in /mnt/user/isos mit Schreibrechten geändert: Und dann mit folgendem Kommando von Unraid aus problemlos kopiert (Schlüssel von Unraid selbst war natürlich im rsync-server container hinterlegt): rsync --itemize-changes --recursive --rsh='ssh -p5533' /tmp/ root@localhost:/mnt/user/isos/test Das hat problemlos funktioniert. Was ich auch komisch finde aus deinem Screenshot ist diese Schreibweise: 'root@rechnername:"/mnt/backup/BIT/tmp_CPC2VV"/' Man beachte hierbei den letzten Schrägstrich nach dem Pfad. Allerdings konnte ich es nicht provozieren, dass er dann so wie bei dir reagiert. Also so geht es problemlos: rsync --itemize-changes --recursive --rsh='ssh -p5533' /tmp/ root@localhost:"/mnt/user/isos/test"/ Oder enthält dein Rechnername evtl noch ein komisches Zeichen oder ein Leerzeichen oder so? Kannst du in BIT noch weitere Optionen hinzufügen? Dann würde ich mal -vvvvv probieren. In dem Fall gibt rsync deutlich mehr Informationen zurück wie zb den Pfad, wo die Dateien hingeschrieben werden sollen: Wenn -vvvvv gesetzt werden kann, dann probier auch mal den Usernamen "root" gegen "test" zu ersetzen, falls das "root" im Zielpfad übernommen wird, sollte das dann auch bei "test" der Fall sein, auch wenn er sich dann logischerweise nicht verbinden kann:

In dem ZIP ist die Log

Habe dir im Support Thread vom Container geantwortet. Du hast /user im Pfad vergessen.

Your target is /mnt/backup while it should be /mnt/user/backup and regarding the "no such file or directory" you need to use this fix of Back in Time: https://github.com/bit-team/backintime/issues/1253#issuecomment-1126770876

In deinem Screenshot sehe ich keinen Unterordner "Test". Den tmp... kann rsync noch erstellen, aber keine Unterordner in Unterordnern.

Dann solltest du dein Netzwerk prüfen.

Wie gesagt. Wenn du die SMR Version der WD Red hast, dann ist das dein Hauptproblem. Allerdings sollte ohne Parität der Effekt nicht so krass sein. Dann transferiert du vermutlich sehr kleine Dateien und du hast vermutlich kein SMB Multi-Channel aktiviert. Außerdem nutzt du offensichtlich den Cache nicht. Niemand hier transferiert direkt ins Array, außer er befüllt den Server das erste Mal.

Keine Plus? Dann hast du SMR und damit dein Hauptproblem gefunden. SMR sind ungeeignet für NAS. WD behauptet zwar das Gegenteil, aber du siehst ja die Wahrheit.

Dann wird es wieder schnell sein. Die Parität macht es deutlich langsamer. Faktoren habe ich oben aufgelistet. Du musst jetzt mal deine Hardware auflisten.

Das hatte ich schon mal dem Maintainer vom influx Container gesagt, aber der reagiert nicht.

Bei jedem unsauberem Shutdown wird ein Log in /boot/logs generiert. Da schauen was den Shutdown aufgehalten hat.

Dann ist das so. Viele kleine Dateien, langsame HDDs, langsame CPU,... Da gibt es mehrere Faktoren, aber Wunder darf man vom Array nicht erwarten, außer man verbaut ausschließlich SSDs. Dann hast du nur eine SSD im Cache. Dh SSD kaputt, also Docker und VM weg. Davor warnt dich das Ausrufezeichen. Entweder regelmäßig Backups machen und mit einem gewissen Verlust bei Defekt leben oder eine zweite SSD verbauen und ein RAID1 machen.

Der Dirty Page Cache reserviert keinen RAM, sondern nutzt x % vom freien RAM ohne ihn zu blockieren. Daher zeigt das Dashboard auch nichts an. Die standardmäßigen 20% oder deine eingestellten 80% beziehen sich auch nicht auf den kompletten RAM, sondern nur den, der gerade frei ist. Und Linux nimmt immer den kompletten freien RAM für das Caching. Hast du zb 6GB von 256GB in Nutzung, dann hast du 250GB frei. Stellst du 80% für den Schreibcache ein, dann nutzt Linux 200GB für den Schreibcache und 50GB für den Lesecache. Also der eingestellte Schreibcache beeinflusst auch direkt die Größe des Lesecache (50GB sind immer noch viel). Die 250GB bleiben aber jederzeit "frei", auch wenn sie gerade verwendet werden. Linux kennt also so gesehen keinen "freien" RAM, sondern benutzt immer alles. Gute Frage. Ich schlage vor, dass du während du die Datei hochlädst (ist es eigentlich eine Datei oder mehrere kleine?), im Terminal "htop" ausführst und die Prozesse beobachtest. Gibt es bei ZFS evtl weniger Prozesse? Ich tippe auf den Fuse Overhead (sshfs), der beim Kopieren auf /mnt/user entsteht. Dies lässt sich durch Aktivierung von SMB Multichannel + RSS oder durch Kopieren auf Disk Shares umgehen. Siehe auch: Nach Aktivierung von RSS gibt es dann mehrere Prozesse und die Last wird besser auf die CPU Kerne verteilt.

Existiert der Ordner /mnt/backup/Test/tmp... im Ziel? Rsync kann nicht den Hauptpfad im Ziel erstellen. Nur das was man an Ordnern darunter übertragt.

Muss ich leider widersprechen. Zumindest schaue ich immer wieder neidisch auf die privaten Leitungen internationaler Kollegen und Kunden. Sei es asiatischer Raum, Osteuropa oder Südafrika. In der Schweiz gibt es zb Anbieter, die 25G synchron anbieten und das zu vertretbaren Preisen. Deutschland ist einfach nur peinlich im internationalen Vergleich.

Hast du dir auch mal den Inhalt auf dem Cache angeschaut? Eventuell leere Ordner?!

Dateien, die in Nutzung sind, können nicht verschoben werden. Wenn ich es richtig verstanden habe, geht es sogar um eine einzelne Datei, die größer ist als der Cache selbst? Das geht schon mal gar nicht. Die Datei muss direkt auf das Array geschrieben werden.

Grottige Bewertungen bei Google. Lasst es bleiben. Ich habe den Geizhals gemeldet.

Dh Cache steht bei allen Shares auf No? Was zeigt der denn bei Location an, wenn du den Inhalt des Shares anzeigen lässt? PS welchen Sinn hat es einen Cache Pool zu verbauen, den man nicht nutzt?!

Da der Funktionsumfang vor allem durch Container geprägt ist, braucht man solange kein Update, solange es keine Lücke in Docker gibt. Es gab tatsächlich mal eine gefährliche Lücke, die es erlaubte aus einem unpreviligierten Container auszubrechen und als Root auf dem Host zu agieren: https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/ Und da unRAID kein "apt update" kennt, bleibt in so einem Fall nur unRAID zu aktualisieren. Also brav das beobachten und bei "Rot" in Panik geraten https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html Eigentlich alle gefährlichen Linux Sicherheitslücken erfordern, dass man Zugriff auf das Terminal hat. Und der einzige User, der das bei unRAID kann, ist der root und der kann ja eh schon alles. Daher ist es am wichtigsten den Zugriff auf unRAID über SSH / die GUI zu verhindern. Ist man paranoid, dann in den man dies in ein separates VLAN packt, wo man einen separaten PC ohne Internetzugang angeschlossen hat. Man muss sich einfach überlegen was wäre, wenn das oder das gehackt wird (zb der Smart TV) und was der dann alles im heimischen Netzwerk machen könnte.

Wird so gewesen sein. Du kannst auch rechts beim Cache den Inhalt anschauen. Wie auch immer: Eine SSD im Cache = alle Daten weg, die auf dem Cache liegen wenn SSD kaputt.

Darum: - Zwei Unraid Server - erster Sync lokal - zweitern Server bei Mutti oder Freund aufbauen - weitere Syncs dann inkrementell über das Internet machen

Im Unraid Terminal ausführen: 2x mit ENTER bestätigen (= als Gast anmelden) smbclient -L //localhost Diesmal deinen Usernamen angeben und mit deinem Passwort bestätigen: smbclient -L //localhost -U <username> Beispiel: Diesmal den Inhalt eines Shares anzeigen lassen: smbclient //localhost/<sharename> -U <username> -c "ls" Beispiel: Man sieht dann auch direkt die verwendete Workgroup. In Windows alle Shares des Servers anzeigen lassen: net view \\<tower> Beispiel: Und so kann man sich zB den Inhalt eines Shares anzeigen lassen (setzt aber voraus, dass der Login bereits in Windows hinterlegt ist): get-childitem \\<tower>\<sharename> Beispiel:

Dir wird nichts anderes übrig bleiben als alles zu testen. Kostenlos wäre: - RAM neu reinstecken - alle Kabel neu reinstecken - CPU neu montieren - CPU Kühler neu montieren - RAM testen - möglichst alles abklemmen und ohne gestartetes Array laufen lassen Danach von billig nach teuer. Kabel tauschen, Netzteil tauschen, Board tauschen...