summaryrefslogtreecommitdiffstats
path: root/content/posts/ext4magic-data-recovery.md
blob: 48174061f9f9456b4a46ad314552b7cf04cdee19 (plain) (blame)
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
---
title: "ext4 deleted data recovery"
date: 2022-05-09T17:07:00
tags: ["Linux", "Recovery", "Snippets", "Software"]
---

Two data recovery stories in as many weeks! Fortunately, the events that lead to these were actually split by well over a year.

Inevitably, while using Linux you're going to end up making the human error of deleting a file you shouldn't delete. I was working in two near-identical file trees slowly merging them together. As you've guessed, I `rm -rf`'d a directory in the wrong tree. I immediately knew as soon as I hit enter so unmounted the drive and started researching recovery methods.

As I was still working on the directories, inevitably I hadn't made a backup.

I was lucky for a number of reasons:
* I still had access to a working live system
* the drive was mostly full
* it was just one directory
* I had an available drive to start dumping recovered files to immediately.
* the drive hadn't been written to since the deletion


After installing (but not using) photorec and testdisk I wanted to see if there was anything else that could work. I looked up `extundelete` which sounded perfect, but wouldn't compile on my system.

In steps `ext4magic`. After looking at a long winded guide which included dumping your journal I had a flick through the documentation and settled on the following command:

```
umount /dev/sdb1
sudo ext4magic /dev/sdb1 -m -d /mnt/rescue
```

What the above will attempt to do is search `/dev/sdb1` (recovering deleted file with the `-m` flag) and copy anything found to destination `/mnt/rescue`.

I can't accurately guage how successful the process was but I certainly recovered files that had been deleted.