hawihoney

Bitte lies Dich dringend ein wenig ein. Wir bewegen uns hier bei 0.0. Den Link findest Du oben in meinem Post. /mnt/disk1/ in meinem Beispiel ist die Antwort auf Deine Frage zum Kopieren von der Synology auf das Unraid Array. In dem Beispiel ist /mnt/disk1/ bzw. /mnt/user/ das Ziel und nicht die Quelle (rsync Quelle Ziel). Du musst das natürlich an Deine Bedürfnisse anpassen. Wenn Du über Backup redest, dann ist das natürlich anders herum. Dann wird z.B. /mnt/user/ zur Quelle. Aber Achtung: Docker Container bzw. VMs sichert man nicht einfach so mitten im Betrieb. Das erfordert eine andere Vorgehensweise. Für Deinen Start ohne Docker Container und ohne VMs kannst Du getrost von /mnt/user/ auf die externe Platte kopieren. /mnt/user/ enthält, wenn User Shares aktiviert sind, alle Wurzelverzeichnisse über alle Datenplatten hinweg. Zudem werden, wenn eingerichtet, die auf dem Schreib-Cache (/mnt/cache/) liegenden neuen Dateien und Ordner ebenfalls hier abgebildet. Kannst also zunächst getrost mit /mnt/user/ arbeiten. /mnt/user0/ enthält die aggregierten Wurzelverzeichnisse aller Datenplatten ohne den Inhalt des Schreib-Caches. /mnt/rootshare/ ignorier den erst einmal. So jetzt bist Du erstmal dran mit Lesen. Und für weitere Nachfragen bitte einen Screenshot der Hauptseite von Unraid posten.

Nachtrag: Hast Du das mit Unassigned Devices gemountet? Würde ich jedenfalls empfehlen. Dann könntest Du das wie folgt übertragen: #!/bin/bash #arrayStarted=true #backgroundOnly=true #clearLog=true #noParity=true # Nur ein Beispiel, Ordner müssen angepasst werden (remotes kommt vom Unassigned Devices plugin) # Zielordner muss vorher existieren # Achte auf die / # Wenn alles auf eine einzelne Disk übertragen werden soll (z.B. disk1) (z.B. Quell- und Zielordner heissen gleich z.B. Tralala) # rsync -avPX "/mnt/remotes/192.168.178.101_disk1/Tralala/" "/mnt/disk1/Tralala/" # Wenn über mehrere Disks hinweg in einen User Share übertragen werden soll # rsync -avPX "/mnt/remotes/192.168.178.101_disk1/Tralala/" "/mnt/user/Tralala/"

Ich fange mal an: Zunächst würde ich empfehlen die FAQs von @ich777, @mgutt, etc hier durchzulesen: Verzeichnisse unter /mnt /mnt/addons/ --> Für eigene Mountpoints. Z.B. rclone, etc /mnt/disk1/ --> Erste Datenplatte /mnt/disk2/ --> Zweite Datenplatte /mnt/disks/ --> Unassigned Devices plugin. Z.B. externe USB Devices /mnt/remotes/ --> Unassigned Devices plugin. Z.B. entfernte SMB/NFS Verbindungen /mnt/user/ --> User Share. Wenn aktiviert werden hier alle Wurzelverzeichnisse über alle Datenplatten hinweg angezeigt Standard-Shares appdata --> Speicherort für die einzelnen Docker Container i.d.R. pro Container ein Ordner domains --> Bei Nutzung von VMs Speicherplatz für die Images der VMs isos --> Ablage für ISO Dateien die z.B. für VMs benötigt werden oder die mit dem Unassigned Devices Plugin gemounted werden sollen system/docker --> Bei der Nutzung von Docker Containern hier das Docker Subsystem Verzeichnis bzw. das Image system/libvirt --> Bei Nutzung von VMs Ablage des VM Subsystems Einstellungen für obige Verzeichnisse unter Einstellungen -> Docker bzw. Einstellungen -> VM Was ist wichtig? Zunächst einmal alles außer system/docker und system/libvirt - diese kann man wieder rekonstruieren. Hinzu kommt dringend eine Sicherung des Unraid Lizenz Sticks unter Flash -> Backup. Damit hast Du dann auch eine Sicherung der Lizenzdatei sowie der Docker Container Konfigurationen (XML Dateien).

Recht herzlichen Dank Euch beiden. Ich würde gerne Euch beiden die Solution zuweisen, muss mich aber für einen entscheiden. Du hast schon eine Solution, @Milongero noch nicht - und er war zuerst. Here we go. Vielen Dank nochmals.

Danke. Also so? /appdata/ /domains/ /isos/ /system/docker/ /system/libvirt/ Könntest Du mir noch die Standard Export und Security im SMB Block der o.g. durchgeben, dann baue ich das bei mir um.

Ich habe ein altes System dessen Standard-Shares (appdata, domains, isos, system) nicht dem Standard entsprechen. 1.) Wie lauten die Standard-Berechtigungen und Cache-Einstellung für diese? 2.) Was ist der vorgesehene Inhalt? appdata, domains und isos ist eigentlich klar. Kommt in systems das Docker Verzeichnis? Und wo landet die libvirt.img? Vielen Dank.

Ja, da hat halt jeder andere Anforderungen. Um 04:00 passiert bei uns nicht viel - um nicht zu sagen: nix. Von 01:00-04:00 Plex Maintenance, von 04:00-06:00 Unraid Maintenance.

Preclear ist völlig überflüssig. Das macht Unraid selbst. Aber ich denke wir können es an dieser Stelle auch gut sein lassen. Wir drehen uns im Kreis. Du hast ein ganz bestimmtes Einsatz-Szenario skizziert welches Unraid derzeit im Array nicht bietet - aber in den Pools (ab 6.12). Unraid ist wie jedes Produkt ein Angebot. Man hat als potentieller Nutzer dann wie immer mehrere Möglichkeiten. a.) Man zieht weiter b.) Man passt seine Wünsche-Arbeitsweise an das Produkt an c.) Man wartet. In diesem konkreten Fall bringt es noch nicht mal was einen Feature-Request zu initiieren denn was Du schreibst wird sicherlich auf der traditionell von Limetech nicht kommunizierten Roadmap stehen. Nachtrag: Die volle ZFS Integration in Unraid wird laut Announcement auf zwei Release ausgedehnt. Eine Mini-Roadmap ohne Terminangabe hätten wir dann schon mal ...

Natürlich, im Array (ohne TRIM) und in Pools (ab 6.12 mit dem heißgeliebten TRIM). Ansonsten definiere "korrekt":

Es gibt kein BTRFS-Array oder XFS-Array. Limetechs Array Implementierung erlaubt im Array gemischte Dateisysteme.

Das ist falsch. Steht im Announcement:

Nein. Limetech hat sich noch nie in ein zeitliches Raster pressen lassen. Wenn 6.12 fertig ist, dann ist es fertig.

Wieso nicht? Das Array ist bei mir immer der erste Schritt zum kompletten Backup. Nachts wird mit einem dutzend Scripte automatisiert ins Array gesichert. Dabei werden z.B. Container kurzfristig runtergefahren und wieder hochgefahren. Tagsüber wird dann vom Array auf langsame externe Systeme gesichert - dabei muss nix mehr gestoppt werden. Dadurch ist die Downtime auf das Minimum reduziert.

Na ja, dann hatte ich halt eine 100 % Trefferquote bei zwei Stromausfällen (der Elektriker meinte noch, da passiert nix: Peng). Beides mal musste mein BTRFS Mirror im Cache Pool komplett neu aufgebaut werden.

Du scherzt, oder? Was soll denn eine SSD in einem x-disk Unraid Array bestehend aus Harddisks. Das ist die schlechteste aller Lösungen. Die meisten hier nutzen ein stromsparendes Unraid Array (RAID-4 mit P+Q Parity) bestehend aus günstigen Harddisks als Cold-Storage und nehmen dafür die reduzierte Performance in Kauf. Die Pools sind dann für die weiteren Unraid Subsysteme wie Docker, KVM, Schreib-Cache, etc. vorgesehen. In diese Hot-Storages wandern dann teurere Disks mit erheblich besserer Performance. Wenn Du allerdings immer die beste Performance benötigst oder der Strompreis kein Thema ist oder Disk Preise kein Thema sind, ja dann hält niemand Dich davon ab ein SSD Array zu betreiben. Das ist hier aber eher nicht so oft vertreten. Denn die Kernfunktion von Unraid war und ist das Array.

Das genau meine ich doch. Ein Dateisystem muss mit einem Crash - egal ob durch Strom oder etwas anderes - klar kommen. Das kommt BTRFS einfach nicht. Ich hatte Ende 2021 zwei selbst verschuldete Abstürze. Beide Male hat der BTRFS Mirror Pool (2x NVMe M.2) nicht überlebt und jedes mal durfte ich manuell reparieren und sogar den Rechner aufschrauben um an die M.2 Riegel zu kommen. Zu dem Zeitpunkt habe ich alles was BTRFS im Namen hat eliminiert. Ob ich jetzt auf ZFS springe oder nicht weiß ich noch nicht. BTRFS lasse ich aber auf jeden Fall links liegen. Das ist bei mir verbrannte Erde.

1.) RAID5/6 Systeme mit BTRFS sind noch nicht ausgereift. Single Device FS z.B. im Array mag kein Thema sein. Ein Multi-Device BTRFS Pool käme mir aber nicht ins Haus - auch wenn es ein angeblich fertiges BTRFS RAID-1 ist: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices Als persönliche Anmerkung hierzu noch Folgendes. Wenn in einem RAID Verbund aus zwei Platten (z.B. der typische Unraid Cache) eine Platte ausfällt, dann geht das normalerweise so: (Stoppen), Platte austauschen, (Starten), Sync, fertig. Bei BTRFS kommt noch dazu, dass unter Volllast die verbliebene gesunde Platte mit den Metadaten rumspielt. Das sind bei BTRFS somit zwei Volllast Szenarien beim Ausfall einer Platte statt nur einem bei anderen RAID Systemen. Ich habe das einmal erlebt und war weg. Das mag sich vielleicht geändert haben, ich glaube das aber nicht. Jeder Sync ist IMHO eine kritische Situation. Bei BTRFS genehmigt man sich zwei davon. Ich kann nicht verstehen, dass BTRFS allen Ernstes für solche Szenarien eingesetzt wird. Wie kommst Du darauf? Im Gegenteil. Laut der oben verlinkten Status Seite vom BTRFS Team gibt es auch bei SSDs die sich zwischen 50 % und 100 % ihres Lebenszyklus befinden massive Probleme durch die Write Amplication von BTRFS und der Metadaten Duplizierung. Auch hier ist XFS unverdächtig. Als interessierter Nutzer verfolge ich die Entwicklung beider FS im Kernel und auch außerhalb. Meiner bescheidenen persönlichen Meinung nach verfolgen beide Fraktionen unterschiedliche Entwicklungsansätze. M.M.n. haut das BTRFS Team alle Features gleichzeitig raus und beginnt dann mit dem Fixen. Das XFS Team setzt einzelne kleine Schritte als Ziel und macht sie fertig. Erst dann kommen sie ans Licht und das nächste Ziel wird ausgerufen. Nur meine 0.02 Cent. Jeder kann machen was er will, aber guck Dir mal die hunderte Fehlermeldungen an. Es ist fast immer der BTRFS Cache (nach einem Crash oder Stromabriss o.ä.).

Mache ich auch. Ich nutze hierzu ein Skript welches ich mal hier im Forum gefunden habe. Das habe ich in ein User Script gepackt und es sichert 1x die Woche ins Array:

Keine Ahnung, kenne ZFS nicht. Aber wenn man ZFS per Hand mounten kann, kann man das nicht per Hand unmounten?

Das würde ich nicht machen. Unraid und Unassigned Devices haben extra dafür /mnt/addons/ geschaffen. Es ist nämlich nicht garantiert das Unraid Dir das unter /mnt/ nicht mal weglöscht.

Das sind keine 36 TB Parity sondern 2x 18 TB Parity. Du hast das Parity Konzept von Unraid nicht verstanden. Bitte schau Dir das in den deutschen FAQs an:

Achtung: Parity 2 wird u.a. aus Parity 1 berechnet. Parity 1 und Parity 2 haben unterschiedliche Inhalte. Ich bin mir nicht sicher ob "New config" bei Parity 2 ohne Parity 1 so einfach geht. M.E. kann er mit einer einzelnen Parity 1 (18 TB) beginnen und die Parity durch "New config" neu aufbauen lassen. Der Prozess wäre allerdings ungeschützt und erfordert Backup der wichtigen Daten.

Klar. Du müsstest die zweite 18 TB für Parity 1 verwenden.

Du kannst keine 18 TB Daten-Platte in ein Array aufnehmen wenn eine der beiden Parity-Platten nur 8 TB groß ist. Parity-Platten müssen immer größer oder gleich der größten Daten-Platte sein. Das liegt in der Natur der Parity-Berechnung. https://wiki.unraid.net/Articles/Getting_Started#Assigning_Devices_to_the_Array_and_Pool.28s.29

"Normale" User müssen sich zu 99,99% nicht mit dem "Linux-Weg" beschäftigen. (Sym)links sind nun wirklich nicht erforderlich - egal ob im Host oder im Container. Es ist besser die von Unraid oder, in diesem Fall, Docker bereitgestellten Mechanismen zu nutzen. Zu den Mechanismen gehören auch Plugins wie Unassigned Devices. Bei Nutzung dieser Mechanismen und Tools ist garantiert, dass Unraid Spezialitäten wie User, Gruppen, Rechte etc. korrekt durchgezogen werden.