1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="/includes/stylesheet.css" />
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta
property="og:description"
content="The World Wide Web pages of Adam Carpenter"
/>
<meta property="og:image" content="https://nextcloud.53hor.net/index.php/s/Nx9e7iHbw4t99wo/preview" />
<meta property="og:site_name" content="53hor.net" />
<meta property="og:title" content="How I Do Data Recovery" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://www.53hor.net" />
<title>53hornet ➙ How I Do Data Recovery</title>
</head>
<body>
<nav>
<ul>
<li>
<a href="/">
<img src="/includes/icons/home-roof.svg" />
Home
</a>
</li>
<li>
<a href="/info.html">
<img src="/includes/icons/information-variant.svg" />
Info
</a>
</li>
<li>
<a href="https://git.53hor.net">
<img src="/includes/icons/git.svg" />
Repos
</a>
</li>
<li>
<a href="/hosted.html">
<img src="/includes/icons/desktop-tower.svg" />
Hosted
</a>
</li>
<li>
<a type="application/rss+xml" href="/rss.xml">
<img src="/includes/icons/rss.svg" />
RSS
</a>
</li>
</ul>
</nav>
<article>
<h1>How I Do Data Recovery</h1>
<p>
This week Amy plugged in her flash drive to discover that there were no
files on it. Weeks before there had been dozens of large cuts of footage
that she needed to edit down for work. Hours of recordings were
seemingly gone. And the most annoying part was the drive had worked
perfectly on several other occasions. Just not now that the footage was
actually needed of course. Initially it looked like everything had been
wiped clean, however both Amy's Mac and her PC thought the drive was
half full. It's overall capacity was 64GB but it showed only about 36GB
free. So there still had to be data on there if we could find the right
tool to salvage it.
</p>
<p>
Luckily this wasn't the first time I had to recover accidentally (or
magically) deleted files. I had previously done so with some success at
my tech support job, for some college friends, and for my in-laws'
retired laptops. So I had a pretty clear idea of what to expect. The
only trick was finding a tool that knew what files it was looking for.
The camera that took the video clips was a Sony and apparently they
record into <code>m2ts</code> files, which are kind of a unique format
in that they only show up on Blu-Ray discs and Sony camcorders. Enter my
favorite two tools for dealing with potentially-destroyed data:
<code>ddrescue</code> and <code>photorec</code>.
</p>
<h2>DDRescue</h2>
<p>
<code>ddrescue</code> is a godsend of a tool. If you've ever used
<code>dd</code> before, forget about it. Use <code>ddrescue</code>. You
might as well <code>alias dd=ddrescue</code> because it's that great. By
default it has a plethora of additional options, displays the progress
as it works, recovers and retries in the event of I/O errors, and does
everything that good old <code>dd</code> can do. It's particularly good
at protecting partitions or disks that have been corrupted or damaged by
rescuing undamaged portions first. Oh, and have you ever had to cancel a
<code>dd</code> operation? Did I mention that <code>ddrescue</code> can
pause and resume operations? It's that good.
</p>
<h2>PhotoRec</h2>
<p>
<code>photorec</code> is probably the best missing file recovery tool
I've ever used in my entire life. And I've used quite a few. I've never
had as good results as I've had with <code>photorec</code> with other
tools like Recuva et. al. And <code>photorec</code> isn't just for
photos, it can recover documents (a la Office suite), music, images,
config files, and videos (including the very odd
<code>m2ts</code> format!). The other nice thing is
<code>photorec</code> will work on just about any source. It's also free
software which makes me wonder why there are like $50 recovery tools for
Windows that look super sketchy.
</p>
<h2>In Practice</h2>
<p>
So here's what I did to get Amy's files back. Luckily she didn't write
anything out to the drive afterward so the chances (I thought) were
pretty good that I would get <em>something</em> back. The first thing I
always do is make a full image of whatever media I'm trying to recover
from. I do this for a couple of reasons. First of all it's a backup. If
something goes wrong during recovery I don't have to worry about the
original, fragile media being damaged or wiped. Furthermore, I can work
with multiple copies at a time. If it's a large image that means
multiple tools or even multiple PCs can work on it at once. It's also
just plain faster working off a disk image than a measly flash drive. So
I used <code>ddrescue</code> to make an image of Amy's drive.
</p>
<pre><code>
$ sudo ddrescue /dev/sdb1 amy-lexar.dd
GNU ddrescue 1.24
Press Ctrl-C to interrupt
ipos: 54198 kB, non-trimmed: 0 B, current rate: 7864 kB/s
opos: 54198 kB, non-scraped: 0 B, average rate: 18066 kB/s
non-tried: 63967 MB, bad-sector: 0 B, error rate: 0 B/s
rescued: 54198 kB, bad areas: 0, run time: 2s
pct rescued: 0.08%, read errors: 0, remaining time: 59m
time since last successful read: n/a
Copying non-tried blocks... Pass 1 (forwards)
</code></pre>
<p>
The result was a very large partition image that I could fearlessly play
around with.
</p>
<pre>
<code>
$ ll amy-lexar.dd
-rw-r--r-- 1 root root 60G Sep 24 02:45 amy-lexar.dd
</code>
</pre>
<p>
Then I could run <code>photorec</code> on the image. This brings up a
TUI with all of the listed media that I can try and recover from.
</p>
<pre><code>
$ sudo photorec amy-lexar.dd
PhotoRec 7.0, Data Recovery Utility, April 2015
http://www.cgsecurity.org
PhotoRec is free software, and
comes with ABSOLUTELY NO WARRANTY.
Select a media (use Arrow keys, then press Enter):
>Disk amy-lexar.dd - 64 GB / 59 GiB (RO)
>[Proceed ] [ Quit ]
Note:
Disk capacity must be correctly detected for a successful recovery.
If a disk listed above has incorrect size, check HD jumper settings, BIOS
detection, and install the latest OS patches and disk drivers.
</code></pre>
<p>
After hitting proceed <code>photorec</code> asks if you want to scan
just a particular partition or the whole disk (if you made a whole disk
image). I can usually get away with just selecting the partition I know
the files are on and starting a search.
</p>
<pre><code>
PhotoRec 7.0, Data Recovery Utility, April 2015
http://www.cgsecurity.org
Disk amy-lexar.dd - 64 GB / 59 GiB (RO)
Partition Start End Size in sectors
Unknown 0 0 1 7783 139 4 125042656 [Whole disk]
> P FAT32 0 0 1 7783 139 4 125042656 [NO NAME]
>[ Search ] [Options ] [File Opt] [ Quit ]
Start file recovery
</code></pre>
<p>
Then <code>photorec</code> asks a couple of questions about the
formatting of the media. It can usually figure them out all by itself so
I just use the default options unless it's way out in left field.
</p>
<pre><code>
PhotoRec 7.0, Data Recovery Utility, April 2015
http://www.cgsecurity.org
P FAT32 0 0 1 7783 139 4 125042656 [NO NAME]
To recover lost files, PhotoRec need to know the filesystem type where the
file were stored:
[ ext2/ext3 ] ext2/ext3/ext4 filesystem
>[ Other ] FAT/NTFS/HFS+/ReiserFS/...
</code></pre>
<p>
Now this menu is where I don't just go with the default path.
<code>photorec</code> will offer to search just unallocated space or the
entire partition. I always go for the whole partition here; sometimes
I'll get back files that I didn't really care about but more often than
not I end up rescuing more data this way. In this scenario searching
just unallocated space found no files at all. So I told
<code>photorec</code> to search everything.
</p>
<pre><code>
PhotoRec 7.0, Data Recovery Utility, April 2015
http://www.cgsecurity.org
P FAT32 0 0 1 7783 139 4 125042656 [NO NAME]
Please choose if all space need to be analysed:
[ Free ] Scan for file from FAT32 unallocated space only
>[ Whole ] Extract files from whole partition
</code></pre>
<p>
Now it'll ask where you want to save any files it finds. I threw them
all into a directory under home that I could zip up and send to Amy's
Mac later.
</p>
<pre><code>
PhotoRec 7.0, Data Recovery Utility, April 2015
Please select a destination to save the recovered files.
Do not choose to write the files to the same partition they were stored on.
Keys: Arrow keys to select another directory
C when the destination is correct
Q to quit
Directory /home/adam
drwx------ 1000 1000 4096 28-Sep-2019 12:10 .
drwxr-xr-x 0 0 4096 26-Jan-2019 15:32 ..
>drwxr-xr-x 1000 1000 4096 28-Sep-2019 12:10 amy-lexar-recovery
</code></pre>
<p>
And then just press <code>C</code>. <code>photrec</code> will start
copying all of the files it finds into that directory. It reports what
kinds of files it found and how many it was able to locate. I was able
to recover all of Amy's lost footage this way, past, along with some
straggler files that had been on the drive at one point. This has worked
for me many times in the past, both on newer devices like flash drives
and on super old, sketchy IDE hard drives. I probably won't ever pay for
data recovery unless a drive has been physically damaged in some way. In
other words, this software works great for me and I don't foresee the
need for anything else out there. It's simple to use and is typically
pretty reliable.
</p>
</article>
</body>
</html>
|
