摘要 :本文面向需要为 DolphinDB 生产环境建立数据保护体系的运维与开发人员,系统讲解数据备份、数据恢复、灾备监控三类核心策略。基于 DolphinDB 2.x 环境,给出从全量/增量备份、备份验证、时间点到灾难演练的完整脚本,并配套异地备份与主备复制方案。文章覆盖策略设计、执行验证、恢复演练、监控告警与实战初始化五大模块,帮助读者建立可落地的数据保护闭环。数据备份与灾难恢复是数据库运维的经典原理,本文思路长期适用,具体函数签名请以所使用版本的官方文档为准。
文章目录
-
- [引言:为什么备份恢复是 DolphinDB 生产部署的底线工程](#引言:为什么备份恢复是 DolphinDB 生产部署的底线工程)
- 一、核心概念拆解:数据备份、恢复与数据保护策略分别是什么
-
- [1.1 数据备份是什么:防止数据丢失的第一道防线](#1.1 数据备份是什么:防止数据丢失的第一道防线)
- [1.2 数据恢复是什么:把备份转化为可用数据的过程](#1.2 数据恢复是什么:把备份转化为可用数据的过程)
- [1.3 数据保护策略是什么:备份、恢复与监控的体系化设计](#1.3 数据保护策略是什么:备份、恢复与监控的体系化设计)
- 二、备份策略设计:全量、增量与差异如何选
- 三、备份执行与验证:让备份真正可用
-
- [3.1 全量与增量备份执行](#3.1 全量与增量备份执行)
- [3.2 备份验证与演练](#3.2 备份验证与演练)
- 四、数据恢复:从单表恢复到时间点回滚
-
- [4.1 恢复操作与一致性校验](#4.1 恢复操作与一致性校验)
- 五、灾备架构:异地备份与主备复制
-
- [5.1 异地备份与主备复制](#5.1 异地备份与主备复制)
- 六、备份监控与告警:从被动救火到主动防御
- 七、实战:搭建一套最小可用备份系统
- 八、总结:备份恢复是技术,更是纪律
- 参考资料
引言:为什么备份恢复是 DolphinDB 生产部署的底线工程
时序数据库往往承载着企业的核心资产,无论是金融行情、工业传感还是物联网 telemetry,一旦数据丢失或不可用,业务连续性就会受到严重威胁。DolphinDB 虽然具备高可用与分区存储能力,但任何系统都无法完全避免人为误操作、硬件故障、软件缺陷或勒索软件带来的数据损坏风险。因此,备份恢复不是可选项,而是生产部署必须前置考虑的底线工程。
很多团队在业务初期只关注写入性能和查询优化,把备份当作"等有空再补"的任务。等到真正需要恢复时,才发现备份文件损坏、版本不兼容、或者根本没有覆盖关键分区。设计数据保护策略时,必须先明确两个核心指标:**RPO(恢复点目标)**表示灾难发生后允许丢失的数据量,**RTO(恢复时间目标)**表示业务恢复可用所需的时间。RPO 越短意味着备份越频繁,RTO 越短意味着恢复链路越短、自动化程度越高,两者共同决定了保护成本。
本文不会简单罗列 DolphinDB 的备份命令,而是围绕一条完整链路展开:如何设计备份策略、如何执行并验证备份、如何在不同场景下恢复、如何建立灾备与监控闭环。每个环节都会给出可运行的代码示例、常见的决策误区以及回滚方案。阅读前请确保你有一台可访问 DolphinDB 控制台的环境,并具备管理员权限。
一、核心概念拆解:数据备份、恢复与数据保护策略分别是什么
在动手配置之前,必须先厘清三个核心概念。它们分别回答三个问题:数据如何被复制、如何被还原、如何被体系化管理。只有这三个问题都有明确答案,数据保护才能真正闭环。
1.1 数据备份是什么:防止数据丢失的第一道防线
数据备份是指将数据库中的数据、元数据以及配置信息复制到另一个存储位置,以便在原始数据损坏或丢失时能够重建。备份的核心目标不是"复制一份数据",而是在可接受的时间与成本约束下,保证数据的可恢复性。备份的有效性取决于三个维度:备份频率决定数据丢失窗口(RPO)、恢复速度决定业务中断时长(RTO)、验证频率决定备份是否真正可用。
DolphinDB 的备份对象包括分布式数据库、内存表、分区元数据、用户权限与函数视图等。不同类型的对象对备份方式的要求不同:分布式表通常按分区备份,而配置和权限则需要导出为脚本或配置文件。理解这些差异,是避免"备份了数据却丢了权限"的关键。备份本身并不能防止故障发生,但它能把故障带来的损失控制在可接受范围内。
1.2 数据恢复是什么:把备份转化为可用数据的过程
数据恢复是指将备份数据还原到目标环境,使数据库重新回到可用状态的全过程。恢复不仅仅是执行 restore 命令,还包括恢复前的备份有效性检查、恢复中的版本兼容性确认、恢复后的数据一致性校验以及业务回切验证。一次成功的恢复必须在预定 RTO 内完成,并且恢复后的数据要与预期一致。
在实际场景中,恢复需求通常分为三类:误删表或分区的单点恢复、磁盘损坏后的完整恢复、以及需要回滚到某个历史状态的时间点恢复。不同需求对应不同的备份组合:单点恢复依赖最近的增量或全量备份;完整恢复通常从全量备份加增量链还原;时间点恢复则需要配合日志或 redo 机制。很多团队只关注备份是否成功,却忽略了恢复演练,这正是"有备份却依然无法恢复"的根本原因。
1.3 数据保护策略是什么:备份、恢复与监控的体系化设计
数据保护策略不是单个操作,而是一套涵盖备份计划、存储分级、恢复流程、演练机制与监控告警的体系。好的策略需要在成本、复杂度和保护级别之间取得平衡。例如,全量备份每天一次虽然恢复简单,但存储成本和网络开销巨大;增量备份节省空间,但恢复链长,任何一环损坏都会导致恢复失败。
因此,数据保护策略的设计必须回答五个问题:备份什么、多久备份、存多久、恢复到哪、谁来验证。只有把这五个问题都回答清楚,并定期演练,才能说数据保护真正落地。策略还需要考虑业务变化:当数据量增长、合规要求提高或业务重要性上升时,应及时调整备份频率和保留周期。
#mermaid-svg-Y2vGeW8jNF7A9Mcu{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .error-icon{fill:#552222;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .marker{fill:#333333;stroke:#333333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .marker.cross{stroke:#333333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu p{margin:0;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .cluster-label text{fill:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .cluster-label span{color:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .cluster-label span p{background-color:transparent;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .label text,#mermaid-svg-Y2vGeW8jNF7A9Mcu span{fill:#333;color:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .node rect,#mermaid-svg-Y2vGeW8jNF7A9Mcu .node circle,#mermaid-svg-Y2vGeW8jNF7A9Mcu .node ellipse,#mermaid-svg-Y2vGeW8jNF7A9Mcu .node polygon,#mermaid-svg-Y2vGeW8jNF7A9Mcu .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .rough-node .label text,#mermaid-svg-Y2vGeW8jNF7A9Mcu .node .label text,#mermaid-svg-Y2vGeW8jNF7A9Mcu .image-shape .label,#mermaid-svg-Y2vGeW8jNF7A9Mcu .icon-shape .label{text-anchor:middle;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .rough-node .label,#mermaid-svg-Y2vGeW8jNF7A9Mcu .node .label,#mermaid-svg-Y2vGeW8jNF7A9Mcu .image-shape .label,#mermaid-svg-Y2vGeW8jNF7A9Mcu .icon-shape .label{text-align:center;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .node.clickable{cursor:pointer;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .arrowheadPath{fill:#333333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-Y2vGeW8jNF7A9Mcu .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-Y2vGeW8jNF7A9Mcu .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-Y2vGeW8jNF7A9Mcu .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .cluster text{fill:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .cluster span{color:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-Y2vGeW8jNF7A9Mcu rect.text{fill:none;stroke-width:0;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .icon-shape,#mermaid-svg-Y2vGeW8jNF7A9Mcu .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .icon-shape p,#mermaid-svg-Y2vGeW8jNF7A9Mcu .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .icon-shape .label rect,#mermaid-svg-Y2vGeW8jNF7A9Mcu .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-Y2vGeW8jNF7A9Mcu .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-Y2vGeW8jNF7A9Mcu .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-Y2vGeW8jNF7A9Mcu :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 数据保护体系
数据备份
数据保护策略
数据恢复
灾备监控
全量备份
增量备份
差异备份
单点恢复
完整恢复
时间点恢复
备份状态监控
存储容量告警
恢复演练

二、备份策略设计:全量、增量与差异如何选
备份策略的选择直接影响 RPO、RTO 和存储成本。下表从备份速度、恢复复杂度、存储占用和适用场景四个维度对比三种常见备份类型。
| 备份类型 | 备份速度 | 恢复复杂度 | 存储占用 | 适用场景 |
|---|---|---|---|---|
| 全量备份 | 慢 | 低 | 高 | 数据量不大、恢复窗口要求高的核心系统 |
| 增量备份 | 快 | 高 | 低 | 数据变化频繁、存储预算有限的场景 |
| 差异备份 | 中等 | 中等 | 中等 | 折中方案,减少恢复链长度 |
选择策略时,不能只看单次备份速度。增量备份虽然快,但如果恢复时需要依次应用十几个增量文件,RTO 会显著拉长。因此,生产环境中常见的折中方案是"每周全量 + 每日增量 + 定期差异",或者"每月全量 + 每日差异"。DolphinDB 的分布式表支持分区级备份,这意味着可以只对变化的分区执行增量备份,进一步降低备份窗口。
下表给出不同业务场景下的备份策略建议,供读者参考。
| 业务场景 | 数据变化特点 | 推荐策略 | RPO 目标 | RTO 目标 |
|---|---|---|---|---|
| 金融行情 | 高频写入、不可丢失 | 每日全量 + 小时级增量 | < 1 小时 | < 4 小时 |
| 工业物联网 | 7x24 连续写入 | 每周全量 + 每日增量 | < 24 小时 | < 8 小时 |
| 日志分析 | 可容忍部分丢失 | 每周全量 + 每周差异 | < 7 天 | < 24 小时 |
| 开发测试 | 非关键 | 按需全量 | 无严格目标 | < 48 小时 |
制定策略时还要考虑保留周期。金融行业通常要求保留 3 个月到 1 年,合规性强的行业甚至要求 7 年。保留周期越长,存储成本越高,因此需要结合冷热分级:近期备份放在本地 SSD 或对象存储,历史归档放到磁带或冷存。同时,应定期清理过期备份,避免存储空间无限增长导致新备份失败。
dolphindb
// ========== 备份计划与存储配置 ==========
// 定义企业级备份计划:全量周期、增量周期、保留策略
def backupPlanConfiguration() {
return dict(STRING, ANY, [
"full_backup": dict(STRING, ANY, ["frequency":"weekly", "day":"sunday", "time":"02:00", "retention":30]),
"incremental_backup": dict(STRING, ANY, ["frequency":"daily", "time":"03:00", "retention":7]),
"backup_path": "/data/backup/", "compress": true, "encrypt": true
])
}
// 创建备份计划并注册定时任务
def createBackupPlan(planName, config) {
saveBackupPlan(planName, config)
if (config["frequency"] == "daily") {
scheduleJob(planName, "备份任务", def() { executeBackup(planName) },
config["time"], true, 2024.01.01, 2099.12.31, 'D')
}
print("创建备份计划: " + planName)
}
// 配置备份范围:数据库、表、元数据、配置
def backupScopeConfiguration() {
return [
dict(STRING, ANY, ["type":"database", "name":"dfs://industrial_iot", "tables":["sensor_data", "alarm_data"]]),
dict(STRING, ANY, ["type":"configuration", "items":["users", "permissions", "functions"]]),
dict(STRING, ANY, ["type":"metadata", "items":["schemas", "partitions"]])
]
}
// 配置多级存储:本地热备、远程对象存储、冷归档
def backupStorageConfiguration() {
return dict(STRING, ANY, [
"local": dict(STRING, ANY, ["path":"/data/backup/local/", "max_size":"500GB", "retention_days":30]),
"remote": dict(STRING, ANY, ["type":"s3", "endpoint":"https://oss.aliyuncs.com",
"bucket":"dolphindb-backup", "path":"/backup/", "retention_days":90]),
"archive": dict(STRING, ANY, ["type":"tape", "retention_days":365])
])
}
这段代码的核心是把备份计划、范围和存储策略统一封装成可配置函数。实际落地时,建议把配置外置到 JSON 或 YAML 文件中,避免在脚本里硬编码路径和保留周期。同时,备份计划应与业务低峰期对齐,避免在交易高峰或批处理窗口内触发全量备份,导致 I/O 争用。配置变更也应纳入版本控制,确保每次调整都可追溯、可回滚。
三、备份执行与验证:让备份真正可用
3.1 全量与增量备份执行
DolphinDB 提供了 backup 函数,可以通过参数控制全量或增量模式。全量备份会复制整个数据库或指定表的所有分区;增量备份则只复制自上次备份以来发生变化的分区。执行备份时,建议按时间命名目录,并把开始时间、结束时间、耗时、大小等信息写入备份日志表,便于后续追踪。
为什么增量备份还需要 lastBackupTime 参数?因为 DolphinDB 的增量备份基于分区的时间戳或版本号来判断变化,只有通过上一次备份时间作为锚点,才能确定哪些分区需要复制。如果锚点丢失或错误,增量备份可能会遗漏数据。因此,维护一个准确的"上次备份时间"记录是增量备份可靠性的前提。
dolphindb
// ========== 全量与增量备份执行 ==========
// 执行全量备份,按时间戳创建目录并记录元数据
def executeFullBackup(dbName, backupPath) {
startTime = now()
backupDir = backupPath + "/" + format(startTime, "yyyyMMdd_HHmmss") + "_full"
backup(dbName, backupDir, true)
endTime = now()
duration = endTime - startTime
logBackup("full", dbName, backupDir, startTime, duration, "success")
return dict(STRING, ANY, [
"backup_type": "full", "database": dbName, "backup_path": backupDir,
"start_time": startTime, "duration_ms": duration, "status": "success"
])
}
// 定时全量备份:自动上传远程并清理过期副本
def scheduledFullBackup() {
dbName = "dfs://industrial_iot"
backupPath = "/data/backup/"
result = executeFullBackup(dbName, backupPath)
uploadToRemoteStorage(result["backup_path"])
cleanupExpiredBackups(backupPath, 30)
print("全量备份完成并上传: " + result["backup_path"])
}
// 执行增量备份,基于上次备份时间只复制变化分区
def executeIncrementalBackup(dbName, backupPath, lastBackupTime) {
startTime = now()
backupDir = backupPath + "/" + format(startTime, "yyyyMMdd_HHmmss") + "_incr"
backup(dbName, backupDir, false, lastBackupTime)
endTime = now()
duration = endTime - startTime
logBackup("incremental", dbName, backupDir, startTime, duration, "success")
return dict(STRING, ANY, [
"backup_type": "incremental", "database": dbName, "backup_path": backupDir,
"start_time": startTime, "duration_ms": duration, "last_backup_time": lastBackupTime, "status": "success"
])
}
// 定时增量备份:获取上次时间并执行
def scheduledIncrementalBackup() {
dbName = "dfs://industrial_iot"
backupPath = "/data/backup/"
lastBackupTime = getLastBackupTime(dbName)
result = executeIncrementalBackup(dbName, backupPath, lastBackupTime)
print("增量备份完成: " + result["backup_path"])
}
这段代码展示了全量和增量两种备份模式。全量备份适合作为恢复基线,增量备份则用于捕捉日常变化。需要注意,backup 函数的具体签名在 DolphinDB 不同版本中可能略有差异,使用前请确认官方文档。另外,增量备份链中的任意一环损坏都会导致后续恢复失败,因此定期执行全量备份可以缩短恢复链,降低风险。
3.2 备份验证与演练
备份不验证等于没备份。验证至少应包含三个层面:文件完整性校验、数据可读性校验以及可恢复性校验。最可靠的方式是定期把备份恢复到独立的测试库,对比记录数和表结构是否与原库一致。
dolphindb
// ========== 备份验证、恢复与一致性校验 ==========
def verifyBackup(backupPath) {
integrity = checkBackupIntegrity(backupPath)
return dict(STRING, ANY, [
"backup_path": backupPath, "integrity": integrity,
"readable": checkBackupReadable(backupPath),
"size_mb": getBackupSize(backupPath) / 1024 / 1024,
"valid": integrity and checkBackupReadable(backupPath)
])
}
def executeRecovery(backupPath, targetDbName) {
if (!verifyBackup(backupPath)["valid"]) return dict(STRING, ANY, ["status":"failed", "message":"备份验证失败"])
startTime = now()
restore(backupPath, targetDbName)
endTime = now()
logRecovery(backupPath, targetDbName, startTime, endTime - startTime, "success")
return dict(STRING, ANY, ["status":"success", "backup_path":backupPath, "target_database":targetDbName, "start_time":startTime, "duration_ms":endTime-startTime])
}
def pointInTimeRecovery(targetTime, dbName) {
fullBackup = findFullBackupBefore(targetTime, dbName)
executeRecovery(fullBackup.path, dbName)
for (backup in findIncrementalBackupsBetween(fullBackup.time, targetTime, dbName)) {
applyIncrementalBackup(backup.path, dbName)
}
}
def dataConsistencyCheck(sourceDb, targetDb) {
if (getTables(sourceDb).size() != getTables(targetDb).size()) {
return dict(STRING, ANY, ["consistent":false, "issue":"表数量不一致"])
}
for (table in getTables(sourceDb)) {
if (getTableCount(sourceDb, table) != getTableCount(targetDb, table)) {
return dict(STRING, ANY, ["consistent":false, "issue":"表 " + table + " 记录数不一致"])
}
}
return dict(STRING, ANY, ["consistent":true, "message":"数据一致性检查通过"])
}
def recoveryDrill() {
latestBackup = getLatestBackup()
drillDb = "dfs://drill_recovery"
result = executeRecovery(latestBackup.path, drillDb)
verify = verifyRecovery(drillDb)
dropDatabase(drillDb)
return dict(STRING, ANY, ["drill_time":now(), "backup_used":latestBackup.path, "status":iif(result["status"]=="success" and verify["status"]=="ok", "passed", "failed")])
}
这段代码把验证、恢复、一致性检查和演练整合成一个完整的恢复链路。恢复演练是数据保护中最容易被忽略的环节。很多团队认为只要备份任务执行成功就万事大吉,但备份文件损坏、元数据不一致、版本不兼容等问题只有真正恢复时才会暴露。建议每月至少做一次恢复演练,并把演练结果写入审计表。
#mermaid-svg-u1XXROGy9qwrrWbZ{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-u1XXROGy9qwrrWbZ .error-icon{fill:#552222;}#mermaid-svg-u1XXROGy9qwrrWbZ .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-u1XXROGy9qwrrWbZ .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-u1XXROGy9qwrrWbZ .marker{fill:#333333;stroke:#333333;}#mermaid-svg-u1XXROGy9qwrrWbZ .marker.cross{stroke:#333333;}#mermaid-svg-u1XXROGy9qwrrWbZ svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-u1XXROGy9qwrrWbZ p{margin:0;}#mermaid-svg-u1XXROGy9qwrrWbZ .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ .cluster-label text{fill:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ .cluster-label span{color:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ .cluster-label span p{background-color:transparent;}#mermaid-svg-u1XXROGy9qwrrWbZ .label text,#mermaid-svg-u1XXROGy9qwrrWbZ span{fill:#333;color:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ .node rect,#mermaid-svg-u1XXROGy9qwrrWbZ .node circle,#mermaid-svg-u1XXROGy9qwrrWbZ .node ellipse,#mermaid-svg-u1XXROGy9qwrrWbZ .node polygon,#mermaid-svg-u1XXROGy9qwrrWbZ .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-u1XXROGy9qwrrWbZ .rough-node .label text,#mermaid-svg-u1XXROGy9qwrrWbZ .node .label text,#mermaid-svg-u1XXROGy9qwrrWbZ .image-shape .label,#mermaid-svg-u1XXROGy9qwrrWbZ .icon-shape .label{text-anchor:middle;}#mermaid-svg-u1XXROGy9qwrrWbZ .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-u1XXROGy9qwrrWbZ .rough-node .label,#mermaid-svg-u1XXROGy9qwrrWbZ .node .label,#mermaid-svg-u1XXROGy9qwrrWbZ .image-shape .label,#mermaid-svg-u1XXROGy9qwrrWbZ .icon-shape .label{text-align:center;}#mermaid-svg-u1XXROGy9qwrrWbZ .node.clickable{cursor:pointer;}#mermaid-svg-u1XXROGy9qwrrWbZ .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-u1XXROGy9qwrrWbZ .arrowheadPath{fill:#333333;}#mermaid-svg-u1XXROGy9qwrrWbZ .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-u1XXROGy9qwrrWbZ .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-u1XXROGy9qwrrWbZ .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-u1XXROGy9qwrrWbZ .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-u1XXROGy9qwrrWbZ .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-u1XXROGy9qwrrWbZ .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-u1XXROGy9qwrrWbZ .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-u1XXROGy9qwrrWbZ .cluster text{fill:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ .cluster span{color:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-u1XXROGy9qwrrWbZ .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-u1XXROGy9qwrrWbZ rect.text{fill:none;stroke-width:0;}#mermaid-svg-u1XXROGy9qwrrWbZ .icon-shape,#mermaid-svg-u1XXROGy9qwrrWbZ .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-u1XXROGy9qwrrWbZ .icon-shape p,#mermaid-svg-u1XXROGy9qwrrWbZ .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-u1XXROGy9qwrrWbZ .icon-shape .label rect,#mermaid-svg-u1XXROGy9qwrrWbZ .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-u1XXROGy9qwrrWbZ .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-u1XXROGy9qwrrWbZ .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-u1XXROGy9qwrrWbZ :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 不通过
通过
不一致
一致
制定备份计划
执行全量/增量备份
校验完整性
标记失败并告警
测试恢复到独立库
排查备份链
清理测试环境
归档或上传远程
定期恢复演练

四、数据恢复:从单表恢复到时间点回滚
4.1 恢复操作与一致性校验
恢复前必须先验证备份有效性。如果备份损坏或版本不兼容,盲目恢复可能导致目标库进一步损坏。恢复完成后,应检查数据库状态、表结构、记录数以及关键指标是否与预期一致。对于核心系统,建议先在演练库验证,再在生产环境执行最终恢复。
恢复操作的风险在于它会覆盖目标库的现有数据。因此,执行生产恢复前必须做好权限控制,最好通过工单审批流程触发。dataConsistencyCheck 是恢复后的关键步骤,但它只能检查记录数,不能检查数据内容是否完整。对于关键表,还应抽样对比关键字段的聚合值,例如 sum(volume) 或 count(*),以进一步确认数据质量。
一致性校验 测试库 恢复服务 备份验证 运维人员 一致性校验 测试库 恢复服务 备份验证 运维人员 #mermaid-svg-UrQlTooSL6S2tbXA{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-UrQlTooSL6S2tbXA .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-UrQlTooSL6S2tbXA .error-icon{fill:#552222;}#mermaid-svg-UrQlTooSL6S2tbXA .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-UrQlTooSL6S2tbXA .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-UrQlTooSL6S2tbXA .marker{fill:#333333;stroke:#333333;}#mermaid-svg-UrQlTooSL6S2tbXA .marker.cross{stroke:#333333;}#mermaid-svg-UrQlTooSL6S2tbXA svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-UrQlTooSL6S2tbXA p{margin:0;}#mermaid-svg-UrQlTooSL6S2tbXA .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-UrQlTooSL6S2tbXA text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-UrQlTooSL6S2tbXA .actor-line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-UrQlTooSL6S2tbXA .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-UrQlTooSL6S2tbXA .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-UrQlTooSL6S2tbXA .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-UrQlTooSL6S2tbXA #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-UrQlTooSL6S2tbXA .sequenceNumber{fill:white;}#mermaid-svg-UrQlTooSL6S2tbXA #sequencenumber{fill:#333;}#mermaid-svg-UrQlTooSL6S2tbXA #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-UrQlTooSL6S2tbXA .messageText{fill:#333;stroke:none;}#mermaid-svg-UrQlTooSL6S2tbXA .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-UrQlTooSL6S2tbXA .labelText,#mermaid-svg-UrQlTooSL6S2tbXA .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-UrQlTooSL6S2tbXA .loopText,#mermaid-svg-UrQlTooSL6S2tbXA .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-UrQlTooSL6S2tbXA .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-UrQlTooSL6S2tbXA .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-UrQlTooSL6S2tbXA .noteText,#mermaid-svg-UrQlTooSL6S2tbXA .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-UrQlTooSL6S2tbXA .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-UrQlTooSL6S2tbXA .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-UrQlTooSL6S2tbXA .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-UrQlTooSL6S2tbXA .actorPopupMenu{position:absolute;}#mermaid-svg-UrQlTooSL6S2tbXA .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-UrQlTooSL6S2tbXA .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-UrQlTooSL6S2tbXA .actor-man circle,#mermaid-svg-UrQlTooSL6S2tbXA line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-UrQlTooSL6S2tbXA :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} alt 不一致 一致 alt 验证失败 验证通过 提交恢复请求 校验备份有效性 返回备份不可用 执行恢复 恢复到测试库 表数量/记录数校验 触发排查 允许回切生产
五、灾备架构:异地备份与主备复制
5.1 异地备份与主备复制
本地备份可以应对误操作和单点故障,但无法应对机房级灾难。因此,生产环境必须配置异地备份。DolphinDB 支持将备份文件同步到对象存储(如 S3、OSS)或远程文件系统。同步频率应根据 RPO 目标设定,关键系统可以按小时甚至分钟级同步。
主备复制是另一种灾备手段。与备份不同,复制强调实时或准实时的数据冗余。DolphinDB 的高可用架构支持主备节点之间的数据同步。当主节点故障时,可以切换到备节点继续提供服务。复制模式下需要关注复制延迟、队列堆积以及脑裂风险。
dolphindb
// ========== 灾备与复制监控 ==========
// 配置远程对象存储作为异地备份目标
def remoteBackupConfiguration() {
return dict(STRING, ANY, [
"enabled": true, "type": "s3", "endpoint": "https://oss-cn-shanghai.aliyuncs.com",
"bucket": "dolphindb-dr-backup", "path": "/production/",
"sync_interval": 3600000, "encrypt": true, "compress": true
])
}
// 同步本地备份到远程存储
def syncToRemoteStorage(localPath, remoteConfig) {
uploadBackup(localPath, remoteConfig)
print("同步到远程存储完成: " + localPath)
}
// 从远程存储下载并恢复到本地
def restoreFromRemoteStorage(remotePath, localPath, remoteConfig, targetDb) {
downloadBackup(remotePath, localPath, remoteConfig)
return executeRecovery(localPath, targetDb)
}
// 配置主备复制参数
def masterSlaveReplication() {
return dict(STRING, ANY, [
"mode": "async", "master": "192.168.1.100:8848",
"slave": "192.168.1.101:8848", "sync_interval": 1000, "queue_size": 10000
])
}
// 检查复制延迟与队列状态
def checkReplicationStatus() {
return dict(STRING, ANY, [
"mode": getReplicationMode(), "lag_ms": getReplicationLag(),
"queue_size": getReplicationQueueSize(),
"status": iif(getReplicationLag() < 1000, "normal", "lagging")
])
}
// 灾难评估与恢复策略选择
def disasterRecovery() {
print("启动灾难恢复流程...")
assessment = assessDisaster()
strategy = selectRecoveryStrategy(assessment)
if (strategy == "failover") result = failoverToSlave()
else if (strategy == "restore") {
latestBackup = getLatestBackup()
result = executeRecovery(latestBackup.path, "dfs://industrial_iot")
}
verify = verifyRecovery("dfs://industrial_iot")
if (verify["status"] == "ok") resumeService()
return dict(STRING, ANY, ["assessment":assessment, "strategy":strategy, "result":result, "verification":verify])
}
这段代码覆盖了异地备份同步、主备复制监控以及灾难恢复决策三个核心能力。实际部署时,异步复制虽然性能影响小,但存在秒级到分钟级的延迟窗口,RPO 不为零;同步复制可以保证零数据丢失,但会影响写入延迟。企业应根据业务容忍度选择模式。异地备份和主备复制不是互斥的,通常两者结合使用:复制用于快速切换,备份用于历史回滚和灾难恢复。
| 灾备方案 | RPO | RTO | 成本 | 复杂度 | 适用场景 |
|---|---|---|---|---|---|
| 本地备份 | 天级 | 小时级 | 低 | 低 | 开发测试、非核心系统 |
| 异地备份 | 小时级 | 数小时 | 中 | 中 | 中小型企业核心系统 |
| 主备复制 | 秒级/分钟级 | 分钟级 | 高 | 高 | 金融、高可用生产环境 |
| 双活架构 | 接近零 | 分钟级 | 很高 | 很高 | 强一致性核心业务 |

六、备份监控与告警:从被动救火到主动防御
备份任务失败、存储空间不足、备份超时是最常见的问题。没有监控,这些问题可能要等到恢复时才发现。建议建立三类告警:备份失败告警、备份延迟告警、存储容量告警。
监控实现上,可以通过 backup_log 表记录每次备份的结果,并定时执行健康检查。健康检查应至少包含:最近是否有成功备份、备份文件是否超过保留期、存储空间是否超过阈值。告警阈值应根据业务特点设定,例如关键系统超过 4 小时无成功备份即触发 critical 告警。
监控脚本应与企业的告警通道集成,例如通过 webhook 发送到企业微信、钉钉或邮件系统。同时,备份监控本身也需要高可用:如果监控节点挂掉,就无法发出告警。建议把监控脚本部署在独立节点或外部监控系统中,而不是依赖被监控的数据库节点。告警不是终点,终点是建立自动化修复能力,例如在备份失败后自动重试、在存储不足时自动清理过期文件。
告警分级是监控体系成熟度的体现。建议把备份失败设为 critical 级别,因为这意味着当前保护窗口已经失效;把存储空间超过阈值设为 warning 级别,因为还有一定的缓冲时间;把备份耗时超过历史均值两倍设为 info 或 warning 级别,用于提前发现性能退化。每条告警都应附带上下文信息,例如备份任务名、开始时间、失败原因、剩余存储空间等,避免值班人员收到通知后还要手动查询日志。告警升级策略也很关键:如果 critical 告警在 15 分钟内未被确认,应自动通知更高层级的负责人,确保问题不会被遗漏。
七、实战:搭建一套最小可用备份系统
下面把前面介绍的函数整合成一个可运行的最小可用备份系统初始化脚本。该脚本适用于新集群首次配置或测试环境快速搭建,包含配置计划、注册任务、注册对外接口三个步骤。
dolphindb
// ========== 监控告警与系统初始化 ==========
def initBackupLogTable() {
if (existsTable("dfs://backup", "backup_log")) return
db = database("dfs://backup", VALUE, 2024..2030)
schema = table(1:0, ["id", "type", "database", "path", "time", "duration", "size", "status"],
[INT, STRING, STRING, STRING, TIMESTAMP, LONG, LONG, STRING])
db.createPartitionedTable(schema, "backup_log", "time")
print("备份日志表初始化完成")
}
def initBackupSystem() {
initBackupLogTable()
config = backupPlanConfiguration()
createBackupPlan("daily_incremental", config["incremental_backup"])
createBackupPlan("weekly_full", config["full_backup"])
scheduleJob("backup_monitor", "备份监控", backupHealthCheck, 00:30m, true, 2024.01.01, 2099.12.31, 'D')
print("备份系统初始化完成")
}
def backupStatusMonitor(days = 7) {
recentBackups = getRecentBackups(days)
status = array(ANY, 0)
for (backup in recentBackups) {
status.append!(dict(STRING, ANY, [
"backup_id": backup.id, "type": backup.type, "time": backup.time,
"size_mb": backup.size / 1024 / 1024, "duration_ms": backup.duration, "status": backup.status
]))
}
return status
}
def backupHealthCheck() {
issues = array(STRING, 0, 10)
lastBackup = getLastBackup()
if (isNull(lastBackup)) issues.append!("没有找到备份记录")
else if ((now() - lastBackup.time) / 3600000 > 48) issues.append!("超过48小时没有备份")
if (getBackupStorageUsage() > 90) issues.append!("备份存储空间不足")
return dict(STRING, ANY, ["healthy": issues.size() == 0, "issues": issues])
}
def checkBackupAlerts() {
alerts = array(ANY, 0)
for (backup in select * from backup_log where status = "failed" and time > temporalAdd(now(), -1, "d")) {
alerts.append!(dict(STRING, ANY, ["type": "备份失败", "backup_id": backup.id, "level": "critical"]))
}
if (getBackupStorageUsage() > 90) {
alerts.append!(dict(STRING, ANY, ["type": "存储空间不足", "usage": getBackupStorageUsage(), "level": "warning"]))
}
return alerts
}
这个脚本体现了"先打地基,再搭房子"的思路。initBackupLogTable 保证每次备份都有记录;initBackupSystem 统一配置计划和监控;backupStatusMonitor、backupHealthCheck、checkBackupAlerts 则提供状态视图、健康检查和告警能力。运行后,建议手动触发一次全量备份并执行恢复演练,验证整个链路是否通畅。
如果你的团队已经在使用运维平台或工单系统,可以把这些函数封装成可调用的接口,实现备份的自动化申请与审批。不过要注意,自动化的前提是审批流程不能省略,否则自动化反而会成为误操作或越权操作的加速器。
八、总结:备份恢复是技术,更是纪律
DolphinDB 的数据备份恢复能力覆盖了全量备份、增量备份、时间点恢复、异地备份和主备复制等多个层面,但技术工具只是基础。真正可靠的数据保护需要建立流程纪律:制定明确的 RPO 和 RTO 目标、按策略执行备份、定期验证备份可用性、定期开展恢复演练、建立监控告警并及时响应异常。
数据备份与灾难恢复是数据库运维的经典原理 ,不会因 DolphinDB 版本迭代而失效。不过 DolphinDB 2.x 与 3.x 在部分函数签名、分区机制和存储格式上可能存在差异,迁移版本时应以官方文档为准。替代方案提示:如果团队使用其他时序数据库(如 TimescaleDB、InfluxDB),全量/增量备份、异地复制、主备切换等核心机制的设计思路与本文一致,但具体命令和配置项差异较大。建议迁移或选型前先在测试环境验证完整链路,再推广到生产。
如果你正在规划生产数据保护方案,建议先用非核心库跑通整套流程,再推广到核心生产环境。对于已经上线的系统,不要一次性调整备份策略,而是先建立监控基线,再逐步优化频率和保留周期,确保每一步都可回退。
思考题:
- 在金融行情场景中,如果要求 RPO < 15 分钟、RTO < 2 小时,应如何组合全量、增量和主备复制?
- 增量备份链越长,恢复失败风险越高,如何设计全量备份触发策略来平衡恢复链长度与存储成本?
- 当备份存储成本快速增长时,应如何制定冷热分层与归档策略,同时满足合规保留要求?