第4章备份策略设计

4. 备份策略设计：全量备份、增量备份、差异备份的对比与选择、备份窗口与频率规划

说到Tick级数据的备份策略，我得先跟你交个底：没有银弹。全量、增量、差异这三种方式，我这些年都踩过坑，也填过坑。今天咱们就掰开揉碎了聊聊，到底怎么选、怎么配。

4.1 三种备份方式的核心差异

先看一张图，把三者的关系理清楚：

这张图其实已经把核心逻辑说透了。我简单解释一下：

全量备份：把整个Tick数据集完整复制一份。最笨但最可靠的方法。
增量备份：只备份从上一次备份（不管全量还是增量）以来变化的数据。
差异备份：只备份从上一次全量备份以来变化的数据。

你想想看，增量备份就像记流水账——每天只记今天新发生的事。差异备份呢？它像每周写周报——每次都从周一算起，把这一周的变化汇总起来。

4.2 三种方式的优劣对比

直接上表格，一目了然：

维度	全量备份	增量备份	差异备份
备份速度	慢（全量扫描）	快（仅变化数据）	中等（累积变化）
存储空间	大（完整副本）	小（仅增量）	中等（累积增量）
恢复速度	快（直接加载）	慢（需逐层回放）	中等（全量+最新差异）
恢复复杂度	低	高（依赖链完整）	中
数据冗余	无冗余	低冗余	中等冗余
典型场景	周/月备份	小时级高频备份	日备份

💡 我的经验之谈

我在项目中遇到过最头疼的情况：增量备份链断了。某个中间增量文件损坏，导致后面所有增量都白费。所以我现在有个习惯——全量备份是底线，增量备份是效率，差异备份是折中。三者搭配使用，别只押注一种。

4.3 Tick级数据的特殊考量

Tick数据跟普通业务数据不一样。它有几个特点：

数据量大：一天可能产生几十GB甚至上百GB的Tick数据。
写入频繁：每秒成千上万条记录。
时间敏感：恢复时要求时间戳精确到毫秒甚至微秒。
不可变性：历史Tick数据几乎不会修改，只有新增。

这些特点决定了我们的备份策略不能照搬通用方案。我个人建议：

全量备份放在低峰期：比如凌晨2点到4点，交易所休市时段。
增量备份可以高频：每15分钟或每小时做一次增量，覆盖盘中数据。
差异备份作为日终快照：每天收盘后做一次差异备份，方便快速恢复当天数据。

⚠️ 避坑指南

我曾经因为增量备份频率太高（每5分钟一次），导致备份文件数量爆炸，恢复时光找文件就花了半小时。后来我调整策略：高频增量只保留最近24小时，超过24小时的合并成差异备份。这个教训让我明白——备份策略要兼顾恢复效率。

4.4 备份窗口与频率规划

备份窗口，说白了就是你能用来做备份的时间段。Tick数据系统通常7×24小时运行，但交易时段和非交易时段的负载差异很大。

我一般这样规划：

时间段	系统负载	推荐备份类型	频率	备份窗口
交易时段（9:30-15:00）	高	增量备份	每30分钟	5分钟以内
盘后时段（15:00-17:00）	中	差异备份	每日1次	15-30分钟
夜间时段（17:00-次日8:00）	低	全量备份	每周1-2次	2-4小时
周末/节假日	极低	全量备份+校验	每周1次	4-8小时

你可能会问：为什么交易时段只做增量？原因很简单——全量备份太耗时，会拖慢系统响应。我见过有人试图在盘中做全量备份，结果IO被打满，Tick数据写入延迟飙升，差点被运维投诉。

🔧 实用技巧

我习惯用滚动窗口策略：保留最近7天的增量备份，最近30天的差异备份，以及最近12个月的全量备份。超过这个时间范围的，归档到冷存储。这样既保证了快速恢复，又控制了存储成本。

4.5 一个实际的备份策略示例

假设我们管理一个期货Tick数据系统，每天产生约50GB数据。我的策略是这样的：

# 备份策略配置示例（伪代码）
backup_policy = {
    "full_backup": {
        "schedule": "0 2 * * 0",          # 每周日凌晨2点
        "retention": 12,                   # 保留12个月
        "compress": True,
        "verify": True                     # 备份后校验
    },
    "diff_backup": {
        "schedule": "0 17 * * 1-6",        # 周一至周六17:00
        "retention": 30,                   # 保留30天
        "base_on": "last_full"             # 基于最近一次全量
    },
    "inc_backup": {
        "schedule": "*/30 9-15 * * 1-5",   # 交易时段每30分钟
        "retention": 7,                    # 保留7天
        "base_on": "last_any"              # 基于最近任意备份
    }
}

这个配置看起来简单，但实际落地时有很多细节。比如：

全量备份时，要确保增量备份链不会断。我通常在全量完成后，清理掉之前的增量文件。
差异备份的"base_on"必须指向全量，不能指向另一个差异。否则恢复时逻辑会乱。
增量备份的"base_on"可以指向全量或增量，但必须保证链的连续性。

📌 核心要点总结

全量备份是基石，但成本高，适合低频执行。
增量备份效率高，但恢复时依赖链完整，适合高频执行。
差异备份是折中方案，适合日终快照。
备份窗口要避开系统高峰，交易时段只做轻量级备份。
恢复速度比备份速度更重要——别为了省存储而牺牲恢复效率。