1.背景
前段时间，由于运维同事的一次误操作，清空了内网核心数据库，导致了公司内部管理系统长时间不可用，大量知识库内容由于没有备份险些丢失。
结合这两天微盟的删库跑路事件，我们可以看到，数据库的备份与恢复显得尤为重要。
本文将对此次内网数据恢复过程做一些整理，介绍删库后的抢救方案。
同时，引发对数据库稳定性的思考。
2.数据抢修
这份内网数据事先没有特意备份，所以一开始认为需要从磁盘恢复数据了。所以紧急联系了数据恢复公司，希望过来恢复磁盘数据。
这里需要注意，数据恢复公司建议马上关机，避免磁盘数据被覆盖。
联系数据恢复公司的同时，运维同事在内网找到了几个残缺的备份文件，包括去年4月份的一个全量备份数据、今年2月初一个半全量备份数据（备份到r开头的表就失败了，剩余表没有备份），以及近7天到binlog日志文件。
所以立刻进行另一套恢复方案：
1）用今年2月初的半全量数据恢复一个库A
2）用去年4月份的全量数据恢复一个库B
3）将B数据库中r开头之后的表拷贝一份到数据库A中
4）数据库A中重放近3天的binlog。（注意，binlog回放时间截止到drop命令时间之前）
2.1 dump文件恢复
一开始想通过阿里云，把dump文件恢复到rds上。
结果发现需要super权限，而这个权限是阿里云高权限账号（另外还有普通账号）也不具备的，问了阿里云也不提供。因此，无法恢复到rds。
所以我们只能把dump文件恢复到本地数据库。
在ECS上建立一个mysql数据库，然后就是dump文件恢复。
有两种方式：
1）命令行恢复
mysql -u root xxxdb < xxxx-backup.sql
2）在mysql客户端中恢复
用root登陆后
use xxxdb;
source /data/xxxx-backup.sql
2.2 binlog文件重放恢复
基于起止时间恢复数据
sudo mysqlbinlog --start-datetime="2020-02-16 17:00:01" --stop-datetime="2020-02-20 17:00:00" —database=xxxdb mysql-bin.000218 | mysql -f -u root xxxdb
--database 指定了使用binlog中的哪个数据库进行导入，否则，如果binlog中有多个库的操作记录，会大量报错。
更多binlog命令参数见:
dev.mysql。com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database
-f 用于mysql命令，重建过程中如果遇到问题会继续执行而不是中断退出。
Actually mysqlbinlog does not stop after error, mysqlbinlog just converts log file to text format, nothing more. The problem is that mysql client stops after error. Please try 'mysql -f'.
3 数据备份
数据备份可以有多种方式，这里介绍三种
3.1 本地dump备份数据文件
比较方便存储，不过用起来限制也比较多，容易中断。
mysqldump --max_allowed_packet=1024M -u root xxxxdv > 20200219.sql
3.2 阿里云dts迁移备份
可以在阿里云上建一个dts迁移任务（迁移任务基本免费，同步任务收费），然后通过dts将源数据库直接迁移到rds、ecs自建数据库、vpc网络下到自建数据等地方。
可以避免dump还原的过程。
需要有个目标库，备份不是以简单的数据文件形式，而是一个备份数据库的形式。
3.3 xtrabackup(简称xbk)
www.percona。com/software/mysql-database/percona-xtrabackup
基于拷贝物理文件和redo来实现备份。
- 数据库稳定性思考
不管是运维的误操作，还是像微盟这样的恶性事件，从根本上反映了企业数据库稳定性管理的不足。
任何事后抢救的措施，都比不上事前的谨慎防范。
如何提高企业数据库的稳定性，避免出现类似这样的事情呢？
1）统一技术栈，使用云厂商的云数据库
从现在云技术的发展来看，以阿里云、华为云等大厂提供的云数据库，能大大降低企业数据库的运维成本。
虽然云数据库可能比自建数据库的价格贵一点，但是，云数据库提供的完整的配套设施，如备份恢复、监控报警、技术支持、数据库高可用等，都会给游戏交易企业数据库稳定性带来巨大帮助。从长期来看，能够大大节约企业的运维成本和人力成本。
另外，我特意去看了下阿里云的rds数据库，有完整的备份恢复机制，而且七天内的备份数据是不可删除的。
所以，如果使用了云数据库，那基本上不需要担心数据丢失或者被人恶习删除的问题了。
2）自建数据库的完善备份机制
当然，有的公司虽然使用了云数据库，但是出于数据安全性的角度，还是会有自建数据库的可能。
如果使用了自建数据库，那么一定需要有完善的备份机制。
我司自从发生了误操作删除内网数据的事件后，立刻引起重视，重新盘点梳理了核心数据的备份机制，包括云数据库、自建数据库，对于核心数据（包括但不限于生产数据、内部核心数据等）必须实施定期全量备份，同时考虑末日容灾，实施跨机房、跨云厂商的数据备份。
3）更健全的权限管理系统
除了数据备份外，我们还可以看到，数据库权限管理的重要性。
尤其中小企业，数据库权限要么没有管理，开发人员可以任意操作；要么是集中在少数几个运维同事手上。
无论哪种，都不安全。
最好的方式，还是开发一个统一数据库管理操作平台（或者购买类似阿里云DMS产品），在系统层面进行数据库的权限管控。
所有人员都只能通过这个平台操作数据库，同时，禁用危险命令，对高危操作进行分级审核。
