kingbase备份与恢复实战（六）—— 备份自动化与保留策略：Windows任务计划+日志追溯

处理kingbase备份与恢复实战（六）—— 备份自动化与保留策略：Windows任务计划+日志追溯这类问题时，先确认目标场景，再按步骤核对配置或玩法细节。

引言

许多团队无法达成备份，问题并不出在 sys_dump 自身，而是因为“流程未落实”，常见的状况你很可能已经目睹过。

1. 备份全靠手工，忙的时候忘了

2. 备份做了，但没人知道有没有成功

3. 备份文件越堆越多，占满磁盘

4. 真出事了才发现：最近一次可用备份是半年前

所以从运维视角看，备份要真正可用，至少得把下面 4 件事补齐：

1. 定时执行（自动化）

2. 成功/失败可感知（日志 + 返回码）

3. 保留策略（留存周期 + 清理）

4. 恢复演练（验证备份可用）

在 Windows 环境当中，利用前面几篇所掌握的命令，把一套“可追溯”的自动备份方案落实下来，也就是依靠 Windows 任务计划，统一目录，统一命名，日志留存以及保留策略，这样做，起码能够先稳固住“每天有人管理，出了事情可以查询，磁盘不会爆炸”这两件事。

@[toc]

一、统一目录与命名（自动化的前提）

先把目录和命名统一起来，后面自动化才好做、也好排障。建议沿用本系列的统一路径：

1. D:KB_LABbackuplogical：逻辑备份输出目录
2. D:KB_LABlogs：备份脚本日志目录

创建目录：

New-Item -ItemType Directory -Force -Path D:KB_LABbackuplogical | Out-NullNew-Item -ItemType Directory -Force -Path D:KB_LABlogs | Out-Null

命名建议最好写得“能直接复制

1. 备份文件：YYYYMMDD_HHMM_backup_lab_full.dump
2. 日志文件：YYYYMMDD_HHMM_backup_lab_full.log

二、自动化落地前的“前置条件”（避免任务跑了但实际没备份）

在 Windows 上做数据库备份自动化，最容易被忽略的真不是命令怎么写，而是“谁在跑、有没有权限”

2.1 任务计划运行账户需要具备什么权限？

至少要满足：

1. Windows 权限：对 D:KB_LABbackuplogical 与 D:KB_LABlogs 具备读写权限
2. 数据库权限：能连接目标库，并具备导出所需权限（演示用建议管理员账号）
3. 工具权限：能访问 sys_dump.exe（要么配置 PATH，要么使用绝对路径）

2.2 强烈建议：备份命令使用“绝对路径”

别赌任务计划里的环境变量会不会和你手工打开的 cmd 一样。最稳妥的做法就是：

1. 任务计划里直接调用 D:ToolsKingbaseESServerbinsys_dump.exe
2. 日志与备份输出写绝对路径

这样就算机器重启、换人维护，任务也更容易持续跑通。

二、备份策略建议（先讲清“怎么做才合理”）

这套系列以“单机/中小规模”场景的常见诉求，给你一个可落地的基线策略：

1. 每天 1 次全库逻辑备份（custom 格式，便于精准恢复）

2. 保留 7~14 天（按磁盘与合规要求调整）

3. 每周至少做一次“恢复验收”（可以恢复到新库做校验）

如果你同时做了物理冷备（上一篇），可以扩展为：

1. 每周 1 次物理冷备（停机窗口内执行）

2. 每天 1 次逻辑备份（不停机）

三、案例脚本清单

建议准备 3 个脚本文件（命名你按团队规范调整就行）：

kb_backup_logical_full.bat - 作用：执行 sys_dump 全库备份（custom 格式）。

1. 关键命令：sys_dump -F c -f <dump_file> backup_lab

2. 关键要求：输出返回码、把标准输出/错误输出写入日志文件

kb_backup_retention.ps1

1. 用途：清理超出保留期的备份文件与日志

关键命令为：按照 LastWriteTime 删除超出 N 天的 *.dump / *.log 文件。

kb_backup_verify.sql 用于恢复之后的验收，其中包含对象，行数以及关键聚合信息。

1. 关键语句：dt、COUNT(*)、关键表聚合校验

四、自动化执行：Windows 任务计划（详细步骤 + 可复用参数）

4.1 打开任务计划程序

1）打开【控制面板】，搜索 “计划任务”，点击

2）选择【创建任务】（不要选“创建基本任务”，可配置项更少）

4.2 常规（General）设置

1. 名称：KingbaseES_LogicalBackup_Daily
2. 安全选项：
   1. 选择一个有权限执行备份的 Windows 账户
   2. 勾选【不管用户是否登录都要运行】（推荐）
   3. 勾选【使用最高权限运行】（避免权限导致备份失败）

4.2.1 额外建议：把“用户名/端口/库名/目录”参数化

为了让文章更贴近生产，文章里明确一组“统一变量”：

1. 实例工具目录：D:ToolsKingbaseESServerbin
2. 备份输出目录：D:KB_LABbackuplogical
3. 日志目录：D:KB_LABlogs
4. 连接参数：-h 127.0.0.1 -p 54321 -U system
5. 目标库：backup_lab

4.3 触发器（Triggers）

1. 新建触发器
2. 开始任务：按计划
3. 设置：每天
4. 时间：例如 01:00

4.4 操作（Actions）：配置执行命令

你有两种常见选择：

选择 A：直接运行批处理（推荐写法）

1. 程序/脚本：cmd.exe
2. 添加参数：/c D:KB_LABscriptskb_backup_logical_full.bat
3. 起始于：D:ToolsKingbaseESServerbin（可选，但建议指定）

起始于为什么重要

1. 任务计划有时不会加载你手工终端的 PATH
2. 指定“起始于”能减少相对路径导致的失败

选择 B：直接运行 sys_dump（一条命令）

如果你希望不依赖脚本文件，也可以直接在“添加参数”里写完整命令（但不利于维护）。

示例逻辑（用 custom 格式输出）：

D:ToolsKingbaseESServerbinsys_dump.exe -h 127.0.0.1 -p 54321 -U system -F c -E UTF8 -f D:KB_LABbackuplogical20260207_0100_backup_lab_full.dump backup_lab

4.4.1 让任务“可追溯”：必须把输出重定向到日志

只要你做过一次生产事故复盘就会明白：没有日志，自动化就很难交付——出了问题没证据、也不好定位。

推荐你在任务计划里把参数写成“带日志”的形式（示例）：

/c D:ToolsKingbaseESServerbinsys_dump.exe -h 127.0.0.1 -p 54321 -U system -F c -E UTF8 -f D:KB_LABbackuplogical20260207_0100_backup_lab_full.dump backup_lab 1>> D:KB_LABlogs20260207_0100_backup_lab_full.log 2>>&1

这样每次执行都会把标准输出和错误输出都写进日志里，哪怕失败了，也能顺着日志把原因找出来。

4.5 条件（Conditions）与设置（Settings）

建议配置（偏运维实践）：

1. 条件：
   1. 如是服务器环境：可勾选“只有在计算机使用交流电源时才启动任务”（按实际）
2. 设置：
   1. 允许按需运行任务
   2. 如果任务失败，按间隔重试 1~3 次
   3. 如果任务运行时间超过阈值（例如 2 小时）则停止任务（避免卡死）

4.6 手动运行一次验证

创建完任务后，右键任务【运行】，然后检查：

1. D:KB_LABbackuplogical 是否生成新的备份文件

2. D:KB_LABlogs 是否生成对应日志

3. 任务计划“上次运行结果”是否为成功（0x0）

“验证闭环”，怎么确认“真的备到了、而且可用”：

1. 日志里是否出现明显报错（连接失败、权限不足、磁盘满）

2. 备份文件大小是否合理（不为 0、与历史量级接近）

如果是 custom 归档格式，它能否被 sys_restore -l 正常列出以满足快速可用性验收的要求？

五、保留策略：自动清理旧备份（思路与关键命令）

保留策略其实就回答两个问题：

1. 留多久（N 天）
2. 超出后怎么删（按文件时间/按容量阈值）

5.1 按天数保留（最常用）

思路很简单：

1. 每天备份后，执行一次清理：删除超过 N 天的 *.dump 与 *.log

PowerShell 的关键命令逻辑

$keepDays = 14$deadline = (Get-Date).AddDays(-$keepDays)Get-ChildItem D:KB_LABbackuplogical -Filter *.dump | Where-Object { $_.LastWriteTime -lt $deadline } | Remove-Item -ForceGet-ChildItem D:KB_LABlogs -Filter *.log | Where-Object { $_.LastWriteTime -lt $deadline } | Remove-Item -Force

你可以把它单独做成第二个任务每天跑一次，也可以在备份任务后面追加执行（看你们习惯哪种维护方式）。

5.1.1 建议额外清理：临时文件与异常残留

一些失败的备份可能会留下：

1. 体积很小的 dump 文件
2. 只写了一半的日志

判定思路：

1. 备份文件小于阈值（例如 < 1MB）视为失败残留，纳入清理
2. 或者只清理“超过 N 天”的失败残留，保留近期故障现场用于排查

5.2 额外建议：保留“月度最后一次备份”

如果合规要求更高，建议额外保留：

1. 每月最后一次全量备份，保留 6~12 个月

实现方式很多，这里给个思路就够用：

1. 按月份归档到 D:KB_LABbackuplogicalmonthlyYYYYMM
2. 清理策略对 monthly 目录使用更长留存周期

六、把“可用性验证”制度化（不要只备不验）

自动化备份跑起来以后，最容易被忽略的一件事反而是：这份备份到底可不可靠。

建议每周至少做一次恢复验收（最好恢复到新库，隔离验证更安全）：

1）创建目标库：

DROP DATABASE IF EXISTS backup_lab_verify;CREATE DATABASE backup_lab_verify WITH TEMPLATE = template0 ENCODING ='UTF8';

2）用 sys_restore 恢复（如果你的备份是 custom 格式）：

sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab_verify D:KB_LABbackuplogical<latest>.dump

3）执行验收 SQL（kb_backup_verify.sql）并留存结果（截图/日志）。

七、把“成功/失败”变成可感知（日志之外再加一层）

在运维实践里> 备份失败必须被看见（至少进事件查看器/监控系统），否则自动化等于形式化。

最简做法（不依赖额外组件）：

1. 任务计划配置“失败时重试”

2. 定期人工抽查：看“上次运行结果”与日志末尾

更标准的做法（按你单位监控体系选用）：

1. 把日志采集到集中日志平台

2. 失败关键字触发告警（例如包含 ERROR/FATAL/permission denied）

总结

本文把“备份从手工活变成可交付能力”落到了 Windows 可执行层面：

1. 用任务计划把 sys_dump 固化为每天自动执行

2. 用统一目录与命名让文件可追溯

3. 用日志与任务返回码让成功/失败可感知

4. 用保留策略避免磁盘被备份占满

用按阶段复原验收来确保备份切实可用，这篇文作为系列的结尾部分，我们将此套方案向前推进一步，形成成“演习剧本+事故处理列表+常见故障检查”这样的形式，这样你就能直接执行一次全面的复原演习。