携程当年也是数据库挂了！损失了一笔钱！这次炉石居然更离谱，只能恢复前几天数据！我一直在小公司，真不知道你们大公司咋玩的！求指教好的备份方案，我现在用的阿里云的 RDS ，数据量大概 40 多个 G
This topic created in 3583 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jan 18, 2017
上次一条 Sql 执行错地方了，本来应该在本地执行，结果没看界面直接在生产环境执行了，把用户余额全刷成 0 ！然后通过 RDS 早上 3 点的备份，一笔一笔的根据用户的交易充值记录来算！完全不懂怎么根据 log 来操作！
 |
1
能恢复到前几天了 还叫没备份？？？ 只是说明别人没有每天备份吧
但是这样的数据肯定是要每天备份的吧 一般小项目 一周一备份基本也没什么问题吧 |
1 |
2
@xjp 阿里云的 RDS 有一天一备份！
|
 |
3
这种场景要靠日志呀，当然还要有从日志中恢复数据的工具。相信这样的故障不太可能是单一问题导致的，很可能是同时出现很多问题导致数据丢失，事先设计的备份方案又不能正常工作。说到底还是自动化不够、测试不够。很多灾备措施如果不能经常地测试和演练，关键时刻能不能发挥作用就不好说了。
|
|
5
|
 |
6
另一个贴的回复不是说都挂了 40 个小时了吗。。按公告说的那份损坏的备份在朝上加 24 小时的话，倒回 14 号未必不是没有每日备份吧。。
|
|
7
@langmoe 诶，心好累！上次把用户的余额全部刷成 0 了，赶紧停止交易！
|
 |
8
怎么说呢，灾备问题，安全问题等这类问题，都是没出事的时候没人在意，出事了傻眼了。
而且好的全自动的灾备方案，并不是那么容易弄出来。就算弄出来了，不演练就无法知道这方案是否可行。可是对大型复杂的系统，想演练一下灾备方案也不是那么简单。好吧就算大家都配合，方案弄好了，演练也成功，然后产品发生重大更新，保不齐就要求灾备方案也要相应更新，谁能保证一套方案行万年？也就是说，你要费心做方案，费心去演练，而且还要周期性地去做。好吧，费了半天劲，都做好了，效果呢？对不起看不到。不像开发，费心费力做出东西来，能让人看到。你灾备做得好，外人看不到啊。 不出事的时候，说搞灾备的没用。 出事的时候，还说搞灾备的没用。 |
|
10
@SpicyCat 确实是，系统大了灾备也麻烦！
|
|
11
@awsx 机房都是有独立发电机的！就像笔记本断电并不会重启电脑！
|
 |
12
备份数据库同时也坏了才是神奇 这是磁带被耗子吃了吧
|
|
13
我们自己的 vmware 的虚拟化 备份估计也是买的 还有远程的灾备机房 还能怎么弄 简单粗暴呗 能备份数据库的全库或者增量 不能的直接整个系统备份
其实舍得给钱方案多得是 反正现在磁盘便宜 一周全量备份一次存一个月资料都没啥问题 |
 |
14
山口山越搞越烂就算了，想不到炉石也。。。黄易💊
|
 |
15
现在用的阿里 RDS 每天备份，但是从来没用过备份数据，看来还是要定期测试一下。
|
 |
16
总比 12306 的空调坏了理由好点……
|
|
17
@murmur 诶！！！！反正事情没那么简单！游戏架构也复杂！！！毕竟灾备演练是很耗成本的！！！！
|
|
18
@n6DD1A640 哥，山口山是啥？？？
|
|
19
@billowqiu 我现在用 python 写了一份 dump 数据，将用户信息以及交易记录转移到杭州备份！如果真发生回滚，补贴也有数据可查！
|
|
20
@wdlth 12306 是全球最忙的网站！
|
 |
21
|
 |
22
我是每日异地备份
|
 |
23
@lianxiaoyi wow 山口山
|
|
24
@kn007 66666 全量备份？
|
 |
simple2025Jan 19, 2017
25
@lianxiaoyi 怎们做备份，完全不会。。
|
 |
sujin190Jan 19, 2017
26
其实一个数百 G 上 T 的数据备份还不太容易啊，一次全量备份得花一个小时以上，完全占着 io ，有什么简单的方案么？
|
 |
dreamwarJan 19, 2017
27
关注了一天，感觉应该是：
1.数据被污染； 2.热备数据被污染； 3.冷备 3 天一备 /发生事故后停止了冷备； 所以最后恢复的数据应该是从 14 号的冷备数据恢复回来的 |
|
kn007Jan 19, 2017
30
@lianxiaoyi 全盘数据增量备份+重要文件打包备份
|
Select Language