IDC 网络与安全

http://netkiller.github.io/journal/security.idc.html

Mr. Neo Chen (陈景峯), netkiller, BG7NYT

中国广东省深圳市龙华新区民治街道溪山美地
518131
+86 13113668890

<netkiller@msn.com>

$Id: 161f838a2fd37d2fc35178f48ff39d7933d311de

转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。

文档出处:

http://netkiller.github.io

http://netkiller.sourceforge.net

微信扫描二维码进入 Netkiller 微信订阅号

QQ群：128659835 请注明“读者”

2017-06-16

摘要

在群里看到有网友问，IDC的服务器是否需要开启防火墙，我意识到应该写一篇关于IDC安全的文章。

1. 背景
2. 网络拓扑的变化
3. 恢复方案
4. 手工恢复
5. 恢复方案
- 5.1. 第一种
- 5.2. 第三种

1. 背景

我们来假设一个场景。

你是否适用 mysqldump 每隔一段时间备份一次数据库，每个备份一个数据文件。

公司决策你是不是因为数据持续增加，有些数据已经不会再查询，会删除旧的历史数据。

有时公司突然说要恢复历史数据，有可能全补回复，有可能部分恢复。

你将怎么做？

我们来假设一个场景。

你是否适用 mysqldump 每隔一段时间备份一次数据库，每个备份一个数据文件。

公司决策你是不是因为数据持续增加，有些数据已经不会再查询，会删除旧的历史数据。

有时公司突然说要恢复历史数据，有可能全补回复，有可能部分恢复。

你将怎么做？

首先看看备份方式，你是不是采用这种方法备份

我使用一串数字表述数据库数据递增情况，数据的增长变化

垂直轴表示备份时间轴

2. 网络拓扑的变化

首先看看备份方式，你是不是采用这种方法备份

我使用一串数字表述数据库数据递增情况，数据的增长变化

垂直轴表示备份时间轴

最常见的备份方法，完全备份

下面这种备份方式也比较常见，这种方式很有规律。

更复杂的情况，无规律可循

以此类推，删除原因有多种，如空间不足，改善查询性能...等等

最杂的情况，无规律可循，同时交叉数据可能会有更新

我用'o' 表示与上次备份中有差异的部分。

3. 恢复方案

，最好恢复，第二种。

上面所提三种备份方式

第一种: 最好恢复，100% 都能搞定.
第二种: 恢复起来稍复杂，仍能搞得定.
第三种: 比较复杂，因为本档案中存在重复记录，费点脑筋
第四种: 最复杂，看似复杂，其实也不复杂，跟第三种差不多.

3.1. 第一种

这种备份非常简单，菜鸟也搞搞定

文本格式回复

压缩格式恢复

或者先使用gunzip解压，再恢复数据

提示

很多人喜欢用tar打包，我不见这样做，一个文件时无需使用tar打包的，画蛇添足

仅使用gzip压缩，可以方便使用zcat直接操作文件。

3.2. 第三种

这种恢复建议按照顺序进行，因为重叠数据没有变化，所以即可以顺时间轴恢复也可以逆时间轴，条件是表结构需要有主键(PK)

insert 方式有要求

必须是

不能是

这种备份参数如下

这种方式备份，备份文件尺寸会比较大。

正时序恢复案例，

逆时序恢复数据

因为有主键，所以已存在的重复记录不会被重复插入。

3.3. 第四种

这种恢复必须按照顺序进行，即可以顺时间轴恢复也可以逆时间轴，但处理上稍有不同.一旦操作错误数据就会损坏，同时也有很多条件。

顺时序恢复数据，只需将 insert 替换为 replace 即可

新数据总会覆盖旧数据

但逆向就不同了，逆时序恢复数据与上面第三种相同, 恢复过程中旧数据在 insert 的时候不会覆盖现有的新数据。仅仅将失去的数据恢复到数据库中。

操作要十分谨慎，理解正向与逆向的不同，方能操作。

4. 手工恢复

有时上面所讲的四种恢复方法不能满足你需求，我们模拟一个场景，假如你需要恢复一个时间段的数据，或者ID字段去一个范围等等，上面所举例子均为一刀切。该怎么办呢？

不用担心方法总是有的

INSERT ... SELECT

REPLACE ... SELECT

例 1. INSERT ... SELECT

5. 恢复方案