【记录】删库如何进行恢复？

一、前言

新年伊始，万象更新，先说点什么吧，当今日新月异的巨量信息不断冲击着人们的视觉，本人虽然不是一枚川粉吧，但也很热衷去吃瓜大统领的各种骚操作，四年来给我们普通人带来了不知道多少欢乐啊，还有各种让人惊愕的美式双标，哈哈哈，眼瞅着还有一个多星期大统领就要离我等而去了，还是有点莫名的失落啊，往后可就没瓜可吃啦。当然，还有让人惊愕到下巴的是，大统领过分而激烈的幕后操作（就是那个双标不能再双标的风景线了，国会山事件）直接招致了自我的“社会性死亡”，说好的美式民主和言论自由呢，墙倒众人推，凄凄惨惨戚戚向谁说理去啊！哈哈哈哈，孤家寡人的建国大统领只能在白房子里暗淡的度过为数不多的时光了，别怕，世界人民与你同在，上帝与你同在。当然，该理智还是要理智的，上帝也在奉劝你不要把手中的核按钮当中儿戏啊，一旦引发出灾难级的事故，你就成为了人类公敌啊！

额，跑题了，我本来想说的是最近博客上炸开锅的那件事 —— 链家程序员怒删公司 9TB 数据，被判 7 年！ 但仔细想想，好像也没跑题啊，性质都是不同寻常的骚操作，川普幕后煽动的暴力事件直接招致了自己推特脸书的被封和被各种谴责，而这位程序员大佬怒删了自己公司的数据库，不管出发点是什么，同样都造成了无法逆转的被动局面。

二、删库事件

以前还只是听说“删库跑路”是一个梗，笑一笑就过去了，但如今的社会越来越重视信息安全，身为程序员也要培养自己的职业操守和修养，不管自己对公司如何的不满，也要在法律允许的范围内表达和宣泄情绪啊！

好奇之下，本能的搜了一下近些年这类的事故新闻还真不少啊，来看一下有哪些：

• 2017年1月31日，Gitlab一名系统管理员误删库，发现问题300GB左右的数据只剩下约4.5GB，经过抢救，GitLab.com最终丢失了6小时的数据库数据；
• 2017年4月5日，知名的VPS服务商DigitalOcean出现了一次删除生产数据库的事故，导致DigitalOcean的控制面板和API无法正常使用，时间长达4小时56分；
• 2017年9月，广西某大型IT企业为客户进行扩容割接时，误操作将 HSS 设备里面的用户数据格式化删除，导致该运营商近80万用户数据丢失，从而无法通话和上网，波及七八个地市，事故重大；
• 2018年6月4日14时许，被告人韩冰在位于本市海淀区上地三街福道大厦三层的链家网（北京）科技有限公司（以下简称链家公司），利用其担任链家公司数据库管理员并掌握公司财务系统root权限的便利，登录公司财务系统服务器删除了财务数据及相关应用程序，致使公司财务系统无法登录，链家公司为恢复数据及重新构建财务系统共计花费人民币18万元；
• 2018年9月，顺丰一位高级工程师在升级系统数据库时，不慎将RUSS数据库删除，导致了顺丰线上发车功能约10小时无法使用，负面影响严重，最后该程序员被辞退，也被“跑路”了；
• 2020年2月，微盟公司研发中心运维部核心运维人员贺某因为生活不如意、无力偿还网贷等个人原因，在酒后恶意删除公司SAAS业务数据，导致微盟旗下300万商户的线上业务全部停止，商铺后台的所有数据被清零，经过8天14个小时的抢修才得以正常运营。

虽然，删库常被开发和运维的程序员拿来调侃，但一旦发生给企业造成的事故还是很严重的，不仅是公司或者客户的损失问题了，还有可能自己要面临刑事责任，必须引起重视。

三、如何有效避免删库事故发生？

俗话说防患于未然，杜绝事故要从预防抓起，不同参与的人员，这里有几点建议可以参考，这里删库不仅指删除整个数据库，也包含了删除数据库表及表中的记录等。

开发人员

线上出现问题，开发人员避免不了去操作生产环境的数据库，那么作为开发有以下几点建议：

• 首先，肯定是尽量避免使用 rm -rf 命令了，脑海里要有操作删除数据后带来的风险意识；
• 其次，养成备份的意识，考虑到连接的生产数据库或数据库表是否有备份，一定要先备份再操作；
• 最后，则是给开发人员最好使用低等级、低权限的账号登录进行操作，控制其操作的权限范围，实在需要操作部分敏感表或数据项需要向上级申请。

运维人员

运维人员作为数据库管理员的角色，处理着客户反映的各种问题，避免不了和生产数据库打交道，那么作为运维有以下几点建议：

• 首先，肯定是限制删除数据的行为发生了，可以分配其不同等级的权限账号使用；
• 其次，避免不了删除数据的话，需要进行先备份再操作、或向上级申请等。
• 最后，最好有运维日志，简单记录下此次维护进行了哪些操作，解决了什么问题等等，做到事故分析的可溯源，防止隐蔽的事故发生时过了时间找不到具体的操作。

上面只是从人的角度考虑进行规避删库的风险，当然还可以从系统本身进行有效的机制建设：比如，多机房备份数据（本地备份和远程备份），又比如，利用网络可视化和AI实现智能风控对数据操作进行实时监控与告警等等。

四、删库如何进行恢复？

这里才是今天的重点了，虽然是万无一失是终极目标，但在没有备份的情况下，一旦发生了该怎么处理呢？首先，不能放弃自己，不能想着去跑路啊，哈哈哈。冷静，冷静，再冷静，好的心态有助于挽回当前糟糕的局面。

删库的情况有很多种，比如只删了数据库表的某一部分数据，比如只批量删除了某些数据库的表，也有可能误操作删了整个数据库。这里特此记录和备份一下，该怎么恢复哪些被删除的东西，希望自己永远也用不到~~~

1、Oracle数据库

1、恢复delete删除的数据

在delete数据后，如果被删除的数据块未被覆盖，可以利用闪回方式直接找回：

• 确定删除数据的时间范围，使用以下语句查询删除的数据：

select * from 表名 as of timestamp to_timestamp('删除时间点','yyyy-mm-dd hh24:mi:ss');

• 把查询到的删除数据重新插入原表：

-- 注意要保证主键不重复
insert into 表名 (select * from 表名 as of timestamp to_timestamp('删除时间点','yyyy-mm-dd hh24:mi:ss'));

如果表结构没有发生改变，还可以直接使用闪回整个表的方式来恢复数据（表闪回操作，要求用户必须要有flash any table权限）：

-- 开启行移动 
alter table 表名 enable row movement;
-- 恢复表数据
flashback table 表名 to timestamp to_timestamp('删除时间点','yyyy-mm-dd hh24:mi:ss')
-- 关闭行移动功能
alter table 表名 disable row movement;

2、恢复drop删除的数据

在drop删除表时，没有直接清空表所占的块，Oracle把这些已删除的表的信息放到了一个虚拟容器“回收站”中，而只是对该表的数据块做了可以被覆写的标志，所以在块未被重新使用前还是可以恢表的：

-- 查询这个“回收站”或者查询user_table视图来查找已被删除的表:
select object_name,original_name,type,droptime from user_recyclebin;
select table_name,dropped from user_tables;
-- 如果还能记住原表名，则可以用下面语句直接恢复:
flashback table 原表名 to before drop;
-- 如果记不住了，也可以直接使用回收站的表名进行恢复，然后再重命名:
flashback table "回收站中的表名(如：Bin$DSbdfd4rdfdfdfegdfsf==$0)" to before drop rename to 新表名;

误删数据库的话，使用数据库的闪回功能，可以使数据库回到过去某一状态：

alter database flashback on;
flashback database to scn SCNNO;
flashback database to timestamp to_timestamp('删除时间点','yyyy-mm-dd hh24:mi:ss');

特别注意，Oracle提供了“回收站”机制才使得找回误删的数据成为可能，而drop删除时加上purge选项，删除数据的同时会回收空间，造成永久性的删除了表数据， 因此慎用purge选项。

3、恢复truncate删除的数据

在truncate表时，不会产生日志记录和回滚段空间的使用，不能用闪回方式恢复，但在数据库有备份的情况下是可以用rman恢复的，但因恢复一张表而关停数据库是不可取的。

那有没有在不影响数据业务正常运行的情况下去快速恢复表呢？参考这里：oracle数据库中truncate表后如何快速恢复 。

2、MySQL数据库

1、通用情况

场景说明：在人为SQL语句造成的误操作或者没有主从复制等的热备情况宕机时，通过delete删了数据库表的数据，或者drop删了整个数据库，该怎么去修复呢？

恢复条件：mysql要开启binlog日志功能，并且要全备和增量的所有数据，对外要通知停机维护，禁止继续更新数据库。

参考这里：①. mysql数据库误删除后的数据恢复操作说明。
②. 无备份情况下恢复MySQL误删的表，这样做再也不用怕误删了。

2、极端情况

场景说明：备份，同时没有开启二进制日志，常规的恢复方法彻底走入死路。

恢复条件：使用事务日志恢复。

参考这里：记录一下误删除了mysql表中的数据后的恢复过程。

3、阿里云的mysql数据库环境

场景说明：适用于数据库环境为阿里云的RDS mysql5.7 高可用版的情况。

恢复条件：一定要开启RDS的SQL洞察功能可以查看sql记录。

参考这里：记一次删库后，我是如何恢复数据库和处理的。

小结

本人虽然还没遇到过误删数据的事情，但能感觉到恢复起来还是挺繁琐的，开发中要尽量避免误删才是最重要的。当然，如果遇到了这种事情也要淡定啊，办法总比困难多。未雨绸缪，这里就是我为什么整理记录的动机了，如果以后遇到的话再更新和分享恢复的思考过程吧。