需要备份一张表，却选择基础备份，恢复时会发现只能按整个实例处理；需要构建备用节点，却只做单库逻辑导出，又缺少物理起点。工具没有好坏，关键是恢复目标是否匹配。
KES 官方说明，sys_basebackup 从运行中的数据库实例获取基础备份，结果是整个数据库集簇的二进制副本，可用于时间点恢复，也可作为日志传送或流复制备用服务器的起点。它不能只备一个数据库或对象，单库需求应使用 sys_dump。
--- 先确定要恢复整实例、做时间点恢复还是只取单库。
使用前有一组硬条件
备份通过常规连接和复制协议完成，连接角色需要相应权限，sys_hba.conf 要显式允许复制连接，服务器还要有足够的日志发送能力。不要等任务运行时才发现认证规则未放行。
基础命令结构如下：
powershell
sys_basebackup -h <host> -p <port> -U <user> -D D:\backup\base_20260807 -P-D 指定目标目录。官方说明目录可以被创建，但若已存在且非空会报错。生产脚本应为每次备份生成独立明确目录，执行前验证路径不与数据目录重叠，避免覆盖或把备份写回源盘。
格式和表空间要一起设计
普通格式保留数据目录与表空间布局，额外表空间可能仍指向原绝对路径；同机备份若不做映射，容易与正在使用的路径冲突。tar 格式的解压与表空间还原也有明确要求。选择格式前先列出所有表空间和目标恢复目录。
备份目录放在源数据库同一块磁盘，只能防部分逻辑问题，无法抵御整盘故障。至少复制到独立故障域，并校验复制后的文件完整性。
日志决定它能恢复到哪里
基础备份只是时间点恢复的起点，后续还需要连续可用的日志。官方文档对日志流、复制槽和备份期间日志保留给出多项说明。若所需日志被提前清理，文件再完整也无法恢复到目标时间。
任务监控要同时看基础文件和日志接收，不能只看进度条。-P 输出是近似进度，数据库在备份期间仍可能变化，进度不在正好百分之百结束不应单独判为失败，最终以退出状态、日志和完整性检查为准。
--- 整实例、目录、复制权限、日志和表空间必须一次规划。
从备库备份也有条件
官方说明可以从备库创建基础备份，但需要备库接受复制连接，主库启用必要的全页写，并注意备份期间提升、日志归档和特定表类型等限制。不能简单认为"从备库跑就一定不影响主库且完全等价"。
选择备份节点时评估网络、磁盘、复制延迟和故障切换。备份期间若节点角色变化，任务可能失败，应有告警与重新调度，而不是静默拿残留目录当成功结果。
验收必须启动隔离实例
定期把基础备份恢复到隔离路径，正确处理表空间和日志，启动实例并检查恢复点、数据库列表、关键对象与业务数据。若目标是构建备用节点，还要验证复制能够从备份结束位置继续。
记录恢复所需时间和峰值空间，和业务 RTO 比较。备份能完成但恢复耗时超标，仍然需要调整策略。
sys_basebackup 适合整实例物理起点，不是单库导出工具。恢复目标、日志链和目录布局都匹配时，它才真正发挥作用。
自动化任务需要防止并发执行。官方说明同一时间可运行多个基础备份，但从性能角度最好只做一个再复制结果。调度脚本应使用任务锁或状态检查，发现上一任务仍在运行时告警，不要在慢任务上继续叠加新任务。
限速、压缩和检查点方式都会改变备份时长与资源占用。参数调整前记录基线，在接近真实负载下比较 CPU、磁盘、网络和业务响应。追求更快备份若造成线上延迟，仍然不是合格方案。
失败后残留目录要按明确路径核对再处理。不要用宽泛递归删除清理"上次备份"，先确认目录属于失败任务、没有被其他恢复使用，并保留必要诊断日志。