备份实在是太重要了。

从删库到跑路，大家听过很多，但如果没删备份的话，那只能说玩的不够彻底，不专业。所以仔细研究一下备份，从删库加删备份，最后到跑路，还是很有必要的。当然要是会点奇门遁甲（彻底清除操作痕迹）、尿遁后门之术无影踪等，那就真的成功入神了。所以这里大致分析一下备份管理体系，以备在删库的时候，能够彻底些。

• • -

一 备份体系总体思路

• • -

    备份体系大致分为定义备份对象、确定备份频率和备份方式、制定备份集存储策略和恢复管理五个部分。具体如下：

围绕备份管理体系，进行集中的架构和管理，包括：监控备份是否按时按成；备份集验证策略以及恢复演练的计划等。因为备份一般涉及大容量文件的拷贝复制，所以通常会占用较多 IO 和网络带宽，不好好规划的话，极容易影响生产系统的正常使用。

• • -

二 备份对象

• • -

备份体系的第一步是定义备份对象，即确定有哪些需要对象是需要备份。一般情况下，备份对象包括：应用、文件以及图片、数据库、日志（网络安全法对日志有特别要求，一般保留 180 天）、虚拟机服务器等 OS 级别对象等。往大了说，物理服务器、网络设备等硬件设备及其配件都应该作为备份的对象，以防止硬件故障没有备件及时替换；人员备份也可以作为备份对象，运维工作很多 on call 24H ，如果没有人员备份，只靠个人很难。

经过备份定义，大致会得出下列 3 个表格：

表格一：

表格二：

表格三：

• • -

三 备份频率

• • -

    定义好备份对象之后，接下来就要根据不同的备份对象定义不同的备份频率。备份频率也可以成为备份策略，一般分为两类，实时备份和非实时备份。实时备份更多是高可用架构或是负载均衡的架构，允许单点故障，如应用部署多台，数据库主从同步或是 Cluster 架构等。实时同步的情况下，一般只需要备份一个节点的内容和数据即可。

    非实时备份更多的需要依赖脚本或是其他备份工具按照一定频率进行全量备份或是增量备份。可以选择每日全量备份或是周一、三、五全量备份，二、四增量备份等灵活的策略。比较典型的有 Oracle 的 Rman 备份，以一周为周期，可以周天 0 级备份、周一、周二 2 级备份，周三 1 级备份，四、五、六 2 备份等策略。不同的备份频率产生的最终备份集大小不一样、备份耗时不一样、备份恢复的时间和恢复复杂度都不一样。一般情况下，每日全备最简单，但是有耗时久，占用空间大，恢复时间慢等缺点，详细的增量备份，可以节省备份空间，提高恢复速度，但是管理和恢复比较复杂是其一缺点。

    经过指定备份频率之后，上述表格一可以优化为表格 1.1 ：

表格 1.1

• • -

四 备份方式

• • -

定义好备份对象，指定好备份频率之后，接下来需要根据不同的对象进行备份方式的定义。备份方式主要有两种方式：自己编写脚本 + 定时任务实现自动备份；购买专业的商业备份软件进行备份。技术尚可的话，一般情况下采用编写脚本 + 定时任务的方式实现自动备份。编写的脚本一般需要以下几个注意点：

1 调用备份工具的时候，注意环境变量。

2 设置单独的备份账号，并且对备份账户的权限进行最小原则设计。

3 备份异常处理设计并且抛出邮件等方式通知。

4 除了每一备份对象的备份脚本外，还需一个脚本检查是否所有备份对象已经自动备份完成。

5 脚本定时任务的执行时间一般选择业务低峰期，减少对生产系统的影响。

经过备份方式，上表格 1.1 可以优化为表格 1.2 ：

表格 1.2

• • -

五 存储策略

• • -

完整的备份脚本除上述四中 5 点外，还需增加两点：存储策略、失效备份集删除策略。

备份集的存储策略需要考虑两点：存储的位置和周期。一般建议备份集存储位置分为本机 + 同机房备份服务器 + 异地或云端；不同位置的备份集存放的周期不必一致，一般情况本机存放最近 3 天或最近 1~3 次的备份集即可。存储策略的考虑除了基于备份集的大小和存储空间外，还需考量一点，就是所处行业的法律法规：例如有些行业按照网络安全法或是行业监管单位规定，日志需要存放 180 天，数据库备份需要保留 30 天等规定。通过对存储策略的完善，上述表格 1.2 可以优化为表格 1.3 ：

表格 1.3

• • -

六 恢复管理

• • -

一般在架构备份体系的时候，往往会忽略恢复管理这一块。这一块其实非常重要，在需要使用备份集恢复的情况，一般都比较紧急，越紧急的情况越不应该依赖个人的经验和技术，而应该更多的依赖提前备好的预案。恢复管理同备份一样重要，不可或缺。

恢复管理包括四部分：

1 恢复脚本，即备份对象的备份集所对应的灰度脚本。使用该脚本即可完成备份集的自动恢复。

2 恢复条件，定义恢复脚本在何种情况或条件下才可执行，避免在不适宜的情况下进行恢复造成数据不准确。

3 恢复评价，即对于恢复条件下，使用恢复脚本对于备份集进行恢复的时候，会有什么样的影响，例如数据会有多少丢失等。

4 恢复测试，在执行恢复之后，需要进行测试看是否达到预期效果。

特别特别注意：在执行数据恢复的时候，请务必将当期环境进行备份，例如做快照等方式。避免恢复期间出现问题，导致问题更加复杂。

经过恢复管理，上述表格 1.3 可以优化为表格 1.4 ：

• • -

七 总结

• • -

在经历了备份对象定义、指定备份频率、确定备份方式、完成存储策略和恢复管理之后，根据产品线和项目的思路，以项目为单位进行备份，综合上述几个表格，可以优化为如下表格：

备份集明细子表格：

通过脚本或是编程，将备份集相关信息记录并且进行展示，实现对备份集的管理。但是完整的备份管理体系还需要包括备份架构、备份监控、备份集验证策略、应急恢复演练等配套措施。

为了最大程度的减少备份对生产系统的影响，一般建议服务器内备份用的本地硬盘和网络与生产系统用的隔离。；例如单独指定一块网卡用来做备份集的传输，单独的一块或是几块硬盘做本地备份集的存放。

对于备份集集中管理和监控，可以了解指定的备份对象的备份集是否正常完成。备份集验证策略制定备份集验证计划，确保备份集的准确可用性。同时要定期执行恢复演练和系统的应急演练，以增加对备份恢复的熟悉程度。

• • -

八 继续从删库、删备份到跑路

• • -

好了，至此，备份体系的建立大致就是这些。再继续文章开头的话题，从删库到删备份，再到跑路，还是有可能被抓，缺少了另一个关键点：操作痕迹。

一般来讲，干坏事最怕被现场抓住，所以简单点，定时执行是很有必要的，离职俩月或半年后在进行自动破坏，结果会更坏，女人会更爱。定时执行加彻底删除操作痕迹，是一个合格的报复着的必备技能啊。删除痕迹三步走：

1history –c

2vi /etc/profile ，找到 HISTSIZE 这个值，修改为 0

3 删除日志：

删除登录失败记录 :echo> /var/log/btmp

删除登录成功记录 :echo> /var/log/wtmp （此时执行 last 命令就会发现没有记录）

删除日志记录 :echo> /var/log/secure

当然彻底一些的话，可以清理一下 /var/log 下的所有日志文件。

清楚痕迹之后，还需要做一下伪装，常用的恶搞是给命令起别名，还有就是伪装成系统用户或是系统脚本，定期执行，这样也不易被发觉。

综合一下，完整的从删库到删备份到完美跑路的脚本应该是：

1 脚本名称伪装，执行用户伪装，定时任务伪装。

2 编写脚本触发器，可以定时触发，也可以人为操作触发，如定义别名，引导用户执行。

3 脚本执行：① 不记录操作日志 ② 进行破坏操作 ③ 清理日志，清空操作痕迹。

4 脚本定时任务删除、脚本彻底删除，不可恢复。

5 思考五分钟，然后跑路。

哦，对！你在编写脚本上传至服务器的时候，也可能被监控到，例如被操作系统记录到（后面会删除），被堡垒机或是跳板机记录掉，所以这一部分的记录也得给删掉。

差不多了，可以进行跑路了。

• • -

九 作为企业怎么办？

• • -

为了防止这种删库，删备份然后跑路的情况发生，大致两种方式：

1 权限管理最小化，制定科学合理的权限管理。

2 人员离职流程要完善，尤其是离职人员权限的回收和相应账户、密码、权限的更新。

当然了，还有一点非常非常重要，那就是：好聚好散。