guboehm

ok, damit könnte ich leben 🙂

hmmmm, OK. Ich muss gestehen, dass ich noch nicht ganz verstanden habe, wann man die disks direkt ansprechen soll und wann nur die shares. Wenn ich in diesem Fall die Datei(en) direkt auf eine meiner Disks schreiben würde, hätte ich aber keine Kontrolle mehr darüber, ob sie ggfs. keinen Platz mehr hat., oder? Das würde doch mit dem Schreiben in den Share umgangen werden, da sich ja dann der mover darum kümmert, alles dahin zu packen, wo noch Platz ist. Aber das erklärt ja auch nicht das gesehene Verhalten. Wie gesagt, stören tut mich das nicht wirklich, möchte es nur gerne verstehen...

Moin zusammen, ich habe zwei cache pools cache (für alles mögliche) cache_vm_docker (appdata, etc) sowie zwei shares backup primary storage: cache secondary storage: arry mover action: cache -> array appdata primary storage: cache_vm_docker secondary storage: array mover action: array -> cache_vm_docker Nun habe ich ein Skript, welches ein Backup eines SQL Containers nach /mnt/user/appdata/mssql-production/backup (cache_vm_docker) schreibt. Dann greift sich das Skript dieses Backup und verschiebt es nach /mnt/user/backup/backup-wawi (cache) So, und hier beginnt meine Verwunderung: Die Location ist offensichtlich 'cache_vm_docker', obwohl /mnt/user/backup/backup-wawi ja eigentlich 'cache' nutzen müsste. Nach dem Verschieben wird die Datei gezippt. Die tmp Datei ziBwWY9 liegt dann auch wieder ordentlich auf 'cache'. Im Prinzip stört mich das nicht, insbesondere, da ja nach dem Zippen alles da liegt, wo es hingehört. Was ich mich allerdings frage ist das so richtig, dass die Datei erstmal im Falschen cache pool landet würde der mover die Datei dann trotzdem ins Array verschieben? Hier noch das kurze Skript: #!/bin/bash # Define the path to your BackupScript.sh on the host host_script_path="/mnt/user/misc/scripts/BackupMSSQLdatabases.sql" container_script_path="/home" # define backup locations host_backup_path="/mnt/user/appdata/mssql-production/backup" backup_share="/mnt/user/backup/backup-wawi" # Specify the name or ID of your MSSQL container container_name="MS-SQL-Server-Production" docker cp "$host_script_path" "$container_name":"$container_script_path" docker exec "$container_name" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P xxxxx -i /home/BackupMSSQLdatabases.sql # move files to central backup share mv "$host_backup_path"/*.bak "$backup_share/"

ja, steht bei mir auf "Yes" und auf dem flash unter /logs fand ich das syslog, welches ich oben an gehängt habe

Die Container einzel zu stoppen hat leider nichts geändert. Den Parity Check müsste ich doch hier sehen, oder? Diesen Screenshot habe ich wenige Minuten nach dem Shutdown/Reboot gemacht, nachdem ich die Container einzeln gestoppt hatte. Das syslog hänge ich mal an. Es ist aber vom lokalen Flash gezogen. Eine remote syslog Server habe ich leider nicht. Der Shutdown war um 14:35 Die Meldung "Unclean shutdown detected" bekomme ich bei jedem shutdown, reboot, array stop - ohne, dass danach offensichtlich ein Parity Check ausgeführt wird - habe ich im Zuge meiner Fehlersuche bis jetzt ungefähr ein dutzend Male gehabt und war 100%ig reproduzierbar

Nein, hatte ich vergessen zu erwähnen - sorry... Den Docker service habe ich komplett gestoppt, ohne dass es sich gebessert hätte. Soll ich das mit "einem nach dem anderen" trotzdem nochmal machen? hmmmmm..... Es wird gar kein Parity Check ausgeführt - zumindest nicht automatisch. Nachdem ersten Auftreten von "Unclean shutdown detected" hatte ich den Parity Check mal manuell angestossen, ohne dass er Fehler gefunden häte

Moin zusammen, ich bin der Neue und komme ggfs. öfter 🙂 Bitte übt Nachsicht, wenn ich in manchen Dingen noch nicht ganz so Firm bin. Im Mone thabe ich ein recht einfaches System aufgebaut (6.12.4) mit nur einer HD und einer Parity im Array). Mein Problem, mit welchem ich nun seit einiger zeit kämpfe ist, dass die Kiste immer einen "Unclean shutdown detected", egal, ob ich reboote, einen shutdown mache oder einfach nur das Array stoppe. Anfangs hatte zu kurze Timer für die VMs (läuft nur eine Win10VM), bzw. Docker und Disk in verdacht. Diese habe ich hochgesetzt (VM: 420, Docker: 120, Disk: 420). Es nichts gebracht, ausser, dass der shutdown länger gedauert hat. Abgesehen davon, braucht weder die Windows VM, noch die Docker Container so lange um runter zu fahren. Danach habe ich den VM Manager und auch den Docker Dienst komplett abgeschaltet. Das Ergebnis, nun kommt "Unclean shutdown detected" schon nach ca. 5s. Im Syslog finde ich leider die Smoking Gun nicht. Irgendwo in einem Forenbeitrag hatte ich gelesen, dass man den Parity Check auf Debug setzten soll, und dann die Kiste rebooten soll. Danach würde man dann sehen, woran es lag. Lange Rede kurzer Sinn, ich seh' aber nüscht... Das hier ist IMHO der relevante Abschnitt aus dem Syslog: Sep 7 12:19:43 Tower-1 emhttpd: Sync filesystems... Sep 7 12:19:43 Tower-1 emhttpd: shcmd (1578): sync Sep 7 12:19:44 Tower-1 emhttpd: shcmd (1579): /usr/sbin/zfs unmount -a Sep 7 12:19:44 Tower-1 emhttpd: shcmd (1580): umount /mnt/user0 Sep 7 12:19:44 Tower-1 emhttpd: shcmd (1581): rmdir /mnt/user0 Sep 7 12:19:44 Tower-1 emhttpd: shcmd (1582): umount /mnt/user Sep 7 12:19:44 Tower-1 emhttpd: shcmd (1583): rmdir /mnt/user Sep 7 12:19:45 Tower-1 emhttpd: shcmd (1585): /usr/local/sbin/update_cron Sep 7 12:19:45 Tower-1 emhttpd: Unmounting disks... Sep 7 12:19:45 Tower-1 emhttpd: shcmd (1586): umount /mnt/disk1 Sep 7 12:19:45 Tower-1 kernel: XFS (md1p1): Unmounting Filesystem Sep 7 12:19:45 Tower-1 emhttpd: shcmd (1587): rmdir /mnt/disk1 Sep 7 12:19:45 Tower-1 kernel: mdcmd (37): stop Sep 7 12:19:45 Tower-1 kernel: md1p1: stopping Sep 7 12:19:45 Tower-1 kernel: md: unRAID driver removed Sep 7 12:19:45 Tower-1 emhttpd: shcmd (1589): /sbin/modprobe md-mod super=/boot/config/super.dat Sep 7 12:19:45 Tower-1 kernel: md: unRAID driver 2.9.27 installed Sep 7 12:19:45 Tower-1 emhttpd: Device inventory: Sep 7 12:19:45 Tower-1 emhttpd: WDC_WDS200T1R0A-68A4W0_21322D444906 (sdb) 512 3907029168 Sep 7 12:19:45 Tower-1 emhttpd: ST1000DM003-1CH162_S1DGFFP2 (sdc) 512 1953525168 Sep 7 12:19:45 Tower-1 emhttpd: JetFlash_Transcend_16GB_25UVOZGVEPV1HP08-0:0 (sda) 512 30851072 Sep 7 12:19:45 Tower-1 kernel: mdcmd (1): import 0 sdb 2048 1953513560 0 WDC_WDS200T1R0A-68A4W0_21322D444906 Sep 7 12:19:45 Tower-1 kernel: md: import disk0: (sdb) WDC_WDS200T1R0A-68A4W0_21322D444906 size: 1953513560 Sep 7 12:19:45 Tower-1 kernel: mdcmd (2): import 1 sdc 64 976762552 0 ST1000DM003-1CH162_S1DGFFP2 Sep 7 12:19:45 Tower-1 kernel: md: import disk1: (sdc) ST1000DM003-1CH162_S1DGFFP2 size: 976762552 Sep 7 12:19:45 Tower-1 kernel: mdcmd (3): import 2 Sep 7 12:19:45 Tower-1 kernel: mdcmd (4): import 3 Sep 7 12:19:45 Tower-1 kernel: mdcmd (5): import 4 Sep 7 12:19:45 Tower-1 kernel: mdcmd (6): import 5 Sep 7 12:19:45 Tower-1 kernel: mdcmd (7): import 6 Sep 7 12:19:45 Tower-1 kernel: mdcmd (8): import 7 Sep 7 12:19:45 Tower-1 kernel: mdcmd (9): import 8 Sep 7 12:19:45 Tower-1 kernel: mdcmd (10): import 9 Sep 7 12:19:45 Tower-1 kernel: mdcmd (11): import 10 Sep 7 12:19:45 Tower-1 kernel: mdcmd (12): import 11 Sep 7 12:19:45 Tower-1 kernel: mdcmd (13): import 12 Sep 7 12:19:45 Tower-1 kernel: mdcmd (14): import 13 Sep 7 12:19:45 Tower-1 kernel: mdcmd (15): import 14 Sep 7 12:19:45 Tower-1 kernel: mdcmd (16): import 15 Sep 7 12:19:45 Tower-1 kernel: mdcmd (17): import 16 Sep 7 12:19:45 Tower-1 kernel: mdcmd (18): import 17 Sep 7 12:19:45 Tower-1 kernel: mdcmd (19): import 18 Sep 7 12:19:45 Tower-1 kernel: mdcmd (20): import 19 Sep 7 12:19:45 Tower-1 kernel: mdcmd (21): import 20 Sep 7 12:19:45 Tower-1 kernel: mdcmd (22): import 21 Sep 7 12:19:45 Tower-1 kernel: mdcmd (23): import 22 Sep 7 12:19:45 Tower-1 kernel: mdcmd (24): import 23 Sep 7 12:19:45 Tower-1 kernel: mdcmd (25): import 24 Sep 7 12:19:45 Tower-1 kernel: mdcmd (26): import 25 Sep 7 12:19:45 Tower-1 kernel: mdcmd (27): import 26 Sep 7 12:19:45 Tower-1 kernel: mdcmd (28): import 27 Sep 7 12:19:45 Tower-1 kernel: mdcmd (29): import 28 Sep 7 12:19:45 Tower-1 kernel: mdcmd (30): import 29 Sep 7 12:19:45 Tower-1 kernel: md: import_slot: 29 empty Sep 7 12:19:45 Tower-1 emhttpd: import flash device: sda Sep 7 12:19:45 Tower-1 root: Submitting SysDrivers Build Sep 7 12:19:45 Tower-1 emhttpd: read SMART /dev/sdb Sep 7 12:19:45 Tower-1 emhttpd: read SMART /dev/sdc Sep 7 12:19:45 Tower-1 emhttpd: read SMART /dev/sda Sep 7 12:19:45 Tower-1 SysDrivers: SysDrivers Build Starting Sep 7 12:19:45 Tower-1 Parity Check Tuning: Unclean shutdown detected Sep 7 12:19:45 Tower-1 Parity Check Tuning: Send notification: Unclean shutdown detected: Sep 7 12:19:45 Tower-1 sSMTP[31243]: Creating SSL connection to host Sep 7 12:19:45 Tower-1 sSMTP[31243]: SSL connection using TLS_AES_256_GCM_SHA384 Kann evtl. jemand etwas Licht in mein Dunkel bringen? Besten Dank im Voraus tower-1-diagnostics-20230907-1146.zip