原神愿望模拟器大聪明版
62.05M · 2026-04-23
如果说逻辑备份更多是在解决“能不能恢复”,那物理备份更关心的就是另一个问题:恢复能不能快。
在不少生产事故里,真到了拼速度的时候,你会发现最舒服的方式往往不是“导入一堆 SQL”,而是:
这篇文章还是基于 Windows 单机 + ksql,从最通用、最容易上手的一招讲起:停库冷备(拷贝数据目录)。它不依赖复杂组件,照着做也能很快跑通闭环。
@[toc]
冷备(Cold Backup)说白了就是三步:
它的优点很实在:
它的缺点也很明确:
连接到任意库执行:
cd /d D:ToolsKingbaseESServerbin
ksql -U system -d kingbase -h 127.0.0.1 -p 54322
SHOW data_directory;
输出示例(以实际为准):
data_directory
-----------------------------------------
D:/Tools/Kingbase/ES/kes_instance
如果你更习惯用 GUI,这条路也完全没问题:
后面会反复用到两类目录,先把概念记住,后面就不容易绕晕:
D:KB_LABbackupphysical20260207_1200_kes_instance_full冷备看起来简单,但坑也集中。建议原则:
在停库之前,先用 ksql 把实例的关键状态记一笔(演练和复盘时特别省事):
SELECT version();
SHOW data_directory;
SHOW port;
1)Win + R 输入 services.msc 打开服务管理器;
2)找到你的实例服务(名称以实际为准,可能类似 KingbaseES_V9_kes_instance);
3)右键【停止】。
很多冷备失败其实不是拷贝工具的问题,而是“服务点了停止,但进程/端口还在”。稳妥起见,建议做两步确认:
1)确认端口不再(端口以 SHOW port; 为准):
netstat -ano | findstr :54322
2)如果仍有,就回到服务管理器确认状态,必要时看日志再处理。别在实例还在跑的时候强行拷贝数据目录,这样备出来的东西很可能不可用。
部分安装环境会提供 sys_ctl 之类的启停工具(名称以实际为准)。常见形态类似:
sys_ctl stop -D <data_directory>
如果你不确定是否有该工具:
cd /d D:ToolsKingbaseESServerbin
dir *ctl*
New-Item -ItemType Directory -Force -Path D:KB_LABbackupphysical | Out-Null
New-Item -ItemType Directory -Force -Path D:KB_LABbackupphysical20260207_1200_kes_instance_full | Out-Null
假设你的数据目录是:
D:ToolsKingbaseESkes_instance(以你 SHOW data_directory 为准)然后执行拷贝:
robocopy "D:ToolsKingbaseESkes_instance" "D:KB_LABbackupphysical20260207_1200_kes_instance_full" /MIR /R:2 /W:2 /XJ
参数建议
/MIR:镜像目录(目标目录会完全一致)/R:2 /W:2:失败重试 2 次,每次等待 2 秒/XJ:排除目录联接(避免循环)拷贝完别急着结束,至少做 2 件事确认一下:
1)看 robocopy 输出是否有失败项(FAILED)
2)用 PowerShell 统计文件数(简单但有效):
(Get-ChildItem -Recurse -File "D:ToolsKingbaseESkes_instance").Count
(Get-ChildItem -Recurse -File "D:KB_LABbackupphysical20260207_1200_kes_instance_full").Count
可选校验点:
为了模拟“库坏了/数据被误操作”,你可以用两类方式来造事故:
更推荐用逻辑破坏来演练物理恢复,既安全又直观,比如:
DROP TABLE backup_demo.t_order;
确认表已不存在:
dt backup_demo.*
再次停止实例服务。
1)先把“当前数据目录”改名留存(这一步非常关键,避免误操作后无路可退):
例如把:
D:ToolsKingbaseESkes_instance改为:
D:ToolsKingbaseESkes_instance_broken_20260207_12102)把备份目录拷贝回原数据目录路径:
robocopy "D:KB_LABbackupphysical20260207_1200_kes_instance_full" "D:ToolsKingbaseESkes_instance" /MIR /R:2 /W:2 /XJ
这一段属于“真能救命”的习惯:
回到服务管理器,把实例服务启动起来。
用 ksql 连接 backup_lab,检查之前误删的表是否回来了:
ksql -U system -d backup_lab -h 127.0.0.1 -p 54322
dt backup_demo.*
SELECT COUNT(*) AS order_cnt FROM backup_demo.t_order;
如果能看到 t_order,并且行数也对得上,就说明这次物理恢复已经生效。
排查顺序建议,按顺序查,效率最高:
1)看实例日志目录(管控工具/数据目录下通常有日志)
2)检查端口是否冲突(SHOW port; 或服务日志)
3)确认数据目录权限(服务运行账户对目录是否有读写权限)
4)确认你拷贝的是“完整数据目录”,不是只拷了部分子目录
最常见的原因是:
处理办法也很朴素:
建议按下面顺序排查:
1)端口是否与你连接参数一致(SHOW port;)
2)kingbase.conf 里地址配置是否变化
3)Windows 防火墙策略是否拦截(本机演练通常问题不大,远程连接时常见)
部分版本/部署会提供 sys_rman/sys_backup.sh 这类物理备份工具链,用于更体系化的物理备份、归档与恢复。
到这里,Windows 单机环境下“物理备份—恢复—验收”的闭环就讲清楚了:
SHOW data_directory)下一篇会把“恢复点”再往前推进:开启归档并做 PITR 时间点恢复,把数据库恢复到“误操作前一分钟”。