frank80 Posted January 29, 2023 Share Posted January 29, 2023 Hallo liebes Forum, ich brauche mal eure Hilfe. Fix Common Problems hatte mir gestern eine rote Fehlermeldung angezeigt. Unable to write to disk1 Ich glaube, es handelt sich um 2 vdisk Dateien. root@unraid:/mnt/user/06_Backup/11_ProxmoxBackupServer/Debian# ls -lh total 4.0K -rwxrwxrwx 1 nobody users 1.0T Feb 27 2022 vdisk2.img* ----------- root@unraid:/mnt/user/06_Backup/11_ProxmoxBackupServer/PBS# ls -lh total 337G -rwxrwxrwx 1 root users 1.0T Jan 26 01:50 vdisk2.img* Die VM´s habe ich gesichert und die vdisks könnte man löschen. Kann mir jemand sagen, wie ich das Problem lösen kann? Gruß Frank Quote Link to comment
mgutt Posted January 29, 2023 Share Posted January 29, 2023 Nun ist sie denn voll oder kaputt oder was?! Wenn die Dateien gelöscht werden können, warum löschst du sie dann nicht?! Und warum ist deine Vdisk 1TB groß?!?! Quote Link to comment
frank80 Posted January 29, 2023 Author Share Posted January 29, 2023 Hallo mgutt, Voll auf keinen Fall, ich habe noch über 6 TB frei. root@unraid:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 16G 1.1G 15G 7% / tmpfs 32M 848K 32M 3% /run /dev/sda1 29G 3.7G 25G 13% /boot overlay 16G 1.1G 15G 7% /lib/firmware overlay 16G 1.1G 15G 7% /lib/modules devtmpfs 8.0M 0 8.0M 0% /dev tmpfs 16G 0 16G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 128M 684K 128M 1% /var/log tmpfs 1.0M 0 1.0M 0% /mnt/disks tmpfs 1.0M 0 1.0M 0% /mnt/remotes tmpfs 1.0M 0 1.0M 0% /mnt/rootshare /dev/md1 15T 8.1T 6.5T 56% /mnt/disk1 /dev/nvme0n1p1 932G 67G 865G 8% /mnt/cache /dev/sdb1 472G 86G 380G 19% /mnt/vm shfs 15T 8.1T 6.5T 56% /mnt/user0 shfs 15T 8.1T 6.5T 56% /mnt/user /dev/sdg1 932G 158G 774G 17% /mnt/disks/PBS-Backup /dev/loop2 30G 17G 13G 57% /var/lib/docker /dev/loop3 1.0G 5.0M 904M 1% /etc/libvirt tmpfs 3.2G 0 3.2G 0% /run/user/0 root@unraid:~# Löschen würde ich gerne, die vdisk´s sind halt Read-only. root@unraid:/mnt/user/06_Backup# rm -r 11_ProxmoxBackupServer rm: cannot remove '11_ProxmoxBackupServer/Debian/vdisk2.img': Read-only file system rm: cannot remove '11_ProxmoxBackupServer/PBS/vdisk2.img': Read-only file system root@unraid:/mnt/user/06_Backup# 1 hour ago, mgutt said: Und warum ist deine Vdisk 1TB groß?!?! Ich habe eine VM mit Proxmox Backup Server für meine Proxmox VE Server. Da meine PVE`s auch je 1 TB haben und ich noch genug TB´s habe, warum nicht? Gruß Frank Quote Link to comment
mgutt Posted January 29, 2023 Share Posted January 29, 2023 19 minutes ago, frank80 said: Löschen würde ich gerne, die vdisk´s sind halt Read-only. Dann ist vermutlich das Dateisystem hinüber. Klick mal auf das Disk Icon. Dann zeigt er die Logs zu der Disk an oder halt Tools > Syslog nach BTRFS Fehlern suchen. Jedenfalls wäre der erste Schritt ein Backup zu machen. Dann auf die Disk klicken und eine Reparatur versuchen (scrub). Ist dir der Server mal abgeschmiert / hart ausgeschaltet? BTRFS ist da was empfindlich. Quote Link to comment
frank80 Posted January 30, 2023 Author Share Posted January 30, 2023 Hallo mgutt, 20 hours ago, mgutt said: Dann ist vermutlich das Dateisystem hinüber Das befürchte ich auch 😩 Hier das Log Spoiler Jan 29 13:24:30 unraid kernel: ata4: SATA max UDMA/133 abar m2048@0x51535000 port 0x51535280 irq 128 Jan 29 13:24:30 unraid kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jan 29 13:24:30 unraid kernel: ata4.00: ATA-10: TOSHIBA MG08ACA16TE, 0102, max UDMA/133 Jan 29 13:24:30 unraid kernel: ata4.00: 31251759104 sectors, multi 16: LBA48 NCQ (depth 32), AA Jan 29 13:24:30 unraid kernel: ata4.00: Features: NCQ-prio Jan 29 13:24:30 unraid kernel: ata4.00: configured for UDMA/133 Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] 31251759104 512-byte logical blocks: (16.0 TB/14.6 TiB) Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] 4096-byte physical blocks Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Write Protect is off Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00 Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Preferred minimum I/O size 4096 bytes Jan 29 13:24:30 unraid kernel: sde: sde1 Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Attached SCSI disk Jan 29 13:24:30 unraid kernel: BTRFS: device fsid 0c6db0b0-7bd0-48bd-890b-a9aab341325f devid 1 transid 203797 /dev/sde1 scanned by udevd (687) Jan 29 13:26:43 unraid emhttpd: TOSHIBA_MG08ACA16TE_91T0A2J8FVGG (sde) 512 31251759104 Jan 29 13:26:43 unraid kernel: mdcmd (2): import 1 sde 64 15625879500 0 TOSHIBA_MG08ACA16TE_91T0A2J8FVGG Jan 29 13:26:43 unraid kernel: md: import disk1: (sde) TOSHIBA_MG08ACA16TE_91T0A2J8FVGG size: 15625879500 Jan 29 13:26:43 unraid emhttpd: read SMART /dev/sde Jan 29 13:44:42 unraid emhttpd: spinning down /dev/sde Jan 29 13:57:01 unraid emhttpd: read SMART /dev/sde Jan 29 14:12:14 unraid emhttpd: spinning down /dev/sde Jan 29 14:23:30 unraid emhttpd: read SMART /dev/sde Jan 29 14:38:31 unraid emhttpd: spinning down /dev/sde Jan 29 15:00:01 unraid emhttpd: read SMART /dev/sde Jan 29 15:16:02 unraid emhttpd: spinning down /dev/sde Jan 29 15:33:06 unraid emhttpd: read SMART /dev/sde Jan 29 15:48:07 unraid emhttpd: spinning down /dev/sde Jan 29 17:04:32 unraid emhttpd: read SMART /dev/sde Jan 29 17:29:50 unraid emhttpd: spinning down /dev/sde Jan 29 20:25:00 unraid emhttpd: read SMART /dev/sde Jan 29 20:40:13 unraid emhttpd: spinning down /dev/sde Jan 29 23:30:26 unraid emhttpd: read SMART /dev/sde Jan 29 23:45:41 unraid emhttpd: spinning down /dev/sde Jan 30 00:31:23 unraid emhttpd: read SMART /dev/sde Jan 30 00:46:24 unraid emhttpd: spinning down /dev/sde Jan 30 07:45:52 unraid emhttpd: read SMART /dev/sde Jan 30 08:11:56 unraid emhttpd: spinning down /dev/sde Jan 30 11:40:00 unraid emhttpd: read SMART /dev/sde Jan 30 11:55:01 unraid emhttpd: spinning down /dev/sde Jan 30 14:40:01 unraid emhttpd: read SMART /dev/sde Jan 30 14:55:02 unraid emhttpd: spinning down /dev/sde Jan 30 19:27:57 unraid emhttpd: read SMART /dev/sde Jan 30 19:43:11 unraid emhttpd: spinning down /dev/sde Jan 30 19:53:18 unraid emhttpd: read SMART /dev/sde Jan 30 20:15:11 unraid emhttpd: spinning down /dev/sde Jan 30 20:18:06 unraid emhttpd: read SMART /dev/sde ** Press ANY KEY to close this window ** 20 hours ago, mgutt said: Jedenfalls wäre der erste Schritt ein Backup zu machen. Dann auf die Disk klicken und eine Reparatur versuchen (scrub). Ein Backup habe ich gemacht. Der scrub aus der GUI bringt keine Fehler, aber irgendwie glaube ich nicht das er funktioniert, weil er nach dem klick eigentlich auch schon wieder fertig ist. UUID: 0c6db0b0-7bd0-48bd-890b-a9aab341325f Scrub started: Mon Jan 30 20:22:01 2023 Status: aborted Duration: 0:00:00 Total to scrub: 8.06TiB Rate: 0.00B/s Error summary: no errors found 20 hours ago, mgutt said: Ist dir der Server mal abgeschmiert / hart ausgeschaltet? BTRFS ist da was empfindlich. Ja, mir ist auch aufgefallen, dass unraid sich meistens beim Backup auf meine Unraid-Backupserver mit deinem Rsync-Script oder beim Backup auf den PBS verabschiedet. Quote Link to comment
mgutt Posted January 30, 2023 Share Posted January 30, 2023 34 minutes ago, frank80 said: weil er nach dem klick eigentlich auch schon wieder fertig ist. Ja da steht ja auch aborted. Komisch. Nach dem scrub irgendwas in Tools > syslog? Quote Link to comment
frank80 Posted January 30, 2023 Author Share Posted January 30, 2023 ich habe nur diesen Eintrag Jan 30 21:25:10 unraid ool www[5434]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_scrub 'start' '/mnt/disk1' '' Quote Link to comment
frank80 Posted February 6, 2023 Author Share Posted February 6, 2023 (edited) Hallo zusammen, ein kurzes Update. Leider geht aktuell nicht mehr viel. Ich habe noch einmal eine Rsync-Sicherung gestartet, nach ca. 5 Std. war unraid nicht mehr erreichbar und ich musste den Rechner hart neu starten. Als unraid wieder hochgefahren war, hat der Parity Check begonnen, was ebenfalls dazu geführt hat, dass unraid nach ein paar Stunden nicht mehr erreichbar war und ich wieder hart neu starten musste. Was mir ebenfalls aufgefallen ist, es waren nicht nur die 2 vdisks, sondern mehrere Dateien die Read-Only sind. So, heute ist meine neue HDD gekommen (brauchte sowieso eine), wie würdet ihr jetzt am besten vorgehen? Array stop > HDD Defekt raus > Array start > Array stop > HDD neu rein > Array start ? Gruß Frank Edited February 6, 2023 by frank80 Quote Link to comment
cz13 Posted February 6, 2023 Share Posted February 6, 2023 Hab das Procedere noch nie machen müssen, falls der Fall dann mal eintritt würde ich mich an die Doku halten https://wiki.unraid.net/Manual/Storage_Management#Replacing_failed.2Fdisabled_disk.28s.29 Quote Link to comment
frank80 Posted February 6, 2023 Author Share Posted February 6, 2023 Hallo cz13, danke für den Link!! Das Rebuild läuft und ich habe mich für das "Normal replacement" mit der Option 7 entschieden. Gruß und danke Frank Quote Link to comment
frank80 Posted February 7, 2023 Author Share Posted February 7, 2023 Hallo zusammen, so, hier ein ernüchterndes Update... 🙈 Das Rebuild ist fertig und ich habe unraid neu gestartet, nach ca. 10 Min. hatte ich die ersten Benachrichtigungen. Die Fehler kamen in Dauerschleife bei Zugriff auf die Daten.. Feb 7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 4096 Feb 7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 16384 Feb 7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 4096 Feb 7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 16384 Feb 7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 4096 Feb 7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 16384 Fix Common Problems Feb 7 19:08:06 unraid root: Fix Common Problems: Error: Unable to write to disk1 Was kann ich jetzt noch machen? Gruß Frank Quote Link to comment
mgutt Posted February 7, 2023 Share Posted February 7, 2023 2 hours ago, frank80 said: Das Rebuild ist fertig Meinst du Rebuild oder Check? Kein Mensch kann dich dazu zwingen den Check durchlaufen zu lassen. Das ist eben eine Vorsichtsmaßnahme von unRAID, wenn der Server nicht sauber heruntergefahren wurde. 2 hours ago, frank80 said: Die Fehler kamen in Dauerschleife bei Zugriff auf die Daten.. Erweiterten SMART Test versuchen? SMART Daten prüfen? Ich würde aber vermutlich die Disk direkt ausbauen und gegen eine neue ersetzen. Danach kann man die Reparatur / Analyse ja als über UD gemountete Disk versuchen. Es bringt ja nichts eine kaputte Disk weiter im Array zu lassen. Die ist entweder physisch kaputt oder irgendwas ganz grob mit dem Dateisystem hinüber. Ich würde dann auch keinen Rebuild machen, sondern mit Tools > New Config das Array wie zuvor zuweisen, nur eben mit der neuen Disk 1 und dann die Parität neu aufbauen lassen. Danach die kaputte Disk per btrfs restore Richtung Disk 1 wiederherstellen. Mit einem klassischen Rebuild mit Disk Tausch stellt man sonst evtl einfach nur das kaputte Dateisystem wieder her. Quote Link to comment
frank80 Posted February 7, 2023 Author Share Posted February 7, 2023 Hallo mgutt, ich habe die „defekte“ HDD durch eine neue identische HDD ersetzt. Hier bin ich nach der Anleitung aus dem Link von cz13 inkl. Punkt 7 vorgegangen. Spoiler To replace a failed disk or disks: 1. Stop the array. 2. Power down the unit. 3. Replace the failed disk(s) with a new one(s). 4. Power up the unit. 5. Assign the replacement disk(s) using the Unraid webGui. 6. Click the checkbox that says Yes I want to do this 7. (optional) Tick the box to start in Maintenance mode. If you start the array in Maintenance mode you will need to press the Sync button to trigger the rebuild. The advantage of doing this in Maintenance mode is that nothing else can write to the array while the rebuild is running which maximises speed. The disadvantage is that you cannot use the array in the meantime and until you return to normal mode cannot see what the contents of the disk being rebuilt will look like. 8. Click Start.to initiate the rebuild process.and the system will reconstruct the contents of the emulated didk(s) onto the new disk(s) and, if the new disk(s) is/are bigger, expand the file system. 1 hour ago, mgutt said: Mit einem klassischen Rebuild mit Disk Tausch stellt man sonst evtl einfach nur das kaputte Dateisystem wieder her. Ich vermute, dass genau das passiert ist. Die ausgebaute HDD habe ich einmal testweise per USB an meine Synology DS gestöpselt. Hier kann ich auf alle Daten zugreifen und auch die vdiks löschen, die in unraid auf Read-Only standen. Gruß Frank Quote Link to comment
mgutt Posted February 7, 2023 Share Posted February 7, 2023 5 minutes ago, frank80 said: Die ausgebaute HDD habe ich einmal testweise per USB an meine Synology DS gestöpselt. Hier kann ich auf alle Daten zugreifen und auch die vdiks löschen, die in unraid auf Read-Only standen. Und in Unraid, wenn du sie da über USB mountest? Und wie verhält sich der Zugriff nun nach dem Rebuild der neuen Disk? Quote Link to comment
frank80 Posted February 7, 2023 Author Share Posted February 7, 2023 (edited) 7 minutes ago, mgutt said: Und in Unraid, wenn du sie da über USB mountest? Das versuche ich morgen einmal. 7 minutes ago, mgutt said: Und wie verhält sich der Zugriff nun nach dem Rebuild der neuen Disk? Es hat keinen Unterschied gemacht. Es ist als wäre die „defekte“ HDD im Array. Wie du weiter oben im Post auch schreibst, habe ich wieder ein defektes Dateisystem. Edited February 7, 2023 by frank80 Quote Link to comment
mgutt Posted February 7, 2023 Share Posted February 7, 2023 Nun gibt es zwei Möglichkeiten: a) weil der Rebuild den selben kaputten Zustand wiederhergestellt hat b) weil die SATA Buchse / das Kabel defekt ist Hast du ein Backup von den Daten der Disk? Dann könnte man einfach das machen: - Screenshot von der Disk Übersicht machen - Array stoppen - Tools > New Config > Pools behalten - Mit Unassigned Devices Plugin die Partition von der neuen kaputten Disk entfernen - Disks wieder ins Array packen und starten, formatieren, usw Wenn es kein Backup gibt, könnte man vom Prinzip das selbe machen und die alte Disk mounten und dann von der alten auf die neu formatierte kopieren. Du solltest aber zu Anfang mal deinen RAM checken. Nicht dass der das Problem verursacht. Eventuell auch mit dem Preclear Plugin die Disk nullen und verifizieren, bevor du sie ins Array packst. Quote Link to comment
frank80 Posted February 8, 2023 Author Share Posted February 8, 2023 (edited) Hallo, Ok. Dann gehe ich jetzt Mal der Reihe nach. Memtest habe ich heute morgen gestartet, dann schauen wir heute Abend mal was er spricht. SATA Kabel sind bestellt und kommen morgen. Gruß und danke Frank Edited February 8, 2023 by frank80 Quote Link to comment
frank80 Posted February 8, 2023 Author Share Posted February 8, 2023 Hallo, den Memtest habe ich nach über 9 Std. beendet und er brachte keine Fehler. Die „defekte“ HDD habe ich per USB an unraid angeschlossen, kann sie aber nicht mounten. Feb 8 20:56:57 unraid kernel: BTRFS warning: duplicate device /dev/sdi1 devid 1 generation 203841 scanned by mount (16657) Feb 8 20:57:00 unraid unassigned.devices: Mount of 'sdi1' failed: 'mount: /mnt/disks/91T0A2J8FVGG: mount(2) system call failed: File exists. dmesg(1) may have more information after failed mount system call. ' Morgen tausche ich das SATA-Kabel. Gruß Frank Quote Link to comment
frank80 Posted February 10, 2023 Author Share Posted February 10, 2023 Hallo, neue Kabel sind angeschlossen. Das habe bisher gemacht; On 2/8/2023 at 12:31 AM, mgutt said: - Screenshot von der Disk Übersicht machen - Array stoppen - Tools > New Config > Pools behalten - Mit Unassigned Devices Plugin die Partition von der neuen kaputten Disk entfernen - Disks wieder ins Array packen und starten, formatieren, usw Den Parity-Sync habe ich abgebrochen, weil ich die Daten der alten HDD wieder auf die Disk1 kopieren wollte, kann die HDD aber nicht mounten. Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): unrecognized or unsupported super flag: 34359738368 Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): dev_item UUID does not match metadata fsid: b1766b0c-5746-4d3f-a867-6ecb982ee7ba != 0c6db0b0-7bd0-48bd -890b-a9aab341325f Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): superblock contains fatal errors Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): open_ctree failed Feb 10 17:01:57 unraid unassigned.devices: Mount of 'sdg1' failed: 'mount: /mnt/disks/91T0A2J8FVGG: wrong fs type, bad option, bad superblock on /dev/sdg1, miss ing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. ' Feb 10 17:01:57 unraid unassigned.devices: Partition '91T0A2J8FVGG' cannot be mounted. Feb 10 17:03:12 unraid kernel: /dev/sdg1/: Can't open blockdev Feb 10 17:04:00 unraid kernel: BTRFS error (device sdg1): unrecognized or unsupported super flag: 34359738368 Feb 10 17:04:00 unraid kernel: BTRFS error (device sdg1): dev_item UUID does not match metadata fsid: b1766b0c-5746-4d3f-a867-6ecb982ee7ba != 0c6db0b0-7bd0-48bd -890b-a9aab341325f Jetzt habe ich meine BackupHDD im Wechselrahmen und würde so vorgehen; rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1/ Die Backups habe ich so erstellt; rsync -avP --exclude-from=/boot/config/exclude.txt /mnt/user/ /mnt/disks/BackupHDD/ Ist das OK? Quote Link to comment
mgutt Posted February 10, 2023 Share Posted February 10, 2023 12 minutes ago, frank80 said: rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1/ Dadurch wird der Ordner BackupHDD in disk1 erstellt. Normal lässt man beim Ziel den / weg: rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1 Aber du hast jetzt ein Problem. Du hast /mnt/user/ gesichert. Du hast also den Inhalt von disk1 UND cache gesichert. Oder hast du keinen Cache? Wenn nein, sollte es so richtig sein: rsync -avP /mnt/disks/BackupHDD/user/ /mnt/disk1 Check das bitte vorher. Ansonsten hast du nachher doppelte Dateien Quote Link to comment
frank80 Posted February 10, 2023 Author Share Posted February 10, 2023 (edited) 4 minutes ago, mgutt said: rsync -avP /mnt/disks/BackupHDD/user/ /mnt/disk1 Ich kopiere aus user, dann sollte es so reichen; rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1 Cache ist dabei. 🙈 Was mache ich jetzt am besten? Edited February 10, 2023 by frank80 Quote Link to comment
mgutt Posted February 10, 2023 Share Posted February 10, 2023 Oh nein. Warum ^^ Waren nur bestimmte Ordner auf disk1? Oder auch appdata? Also die Frage ist, ob man vielleicht nur einzelne Ordner auf disk1 wiederherstellt. Quote Link to comment
frank80 Posted February 10, 2023 Author Share Posted February 10, 2023 (edited) 29 minutes ago, mgutt said: Oh nein. Warum ^^ Ich dachte, ich habe mir wieder ein Ei gelegt. Auf dem Backup sind außer meinen eigenen Ordnern (+ Daten-Ordner im Bild) noch diese... Cache im zweiten Bild Edited February 10, 2023 by frank80 Quote Link to comment
mgutt Posted February 10, 2023 Share Posted February 10, 2023 29 minutes ago, frank80 said: Auf dem Backup sind außer meinen eigenen Ordnern (+ Daten-Ordner im Bild) noch diese... Cache im zweiten Bild Wir probieren erstmal abzugleichen: rsync -a --itemize-changes --dry-run /mnt/disks/BackupHDD/user/appdata/ /mnt/cache/appdata Optimal wäre keine Ausgabe. Dann wäre der Ordner mit dem Backup identisch. Quote Link to comment
frank80 Posted February 10, 2023 Author Share Posted February 10, 2023 3 minutes ago, mgutt said: rsync -a --itemize-changes --dry-run /mnt/disks/BackupHDD/user/appdata/ /mnt/cache/appdata leider nicht identisch, ich weiß jetzt wie viele, aber >9999 Zeilen Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.