online server: rm -rf /data

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 45 天前的主题，其中的信息可能已经有所发展或是发生改变。

想象一个场景，线上服务器上执行一个rm -rf /data/ 是误操作，mysql 数据目录被误删除。如果这个场景让你感觉还好，如果有恢复机制的话问题不大。那么下面开始谍 buff 。 1.binlog 关闭（开了也不定有用，因为 mysql 那个目录直接被删除了，备份到另外其他目录可解）， 2.没有备份，现在残存的数据最后更新时间超过 1 年，没什么实际意义，和数据库直接原地消失差不多， 3.服务器放在云上，且没有磁盘快照或是其他形式的任何备份，哪怕是随手 down 下来。如果是你你会怎么办呢？（立马跑路吗？:）

这是今天遇到的一个真实的场景，主角非我本人，我刚听到这事时，距离误操作 20 分钟，问了上面的问题，得知希望渺茫。我下班了去尝试恢复，但无果。使用文件恢复工具，如 extundelete 或 e2fsck 都以失败告终。服务器厂商的磁盘是用的固态，所以不确定是否删除掉了闪存里的数据直接就丢掉了。咨询了云服务厂商是否有备份，他们说是存在的文件，会有 3 个 replica ，但是用户删除掉的数据，也是会 3 个同时删除掉。所以说，只能以沉痛的心情告知我的朋友无法恢复（或许是我太菜了），

各位大佬看看是否有其他的方法，奇技淫巧能够解决问题，恢复数据的都可以，现在污染服务器还在线，mysql 服务在线，只不过数据目录没有了，污染数据所在磁盘是 XFS 格式，是 LVM 逻辑卷，且是污染服务器的系统盘。在污染行为 50 分钟后，将污染磁盘克隆了一份，起了一个新的服务器，挂载到新的服务器上作为数据盘。云服务器厂商是京东云。

但是，回来我就在想，我们能从这事中吸取什么教训，毕竟不管是线上数据丢失还是自己个人的数据丢失，都有及其高昂的代价。除了 1 开 binlog 2 定时 dump 全量数据 3 自建 mysql 使用主从并空闲时间定时备份 4 服务器硬盘设置快照策略，5 双主热切换，这几种自建 mysql 的细分操作以外（还有什么大佬们可以补充，我不是专业运维），是否要有种意识，就是要保证自己的不管是工作中的数据，还是生活中的数据的安全。大家可以合理讨论，不要喷人，我们只讨论场景如何避免，有什么思路可以解决，以及其他的类似的场景和思路，谢谢。

12 条回复 • 2024-07-25 14:38:41 +08:00

234ygg

45 天前

带 trim 的 nvme ，除非 rm -rf 后瞬间物理断电，否则小几分钟就被 trim 了

billccn

45 天前

如果当时数据库还在运行，不要关机那 file handle 应该还在，从 procfs 可以找到。

（真）云服务器可以把文件系统 trim 关掉也不会影响性能，这样可以大幅提升恢复的概率。离线修复的话应该先把磁盘镜像做好 snapshot ，以防止修复失误造成更大的损失，如果云支持运行内存也能 snapshot 那更好。

3-2-1 备份必不可少，不要把全部鸡蛋都放在云上。

WaterWestBolus

45 天前

选择相信机制&流程>人，线上服务器执行命令谨慎，一切操作沙盒先验证。
使用各种方法禁止/修改 rm -rf /命令的使用，可以参考 https://cloud.tencent.com/developer/news/76167
登录限制用户/权限。一般操作就用普通账户就行，重要操作才用 root 。

事前做好预防>事后弥补

WaterWestBolus

45 天前

@WaterWestBolus 线上操作视情况选择下午/脑子清醒/用户空闲的时候进行操作。除特殊情况，避开周一/周五/深夜/早上操作。

dorothyREN

45 天前

备份或者从库都能解决这个问题吧，数据库备份是常规操作了，不管是备份数据库还是直接备份硬盘

esee

45 天前 via Android

云上都是虚拟磁盘吧，你克隆磁盘不可能有啥用的吧。文件恢复我只在能接触到物理磁盘且还是机械硬盘的时候自己恢复过一次。

至于说有什么经验，我基本不用 rm 改用 mv 到临时目录然后定期清空，每次 rm 的时候扇自己一下确保清醒。之前有个教训，跟同事一起在机房部署项目，同事 ssh 连接了旧的机器参考配置然后到新的机器部署，结果不小心把旧机器的 Oracle 删了，结果就是请工程师上门恢复，损失上百万，同事被辞退。