summaryrefslogtreecommitdiff
path: root/posts/2019-09-28-my-preferred-method-for-data-recovery.html
diff options
context:
space:
mode:
Diffstat (limited to 'posts/2019-09-28-my-preferred-method-for-data-recovery.html')
-rw-r--r--posts/2019-09-28-my-preferred-method-for-data-recovery.html276
1 files changed, 276 insertions, 0 deletions
diff --git a/posts/2019-09-28-my-preferred-method-for-data-recovery.html b/posts/2019-09-28-my-preferred-method-for-data-recovery.html
new file mode 100644
index 0000000..9751eda
--- /dev/null
+++ b/posts/2019-09-28-my-preferred-method-for-data-recovery.html
@@ -0,0 +1,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>