MySQL数据库无完整备份删库，除了跑路还能怎么办？

来源 | 阿丸笔记

责编| Carol

封图| CSDN│下载于视觉中国

“删库跑路”这个词儿，经常被挂在嘴边当玩笑，是因为大家都知道，一旦真的发生这样的事情，企业损失是无比惨重的。

本文作者为 CSDN 博客的一位博主， 从他的描述中得知，前段时间作者所在的公司，由于运维同事的一次误操作，清空了内网核心数据库，导致了公司内部管理系统长时间不可用，大量知识库内容由于没有备份险些丢失。

结合近期的删库跑路事件，我们可以看到，数据库的备份与恢复显得尤为重要。

本文将对此次内网数据恢复过程做一些整理，介绍删库后的抢救方案。同时，引发对数据库稳定性的思考。

接下来让我们从作者的角度，来看看他们是如何对数据库进行抢救的。

数据抢修

这份内网数据事先没有特意备份，所以一开始认为需要从磁盘恢复数据了。所以紧急联系了数据恢复公司，希望过来恢复磁盘数据。

这里需要注意，数据恢复公司建议马上关机，避免磁盘数据被覆盖。

联系数据恢复公司的同时，运维同事在内网找到了几个残缺的备份文件，包括去年4月份的一个全量备份数据、今年2月初一个半全量备份数据（备份到r开头的表就失败了，剩余表没有备份），以及近7天到binlog日志文件。

所以立刻进行另一套恢复方案：

1）用今年2月初的半全量数据恢复一个库A

2）用去年4月份的全量数据恢复一个库B

3）将B数据库中r开头之后的表拷贝一份到数据库A中

4）数据库A中重放近3天的binlog。（注意，binlog回放时间截止到drop命令时间之前）

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、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命令参数见:

https://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’.

数据备份

数据备份可以有多种方式，这里介绍三种

1、本地dump备份数据文件

比较方便存储，不过用起来限制也比较多，容易中断。

mysqldump --max_allowed_packet=1024M -u root xxxxdv > 20200219.sql

2、阿里云dts迁移备份

可以在阿里云上建一个dts迁移任务（迁移任务基本免费，同步任务收费），然后通过dts将源数据库直接迁移到rds、ecs自建数据库、vpc网络下到自建数据等地方。

可以避免dump还原的过程。

需要有个目标库，备份不是以简单的数据文件形式，而是一个备份数据库的形式。

3、xtrabackup(简称xbk)

https://www.percona.com/software/mysql-database/percona-xtrabackup

基于拷贝物理文件和redo来实现备份。

数据库稳定性思考

不管是运维的误操作，还是删库跑路的事件，从根本上反映了企业数据库稳定性管理的不足。

任何事后抢救的措施，都比不上事前的谨慎防范。

如何提高企业数据库的稳定性，避免出现类似这样的事情呢？

1、统一技术栈，使用云厂商的云数据库

从现在云技术的发展来看，以阿里云、华为云等大厂提供的云数据库，能大大降低企业数据库的运维成本。

虽然云数据库可能比自建数据库的价格贵一点，但是，云数据库提供的完整的配套设施，如备份恢复、监控报警、技术支持、数据库高可用等，都会给企业数据库稳定性带来巨大帮助。从长期来看，能够大大节约企业的运维成本和人力成本。

另外，我特意去看了下阿里云的rds数据库，有完整的备份恢复机制，而且七天内的备份数据是不可删除的。

所以，如果使用了云数据库，那基本上不需要担心数据丢失或者被人恶习删除的问题了。

2、自建数据库的完善备份机制

当然，有的公司虽然使用了云数据库，但是出于数据安全性的角度，还是会有自建数据库的可能。

如果使用了自建数据库，那么一定需要有完善的备份机制。

我司自从发生了误操作删除内网数据的事件后，立刻引起重视，重新盘点梳理了核心数据的备份机制，包括云数据库、自建数据库，对于核心数据（包括但不限于生产数据、内部核心数据等）必须实施定期全量备份，同时考虑末日容灾，实施跨机房、跨云厂商的数据备份。

3、更健全的权限管理系统

除了数据备份外，我们还可以看到，数据库权限管理的重要性。

尤其中小企业，数据库权限要么没有管理，开发人员可以任意操作；要么是集中在少数几个运维同事手上。

无论哪种，都不安全。

最好的方式，还是开发一个统一数据库管理操作平台（或者购买类似阿里云DMS产品），在系统层面进行数据库的权限管控。

所有人员都只能通过这个平台操作数据库，同时，禁用危险命令，对高危操作进行分级审核。

《原力计划【第二季】- 学习力挑战》正式开始！即日起至 3月21日，千万流量支持原创作者！更有专属【勋章】等你来挑战

推荐阅读：

真香，朕在看了！