事件经过#

不小心把博客后端的数据库给删了，本来都绝望了，但是我测了一下api发现可以正常请求出来，说明他还在电脑内存里，辛亏用的是sqlite这种数据库，是mysql，postgresql就寄了。 然后就进还在运行的docker容器里找，最好不要在宿主机里找，进程太多，grep出来一大堆。如果docker-compose也被删了，就用docker ps先查容器id。进去容器内部的bash之后，如果有ps的话就ps＋grep查数据库名， 如果没ps，就直接去/proc里，把这个路径下的所有文件全ls一遍，用grep筛选你要的。最好了解一下/proc的组织方式，我放到最后。

1
#进入容器里
2
docker exec -it 65917be1e702 bash
3
ls -l /proc/*/fd/* | grep db
4
#这个是个软连接，从pid11的fd文件句柄下的12号文件软连接到了原本数据库的位置，即使这个的inode已经被删掉了，他并没有被删除在磁盘扇区里。
5
lrwx------ 1 root root 64 Mar 14 12:34 /proc/11/fd/12 -> /flask_backend/instance/app.db (deleted)
6
#把他的软连接连接这的内存里的文件用cat读出来并输出到app.db里
7
root@65917be1e702:/flask_backend# cat /proc/11/fd/12 > /flask_backend/app.db
8
#在宿主机里把他从docker实例里重新读回宿主机里
9
docker cp 65917be1e702:/flask_backend/app.db ./app.db

1. Delete 发生：文件名消失，Inode 引用计数 -1。
2. 进程握住：因为 Flask 还在运行，进程句柄对 Inode 的引用计数是 +1。
3. 结果：总计数 > 0，数据块在磁盘上被物理锁死，禁止重写。
4. 抢救：你通过 cp或cat 建立了一个新的文件名，指向了这个 Inode，引用计数再次 +1。

proc#

/proc 目录不是真实存在于磁盘上的，它是一个“伪文件系统（Virtual File System）”。 它是 Linux 内核在大脑里划出的一块区域，实时映射着内核和进程的状态。

你可以把它理解为内核通过文件系统的形式，向你展示的一张**“动态全身扫描图”**。