Press Ctrl

Each inode is identified by an integer, unique within the system files and directories contained a list of pairs consisting of a number of inode and name identification that allows access to that file, every file has one inode, but may have more than one name in different or even in the same directory to facilitate location. “In our case, our file inode is 512 495, this is the ID of our file on the system. When you delete a file with the rm command, what we do is delete the reference to the inode in question, for a time that inode will continue to exist in our system but we can not see and it appears that the deleted file has disappeared from our system. If any program is accessing the file that we deleted, are lucky. The program in question will have a reference to the inode of the deleted file and provided they do not close this program we can retrieve the contents of this file.

(A practical case that many of us ever happened to the log file to delete any system service (apache, postgresql, mysql. etc) while the service is working) Here is a full session since we delete a file until you recover: We open our file example with less (for example) less fichero_pruebas.txt THIS IS A TEST FILE TEXT fichero_pruebas.txt (END) Press Ctrl + z to suspend the less program without stopping it (the program remain open, accessing our database, but suspended) less fichero_pruebas.txt 1 + Stopped less fichero_pruebas.txt We found that our file is intact: ls-li fichero_pruebas.txt 512 495-rw-r – r – 1 root root 39 02/04/2008 22:28 fichero_pruebas.txt We erase … 😉 accidentally rm test.txt ficheros_de We found that not exist in our directory ls ls-li fichero_pruebas.txt: fichero_pruebas.txt: No such file or directory As discussed above, if we have a program accessing the file we’re lucky. Use lsof to see if any program is accessing the file that we deleted: lsof grep user fichero_pruebas.txt less 4r REG 28 410 3.1 39 512 495 / home / user / fichero_pruebas.txt (deleted) should not be a surprise that our less this program accessing our file deletion. The columns we are interested in this line are the first (PID of the program accessing the file, 28 410), and the fourth, the ‘file descriptor’ (4r) with reference to our file inode (512 495). With this information we go to the virtual filesystem / proc information on our linux system.

ls-l / proc/28410/fd/4 lr-x —— 1 user user 64 02/04/2008 22:38 / proc/28410/fd/4 – / home / user / fichero_pruebas.txt ( deleted) As expected, a reference to the deleted file. All you have to do now is copy the data to which / proc/28410/fd/4 this reference. For this we can easily use cp cp / proc/28410/fd/4 fichero_pruebas.txt.restaurado Now no matter what our program has finished running less because our already deleted file recovered. cat fichero_pruebas.txt.restaurado THIS IS A TEST FILE TEXT This article must have a little luck to keep our database, but in future articles we will see other techniques to use when luck is not on our side. That’s it for today, enjoy it.