引言
许多团队无法达成备份，问题并不出在 sys_dump 自身，而是因为"流程未落实"，常见的状况你很可能已经目睹过。
-
备份全靠手工，忙的时候忘了
-
备份做了，但没人知道有没有成功
-
备份文件越堆越多，占满磁盘
-
真出事了才发现：最近一次可用备份是半年前
所以从运维视角看，备份要真正可用，至少得把下面 4 件事补齐：
-
定时执行（自动化）
-
成功/失败可感知（日志 + 返回码）
-
保留策略（留存周期 + 清理）
-
恢复演练（验证备份可用）
在 Windows 环境当中，利用前面几篇所掌握的命令，把一套"可追溯"的自动备份方案落实下来，也就是依靠 Windows 任务计划，统一目录，统一命名，日志留存以及保留策略，这样做，起码能够先稳固住"每天有人管理，出了事情可以查询，磁盘不会爆炸"这两件事。
文章目录
- 引言
-
- 一、统一目录与命名（自动化的前提）
- 二、自动化落地前的"前置条件"（避免任务跑了但实际没备份）
-
- [2.1 任务计划运行账户需要具备什么权限？](#2.1 任务计划运行账户需要具备什么权限？)
- [2.2 强烈建议：备份命令使用"绝对路径"](#2.2 强烈建议：备份命令使用“绝对路径”)
- 二、备份策略建议（先讲清"怎么做才合理"）
- 三、案例脚本清单
- [四、自动化执行：Windows 任务计划（详细步骤 + 可复用参数）](#四、自动化执行：Windows 任务计划（详细步骤 + 可复用参数）)
-
- [4.1 打开任务计划程序](#4.1 打开任务计划程序)
- [4.2 常规（General）设置](#4.2 常规（General）设置)
- [4.2.1 额外建议：把"用户名/端口/库名/目录"参数化](#4.2.1 额外建议：把“用户名/端口/库名/目录”参数化)
- [4.3 触发器（Triggers）](#4.3 触发器（Triggers）)
- [4.4 操作（Actions）：配置执行命令](#4.4 操作（Actions）：配置执行命令)
-
- [选择 A：直接运行批处理（推荐写法）](#选择 A：直接运行批处理（推荐写法）)
- [选择 B：直接运行 sys_dump（一条命令）](#选择 B：直接运行 sys_dump（一条命令）)
- [4.4.1 让任务"可追溯"：必须把输出重定向到日志](#4.4.1 让任务“可追溯”：必须把输出重定向到日志)
- [4.5 条件（Conditions）与设置（Settings）](#4.5 条件（Conditions）与设置（Settings）)
- [4.6 手动运行一次验证](#4.6 手动运行一次验证)
- 五、保留策略：自动清理旧备份（思路与关键命令）
-
- [5.1 按天数保留（最常用）](#5.1 按天数保留（最常用）)
- [5.1.1 建议额外清理：临时文件与异常残留](#5.1.1 建议额外清理：临时文件与异常残留)
- [5.2 额外建议：保留"月度最后一次备份"](#5.2 额外建议：保留“月度最后一次备份”)
- 六、把"可用性验证"制度化（不要只备不验）
- 七、把"成功/失败"变成可感知（日志之外再加一层）
- 总结
一、统一目录与命名（自动化的前提）
先把目录和命名统一起来，后面自动化才好做、也好排障。建议沿用本系列的统一路径：
D:\KB_LAB\backup\logical：逻辑备份输出目录D:\KB_LAB\logs：备份脚本日志目录
创建目录：
powershell
New-Item -ItemType Directory -Force -Path D:\KB_LAB\backup\logical | Out-Null
New-Item -ItemType Directory -Force -Path D:\KB_LAB\logs | Out-Null命名建议最好写得"能直接复制
- 备份文件：
YYYYMMDD_HHMM_backup_lab_full.dump - 日志文件：
YYYYMMDD_HHMM_backup_lab_full.log
二、自动化落地前的"前置条件"（避免任务跑了但实际没备份）
在 Windows 上做数据库备份自动化，最容易被忽略的真不是命令怎么写，而是"谁在跑、有没有权限"
2.1 任务计划运行账户需要具备什么权限？
至少要满足：
- Windows 权限：对
D:\KB_LAB\backup\logical与D:\KB_LAB\logs具备读写权限 - 数据库权限：能连接目标库，并具备导出所需权限（演示用建议管理员账号）
- 工具权限：能访问
sys_dump.exe（要么配置 PATH，要么使用绝对路径）
2.2 强烈建议：备份命令使用"绝对路径"
别赌任务计划里的环境变量会不会和你手工打开的 cmd 一样。最稳妥的做法就是：
- 任务计划里直接调用
D:\Tools\Kingbase\ES\Server\bin\sys_dump.exe - 日志与备份输出写绝对路径
这样就算机器重启、换人维护，任务也更容易持续跑通。
二、备份策略建议（先讲清"怎么做才合理"）
这套系列以"单机/中小规模"场景的常见诉求，给你一个可落地的基线策略：
-
每天 1 次全库逻辑备份（custom 格式，便于精准恢复）
-
保留 7~14 天（按磁盘与合规要求调整）
-
每周至少做一次"恢复验收"（可以恢复到新库做校验）
如果你同时做了物理冷备（上一篇），可以扩展为：
-
每周 1 次物理冷备（停机窗口内执行）
-
每天 1 次逻辑备份（不停机）
三、案例脚本清单
建议准备 3 个脚本文件（命名你按团队规范调整就行）：
kb_backup_logical_full.bat - 作用：执行 sys_dump 全库备份（custom 格式）。
-
关键命令：
sys_dump -F c -f <dump_file> backup_lab -
关键要求：输出返回码、把标准输出/错误输出写入日志文件
kb_backup_retention.ps1
- 用途：清理超出保留期的备份文件与日志
关键命令为：按照 LastWriteTime 删除超出 N 天的 *.dump / *.log 文件。
kb_backup_verify.sql 用于恢复之后的验收，其中包含对象，行数以及关键聚合信息。
- 关键语句：
\dt、COUNT(*)、关键表聚合校验
四、自动化执行：Windows 任务计划（详细步骤 + 可复用参数）
4.1 打开任务计划程序
1）打开【控制面板】，搜索 "计划任务"，点击
2）选择【创建任务】（不要选"创建基本任务"，可配置项更少）
4.2 常规（General）设置
- 名称：
KingbaseES_LogicalBackup_Daily - 安全选项：
- 选择一个有权限执行备份的 Windows 账户
- 勾选【不管用户是否登录都要运行】（推荐）
- 勾选【使用最高权限运行】（避免权限导致备份失败）
4.2.1 额外建议：把"用户名/端口/库名/目录"参数化
为了让文章更贴近生产，文章里明确一组"统一变量"：
- 实例工具目录：
D:\Tools\Kingbase\ES\Server\bin - 备份输出目录：
D:\KB_LAB\backup\logical - 日志目录：
D:\KB_LAB\logs - 连接参数：
-h 127.0.0.1 -p 54321 -U system - 目标库：
backup_lab
4.3 触发器（Triggers）
- 新建触发器
- 开始任务：按计划
- 设置：每天
- 时间：例如
01:00
4.4 操作（Actions）：配置执行命令
你有两种常见选择：
选择 A：直接运行批处理（推荐写法）
- 程序/脚本：
cmd.exe - 添加参数：
/c D:\KB_LAB\scripts\kb_backup_logical_full.bat - 起始于：
D:\Tools\Kingbase\ES\Server\bin（可选，但建议指定）
起始于为什么重要
- 任务计划有时不会加载你手工终端的 PATH
- 指定"起始于"能减少相对路径导致的失败
选择 B：直接运行 sys_dump（一条命令）
如果你希望不依赖脚本文件，也可以直接在"添加参数"里写完整命令（但不利于维护）。
示例逻辑（用 custom 格式输出）：
cmd
D:\Tools\Kingbase\ES\Server\bin\sys_dump.exe -h 127.0.0.1 -p 54321 -U system -F c -E UTF8 -f D:\KB_LAB\backup\logical\20260207_0100_backup_lab_full.dump backup_lab4.4.1 让任务"可追溯"：必须把输出重定向到日志
只要你做过一次生产事故复盘就会明白：没有日志，自动化就很难交付------出了问题没证据、也不好定位。
推荐你在任务计划里把参数写成"带日志"的形式（示例）：
cmd
/c D:\Tools\Kingbase\ES\Server\bin\sys_dump.exe -h 127.0.0.1 -p 54321 -U system -F c -E UTF8 -f D:\KB_LAB\backup\logical\20260207_0100_backup_lab_full.dump backup_lab 1>> D:\KB_LAB\logs\20260207_0100_backup_lab_full.log 2>>&1这样每次执行都会把标准输出和错误输出都写进日志里，哪怕失败了，也能顺着日志把原因找出来。
4.5 条件（Conditions）与设置（Settings）
建议配置（偏运维实践）：
- 条件：
- 如是服务器环境：可勾选"只有在计算机使用交流电源时才启动任务"（按实际）
- 设置：
- 允许按需运行任务
- 如果任务失败，按间隔重试 1~3 次
- 如果任务运行时间超过阈值（例如 2 小时）则停止任务（避免卡死）
4.6 手动运行一次验证
创建完任务后，右键任务【运行】，然后检查：
-
D:\KB_LAB\backup\logical是否生成新的备份文件 -
D:\KB_LAB\logs是否生成对应日志 -
任务计划"上次运行结果"是否为成功（0x0）
"验证闭环"，怎么确认"真的备到了、而且可用"：
-
日志里是否出现明显报错（连接失败、权限不足、磁盘满）
-
备份文件大小是否合理（不为 0、与历史量级接近）
如果是 custom 归档格式，它能否被 sys_restore -l 正常列出以满足快速可用性验收的要求？
五、保留策略：自动清理旧备份（思路与关键命令）
保留策略其实就回答两个问题：
- 留多久（N 天）
- 超出后怎么删（按文件时间/按容量阈值）
5.1 按天数保留（最常用）
思路很简单：
- 每天备份后，执行一次清理：删除超过 N 天的
*.dump与*.log
PowerShell 的关键命令逻辑
powershell
$keepDays = 14
$deadline = (Get-Date).AddDays(-$keepDays)
Get-ChildItem D:\KB_LAB\backup\logical -Filter *.dump | Where-Object { $_.LastWriteTime -lt $deadline } | Remove-Item -Force
Get-ChildItem D:\KB_LAB\logs -Filter *.log | Where-Object { $_.LastWriteTime -lt $deadline } | Remove-Item -Force你可以把它单独做成第二个任务每天跑一次，也可以在备份任务后面追加执行（看你们习惯哪种维护方式）。
5.1.1 建议额外清理：临时文件与异常残留
一些失败的备份可能会留下：
- 体积很小的 dump 文件
- 只写了一半的日志
判定思路：
- 备份文件小于阈值（例如 < 1MB）视为失败残留，纳入清理
- 或者只清理"超过 N 天"的失败残留，保留近期故障现场用于排查
5.2 额外建议：保留"月度最后一次备份"
如果合规要求更高，建议额外保留：
- 每月最后一次全量备份，保留 6~12 个月
实现方式很多，这里给个思路就够用：
- 按月份归档到
D:\KB_LAB\backup\logical\monthly\YYYYMM\ - 清理策略对
monthly目录使用更长留存周期
六、把"可用性验证"制度化（不要只备不验）
自动化备份跑起来以后，最容易被忽略的一件事反而是：这份备份到底可不可靠。
建议每周至少做一次恢复验收（最好恢复到新库，隔离验证更安全）：
1）创建目标库：
sql
DROP DATABASE IF EXISTS backup_lab_verify;
CREATE DATABASE backup_lab_verify WITH TEMPLATE = template0 ENCODING = 'UTF8';2）用 sys_restore 恢复（如果你的备份是 custom 格式）：
cmd
sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab_verify D:\KB_LAB\backup\logical\<latest>.dump3）执行验收 SQL（kb_backup_verify.sql）并留存结果（截图/日志）。
七、把"成功/失败"变成可感知（日志之外再加一层）
在运维实践里> 备份失败必须被看见（至少进事件查看器/监控系统），否则自动化等于形式化。
最简做法（不依赖额外组件）：
-
任务计划配置"失败时重试"
-
定期人工抽查：看"上次运行结果"与日志末尾
更标准的做法（按你单位监控体系选用）：
-
把日志采集到集中日志平台
-
失败关键字触发告警（例如包含 ERROR/FATAL/permission denied）
总结
本文把"备份从手工活变成可交付能力"落到了 Windows 可执行层面：
-
用任务计划把
sys_dump固化为每天自动执行 -
用统一目录与命名让文件可追溯
-
用日志与任务返回码让成功/失败可感知
-
用保留策略避免磁盘被备份占满
用按阶段复原验收来确保备份切实可用，这篇文作为系列的结尾部分，我们将此套方案向前推进一步，形成成"演习剧本+事故处理列表+常见故障检查"这样的形式，这样你就能直接执行一次全面的复原演习。