Intro
I've accidentally done the dreaded thing. I types ls
instead of cd
, and then a few commands later ran rm -rf
on my current directory instead of a copy of this directory from a few days ago which appeared in mnt
after a script I wrote didn't do what I expected.
I'm aware that there are already questions like this on here, but none are comprehensive. I'd like to take the "opportunity" to start a public contrib series of answers which can be used as a reference for others in future.
For example, there are suggestions about using photorec
and testdisk
. These might not be the best solutions. I found another answer, here, which suggested using locate
. I don't know anything about this or how it works.
My System
My system is a Debian 10 system tracking the Testing branch. The data was on a SSD, formatted as ext4. As soon as I realized that I had run rm -rf
in the wrong place I held the power button down on the computer to turn it off.
Steps to Solution
I have another laptop running another Debian system. I have taken the SSD out of the computer and plugged it into an external USB to Sata interface.
I believe I now need to mount this in a way which means the system cannot write data to the device. How should I do this?
Can I then use this locate
method (linked question) to get the data back? Before running any of this I want to make sure that it is the right thing to do.
Is the data important?
Yes - the directory I deleted contains all the code for my PhD. I have a couple of weeks left. I have an older version which I can use, and then re-implement everything which I did during the last few week or so. However in that short period of time I changed a lot of stuff. I made a "breakthrough" with the research this week. The way in which the code is written means it is not at all trivial to re-implement this.
Did I have backups? (Edit)
The only one I know for sure that I have is on a server with the date 2 May 2020
. I've got a huge amount of work done since then as I've been pretty much working around the clock.
There might be other backups on this SSD, but some of them are in my home directory - so those will be rm -rf
'd, and the backup script was not working as I expected - so probably the regular backups from that do not exist. (Trying to delete the weird stuff that was being copied is how I ended up in this mess.)
At the moment I can't access the SSD to check the date. I need to know how to mount it such that data cannot be written to it, if that is possible.
If I only have the ones from 2 May then that's really very bad. I've been working crazy hours on this recently, which is probably why I woke up this morning and accidentally nuked it.
dd
on the entire partition (to an external drive) before experimenting with restore tools. You can also use thatdd
image as an external image to a virtual machine from where to try to restore, without ever touching your real partition.locate
answer you linked to is only about finding the names of files that are missing, it won't help you get the data back. Mounting read-only is easy (sudo mount -o ro /path/to/your/disk /path/to/mountPount
, but restoring deleted data is not easy at all.-o ro
does write to disk! Don't do it! You can only copy block by block, e.g. bydd
, or loop-mountro
but not like that.-o ro
should mount it read-only. What would be written to disk?-r, --read-only
): "Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, Ext3 or ext4 will replay its journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount ext3 or ext4 filesystem with "ro,noload" mount options or set the block device to read-only mode, see command blockdev(8)."