Lug-dd

lug-dd@mailman.schlittermann.de

6 participants
10818 discussions

Korrupte Dateien in ext4 auf RAID5
by Max Pietzsch 05 Aug '24

05 Aug '24

Hallo in die Runde, ich wende mich an euch in der Hoffnung, dass vllt. jemand Zeit und Muße hat und mir einen Tipp geben kann, doch noch etwas von meinen Daten zu retten. Vorab: es ist vollkommen meine Schuld, RAID ist kein Backup, ich habe kein Backup, weil ich es einfach immer wieder aufgeschoben habe ... das war einfach komplett dumm. Kann man nicht anders beschreiben. Aber von vorn, in Stichpunkten, damit es nicht ewig lang wird: - ich betreibe ein RAID5 mit einem Debian-Rechner als Software-RAID, ext4 Dateisystem - Speicher war komplett voll (0 Byte frei), daher habe ich eine neue Platte eingebunden (dazu die Partitionierung von bestehender Platte sdg auf neue Platte sdd geklont, per sgdisk, am Ende auch neue UUID generiert per "sgdisk -G /dev/sdd") - nach dem Rebuild sah ich, das eine Platte als "removed" markiert war, der Zustand des RAIDs war "clean, degraded" - die SMART-Werte der Platte sahen allerdings ganz okay aus, also habe ich die Platte wieder hinzugefügt ("mdadm /dev/md0 --re-add /dev/sdg1") - danach sah alles erstmal soweit gut aus (hier habe ich aber auch nicht versucht auf meine Daten zuzugreifen, kann also nichts genaues sagen) - vor dem resizen der ext4-Partition wollte ich einen fsck ausführen, wie es im Netz empfohlen wird, also "fsck.ext4 -f /dev/md0" ausgeführt - dabei bekam ich einen erkannten Fehler angezeigt, der sich wie folgt las (Beispiel aus einem Forum): Inode 96108844 has an invalid extent node (blk 1537738982, lblk 0) Clear<y> - das habe ich bejaht, dann passierte in dem Prozess gefühlt 3-5 Minuten nichts, dann brach dieser durch einen OOM Fehler ab - an der Stelle wurde es mir zu heiß und ich wollte erstmal auf die bereits bestellte Backup-Platte warten, da ich mir das Thema jetzt eh mal vornehmen wollte - ca. 15-20 Minuten später wollte ich per SMB auf Daten auf dem RAID zugereifen und bemerkte dass viele Directories komplett leer sind und viele Dateien korrupt, Bilder nur noch zu einem Drittel oder gar nicht mehr gelesen werden können etc. - im dmesg gab es daraufhin immer mal wieder drei verschiedene Arten von Fehlern zu lesen: [Sun Aug 4 15:15:18 2024] EXT4-fs error (device md0): htree_dirblock_to_tree:915: inode #158122016: block 1425161073: comm smbd: bad entry in directory: rec_len % 4 != 0 - offset=0, inode=2347148723, rec_len=23058, name_len=57, size=4096 [Sun Aug 4 15:15:20 2024] EXT4-fs error (device md0): ext4_ext_find_extent:889: inode #159777629: comm smbd: pblk 1278268966 bad header/extent: invalid magic - magic 31d1, entries 10605, max 17309(0), depth 59656(0) [Sun Aug 4 15:25:09 2024] EXT4-fs error (device md0): htree_dirblock_to_tree:915: inode #23117843: block 290551738: comm smbd: bad entry in directory: directory entry overrun - offset=0, inode=2642206138, rec_len=62956, name_len=71, size=4096 Ich habe /dev/md0 erstmal geunmounted und den Samba-Dienst gestoppt, mittlerweile den Rechner heruntergefahren. Ich warte jetzt auf die bestellten Backup-Platten. Um in der Zwischenzeit nicht ganz verrückt zu werden, versuche ich mir gerade alle Möglichkeiten zusammenzusuchen. Erster Schritt sollte ein kompletter dd Dump auf eine Backupplatte sein. Den Dump wollte ich dann als Loopback mounten und schauen, was testdisk und photorec sagen, ob da überhaupt noch irgendwas zu holen ist. Falls ja, auf die zweite neue Platte die Wiederherstellung von Dateien als Ziel laufen lassen. Auf dem Dump hätte ich dann auch einen erneuten fsck (diesmal mit e2fsck) versucht, diesmal dann mit einem Verzeichnis als Zwischenspeicher für die gefundenen Konflikte (siehe: https://serverfault.com/a/9233 ). Ein Bekannter gab mir nun aber den Hinweis, selbst das Ziehen eines Images erstmal sein zu lassen, da der RAID-Algorithmus auch beim lesenden Zugriff versuchen könnte, Daten zu verändern. Das wäre natürlich der absolute GAU. Seht ihr hier Chancen, dass man das ext4 System wieder hinbekommt und auf die Daten wieder korrekt zugreifen kann? Oder ist mit so einem abgebrochenen Check vermutlich schon zu viel zerstört? Habt ihr noch andere Ideen für Tools oder Möglichkeiten, was man tun könnte? Ich bedanke mich herzlich im Voraus bei euch! Beste Grüße Max

1 0

Korrupte Dateien in ext4 auf RAID5
by Max Pietzsch 05 Aug '24

05 Aug '24

1 0

Ist die Festplatte gleich für die Mülltonne?
by Luca Bertoncello 05 Aug '24

05 Aug '24

Moin Leute! Letzte Woche gab es ein kleines Problem bei mir zu Hause und ein Vollidiot (ich kenne kein Wort, was noch besser den Kerl definieren kann), hat mit Gewalt meine ganze Technik ausgeschaltet. Da ich im Urlaub war, konnte ich leider auch nichts dagegen tun... Egal, Fakt ist, dass seitdem (ich bin heute wieder zu Hause), meldet sich SMART so: SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Interrupted (host reset) 90% 7053 - # 2 Extended offline Interrupted (host reset) 90% 7030 - # 3 Short offline Interrupted (host reset) 90% 7029 - ... Und in dmesg sehe ich folgendes (jeden Tag, bei der Zeit, wann die Prüfung gemacht wird): [So Aug 4 02:10:49 2024] ata1.00: exception Emask 0x0 SAct 0x1f80000 SErr 0x0 action 0x6 frozen [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/18:98:80:cd:10/00:00:07:00:00/40 tag 19 ncq dma 12288 out res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:a0:b8:cd:10/00:00:07:00:00/40 tag 20 ncq dma 4096 out res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:a8:e8:cd:10/00:00:07:00:00/40 tag 21 ncq dma 4096 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:b0:18:ce:10/00:00:07:00:00/40 tag 22 ncq dma 4096 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:b8:38:ce:10/00:00:07:00:00/40 tag 23 ncq dma 4096 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:c0:58:ce:10/00:00:07:00:00/40 tag 24 ncq dma 4096 out res 40/00:01:06:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1: hard resetting link [So Aug 4 02:10:50 2024] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [So Aug 4 02:10:50 2024] ata1.00: configured for UDMA/133 [So Aug 4 02:10:50 2024] ata1: EH complete Nun würde ich mich auf eure Meinung freuen... Ist die Festplatte gleich "mülltonnenbereit" oder ist was, das per Software zu reparieren ist? Ich tendiere das erste, freue mich aber auf eure Meinung. Viele Grüße Luca Bertoncello (lucabert(a)lucabert.de)

2 2

Nur ein Test
by Christian Perle 24 Jul '24

24 Jul '24

Hallo aus dem GAG18, bitte ignorieren sie diese Nachricht. Gruss, Christian -- Christian Perle chris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing

2 1

Treffen morgen, 24.07.
by Jakob Mendel 23 Jul '24

23 Jul '24

Hallo allerseits, morgen ist der 4. Mittwoch im Monat, und ich würde zum Stammtisch kommen. Auf https://www.gag-18.com/ steht zwar nichts davon, aber ich erinnere mich (oder glaube, mich zu erinnern ;-)), daß dort seit gestern gebaut wird und daher geschlossen ist. Treffen wir uns um acht gleich in der "Torwirtschaft", oder lassen wir es darauf ankommen? Viele Grüße Jakob

3 2

Treffen im Club ...
by Bernhard Schiffner 10 Jul '24

10 Jul '24

heute abend? Es ist noch Vorlesungszeit, also sollte der GAG offen haben. Ich würde kommen wollen ... ??? Bernhard

2 3

x86_64-efi
by Ottmar-Schmidt＠web.de 08 Jul '24

08 Jul '24

3 3

hat jemand gentoo-Erfahrung
by ronny＠seffner.de 27 Jun '24

27 Jun '24

Hallo Gruppe, ich habe hier ne Hardware hingestellt bekommen, die wohl so eine Art Fotospeicher mit GUI und Schnittstellen ist. Der Hersteller ist längs vom Markt verschwunden. Das Mainbord hat den Geist aufgegeben und mit einem Ersatz aus der Generation (Sockel, RAM) rennt die Kiste in eine Kernel-Panic. Ich habe da unter Knoppix mal ins Storage (RAID-Controller, SATA-Boot-Device) geschaut. Ist wohl ein gentoo 1.12.xx - Wikipedia kennt 1.1, 1.4 und 12.x. Das 12.x ist aus 2012, die Dateien im System aus 2013 - ich tippe daher auf eines dieser 12er gentoo. Alles was ich beim Booten beobachten kann, ist das init daran scheitert /root zu verwenden und dann kommts zur kernel panic. Ich würde jetzt in einem mir bekannten Linux im Bootloader (grub) schauen ob root= irgendwie valide scheint und ggf. die initrd neu bauen (ich einer chroot-Umgebung). Hier liegt /root aber als squashfs-Datei vor. Ich glaube irgendwie nicht, dass es gut wird, wenn ich unter einem knoppix die Partitionen zusammen mounte, mit chroot da rein wechsle und mkintiramfs ausführe. Ich fühle mich in der Konstellation einfach zu unsicher. Hat hier jemand ausreichende gentoo Rettungserfahrungen und kann das remote oder vor Ort mit hoher Sicherheit bootbar bekommen? Dem "Kunden" ist das bares Geld wert, also muss kein Freundschaftsdienst sein. Oder gibts nen howto, dass ich noch nicht fand aber lesen sollte? Antworten auch gern per PN oder an 0174 9474439. Mit freundlichen Grüßen / Kind regards Ronny Seffner

2 2

"Connection refused" von Redhat8
by Preuße, Hilmar 26 Jun '24

26 Jun '24

Moin, gegeben sind 3 Linux-Server auf Redhat8 (virtuelle Maschinen, ob VMWare oder KVM kann ich auf Anhieb nicht sagen). Alle Maschinen stehen topologisch (IPv4) im selben Netz (CIDR /24). Folgendes Verhalten: TCP von ServerA -> TCP/5665 ServerC -> TCP Connect OK TCP von ServerB -> TCP/5665 ServerC -> Connection refused Selbes Verhalten auf TCP/22. Die Host FW auf ServerC ist angeblich down (prüfen kann ich das nicht [kennt jemand eine Methode, wie ich das als non-root testen kann?]). Man verweist mich jetzt auf ein mgl. Netz-FW, aber FW's funktionieren doch nur über Netz-Grenzen, also müßten die 3 Kisten in unterschiedlichen Netzen stehen, um eine FW zum Einsatz zu bringen. Jemand eine Idee, was hier los sein könnte? H. -- sigfault

3 4

26.6.24
by Bernhard Schiffner 26 Jun '24

26 Jun '24

Ich wäre da. Aber wo? Kann jemand sagen, ob der GAG morgen offen sein wird, bzw. ob man es gleich woanders versuchen sollte (Torwirtschaft)? Ober man trifft sich 20:00 am GAG und "wandert weiter", falls der zu ist? ??? Bernhard PS: Für den Fall der Fälle meine Telefonnummer: +4915779093349

4 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Lug-dd