Hallo

ich habe heute auf internal boot umgestellt O.o

nach 5std läuft der unraid wieder (wegen unwissenheit von mir)

nun habe ich aber noch ein 'problem'

ich habe 2 ssd

waren mal ein Raid 1 zz ist auf dem Cache Device 1 noch 'alle' Daten drauf. von hier aus 'starte' ich die Docker usw.

die Daten benötige ich aber auf dem 'neuen' Daten pool. ist das möglich?!

claude gab mir erst diese info
rsync -avhP /mnt/cache/ /mnt/daten/
hier ist aber die daten platte voll gelaufen.

dann schrieb er was von

rsync -avhP --sparse --exclude='system/docker/' /mnt/cache/ /mnt/daten/

aber hier wird wohl (naja exluce halt) keine Docker mit übernommen.

da ich ca. 30 docker habe, wollte ich die nicht alle wieder neu aufsetzen usw.
da bei mir auch iOBroker usw läuft, kann ich den unraid auch nicht ewig 'offline' nehmen.

gibt es einen copy befehl den ich für diesen zweck nehmen kann?

würde mich über hilfe sehr freuen.

falls noch infos fehlen, bitte eine kurze info, dann reiche ich die nach.

3 hours ago, luckyheiko said:

da ich ca. 30 docker habe, wollte ich die nicht alle wieder neu aufsetzen usw.

der Ordner /mnt/user/system/docker ist auch nicht persistent, sprich, den zu kopieren macht wenig Sinn.

die relevanten daten liegen auf

/boot/config/plugins/dockerman/... Start Parameter deiner Dockers

/mnt/user/appdata/... die effektiven persistent Daten der Dockers

5 hours ago, luckyheiko said:

ich habe 2 ssd

Nur so eine kleine Randbemerkung (abseits Deiner Frage): Du hast angedeutet das war mal zfs. Ich sehe, daß Du als Dateisystem für einen der Pools nun btrfs gewählt hast.

Aufgrund diverser Problemmeldungen, deren Ursache sich später als btrfs herausstelle empfehle ich regelmäßige Backups (und ggf., mal zu überlegen ob es nicht vielleicht doch xfs für einen Pool mit nur einem Datenträger sein könnte).

Nicht mißverstehen: btrfs kann natürlich auch ewig super laufen, aber leider ist das eben nicht bei jedem und immer der Fall.

Noch eine Randbemerkung von mir:

14 hours ago, luckyheiko said:

nach 5std läuft der unraid wieder (wegen unwissenheit von mir)

es wäre übrigens besser für diese Community, wenn du deine Posts (auch wenn es nur Deine Unwissenheit war), nicht einfach löscht, oder wieso finde ich den "(dringend)...." Post zu der Aufteilung deiner Cache-SSDs nicht mehr?

Anderen, die ähnliche Probleme haben, könnte die Erkenntnis doch auch helfen...

zum Thema:

14 hours ago, luckyheiko said:

waren mal ein Raid 1 zz ist auf dem Cache Device 1 noch 'alle' Daten drauf. von hier aus 'starte' ich die Docker usw.

die Daten benötige ich aber auf dem 'neuen' Daten pool. ist das möglich?!

claude gab mir erst diese info
rsync -avhP /mnt/cache/ /mnt/daten/
hier ist aber die daten platte voll gelaufen.

Was hast du denn jetzt genau gemacht?

das war ein Raid1, welches Du aufgelöst hast. richtig? Warum eigentlich?

hast Du denn danach die neue "Daten"-Platte gelöscht/formatiert?

Wenn die 1TB leer wären, kann ich mir gerade nicht erklären, wieso da nicht <1TB draufpassen sollten mit deinem rsync-Befehl....

Von wann ist der Screenshot? vor/nach dem Versuch?

hier liegen ca. 750GB auf dem Cache und 500GB auf Daten. Natürlich passen die 750GB nicht zusätzlich zu 500GB auf eine 1TB Platte...

--> Vielleicht schaust Du Dir erstmal an, was alles so auf den beiden Laufwerken noch für Ordner existieren und wie viel Platz noch frei ist bzw. ob das passt, was du vor hast.

@alturismo schrieb ja schon, dass /mnt/cache/appdata (bzw. /mnt/user/appdata) DER wichtige Ordner mit deinen persistenten docker-Daten ist, den Du kopieren willst

ich hole mal etwas weiter aus...

In den Einstellungen des Docker Dienstes sind die Pfade konfiguriert:

Die Daten zu den docker-Apps liegen wie der Default-Name es vermuten lässt unter Appdata.

Unraid fasst mit dem Fuse-System alle Laufwerke unter /mnt/user zusammen, d.h. mit dieser Pfadangabe /mnt/user/appdata ist es egal, ob Dein Ordner auf /mnt/cache/appdata oder /mnt/Daten/appdata liegt (oder teils/teils), die Summe der Daten ist immer erreichbar unter /mnt/user/appdata. (doof ist nur, wenn die gleiche Datei auf mehreren Laufwerken zu finden ist, aber das sei ein anderes Thema)

Du brauchst hier also nichts ändern, wenn Du ihn verschiebst.

Im System-Ordner liegen die docker images (in einer großen Image-Daten oder im Directory-Modus) die aus dem repository entsprechend der docker Konfig runtergeladen werden.

Diese sind quasi "unwichtig", heißt, Du kannst die jederzeit löschen und neu runterladen, was ja z.B. auch beim Update eines docker-Containers gemacht wird.

Dieses System Verzeichnis brauchst Du also für deine docker nicht unbedingt verschieben oder sichern.

Du kannst Deine laufenden Docker-Container jederzeit wiederherstellen mit dem Konfigtemplate und den persistenten App-Daten.

Was Du dafür brauchst, sind die Konfigurationstemplates (quasi "die docker-Edit-Seite" in der GUI):

11 hours ago, alturismo said:

/boot/config/plugins/dockerman/... Start Parameter deiner Dockers

Hierin ist für den jeweiligen docker-container u.a. eingestellt, wo seine persistenten Userdaten liegen sollen: i.d.R. ein Ordner /mnt/user/appdata/[dockername]

DAS sind daher die wichtigen Daten die Du kopieren solltest (und von denen Du auch backups haben solltest! das Plugin "Appdata Backup" kann ich hier empfehlen)

Wenn in deinen docker-Konfigs überall /mnt/user/appdata/... steht, kannst Du das auch alles so lassen, da unraid über das fuse-Dateisystem ja alle Laufwerke unter /mnt/user zusammenfasst, d.h. es ist an dieser Stelle für den docker-container egal, ob appdata nun auf /mnt/cache oder /mnt/Daten liegt.

Das erwähne ich nur, weil, falls du hier einen docker hast, der das fuse Dateisystem umgeht (kann sinnvoll sein) und /mnt/cache/appdata/... konfiguriert sein sollte, findet er seine Daten nicht mehr, wenn du diese auf /mnt/Daten/appdata verschoben hast ;)

D.h. also in der Regel kannst Du einfach docker-Dienst stoppen, den Ordner appdata von /mnt/cache nach /mnt/Daten verschieben, und könntest jetzt den docker-Dienst wieder starten und alles würde danach wieder laufen.

ABER: Du solltest Dir vorher noch das Share anschauen/anpassen:

(iirc ist das die default-Einstellung des Shares "appdata")

Hier ist konfiguriert, auf welchem Laufwerk neue Dateien/Ordner gespeichert werden!

Wenn Du den docker-Dienst einfach nach verschieben des appdata-Ordners wieder startest, hast du zwar alle deine alten Daten auf /mnt/Daten/appdata/... aber wenn Du eine persistente Änderung in einem docker machst, landet diese Datei wieder auf /mnt/cache/appdata/.../..., also solltet Du hier vor dem Start des Dienstes auch den Zielort für neue Dateien anpassen auf "Daten" damit auch zukünftig alles an einem Ort bleibt!!

Mit dem System-Share ist es ähnlich. Du kannst den Share einfach anpassen, dass neue Dateien auf "Daten" geschrieben werden. Wenn Du jetzt den docker-Dienst stoppst und /mnt/cache/system z.B. umbenennt in /mnt/cache/system-alt (oder ihn löscht/verlierst), findet unraid ihn nicht mehr und er wird beim starten des Dienstes das docker-image/Directory unter /mnt/Daten/system neu erstellt und danach sind leider erstmal alle deine docker-container weg!

Du kannst sie dann neu hinzufügen, da deine Konfigurationstemplates (User-Templates) ja noch da sind mit den Pfadangaben etc (s.o.)

Wenn Du hier ein Template deiner docker-Container auswählst, lädt er daraus alle Einstellungen in die GUI und wenn Du unten apply drückst, lädt er das docker Image neu aus dem konfigurierten repository und startet den Container mit diesen Einstellungen.

Daher macht es keinen Sinn, den System Ordner zu sichern/kopieren/verschieben....

So kannst Du den Pool für die beiden docker-relevanten Shares appdata und system ändern. Aufwendig, aber machbar, wenn man versteht wie unraid funktioniert mit dem Fusesystem und dem primary/secondary storage in den Shares.

Basis Shell-Kommandos wie cp, mv, rsync, mkdir, rm, rmdir, ... sind hierbei natürlich auch hilfreich, da der Weg über die GUI oft ultralangsam ist...

P.S.:

wenn es Dir nur darum gehen sollte die System Shares von dem Schreibcache zu trennen auf zwei einzelne NVMEs, wäre es vielleicht auch einfacher (bzgl. der Dienste docker/VM und allem obigen), die System-Shares (system, appdata, domains, isos) so zu lassen wie sie sind und Deine übrigen shares anzupassen, so das primary-storage statt auf "cache" auf "Daten" zeigt (secondary sollte ja "Array" sein) und somit dieses neue Laufwerk als Schreibcache genutzt wird. (Wie die Pools heißen spielt ja überhaupt keine Rolle, "cache" ist nun mal historisch bedingt der default-Name für den ersten Pool - mehr nicht)

Nur als Denkanstoß...

Also am besten möglichst genau beschreiben was Du warum vorhast (und was Du ggf. schon gemacht hast)

5 hours ago, _alo_ said:

Noch eine Randbemerkung von mir:

es wäre übrigens besser für diese Community, wenn du deine Posts (auch wenn es nur Deine Unwissenheit war), nicht einfach löscht, oder wieso finde ich den "(dringend)...." Post zu der Aufteilung deiner Cache-SSDs nicht mehr?

Anderen, die ähnliche Probleme haben, könnte die Erkenntnis doch auch helfen...

zum Thema:

Was hast du denn jetzt genau gemacht?

das war ein Raid1, welches Du aufgelöst hast. richtig? Warum eigentlich?

hast Du denn danach die neue "Daten"-Platte gelöscht/formatiert?

Wenn die 1TB leer wären, kann ich mir gerade nicht erklären, wieso da nicht <1TB draufpassen sollten mit deinem rsync-Befehl....

Von wann ist der Screenshot? vor/nach dem Versuch?

hier liegen ca. 750GB auf dem Cache und 500GB auf Daten. Natürlich passen die 750GB nicht zusätzlich zu 500GB auf eine 1TB Platte...

--> Vielleicht schaust Du Dir erstmal an, was alles so auf den beiden Laufwerken noch für Ordner existieren und wie viel Platz noch frei ist bzw. ob das passt, was du vor hast.

Ja, die zwei Platten waren ein Raid 1
ich wollte auf internal boot umstellen und es wurde mir mitgeteilt das ich nicht drumherumkomme eine platte zu 'löschen'.
Deswegen habe ich eine aus dem Raid 1 rausgenommen und mit den Wizzard dann das 'internal boot' laufwerk erstellt.

und dann fingen sie an die Probleme.

und ja, ich habe den 'dringend' beitrag wieder gelöscht, da dies (für mich) so umständlich war und ich hier froh war das mit da der claude geholfen hat.

gab ja auch nicht wirklich 'fehlermeldungen'.
und er hat mir die cache.cfg und data.cfg angepasst, da die 'alte' (eine platte vom Raid1) noch von dem einem Pool erwartet worden ist und ich deswegen gar nicht mehr an meine Daten gekommen bin.

nach ändern der cache.cfg konnte ich (so wie jetzt) wenigstens wieder die Docker starten.

5 hours ago, _alo_ said:

P.S.:

wenn es Dir nur darum gehen sollte die System Shares von dem Schreibcache zu trennen auf zwei einzelne NVMEs, wäre es vielleicht auch einfacher (bzgl. der Dienste docker/VM und allem obigen), die System-Shares (system, appdata, domains, isos) so zu lassen wie sie sind und Deine übrigen shares anzupassen, so das primary-storage statt auf "cache" auf "Daten" zeigt (secondary sollte ja "Array" sein) und somit dieses neue Laufwerk als Schreibcache genutzt wird. (Wie die Pools heißen spielt ja überhaupt keine Rolle, "cache" ist nun mal historisch bedingt der default-Name für den ersten Pool - mehr nicht)

Nur als Denkanstoß...

Also am besten möglichst genau beschreiben was Du warum vorhast (und was Du ggf. schon gemacht hast)

ich wollte eigentlich nur auf internal boot umstellen. wollte nie vom raid 1 weg.
wenn ich gewusst hätte das das so ein ... ist. hätte ich alles gelassen und damit gelebt das ich alle monat halt 5 min beim start brauche

und mein ziel war es eigenlich am ende wieder ein Raid 1 mit den beiden nvme zu haben mit internal boot.

aber gerade bin ich dabei es lieber gehen zu lassen, da es ja zz läuft. auch wenn ich jetzt gar keine 'sicherheit' mehr habe.

für 'anfänger' oder mausschubser wie ich einer bin ist unraid (eigentlich) nix.

P.S.: der Daten Pool war nur so 'voll' weil ich bei Rest von 50GB abgebrochen habe und Claud meinte ich müsse
rm -rf /mnt/daten/system/docker/
zz ist es aber wieder leer

Der Ordner system/docker/docker/docker/btrfs/ ist der interne BTRFS-Storage-Driver von Docker – dort liegen alle Image-Layer als BTRFS-Subvolumes mit Snapshots/Reflinks. Auf BTRFS teilen sich viele Container-Layer denselben physischen Speicher (Copy-on-Write, z.B. dieselbe Python-Runtime in 10 verschiedenen Containern nimmt nur einmal echten Platz weg).

rsync kann diese Reflinks nicht erhalten – es kopiert jede Datei aus jedem Subvolume/Layer als eigenständige Vollkopie auf /mnt/daten (XFS, kein CoW). Das erklärt die Explosion: 7.240.345 Dateien insgesamt (!), viele davon identische Duplikate über Layer hinweg, die auf der Quelle dank BTRFS-Dedup nur einmal Platz brauchten.

Sofort handeln – diesen Ordner brauchst du gar nicht:

Das Docker-Image-Verzeichnis (system/docker/docker/docker/) ist rein ephemer – wird beim nächsten Docker-Start aus den Images neu aufgebaut. Das muss man niemals manuell migrieren.

Edited July 21Jul 21 by luckyheiko

kann man irgendwo sehen welches Template gerade für den Docker benutzt wird?


oder anders, gibt es dann auch eine 'Liste' welche Docker beim start geladen werden?!

1 hour ago, luckyheiko said:

wenn ich gewusst hätte das das so ein ... ist. hätte ich alles gelassen und damit gelebt das ich alle monat halt 5 min beim start brauche

und mein ziel war es eigenlich am ende wieder ein Raid 1 mit den beiden nvme zu haben mit internal boot.

Ah ok, kann internal boot nicht von einem RAID-Konstrukt booten? Wusste ich auch nicht....

Aber ich sehe da auch keinen Vorteil vom internal Boot. Klar, bei manchen gehen die USB-Sticks irgendwann kaputt oder sie sind langsam und das Booten dauert 5min (echt, so lange?)

Ich nutze 4€ SanDisk mini Sticks seit drei Jahren und hatte noch keinen Ausfall. Ich habe aufgrund der USV-Thematik heute beide Server mindestens einmal gebootet (meine Fehler 🤪) und mit den 1-2min kann ich gut leben....Dank USV könnte es gut sein, dass die Server jetzt ewig laufen bis was kaputt geht. Wozu booten?

54 minutes ago, luckyheiko said:

kann man irgendwo sehen welches Template gerade für den Docker benutzt wird?

im XML-Dateinamen steht der Namen deines Docker-Containers (also zwischen "my-" und ".xml")

im Reiter docker siehst du alle installierten docker Container

51 minutes ago, luckyheiko said:

gibt es dann auch eine 'Liste' welche Docker beim start geladen werden?!

unter /mnt/user/system/docker/unraid-autostart steht die Liste, welche automatisch gestartet werden, das sind die, wo der Autostart-Haken (im docker-Tab) gesetzt ist:

Hallo,

ich hatte Docker und VM gestoppt. Mittels Mover die Daten ins Array gebracht. Pool gelöscht. Dann könnte ich die Bootpartition auf dem leerem RAID anlegen. Auf dem verblieben Rest wieder den Pool angelegt. Mit Mover zurück geschoben. Docker und VM gestartet, fertig.

2 hours ago, _alo_ said:

Ah ok, kann internal boot nicht von einem RAID-Konstrukt booten? Wusste ich auch nicht....

booten dann schon, aber man kann kein raid 1 zum internal boot umwandeln (wobei ich brauchte ja die eine platte für die daten)

wenn man dann 'beide' löscht, könnte es gehen.

bei mir war das aber nicht möglich, da bei mir die Datengrab Festplatten voll sind

deswegen wollte ich den 'umweg' mit den zwei einzelnen platten machen.

und dann wieder ein raid1.

danke für die Infos.

Edited July 21Jul 21 by luckyheiko

so,
ich hoffe meine letzte frage.
habe meine daten nun auf der nvme mit dem internal boot.
und es scheint erst mal alles zu laufen.

habe dann das array gestopt und wollte die zweite platte zum pool hinzufügen, was auch prizipiell geht aber ich hab

irgendwie keine info gesehen ob das dann als raid 1 oder was auch immer dann gestartet wird.
kommt diese frage erst 'nach' dem start? oder muss ich das dem unraid vorher mitteilen? (wenn ja, wo?)

P.S. muss ich auch noch vorher an der 'zweiten' nvme ändern?! oder würde die dann (wegen raid1) dann auch zum internal boot drive + daten?!

Verstehe ich nicht. Ich dachte du hast das raid aufgelöst und Docker / Daten aufgeteilt auf die beiden nvmes….

Jetzt willst du sie wieder zusammenfassen zu einem raid?

Hast du denn vorher alles kopiert und ist die zweite auch leer?