online server: rm -rf /data

想象一个场景，线上服务器上执行一个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 的细分操作以外（还有什么大佬们可以补充，我不是专业运维），是否要有种意识，就是要保证自己的不管是工作中的数据，还是生活中的数据的安全。大家可以合理讨论，不要喷人，我们只讨论场景如何避免，有什么思路可以解决，以及其他的类似的场景和思路，谢谢。

esee

146 天前

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

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