_alo_

Warum, was kommt für ein Fehler und an welcher Stelle? Steht dazu irgendwas im System-Log? d.h. sie liegen jetzt auf dem "cache"-Pool auf der 1TB SSD, was du eigentlich nicht wolltest, richtig?!

Sicher? Weil du sie mangels Formatierung eben nicht (!) wiederhergestellt hast. Das zeigen die Screenshots aber nicht Ich schrieb von zwei getrennten Pools. „Cache“ist nur der defaultname des ersten Pools (weil der eben i.d.R. auch als schreib“Cache“ vorgesehen ist), mehr nicht. Du kannst aber auch mehrere Pools anlegen nicht nur einen „Cache“-Pool. 2 ssds in einem Pool ist dann sinnvoll, wenn diese identisch groß sind und du einen spiegel also Redundanz erstellen willst (raid1). Wenn du mehrere Pools hast, kannst du pro Share natürlich definieren, welcher wo liegen soll. Auch dem Docker Dienst sagt man in der konfig auf welchem Ordner er liegen soll. Das ist jetzt ein mirror aus zwei unterschiedlich großen ssds. Das kann nicht funktionieren (bzw. doch: bis max 256gb schon, was natürlich Verschwendung der großen 1TB wäre), das solltest du also besser wieder auflösen.

...und da siehst Du es ja bei beiden SSDs: "Unmountable: unsupported or no filesystem" d.h. direkt unter diesen Laufwerksangaben im Main-Tab bei den Array-Operationen sollte der Hinweis auf nötige Formatierung der Laufwerke kommen. Das wirst du einfach noch nicht gemacht haben, richtig? also ist es noch nicht zu Ende eingerichtet 😉 Ohne Dateisystem können sie nicht ins System eingebunden werden und ohne das kannst du auch nicht auf sie schreiben. Ah, jetzt verstehe ich das mit der NVMe auch: Du hast sie einfach dem Array hinzugefügt. Und Du willst die shares appdata und system dann so einrichten, dass sie ausschließlich diese NVMe nutzen sollen?! Ja, dann werden die Daten darauf auch per Parity geschützt, aber das heißt auch gleichzeitig: Höherer Stromverbrauch: die Parity-HDD läuft quasi dauerhaft, weil eigentlich immer was bei den docker Containern geschrieben wird geringere Geschwindig: der Geschwindigkeitsvorteil der NVMe ist nicht mehr gegeben, da immer paralell auf NVMe und HDD (parity) geschrieben wird. Das ganze wird also so langsam wie auf das Schreiben aufs Array sonst auch ist Wenn es dir nur um docker geht: Ich würde die 256GB NVMe als Pool konfigurieren, darauf dann die ganzen Standard-Systemshares als pool-only ablegen (so wie unraid das standardmäßig konfiguriert, wenn du mit pool und array startest). Die Daten würde ich dann per appdata-Backup-Plugin täglich aufs Array sichern, System brauchst Du nicht sichern, das lässt sich besser neu erstellen im Fehlerfall. Die Intenso 1TB als weiteren Pool dann also nur als Schreibcache bzw. für Daten, die schnell verfügbar aber ungesichert dort liegenbleiben sollen/dürfen ...

sorry, ich war noch nicht dazu gekommen, mir die Diagnostics anzuschauen.... kein Problem, also die Intenso SATA SSD. die wird in der Config mit diskSize="0" angegeben, das ist merkwürdig bzw. erklärt, wieso Du darauf nichts schreiben kannst. Hier sollte eigentlich die Größe der Partition stehen, also z.B. diskSize="976761560" wie bei meinem 1TB Cache-Pool. Mit welchem Dateisystem hast Du sie formatiert? in der Konfig steht diskFsType="auto".... xfs würde ich hier empfehlen... also denke ich, Du hast die neue SSD noch nicht richtig eingebunden, vielleicht wäre ein Screenshot von Main hier gut. das verstehe ich leider auch nicht wo ist die NVMe eingebunden? Ich kann hier keinen zweiten Pool finden... und was hat die Parität eines Pools mit einer NVMe (als Pool?) zu tun? Oder möchtest du etwa ein Array als ZFS-Konstrukt bauen?

Achso nee, k.A., das brauche ich nicht, die usv sichert nur den Server ab, alles andere angeschlossene muss nicht runtergefahren werden.

Ich habe ja mittlerweile auch diese beiden Hersteller an meinen Servern hängen und wüsste nicht wofür ich NuT brauche, das integrierte funktioniert. 🤷🏻‍♂️

Ja das wusste ich ja auch vorher aber da es sich nur um ein mini pihole handelte, dachte ich, ich probier den theoretisch einfacheren Weg mal … Nur eine 50/50 Erfolgschance bin ich von unixoiden Systemen nicht gewohnt 🤣 Es wäre halt interessant zu wissen woran es liegt… Rechte glaube ich weniger, da bei mv ja alle mitgenommen werden sollten. 🤔 Da sich nur die disk geändert hat, denke ich eher an eine Verknüpfung mit dieser - ist aber nur eine Vermutung (bin wie ihr merkt kein docker Experte)… Aber dann würden 100% nicht funktionieren… bei fehlenden Rechten allerdings auch - oder betrifft es Deiner Erfahrung nach dann nur einen Teil der Container? Tritt das Thema auch auf ohne disk-Wechsel, nur durchs hin und herschieben? Das könnte ich ja nochmal testen… Oder bewirken zwischenzeitliche Reboots ggf. Etwas? Ich Probier nochmal n bisschen 😉falls keiner hier den passenden Hinweis liefern kann.

Ein kleiner Erfahrungsbericht, vielleicht hilft er ja anderen bei ähnlichen Problemen/Fragestellungen. Ich hab gerade die Cache-SSD in meinem Backup-System (7.3.2) getauscht, nach folgendem Prozedere: docker Service stoppen (VM hab ich hier keine) alle meine Cache-only Shares (apdata/domains/system/isos/...) auf secondary-storage=array gestellt (und darauf geachtet, dass alle anderen Schreibcache-shares aktuell nicht genutzt werden) mover-action steht dann automatisch auf cache-->array mover manuell gestartet Kontrolle: /mnt/cache ist leer und alle zuvor angepassten Shares liegen auf /mnt/disk... Server runterfahren SSD umbauen Booten Problemchen 1: unraid-Oberfläche kommt nicht wieder 🤔 Grund: 🤦‍♂️auf der SSD war noch ein altes Ubuntu installiert, sie hat sich dadurch im BIOS in die boot-Reihenfolge vor den USB-Stick geschoben 🙄 Lösung: Bildschirm/Tastatur/Maus dran; STRG/ALT+DEL...DEL...BIOS: Boot-Reihenfolge ändern...SAVE+BOOT...weiter geht's 😉 unraid Oberfläche wieder da Array startet logischerweise nicht, weil cache-disk nicht gefunden werden kann dem Pool "cache" die richtige/neue SSD zuweisen Formatierung von cache anpassen von btrfs auf xfs (es ist ein single-disc cache) Array starten nicht mountbare Laufwerke formatieren (betrifft die neue SSD - ist ja noch ubuntu drauf) Cache wieder vorhanden in allen zuvor angepassten shares die mover-action umdrehen auf array-->cache Mover wieder manuell starten Kontrolle: alle betroffenen shares liegen jetzt wieder ausschließlich auf /mnt/cache (^=cache-only) optional: secondary-storage wieder auf none setzen (hat ab jetzt eh keine Auswirkungen mehr) docker service wieder aktivieren System sollte wieder laufen soweit, so klar.....eigentlich... Problem 2: Was mich aber wunderte: wieso fehlen anschließend die docker-container? Die Liste war leer. Ich habe /mnt/cache/system (docker im directory modus; storage driver= native) lediglich hin und hergeschoben und nicht neu erstellen lassen, eigentlich sollten doch alle Infos über bestehende Container vorhanden sein und beim Servicestart sollten diese dann doch auch wieder mindestens auftauchen und aufgrund von autostart=on auch direkt wieder hochkommen, oder? Ich sehe den Unterschied gerade nicht zu einem normalen reboot. Der mover sollte die Daten ja jedes Mal 1:1 verschieben🤔. Ist in den Untiefen von Docker irgendwo das Laufwerk selbst (UUID) mit den Containern verknüpft, o..ä.? Grund: ? Lösung: Docker --> add_container: das auf dem Stick gespeicherte User-Template für den Container nehmen und ihn wiederherstellen, dabei hat er das container-image neu runtergeladen (nicht schlimm aber auch seltsam - sollte er das nicht schon haben? Der Container war auf dem aktuellsten Stand), die Einstellungen sind also wiederhergestellt und Appdata ist ja auch vorhanden für die persistenten Daten. Soweit also inkl. Umbau/Mover nach 5min alles wieder funktionsfähig (war nur ein Container 😉), aber es wundert mich schon, wieso die Dockerliste leer war - hat jemand eine Erklärung? was hab ich übersehen?

dass jemand eine Festplatte für den Cache nimmt, hab ich zwar noch nie gehört, aber ok, jeder wie er mag. und warum nicht nur eine (etwas größere) NVMe für beides? wie hast du das denn konfiguriert? Screenshot vom "Main" wäre zum Start ganz gut, oder gleich die Diagnostics hier hochladen. was sagt das Log dazu? ja, kann sein und nein, ohne mehr Infos natürlich nicht ;)

Daran dachte ich auch erst aber die alten lizenzen (er hat plus ich pro) konnten ja noch dauerhaft Updates bekommen und waren nur bzgl Laufwerke beschränkt oder?

eigentlich nicht. ich bin damals mit 6.12.5(?) angefangen, deine Ansicht kenne ich so nicht, aber die Quelle der Updates hat sich m.W. nie geändert - da können andere vielleicht mehr zu sagen, die schon länger dabei sind. Ansonsten würde ich an deiner Stelle ruhig diesen Zwischenschritt machen (in der Hoffnung, dass danach das Update auf die aktuelle Version angeboten wird), kann ja nicht schaden...

seltsam, ich bin auch noch bei 6.12(.15), aber bei mir wird direkt der große Sprung angezeigt: Ich stehe mit dem Server also auch noch vor dem Update. Wie ich vorgehen werde: alle docker + Plugins auf Aktualität prüfen Backups erstellen (auf separates System), auch vom Stick Screenshot vom Main erstellen mit allen Laufwerkszuordnungen Dienste (docker/VM) stoppen automatisierte Skripte, die irgendwas am System Verändern, stoppen Array stoppen und autostart rausnehmen unraid-Update durchführen, auf Fehler/Hinweise achten nach erfolgreichem reboot schauen ob alles wieder da ist bzw. erkannt wurde und ASPM noch passt Hinweisen aus Updateprozess nachgehen Array starten und NAS Funktionalitäten prüfen docker/VM starten und Dienste prüfen sonst: rollback ...wenn ich dafür mal Zeit/Lust habe Nextcloud scheint ja generell etwas aufwendiger zu sein (AIO Setup?), hab ich nicht im Einsatz, aber hier ist vielleicht genauer zu schauen ....

ich habe hier ein ähnliches Setup (TVs & Heimkino). das neue AppleTV lohnt sich m.M.n. hierfür nicht (kann immer noch kein passthrough), ich habe 2 der Vorgänger im Kino und Wohnzimmer im Einsatz (und suche eigentlich auch noch ein drittes fürs Gästezimmer). Jellyfin läuft sonst bei meinem Sohn auch relativ gut auf einem der neueren atmos-fähigen 4k FireTV-Stick (unklar, welcher das genau ist). Ansonsten geht natürlich jeder PC-Client mit kodi/jellyfin von einem raspberryPi bis zu einem ausgewachsenen HTPC (mit madvr und gaming-GPU für dynamisches Tonmapping, wenn Du richtige Videoqualität suchst😉) ziemlich gut. Dann gibt es ja auch noch diverse Android-Medienplayer, die Netzwerkshares mounten können und quasi genau dafür gebaut wurden, schau z.B. mal bei zidoo vorbei...

Kann ich nachvollziehen, ich war anfangs auch positiv überrascht, als die N-Serie rauskam (nicht-19"-Gehäuse für viele HDDs gibt es kaum noch). Leider hatten bislang alle Varianten (für mich) Nachteile wie "falscher" Netzteil-Formfaktor, zu knapper Bauraum bzw. mangelnder Airflow, Holzoptik und Preis. Das N6 scheint da in einigen Themen besser zu sein, als die Vorgänger 👍 Das Node804 ist schon alt, hat auch seine Schwächen (da dürfte gern mal eine überarbeitete Version erscheinen), aber für meine Zwecke voll ok und vor allem oft vergleichsweise günstig. besser entkoppelt als das Node würde ich nicht sagen: du schraubst die HDDs über die gleichen Gummies an, wie beim Node804, aber in einzelne Käfige, die wiederum auf der einen Seite nur in eine Blechnase gefädelt und auf der anderen Seite verschraubt werden - das könnte(!) schon eher als beim Node rappeln, tut es aber bei mir nicht. Wobei ich dazusagen muss, dass die 6 HDDs auch größtenteils im spindown sind, da sie selten was zu tun haben. Das meiste läuft über docker/vm im "cache"-Pool oder über einen weiteren SSD-Pool, den ich fürs tägliche Arbeiten und als NAS-Schreibcache nutze. aber besser umlüftet sind sie definitiv: in der sehr offenen Front hab ich drei langsame/leise 14cm Lüfter verbaut, die seitlich direkt die Platten umpusten, diese haben ausreichend Abstand zueinander und der Airflow wird nur minimal durch die Käfige behindert, siehe Bild Mehr Volumen bedeutet nunmal einfach bessere Belüftungsmöglichkeit! Wenn man viele Platen auf engem Raum verbauen will, kommt man an den Jonsbos kaum vorbei, aber dann kann(!) es warm oder durch die Lüfter laut werden. Das Node804 (und zuvor das 304 ITX) war für mich immer ein guter Kompromiss aus Lüftung/Platz und ausreichender Anzahl HDDs. vom Platz her könnte man im 804 noch einige HDDs mehr unterbringen, aber dafür gibt es ja 3D-Drucker 😉 Das Meshify2 ist aber auch ein riesiges full-ATX-Gehäuse für eine Menge Platten:Bei mir war schnell klar, dass die Features, die ich haben wollte, nur von full-ATX Boards bereitgestellt werden, daher war dann auch schnell Schluss mit Mini-Gehäusen ... Generell sehe ich(!) aber das Thema HDD-Entkopplung bzw. Gehäuse-Rappeln durch HDDs bei unraid-Servern nicht so wirklich. Aktuell stehen beide Server bei mir im Büro/Gästezimmer und eigentlich läuft maximal nur auf einem der Mover nachts kurz (wenn überhaupt), d.h. die HDDs schlafen i.d.R. über 23,5h am Tag. Das ist aber natürlich sehr individuell und andere stört da jedes Geräusch. Bei mir sind die Platten auf jeden Fall lauter als etwaige Gehäusegeräusche, wenn sie kurz laufen... Damm kommen noch die Lüftergeräusche dazu und da sind kleine Gehäuse leider im Nachteil: wenig Volumen --> stärkere bzw. schnellere Erwärmung --> mehr Lüftungs-Durchsatz erforderlich oft nur kleine Lüfter möglich --> diese müssen schneller drehen oder es müssen mehr verbaut werden für den nötigen Durchsatz (mehr) schnell drehende Lüfter sind laut und regen ggf. zusätzlich das Gehäuse mehr zum Schwingen/Rappeln an Also immer ein Kompromiss! Auf zwei Server aufteilen macht m.M.n. (gerade vom Stromverbrauch) überhaupt keinen Sinn bei unraid, denn dafür ist es doch optimiert mit der Nutzung von Pool(s) und Array.

Das ist mein Backupserver ohne Parity 😉 aber nein, ein durch die HDDs verursachtes Rappeln hab ich da noch nicht wahrgenommen. Die HDDs sind durch die Gummies entkoppelt und die Käfige sitzen recht fest in den Schienen. Airflow ist vielleicht besser als in den engen jonsbos, aber auch nicht optimal, da die Front größtenteils geschlossen ist und die Käfige den Airflow etwas behindern. Ich habe mittlerweile vorne und hinten nen 14cm Lüfter spendiert, damit die HDD-Temperaturwarnungen beim längeren Backupjob ausbleiben. Mein Meshify2 ist dahingehend einiges besser, aber natürlich auch viel größer... so spät? P.S.: wofür Wechsel-Rahmen?