From bfaccc32571df8a02f69518d8864244efba3b5b5 Mon Sep 17 00:00:00 2001
From: 53hornet <atc@53hor.net>
Date: Wed, 28 Jul 2021 10:58:58 -0400
Subject: php site, templating and partials, faster index generation

---
 ...09-28-my-preferred-method-for-data-recovery.php | 224 +++++++++++++++++++++
 1 file changed, 224 insertions(+)
 create mode 100644 posts/2019-09-28-my-preferred-method-for-data-recovery.php

(limited to 'posts/2019-09-28-my-preferred-method-for-data-recovery.php')

diff --git a/posts/2019-09-28-my-preferred-method-for-data-recovery.php b/posts/2019-09-28-my-preferred-method-for-data-recovery.php
new file mode 100644
index 0000000..d7b68d2
--- /dev/null
+++ b/posts/2019-09-28-my-preferred-method-for-data-recovery.php
@@ -0,0 +1,224 @@
+<?php
+$title = "How I Do Data Recovery";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+<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>
-- 
cgit v1.2.3