<p>First, don't panic!</p>

<p>Second, make an image backup of the wiped drive to a physically different drive.</p>

<p>Third, you maybe able to recover the deleted files with tools such as <a href="http://www.irongeek.com/i.php?page=backtrack-3-man/magicrescue" rel="nofollow noreferrer">magic rescue</a> so long as the sectors on your drive that your wallet was wiped from are intact... otherwise you may be out those coins... I've had OK luck with rescuing data off drives for friends but also some failed attempts to because of rewritten blocks corrupting deleted data.</p>

<p>In other words this will cost you in either time or in the coins you've lost. Right now you're in <em>limbo</em> and I would suggest you do a <code>dd</code> backup of your wiped drive and try to use recovery tools on the backed up drive image so that you don't accedentaly wipe the target data off the original drive.</p>

<p>I'll see what I can find in my notes in a few hours on the subject of drive imaging and recovery for ya.</p>

<h2>Updates</h2>

<p>Here's an edited version of my private notes on data recovery steps that I've used to recently recover a corrupted USB drive that was being used to backup a client's Windows user account files. Note file names did get mangled during the process so be aware that there will be cleanup after this process.</p>

<h3>Setup</h3>

<ul>
<li><p>You'll need second drive with enough free space to house double the total number of bits of the target drive. Or in my case I had to get two drives of greater than 64gigs; one for the backup image and the other to receive recovered files. This is because we are going to be copying <strong>every</strong> bit off the target drive; even the zeros. In my case discussed here there was only 13~gigs used out of 63'ish but we still had to copy it all.</p></li>
<li><p>You'll need a USB or CD bootable Linux distribution. I used Kali Sana for my recovery because it has pretty up to date tools for this job but you might want to hunt for a specifically designed distro. Web search for terms like "USB recovery Linux distro" and you'll likely find a <em>top 10s</em> list of someone's testing results or recommendations; there be choices in flavor so I'll keep this based off my expenses with Kali.</p></li>
<li><p>You're going to need to locate the dev file path for your target drive, in this example it's <code>/dev/hda</code> but for you it maybe different. Hint use <code>mount</code> &amp; <code>blkid</code> commands to show drives, their file paths and other info. Once located unmount it so you're normal programs don't write or read from it by accident. For example my target drive was mounted at the following <code>umount</code> command directory path</p>

<p>umount /mnt/usb/damaged</p></li>
</ul>

<blockquote>
  <p>Repeat above for any mount points associated with
  the target drive to be backed-up. For my revival there
  was two partitions associated with <code>/dev/hda</code> physical
  drive and both had to be unmounted. Also be on the look
  out for <code>swap</code> partitions associated with the target; mine
  didn't but if you roll the next command with <strong>any</strong>
  of the target drive's mounted you run the risk of a bad
  backup image being made to work from.</p>
</blockquote>

<h3>Backup command</h3>

<pre><code>dd if=/dev/hda bs=4K conv=sync,noerror | tee mybackup.img | md5sum &gt; mybackup.md5
</code></pre>

<p>Be very <strong>very</strong> careful with the above because <code>dd</code> is not forgiving! Also note that the directory path is different than what was used with <code>umount</code> because we're now operating on the target drive a a whole and not a partition within the target drive. Hint, the previously mentioned  <code>mount</code> &amp; <code>blkid</code> commands used to reveal mounted directory paths should have shown the dev related path too.</p>

<ul>
<li><code>-if=/dev/sda</code> should be the drive location of the hard-drive you need to recover data from. Don't include any partition numbers as you'll want every bit from start to finish.</li>
<li><code>bs=4K</code> is the bite count per read/write (I think) and lower values will take longer but be less prone to errors.</li>
<li><code>conv=sync,noerror</code> are options to keep <code>dd</code> chugging away even if there's a bad sector or two.</li>
<li><code>| tee mybackup.img</code> redirects (and duplicates with <code>tee</code>) output from <code>dd</code> reading the target drive and saves it to <code>mybackup.img</code>. Note this fine path should <strong>not</strong> point to the drive your imaging; if you write to the same drive you'll likely wipe bits you want back for good from your drive because right now the addresses/sectors are marked as available for writing that use to contain your data.</li>
<li><code>| md5sum &gt; mybackup.md5</code> takes the duplicated output from <code>dd</code> and writes a signature to <code>mybackup.md5</code> same rules for file placement as the image file too.</li>
</ul>

<p>Now the above is going to take some time; for the 64~gigs I had to recover I used an RPi board (cheaper on the electric bill) and ran the above in <code>screen</code> for one full night and half a day. The above also isn't going to give you any feedback or process until it's done. In other words, grab a book or watch a season of Firefly to pass the time.</p>

<p>Eventually it'll report the number of <code>records</code> <code>in</code>/<code>out</code> and the time it took in seconds. And we can roll some tools over the backup image instead of on the target drive; this means mistakes can be made and you're just out the time of making another image.</p>

<p>To verify that the backup image you've saved is good you can run the md5 command against the image file and compare against the one generated during backup. Furthermore if really worried you can roll the md5 command against the target drive and compare that all three signatures/fingerprints are equivalent. The following are steps that I used to verify the image I took.</p>

<pre><code>dd if=/dev/hda bs=4K conv=sync,noerror | md5sum &gt; drive.md5
## Above should modified to point to your target drive
## Bellow should point to your backup image
dd if=mybackup.md5 bs=4K conv=sync,noerror | md5sum &gt; image.md5
</code></pre>

<p>Use <code>cat</code> to show the contents of each md5 file, they <em>should</em> all match or show the <strong>same</strong> human unrelated junk. Note for other readers, yes collisions (false matches) can happen but we're not trying to make any collisions so chances are low.</p>

<h3>Tips for keeping sanity on next steps</h3>

<ul>
<li>if you've the space then make a backup of your backup because it's safer that way and will save your target drive from any accidents when having to start a whole new <code>dd</code> command ;-) beware of sleepy terminal user input.</li>
<li>if possible unplug/disconnect the target drive or attempt the next block of steps on different hardware operating only on your backup image.</li>
<li>take your time at this point. There's little reason to rush at this point, well unless you liked waiting for the next backup image to complete. Not going to judge if that's what you're into.</li>
</ul>

<h3>Optional, install Windows partition compatibility</h3>

<pre><code>## For many Debian/Ubuntu based distributions
sudo apt-get install ntfs-3g
## Kali Sana
sudo apt-get install ntfs-config
## and some Ubuntu flavors
sudo apt-get install ntfsprogs
</code></pre>

<p>Using <code>apt-cache policy ntfs-3g</code>, subbing in application name to check, it's possible to see which is available to your system if using apt and a package manager.</p>

<h3>Install software for working with drive images</h3>

<pre><code>sudo apt-get install kpartx
</code></pre>

<h3>Install software for working with partitions</h3>

<pre><code>sudo apt-get install parted
## Either above or below, 'g' stands for GUI
sudo apt-get install gparted
</code></pre>

<h3>Install software for data recovery &amp; inspection</h3>

<pre><code>sudo apt-get install safecopy magicrescue testdisk testdisk-dbg
</code></pre>

<h3>Getting documentation</h3>

<p>Any of the above can have its manual or help docs printed via the following syntax</p>

<pre><code>man magicrescue
safecopy --help
</code></pre>

<h3>About kpartx</h3>

<p>Using <code>kpartx</code> the backup image can be <em>opened</em> and it's internal partitions can be mapped to the <code>/dev</code> directory for later mounting to a path(s). This bit is better in use cases where corruption or deletions do not need to be recovered from.</p>

<pre><code>## Make some directories for the image partitions to be mounted to
mkdir -p /media/rescue_p1
mkdir -p /media/rescue_p2
## Map image to dev loop paths
kpartx -v -a /media/backup_drive/mybackup.img
## Note the output of above command it will be similar to below
##  but not identical.
mount /dev/mapper/loop0p1 mkdir -p /media/rescue_p1 -o ro
mount /dev/mapper/loop0p2 mkdir -p /media/rescue_p2 -o ro
</code></pre>

<p>Note the use of <code>- o ro</code> means read only. Remove it if you wish to do stuff without protection to backups and like loading another backup image.</p>

<p>Files within the drive image should now be available to the same extent as the original target drive, however, because your files where deleted and my client's files where corrupted then there's still more work to do. So let's un-mount for now and install another tool. For now know that you've this power of resurrection unlocked.</p>

<pre><code>unmount /dev/mapper/loop0p1
unmount /dev/mapper/loop0p2
kpartx -d /media/backup_drive/mybackup.img
</code></pre>

<h3>information gathering</h3>

<p>Now some info about the drive image needs to be know for you to make use of the following block</p>

<pre><code>## Take note of Disklable in following output
fdisk -l /media/backup_drive/mybackup.img
## Take note of Partition Table, Type, &amp; File system
##  in following output
parted /media/backup_drive/mybackup.img
## you may have to look for quit (q) command to get back to the terminal.
</code></pre>

<p>Now prepared with knowledge about your drive the following blocks can be tried on your backup image</p>

<h3>About testdisk</h3>

<p>Test disk is a command line, menu driven, application. So be very aware of what context your keyboard input will be read under. To test disk recover any files we should first <code>cd</code>  to a directory safe for it to dump in to. For my recovery I mounted the second drive I had and changed directories to it as shown</p>

<pre><code>mkdir -p /media/salvaged/testdisk
## mount recovery drive partition to above, then cd
cd /media/salvaged/testdisk
## start testdisk against image file
testdisk /media/backup_drive/mybackup.img
## Choose Analyse &amp; Deeper-scan to go deeper
## Use bundled photorec program to try and recover deleted our corrupted files
photorec /media/backup_drive/mybackup.img
</code></pre>

<p>After using the above two recovery tools, the results can be reviewed using logs saved to your current working directory. Here's the command I ran</p>

<pre><code>ls -hal /media/salvaged/testdisk | less -R5
## use letter q on keyboard to quit, arrow keys to
## move up and down though output in five row chunks
## and page keys to move though output based on
## the entire screen hight.
</code></pre>

<h3>About safecopy</h3>

<p>The safecopy tool can be used to read drives even when blocks within go bad. Supper useful if you run into a situation where a drive is reporting health issues or similar errors or into situations where partitions where messed with. It saves image files kinda like what we did with dd but unlike dd it's able to really <em>dig into</em> sectors marked as bad.</p>

<pre><code>## Copy target drive source, bad block marks are listed in
## stage1.badblocks output file in your terminal's
## current working directory. They'll come in handy in the
## next steps.
safecopy --stage1 /dev/hda stage_one.img
## Attempt to read bad blocks marked in
## stage1.badblocks with no repeats marking ends
## of bad areas in stage2.badblocks
safecopy --stage2 /dev/hda stage_two.img
## Give no heed to bad blocks and attempt to copy
## everything. Note this next one will retry forever on
## every uncooperative block so it may take forever
## or just a ridiculously long time. Additionally if your
## target drive is a platter style then if there are problems
## with the mechanics of the drive this may cause
## increased ware and tare.
safecopy --stage3 /dev/hda stage_three.img
</code></pre>

<p>Next try any of the recovery tools already suggested to try and recover lost data. Even if these backups still don't have your data there are likely other tools you can try.</p>

<p>While there's still a chance that you've lost your coins, such as if a new file was written over it, the above steps should increase your chances at recovery. Try searching for terms like <code>forensic drive imaging</code> and similar to find even hope of recovering data from that state. Last but not least there maybe a place in your area that can open up the drive (it's platter style) and use specific tools for literally imaging the data off it; <em>mom &amp; pop</em> tech shops and state level law enforcement are two good places to chat-up for suggestions on where they send out drives for full revival. However, that route will cost in time and in money so reserve this as last resort.</p>

<p>Hopefully the first image is the only one needed and you get your coins back without issue. In either case save these notes somewhere so that you can impress a luckier soul with your wizardry.</p>

CC BY-SA 3.0
2016-11-06T08:11:56.967Z
2016-11-07T21:51:20.780Z
2016-11-07T21:51:20.780Z
S0AndS0
<p>I've deleted my wallet when I wiped my computer recently and never backed up my files. The only thing I've done was convert money into bitcoins and it was sitting in my wallet never touched. I reached out to the company that processed my conversion and they provided me with the necessary addresses that were used. How can I recover my bitcoins? Any help would very appreciated. Thank you. </p>

CC BY-SA 3.0
2016-11-06T07:53:46.943Z
Did they provide a private key too, or just the addresses?
Nick ODell
CC BY-SA 3.0
2016-11-08T08:24:01.453Z
I encrypted the wallet. I don't believe I applied a private key. I know the password to my wallet if that helps.
bblankier
CC BY-SA 3.0
2016-11-17T11:29:17.877Z
Possible duplicate of [I lost my private key](http://bitcoin.stackexchange.com/questions/43425/i-lost-my-private-key)
UTF-8
CC BY-SA 3.0
2017-11-22T05:52:51.443Z
Hi! If you did not succeed, there are companies our there that help. I had a similar problem, and they recovered everything. PM me and I can tell you more.
NDB
<wallet-recovery><lost-wallet>
I've deleted my wallet and never backed up my files. How can I recover my coins?
bblankier
# I've deleted my wallet and never backed up my files. How can I recover my coins?

(Asked by: username_0 on 2016-11-06)

I've deleted my wallet when I wiped my computer recently and never backed up my files. The only thing I've done was convert money into bitcoins and it was sitting in my wallet never touched. I reached out to the company that processed my conversion and they provided me with the necessary addresses that were used. How can I recover my bitcoins? Any help would very appreciated. Thank you.

**Tags:** wallet-recovery, lost-wallet

> **Comments:**
> **username_1**: Did they provide a private key too, or just the addresses?  
> **username_0**: I encrypted the wallet. I don't believe I applied a private key. I know the password to my wallet if that helps.  
> **username_2**: Possible duplicate of [I lost my private key](http://bitcoin.stackexchange.com/questions/43425/i-lost-my-private-key)  
> **username_3**: Hi! If you did not succeed, there are companies our there that help. I had a similar problem, and they recovered everything. PM me and I can tell you more.  

---

## 1 answers

### Answer by username_4 on 2016-11-06. Score: 5

First, don't panic!

Second, make an image backup of the wiped drive to a physically different drive.

Third, you maybe able to recover the deleted files with tools such as [magic rescue](http://www.irongeek.com/i.php?page=backtrack-3-man/magicrescue) so long as the sectors on your drive that your wallet was wiped from are intact... otherwise you may be out those coins... I've had OK luck with rescuing data off drives for friends but also some failed attempts to because of rewritten blocks corrupting deleted data.

In other words this will cost you in either time or in the coins you've lost. Right now you're in *limbo* and I would suggest you do a `dd` backup of your wiped drive and try to use recovery tools on the backed up drive image so that you don't accedentaly wipe the target data off the original drive.

I'll see what I can find in my notes in a few hours on the subject of drive imaging and recovery for ya.

## Updates

Here's an edited version of my private notes on data recovery steps that I've used to recently recover a corrupted USB drive that was being used to backup a client's Windows user account files. Note file names did get mangled during the process so be aware that there will be cleanup after this process.

### Setup

* You'll need second drive with enough free space to house double the total number of bits of the target drive. Or in my case I had to get two drives of greater than 64gigs; one for the backup image and the other to receive recovered files. This is because we are going to be copying **every** bit off the target drive; even the zeros. In my case discussed here there was only 13~gigs used out of 63'ish but we still had to copy it all.
* You'll need a USB or CD bootable Linux distribution. I used Kali Sana for my recovery because it has pretty up to date tools for this job but you might want to hunt for a specifically designed distro. Web search for terms like "USB recovery Linux distro" and you'll likely find a *top 10s* list of someone's testing results or recommendations; there be choices in flavor so I'll keep this based off my expenses with Kali.
* You're going to need to locate the dev file path for your target drive, in this example it's `/dev/hda` but for you it maybe different. Hint use `mount` & `blkid` commands to show drives, their file paths and other info. Once located unmount it so you're normal programs don't write or read from it by accident. For example my target drive was mounted at the following `umount` command directory path

  umount /mnt/usb/damaged

> Repeat above for any mount points associated with
> the target drive to be backed-up. For my revival there
> was two partitions associated with `/dev/hda` physical
> drive and both had to be unmounted. Also be on the look
> out for `swap` partitions associated with the target; mine
> didn't but if you roll the next command with **any**
> of the target drive's mounted you run the risk of a bad
> backup image being made to work from.

### Backup command

```
dd if=/dev/hda bs=4K conv=sync,noerror | tee mybackup.img | md5sum > mybackup.md5

```

Be very **very** careful with the above because `dd` is not forgiving! Also note that the directory path is different than what was used with `umount` because we're now operating on the target drive a a whole and not a partition within the target drive. Hint, the previously mentioned `mount` & `blkid` commands used to reveal mounted directory paths should have shown the dev related path too.

* `-if=/dev/sda` should be the drive location of the hard-drive you need to recover data from. Don't include any partition numbers as you'll want every bit from start to finish.
* `bs=4K` is the bite count per read/write (I think) and lower values will take longer but be less prone to errors.
* `conv=sync,noerror` are options to keep `dd` chugging away even if there's a bad sector or two.
* `| tee mybackup.img` redirects (and duplicates with `tee`) output from `dd` reading the target drive and saves it to `mybackup.img`. Note this fine path should **not** point to the drive your imaging; if you write to the same drive you'll likely wipe bits you want back for good from your drive because right now the addresses/sectors are marked as available for writing that use to contain your data.
* `| md5sum > mybackup.md5` takes the duplicated output from `dd` and writes a signature to `mybackup.md5` same rules for file placement as the image file too.

Now the above is going to take some time; for the 64~gigs I had to recover I used an RPi board (cheaper on the electric bill) and ran the above in `screen` for one full night and half a day. The above also isn't going to give you any feedback or process until it's done. In other words, grab a book or watch a season of Firefly to pass the time.

Eventually it'll report the number of `records` `in`/`out` and the time it took in seconds. And we can roll some tools over the backup image instead of on the target drive; this means mistakes can be made and you're just out the time of making another image.

To verify that the backup image you've saved is good you can run the md5 command against the image file and compare against the one generated during backup. Furthermore if really worried you can roll the md5 command against the target drive and compare that all three signatures/fingerprints are equivalent. The following are steps that I used to verify the image I took.

```
dd if=/dev/hda bs=4K conv=sync,noerror | md5sum > drive.md5
## Above should modified to point to your target drive
## Bellow should point to your backup image
dd if=mybackup.md5 bs=4K conv=sync,noerror | md5sum > image.md5

```

Use `cat` to show the contents of each md5 file, they *should* all match or show the **same** human unrelated junk. Note for other readers, yes collisions (false matches) can happen but we're not trying to make any collisions so chances are low.

### Tips for keeping sanity on next steps

* if you've the space then make a backup of your backup because it's safer that way and will save your target drive from any accidents when having to start a whole new `dd` command ;-) beware of sleepy terminal user input.
* if possible unplug/disconnect the target drive or attempt the next block of steps on different hardware operating only on your backup image.
* take your time at this point. There's little reason to rush at this point, well unless you liked waiting for the next backup image to complete. Not going to judge if that's what you're into.

### Optional, install Windows partition compatibility

```
## For many Debian/Ubuntu based distributions
sudo apt-get install ntfs-3g
## Kali Sana
sudo apt-get install ntfs-config
## and some Ubuntu flavors
sudo apt-get install ntfsprogs

```

Using `apt-cache policy ntfs-3g`, subbing in application name to check, it's possible to see which is available to your system if using apt and a package manager.

### Install software for working with drive images

```
sudo apt-get install kpartx

```

### Install software for working with partitions

```
sudo apt-get install parted
## Either above or below, 'g' stands for GUI
sudo apt-get install gparted

```

### Install software for data recovery & inspection

```
sudo apt-get install safecopy magicrescue testdisk testdisk-dbg

```

### Getting documentation

Any of the above can have its manual or help docs printed via the following syntax

```
man magicrescue
safecopy --help

```

### About kpartx

Using `kpartx` the backup image can be *opened* and it's internal partitions can be mapped to the `/dev` directory for later mounting to a path(s). This bit is better in use cases where corruption or deletions do not need to be recovered from.

```
## Make some directories for the image partitions to be mounted to
mkdir -p /media/rescue_p1
mkdir -p /media/rescue_p2
## Map image to dev loop paths
kpartx -v -a /media/backup_drive/mybackup.img
## Note the output of above command it will be similar to below
##  but not identical.
mount /dev/mapper/loop0p1 mkdir -p /media/rescue_p1 -o ro
mount /dev/mapper/loop0p2 mkdir -p /media/rescue_p2 -o ro

```

Note the use of `- o ro` means read only. Remove it if you wish to do stuff without protection to backups and like loading another backup image.

Files within the drive image should now be available to the same extent as the original target drive, however, because your files where deleted and my client's files where corrupted then there's still more work to do. So let's un-mount for now and install another tool. For now know that you've this power of resurrection unlocked.

```
unmount /dev/mapper/loop0p1
unmount /dev/mapper/loop0p2
kpartx -d /media/backup_drive/mybackup.img

```

### information gathering

Now some info about the drive image needs to be know for you to make use of the following block

```
## Take note of Disklable in following output
fdisk -l /media/backup_drive/mybackup.img
## Take note of Partition Table, Type, & File system
##  in following output
parted /media/backup_drive/mybackup.img
## you may have to look for quit (q) command to get back to the terminal.

```

Now prepared with knowledge about your drive the following blocks can be tried on your backup image

### About testdisk

Test disk is a command line, menu driven, application. So be very aware of what context your keyboard input will be read under. To test disk recover any files we should first `cd` to a directory safe for it to dump in to. For my recovery I mounted the second drive I had and changed directories to it as shown

```
mkdir -p /media/salvaged/testdisk
## mount recovery drive partition to above, then cd
cd /media/salvaged/testdisk
## start testdisk against image file
testdisk /media/backup_drive/mybackup.img
## Choose Analyse & Deeper-scan to go deeper
## Use bundled photorec program to try and recover deleted our corrupted files
photorec /media/backup_drive/mybackup.img

```

After using the above two recovery tools, the results can be reviewed using logs saved to your current working directory. Here's the command I ran

```
ls -hal /media/salvaged/testdisk | less -R5
## use letter q on keyboard to quit, arrow keys to
## move up and down though output in five row chunks
## and page keys to move though output based on
## the entire screen hight.

```

### About safecopy

The safecopy tool can be used to read drives even when blocks within go bad. Supper useful if you run into a situation where a drive is reporting health issues or similar errors or into situations where partitions where messed with. It saves image files kinda like what we did with dd but unlike dd it's able to really *dig into* sectors marked as bad.

```
## Copy target drive source, bad block marks are listed in
## stage1.badblocks output file in your terminal's
## current working directory. They'll come in handy in the
## next steps.
safecopy --stage1 /dev/hda stage_one.img
## Attempt to read bad blocks marked in
## stage1.badblocks with no repeats marking ends
## of bad areas in stage2.badblocks
safecopy --stage2 /dev/hda stage_two.img
## Give no heed to bad blocks and attempt to copy
## everything. Note this next one will retry forever on
## every uncooperative block so it may take forever
## or just a ridiculously long time. Additionally if your
## target drive is a platter style then if there are problems
## with the mechanics of the drive this may cause
## increased ware and tare.
safecopy --stage3 /dev/hda stage_three.img

```

Next try any of the recovery tools already suggested to try and recover lost data. Even if these backups still don't have your data there are likely other tools you can try.

While there's still a chance that you've lost your coins, such as if a new file was written over it, the above steps should increase your chances at recovery. Try searching for terms like `forensic drive imaging` and similar to find even hope of recovering data from that state. Last but not least there maybe a place in your area that can open up the drive (it's platter style) and use specific tools for literally imaging the data off it; *mom & pop* tech shops and state level law enforcement are two good places to chat-up for suggestions on where they send out drives for full revival. However, that route will cost in time and in money so reserve this as last resort.

Hopefully the first image is the only one needed and you get your coins back without issue. In either case save these notes somewhere so that you can impress a luckier soul with your wizardry.


---

