mgutt

Jo, Unraid ist der Unterbau egal Wenn das so wäre, wäre das der Jackpot, denn die Grafikkarte könnte man sogar noch verkaufen. Aber so Recht glaube ich da nicht dran.

Ok, also früher ging es nicht anders.

Ich habe noch mal intensiv gesucht. Es scheint wirklich so zu sein, dass der Vorgänger vom M920q, also dein M910q, doch keinen PCIe Slot hat. Das tut mir echt leid. Ich dachte ich hätte alles genau recherchiert, aber dann bin ich wohl doch über Bilder vom M920q gestolpert. Siehe zB hier: https://www.servethehome.com/lenovo-thinkcentre-m920-and-m920q-tiny-guide-and-review/lenovo-thinkcentre-m920q-tiny-internal-view-wifi-m2/ Demnach scheint von dem alten Modell nur der M910x über den PCIe Slot zu verfügen. Wobei es den komischerweise quasi für das selbe Geld gibt (159 €): https://www.refurbed.de/p/lenovo-thinkcentre-m910x-tiny/ Ich würde daher noch mal durchtauschen.

The Docker Engine is already running or don't you have any dockers? And a container itself does not produce any relevant overhead as processes are executed natively on the host. Which means: It's absolutelly the same running an application inside a container or on the host. But there is a major impact in security. Using the Unraid root login on an external server is kinda risky, not to say dumb. Even if you use SSH public key exchange, you finally allow the external machine to act as root user on your Unraid server. One of the reasons why I'm using the rsync container is to mount any path read-only. By that I'm able to pull all files, without being able to delete/change them, which makes it safe against ransomware attacks. Conclusion: Security > Comfort.

Das Problem ist, dass sie 2x existiert. Das darf gar nicht sein. Entscheide dich welche du behalten willst und lösch die jeweils andere. Warum ist die bitte so groß? Und sonst: Vom Prinzip kannst du das docker.img auch einfach löschen. Also beide Dateien. Das kann jederzeit neu erstellt werden und enthält keine relevanten Daten. Nach Neuerstellung einfach über Docker > Add Container die Container wieder hinzufügen.

Ja. Aber wozu solltest du den Job vom Mover machen. Dafür ist der doch da. Mover logs aktivieren, Mover starten und in Tools > syslog schauen was der Grund ist.

Steht in den Logs von dem Skript evtl etwas von Fehlern? Ich kann mir das nur mit irgendwelchen Berechtigungsfehlern erklären. Gehört die perms.txt auf der Quelle auch dem User root?

Yes heißt nicht, dass der Cache permanent genutzt wird. Also ich denke mal das ist deine Cache Einstellung des Shares.

Nein auf keinen Fall Docker starten. Erst müssen alle Dockerpfade /mnt/user lauten (erweiterte Ansicht aktivieren und alle Pfade aufklappen und sichten). Auch müssen alle Dateien auf das Array. Einfach damit dein aktuelles Problem nicht nachher alle Container zerschießt. Die Container suchen ja laut deiner aktuellen Einstellung die Dateien auf nvme und Array und nicht auf Schreibcache. Das kann böse enden, wenn da plötzlich teilweise Dateien "fehlen".

VMs nicht, weil die ja nicht mehr nutzen können als die vDisk groß ist. Stellt man Shares auf Prefer oder Yes, hat man auch kein Problem, weil dann auf das Array ausgewichen wird. Aber klar, so oder so sollte kein Container nach Docker schreiben. Dann ist halt einfach was falsch eingestellt.

Dann hast du was falsch verstanden. Wenn du Verzeichnis wählst, gibt es keine vDisk, sondern Docker schreibt seine Dateien direkt auf den Datenträger in das besagte Verzeichnis. Und es wird nicht der gesamte Cache vereinnahmt, sondern nur so viel wie die Dateien belegen. Also wenn du nicht gerade irgendwas verbockt hast, sogar weniger als bei der vDisk. Beispiel von meinem Server: # du -hs /mnt/cache/docker 12G /mnt/cache/docker Mein Docker-Verzeichnis belegt also "nur" 12GB statt 20GB. Check ich nicht. Wieso Arbeitsspeicher?! Verzeichnis vs vDisk Was ist nun besser? Natürlich Verzeichnis. Kein Stress mehr mit der Größe, weniger Belegung, weniger Overhead (weil nicht erst eine vDisk gemountet und darin Dateien geschrieben werden müssen) und es kann das Dateisystem in der vDisk nicht kaputt gehen (passiert auch gerne mal), weil es eben keine mehr gibt... Faktisch ist die vDisk also Nonsense. Um genau zu sein weiß ich nicht mal warum man bei Unraid die vDisk früher zum Standard gemacht hat. War eine blöde Idee und gehört meiner Ansicht komplett weg.

Ich denke nicht, dass man bei Folder das Dateisystem ändern kann. Dann gilt einfach das, was der Datenträger selbst hat.

Wie gesagt ist das rein technisch schon nicht möglich, weil das Mover Skript nur zwischen Pool und Array und zurück verschieben kann. Wenn wurde es auf das Array und dann zurück auf die SATA SSD verschoben. Das hätte aber zwei Mover Durchläufe gebraucht. Oder benutzt du irgendein Plugin wie Mover Tuning? Wie auch immer. Wenn appdata jetzt auf "schreibcache" liegt, muss dieser Cache ja auch beim Share appdata ausgewählt worden sein. Also beim Share den Eintrag "Select cache pool". Da sollte bei dir "schreibcache" stehen. Noch eine Möglichkeit wäre. dass du die Container bearbeitet hast und bei den Pfaden direkt /schreibcache hinterlegt ist. Ich habe da zB /cache direkt hinterlegt: Allerdings würde das erst greifen, wenn die Docker laufen und natürlich sollte man niemals versuchen seinen Cache zu leeren, wenn man solche Anpassungen gemacht hat. Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/#comment-1223263

Das sind vermutlich virtuelle Docker Laufwerke. Ich habe noch mal umgebaut: #!/bin/bash while read -r type size usage free percent path; do if [[ $percent =~ (100|9[0-9])% ]]; then logger -t Devices "Error: $path ($type) uses $usage of $size and only $free ($percent) are left!" fi done < <(df -h -B GB | tr -s ' ' | cut -d ' ' -f 1-6) Wir hatten bisher "type" ausgegeben. Für dich relevanter ist aber "path". Beispiel nun von mir: Error: /mnt/disk1 uses 17160GB of 17999GB and only 839GB (96%) are left! Error: /mnt/disk2 uses 17057GB of 17999GB and only 942GB (95%) are left! Error: /mnt/disk3 uses 16824GB of 17999GB and only 1175GB (94%) are left! Error: /mnt/disk4 uses 17232GB of 17999GB and only 767GB (96%) are left!

Wenn du alle in den selben Ordner sicherst, kann das auch nicht funktionieren. Das Skript sucht ja in dem Ordner nach dem letzten Backup. Das letzte Backup ist dann zB zufällig das vom /boot Verzeichnis. Du sicherst aber gerade irgendeinen anderen Share. Er findet nichts in dem letzten Backup was dazu passt und erstellt es komplett neu. Fazit: Die Zielverzeichnisse müssen pro Quellverzeichnis unterschiedlich sein.

Ich sichere einfach /boot auf irgendeine Disk im Array. Auch nicht die sicherste Methode, aber mein Server wird auch noch mal komplett extern gesichert.

Der Zielpfad ist "user@server:/pfad". Wie im Beispiel zu sehen. Nix "ssh " und nix "cd".

Kann es sein, dass appdata mal auf dem Schreibcache lag? Ich kann mir das nur so erklären, dass da schon die ganze Zeit der appdata Ordner auf "Schreibcache" lag. Weil der Mover kann nichts von Pool zu Pool bewegen. Schau dir mal an was in dem Ordner drin ist.

Docker und VM auf Nein gestellt? Dateien, die in Benutzung sind, können nicht verschoben werden. Von welchen Shares und stehen die auch alle auf yes?

Bei den Einstellungen ist ein Beispiel. # user-defined ssh command #alias ssh='sshpass -p "<password>" ssh -o "StrictHostKeyChecking no"' Du machst nur eben alias ssh='ssh -p 5022'

Jo, SSH geht auch. Dann solltest du aber die Schlüssel austauschen, damit keine Passwortabfrage kommt. Also auf dem Terminal musst du in der Lage sein "ssh user@server" ohne Passwort auszuführen.

Jo. Dann gehen die Hardlinks nicht. Das ist komisch, weil über NFS Hardlinks eigentlich gehen sollten.

Wenn sich Daten ändern, bricht die Schreibrate massiv ein. Also so 1 bis 30 MB/s so dann das Maximum. SMR eignet sich nur für voll machen und so lassen. Also zb Mediensammlungen.

Nö Leider nein. Die Buchse auf dem Mainboard ist proprietär. Schau genau hin. Die Lücke zwischen den Pins ist anders angeordnet.

Ja, diese Funktion ist drin, aber wie gesagt kannst du mit einem inkrementellen Backup nichts anfangen.