recurring job 未触发 S3 备份，因 Longhorn 的 recurring job 仅调用 backup 操作，实际上传依赖 BackupTarget 配置、有效凭证、volume 已 attached、S3 权限与 region 匹配，且 backup index 需等待 5 分钟扫描同步。
recurring job 为什么没触发 backup 到 S3？
Longhorn 的 recurring job 本身不直接上传备份，它只负责调用 backup 或 snapshot 操作；真正传到 S3 是靠 volume 的 backup target 配置和 backup store 的可用性驱动的。
- 必须在 Longhorn UI 的 Settings → Backup Settings 中正确填写
BackupTarget（如s3://longhorn-backup@cn-north-1/）且BackupTargetCredentialSecret存在并有效 -
recurring job类型选backup，不是snapshot——后者只存本地，不会走 S3 - volume 必须处于
attached状态（即被 workload 使用中或已手动 attach），detached volume 的 backup 会被跳过 - 检查 longhorn-manager 日志：
kubectl logs -n longhorn-system $(kubectl get pod -n longhorn-system -l app=longhorn-manager -o jsonpath='{.items[0].metadata.name}') | grep -i "backup\|s3"，常见错误如Failed to list backups in s3或InvalidAccessKeyId
backup 失败时 S3 目录里只有 .lock 文件
这是典型的 backup 过程中断后残留的锁文件，说明 backup worker 启动了但没完成写入。S3 上出现 .lock 而无对应 .json 和 .img，基本等于这次 backup 已失败，不能手动清理后“续传”。
- 先确认 S3 bucket 权限：Longhorn 需要
s3:GetObject、s3:PutObject、s3:ListBucket、s3:DeleteObject—— 少一个都可能卡在 lock 阶段 - 检查 backup target URL 中 region 是否匹配实际 bucket 所在区域，例如
@us-east-1写成@us-west-2会导致签名失败，日志里常出现AuthorizationHeaderMalformed - 网络超时也容易导致 lock 残留：Longhorn 默认 backup 超时是 2 小时，大 volume（>100Gi）在慢网或高延迟 S3 endpoint 下建议调大
BackupTimeoutHour设置 - 手动删
.lock文件没用，得进 Longhorn UI 对该 volume 点击Remove all backups（会同步清理 S3 中已成功上传的部分），再重试 recurring job
多个 recurring job 共享同一个 backup target 会冲突吗？
不会自动冲突，但存在隐式竞争：所有 backup 操作共享同一套 S3 client 和 credential，底层共用同一个 BackupTarget 配置，所以不是“隔离的”。问题出在并发控制和命名上。
- Longhorn 不限制并发 backup，如果两个 recurring job 在相近时间触发，可能同时往同一个 S3 prefix 写文件，虽有对象级锁，但易触发 S3 429 Too Many Requests（尤其用 MinIO 或某些国产 S3 兼容层）
- backup 名称由 Longhorn 自动生成（形如
backup-bcdef123-4567-89ab-cdef-1234567890ab），不支持自定义前缀，因此无法靠路径隔离不同 job 的输出 - 更稳妥的做法是：为不同业务 volume 分配不同 backup target URL（比如用子目录区分：
s3://backups@region/prod-db/vss3://backups@region/staging-app/），靠 S3 路径实现逻辑隔离 - 避免把 backup 和 snapshot recurring job 绑定到同一个 volume —— backup 依赖 snapshot，如果 snapshot job 频率太高，可能因 snapshot chain 过长拖慢 backup 创建
backup 到 S3 后，restore 时提示 “backup doesn’t exist”
这不是 restore 命令的问题，而是 backup index 没同步到 local cache，Longhorn manager 每 5 分钟主动 scan 一次 S3 获取 backup 列表；如果刚 backup 完就立刻 restore，大概率查不到。
- 等 5–10 分钟再试，或手动触发 scan：
kubectl -n longhorn-system exec deploy/longhorn-manager -- longhorn backup ls --volume test-vol - 确认 backup target 的 endpoint 可访问：从 longhorn-manager pod 内 curl 测试，比如
curl -v https://s3.cn-north-1.amazonaws.com.cn/longhorn-backup/?prefix=test-vol，注意 S3 兼容服务可能需要关闭 TLS 验证或指定 CA - restore 时必须指定完整 backup ID（不是名字），ID 在 backup detail 页面或
longhorn backup ls输出里第一列，格式类似backup-abcdef12-3456-7890-abcd-ef1234567890 - 如果用了跨 region 的 S3（比如 backup 存 us-east-1，restore 从 cn-north-1 的集群发起），需确保 backup target URL 中 region 正确，否则 scan 会连错 endpoint
事情说清了就结束。最常卡住的地方其实是 backup target 的 region 和 credential scope 匹配问题，而不是 job 配置本身。
