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 |
> |