让DBA梦中惊醒——吐槽那些让你崩溃备份恢复的故事/遭遇赢取精美礼品

显示全部楼层 · 2013-8-16 14:31:52

数据库对于系统的重要性相信每个开发者都有深深的体会。数据库的安全则更是重中之重。意外断电、系统或服务器崩溃、用户失误、磁盘损坏甚至数据中心的灾难性丢失都可能造成数据库文件的破坏或丢失。而这些文件往往包含着珍贵的数据，经不得任何损失。
有句话说得不错“系统总是要崩溃的，没有有效的备份只是在等哪一天死”。在这种情况下，备份与恢复占了举足轻重的位置。数据库管理员必须对此有所准备。数据库的备份和恢复是指为保护一个数据库免于数据损失或者在发生数据损失后进行数据重新创建的各种策略和步骤、方法。
这里为广大的PUBer准备的大量的备份恢复案例，欢迎大家下载查阅。然后结合自己的经历，给大家分享备份恢复中的经验教训。

2.jpg (21.38 KB, 下载次数: 39)
下载附件
2012-11-20 08:57 上传

1.jpg (16.7 KB, 下载次数: 38)
下载附件
2012-11-20 08:57 上传

点击获取更多备份恢复案例和技术
话题讨论：吐槽那些让你奔溃备份恢复的故事/遭遇。（可以分享自己备份失败的经历，以及备份过程中遇到的问题，和存储管理人员之间发生的故事）
讨论时间：2012.11.20——2012.12.5
讨论奖励：在讨论结束后我们将抽取五位回答内容丰富的会员赠送50元充值卡一张。获奖会员：hwtongrushmLuiseDalian ylky_2000师恩难忘

千问 · 2013-8-16 14:31:52

arron刘发表于 2012-11-20 10:22
来点干货吧。
好吧,说下以前在富士康的一个事情.
是Oracle环境的.当时有对Oracle数据库建制Standby数据库,是每15分钟将Archive Log传送到Standby服务器上,之后应用到Standby数据库.
而且由于磁盘空间紧张,所以也设置的有Crontab来定期删除Archive Log.
同时每天,System部门的同事也有将这些Archive Log备份到Tape,并且保存三年时间.(由于是每天备份,所以可以保证所有的Archive Log都能被完整的备份到Tape)
之后某一天,业务部门提出需求,需要将一个月之前的数据库恢复出来,他们需要做一些比对.
这时,就需要System部门的同事将Tape中的文件传送到Server上,之后再应用.
但是悲剧的事情发生了,System是每天有在做到Tape的backup,但是Check Backup的人不太仔细,导致最近两个月的Tape Backup都失败了.也就是说我们根本不可能实现用户的需求.
最后也没办法,只能对业务部门say sorry.当然那个同事也被我们的副理训惨了.最后据说,那一年的绩效没了..........
所以不管是对数据库还是其他的一些文件,假如非常重要,那么我们需要严格的执行备份+Check备份+定期还原机制.
这样才能保证我们的SLA.否则会被业务部门或者用户challenge.

千问 · 2013-8-16 14:31:52

本帖最后由 rushm 于 2012-11-20 16:29 编辑
说个sqlserver 的，10来台，一次全备的数据大概2.5T，没有专门的存储设备，之前的数据都是交叉异地备份在同一个机房里边的其他win机器（win共享出来做备份的目录，经常因为网络、磁盘空间不足等原因备份失败，慢慢的麻木了dba没及时去处理），其他人没有所有db的备份列表，所以存在两个问题，1、偶尔性出现备份失败；2、其他人不知道哪台db备份在哪里。机房在singapore，一次一台数据库垮了（raid10），一个负责备份的DBA刚好回国玩，联系不上，到处找不到这台机备份在哪里。结果只能找专业公司恢复数据，最后总算恢复过来，服务停了大概5天，给领导骂个半死。
之后因为存储设备贵，弄了台性能不错的2U机器装linux，插几个几T的移动硬盘上面，开个samba共享。所有的db错开时间远程备份进去，全备+差异备，定期更换移动硬盘回office（机房在office旁边），居然很稳定了。另一个就是wiki上多了db备份维护页面。

千问 · 2013-8-16 14:31:52

在这里分享一点经验。
一般公司关于数据库的备份和恢复都有它自己的一套完整的东西，这可能是前人留下的，也可能就是你做的。
这样做的目的，无外乎是想使备份工作更具有条理，不会忘记一些过程。建议使用RMAN进行备份和恢复。
因为不使用RMAN，对备份的管理就很麻烦可能需要不断的提醒自己：
（1）哪些数据文件最近7天没有备份
（2）某个归档日志是否可以删除
（3）SYSTEM表空间有几份备份
（4）备份保存在何处
（5）这个备份是什么时候发生的，当时的数据文件头SCN是多少
当然这只是不断向自己提出的问题中相当小的一部分。为了快速准确地回答这些问题，
管理员必须认真地做记录，可能还要编写一些脚本。然而这些步骤在Oracle的控制之外，
人为影响因素较高，这些步骤越复杂导致人为错误的可能性就越高。
例，错误地删除一个归档日志，导致将来只能不完全恢复。
记得在维护学校学籍数据时犯过一个类似的错误，因为那时才刚刚入行，
做一些动作之前，考虑不是很多，也很大胆。结果造成新生数据的重新
录入（还好，再打新生注册页面，让学生自己填写即可，因为原来的数据就是学生自己输入的。）
所以做DBA时间越长，胆子就越小，当然出现问题的机率也主越小了。
总之，建议形成自己的备份策略，使用RMAN备份和恢复工具或第三方专业的备份工具和存储介质
就比较有保障。

千问 · 2013-8-16 14:31:52

本帖最后由师恩难忘于 2012-11-21 09:42 编辑
记得在以前的公司上班的时候，因为业务原因管理过一台IBM的P690小型机，数据库是IBM的DB2，系统是AIX5.2，上面装了许多IBM的通讯组件。因为系统要进行升级，所以我们需要修改一部分数据，更新一部分数据字典。在修改之前，肯定是先做备份，做好备份之后我还对备份进行了检查，确保备份是OK的。在其他机器上的升级都很顺利地成功了，自认为万无一失的我就开始了升级。
现在语句记得不太清楚了，好像是
db2 connect to ifss
db2 "load from acmmst.txt of del ....."
好像导出的是ixf，然后报错了：
SQL****** NO ....
SQLSTATE=*****
当时我很郁闷，加班了几个通宵，最后换来的是一泼冷水浇头。。。无奈之中我拨打了IBM技术热线，IBM工程师说有这个错误，不过不可能出现。。。
问题还是得不到解决，最后没有办法，我和同事又加了好几个通宵班重建了20多张表，才把这个窟窿给补上。事情过去了一年多，IBM还给我寄了一张光盘，上面是这个问题的系统补丁。感觉大公司就是不一样，服务很到位。

千问 · 2013-8-16 14:31:52

1、和领导确认备份策略
由于存储空间的紧张，备份策略设置1周一次全备，每天备份归以前的档日志，备份完毕删掉以前的归档。
后来遇到一个蛋疼的问题，数据库有张表的数据不对，需要恢复到1周以前，此时没有备份了，也就无从恢复了。因此在做备份策略的时候，一定和要领导确认清楚目前的备份恢复窗口。否则
出了问题，他可能说是你的原因。
2、和应用确认是否是物理删除
去年在公司做一次数据恢复，由于软件的BUG，导致一批数据被删除了。数据库需要恢复到早上的时刻。
到了晚上便开始恢复，由于存储性能不佳，恢复比较慢，折腾了大半天终于把这个表恢复了。
可以第二天开发人员说，这个不需要恢复的，他们设计的是逻辑删除，表里有个DEL_FLAG字段，删除的时候就把这条记录DEL_FLAG设置为'Y'，如果早点知道，就不用那么麻烦了。

3、确认好最优的恢复方案
还是由于误操作，导致数据全部被更新，等知道的时候，已经很长时间了，通过闪回的方法是不可行了。
这次是同事做的恢复，由于同事对数据库了解的不是很深，他准备将备原全部还原，由于备份文件大约有300G，整个还原将会浪费很长时间，可能到第二天恢复不了，其实这个完全没有必要
整个还原。由于这个表只在某一个表空间中，我们只需要还原SYSTEM，SYSAUX,UNDOTBS,及其这个表空间即可。在RESTORE的时候SKIP掉不需要的表空间，这样将会大大节省恢复时间和存储空
间。

4、要是有一份最新的备份该多好
今年年初的时候，一个朋友的公司的数据库因为系统2次掉电后，导致数据库起不来了。
据朋友描述数据库MOUNT不上，本以外是控制文件的问题，这个也不难恢复。后来登陆到服务器上查看才知道，
问题比较复杂，掉电导致文件头都坏掉了，通过BBED发现文件头开始的块都是0000000000，根本都没有数据了，而且数据库最近1年没有备份，
最后折腾了2个晚上，从1年前的一个备份中找出表结构，然后从文件里抽取数据，当然了还是丢了很多数据。
不过比较幸运的是关键的几个表数据基本都找回来了。
真的在多的备份都不为过，总有一天或许你就用到，等你用到的时候，如果没有备份，想哭都来不及。
有时候可以考虑EXP来辅助备份。

千问 · 2013-8-16 14:31:52

背景：前一段时间（2012.9-2012.10），结算单业务数据翻倍，在处理完错误数据后，为了还原当时场景，模拟错误发生时候的系统状况，对数据库还原。
数据库是oracle 10g，服务器是2003 serverr2的。
还原文件大于50G,
下面说说我还原的惨痛过程：
1、还原的服务器都是32位的2003 server，这个没有影响，blocksize都是8192.
2、第一次还原，很多表数据都没有还原进去，这个原因是其中有一个主要表空间我只建了一个数据文件，这样最大表空间也就是32G，而这个表空间实际应该已经超过50G了，所以失败。
3、第二次还原，吸取第一次的教训，为关键表空间建了三个能自动扩展到32G的数据文件，这次表都还原成功了，但是又出现一个奇怪的问题——就是procedure、package等都没有还原成功，只有表！这个原因到现在我也不知道为什么。
4、然后我就不还原整个库了，打算还原单表。备份的dmp文件只有system整库的，这个是前提。我在还原单表的时候遇见了
"0x0041b385"指令引用的"0x00000038"内存。该内存不能为"read"这个错误，这个最终也是疑问收场，没有成功。
5、截止到以上，我已经很痛苦了。浪费的时间也已经在一周以上了。
最后曲线救国，先按照正库还原，最终也是只还原了表；然后通过toad将运行库中的procedure、trigger等倒出来，再进行创建。这样算是勉强恢复完成，不过环境跟当时真实的，肯定还是有差异的。
关于这个我觉得值得反思的是数据库中的数据，尽量少为好，业务数据定期转移或者清理，给系统足够的空间，业务也有足够的效率，一旦出现故障，还原也方便。

千问 · 2013-8-16 14:31:52

本帖最后由 ylky_2000 于 2012-11-22 13:57 编辑
分享备份失败的经历：
环境：两台linux服务器，一台正式，一台备用。通过rsync同步备份文件夹。
事故经过：因切换过服务器ip地址对调了。导致将备份服务器上的配置文档同步到了正式服务器上，造成部分数据丢失。
备份脚本如下：rsync -a --progress --delete --password-file=/usr/local/password-file/usr/local/squid/etc/ 备用服务器ip:/usr/local/squid/etc/
造成事故原因分析：
1、两台服务器密码一致，导致两个脚本都可以顺利认证执行；
2、缺少检查机制，运维流程不规范。

千问 · 2013-8-16 14:31:52

我来说说我经历的一次数据还原.
有一次帮助另一个分公司进行数据还原,要将SAP正式环境还原到测试环境,正式环境和测试环境都接在同一个带库,所以只要从备份的磁带中捞出数据到测试环境就好了,应该是一件很简单事,以前自己公司也经常这么做.
在做还原之前先检查了一些项目:
1.正式环境的备份记录没有问题,备份耗时约两小时左右.
2.网络连接也都正常,测试环境的数据能够正常备份到带库中.
3.预估还原时间2-4小时,预留8小时做数据还原,将这条备份通道这段时间内的其它备份取消或推迟.
但在实际还原时发现速度特别缓慢,最后整整用去21个小时才把数据全部还原到测试环境,最后查找原因发现正式环境备份时是走SAN,而测试环境根本就没有接入SAN环境,完全是走网络在还原,崩溃!
所以,在做备份还原时一定要考虑到每一个细节,千万不能心存侥幸.

千问 · 2013-8-16 14:31:52

支持Arron