mgutt

Voraussetzung ist, dass du ein Linux Dateisystem verwendest, damit die Dateirechte passen. Oder du nimmst ein Backup Tool was tar erstellt sie zb das Appdata Backup Plugin. Saubere Backups von Containern (also den appdata Unterordnern) bekommst du nur, wenn der Container gestoppt wurde. Auch das macht übrigens das appdata Backup plugin automatisch. Und ja, man braucht nur den appdata Inhalt. Und halt das Template von dem Container, also falls man das an den Einstellungen des Containers geändert hat. Das liegt aber eh auf dem USB Stick.

Du hast korrupte Daten. Du könntest jetzt an Hand der inode versuchen herauszufinden ob es Dateien betrifft, die dir weh tun. Also ein scrub ausführen und dann das Kommando versuchen: dmesg | grep "checksum error at" | cut -d\ -f24- | sed 's/.$//' | sort | uniq Von hier: https://superuser.com/a/1000835/129262 Los wird man die Fehler wohl nur, wenn man die betroffenen Dateien löscht: https://www.reddit.com/r/btrfs/comments/hcllay/how_to_cleanup_after_btrfs_scrub_checksum_errors/ Hast du ECC RAM?

Ich würde die Platte als zweite Platte bei einer neuen Windows VM zuordnen und dann eine Reparatur versuchen.

Was geben die Kommandos aus: df -h findmnt | grep zfs zfs list -o name,mounted,mountpoint

Was hast du denn jetzt mit den Dateien gemacht, die vom Cache auf der Disk gelandet sind?

Exakt so. Man kann beliebig löschen oder umbenennen. Wenn man eine Datei löscht, werden nur die Datenblöcke gelöscht, die sonst keine andere reflink Datei verwendet.

Hattest du nicht was wegen der Schreibweise gesagt? EDIT: Ich glaube du musst erst den Mount entfernen, damit der Pool nicht "doppelt" offen ist oder so?!

Das wird vermutlich Protest auslösen, aber ich bin dafür, dass das verboten wird. Außerdem sollte das Formatieren von emulierten Disks nicht angeboten werden. Ich habe das mal als Verbesserungsvorschlag gepostet: Wenn du gezielt danach suchst, dann findest du mehrere Threads dazu. Der letzte Fall im deutschen Forum war einer, der eine BTRFS formatierte Disk im Array hatte und wo ich ihm bei der Datenrettung geholfen habe. Dass das passiert liegt denke ich daran, dass die Metadaten korrupt sind und das Dateisystem eigentlich intakt ist, aber eben nicht mehr gemountet werden kann. Bei XFS muss man dann erst einen Repair starten.

What happened: This is the second time I notice that a user killed his data (another topic). Their disk lost it's connection, so it was thrown out of the array, but parallel the disk partition was corrupt. First problem: This means the user had as a result an emulated disk without partition (with defective partition table) and the GUI offered them to format the disk. Second problem: The user formatted the disk as they thought this could be a necessary step to rebuild the data. Instead it resetted the file system and updated the parity accordingly. Third problem: Their caching rules applied. The mover moved new data to the fresh formatted and emulated disk. Now important sectors with data were overwritten (the chances to recover the data through a third-party software shrunk). Fourth problem: The user started a data rebuild with the same disk that was disconnected before (hardware problem was solved, like a defective cable or sata port). After the rebuild process was finished all its original data was replaced against a fresh formatted disk + the moved data from the cache. What should happen instead: a) do not offer to format an emulated disk. Instead it should advise the user to repair the partition table b) do not allow to replace a "defective" disk by itself. By that its impossible to kill the original data

Ne das waren Retouren. Die bekommt man mit Glück für 400 €. Ich habe schon mit Amazon UK gesprochen. Ich soll die retournieren und bekomme mein Geld wieder. Auch den Rückversand bekomme ich erstattet. Hier noch mal ein Foto: Wie man sieht wurden runde Sticker über die Schrauben gemacht. Oben links den Sticker hatte ich bei Ankunft entfernt, weil mir das direkt Spanisch vorkam. Und weil ich gerade Pech habe, hat mir der Händler einen E-2224 geschickt. Also 4-Kerner ohne iGPU. Böse Zungen würden sagen ein billiger i3 mit anderem Logo drauf für mehr als den doppelten Preis. 🤪

Du brauchst nur den Inhalt von /boot/config. Also man kann jederzeit einen neuen Stick mit dem Creator erstellen und dann einfach diesen Ordner mit dem Backup überschreiben. Übrigens kannst du ein ZIP vom Stick machen lassen, wenn du auf den Namen des Sticks klickst.

Hier siehst du nun die verschiedenen txg mit den Zeitstempeln: Wenn ich das richtig verstehe, kannst du nun mit folgendem Kommando prüfen ob dieses txg in Ordnung ist: zdb -dG -o zfs_max_missing_tvds=1 -T <txg> <pool> Dh du probierst jetzt die txg absteigend nach Datum durch. Natürlich ohne Gewähr. Ich mag es nicht sowas ohne Backup zu machen.

Korrekt. Ist parallel passiert, weil die emulierte Dis3 funktioniert ja auch ohne HDD. Das ist ja der Sinn an einer Parität, dass sie für Ausfallsicherheit sorgt und das System auch mit einer HDD weniger weiter genutzt werden kann.

Nein, weil du wie gesagt die emulierten Disk3 formatiert hast. Du hast also die Parität entsprechend so aktualisiert, dass sie nur noch eine neue formatierte Disk3 kennt und die hast du dann wiederhergestellt. Allerdings wird beim Formatieren ja "nur" die Partitionstabelle und der Dateiindex neu erstellt. Die eigentlichen Datenblöcke der Dateien bleiben erhalten. Allerdings wurden bereits 200GB dieser Datenblöcke überschrieben, so dass mit einem Datenverlust zu rechnen ist. Natürlich solltest du alles daran setzen, dass nicht noch mehr auf die Disk3 geschrieben wird.

Das Ziel des Symlinks existiert nicht. Deswegen schlägt das Kommando fehl. Du kannst dir den symlink so ausgeben lassen: ls -l <Pfad> Fazit: Symlink löschen oder korrigieren.

Nein. Alles was du danach gemacht hast, wurde bereits in der Parität aktualisiert. Die 200GB geschriebenen Daten haben zb die Parität komplett verändert. Ich glaube mittlerweile zu wissen was passiert ist. Und zwar ist erst das Dateisystem von Disk3 kaputt gegangen und danach ist Disk3 entfernt worden bzw das passierte gleichzeitig. Dh du konntest nicht mehr auf die Dateien zugreifen als die Disk3 rausgeworfen wurde, korrekt? Normalerweise geht das nämlich, da eine entfernte Disk dann einfach live durch die Parität emuliert wird. Wenn man nun formatiert, dann formatiert man nicht die Disk3, sondern die emulierte Disk3. Dh du hast zu dem Zeitpunkt das kaputte Dateissystem der emulierten Disk3 formatiert, statt es zu reparieren. Eine Reparatur war zu dem Zeitpunkt noch möglich. Allerdings nicht über die GUI. Das hätte man manuell über die Kommandozeile machen müssen. Nun das nächste Disaster. Die HDD selbst war vermutlich vollständig intakt. Hatte vermutlich sogar ein korrektest Dateissystem und enthielt alle deine Dateien. Du hast dann die absolut intakte HDD dem Disk3 Slot zugewiesen und an Hand der Parität wiederhergestellt. Du hast also die formatierte und leere Partition neu auf die HDD geschrieben und danach wurden 200GB an neuen Dateien drauf geschrieben, weil dein Yes Share vom Cache entfernt wurde. Was ich nun nicht verstehe, warum du die Disk3 wieder als Disk3 zuweisen konntest. Ich dachte immer, dass das nicht geht und unRAID eine HDD mit einer anderen Seriennummer voraussetzt?! @ich777? Wie ich herauslese, hast du kein Backup. Dann bleibt dir tatsächlich nur Disk3 ausbauen und eine Datenrettung probieren. Es wird in jedem Fall zu einem Datenverlust gekommen sein, da die 200GB neue Dateien, bereits bestehende Dateien überschrieben haben. Der größte Teil sollte aber zu retten sein. Ich vermute allerdings ohne Dateinamen. Das geht meine ich nur bei BTRFS. Für die Zukunft: Kümmer dich um Backups.

Was ist mit der Ausgabe von: zdb -e RAID-Z1-1 -ul Du erhältst eine Solche Ausgabe mit Zeitstempeln: https://serverfault.com/a/1002891/44086 Man kann dann wohl die einzelnen txg durchprobieren und wiederherstellen: https://serverfault.com/a/1083138/44086 Wobei auch der erstmal den Pool auf neue Platten gesichert hat.

Array? Welche Disk? Wenn sagen wir mal Disk2 mit Seriennummer 123 verschwindet und deswegen aus dem Array fliegt, kannst du sie nicht mehr als Disk2 zuweisen. unRAID möchte eine Disk mit einer anderen Seriennummer. Also was genau hast du getan, dass sie trotzdem akzeptiert und vor allem formatiert werden musste?! Hast du? Klingt nicht so. Klingt eher so, dass du eine Disk formatiert, also geleert hast und dann anschließend die Parität hast neu aufbauen lassen. Wieso wurde der Cache auf das Array verschoben?! Das passiert nur, wenn man die Cache Einstellungen der Shares ändert. Oder hattest du zufällig 200GB kurz vor dem Defekt in einen Share geladen, der die Cache Einstellung Yes nutzt?! Backup? Falls die kaputte Disk nur formatiert und nicht genullt / vollständig überschrieben wurde, könnte man es auch noch mit einer Datenrettungssoftware bei dieser einzelnen Disk probieren.

Nur Text hilft ja denke ich nicht weiter. Kopiere die Meldungen und was in den Logs an Fehlern kommen. Schon das versucht? zdb -ul <pool_name> Und dann: zpool import -F -T <id> <pool_name> Aber Achtung. Wenn das fehlschlägt sind die Daten weg vom Fenster. Daher besser alle Platten 1:1 auf andere Platten spiegeln / mit dd in raw images sichern: https://forum.proxmox.com/threads/import-convert-export-raw-images-to-zfs-volume.21241/

Für appdata? Das ist sinnfrei. HDDs laufen ständig und die Performance ist auch mies.

Ich habe mit einer 2TB SSD angefangen und eine 1GB Datei drauf erstellt. Danach habe ich eine 1TB SSD hinzugefügt: Dann die 2TB entfernt und den Start bestätigt: Wie gehabt 1GB belegt: Dann die 2TB wieder ausgewählt und nun werde ich gewarnt, dass die 2TB SSD formatiert wird: Wie gehabt Daten noch da: Auch wenn ich das andersherum mache und die 1TB gegen eine weitere 2TB ersetze, sind die Daten noch da: Auch andersherum zuordnen ändert nichts: Fazit: Ich hab keine Ahnung wie du das geschafft hast.

Dateien liegen entweder auf dem Cache oder dem Array. Allerdings ist das doch völlig irrelevant für dein Problem. Du hast gesagt, dass du ein Update gemacht hast. Dadurch wird ja nicht der Pool entfernt. Also entweder hast du noch was anderes gemacht oder es ist einfach nur dein docker Image kaputt gegangen, was schlicht irrelevant ist, weil alle Dateien nach wie vor in /mnt/user/appdata vorhanden sind. Also woher nimmst du die Annahme, dass die weg seien? Shares > Appdata > Inhalt anzeigen. Wirklich leer?

Die CDs sind allgemein Schwachsinn, weil schon bei Pressung veraltet und gehören meiner Ansicht nach verboten.

I enabled websockets for Plex and it works. Are you using an additional Proxy like cloudflare or do you have a proxified IPv4 address through your internet provider?

Lokal kann das nur gehen, wenn swag im br0 Netzwerk mit eigener fester IP läuft oder du unRAIDs Ports zb auf 5000/5001 änderst, damit 80 und 443 für Swag genutzt werden kann.