看完了，果然跟中间的预测一样，实际数据压根就不在这台ecs上，阿里云完全没问题

但你这几年一直是以为数据在这台上面的，除了做快照备份外，难道就没有实际上去看过数据么。。。

太混乱了

事实证明，怀疑计算机出错，最终大概率是自己搞错了。我多次踩了这种坑

学习了，搞运维不认真，确实有时候会把生产和测试环境弄混

如果是别人有心，会死的很惨吧

以前某个项目试运行就发现了很多问题，但大老板一定要用它，于是自己写脚本：
每天做数据库导出，本地存7天，远端存30天，每个星期做整个星期的数据导入测试。
最危险的一次也就丢了1天数据。

另外，不要相信aliyun的监控，我那个时代ECS会不经你同意自己重启服务器的，没有自己搭建的监控，服务挂了你都不知道。

好惊险 iOS fly ~

解决问题就好，阿里云作为现在3A之一，这么几年的使用，我还是比较信赖的

从头看到尾，就想知道，这么个系统，运行这么久了，从来都不用浏览数据库的工具查看下数据库？比如说phpmysqladmin.

还有个问题，主机出问题时，应该是先做全盘备份，然后再用快照恢复吧。

建议改下标题，免的误导下面没有了

回复75#猛禽

感谢你这个提醒

持续关注阿里云运维事故案例

楼主确实不是专业运维...故障现象都讲不清...

后续呢？解决到什么程度了

我不是IT,严格意义上，我是搞融资和股权的，这个系统不是我的工作内容，不过我用工具连过数据库，连的新ecs，因为阴差阳错的因素，只需要去查询2018.10之前的条目。

从来我都信不过别人，自己一定要一天最少留一份，特别这种不见了还找不到人的云，出问题比自己硬盘出坏道更糟糕。 iOS fly ~

贵司IT/ops裁了不冤

看完笑了，我喷错云了 iOS fly ~

完全没有本地备份？非电工路过，感觉楼主有些不够谨慎呀

对大家都是前车之鉴吧，首先得找个靠谱的技术负责人，还有就是需要制定应急预案，出了这类问题后该怎么解决。

我基本每天都备份数据到另外的机器上

你是最早提出的，一看就是运维老行家！

还是找个搞it的吧。

备份不同于灾备，是保持业务的可连续性恢复，比如数据库这块，不仅要备份全量还要实时备份日志，才能保证恢复到任意时点。理论上说，删库也不怕。

系统快照是一种特殊的全量备份，还记录了系统信息。优点快捷，缺点不能异机恢复。云环境不考虑日志显然快照效率高于全量。

备份有计划，有检查，有人定期恢复验证才算基本靠谱。