Rds没有？ iOS fly ~

楼猪不是合格电工啊:scream:，我这种伪电工都多个备份 iOS fly ~

那就 不知道了，我也只是重度用户。让阿里的技术人员帮着看看。有没有其他的快照可用的。

这个真奇怪了 iOS fly ~

我负责的阿里云集群也有几十台,三年多了也没出过问题
lz没有靠谱的运维技术朋友帮忙搞搞?
在开个新的ecs 用快照恢复看看,我觉得技术层面的问题可能更大一些,阿里云出问题的概率是有,只能尽量恢复吧.
另,生产环境还是rds靠谱.自建mysql要搞好备份啊,好歹弄个黑群晖自己备份也是个意思

关注下……重要数据还得本地做备份

反正云存储服务商都不负责数据丢失的。数据丢了，只能自认倒霉。 iOS fly ~

没人问问楼主怎么发财吗 iOS fly ~

我只说一句：快照不可靠。


我之前在阿里和Vultr都有Windows系统快照恢复了启动不起来，怀疑是硬盘不够了，而快照是机器运行时生成的，重启就因为硬盘不够启动不起来了。

没准阿里云自己搞坏了装糊涂，原来在上海IDC上班时这种甩锅的事见多了。

你没有数据库定时备份任务？

全部依靠快照？
半路出家的吧？生产DB 每天 都要执行备份任务

回复1#皇.帝

操作前居然不备份啊

59楼的说法最靠谱

云端的快照可以认为可靠。。。但是这个可靠是系统级的可靠。。。

具体到你的业务，你可能无法确定是否可靠

万一你的业务是跑在内存里的。。。或者使用了内存作为缓存。。。HiPDA·NG

我不是技术人员，我对软件的要求也没有那么高，实际我就是只需要快照起作用。

现在阿里的所谓高级工程师给回复了，一口咬定，按日期恢复之后，一定是那天的状态，我的技术人员告诉我，8.7有基于软件的订单收入，但是回复8.8，或者之前任何2018.10.09之后的快照，没有任何一个订单。

查数据库日志， 我感觉是被删库了！

db操作comit后，会写到硬盘里的
如果快照恢复有问题，绝逼是快照出的问题

即使全内存运行的DB 也会随时执行物理写入操作
不存在内存运行，物理磁盘不写入的情况

除非。。。他的db有特殊设置

1.你是不是得罪人了？2.蹲下来想想，最近有谁离职的

3.你的管理好混乱，最基本的生产 db每日备份都没有，草台班子？

ecs不是只有系统盘稳定吗？挂载的另外一个盘是不稳定的

提前一周改个参数，把表改成内存存储。。。

然后，一周后删库。。。

于是，就会有现在这个效果了，2个快照也恢复不了数据了吧

按照惯例。。。删库的时候默认路径下也许会留个黑客的联系方式和比特币地址。。。


但是，黑客没想到的是，楼主直接回滚了快照。。。看都没看一眼HiPDA·NG

没有备份的话，神仙也难救

刚又看了一遍帖子，楼主，你就算着急，发求助贴说话态度也好点，别好像坛友也欠你的一样。 ios fly～

快照备份到了多久的呢？

快照根本靠不住。
其次，不管什么方式的备份，如果执行没有定期恢复测试，实际上就是无效备份

确认数据库在系统盘上？
没有数据盘？
目录的mtime是去年，其他目录的mtime呢？
比如系统文件的mtime。

感觉阿里云自己出了问题,然后甩锅吧,这种事从逻辑上讲就不可能的,快照就类似GHOST，怎么可能今年的快照恢复出来是去年的数据，那个工程师瞎JB乱说。。。

快照是不是与那个域名解析有关系 原来一直快照的是原来ecs的机器的盘 ，在当时快照功能用的缓存的ip 所以一直快照的是原来的磁盘。 这次出问题时估计你这个新机器数据库crash了。你这时如果在新机器上恢复估计可以。但是你重新设置好域名后 新机器就可以连上那个快照了 ,恢复的当然是原来旧机器上的快照

只通过数据库的数据是没办法判断快照时间的。。。

要看系统日志或者相关系统文件是什么时间

楼主想当然的认为快照恢复了，数据库就一定会恢复。。。这个因果关系是不一定的HiPDA·NG

标准 三备份 最起码一个是异地
iOS fly ~

回复79#logic90


78楼说得有道理，你说的这个是瞎扯，懂不懂什么叫快照？

ecs的快照里有内存数据吗？HiPDA·NG

回复82#logic90

就算缓存丢了也不可能丢一年的，楼主代码和数据都在同一个盘，恢复3天前的快照怎么可能恢复到2018年去？动动脑子！

换其他公有云呗

数据库目录的修改时间是2018

就能认为快照是2018年的？你确定？HiPDA·NG

回复85#logic90


你家的数据库一年都不回写数据？

收集监控、流量等信息，证明阿里云快照功能有问题，准备起诉吧。 iOS fly ~

也许搞错了路径呢？HiPDA·NG

快照不是文件级的，快照备份的是扇区 iOS fly ~

如果本地没有备份，目前只能靠阿里云工程师了，工单里提供尽可能详细的信息给他们备用。

//
你提到的第二个异常挺奇怪的，服务器地址不对。

“操作审计”功能开了没有，看一下近期登录记录。如果有异常时间段和IP，接下来整套密码、key建议都换一遍。

现在访问的是迁移之前的服务器吧，迁移后的服务器看不到了？去迁移后那个服务器找备份。书荒点我

找阿里要赔偿，不行就起诉

这么重要的数据，不能只相信云吧。HiPDA·NG

用阿里云快5年，一直没出现过问题

搬凳子听楼主后续的情况

我更感觉像是被黑

域名解析都错了，意味着有人想把数据指向另外的地方。

楼主啊 你系统数据库是不是MSSQL。如果是的话，SQL SERVER好像运行时候数据都在内存里，不会写入到mdf文件里。（我曾经观察过）那你快照的都不会是更改的数据啊！！！

（为此我每天凌晨5点自动重启SQL SERVER，这样就会写入到磁盘）

这样快照就有效了。。。。。我感觉你是这个问题引起的！

你这个故障处理大了啊处理大了。。。

赶紧联系下阿里能不能物理恢复数据了

=========2019年8月8日21:45:55更新

拿实际运营环境截图说话吧。
图1的库系统明天设定5:30自动重启MSSQL SERVER，所以每天5点30会自动写入mdf文件。（不考虑ldf，万一用的简单模式呢？）



图2的库未设定5点30重启，这几个库的mdf文件修改时间全部是系统投用时间。这样整盘快照下来的文件应该是没有数据的？？？？这个我没做试验，但是我觉得有数据的可能性不大。


这两个环境隔天定时fullbackup，每天差异和事务备份，在此基础上做快照+异地。

你确定你懂数据库吗？即使内存数据库，也是需要写日志的，不存在永远不宕机的数据库，也就不存在只跑内存不写硬盘的库。除非是只读的，没啥意义

在看了下，理论上你这一年不写数据的可能性也不存在啊。。

确实有点诡异。处理故障的问题是急了点，一般要回滚的话，也会把当前故障环境备份下吧（方便后期查找故障）。

严重关注此事。

vmware都说快照影响性能，

不能作为备份的手段。


生产环境中，没有多种手段的备份，真是不可想像。