Pardasus

Ich habe nun ein weiteres, wohl merkwürdiges verhalten festgestellt. Wie man auf den Screenshot sieht, sind 22GB an Daten auf dem Cache (system). Ich habe alles auf Array gestellt und den Mover gestartet. Es passiert aber nichts. Die Daten bleiben dort liegen. Auch habe ich unter Domains noch 687GB auf den Cache die auch nicht verschoben werden. In der Log-Datei kommt dazu auch keine Fehlermeldung. Man sieht das ich den Mover starte und dann passiert nichts. Als ich das System neu aufgesetzt habe, habe ich eine neue Config erstellt aber den Cache beibehalten. Ich habe das Gefühl, irgendwas mag er da nicht.

Das Verzeichnis "appdata" existiert auch im cache/appdata. @Sacred, wenn ich eine zweite cache Platte einbaue, sorgt diese für eine Redundanz des caches? Anbei einmal die Screenshots:

Ich nutze die 6.12.0 und die Daten liegen nicht im Cache, sondern auf dem Datenträger 1. Ich glaube aber, ich muss noch etwas dazu erzählen wie ich die 3 Platten ausgetauscht habe. Ausgangspunkt: 1x 2TB Parität 2x 2TB Daten (1x Daten war defekt auf der alle Daten waren, die zweite Datenplatte war leer.) Vorgehen von mir: 1. Neue 2TB Platte eingebaut und dem Array hinzugefüght. 2. Alle Daten von der Emulierten, defekten, Platte auf die neue 2TB Platte mit den unRAID Dateimanager verschoben so das die defekte leer war. 3. Die Parität und die noch heile Platte ausgebaut und dafür zwei neue Platten hinzugefügt. 4. Das System komplett neu Konfiguriert (dabei den Cache behalten). 5. Das Array ohne Parität neu erstellt und gestartet. 6. Die neue Parität Platte hinzugefügt und neu Aufbauen lassen. 7. Es ist unter "Start" alles wieder grün und sieht aus wie vorher, nur eben mit komplett neuen Platten. Könnte jetzt das Manuelle Verschieben der Daten, und das anschließende neu Konfigurieren des System sein, dass unRAID die Daten nicht mehr auf dem Zettel hat obwohl sie noch da sind? p.s.: ich habe den defekt einer der Platten zum Anlass genommen, alle auszutauschen.

Moin, ich habe vor kurzen ein unRAID Server aufgebaut mit 2TB Parität Platte und zwei 2TB Datenträgern. Dazu noch eine 1TB NVMe SSD als Cache. Nun habe ich die Parität und die Datenträger Platten komplett ausgetauscht. Dies hat alles wunderbar funktioniert und das gesamte System läuft inkl. Docker und VM. Die Paritätsprüfung ist durch und alles ist grün. Unter Freigaben sehe ich nun aber, dass die Freigabe appdata ungeschützt ist. Ebenso die Domains und system Freigabe. Als Speicherort ist das Array festgelegt. Was muss ich tun das diese Verzeichnisse wieder geschützt sind?

Die Platte ist defekt. Ich habe nun die SSDs gegen Qualitativ besser ausgetauscht. Ich bin sehr positiv überrascht, wie robust unRAID ist beim Plattentausch. Ich habe die Parität und die normalen Datenträger alle Tauschen können ohne Datenverlust. Auch die ganzen Docker und VMs waren noch da und laufen. Bin schwer begeistert. Auch wenn man sich erst mal rein arbeiten muss um zu verstehen, wie unRAID Denkt um sowas fehlerfrei durchführen zu können. An die Admin´s hier, ihr könnt den Thread löschen oder einfach stehen lassen für den nächsten 👍

Moin zusammen, ich ziehe gerade von Proxmox auf unRAID um und habe nun über die hälfte meiner System in unRAID untergebracht. Heute ist das System das erste mal über Nacht durchgelaufen und wird Produktiv verwendet. Ich habe 3x 2TB SSDs eingebaut (1x Parität, 2x Daten). Heute morgen sehe ich, dass eine der Daten Platten ein "x" vor der Bezeichnung hat. Wenn man da drauf geht kommt die Meldung "Datenträger deaktiviert, Inhalt Emuliert". Ich habe nicht das Gefühl als wäre sie defekt. Smart Test laufen sauber durch. Anbei das Log, der Platte. Ich bin noch recht neu unter unRAID, hat hier jemand eine Idee was das Problem sein könnte? Jun 26 07:14:07 HomeServer kernel: ata6: SATA max UDMA/133 abar m2048@0x5081d000 port 0x5081d380 irq 127 Jun 26 07:14:07 HomeServer kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jun 26 07:14:07 HomeServer kernel: ata6.00: ATA-11: Fanxiang S101 2TB, SN14130, max UDMA/133 Jun 26 07:14:07 HomeServer kernel: ata6.00: 4000797360 sectors, multi 1: LBA48 NCQ (depth 32), AA Jun 26 07:14:07 HomeServer kernel: ata6.00: configured for UDMA/133 Jun 26 07:14:07 HomeServer kernel: sd 7:0:0:0: [sdd] 4000797360 512-byte logical blocks: (2.05 TB/1.86 TiB) Jun 26 07:14:07 HomeServer kernel: sd 7:0:0:0: [sdd] Write Protect is off Jun 26 07:14:07 HomeServer kernel: sd 7:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Jun 26 07:14:07 HomeServer kernel: sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 26 07:14:07 HomeServer kernel: sd 7:0:0:0: [sdd] Preferred minimum I/O size 512 bytes Jun 26 07:14:07 HomeServer kernel: sdd: sdd1 Jun 26 07:14:07 HomeServer kernel: sd 7:0:0:0: [sdd] Attached SCSI disk Jun 26 07:14:26 HomeServer emhttpd: Fanxiang_S101_2TB_MX_00000000000013998 (sdd) 512 4000797360 Jun 26 07:14:26 HomeServer kernel: mdcmd (2): import 1 sdd 2048 2000397656 0 Fanxiang_S101_2TB_MX_00000000000013998 Jun 26 07:14:26 HomeServer kernel: md: import disk1: (sdd) Fanxiang_S101_2TB_MX_00000000000013998 size: 2000397656 Jun 26 07:14:26 HomeServer emhttpd: read SMART /dev/sdd Jun 26 07:14:27 HomeServer root: /usr/sbin/wsdd2 -d -4 Jun 26 07:14:27 HomeServer wsdd2[4083]: starting. Jun 26 07:14:35 HomeServer wsdd2[4083]: 'Terminated' signal received. Jun 26 07:14:35 HomeServer wsdd2[4083]: terminating. Jun 26 07:14:37 HomeServer root: /usr/sbin/wsdd2 -d -4 Jun 26 07:14:37 HomeServer wsdd2[5002]: starting. Jun 26 07:21:43 HomeServer emhttpd: spinning down /dev/sdd Jun 26 07:24:26 HomeServer emhttpd: read SMART /dev/sdd Jun 26 07:27:01 HomeServer emhttpd: read SMART /dev/sdd Jun 26 07:27:54 HomeServer emhttpd: read SMART /dev/sdd Jun 26 07:28:01 HomeServer wsdd2[5002]: 'Terminated' signal received. Jun 26 07:28:01 HomeServer wsdd2[5002]: terminating. Jun 26 07:28:03 HomeServer emhttpd: Fanxiang_S101_2TB_MX_00000000000013998 (sdd) 512 4000797360 Jun 26 07:28:03 HomeServer kernel: mdcmd (2): import 1 sdd 2048 2000397656 0 Fanxiang_S101_2TB_MX_00000000000013998 Jun 26 07:28:03 HomeServer kernel: md: import disk1: (sdd) Fanxiang_S101_2TB_MX_00000000000013998 size: 2000397656 Jun 26 07:28:03 HomeServer emhttpd: read SMART /dev/sdd Jun 26 07:28:04 HomeServer root: /usr/sbin/wsdd2 -d -4 Jun 26 07:28:04 HomeServer wsdd2[20435]: starting. Jun 26 07:32:07 HomeServer wsdd2[20435]: 'Terminated' signal received. Jun 26 07:32:07 HomeServer wsdd2[20435]: terminating. Jun 26 07:32:09 HomeServer root: /usr/sbin/wsdd2 -d -4 Jun 26 07:32:09 HomeServer wsdd2[26276]: starting.

Bitte nicht falsch verstehen, ich bin dankbar für deine Unterstützung. Aber in deiner ersten Antwort gingst du davon aus, dass das Problem der Aufruf von "mysql" außerhalb vom Container das Problem war. Dabei ist "mysql" weder innerhalb, noch von außerhalb auffindbar gewesen. Dann haben wir heraus bekommen das ich "mariadb..." eingeben muss und nicht "mysql". Da ich am Anfang aber noch damit Beschäftigt war heraus zu bekommen warum "mysql" nicht gefunden wird, hatte ich mich ehrlich gesagt nicht weiter mit deiner Lösung beschäftigt wie man Daten wieder zurückspielen kann. Hier scheint es mehrere Wege zu geben. Weg 1 (von mir nicht getestet) mysql --user="xxx" --password="xxx" mysql> use homeassistant; mysql> SET autocommit=0 ; source wo_auch_immer_das_im_container_gemappt_wurde.sql ; COMMIT ; Weg 2 mariadb-dump --user="xxx" --password="xxx" homeassistant < homeassistant.sql Ich denke, wir haben uns 1-2x missverstanden, aber am ende dann doch gemeinsam die Lösung gefunden 👍

So, nach vielen hin und her hier die Lösung: MariaDB ist quasi MySQL. Darum finde man oft im Internet Beispiele für "MySQL" welcher der MariaDB Docker Container nicht versteht. Backup einer Datenbank: mariadb-dump --user="xxx" --password="xxx" --host="192.168.178.179" homeassistant > homeassistant.sql Der "Host" ist nicht unbedingt notwendig. Hier wollte ich aber ein Backup einer bereits laufenden, externen, MariaDB machen. Importiert wird das ganze dann mit: mariadb --user="xxx" --password="xxx" homeassistant < homeassistant.sql Den Befehlt habe ich in der Console vom Docker Container ausgeführt. In meinen Beispiel geht es um eine Homeassistant Datenbank. Die Datenbank muss vorher erstellet werden.

Die frage kann ich leider nicht vollständig beantworten. Die Datei ist 1GB groß, denke da dürfte die komplette DB sein und nicht nur die Tabellen. Mittlerweile bin ich auch schlauer geworden, funktionieren tut es aber immer noch nicht. Ich gehe in die Console vom Docker-Containter "MariaDB" und erstelle mir direkt dort das Backup von der anderen Datenbank mit: mariadb-dump --user="xxx" --password="xxx" --host="192.168.178.179" homeassistant > homeassistant.sql Dies dauert auch ein paar Sekunden und raus kommt eine 1GB .sql Datei. Nun Importiere ich die local gespeicherte DB wieder mit: mariadb-dump --user="x" --password="x" homeassistant < homeassistant.sql Dies dauert aber nur 1 Sekunde und raus kommt dies: -- MariaDB dump 10.19-11.0.2-MariaDB, for debian-linux-gnu (x86_64) -- -- Host: localhost Database: homeassistant -- ------------------------------------------------------ -- Server version 11.0.2-MariaDB-1:11.0.2+maria~ubu2204 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8mb4 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; /*!40101 SET SQL_MODE=@OLD_SQL_MODE */; /*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; /*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */; -- Dump completed on 2023-06-24 20:47:38 Und es sind nur die Tabellen erstellt worden. Mysteriös....

Die Letzte Seite 😄 und ich habe vorne angefangen. Wenn ich alle bis Seite 123 gelesen hätte, wäre ich sicher ein Experte für Macinabox 😉

Ich habe nun die Lösung hier gefunden, vielen dank.

Meinst du das Offizielle Support Forum? Ich bin jetzt bei Seite 5 angekommen und sehe das geht bis 123... Ich habe es auch schon mit der Suchfunktion probiert, verwende aber wohl die falschen Suchbegriffe 😞

So, ich habe MariaDB noch mal gelöscht und neu angelegt. Dabei ein zufällig genierte Passwort von Installation Script erzeugen lassen. Nun klappte der Import.... bedingt. Es kamm keine Fehlermeldung mehr, aber er hat nur die Tabellen angelegt, nicht aber mit werten gefüllt. Das bekomme ich aber auch noch raus

Ah, ok. Jetzt kommen wir weiter. Den Befehl "mariadb" und "mariadb-dump" kennt er. Wenn ich über "mariadb-dump" aber das .sql File Importieren will, sagt er immer "Access denied for user..." wobei ich mich Problemlos über phpMyAdmin anmelden kann.

Ich habe dies immer über die unRAID Console probiert, aber auch über die Console vom MariaDB-Container sagt er mir "msql: not found". Fehlt die Anwendung vielleicht einfach im Docker?

Moin, ich wollte Macinabox ausprobieren, was auch soweit alles geklappt hat. Nun möchte die ich VM wieder löschen. Leider passiert da nichts. Was habe ich bis jetzt versucht? - AppCleaner probiert - Docker gelöscht - Scripte gelöscht - unter Domain alles gelöscht - paar mal neu gestartet Wenn ich unter VMS auf "Macinabox BigSur" gehe und sage, ich möchte es löschen. Passiert einfach nix... jemand ne Idee?

Ich lese die Fehlermeldung so, dass "mysql" im Docker Container nicht gefunden wurde. Ich habe die offizielle MariaDB Version aus dem App-Store genommen. docker exec -i MariaDB-Official mysql -{user} -{password} OCI runtime exec failed: exec failed: unable to start container process: exec: "mysql": executable file not found in $PATH: unknown Dort steht ja "executable file not found" mit bezug auf "mysql".

Moin zusammen, ich bin dabei von einem Proxmox Server auf unRAID umzuziehen. Nun ist die MariaDB dran. Die Datenbank konnte ich problemlos exportieren und liegt nun als .sql File vor. Jetzt wollte ich diese im MariaDB (unRAID Docker) wieder Importieren. Leider klappt dies nicht. Ich gebe folgendes ein: docker exec -i MariaDB-Official mysql -{user} -{password} homeassistant < /mnt/user/appdata/homeassistant.sql Als Fehlermeldung erhalte ich dies: OCI runtime exec failed: exec failed: unable to start container process: exec: "mysql": executable file not found in $PATH: unknown Hat da jemand eine Idee? Wollte es erst mit PHPmyAdmin hochladen, aber die DB ist 1GB groß und ich bekomme das PHP Upload Limit nicht erhöht.