Linux Data Recovery


You typed rm-rf

Beware Linux data recovery. There is a very hurtful way to find out why you would need to recover data. Very simply – have a backup file.

tar -czvf backup.tar.gz database.sql /home/you /usr/local/sbin /var

Now download it to your local computer. But what in the world are these things saying about it? It is more than discouraging to read it from the front of – but there it is:

sudo apt-get install testdisk

Testdisk is just that – its a gui for a very simple command which is more than likely generated for expounding the output.

dd if=/dev/vda1 of=/mnt/recover/crap.iso bs=4096

ext4magic /dev/vda1 -M -d /mnt/recover

If you need to be angry very quickly – download ext4magic and so on. I wouldn’t. Maybe I can save someone the trouble. Maybe not. Here she goes:


/dev/sda: UUID=”7a992589-2a85-4a34-b73c-680ea9b20fb2″ TYPE=”ext4″
/dev/vda1: LABEL=”cloudimg-rootfs” UUID=”1943530c-1f82-498b-8b82-d1b474ba22c1″ TYPE=”ext4″ PARTUUID=”9542e1d8-1934-4185-83b3-44a08eee31a4″
/dev/vda15: LABEL_FATBOOT=”UEFI” LABEL=”UEFI” UUID=”53A4-477C” TYPE=”vfat” PARTUUID=”3a5f50b2-b79d-453d-ad14-06dc97c044dc”
/dev/loop0: TYPE=”squashfs”
/dev/loop1: TYPE=”squashfs”
/dev/loop2: TYPE=”squashfs”
/dev/loop3: TYPE=”squashfs”
/dev/loop4: TYPE=”squashfs”
/dev/loop5: TYPE=”squashfs”
/dev/vda14: PARTUUID=”94be4c0e-4c51-49ad-86b1-5ccfcfbd

If you are extremely conscious of what it exactly any of these people had in mind when they were looking for an additional partition for free space, in the bash terminal, type blkid

By the output to the current terminal command, blkid – There are two disks:


Are they in use? Type the command df -hi

I dont know if you can see the hidden charm there – but some people already have walked under that ladder and it didn’t lead to the other side.

Filesystem Inodes IUsed IFree IUse% Mounted on
udev 119K 408 119K 1% /dev
tmpfs 123K 653 123K 1% /run
/dev/vda1 3.1M 885K 2.3M 29% /
tmpfs 123K 4 123K 1% /dev/shm
tmpfs 123K 4 123K 1% /run/lock
tmpfs 123K 18 123K 1% /sys/fs/cgroup
/dev/vda15 0 0 0 – /boot/efi
/dev/loop0 11K 11K 0 100% /snap/core18/1944
/dev/loop1 11K 11K 0 100% /snap/core18/1988
/dev/loop2 1.6K 1.6K 0 100% /snap/lxd/19032
/dev/loop3 1.6K 1.6K 0 100% /snap/lxd/19188
/dev/loop4 470 470 0 100% /snap/snapd/11036
/dev/loop5 474 474 0 100% /snap/snapd/11107
/dev/sda 1.6M 11 1.6M 1% /mnt/recover
tmpfs 123K 22 123K 1% /run/user/0

Nervous? yes. Why would anyone believe that additional output would do anything other than exactly what it said it would do – and so on. Many of the writers are very eccentric but with just a little bit more than a strange sort of contention:

df -h /mnt/recover

Filesystem Size Used Avail Use% Mounted on
/dev/sda 50G 53M 47G 1% /mnt/recover

If the drive is not mounted type:

mkdir /mnt/recover

mount /dev/sda /mnt/recover

By this output – 47G are available to make an image of the entire /dev/vda1 disk which contains the root file system and it has 25G

df -h /

Filesystem Size Used Avail Use% Mounted on
/dev/vda1 25G 25G 0 100% /

25G is smaller than 47G. See what I am getting at? There is another ladder to walk under and it too short for any one I want know.

sudo apt-get install photorec

PhotoRec 7.1, Data Recovery Utility, July 2019
Christophe GRENIER

Disk /dev/vda – 26 GB / 25 GiB (RO)
Partition Start End Size in sectors
1 P Linux filesys. data 225 8 25 52012 10 41 52201439

Destination /mnt/recover/recup_dir

Pass 1 – Reading sector 1589248/52201439, 32988 files found
Elapsed time 0h00m11s – Estimated time to completion 0h05m50
txt: 25658 recovered
tx?: 2866 recovered
elf: 2411 recovered
pyc: 503 recovered
gif: 396 recovered
gz: 369 recovered
png: 335 recovered
ps: 177 recovered
jpg: 70 recovered
others: 203 recovered

Photorec appears to work under the Destination /mnt/recover/recup_dir and just where is that? Remember the guy who – said exactly what it said it would do and I dont know…

grep -r “map_initialize” | more

map_initialize  is a phrase contained within a text-file with the rm -rf in question – contained. While this is extremely hard to find the right phrase to find the right data for the right text file. The data even includes partial edits and temporary agents used to display text to the terminal:

grep -r “map_initialize

Binary file recup_dir.911/f28005288.a matches
Binary file recup_dir.782/f23986664.elf matches
Binary file recup_dir.14/f0621488.elf matches
Binary file recup_dir.14/f0620304.elf matches
Binary file recup_dir.180/f3972864.elf matches
Binary file recup_dir.375/f13258176.elf matches
Binary file recup_dir.613/f19476480.elf matches
Binary file recup_dir.603/f19114920.a matches
Binary file recup_dir.248/f5969920.a matches

However, the cat maybe able to find the particular text you deleted, but the data that is recovered is very very bad. All cats include:

cat recup_dir.603/f19114920.a > junk

vi junk

An entire directory deleted at any one particular time has an exclusive journal or a ext4 filesystem. While it would be better to simply re-write the software from what you are able to recover with updated changes;
have a backup file or remember explicitly that – you should never write rm -rf to the terminal and press enter. Maybe – its better to move the files altogether to a junk directory – ;p

While the more serious part is far from being over – the recovered files from photorec appear as any other file; but not necessarily the mountains of West Virginia.

Previous articleNot a woman?
Next articleTrump sues
Thank you for visiting WEEDBOX News. Michael Kearney writes detailed technical instruction(s) - and news articles for - try the search icon. Michael Kearney has over 25 years of computer experience. already thought about it - sign-up and get a free shell at call me at +1 (571) 662-1795 or email


Please enter your comment!
Please enter your name here