如果这个场景让你感觉还好，如果有恢复机制的话问题不大。那么下面开始谍 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 的细分操作以外（还有什么大佬们可以补充，我不是专业运维），是否要有种意识，就是要保证自己的不管是工作中的数据，还是生活中的数据的安全。大家可以合理讨论，不要喷人，我们只讨论场景如何避免，有什么思路可以解决，以及其他的类似的场景和思路，谢谢。
