• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Datenrettung SD-Card

gehrke

gehrke

Administrator
Teammitglied
Moin *,

mir ist mein Raspberry abgeraucht, ist jedenfalls per ssh nicht mehr zu erreichen.

Bei der Ursachenforschung stolpere ich über eine scheinbar kaputte SD-Card, auf welcher das OS installiert ist.

EDIT: Die goldene Regel bei Datenrettungsversuchen lautet, so wenig wie möglich mit dem Original zu arbeiten, um weitere Beschädigungen zu vermeiden. Aus diesem Grund möchte ich eine exakte Kopie (Image) erstellen und die weiteren Schritte darauf anwenden.

Eingeschoben in einen PC zeigen sich Fehlermeldungen in den Logs und der Versuch, per dd ein Image zu ziehen scheitert mit der Meldung:
Code: 
dd: error reading ‘/dev/sde’: Input/output error

Also versuche ich es mal mit dd_rescue, welches laut Linupedia das Mittel der Wahl ist, weil es bei Fehlern nicht blockiert, sondern Nullen schreibt:
Code: 
j2:~ # dd_rescue /dev/sde /home/gehrke/images/kali-20150531-rescue.img
dd_rescue: (info): Using softbs=131072, hardbs=4096
dd_rescue: (info): expect to copy 15558144kB from /dev/sde
dd_rescue: (info): ipos:     63324.0k, opos:     63324.0k, xferd:     63324.0k
                *  errs:      0, errxfer:         0.0k, succxfer:     63324.0k
             +curr.rate:    11511kB/s, avg.rate:     2283kB/s, avg.load:  0.4%
             >-........................................<   0%  ETA:  0:24:11 
dd_rescue: (warning): read /dev/sde (63324.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 15831 
dd_rescue: (info): ipos:     63328.0k, opos:     63328.0k, xferd:     63328.0k
                *  errs:      1, errxfer:         4.0k, succxfer:     63324.0k
             +curr.rate:     8633kB/s, avg.rate:     1992kB/s, avg.load:  0.4%
             >x........................................<   0%  ETA:  0:25:14 
dd_rescue: (warning): read /dev/sde (63328.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 15832 
dd_rescue: (info): ipos:     74716.0k, opos:     74716.0k, xferd:     74716.0k
                *  errs:      2, errxfer:         8.0k, succxfer:     74708.0k
             +curr.rate:     4554kB/s, avg.rate:     1510kB/s, avg.load:  0.3%
             >x........................................<   0%  ETA:  0:29:40 
dd_rescue: (warning): read /dev/sde (74716.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 18679 
dd_rescue: (info): ipos:     74720.0k, opos:     74720.0k, xferd:     74720.0k
                *  errs:      3, errxfer:        12.0k, succxfer:     74708.0k
             +curr.rate:     3416kB/s, avg.rate:     1396kB/s, avg.load:  0.3%
             >x........................................<   0%  ETA:  0:30:44 
dd_rescue: (warning): read /dev/sde (74720.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 18680 
dd_rescue: (info): ipos:     96172.0k, opos:     96172.0k, xferd:     96172.0k
                *  errs:      4, errxfer:        16.0k, succxfer:     96156.0k
             +curr.rate:     4289kB/s, avg.rate:     1320kB/s, avg.load:  0.3%
             >x........................................<   0%  ETA:  0:37:15 
dd_rescue: (warning): read /dev/sde (96172.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 24043 
dd_rescue: (info): ipos:   1387972.0k, opos:   1387972.0k, xferd:   1387972.0k
                *  errs:      5, errxfer:        20.0k, succxfer:   1387952.0k
             +curr.rate:     4416kB/s, avg.rate:     5314kB/s, avg.load:  2.5%
             >x---.....................................<   8%  ETA:  0:37:31 
dd_rescue: (warning): read /dev/sde (1387972.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 346993 
dd_rescue: (info): ipos:   1387976.0k, opos:   1387976.0k, xferd:   1387976.0k
                *  errs:      6, errxfer:        24.0k, succxfer:   1387952.0k
             +curr.rate:     3312kB/s, avg.rate:     5233kB/s, avg.load:  2.4%
             >x--x.....................................<   8%  ETA:  0:38:28 
dd_rescue: (warning): read /dev/sde (1387976.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 346994 
dd_rescue: (info): ipos:   1388016.0k, opos:   1388016.0k, xferd:   1388016.0k
                *  errs:      7, errxfer:        28.0k, succxfer:   1387988.0k
             +curr.rate:     2487kB/s, avg.rate:     5152kB/s, avg.load:  2.4%
             >x--x.....................................<   8%  ETA:  0:39:25 
dd_rescue: (warning): read /dev/sde (1388016.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 347004 
dd_rescue: (info): ipos:   1388020.0k, opos:   1388020.0k, xferd:   1388020.0k
                *  errs:      8, errxfer:        32.0k, succxfer:   1387988.0k
             +curr.rate:     1865kB/s, avg.rate:     5002kB/s, avg.load:  2.3%
             >x--x.....................................<   8%  ETA:  0:40:39 
dd_rescue: (warning): read /dev/sde (1388020.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 347005 
dd_rescue: (info): ipos:   1429888.0k, opos:   1429888.0k, xferd:   1429888.0k
                *  errs:      9, errxfer:        36.0k, succxfer:   1429852.0k
             +curr.rate:     4364kB/s, avg.rate:     4839kB/s, avg.load:  2.2%
             >x--x.....................................<   9%  ETA:  0:40:45 
dd_rescue: (warning): read /dev/sde (1429888.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 357472 
dd_rescue: (info): ipos:   1429972.0k, opos:   1429972.0k, xferd:   1429972.0k
                *  errs:     10, errxfer:        40.0k, succxfer:   1429932.0k
             +curr.rate:     3278kB/s, avg.rate:     4773kB/s, avg.load:  2.2%
             >x--x.....................................<   9%  ETA:  0:41:45 
dd_rescue: (warning): read /dev/sde (1429972.0k): Input/output error!
dd_rescue: (warning): Bad block reading /dev/sde: 357493 
dd_rescue: (info): ipos:  15556608.0k, opos:  15556608.0k, xferd:  15556608.0k
                   errs:     11, errxfer:        44.0k, succxfer:  15556564.0k
             +curr.rate:     6164kB/s, avg.rate:     6406kB/s, avg.load:  3.1%
             >x--x------------------------------------.<  99%  ETA:  0:00:00 
dd_rescue: (info): read /dev/sde (15558144.0k): EOF
dd_rescue: (info): Summary for /dev/sde -> /home/gehrke/images/kali-20150531-rescue.img
dd_rescue: (info): ipos:  15558144.0k, opos:  15558144.0k, xferd:  15558144.0k
                   errs:     11, errxfer:        44.0k, succxfer:  15558100.0k
             +curr.rate:     5380kB/s, avg.rate:     6405kB/s, avg.load:  3.1%
             >x--x------------------------------------.<  99%  TOT:  0:40:29
Der komplette Prozess dauerte tatsächlich 40 Minuten.

Dann habe ich versucht, dieses Images zu mounten - ich vermute die interessanten Files auf 'sde2':
Code: 
j2:~ # modprobe loop
j2:~ # kpartx -va /home/gehrke/images/kali-20150531-rescue.img
add map loop0p1 (253:7): 0 125000 linear /dev/loop0 1
add map loop0p2 (253:8): 0 6018999 linear /dev/loop0 125001
add map loop0p3 (253:9): 0 2 linear /dev/loop0 6144000

j2:~ # mount -o loop,ro /dev/mapper/loop0p2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
Das war schon mal ein Fehlschlag - mit 'sde1' (boot-Partition) funktioniert das übrigens. Dateisystem müsste 'ext4' sein.

Natürlich habe ich von diesem System kein aktuelles Backup, maximal ein älteres Image. Das System werde ich wohl wieder hinfrickeln können, aber ich hoffe sehr, dass ich noch an die restlichen Daten komme.

Der Versuch, dass kaputte Dateisystem zu reparieren brachte scheinbar den Erfolg:
Code: 
j2:~ # fsck.ext4 /dev/mapper/loop0p2
e2fsck 1.42.8 (20-Jun-2013)
/dev/mapper/loop0p2: recovering journal
Setting free inodes count to 112594 (was 112647)
Setting free blocks count to 4097 (was 379256)
/dev/mapper/loop0p2: clean, 75822/188416 files, 748277/752374 blocks

j2:~ # mount -o loop,ro /dev/mapper/loop0p2 /mnt
Ich kann tatsächlich wieder auf einen Teil der Daten zugreifen. Scheinbar ist das System schon am 13.03. verstorben. Der nächste Pi wird ein Nagios...


cu, gehrke
 
/dev/null

/dev/null

Moderator
Teammitglied
Hallo gehrke,

Der nächste Pi wird ein Nagios...
Zum Vergrößern anklicken....
Ob das die Lösung ist?

Wenn du dich im Raspi-Forum (http://www.forum-raspberrypi.de) umschaust, wirst du feststellen, dass du in guter Gesellschaft bist. So mancher schreibt von "Halbwertszeiten" seiner SD-Cards, welche bei einem halben Jahr und weniger liegen. Tödlich ist zum Bsp., wenn ein RasPi einfach so durch Ziehen des Netzsteckers hart beendet wird. (Deshalb haben meine alle eine kleine Taste, mit denen ich sie mit einem Klick sauber herunterfahren kann).
Und du wirst dann auch davon lesen, dass der Einsatz einer SD-Card für ein Betriebssystem eigentlich überhaupt nicht das ist, wofür dieser Datenträger eigentlich entwickelt und produziert wurde. Ich möchte nur die unablässigen Schreibvorgänge nennen, welche Linux schon mit seinen vielen Logdateien macht. Die Digitalkamera macht das nicht ... .
Auch wirst du Tipps finden, wie du zum Bsp. bestimmte Bereiche "in den RAM" mounten kannst, was rein theoretisch der SD ein längeres Leben bringen könnte.


Ob es viel bringt, noch ein paar Daten zu retten, wage ich zu bezweifeln. Kommt ja auch darauf an, was du an Daten drauf hattest. Und was ich da so lese, hast du ja schon so ziemlich alles getan ... .

Ich habe mir angewöhnt:
1.) Jedes Image wird schon während der Installation wenigstens 2-3 mal per dd auf die Platte kopiert. Und dann natürlich noch einmal, wenn alles fertig ist. So kann ich jederzeit einen Zwischenschritt zurückspielen, wenn mal was schief ging bzw. eine neue SD mit dem OS und den Programmen bespielen.
2.) Die Daten des einen RasPi, welcher wirklich Daten hostet (meine Kombination aus Seafile und Radicale) werden jeden Abend vollautomatisch auf mein NAS gesichert.
Ergebnis: Eine totgegangene SD kostet mich den Kaufpreis und max. eine Stunde "Arbeit" - und alles ist wie vorher.

Ach ja, meine drei RasPi hängen gemeinsam mit dem NAS und dem Router an einer USV ... .


MfG Peter
 
OP
gehrke

gehrke

Administrator
Teammitglied
/dev/null schrieb:
Der nächste Pi wird ein Nagios...
Zum Vergrößern anklicken....
Ob das die Lösung ist?
Zum Vergrößern anklicken....
Natürlich ist das die Lösung - allerdings wohl nur für das Problem, dass ich den Ausfall erst nach 2 Monaten mitbekomme...

/dev/null schrieb:
Wenn du dich im Raspi-Forum (http://www.forum-raspberrypi.de) umschaust, wirst du feststellen, dass du in guter Gesellschaft bist. So mancher schreibt von "Halbwertszeiten" seiner SD-Cards, welche bei einem halben Jahr und weniger liegen. Tödlich ist zum Bsp., wenn ein RasPi einfach so durch Ziehen des Netzsteckers hart beendet wird. (Deshalb haben meine alle eine kleine Taste, mit denen ich sie mit einem Klick sauber herunterfahren kann).
Zum Vergrößern anklicken....
Das ist ein guter Hinweis. In diesem konkreten Fall war das zwar nicht so, aber ich habe einen weiteren Pi mit Kodi darauf, den ich an den USB-Port des TV für die Stromversorgung angeklemmt habe (war keine Dose mehr frei). Bei jedem Ausschalten des TVs ist der auch ausgeknipst, das wird wohl nicht lange gut gehen. Zu meiner Ehrenrettung speichert der aber keine Daten lokal und ich habe ein Image, weil ich mir schon gedacht habe, dass das nicht so ganz gut ist.

/dev/null schrieb:
Und du wirst dann auch davon lesen, dass der Einsatz einer SD-Card für ein Betriebssystem eigentlich überhaupt nicht das ist, wofür dieser Datenträger eigentlich entwickelt und produziert wurde. Ich möchte nur die unablässigen Schreibvorgänge nennen, welche Linux schon mit seinen vielen Logdateien macht. Die Digitalkamera macht das nicht ... .
Auch wirst du Tipps finden, wie du zum Bsp. bestimmte Bereiche "in den RAM" mounten kannst, was rein theoretisch der SD ein längeres Leben bringen könnte.
Zum Vergrößern anklicken....
Yepp. Das habe ich auch gelesen und bin das Risiko trotzdem bewusst eingegangen (es fehlte die Zeit, das ordentlich zu machen. Das rächt sich immer auf lange Sicht). Ist ca. 1 1/2 Jahre gut gegangen, nun hat es mich erwischt.
/dev/null schrieb:
1.) Jedes Image wird schon während der Installation wenigstens 2-3 mal per dd auf die Platte kopiert. Und dann natürlich noch einmal, wenn alles fertig ist. So kann ich jederzeit einen Zwischenschritt zurückspielen, wenn mal was schief ging bzw. eine neue SD mit dem OS und den Programmen bespielen.
Zum Vergrößern anklicken....
Das ist immer ein guter Tipp. Ein solches Image habe ich auch, das System würde ich damit recht schnell wieder ans Fliegen bekommen. Die Config müsste auch aktuell in meinem GIT-Server liegen, soweit alles im Lack. Was mir fehlen würde wären aktuelle Logs und die Bash-History.

/dev/null schrieb:
2.) Die Daten des einen RasPi, welcher wirklich Daten hostet (meine Kombination aus Seafile und Radicale) werden jeden Abend vollautomatisch auf mein NAS gesichert.
Zum Vergrößern anklicken....
Steht seit Monaten auf meiner Todo-Liste...
TNX
 
framp

framp

Moderator
Teammitglied
Eine Raspi ohne regelmäßiges Backup sollte man nur als Spielsystem betreiben :fies: . Da bei mir zwei in Produktion laufen habe ich mir ein kleines BackupScript raspiBackup geschrieben welches eine beliebige Anzahl von Backups erstellen und vorhalten kann. Ein paar Mal musste ich schon auf das Backup zurückgreifen :eek:0: .
Nachdem ich das dann auch im Netz der Community zur Verfügung gestellt habe wird es mittlerweile recht häufig benutzt. Es wurden eine Menge weitere Features von der Community nachgefragt und dann auch von mir eingebaut. Es ist mittlerweile recht umfangreich und flexibel.
Du kannst es Dir ja mal ansehen ;)
 
S

spoensche

Moderator
Teammitglied
Das Problem ist ein Journaling Dateisystem das fleisig Schreibvorgänge auf der SD-Card erzeugt, diese aber nicht dafür ausgelegt ist.
Für eine längere "Halbwertszeit" der SD-Card muss also ein Flashspeicher-Freundliches FS verwendet werden.

Dazu gehören z.B. JFS (Journal Flash Filesystem) oder das neue von Samsung, was den Kernelentwicklern übergben worden ist.
Verflixt wie heisst es denn noch gleich?? :???:

EDIT:
F2FS
 
/dev/null

/dev/null

Moderator
Teammitglied
@framp:

Perfekt! Einfach Spitze!
Hier meine ersten beiden Versuche vom heutigen Abend:
Code: 
root@seafile:/usr/local/bin# ./raspiBackup.sh -t tar -p /media/nas-backup/
--- RBK0009I: seafile: raspiBackup.sh V0.5.15 started at Sat Jun  6 20:24:52 CEST 2015
--- RBK0010I: seafile: raspiBackup.sh V0.5.15 stopped at Sat Jun  6 20:40:11 CEST 2015
--- RBK0017I: Backup finished successfully
root@seafile:/usr/local/bin# ./raspiBackup.sh -t rsync -p /media/nas-backup/
--- RBK0009I: seafile: raspiBackup.sh V0.5.15 started at Sat Jun  6 20:41:43 CEST 2015
--- RBK0049W: Some files were changed or vanished during backup. RC: 23 - ignoring change
--- RBK0010I: seafile: raspiBackup.sh V0.5.15 stopped at Sat Jun  6 21:17:29 CEST 2015
--- RBK0017I: Backup finished successfully
root@seafile:/usr/local/bin#

Ergebnis der Versuche: Noch etwas Feinarbeit bei mir erforderlich (meine Syno läuft nicht durch, sondern startet täglich 19:30, nimmt per dirvisch die Sicherung aller meiner /home entgegen und legt sich wieder vollständig schlafen). Deswegen nutze ich auf meinen 3 Rechnern autofs, um keine hängenden Mounts zu bekommen. Auf dem RasPi werde ich in die Startscripts mount und umount einbauen. Aber das ist alles nur noch Kleinkram.

Auf jeden Fall hat es riesigen Spaß gemacht, mit deinem Script zu basteln! DANKE!


MfG Peter
 
framp

framp

Moderator
Teammitglied
Freut mich, dass es bei Dir auch hilft. Hast Du den Restore schon getestet ;) ?

Es ist eine interessante Erfahrung wenn man ein Backupscript - nur für privaten Gebrauch erstellt - der Community mal einfach so zum Download zur Verfügung stellt - und dann lernt welche anderen Bedürfnisse in der Community beim Backup bestehen und nachgefragt werden. Implementiert man die entsteht ein ganz nützliches und variables Tool :)
 
/dev/null

/dev/null

Moderator
Teammitglied
(ich hoffe mal, dass gehrke es uns nicht übel nimmt, wenn wir hier einfach so seinen Thread kapern ;-))

Hi framp,

Hast Du den Restore schon getestet ;) ?
Zum Vergrößern anklicken....
Schau dir mal die Zeit an, wo mein zweites Test-Backup fertig war ... .

Ich bin mir auch noch gar nicht mal so sicher, wie ich jetzt weiter vorgehen werde. Ich habe ausgerechnet gestern Nachmittag (!) einen 16GB USB-Stick eingebunden und direkt als /home aller drei Nutzer (pi, radicale und seafile) gemounted. Selbstverständlich ist alles sauber in der Sicherung zu sehen.
Bislang hatte ich lediglich die reinen Daten von radicale und seafile (täglich automatisch) gesichert. Und vorher das letzte "produktive" Image, bevor die Daten gehostet wurden. Im Fehlerfall also dieses Image auf eine neue SD, System aktualisieren und dann die Daten aus der Sicherung zurückspielen. Das hatte ich natürlich getestet.

Wie ich jetzt weiter mache, und ob das mit dem USB-Stick überhaupt eine so gute Idee war, weiß ich noch nicht. Vielleicht hast du eine Idee dazu?
Meine Nutzung des kleinen Spielzeugs ist recht schreiblastig. Ich habe von meinen drei Rechnern und jeweils zwei Konten fast das gesamte /home (bis auf die riesige Bildersammlung, meine 4,xGB-Sicherheitskopien, Mediathek-"Sicherungen" und weitere fette Sachen), aber die TB- und Fx-Profile, alle Dokumente usw. alles mit seafile synchronisiert. Also fast genau so, wie wir das von einem servergestützten Profil aus der Firma kennen. Und mit radicale synchronisiere ich meine vielen Kalender (.ics) und auch die Adressbücher. So sind Kalender und AB nicht nur auf den 6 TB-Installationen, sondern auch noch auf dem Schlau-Fernsprechapparat ständig synchron. (Dass das ganze außerhäusig über ein IPsec-VPN läuft, erwähne ich nur am Rande.)
Das alles funktioniert schon recht lange - so lange ich den ersten Pi habe. Es ist sogar noch ein "alter" Pi B, welcher dafür völlig ausreicht. Und sogar noch mit der ersten SD, welche mit in dem Bundle war ... .

MfG Peter
 
OP
gehrke

gehrke

Administrator
Teammitglied
/dev/null schrieb:
(ich hoffe mal, dass gehrke es uns nicht übel nimmt, wenn wir hier einfach so seinen Thread kapern ;-))
Zum Vergrößern anklicken....
Passt schon. Mir ging es ursprünglich nur um den Rettungsprozess. Erst glaubte ich, Hilfe zu brauchen, aber dann habe ich es selbst hinbekommen. Da hatte ich den Text aber schon geschrieben und dachte mir, schadet ja nicht, wenn ich das poste. Und sei es als Ausgangsbasis für so was hier...
 
framp

framp

Moderator
Teammitglied
Der erste rsync Lauf dauert zwangsläufig lange. Aber die folgenden Läufe sind schon viel schneller, da ja nur die geänderten Daten gesichert werden. Deshalb empfehle ich auch immer rsync zu nehmen und nicht dd oder tar. Da es aber Leute gibt, die einfach ein dd oder tar als Backup haben wollen ist das aber auch verfügbar.

USB Sticks halten länger. Wenn Du alles ausser der Bootpartition dort rüberkopierst wird die SD Karte nur noch zum Booten und lesenderweise genutzt. Dann hält die SD Karte ewig :)

Zum Umziehen auf USB Stick habe ich übrigends auch noch ein Script geschrieben ;)
 
/dev/null

/dev/null

Moderator
Teammitglied
Ja, das mit dem rsync ist schon wohlbekannt. Das von mir schon recht lange genutzte "dirvish" hat ja auch rsync "unter der Haube". Ich habe gerade mal nachgesehen - ich habe seit über drei Jahren ein tägliches "Vollbackup" meiner /home auf der Platte. Wobei das meiste davon aus Hardlinks bestehen dürfte. Aber ich kann eben jederzeit das Backup eines bestimmten Tages nehmen und das System ist so, wie an jenem Tag.

Zurück zum Pi.
Die Idee, dass komplette System auf den USB-Stick zu nehmen, ist auch ganz reizvoll. Dann könnte ich das alles auch auf eine USB-HD kopieren. Habe zufällig noch eine ungenutzte mit stolzen 40GB herumzuliegen. Dafür wäre sie bestens geeignet. Und dann noch ein bis zwei zusätzliche "Boot-SD". Muss nur sehen, was das Teil für Strom verbraucht. Ein zusätzliches Netzteil wäre kontraproduktiv.

Aber jetzt läuft es erst mal so, wie es ist. Von /home habe ich eine aktuelle Sicherung und das reicht mir vorerst.

In der nächsten Woche ziehen wir erst mal aus NRW zurück in meine alte sächsische Heimat. Dann werde ich wohl erst einmal für meine Hobbys ein paar Wochen wenig Zeit haben. Und danach sehen wir weiter ... .


MfG Peter
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben