商家说恢复成功了，可我的站还是起不来：备份验收该你自己定

论坛里这两天有个很典型的争执：有人第一次用商家自带的备份恢复，机器起来了、能 SSH 登录，但服务全是坏的。商家说备份和恢复都成功了——能开机、能登录就是成功；用户说这不是我要的那台机器。两边都没撒谎，问题出在「恢复成功」这四个字由谁定义。

先把两种备份分开

商家快照、整机镜像这一层，粒度是整盘，恢复快，但它能不能用完全取决于对方的平台：换节点、换虚拟化类型、镜像版本对不上，都可能落在一个「能启动但服务不全」的状态。它保的是机器，不是你的业务。

你自己做的文件级、逻辑级备份（restic、borg、pg_dump、mysqldump）粒度是你定义的，能恢复到任何一台机器上，代价是得自己写清楚到底要备什么。

所以结论只有一句：商家的那份当「机器能回来」的保险，自己的那份当「数据还在」的保险，两份都要，而验收标准只写你自己那份。

验收要做成动作，不是感觉

用 restic 的话，命令是现成的：

1. 查仓库：restic -r <仓库> check。注意它默认只校验结构和索引，不读真实数据；真要确认字节没坏，加 --read-data，代价是把所有 pack 文件拉一遍，时间和带宽都上去了。仓库大就分批，--read-data-subset=1/5（分五次覆盖全量）或 --read-data-subset=10% 抽样都行。check 报错必须先 restic repair index 修好，带着坏仓库继续备份，新快照也没人保证能恢复。
2. 先预演再动手：restic -r <仓库> restore latest --target /tmp/restore --dry-run --verbose=2，先看清会落哪些文件、哪些会被覆盖。
3. 恢复到临时目录，别直接盖生产目录。可以用 --include 只取单个文件，用 --host、--path 挑快照。要原地覆盖时记住文档里的警告：原地恢复被中断会留下「恢复了一半」的状态，动手前先给当前状态留一份；--delete 会把快照里没有的文件删掉，务必先 --dry-run -vv。
4. 数据库别只看文件在不在：restic dump <snapshot> production.sql | mysql 直接灌回一个临时库跑一遍查询，比 ls 一眼强得多；要打包就 dump ... > restore.tar。
5. 定频率：每月一次抽样 check，每季度一次真恢复并把服务跑起来。只「跑过 backup」不算数，「恢复出来能对外服务」才算数。

谁最该做这件事

手上有两台以上 VPS、或者存了付费用户数据的小团队。反过来，纯静态站、代码全在 Git 里、数据库能重建的，投入可以压到最低，把精力放在异地那一份够不够远上。

风险清单

--read-data 会下载整仓，按流量计费的备份目标别天天跑；仓库密钥丢了谁也救不回来，密码进密码管理器是第一步；演练请开一台临时机器，别拿生产机练手。仓库要搬家或再复制一份异地，用 restic copy，但要注意它会整份下载再上传，带宽比平时高不少。

命令的权威写法都在 restic 官方文档 里，照着抄比凭记忆敲安全。