早上刚到公司，小李就急得满头大汗——他刚在FTP服务器上清理旧备份时，手一滑把正在用的项目资料给删了。现在开发组等着传文件，领导也在催进度。这种“误删”情况在运维工作中太常见了，关键是怎么快速补救。
先别慌，确认删除类型
FTP本身只是文件传输协议，不负责存储管理。你通过FTP删掉的文件，其实是在操作服务器上的实际目录。所以能不能恢复，取决于服务器本身的机制和配置。
如果文件是直接从Linux系统的/var/ftp/pub这类目录下被rm删除的，那原生FTP服务是没法自动找回的。这时候就得看有没有开启回收站机制，或者依赖系统层面的备份。
利用脚本模拟回收站功能
很多单位为了防误删，会提前给FTP服务器加个“软回收站”。比如在vsftpd中，可以通过自定义删除脚本，把rm命令替换成mv命令，把要删的文件移到一个隐藏目录里。
举个例子，在执行删除操作时，不是运行：
rm -rf /var/ftp/pub/report.docx而是改成：
mv /var/ftp/pub/report.docx /var/ftp/.trash/report.docx_$(date +%s)这样文件只是被挪走了，随时能找回来。只要定期清空.trash目录就行。
检查是否有定时备份
大多数生产环境都会有rsync、tar快照或云备份机制。比如每天凌晨3点执行一次全量同步：
0 3 * * * rsync -av /var/ftp/ /backup/ftp_bak/$(date +\%Y\%m\%d)发现误删后，第一时间去对应日期的备份目录里找。虽然不能秒级还原，但至少能把损失控制在一天内。
尝试extundelete工具（仅限ext文件系统）
要是没回收站也没备份，而且服务器用的是ext3/ext4文件系统，还可以试试extundelete。这个工具能在文件删除后、磁盘未被覆盖前抢救数据。
先卸载被删除文件所在的分区（避免写入新数据）：
umount /dev/sdb1然后使用extundelete扫描：
extundelete /dev/sdb1 --restore-file /var/ftp/pub/photo.jpg恢复的文件会放在当前目录的RECOVERED_FILES里。注意，这招越早用成功率越高。
用lsof查看是否还在占用
有时候你以为删了，但实际上有进程还开着这个文件句柄。这时候文件只是被标记为删除，真实数据还在。
运行下面命令看看：
lsof | grep deleted如果看到类似：
vsftpd 1234 user 5u REG 8,1 10240 123456 /var/ftp/pub/log.txt (deleted)说明文件还能救。直接从/proc/1234/fd/5里复制出来就行：
cp /proc/1234/fd/5 /var/ftp/pub/log.txt预防才是根本
事后补救再熟练也不如提前设防。建议日常做这几件事：一是给FTP删除操作加确认提示脚本；二是启用软删除机制；三是坚持每日增量备份+每周全量备份；四是权限分级，普通用户只能删自己上传的内容。
小李这次运气不错，服务器启用了mv式回收站，半小时就把文件找回来了。下次可别再图快直接敲rm了。