# XXX平台容灾备份方案设计

| 文档属性 | 内容 |
|---------|------|
| 文档名称 | XXX平台容灾备份方案设计 |
| 文档版本 | V1.0 |
| 编制日期 | 2026年7月 |
| 密级 | 机密 |

---

## 修订记录

| 版本号 | 修订日期 | 修订内容 | 编制人 | 审核人 |
|--------|---------|---------|--------|--------|
| V1.0   | 2026-07-01 | 初稿编制 |        |        |

---

## 目  录

- [1 概述](#1-概述)
  - [1.1 编制目的](#11-编制目的)
  - [1.2 适用范围](#12-适用范围)
  - [1.3 术语与缩略语](#13-术语与缩略语)
  - [1.4 参考文档](#14-参考文档)
- [2 系统现状分析](#2-系统现状分析)
  - [2.1 平台概述](#21-平台概述)
  - [2.2 飞服平台架构](#22-飞服平台架构)
  - [2.3 监管平台架构](#23-监管平台架构)
  - [2.4 中间件组件对比](#24-中间件组件对比)
- [3 容灾备份需求分析](#3-容灾备份需求分析)
  - [3.1 业务连续性需求](#31-业务连续性需求)
  - [3.2 RPO与RTO指标](#32-rpo与rto指标)
  - [3.3 数据安全需求](#33-数据安全需求)
  - [3.4 备份数据范围](#34-备份数据范围)
- [4 容灾备份总体方案](#4-容灾备份总体方案)
  - [4.1 设计原则](#41-设计原则)
  - [4.2 容灾架构模型](#42-容灾架构模型)
  - [4.3 双中心异地灾备总体架构](#43-双中心异地灾备总体架构)
  - [4.4 网络与域名规划](#44-网络与域名规划)
- [5 飞服平台容灾备份方案](#5-飞服平台容灾备份方案)
  - [5.1 飞服平台部署架构](#51-飞服平台部署架构)
  - [5.2 飞服平台数据备份策略](#52-飞服平台数据备份策略)
  - [5.3 飞服平台增量备份方案](#53-飞服平台增量备份方案)
  - [5.4 飞服平台全量备份方案](#54-飞服平台全量备份方案)
  - [5.5 飞服平台灾备切换流程](#55-飞服平台灾备切换流程)
- [6 监管平台容灾备份方案](#6-监管平台容灾备份方案)
  - [6.1 监管平台部署架构](#61-监管平台部署架构)
  - [6.2 监管平台数据备份策略](#62-监管平台数据备份策略)
  - [6.3 监管平台增量备份方案](#63-监管平台增量备份方案)
  - [6.4 监管平台全量备份方案](#64-监管平台全量备份方案)
  - [6.5 监管平台灾备切换流程](#65-监管平台灾备切换流程)
- [7 数据备份安全机制](#7-数据备份安全机制)
  - [7.1 加密传输方案](#71-加密传输方案)
  - [7.2 数据一致性校验](#72-数据一致性校验)
  - [7.3 密钥管理](#73-密钥管理)
  - [7.4 访问控制与审计](#74-访问控制与审计)
- [8 自动化运维方案](#8-自动化运维方案)
  - [8.1 备份自动化调度](#81-备份自动化调度)
  - [8.2 数据导入自动化](#82-数据导入自动化)
  - [8.3 异常告警与人工介入机制](#83-异常告警与人工介入机制)
  - [8.4 监控与日志](#84-监控与日志)
- [9 灾备演练方案](#9-灾备演练方案)
  - [9.1 演练目标](#91-演练目标)
  - [9.2 演练计划](#92-演练计划)
  - [9.3 演练流程](#93-演练流程)
  - [9.4 演练评估标准](#94-演练评估标准)
- [10 具体操作手册（待完善）](#10-具体操作手册待完善)
  - [10.1 MySQL备份与恢复操作手册](#101-mysql备份与恢复操作手册)
  - [10.2 InfluxDB备份与恢复操作手册](#102-influxdb备份与恢复操作手册)
  - [10.3 MinIO备份与恢复操作手册](#103-minio备份与恢复操作手册)
  - [10.4 Doris备份与恢复操作手册](#104-doris备份与恢复操作手册)
  - [10.5 灾备切换操作手册](#105-灾备切换操作手册)
  - [10.6 灾备回切操作手册](#106-灾备回切操作手册)
- [附录A 备份任务Cron表达式汇总](#附录a-备份任务cron表达式汇总)
- [附录B 灾备切换检查清单](#附录b-灾备切换检查清单)

---

## 1 概述

### 1.1 编制目的

本文档旨在为XXX平台（包含飞服平台与监管平台）提供一套完整的、可落地执行的容灾备份方案设计。方案以"双中心+异地灾备"为核心架构，通过定期增量备份与全量备份相结合的数据保护策略，确保在单一机房发生灾难性故障时，业务能够在规定时间内完成接管切换，恢复平台正常运行，最大程度降低数据丢失风险。

本文档将作为XXX平台容灾备份体系建设的指导性文件，为后续系统部署、运维操作、灾备演练提供技术依据。

### 1.2 适用范围

本方案适用于以下系统与组件：

- **飞服平台**：部署于电信机房（主中心）与移动机房（灾备中心）的全部Kubernetes集群及中间件服务
- **监管平台**：部署于电信机房（主中心）与移动机房（灾备中心）的全部Kubernetes集群及中间件服务
- **涉及人员**：系统运维工程师、数据库管理员、网络管理员、安全管理员

### 1.3 术语与缩略语

| 术语/缩略语 | 全称 | 说明 |
|------------|------|------|
| RPO | Recovery Point Objective | 恢复点目标，指灾难发生后允许丢失的最大数据量，以时间度量 |
| RTO | Recovery Time Objective | 恢复时间目标，指灾难发生后系统恢复服务所需的最长时间 |
| K8s | Kubernetes | 容器编排平台 |
| EMQX | — | 高性能MQTT消息代理服务器 |
| MySQL | — | 关系型数据库管理系统 |
| InfluxDB | — | 开源时序数据库 |
| MinIO | — | 高性能对象存储服务 |
| Doris | Apache Doris | 高性能实时分析数据库 |
| AES | Advanced Encryption Standard | 高级加密标准，对称加密算法 |
| DNS | Domain Name System | 域名解析系统 |
| GSLB | Global Server Load Balancing | 全局服务器负载均衡 |
| CCR | Cross-Cluster Replication | Doris跨集群复制 |

### 1.4 参考文档

| 序号 | 文档名称 | 说明 |
|------|---------|------|
| 1 | 《XXX平台系统架构设计说明书》 | 平台整体架构参考 |
| 2 | 《信息系统灾难恢复规范》（GB/T 20988-2007） | 国家灾难恢复标准 |
| 3 | 《Kubernetes官方文档》 | K8s集群管理参考 |
| 4 | 《Velero官方文档》 | K8s备份恢复工具参考 |
| 5 | 《Apache Doris备份恢复文档》 | Doris数据备份参考 |

---

## 2 系统现状分析

### 2.1 平台概述

XXX包含两大独立运行的业务平台：

- **飞服平台**：面向无人机飞行服务场景，提供无人机、机库的数据接入、业务管理、视频存储与时序数据分析等核心功能。通过域名 `A.com` 对外提供访问。
- **监管平台**：面向低空空域监管场景，提供探测设备、反制设备、无人机、机库的数据接入，以及多源融合分析、三维空间地图、视觉探测等核心功能。通过域名 `B.com` 对外提供访问。

两平台均采用Kubernetes集群部署方式，运行环境相互独立，互不依赖。

### 2.2 飞服平台架构

飞服平台的技术架构及中间件组件如下：

| 组件 | 功能职责 | 容灾备份需求 |
|------|---------|-------------|
| EMQX | 负责接收和转发无人机、机库传输的实时数据（MQTT协议） | **无需容灾备份**。EMQX作为消息代理，数据为实时流转性质，不持久化存储业务状态 |
| MySQL | 负责存储平台所有结构化业务数据，包括用户信息、飞行计划、设备管理、权限配置等 | **需要容灾备份**。作为核心业务数据库，数据丢失将直接影响平台业务运行 |
| InfluxDB | 负责存储平台时序数据，包括无人机飞行轨迹、传感器采集数据、设备状态监控指标等 | **需要容灾备份**。时序数据是飞行记录与运营分析的重要依据 |
| MinIO | 负责存储无人机和机库产生的视频文件、图片资源等非结构化数据 | **需要容灾备份**。视频数据为飞行任务执行的重要凭证 |

**【图示说明：飞服平台技术架构图】**

> 图片内容描述：一张分层架构图。最上层为"用户访问层"，标注域名A.com，通过Ingress Controller接入。中间层为"Kubernetes集群"，内部包含多个Pod，分别部署飞服平台的微服务应用（如飞行管理服务、设备管理服务、用户服务等）。底层为"中间件层"，从左到右依次排列四个组件框：EMQX（标注灰色，注明"无需备份"）、MySQL（标注绿色，注明"需要备份"）、InfluxDB（标注绿色，注明"需要备份"）、MinIO（标注绿色，注明"需要备份"）。各微服务与中间件之间以箭头连线表示数据流向。左侧有一条虚线箭头从外部设备图标（无人机、机库）指向EMQX，标注"MQTT数据上报"。

### 2.3 监管平台架构

监管平台的技术架构及中间件组件如下：

| 组件 | 功能职责 | 容灾备份需求 |
|------|---------|-------------|
| EMQX | 负责接收和转发探测设备、反制设备、无人机、机库传输的实时数据（MQTT协议） | **无需容灾备份**。EMQX作为消息代理，数据为实时流转性质，不持久化存储业务状态 |
| MySQL | 负责存储平台所有结构化业务数据，包括探测目标信息、反制任务记录、设备管理、权限配置等 | **需要容灾备份**。作为核心业务数据库，数据丢失将直接影响平台业务运行 |
| Doris | 负责存储多源融合分析产生的时序数据及三维空间地图数据，承担大规模数据分析查询任务 | **需要容灾备份**。融合分析数据和空间地图数据是监管业务的核心数据资产 |
| MinIO | 负责存储视觉探测产生的视频文件和图片数据 | **需要容灾备份**。视觉探测数据为监管取证的重要依据 |

**【图示说明：监管平台技术架构图】**

> 图片内容描述：一张分层架构图。最上层为"用户访问层"，标注域名B.com，通过Ingress Controller接入。中间层为"Kubernetes集群"，内部包含多个Pod，分别部署监管平台的微服务应用（如探测管理服务、反制管理服务、多源融合分析服务、三维空间地图服务等）。底层为"中间件层"，从左到右依次排列四个组件框：EMQX（标注灰色，注明"无需备份"）、MySQL（标注绿色，注明"需要备份"）、Doris（标注绿色，注明"需要备份"）、MinIO（标注绿色，注明"需要备份"）。各微服务与中间件之间以箭头连线表示数据流向。左侧有一条虚线箭头从外部设备图标（探测设备、反制设备、无人机、机库）指向EMQX，标注"MQTT数据上报"。

### 2.4 中间件组件对比

| 对比维度 | 飞服平台 | 监管平台 |
|---------|---------|---------|
| 消息中间件 | EMQX（无需备份） | EMQX（无需备份） |
| 关系型数据库 | MySQL | MySQL |
| 时序/分析数据库 | InfluxDB | Doris（Apache Doris） |
| 对象存储 | MinIO | MinIO |
| 数据来源 | 无人机、机库 | 探测设备、反制设备、无人机、机库 |
| 访问域名 | A.com | B.com |
| 部署环境 | 独立K8s集群 | 独立K8s集群 |

> **说明**：飞服平台与监管平台的核心差异在于时序/分析数据库的选型不同——飞服平台使用InfluxDB，监管平台使用Apache Doris。这一差异导致两个平台在数据备份的具体实施策略上存在区别，但整体灾备架构和流程保持一致。

---

## 3 容灾备份需求分析

### 3.1 业务连续性需求

根据XXX平台的业务特性和运营要求，容灾备份方案须满足以下业务连续性需求：

1. **多机房冗余部署**：飞服平台与监管平台须在电信机房和移动机房分别完成一模一样的完整部署，两个机房的部署环境相互独立，互不依赖。
2. **快速业务接管**：当任一机房发生灾难性故障且无法短时恢复时，另一机房应在 **2小时以内** 完成业务接管，恢复平台对外服务。
3. **域名透明切换**：灾备切换通过DNS域名解析实现，终端用户无需更改访问地址即可无感知切换至灾备机房。
4. **独立运行能力**：灾备机房应具备独立承载全部业务的能力，无需依赖故障机房的任何资源。

### 3.2 RPO与RTO指标

| 指标 | 目标值 | 说明 |
|------|-------|------|
| **RTO（恢复时间目标）** | ≤ 2小时 | 从故障确认到灾备机房完成业务接管的总时间。其中DNS切换后的域名生效时间预计在10分钟以内，剩余时间用于数据验证和服务确认 |
| **RPO（恢复点目标）** | ≤ 2小时 | 允许丢失的最大数据时间窗口为2小时。增量备份周期设置为每2小时执行一次，确保RPO不超过2小时 |

### 3.3 数据安全需求

1. **传输加密**：所有跨机房的数据备份传输必须采用对称加密方式（AES-256），确保数据在传输过程中不被窃取或篡改，保证核心业务数据不外泄。
2. **完整性校验**：备份数据在传输完成后须进行一致性校验（SHA-256哈希校验），确保传输过程中数据未发生损坏或丢失。
3. **访问控制**：备份数据的存储和传输通道须实施严格的访问控制，仅授权运维人员可操作。
4. **审计追踪**：所有备份和恢复操作须记录完整日志，支持事后审计。

### 3.4 备份数据范围

#### 3.4.1 飞服平台备份数据范围

| 数据源 | 数据类型 | 备份目标 | 备份必要性 |
|--------|---------|---------|-----------|
| MySQL | 结构化业务数据（用户、飞行计划、设备管理等） | MySQL（灾备中心） | 必须 |
| InfluxDB | 时序数据（飞行轨迹、传感器数据、设备状态等） | InfluxDB（灾备中心） | 必须 |
| MinIO | 非结构化数据（视频文件、图片资源等） | MinIO（灾备中心） | 必须 |
| EMQX | 实时消息数据 | — | 不需要 |

#### 3.4.2 监管平台备份数据范围

| 数据源 | 数据类型 | 备份目标 | 备份必要性 |
|--------|---------|---------|-----------|
| MySQL | 结构化业务数据（探测目标、反制任务、设备管理等） | MySQL（灾备中心） | 必须 |
| Doris | 多源融合分析时序数据、三维空间地图数据 | Doris（灾备中心） | 必须 |
| MinIO | 非结构化数据（视觉探测视频、图片数据等） | MinIO（灾备中心） | 必须 |
| EMQX | 实时消息数据 | — | 不需要 |

---

## 4 容灾备份总体方案

### 4.1 设计原则

本容灾备份方案遵循以下设计原则：

| 原则 | 说明 |
|------|------|
| **独立性原则** | 每个机房独立部署完整的平台环境，包括K8s集群和全部中间件，机房之间不存在运行时依赖关系 |
| **一致性原则** | 飞服平台与监管平台采用相同的灾备架构和流程框架，仅在具体中间件备份策略上因组件差异而有所区别 |
| **自动化原则** | 数据备份、加密传输、一致性校验、数据导入等流程均应实现自动化运行，减少人工操作风险 |
| **安全性原则** | 数据传输全程采用对称加密保护，密钥独立管理，确保备份数据不外泄 |
| **可恢复性原则** | 增量备份保存3份副本，全量备份保存1份副本，确保在多种故障场景下均可恢复数据 |
| **可演练原则** | 灾备方案应具备定期演练能力，验证切换流程和RTO/RPO指标是否达标 |

### 4.2 容灾架构模型

本方案采用 **"双中心 + 异地灾备"** 架构模型：

- **主中心（电信机房）**：承载日常业务运行，作为业务流量的主要入口。
- **灾备中心（移动机房）**：部署与主中心一模一样的完整环境，日常处于热备状态，定期接收主中心的增量备份数据。当主中心发生故障时，灾备中心快速接管业务。

该架构模型的核心特点：

1. **主备模式**：日常业务仅在主中心运行，灾备中心接收数据备份并保持就绪状态。
2. **数据单向同步**：数据从主中心向灾备中心单向同步，避免双向同步带来的数据冲突问题。
3. **域名级切换**：通过DNS域名解析切换实现流量转移，切换过程对用户透明。

**【图示说明：双中心异地灾备架构总览图】**

> 图片内容描述：一张横向布局的架构图，左右两侧分别表示"电信机房（主中心）"和"移动机房（灾备中心）"，两侧结构完全对称。
>
> 左侧"电信机房"内部包含：一个K8s集群框（内含多个微服务Pod），集群下方排列中间件组件（MySQL、InfluxDB/Doris、MinIO、EMQX）。上方有一个"DNS解析"框，标注A.com / B.com指向电信机房IP。
>
> 右侧"移动机房"内部包含：与电信机房完全一致的K8s集群和中间件部署。上方同样有"DNS解析"框，标注灾备切换时A.com / B.com指向移动机房IP。
>
> 两个机房之间通过一条粗箭头连接，箭头从左指向右，标注"加密增量备份数据同步（每2小时）"。箭头上方有一个锁形图标，标注"AES-256对称加密"。箭头下方有一条虚线箭头，标注"全量备份数据同步（每周日02:00）"。
>
> 图的最上方居中位置有一个"用户"图标，通过域名A.com / B.com访问平台，虚线分别指向两个机房，其中指向电信机房的线为实线（日常访问），指向移动机房的线为虚线（灾备切换后访问）。

### 4.3 双中心异地灾备总体架构

#### 4.3.1 主中心（电信机房）

主中心承担以下职责：

- 运行飞服平台和监管平台的全部业务服务
- 接收并处理全部业务流量
- 作为数据备份的源端，定期生成增量备份和全量备份数据
- 将加密后的备份数据传输至灾备中心

#### 4.3.2 灾备中心（移动机房）

灾备中心承担以下职责：

- 部署与主中心完全一致的K8s集群和中间件环境
- 接收主中心传输的加密备份数据，执行解密和数据导入
- 日常保持服务就绪状态（应用已部署、中间件已运行，但不对外提供服务）
- 在主中心故障时，通过DNS切换接管全部业务流量

#### 4.3.3 K8s集群配置同步

为确保两个机房的K8s集群部署配置保持一致，建议采用以下策略：

- **GitOps管理**：所有K8s资源配置（Deployment、Service、ConfigMap、Secret等）纳入Git仓库统一版本管理，两个机房通过相同的Git仓库同步部署配置。
- **Velero集群备份**：使用Velero工具定期备份K8s集群资源对象和配置信息，备份文件存储至异地MinIO对象存储，用于灾备恢复时快速重建集群状态。
- **镜像仓库同步**：两个机房均部署独立的容器镜像仓库，通过镜像同步机制保持镜像版本一致。

### 4.4 网络与域名规划

#### 4.4.1 域名规划

| 平台 | 域名 | 日常解析目标 | 灾备切换后解析目标 |
|------|------|------------|------------------|
| 飞服平台 | A.com | 电信机房公网IP | 移动机房公网IP |
| 监管平台 | B.com | 电信机房公网IP | 移动机房公网IP |

#### 4.4.2 域名切换策略

- **DNS TTL设置**：将A.com和B.com的DNS记录TTL值设置为较短周期（建议60秒~300秒），以缩短灾备切换时DNS缓存失效的等待时间。
- **切换方式**：通过域名管理方修改DNS A记录的解析IP地址，将域名从电信机房IP切换至移动机房IP。
- **预期生效时间**：DNS切换操作后，由于TTL设置较短，预计全网生效时间在 **10分钟以内**。

#### 4.4.3 网络通道

- 两个机房之间建立专线或VPN加密隧道，用于备份数据的安全传输。
- 传输通道须满足备份数据带宽需求，确保增量备份数据能够在备份周期内完成传输。

---

## 5 飞服平台容灾备份方案

### 5.1 飞服平台部署架构

飞服平台在电信机房（主中心）和移动机房（灾备中心）采用完全一致的部署架构：

| 部署层级 | 组件 | 部署方式 | 说明 |
|---------|------|---------|------|
| 接入层 | Ingress Controller | K8s Ingress | 反向代理、SSL终止、路由转发 |
| 应用层 | 飞服平台微服务 | K8s Deployment | 无状态应用，支持水平扩展 |
| 消息层 | EMQX | K8s StatefulSet / 独立部署 | MQTT消息代理，无需备份 |
| 数据层-关系型 | MySQL | K8s StatefulSet / 独立部署 | 核心业务数据存储 |
| 数据层-时序 | InfluxDB | K8s StatefulSet / 独立部署 | 时序数据存储 |
| 数据层-对象 | MinIO | K8s StatefulSet / 独立部署 | 非结构化文件存储 |

**【图示说明：飞服平台双中心部署示意图】**

> 图片内容描述：一张左右对称的部署示意图。左侧标注"电信机房（主中心）"，右侧标注"移动机房（灾备中心）"。
>
> 左侧电信机房内部自上而下排列：用户通过A.com域名访问 → Ingress Controller → 飞服平台微服务集群（多个Pod） → 中间件层（EMQX、MySQL、InfluxDB、MinIO并排排列）。外部设备（无人机、机库）通过MQTT连接至EMQX。
>
> 右侧移动机房的结构与左侧完全一致，但标注"灾备就绪，日常不对外服务"。
>
> 两个机房的中间件之间以三条虚线箭头连接（从左指向右），分别标注：MySQL增量同步、InfluxDB增量同步、MinIO增量同步，每条箭头上均有一个锁图标表示加密传输。EMQX之间无连接线。

### 5.2 飞服平台数据备份策略

飞服平台的数据备份采用 **"增量备份 + 全量备份"** 相结合的策略：

| 备份类型 | 执行周期 | 备份内容 | 副本数量 | 保留策略 |
|---------|---------|---------|---------|---------|
| 增量备份 | 每2小时 | 最近2小时的变更数据 | 3份 | 滚动保留最近72小时（36份） |
| 全量备份 | 每周日凌晨02:00 | 全部数据的完整快照 | 1份 | 保留最近4周（4份） |

备份数据流向：

```
电信机房 MySQL     ──加密传输──→  移动机房 MySQL
电信机房 InfluxDB  ──加密传输──→  移动机房 InfluxDB
电信机房 MinIO     ──加密传输──→  移动机房 MinIO
```

### 5.3 飞服平台增量备份方案

#### 5.3.1 MySQL增量备份

| 配置项 | 参数值 |
|--------|-------|
| 备份工具 | Percona XtraBackup / mysqldump（逻辑备份） |
| 备份周期 | 每2小时执行一次 |
| 备份范围 | 最近2小时内发生变更的数据 |
| 备份方式 | 基于Binlog的增量备份 |
| 加密算法 | AES-256-CBC对称加密 |
| 传输方式 | 通过加密通道传输至灾备中心 |
| 一致性校验 | SHA-256哈希校验 |
| 副本数量 | 3份 |

**备份流程**：

1. 在主中心MySQL实例上执行增量备份，导出最近2小时的Binlog变更数据。
2. 对备份文件执行AES-256-CBC对称加密处理。
3. 生成加密后文件的SHA-256哈希校验值。
4. 将加密备份文件和校验文件通过加密通道传输至灾备中心。
5. 灾备中心接收文件后，执行SHA-256校验，确认数据完整性。
6. 校验通过后，解密备份文件并导入至灾备中心MySQL实例。
7. 将备份文件保存3份副本（本地备份存储、灾备中心存储、独立备份存储设备）。

#### 5.3.2 InfluxDB增量备份

| 配置项 | 参数值 |
|--------|-------|
| 备份工具 | influxd backup / influx_inspect export |
| 备份周期 | 每2小时执行一次 |
| 备份范围 | 最近2小时内写入的时序数据 |
| 备份方式 | 基于时间范围的数据导出（按时间切片模拟增量备份） |
| 加密算法 | AES-256-CBC对称加密 |
| 传输方式 | 通过加密通道传输至灾备中心 |
| 一致性校验 | SHA-256哈希校验 |
| 副本数量 | 3份 |

**备份流程**：

1. 在主中心InfluxDB实例上，按时间范围（最近2小时）导出时序数据。
2. 对导出文件执行AES-256-CBC对称加密处理。
3. 生成加密后文件的SHA-256哈希校验值。
4. 将加密备份文件和校验文件通过加密通道传输至灾备中心。
5. 灾备中心接收文件后，执行SHA-256校验，确认数据完整性。
6. 校验通过后，解密备份文件并导入至灾备中心InfluxDB实例。
7. 将备份文件保存3份副本。

#### 5.3.3 MinIO增量备份

| 配置项 | 参数值 |
|--------|-------|
| 备份工具 | MinIO Client（mc）/ MinIO Bucket Replication |
| 备份周期 | 每2小时执行一次 |
| 备份范围 | 最近2小时内新增或修改的对象文件 |
| 备份方式 | 基于修改时间的增量同步 |
| 加密算法 | AES-256-CBC对称加密 |
| 传输方式 | 通过加密通道传输至灾备中心（支持TLS加密传输） |
| 一致性校验 | MD5/SHA-256哈希校验 |
| 副本数量 | 3份 |

**备份流程**：

1. 使用MinIO Client（mc mirror命令）扫描主中心MinIO存储桶，识别最近2小时内新增或修改的对象文件。
2. 对待传输的对象文件执行AES-256-CBC对称加密处理。
3. 生成加密后文件的哈希校验值。
4. 将加密文件通过加密通道（TLS）传输至灾备中心MinIO实例。
5. 灾备中心接收文件后，执行哈希校验，确认数据完整性。
6. 校验通过后，解密文件并存入灾备中心MinIO对应的存储桶。
7. 将备份文件保存3份副本。

> **替代方案说明**：若两个机房的MinIO实例之间网络条件良好，可考虑启用MinIO原生的 **Bucket Replication（桶复制）** 功能替代定时增量备份。Bucket Replication支持近实时的对象级自动同步，可显著降低RPO，但需确保传输通道已开启TLS加密。

### 5.4 飞服平台全量备份方案

| 配置项 | 参数值 |
|--------|-------|
| 执行时间 | 每周日凌晨02:00 |
| 备份范围 | MySQL全量数据 + InfluxDB全量数据 + MinIO全量数据 |
| 存储位置 | 独立备份存储设备（与业务存储物理隔离） |
| 副本数量 | 1份 |
| 保留策略 | 保留最近4个全量备份版本（约1个月） |

**全量备份流程**：

1. **MySQL全量备份**：使用Percona XtraBackup或mysqldump执行全库全量备份，生成完整的数据备份文件。
2. **InfluxDB全量备份**：使用influxd backup命令执行全量数据备份，生成完整的时序数据备份文件。
3. **MinIO全量备份**：使用mc mirror命令执行全量对象同步，将所有存储桶的全部对象复制至备份存储设备。
4. **加密处理**：对全部备份文件执行AES-256-CBC对称加密。
5. **完整性校验**：生成所有加密备份文件的SHA-256校验清单。
6. **存储归档**：将加密备份文件和校验清单存储至独立备份存储设备。

### 5.5 飞服平台灾备切换流程

当电信机房发生灾难性故障，且判断无法在短时间内恢复时，启动飞服平台灾备切换流程。

#### 5.5.1 切换触发条件

- 电信机房出现不可恢复的硬件故障、网络中断或自然灾害
- 经评估判断，故障无法在2小时内恢复
- 由应急指挥团队下达灾备切换指令

#### 5.5.2 切换操作步骤

| 步骤 | 操作内容 | 责任人 | 预估耗时 |
|------|---------|--------|---------|
| 1 | 确认电信机房故障情况，评估是否启动灾备切换 | 应急指挥团队 | 10~30分钟 |
| 2 | 确认灾备中心（移动机房）飞服平台各服务运行状态 | 运维工程师 | 5~10分钟 |
| 3 | 确认灾备中心最近一次增量备份数据已成功导入 | 数据库管理员 | 5~10分钟 |
| 4 | 执行灾备中心数据一致性验证（抽检核心业务表数据） | 数据库管理员 | 10~15分钟 |
| 5 | 启动灾备中心飞服平台全部微服务（如处于待机状态） | 运维工程师 | 5~10分钟 |
| 6 | 域名管理方将A.com的DNS A记录解析IP修改为移动机房公网IP | 网络管理员 | 5~10分钟 |
| 7 | 等待DNS缓存失效，确认A.com解析已指向移动机房IP | 网络管理员 | 5~10分钟 |
| 8 | 执行业务功能验证（登录、核心功能操作验证） | 测试工程师 | 10~15分钟 |
| 9 | 确认灾备切换完成，发布切换成功通知 | 应急指挥团队 | 5分钟 |

**预计总切换时间**：60~120分钟，满足RTO ≤ 2小时的目标要求。

#### 5.5.3 切换后数据评估

灾备切换完成后，需评估数据丢失情况：

- 确认灾备中心最后一次成功导入的增量备份时间点
- 计算从该时间点到故障发生时间的数据丢失窗口（预计 ≤ 2小时）
- 记录数据丢失范围报告，用于后续数据补录或业务处理

**【图示说明：飞服平台灾备切换流程图】**

> 图片内容描述：一张自上而下的流程图，描述灾备切换的完整流程。
>
> 起始节点："电信机房故障发生"。
> 判断节点1："故障是否可在2小时内恢复？" → 是："执行机房故障恢复流程"（流程结束）。→ 否：进入下一步。
> 操作节点1："应急指挥团队下达灾备切换指令"。
> 操作节点2："确认灾备中心服务运行状态"。
> 操作节点3："确认最新增量备份数据已导入"。
> 操作节点4："执行数据一致性验证"。
> 判断节点2："验证是否通过？" → 否："人工介入处理"。→ 是：继续。
> 操作节点5："启动灾备中心全部微服务"。
> 操作节点6："DNS管理方修改A.com解析至移动机房IP"。
> 操作节点7："等待DNS生效，验证域名解析"。
> 操作节点8："执行业务功能验证"。
> 结束节点："灾备切换完成，发布通知"。

---

## 6 监管平台容灾备份方案

### 6.1 监管平台部署架构

监管平台在电信机房（主中心）和移动机房（灾备中心）采用完全一致的部署架构：

| 部署层级 | 组件 | 部署方式 | 说明 |
|---------|------|---------|------|
| 接入层 | Ingress Controller | K8s Ingress | 反向代理、SSL终止、路由转发 |
| 应用层 | 监管平台微服务 | K8s Deployment | 无状态应用，支持水平扩展 |
| 消息层 | EMQX | K8s StatefulSet / 独立部署 | MQTT消息代理，无需备份 |
| 数据层-关系型 | MySQL | K8s StatefulSet / 独立部署 | 核心业务数据存储 |
| 数据层-分析 | Apache Doris | 独立部署（FE + BE节点） | 多源融合分析与三维空间地图数据存储 |
| 数据层-对象 | MinIO | K8s StatefulSet / 独立部署 | 非结构化文件存储 |

> **与飞服平台的差异说明**：监管平台使用Apache Doris替代InfluxDB作为时序/分析数据库，Doris除存储时序数据外，还承担多源融合分析和三维空间地图数据的存储与查询任务。Doris的备份策略与InfluxDB存在显著差异，需采用Doris原生的Backup & Restore机制或CCR跨集群复制方案。

**【图示说明：监管平台双中心部署示意图】**

> 图片内容描述：一张左右对称的部署示意图。左侧标注"电信机房（主中心）"，右侧标注"移动机房（灾备中心）"。
>
> 左侧电信机房内部自上而下排列：用户通过B.com域名访问 → Ingress Controller → 监管平台微服务集群（多个Pod，包括探测管理、反制管理、多源融合分析、三维空间地图等服务） → 中间件层（EMQX、MySQL、Apache Doris集群【含FE和BE节点】、MinIO并排排列）。外部设备（探测设备、反制设备、无人机、机库）通过MQTT连接至EMQX。
>
> 右侧移动机房的结构与左侧完全一致，标注"灾备就绪，日常不对外服务"。
>
> 两个机房的中间件之间以三条虚线箭头连接（从左指向右），分别标注：MySQL增量同步、Doris增量同步、MinIO增量同步，每条箭头上均有一个锁图标表示加密传输。EMQX之间无连接线。

### 6.2 监管平台数据备份策略

监管平台的数据备份采用 **"增量备份 + 全量备份"** 相结合的策略：

| 备份类型 | 执行周期 | 备份内容 | 副本数量 | 保留策略 |
|---------|---------|---------|---------|---------|
| 增量备份 | 每2小时 | 最近2小时的变更数据 | 3份 | 滚动保留最近72小时（36份） |
| 全量备份 | 每周日凌晨02:00 | 全部数据的完整快照 | 1份 | 保留最近4周（4份） |

备份数据流向：

```
电信机房 MySQL  ──加密传输──→  移动机房 MySQL
电信机房 Doris  ──加密传输──→  移动机房 Doris
电信机房 MinIO  ──加密传输──→  移动机房 MinIO
```

### 6.3 监管平台增量备份方案

#### 6.3.1 MySQL增量备份

监管平台MySQL增量备份方案与飞服平台完全一致，具体参见 [5.3.1 MySQL增量备份](#531-mysql增量备份)。

备份内容包括：探测目标信息、反制任务记录、设备管理数据、用户权限配置等所有结构化业务数据。

#### 6.3.2 Doris增量备份

| 配置项 | 参数值 |
|--------|-------|
| 备份工具 | Apache Doris原生Backup & Restore / CCR（Cross-Cluster Replication） |
| 备份周期 | 每2小时执行一次 |
| 备份范围 | 最近2小时内写入或变更的分析数据、三维空间地图数据 |
| 备份方式 | 方案A：基于分区的Snapshot备份；方案B：基于Binlog的CCR增量同步 |
| 加密算法 | AES-256-CBC对称加密 |
| 传输方式 | 通过加密通道传输至灾备中心 |
| 一致性校验 | SHA-256哈希校验 |
| 副本数量 | 3份 |

**方案A：基于Snapshot的分区备份流程**：

1. 在主中心Doris集群中，创建指向灾备中心对象存储（如MinIO）的Repository。
2. 每2小时对新增或变更的数据分区执行BACKUP命令，生成快照文件。
3. 快照文件通过加密通道传输至灾备中心的Repository存储。
4. 灾备中心Doris集群执行RESTORE命令，从Repository中恢复最新的分区快照数据。
5. 生成SHA-256校验值并执行一致性验证。

**方案B：基于CCR的增量同步流程（推荐）**：

1. 在主中心和灾备中心的Doris集群上分别部署CCR Syncer服务。
2. 配置主中心FE和BE节点开启Binlog参数。
3. 通过CCR Syncer建立数据库级别或表级别的跨集群复制链路。
4. CCR基于Binlog机制自动同步DDL和DML变更，实现近实时增量同步。
5. 定期执行数据一致性抽检，确保主备数据一致。

> **方案选择建议**：若Doris版本支持CCR功能（Apache Doris 2.0+），优先推荐方案B（CCR跨集群复制），其同步延迟更低（秒级至分钟级），可显著优于2小时的RPO目标。若Doris版本不支持CCR，则采用方案A（分区Snapshot备份）。

#### 6.3.3 MinIO增量备份

监管平台MinIO增量备份方案与飞服平台完全一致，具体参见 [5.3.3 MinIO增量备份](#533-minio增量备份)。

备份内容包括：视觉探测产生的视频文件、图片数据等非结构化数据。

### 6.4 监管平台全量备份方案

| 配置项 | 参数值 |
|--------|-------|
| 执行时间 | 每周日凌晨02:00 |
| 备份范围 | MySQL全量数据 + Doris全量数据 + MinIO全量数据 |
| 存储位置 | 独立备份存储设备（与业务存储物理隔离） |
| 副本数量 | 1份 |
| 保留策略 | 保留最近4个全量备份版本（约1个月） |

**全量备份流程**：

1. **MySQL全量备份**：使用Percona XtraBackup或mysqldump执行全库全量备份，生成完整的数据备份文件。
2. **Doris全量备份**：使用Doris原生BACKUP命令对全部数据库执行全量快照备份，快照存储至远程Repository。
3. **MinIO全量备份**：使用mc mirror命令执行全量对象同步，将所有存储桶的全部对象复制至备份存储设备。
4. **加密处理**：对全部备份文件执行AES-256-CBC对称加密。
5. **完整性校验**：生成所有加密备份文件的SHA-256校验清单。
6. **存储归档**：将加密备份文件和校验清单存储至独立备份存储设备。

### 6.5 监管平台灾备切换流程

当电信机房发生灾难性故障时，监管平台的灾备切换流程与飞服平台一致，仅在域名和数据验证环节存在差异。

#### 6.5.1 切换触发条件

- 与飞服平台相同（参见 [5.5.1 切换触发条件](#551-切换触发条件)）

#### 6.5.2 切换操作步骤

| 步骤 | 操作内容 | 责任人 | 预估耗时 |
|------|---------|--------|---------|
| 1 | 确认电信机房故障情况，评估是否启动灾备切换 | 应急指挥团队 | 10~30分钟 |
| 2 | 确认灾备中心（移动机房）监管平台各服务运行状态 | 运维工程师 | 5~10分钟 |
| 3 | 确认灾备中心MySQL最近一次增量备份数据已成功导入 | 数据库管理员 | 5~10分钟 |
| 4 | 确认灾备中心Doris数据同步状态（CCR同步延迟/最新Snapshot时间） | 数据库管理员 | 5~10分钟 |
| 5 | 确认灾备中心MinIO最近一次增量备份数据已成功同步 | 运维工程师 | 5~10分钟 |
| 6 | 执行灾备中心数据一致性验证（抽检MySQL核心业务表、Doris分析数据、MinIO对象文件） | 数据库管理员 | 10~15分钟 |
| 7 | 启动灾备中心监管平台全部微服务（如处于待机状态） | 运维工程师 | 5~10分钟 |
| 8 | 域名管理方将B.com的DNS A记录解析IP修改为移动机房公网IP | 网络管理员 | 5~10分钟 |
| 9 | 等待DNS缓存失效，确认B.com解析已指向移动机房IP | 网络管理员 | 5~10分钟 |
| 10 | 执行业务功能验证（登录、探测/反制功能、三维地图、多源融合分析等核心功能验证） | 测试工程师 | 10~15分钟 |
| 11 | 确认灾备切换完成，发布切换成功通知 | 应急指挥团队 | 5分钟 |

**预计总切换时间**：70~135分钟，满足RTO ≤ 2小时的目标要求。

#### 6.5.3 切换后数据评估

与飞服平台一致，灾备切换完成后需评估数据丢失情况（参见 [5.5.3 切换后数据评估](#553-切换后数据评估)）。特别注意：

- 如采用Doris CCR方案，需额外确认CCR同步的最后成功偏移量，评估Doris数据的丢失范围。
- 如采用Doris Snapshot方案，需确认最后一次成功Snapshot的时间点。

**【图示说明：监管平台灾备切换流程图】**

> 图片内容描述：一张自上而下的流程图，与飞服平台灾备切换流程图结构类似，但增加了以下差异节点：
>
> 在"确认最新增量备份数据已导入"步骤中，拆分为三个并行确认操作：①确认MySQL备份导入状态、②确认Doris同步状态（CCR延迟/Snapshot时间）、③确认MinIO备份同步状态。三个并行操作完成后汇聚至"执行数据一致性验证"节点。
>
> DNS修改步骤中标注域名为B.com。业务功能验证步骤中标注"验证探测/反制功能、三维地图、多源融合分析"。其余流程与飞服平台一致。

---

## 7 数据备份安全机制

### 7.1 加密传输方案

#### 7.1.1 加密算法选型

| 配置项 | 参数值 |
|--------|-------|
| 加密算法 | AES-256-CBC（高级加密标准，256位密钥，CBC模式） |
| 加密类型 | 对称加密 |
| 加密工具 | OpenSSL |
| 适用范围 | 全部跨机房传输的备份数据（MySQL、InfluxDB、Doris、MinIO备份文件） |

#### 7.1.2 加密流程

```
备份源文件 → AES-256-CBC加密 → 生成加密文件(.enc) → 加密传输 → 接收端解密 → 恢复数据
```

**加密操作示例**：

```bash
# 加密
openssl enc -aes-256-cbc -salt -pbkdf2 \
  -in backup_data.sql \
  -out backup_data.sql.enc \
  -pass file:/path/to/keyfile

# 解密
openssl enc -aes-256-cbc -d -pbkdf2 \
  -in backup_data.sql.enc \
  -out backup_data.sql \
  -pass file:/path/to/keyfile
```

#### 7.1.3 传输通道安全

- **机房间网络通道**：通过专线或VPN建立加密隧道，确保传输链路安全。
- **MinIO传输**：启用TLS/SSL证书加密，确保MinIO Client与MinIO Server之间的数据传输安全。
- **端口控制**：仅开放备份数据传输所需的特定端口，关闭所有非必要端口。

### 7.2 数据一致性校验

#### 7.2.1 校验机制

| 校验阶段 | 校验方式 | 说明 |
|---------|---------|------|
| 备份文件加密后 | 生成SHA-256哈希值 | 在源端生成加密文件的校验值 |
| 传输完成后 | SHA-256哈希对比 | 在目标端重新计算哈希值，与源端校验值对比 |
| 数据导入后 | 业务数据抽检 | 对核心业务表的记录数、关键字段进行抽样比对 |

#### 7.2.2 校验操作示例

```bash
# 源端生成校验文件
sha256sum backup_data.sql.enc > backup_data.sql.enc.sha256

# 目标端校验
sha256sum -c backup_data.sql.enc.sha256
```

#### 7.2.3 校验失败处理

- 校验失败时，自动触发告警通知运维人员。
- 系统自动重新从源端获取备份文件，执行重传操作。
- 连续3次重传失败后，升级告警等级，要求人工介入排查。

### 7.3 密钥管理

| 管理要求 | 具体措施 |
|---------|---------|
| 密钥存储 | 加密密钥存储于独立的密钥管理系统中，严禁与备份数据同存储 |
| 密钥分发 | 密钥仅在主中心和灾备中心的备份服务器上部署，通过安全通道分发 |
| 密钥更新 | 每季度定期更换加密密钥，更换前后新旧密钥并行使用一个备份周期 |
| 密钥备份 | 密钥以离线方式备份至安全介质，由安全管理员保管 |
| 访问控制 | 仅授权运维人员可访问密钥文件，严格限制文件系统权限 |

### 7.4 访问控制与审计

| 控制维度 | 具体措施 |
|---------|---------|
| 账号管理 | 备份操作使用专用服务账号，与业务账号隔离 |
| 权限控制 | 备份服务账号仅具备数据读取和备份文件写入权限，不具备数据修改或删除权限 |
| 操作审计 | 全部备份操作、传输操作、恢复操作记录至审计日志，日志保留不少于6个月 |
| 网络隔离 | 备份传输通道与业务网络逻辑隔离，避免备份流量影响业务性能 |

---

## 8 自动化运维方案

### 8.1 备份自动化调度

#### 8.1.1 增量备份调度

全部增量备份任务通过Kubernetes CronJob或系统Cron定时任务实现自动化调度：

**飞服平台增量备份任务调度表**：

| 任务名称 | Cron表达式 | 执行时间说明 | 目标组件 |
|---------|-----------|-------------|---------|
| mysql-incremental-backup | `0 */2 * * *` | 每2小时整点执行 | MySQL → MySQL |
| influxdb-incremental-backup | `10 */2 * * *` | 每2小时的第10分钟执行 | InfluxDB → InfluxDB |
| minio-incremental-sync | `20 */2 * * *` | 每2小时的第20分钟执行 | MinIO → MinIO |

**监管平台增量备份任务调度表**：

| 任务名称 | Cron表达式 | 执行时间说明 | 目标组件 |
|---------|-----------|-------------|---------|
| mysql-incremental-backup | `0 */2 * * *` | 每2小时整点执行 | MySQL → MySQL |
| doris-incremental-backup | `10 */2 * * *` | 每2小时的第10分钟执行 | Doris → Doris |
| minio-incremental-sync | `20 */2 * * *` | 每2小时的第20分钟执行 | MinIO → MinIO |

> **说明**：各任务执行时间错开10分钟，避免多个备份任务同时运行对系统资源造成过大压力。

#### 8.1.2 全量备份调度

| 任务名称 | Cron表达式 | 执行时间说明 | 备注 |
|---------|-----------|-------------|------|
| full-backup-weekly | `0 2 * * 0` | 每周日凌晨02:00执行 | 飞服平台和监管平台统一执行 |

#### 8.1.3 备份脚本架构

```
/opt/disaster-recovery/
├── bin/
│   ├── mysql-backup.sh          # MySQL增量/全量备份脚本
│   ├── influxdb-backup.sh       # InfluxDB增量/全量备份脚本（飞服平台）
│   ├── doris-backup.sh          # Doris增量/全量备份脚本（监管平台）
│   ├── minio-sync.sh            # MinIO增量/全量同步脚本
│   ├── encrypt.sh               # AES-256加密脚本
│   ├── decrypt.sh               # AES-256解密脚本
│   ├── verify-checksum.sh       # SHA-256校验脚本
│   └── transfer.sh              # 跨机房传输脚本
├── conf/
│   ├── backup.conf              # 备份配置文件
│   └── alert.conf               # 告警配置文件
├── logs/
│   └── backup-YYYYMMDD.log      # 备份日志文件
└── keys/
    └── .backup.key              # 加密密钥文件（权限600）
```

### 8.2 数据导入自动化

灾备中心的数据导入流程同样实现自动化运行：

1. 灾备中心部署数据接收服务，自动监听备份数据传输。
2. 接收到加密备份文件后，自动执行SHA-256校验。
3. 校验通过后，自动执行解密操作。
4. 解密后的数据自动导入至对应的中间件实例（MySQL、InfluxDB/Doris、MinIO）。
5. 导入完成后，生成导入状态报告并记录日志。

### 8.3 异常告警与人工介入机制

#### 8.3.1 告警分级

| 告警级别 | 触发条件 | 通知方式 | 处理要求 |
|---------|---------|---------|---------|
| **P1-紧急** | 备份任务连续3次执行失败 | 电话 + 短信 + 企业微信 | 15分钟内人工介入 |
| **P2-重要** | 单次备份任务执行失败 | 短信 + 企业微信 | 30分钟内人工介入 |
| **P2-重要** | 数据校验失败（含自动重试） | 短信 + 企业微信 | 30分钟内人工介入 |
| **P3-一般** | 备份任务执行超时（超过预设阈值） | 企业微信 | 1小时内确认处理 |
| **P3-一般** | 备份存储空间低于阈值（<20%） | 企业微信 | 24小时内扩容处理 |

#### 8.3.2 人工介入场景

以下场景需要运维人员人工介入处理：

1. 增量备份任务连续3次执行失败，需排查数据源或传输链路问题。
2. 数据校验连续3次重传后仍失败，需排查传输通道或加密密钥问题。
3. 数据导入至灾备中心后一致性抽检不通过，需排查数据库状态。
4. 全量备份执行失败或耗时异常，需排查存储空间和系统资源。
5. 灾备中心服务健康检查异常，需排查灾备环境运行状态。

### 8.4 监控与日志

#### 8.4.1 监控指标

| 监控项 | 监控内容 | 采集频率 | 告警阈值 |
|--------|---------|---------|---------|
| 备份任务状态 | 各备份任务的执行状态（成功/失败/进行中） | 每次任务执行时 | 失败即告警 |
| 备份数据量 | 每次备份生成的数据量大小 | 每次任务执行时 | 偏差超过50%告警 |
| 备份耗时 | 每次备份任务的执行时长 | 每次任务执行时 | 超过预设阈值告警 |
| 传输带宽利用率 | 机房间传输通道的带宽使用情况 | 每5分钟 | 超过80%告警 |
| 备份存储空间 | 备份存储设备的剩余空间 | 每小时 | 低于20%告警 |
| 灾备中心服务状态 | 灾备中心各中间件和微服务的运行状态 | 每分钟 | 异常即告警 |

#### 8.4.2 日志管理

| 日志类型 | 内容 | 保留周期 |
|---------|------|---------|
| 备份执行日志 | 备份任务的启动时间、执行步骤、数据量、耗时、完成状态 | 90天 |
| 传输日志 | 文件传输的起止时间、文件大小、传输速率、传输结果 | 90天 |
| 校验日志 | 哈希校验的文件名、源端校验值、目标端校验值、校验结果 | 90天 |
| 导入日志 | 数据导入的起止时间、导入数据量、导入结果 | 90天 |
| 操作审计日志 | 人工操作的操作人、操作时间、操作内容、操作结果 | 180天 |

---

## 9 灾备演练方案

### 9.1 演练目标

1. 验证灾备切换流程的完整性和可操作性。
2. 验证RTO和RPO指标是否达到设计目标。
3. 检验运维团队对灾备切换流程的熟练程度。
4. 发现灾备方案中的潜在问题并持续改进。

### 9.2 演练计划

| 演练类型 | 演练周期 | 演练范围 | 说明 |
|---------|---------|---------|------|
| 桌面推演 | 每季度1次 | 全流程 | 以文档推演方式走读灾备切换全流程，不涉及实际操作 |
| 备份恢复演练 | 每季度1次 | 数据备份与恢复 | 实际执行备份数据的恢复操作，验证数据可用性 |
| 切换演练 | 每半年1次 | 全流程切换 | 实际执行灾备切换操作（可在维护窗口期执行），验证端到端切换能力 |

### 9.3 演练流程

#### 9.3.1 演练前准备

1. 制定演练方案，明确演练目标、范围、步骤和人员分工。
2. 通知相关业务方演练时间和可能的影响。
3. 确认灾备中心环境运行状态正常。
4. 准备演练记录表和评估清单。

#### 9.3.2 演练执行

1. 按照灾备切换流程逐步执行操作。
2. 记录每个步骤的实际执行时间和结果。
3. 记录演练过程中遇到的问题和异常情况。
4. 完成业务功能验证，确认灾备环境服务正常。

#### 9.3.3 演练回切

1. 演练完成后，将业务流量切回主中心。
2. 确认主中心业务恢复正常。
3. 验证回切过程中的数据一致性。

#### 9.3.4 演练总结

1. 编制演练报告，汇总演练过程、执行耗时、发现问题。
2. 评估RTO和RPO指标是否达标。
3. 针对发现的问题制定改进措施和整改计划。
4. 更新灾备方案文档（如有必要）。

### 9.4 演练评估标准

| 评估维度 | 达标标准 | 说明 |
|---------|---------|------|
| RTO | ≤ 2小时 | 从启动切换到业务恢复对外服务的总耗时 |
| RPO | ≤ 2小时 | 数据丢失时间窗口不超过2小时 |
| 切换成功率 | 100% | 所有业务功能均正常可用 |
| 数据完整性 | 100% | 备份数据与源数据一致性校验通过 |
| 流程规范性 | 100% | 所有步骤按照文档规范执行 |

---

## 10 具体操作手册（待完善）

> **说明**：本章节为具体操作手册的预留章节，将在方案评审通过后，根据实际部署环境编写详细的操作步骤指南。每份操作手册应包含：前置条件、操作步骤、验证方法、回滚方案、常见问题处理。

### 10.1 MySQL备份与恢复操作手册

*（待完善）*

主要内容规划：

- MySQL增量备份操作步骤（Percona XtraBackup / mysqldump）
- MySQL增量备份数据恢复步骤（Binlog回放）
- MySQL全量备份操作步骤
- MySQL全量备份数据恢复步骤
- MySQL备份文件加密/解密操作
- MySQL数据一致性校验操作
- 常见故障排查指南

### 10.2 InfluxDB备份与恢复操作手册

*（待完善）*

主要内容规划：

- InfluxDB按时间范围导出操作步骤
- InfluxDB数据导入恢复步骤
- InfluxDB全量备份操作步骤
- InfluxDB全量备份恢复步骤
- InfluxDB备份文件加密/解密操作
- InfluxDB数据一致性校验操作
- 常见故障排查指南

### 10.3 MinIO备份与恢复操作手册

*（待完善）*

主要内容规划：

- MinIO增量同步操作步骤（mc mirror）
- MinIO Bucket Replication配置步骤（可选方案）
- MinIO全量同步操作步骤
- MinIO TLS证书配置步骤
- MinIO对象文件加密/解密操作
- MinIO数据一致性校验操作
- MinIO生命周期管理配置
- 常见故障排查指南

### 10.4 Doris备份与恢复操作手册

*（待完善）*

主要内容规划：

- Doris Repository创建与配置步骤
- Doris Snapshot备份操作步骤（BACKUP命令）
- Doris Snapshot恢复操作步骤（RESTORE命令）
- Doris CCR Syncer部署与配置步骤
- Doris CCR跨集群复制链路建立步骤
- Doris Binlog参数配置步骤
- Doris数据一致性校验操作
- 常见故障排查指南

### 10.5 灾备切换操作手册

*（待完善）*

主要内容规划：

- 灾备切换前检查清单
- 飞服平台灾备切换详细操作步骤
- 监管平台灾备切换详细操作步骤
- DNS域名解析修改操作步骤
- 业务功能验证检查清单
- 切换后数据丢失评估操作步骤
- 灾备切换通知模板

### 10.6 灾备回切操作手册

*（待完善）*

主要内容规划：

- 原主中心故障恢复确认流程
- 数据回同步操作步骤（灾备中心 → 主中心）
- 回切前数据一致性校验步骤
- DNS域名解析回切操作步骤
- 业务功能验证检查清单
- 回切后增量备份恢复正常调度确认

---

## 附录A 备份任务Cron表达式汇总

### A.1 飞服平台

| 任务名称 | Cron表达式 | 执行说明 |
|---------|-----------|---------|
| MySQL增量备份 | `0 */2 * * *` | 每2小时整点（00:00, 02:00, 04:00 ...） |
| InfluxDB增量备份 | `10 */2 * * *` | 每2小时的第10分钟（00:10, 02:10, 04:10 ...） |
| MinIO增量同步 | `20 */2 * * *` | 每2小时的第20分钟（00:20, 02:20, 04:20 ...） |
| 全量备份（全部组件） | `0 2 * * 0` | 每周日凌晨02:00 |

### A.2 监管平台

| 任务名称 | Cron表达式 | 执行说明 |
|---------|-----------|---------|
| MySQL增量备份 | `0 */2 * * *` | 每2小时整点（00:00, 02:00, 04:00 ...） |
| Doris增量备份 | `10 */2 * * *` | 每2小时的第10分钟（00:10, 02:10, 04:10 ...） |
| MinIO增量同步 | `20 */2 * * *` | 每2小时的第20分钟（00:20, 02:20, 04:20 ...） |
| 全量备份（全部组件） | `0 2 * * 0` | 每周日凌晨02:00 |

---

## 附录B 灾备切换检查清单

### B.1 切换前检查

| 序号 | 检查项 | 检查内容 | 检查结果 | 检查人 |
|------|--------|---------|---------|--------|
| 1 | 故障确认 | 确认主中心故障性质和预计恢复时间 | □ 通过 □ 不通过 | |
| 2 | 灾备中心K8s集群 | 确认K8s集群各节点运行正常 | □ 通过 □ 不通过 | |
| 3 | 灾备中心MySQL | 确认MySQL实例运行正常且最新备份已导入 | □ 通过 □ 不通过 | |
| 4 | 灾备中心InfluxDB/Doris | 确认InfluxDB/Doris实例运行正常且最新备份已导入 | □ 通过 □ 不通过 | |
| 5 | 灾备中心MinIO | 确认MinIO实例运行正常且最新备份已同步 | □ 通过 □ 不通过 | |
| 6 | 灾备中心EMQX | 确认EMQX实例运行正常，可接收设备连接 | □ 通过 □ 不通过 | |
| 7 | 灾备中心微服务 | 确认全部微服务Pod运行正常 | □ 通过 □ 不通过 | |
| 8 | DNS管理权限 | 确认域名管理操作权限就绪 | □ 通过 □ 不通过 | |

### B.2 切换后验证

| 序号 | 验证项 | 验证内容 | 验证结果 | 验证人 |
|------|--------|---------|---------|--------|
| 1 | DNS解析 | 确认域名已解析至灾备中心IP | □ 通过 □ 不通过 | |
| 2 | 平台登录 | 确认用户可正常登录平台 | □ 通过 □ 不通过 | |
| 3 | 核心业务功能 | 确认核心业务功能操作正常 | □ 通过 □ 不通过 | |
| 4 | 设备连接 | 确认外部设备可正常连接EMQX | □ 通过 □ 不通过 | |
| 5 | 数据查询 | 确认历史数据可正常查询 | □ 通过 □ 不通过 | |
| 6 | 数据丢失评估 | 确认数据丢失时间窗口 ≤ 2小时 | □ 通过 □ 不通过 | |

---

*文档结束*