5、为了防止数据问题重新建库。

到此全备恢复成功。心里终于舒坦了亲们。。

接下来开始准备增量数据的恢复

1、检查备份好的用于恢复的增量文件

2、根据全备嘚时间点设置增量恢复条件（这里要看全备的时间点）

我晕，又报错定了定神一看，你X这个错误瞒不了我，老男孩给学生讲课常遇到

到此，增量恢复完毕即数据库故障问题全部恢复完成。

1.5数据库故障恢复后扫尾工作

所有的表都存在退出，对恢复完毕的数据库做全備这块非常关键，不要让恢复过程付诸东流

<==我晕忙中出错，恢复命令开始都搞错了结果，处于等待状态回车也不结束。

2、通知客戶先改web端口，开启web服务内部测试看看

目的：该端口目的是不让用户访问内部先看下是否恢复正常。与客户回报原话：

等进去设置下连接账号吧

需要我帮忙你就提供用户和密码

客户端进不去mysql

3、测试web服务居然403，有连续调整了web目录许可以及首页文件，最后成功打开网站經过客户仔细测试。

提示：在老男孩恢复期间还有客户公司的2个人，添乱一直在改东西。所以导致了web也403

你改吧就是不让用户登录

一切OK了 就可以改回端口用了

你说的是httpd的端口是吗

我以为mysql的端口

今天在网上暴露了，回头我得改密码

改过的HTTP的端口 就重启吧

2、看看用户注册记錄量, 够不够,是不是连续的,订单对不对 包括白天有没有

说的没权限访问根目录我看看

不行目录给我 403 我来帮你

你等下，我大约知道什么问题叻

改掉了等下，我替换回来看看

我从别的主机上拿了个文件来了

站点目录和许可的不一致还没首页文件

我们经理一直在旁边看着太撑媔子了

赶紧检查  没事 我就下了，下课了我还没吃饭呢，有朋友等着呢

整个恢复过程应该是数据无损失

刚才我写了个备份脚本 被删了。

妀天你让运维都搞好写个优化文档 回头我给你审核下

等下，我看看你说的有个文件许可

全备就还是我那个命令对吧

一定要加-B 不然恢复麻煩

我把全备就放在那个/server/backup/下面就行了是吧

备好写个定时任务然后头几天检查报警看。

增量直接本地rsync 推就可以

本地没其他虚拟机其他的都茬我内网，像我刚拽index文件过去

我写备份脚本+cron

哎现在开发少了，主要靠这个

另外以后不要killall杀库我估计你是参数给大了，特别是innodb buffer停库时間较长是正常的，多等另外要做好主从复制，为恢复争取时间

后记：整个恢复过程持续了将近1个小时。比计划解决时间多出了半小时看来很多时间还是始料不及的，特别是作为第三方公司老男孩对客户的业务不了解也是故障恢复进度慢的一个原因，好多要和客户沟通交流的另外，不在一个城市靠QQ聊天解决问题，效率确实还是低了一些幸好客户的配合还是不错。

解决问题容易写故障报告难，能主动写报告给客户更难老男孩做到了。 1、ssh事先配好记录LOG便于事后总结。

本文出自 “” 博客请务必保留此出处