mgutt

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.

Gibt es irgendeinen Grund, dass du das komplette Skript hier einfügst? Mach das mal bitte wieder weg und dann zeig nur das was du angepasst hast. Ansonsten könnte ich mir vorstellen, dass ein inkrementelles Skript wenig geeignet ist für dieses Vorhaben. Schließlich bleiben Unterschiede erhalten. Also jedesmal wenn du eine VM startest: Volles Backup der IMG Datei. Oder wenn Docker laufen: Alle geänderten Dateien werden addiert. Oder wenn du Dateien auf den Server hochlädst, die noch nicht auf das Array verschoben wurden: Landen ebenfalls auf der Backup NVMe. Hier mal ein Beispiel von meiner Sicherung: du -hs /mnt/cache/appdata 637G /mnt/cache/appdata du -hs /mnt/disk7/Backups/Shares/appdata 1.9T /mnt/cache/appdata Also wenn kannst du vielleicht zwei inkrementelle Backups auf die Art erhalten. Aber selbst dann könnte es voll laufen. Je nachdem wie viel sich geändert hat. Also entweder holst du eine größere Backup NVMe, damit in jedem Fall zwei Backups drauf passen, oder du machst nur einen simplen rsync: rsync --archive /mnt/cache/ /mnt/cachebtrfs/backup Vorzugsweise so, dass du vorher noch Docker und VMs stoppst, damit ein sauberes Backup erstellt wird.

Das sieht wie irgendein China Böller aus. Hol bitte ein Leicke. Da weiß man, dass es effizient ist.

Nein. Deine Docker legen die Daten im appdata Share ab. Ohne den wäre alles weg.

Warte auf die nächste Version. ZFS kommt nun offiziell.

Repariere alle Disks und Pools. Ich denke da hat sich bei einem Absturz ein Fehler im Dateisystem eingeschlichen.

Das Ergebnis eines Benchmark Tools ist nicht zwangsläufig spürbar. Es ist halt eine etwas größere Zahl. Erfahrungsgemäß 5%. Dass man die im Alltag merkt, bezweifle ich. Installiere dir 2.5G oder noch mehr. Das wäre dann auch spürbar 😉

Nutzt du den netdata Container? Der soll diese Meldungen verursachen: https://forums.unraid.net/topic/123981-anyone-know-where-these-errors-are-coming-from/ Warum das "normal" sein soll, erschließt sich mir aber nicht. Da muss doch irgendein Bug im Container sein. Sonst würde der dich die ganzen Fehler nicht verursachen. Vielleicht mal in GitHub melden.

Diese Änderung macht keinen Sinn. Entweder will man seinen Cold Storage (Medien, Backups, etc) in einem stromsparenden Array oder in einem ständig laufenden RAID. Letzteres ist der Grund warum so viele Unraid verwenden, damit sie genau davon wegkommen und du willst da hin, warum?

Nein das kann man nicht separat einstellen. Entweder hat man das docker.img und das dafür definierte Dateisystem oder man nutzt den Cache Pool und dessen Formatierung. Letzteres kann man nicht ändern, außer man macht den ganzen Pool platt und formatiert ihn neu.

Das sollte man nicht machen Und das schon gar nicht Wenn besagter Container eine Sicherheitslücke hat oder das Passwort des DMS Users gestohlen wird, sind direkt alle Container kompromittiert. Korrekt wäre es, wenn der eine paperless Unterordner auf einen Unraid Share verweist und eben nicht unterhalb von appdata liegt.

Da brauchst du vom Prinzip nicht mehr draufschauen, weil der Balken nun 1:1 die Belegung der Cache-Disk anzeigt 😉 Dementsprechend ist die Aussage von @DataCollector auch falsch. Selbst simple Dateiuploads auf den Server beeinflussen und die Belegung. Am Ende aber auch wieder nicht, denk wenn der Cache voll läuft, schreibt er ja auf das Array weiter. Daher hat man nun "unendlich" viel Platz für Docker. Korrekt wäre es daher eigentlich, wenn Unraid den Balken ausblendet, wenn man auf Verzeichnis umstellt.