sd card oder Dateisystem beschädigt?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hi, mein raspberry hat plötzlich nicht mehr reagiert.

    - hatte keine Ausgabe per HDMI

    - ssh Verbindung war nicht mehr möglich

    -- erst war die IP nicht erreichbar

    -- später seltsamerweise connection refused


    Nach abschalten konnte ich die SD nicht mounten.

    Kann ich das Dateisystem reparieren?


    Danke

  • Wie auch immer, mein aktueller Stand ist, dass wohl die SD Defekt ist.

    Code
    sudo badblocks -wsv -o 2019_01_piSDbadblocks.txt /dev/mmcblk0
    Es wird nach defekten Blöcken gesucht (Lesen+Schreiben-Modus)
    Von Block 0 bis 7703551
    Es wird getestet Mit Muster 0xaa:   0.04% erledigt, 4:30:09 verstrichen. (0/0/0 Fehler)

    Badblocks zeigt bisher eine Fehler an, aber 0.04 Prozent in 5 Stunden und lauter Fehlermeldungen im dmesg sagen wohl alles?

    Code
    ...
    mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400f00
    mmcblk0: command error, retrying timeout
    buffer_io_error: 22 callbacks suppressed
    Buffer I/O error on dev mmcblk0, logical block 272, lost async page write
    Buffer I/O error on dev mmcblk0, logical block 273, lost async page write
    ...


    Außerdem ist das Dateisystem als Image (mit dd kopiert) auch reparierbar.

  • @RTFM

    Das Dateisystem ist nicht gemounted.

    Das heisst aber nicht, dass es mit badblocks -w "repariert" werden kann. Mit badblocks -w wird die ganze SD zerstört (mit 0xaa überschrieben).

    Jetzt kannst Du nur mehr eine (vorhandene) Sicherungskopie auf die SD aufspielen, oder ein neues System aufsetzen.

    Zum Reparieren und Diagnostizoeren sind für EXT4 vorinstalliert:

    debugfs (8) - ext2/ext3/ext4 file system debugger

    dumpe2fs (8) - dump ext2/ext3/ext4 filesystem information

    e2fsck (8) - check a Linux ext2/ext3/ext4 file system

    e2image (8) - Save critical ext2/ext3/ext4 filesystem metadata to a ...

    e2label (8) - Change the label on an ext2/ext3/ext4 filesystem

    e2undo (8) - Replay an undo log for an ext2/ext3/ext4 filesystem

    e4defrag (8) - online defragmenter for ext4 filesystem

    resize2fs (8) - ext2/ext3/ext4 file system resizer

    tune2fs (8) - adjust tunable filesystem parameters on ext2/ext3/ext4...


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Das heisst aber nicht, dass es mit badblocks -w "repariert" werden kann. Mit badblocks -w wird die ganze SD zerstört (mit 0xaa überschrieben).

    Danke für deine Unterstützung.

    Wie oben getestet, das Dateisystem zu reparieren hat nicht funktioniert. Ja, es sollte alles weg sein, ist es aber nicht, die SD schreibt anscheinend nichts mehr. :rolleyes:

    Satze daher auf gelöst und werde gleich das Image auf eine neue Karte kopieren.

    FTR:

    Code
    #Backup
    sudo dd if=/dev/<sdDevice> status=progress | gzip > raspberry_image.img.gz
    #Restore
    gzip -cd raspberry_image.img.gz | sudo dd of=/dev/<sdDevice> status=progress 

    Einmal editiert, zuletzt von debug (12. Januar 2019 um 22:13)

  • Die SD Karte der Raspberry hat die Angewohnheit sich nach einer gewissen Zeit zu verabschieden. Deshalb solltest Du sie immer regelmäßig sichern und dann würdest Du jetzt einfach Dein Backup einspielen und gut ist :shy:

    Zu Deinem Schreibproblem: Das ist ein sehr blöder Fehler wenn eine SD Karte ihren Geist aufgibt. Ich hoffe Du kannst auch noch alle Daten korrekt lesen :crossing-fingers:

  • framp

    rsnapshot legt bei mir täglich Backups an von

    Code
    # LOCALHOST
    backup    /home/        localhost/
    backup    /etc/        localhost/
    backup    /var/www/    localhost/
    backup    /var/ocdata/    localhost/
    backup    /var/log/    localhost/
    backup    /var/mail/    localhost/

    Im aktuellen Fall ließ sich alles auf der sd noch kopieren und mit e2fsck reparieren. Falls ich davon ausgehen kann, dass alle Dateien heile geblieben sind? Brauche ich diese nicht.

  • Das kam nicht raus dass Du Backups hast :(

    Damit solltest Du vermutlich auch im Worst Case recovern können. Allerdings vermutlich mit manuellen Anpassungen.

    Ich sichere meine Raspis immer vollständig. Dann einfach das vollständige Backup restoren und alles lüpt wieder :)

    Gerade letztens hat jemand bei mir auf meiner Webseite geschrieben

    An Heilig Abend ist meine SD Karte abgeraucht. Das war kein Problem dank eines ddz Backups mit RaspiBackup. Ich konnte die Daten auf eine neue SD Karte via Etcher einspielen und diese einfach in den Raspi stecken

  • @framp

    Ja, mit dem cronjob Backups wäre es aber auch einiges an Aufwand gewesen, das System neu zu installieren. Den etc Ordner einfach kopieren ist es ja soweit ich weiß nicht ... :/

    @hyle @framp 

    Danke, habe es gesehen, sieht sehr Interessant aus, werde es auf jeden Fall genauer anschauen und testen. ;)

    Werden damit auch alle Nutzer, Konfigurationsdateien und installierte Pakete bei dem raspiBackup (rsync Backup Methode) gesichert und wieder hergestellt?

    Einmal editiert, zuletzt von debug (13. Januar 2019 um 00:56)

  • Werden damit auch alle Nutzer, Konfigurationsdateien und installierte Pakete bei dem raspiBackup (rsync Backup Methode) gesichert und wieder hergestellt?

    raspiBackup erstellt ein Vollbackup und damit wird dann auch alles wiederhergestellt. Ich weise aber besonders auf die Option -o hin mit der vor dem Backup laufende Services gestoppt werden damit sie konsistent gesichert werden und dann mit der Option -a nach dem Backup wieder gestartet werden.

  • Die SD-Karte ist wieder Defekt ... die Karte hat damit nur ca.1,5 Jahre gehalten, die Karte davor noch weniger < 1J ... damals schafften die SD-Karten deutlich länger bei ähnlicher Config.

    Es sind die gleichen Fehler, nur das es eine 16 GB Karte war. Entweder die Schreibvorgänge haben sich irgendwie erhöht, oder die letzten beiden Karten (von Transcend) sind einfach nicht belastbar gewesen.


    Sehr enttäuschend, aber nur ein Beweis dafür, dass Backups wichtig sind.

  • Es gibt Möglichkeiten, die Schreibvorgänge auf die SD zu begrenzen, damit die Karte länger hält, wie unnötiges Logging ausschalten, dphys-swapfile deaktivieren, oder nach dem Einrichten OverlayFS aktivieren. Karten von Transcend habe ich schon längst entsorgt, Sandisk und Samsung sollen länger halten, aber vorsicht, es gibt viele Fälschungen, also lieber im Laden deines Vertrauens kaufen.

  • Es gibt Möglichkeiten, die Schreibvorgänge auf die SD zu begrenzen, damit die Karte länger hält,

    Begrenzen kann das nur der Admin, der die "lifetime writes" im Superblock überwacht (z.B. mit dumpe2fs -h ) und dann das Filesystem auf r-only setzt.

    Gleichmässige Schreibzugriffe über den gesamten Bereich besorgt Trim, wenn das Speichergerät trim-fähig ist. Das ist auch bei SDs manchmal der Fall.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Also ich finde 1,5 Jahre sind ein guter Wert. In dieser Zeit hast Du massig Zeit ein oder mehrere Backups zu machen um dann bei den ersten Anzeichen einer Ermüdung die SD Karte zu wechseln.

  • Also ich finde 1,5 Jahre sind ein guter Wert.

    Das ist ja relativ, da die Zeit nur eine Variable ist. Wie RTFM geschrieben hat, müsste man die lifetime writes der SD Karte mit dem zu erwartenden maximal Wert abgleichen. An was man sich da richtet (Herstellerangabe, Erfahrungswerte, ...), weiss ich allerdings nicht. Meine 16 GB SD (3 Jahre in Benutzung) hat z.B. Lifetime writes: 588 GB. Der tatsächliche Wert liegt aber wohl um einige GB höher, da ein (oder mehrere) schreiben von Image Datein auf die Karte nicht mitgezählt werden können. Grob gerechnet wurde meine SD ca. 43 mal komplett beschrieben. Nach einer kurzen Suche nach Haltbarkeit, habe ich Werte für Schreibzyklen von 1.000 bis 1.000.000 gefunden. Wenn ich von 1.000 Schreibzyklen ausgehe, dann dürfte bei gleichbleibender Nutzung, die SD noch ca. 23 Jahre halten (theoretisch).

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!