Gentoo Archives: gentoo-user

From: Fabio Scaccabarozzi <fsvm88@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] The sudden disappearance of ....WHAT??? (I/O error on a SD flash card?!)
Date: Sun, 26 Mar 2017 09:55:04
Message-Id: CADNbXsX43E7_2vOd7ix4TRJw0GAC60_+gX5kdRSYL39qpt1zdg@mail.gmail.com
In Reply to: Re: [gentoo-user] The sudden disappearance of ....WHAT??? (I/O error on a SD flash card?!) by tuxic@posteo.de
1 Hi tuxic,
2
3 That looks like an output from photorec. Generally photorec only reads the
4 whole disk block by block, when it finds information in the filesystem's
5 metadata - either inode table or inodes themselves - you're lucky and you
6 get filenames, otherwise you only get that kind of output. Consider that
7 all those items might as well be deleted items, so you might be getting
8 back a lot of cruft.
9 I never had to use the functionality so I cannot comment on how good it
10 works, but testdisk allows you to restore partitions by scanning the entire
11 disk/image searching for superblocks and partition metadata. That might
12 give you a chance of restoring the superblock of the partition and
13 salvaging at least some part of the data. See a guide on testdisk's
14 official website -> http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
15 Consider that by default ext4 partitions should have superblock backups
16 spread out at fixed intervals during the filesystem creation, so this
17 should work better than trying to blindly carve the data out of the
18 partition.
19 Before applying fixes to the image file make a backup in case something
20 gets screwed up :-) Testdisk might detect additional stuff that looks like
21 partition info, but it's not.
22
23 Il giorno dom 26 mar 2017 alle ore 11:37 <tuxic@××××××.de> ha scritto:
24
25 > On 03/26 08:10, Adam Carter wrote:
26 > > > Currently I am ddresucueing the flashcard to the harddisc.
27 > > >>> Next I will try to mount the sdcard.
28 > > >>>
29 > > >>>
30 > > I hope you meant to say "mount the sdcard image". Once ddrescue has done
31 > > its best, you wont try to use the sdcard again.
32 > >
33 > > Also, you probably want to copy the image first, because when you try to
34 > > fix it you will perform writes, and you dont want to lock yourself out of
35 > > other recovery options by making potentially damaging writes.
36 > >
37 > >
38 > > > What reliable sdcard-reader can one recommend ?
39 > > >>>
40 > > >>
41 > > I'm not sure what you mean here given that you're making an image with
42 > > ddrescue.
43 > >
44 > > Is the assumption correct, that -- if ddrescue could read each
45 > > >> partitions of the sdcard without stuttering, retries and errors --
46 > > >>
47 > > > the sdcard itsself is ok and "only" the logical structure
48 > > >> (fs, superblock etc) got damaged?
49 > > >> Or do I overlook something?
50 > > >>
51 > > >
52 > > If ddrescue can read it cleanly with no retries (in which case it will
53 > > offer no benefit over dd) then yes, I agree. However, given the cost of a
54 > > card and the cost of your time and the risk to your data, I wouldnt be
55 > > using it.
56 > >
57 > >
58 > > > I dont know of a cdparanoia type recovery utility for sdcards but I
59 > > > suspect sdcard design means that approach wont work.
60 > > >
61 > >
62 > > I would just use photorec against a copy of the image. I have done this
63 > in
64 > > the past and recovered many files from a ddrescued image of a failing USB
65 > > drive, however, all the filenames were lost.
66 >
67 > Hi,
68 >
69 > I copied the image of course and umounted the sdcard as soon as
70 > possible.
71 >
72 > As in my previous posting, as long the recovered files are images,
73 > the lost of filenames my be annoying...
74 > But in case of files of a Android system (from which the sdcard
75 > originates) the lost of filenames is equivaltent to the lost of
76 > the file itsself...
77 >
78 > Cheers
79 > Meino
80 >
81 >
82 >
83 >
84 >