@tobitobson sagte:

aber das scheint ja nun nix zu nützen, wenn die SD Karte abschmiert...

Backups ja auch immer auf ein externes Medium...

@OliverIO sagte:

empfehlung wäre aber auch für die zukunft

Noch wichtiger wäre auch die Empfehlung gescheite Backups anlegen zu lassen. Der Backitup-Adapter ist ja nicht zur Zierde auf jeder Installation vorinstalliert.

@tobitobson sagte:

anschließend Versuch eines kompletten Images mit dd
Abbruch durch I/O Timeout
sehr niedrige Lesegeschwindigkeit → Hinweis auf defekte SD-Sektoren

man kann dd so konfigurieren, das er nach mehreren versuchen den sektor/block überspringt und weitermacht. das sind dann aber definitiv verlorene bereiche. ob das iobroker daten betrifft kann man so ohne weiteres nicht sagen.
so ein dd image mit mehreren versuchen kann uU mehrere stunden brauchen, je nach größe der speicherkarte.

ob man ein linux image ordentlich unter mac mounten kann weiß ich nicht.
wenn du /opt/iobroker nicht siehst, siehst du wahrscheinlich nur die fat32 partition, in der nur start und boot dateien liegen.

auch ist es keine garantie ob man das image mounten kann. wenn die schäden in den bereichen liegen, die ein dateisystem definiv brauch, dann wird es ebenfalls schwierig.

deine reparaturversuche können auch noch weitere schäden erzeugt haben, da diese ggfs auch wieder geschrieben haben.

empfehlung wäre aber auch für die zukunft, keine sd karte mehr zu nehmen, lieber eine kleine ssd nehmen. die speicher sind etwas langlebiger und haben dann genügen reserveblöcke

iobroker SD-Karten-Recovery (Kurzprotokoll)

• Raspberry Pi bootet nicht mehr (7× grünes LED-Blinken)
• SD-Karte am Mac erkannt (Partitionen vorhanden: bootfs + ext4 root)
• Bootpartition konnte gelesen werden (FAT32, Dateien vollständig vorhanden)
• ext4-Partition war stark beschädigt (extreme Inode-/Blockfehler)
• Reparaturversuche mit e2fsck auf macOS (Homebrew e2fsprogs)
  • viele verwaiste Inodes
  • falsche Größen / Blockzuweisungen
  • defekte Attribute / Directory-Strukturen
• Dateisystem wurde mehrfach erfolgreich „verändert“, aber nicht sofort stabil
• finaler e2fsck-Lauf zeigte:
  • Reparatur abgeschlossen
  • keine Abbruch-Fehler mehr
  • aber Restwarnungen im Dateisystem
• anschließend Versuch eines kompletten Images mit dd
  • Abbruch durch I/O Timeout
  • sehr niedrige Lesegeschwindigkeit → Hinweis auf defekte SD-Sektoren
• Ergebnis:
  • Full-Image nicht zuverlässig möglich
  • SD-Karte vermutlich beginnender Hardware-Defekt
  • Datenrettung nur noch selektiv möglich (Read-only Zugriff / gezieltes Mounten oder Recovery)
  • iobroker-Daten höchstwahrscheinlich noch teilweise oder vollständig auf ext4-Partition vorhanden
• aktueller Stand:
  • Fokus auf Datenextraktion (/opt/iobroker)
  • kein weiterer Schreibzugriff auf SD empfohlen

@tobitobson [sagte]: Daten vom ioBroker wieder rankommen?

Die Daten liegen unter /opt/iobroker/iobroker-data.

@tobitobson sagte:
Am Mac kann ich auf die SD zugreifen und ich sehe auch den Inhalt.

Auch die mit ext4 formatierte Partition?

in der regel unter /opt/iobroker

die wichtigsten daten liegen unter /opt/iobroker/iobroker-data
sofern du alles standard hast und kein redis eingesetzt hast.
daten zu bestimmten adapter bspw datenbanken (sql, influx, etc) können auch noch wo anders liegen.

schau auch mal noch im ordner /opt/iobroker/backup ob da wirklich nichts ist.

wenn deine defekten sektoren der karte in einem der bereiche liegen, könnte es schwierig werden. versuche auch alle schreiboperationen auf dieser karte zu verhindern, da das die situation weiter verschlimmern kann

besser wäre es von der sd karte ein image mit dd zu ziehen, dieses unter linux zu mounten und dann nur noch mit dieser kopie zu arbeiten und daten zu retten.