备份恢复验证

备份顺利完成，不等于备份真的能恢复。唯一的实证就是把它恢复一遍。Databasus 会按计划替你完成这件事：

取最新的备份
把它恢复到一次性数据库容器中
对照源库检查恢复出的数据库
销毁容器
报告结果

什么是验证代理？

验证代理是一个小巧的 Go 二进制程序，运行在你自己掌控的机器上，只要有空闲的 CPU、内存和磁盘就行。代理向 Databasus 注册后，从队列领取验证任务，在本地执行并把结果回报。

你需要什么

一台能通过 HTTPS 出站访问你 Databasus 地址的主机。
主机上装有 Docker：代理会为每个任务启动与源库主版本一致的临时数据库容器。
每个验证任务所需的磁盘容量，包括备份文件大小、数据库原始大小，再加上一段安全余量。
每个并发任务至少 1 个 CPU 核心和 512 MB 可用内存。

为什么校验和不够？

校验和与退出码能发现一部分故障，但对另一些完全无能为力：

校验和能发现归档文件的位衰减，但完全说明不了转储本身是否完整、语义是否有效。
转储退出码只说明转储命令跑完了。它发现不了角色对某些对象缺少读权限、源库缺扩展或表空间不匹配这类问题，而这些都会导致对象被悄悄跳过或丢失。
恢复验证则真的把归档交给数据库自带的恢复工具执行，并逐表统计行数。它是唯一能抓住上述全部问题的检查：如果一个备份恢复不了，你会在需要它之前发现，而不是在灾难发生时。

配置

在界面中创建代理

打开 Settings → Verification agents，点击 Create verification agent。取一个能说明用途的名字，比如 staging-verifier 或 eu-west-host-1。接下来的对话框会显示代理的令牌和 ID。

令牌只显示一次，关闭对话框前务必复制。之后如果丢失，在代理所在行使用 Rotate token 操作签发新令牌；旧令牌会在代理下一次心跳时失效。随后的对话框会按你服务器的架构显示安装命令，与下文描述的命令相同。

在服务器上启动代理

SSH 登录将要运行验证的机器。先下载代理二进制文件。把 https://your-databasus-host 换成你自己的 Databasus 地址；如果服务器是 ARM 架构，把 amd64 换成 arm64：

curl -L -o verification-agent "https://your-databasus-host/api/v1/system/verification-agent?arch=amd64" \
  && chmod +x verification-agent

然后启动代理。代理 ID 和令牌来自上一步的对话框：

./verification-agent start \
  --databasus-host=https://your-databasus-host \
  --agent-id=<AGENT_ID> \
  --token=<TOKEN> \
  --max-cpu=2 \
  --max-ram-mb=2048 \
  --max-disk-gb=20 \
  --max-concurrent-jobs=1

start 会让代理以守护进程运行，并把启动参数写入工作目录下的 databasus-verification.json，之后重启只需执行 ./verification-agent start，无需任何参数。日志写入二进制文件旁边的 databasus-verification.log。

Databasus 地址必须是 https://。只有加上 --allow-insecure-http 才允许纯 HTTP，而它仅用于本地测试：绝不要让生产环境的代理走未加密的 HTTP。

四个 --max-* 参数是总预算，不是单个任务的配额。代理在每次心跳时把它们上报给 Databasus，Databasus 再把预算分给你允许的并发任务。使用 --max-cpu=2 --max-ram-mb=2048 --max-concurrent-jobs=1 时，唯一的任务独占 2 个 CPU 和 2 GB 内存；改为 --max-concurrent-jobs=2 后，每个任务分到 1 个 CPU 和 1 GB。每个任务的下限是 1 个 CPU 和 512 MB：如果预算满足不了下限，代理会上报更低的并发数。磁盘预算最容易设错：每个任务需要容纳备份文件大小、数据库原始大小，外加最多 5 GB 的安全余量，所以请按你最大的数据库把 --max-disk-gb 设得宽裕一些。

管理代理

同一个二进制文件提供四个子命令：

./verification-agent status — 显示守护进程是否在运行以及当前正在处理哪些任务。
./verification-agent stop — 停止守护进程。执行中的验证会以失败状态回报给 Databasus，并重新排队。
./verification-agent start — 重新启动守护进程。参数沿用首次启动时的记录；令牌轮换后传入 --token=<NEW> 更新保存的令牌。
./verification-agent run — 在前台运行而不是守护进程。把代理放进 systemd 单元或 Docker 容器时用这个：这些管理器要求进程不要自行 fork。

Settings 页面在每个代理所在行提供三个图标操作：再次查看安装命令（不会显示令牌）、轮换令牌、删除代理。删除是安全的：当前分配给该代理的验证会退回队列，如果有其他可用代理，会被它们接手。

计划与通知

恢复验证按数据库单独配置。打开数据库的验证设置，启用 Scheduled verification，然后选择周期。

周期选项

After backup — 最强的保障：每个成功的备份一完成就立即验证。
Hourly、daily、weekly、monthly — 选择频率和一天中的时间。
Cron — 用 UTC cron 表达式覆盖预设之外的任何需求。例如：0 4 * * 0 （每周日 4:00 AM UTC）和 0 */6 * * * （每 6 小时一次）。

队列如何处理 "After backup"

验证通常比产生它的备份更慢，如果备份到来的速度超过验证完成的速度，队列会无限增长。Databasus 的解决办法是：每当同一数据库有新备份到达，就取消它所有待处理的验证，队列里只留最新的备份。这个取舍是有意为之：与其花几个小时验证一个反正不会用来恢复的过时备份，不如跳过它。

手动运行

你也可以在数据库的 Restore verifications 标签页发起一次性验证，无需改动计划。适合抽查某个特定备份，或者在把定时任务交给新代理之前先端到端地试运行一次。

通知

成功和失败都可以通过数据库已接入的任意通知渠道发送。两个复选框 — Verification success 和 Verification failed — 彼此独立。多数团队只开失败通知，避免通知疲劳。接入 Slack、Microsoft Teams、Discord、邮件等渠道请参阅通知渠道文档。

解读结果

每次验证尝试都会在数据库的 Restore verifications 标签页显示为一行。状态是 Pending、Running、Successful、Failed 或 Canceled 之一。点击某一行会打开抽屉面板，显示完整时间线、恢复退出码、恢复出的数据库大小、模式与表的数量，以及逐表的行数明细。失败的运行会在抽屉顶部显示失败信息。