[toc]

preface

Every time we execute rm commands on the production environment server, we are always on the edge of our pants, because once we accidentally execute the error deletion, we will be ready to run. After all, people are not machines, let alone machines have bug s, hehe. So what if you really delete files that should not be deleted, such as databases, logs, or execution files?

Simulation scene

pg_ctl start

$ ll
total 8
-rw------- 1 hgdb565 hgdb565 413 May 21 16:45 postgresql-server_log_21
-rw------- 1 hgdb565 hgdb565 760 May 21 16:45 postgresql-server_log_21.csv

delete

Delete database log file by mistake, PostgreSQL server_ log_ 21.csv

rm postgresql-server_log_21.csv

$ ll
total 4
-rw------- 1 hgdb565 hgdb565 413 May 21 16:45 postgresql-server_log_21

recovery

1 use lsof command to check whether there is a process to open PostgreSQL server_ log_ 21. CSV file

$ lsof |grep  postgresql-server_log_21
postgres  2465             hgdb565   10w      REG              253,0       413    201050 /opt/HighGo5.6.5/data/pg_log/postgresql-server_log_21
postgres  2465             hgdb565   11w      REG              253,0       877    201051 /opt/HighGo5.6.5/data/pg_log/postgresql-server_log_21.csv (deleted)

As you can see from the above, the current file status is deleted

2 check whether there is recovery data

$ cd /proc/2465/fd
$ ll
total 0
lr-x------ 1 hgdb565 hgdb565 64 May 21 16:46 0 -> /dev/null
lrwx------ 1 hgdb565 hgdb565 64 May 21 16:46 1 -> /dev/pts/0
l-wx------ 1 hgdb565 hgdb565 64 May 21 16:46 10 -> /opt/HighGo5.6.5/data/pg_log/postgresql-server_log_21
l-wx------ 1 hgdb565 hgdb565 64 May 21 16:46 11 -> /opt/HighGo5.6.5/data/pg_log/postgresql-server_log_21.csv (deleted)
lr-x------ 1 hgdb565 hgdb565 64 May 21 16:46 12 -> pipe:[30810]
l-wx------ 1 hgdb565 hgdb565 64 May 21 16:46 13 -> pipe:[30810]
lrwx------ 1 hgdb565 hgdb565 64 May 21 16:46 2 -> /dev/pts/0
lrwx------ 1 hgdb565 hgdb565 64 May 21 16:46 3 -> anon_inode:[eventpoll]
lr-x------ 1 hgdb565 hgdb565 64 May 21 16:46 6 -> pipe:[30804]
lr-x------ 1 hgdb565 hgdb565 64 May 21 16:46 8 -> pipe:[30805]

//You can see that the link number 11 corresponds to the deleted file
11 -> /opt/HighGo5.6.5/data/pg_log/postgresql-server_log_21.csv (deleted)

3 use I/O redirection to recover files

cat /proc/2465/fd/11 > /opt/HighGo5.6.5/data/pg_log/postgresql-server_log_21.csv

$ ll /opt/HighGo5.6.5/data/pg_log/
total 8
-rw------- 1 hgdb565 hgdb565  413 May 21 16:45 postgresql-server_log_21
-rw-rw-r-- 1 hgdb565 hgdb565 1321 May 21 17:00 postgresql-server_log_21.csv

principle

In Linux system, every running program has a host process isolated from each other, which is represented by / proc / process number (Linux is essentially a file system), such as: ls-l /Proc / 13067 view the process information whose PID is 13067. When the program is running, the operating system will specially open a memory area for the current process to use. For the dependent files, the operating system will issue a file descriptor to read and write files. When we execute rm -f. when deleting a file, it only deletes the directory index node of the file. It is not visible to the file system, but it is still visible to the process of opening it. That is to say, the previously issued file descriptor can still be used to read and write the file. This is the principle that we can use I/O redirection to recover the file. If you accidentally delete a file by mistake, don't worry. First use lsof to view the process of opening the file, then use cat /proc / process number / fd / file descriptor to view the recovery data, and finally use I/O redirection to recover the file.