Hetzner VPS：备份做了，但恢复演练还没过

恢复链路没跑通，备份只是文件不是保障

这次遇到的问题不是备份丢失，而是恢复流程演练中发现链路断点。配置快照都在，挂载点和权限也确认过，脚本能跑，但一到数据一致性校验，应用层就出错。日志显示 nginx 正常启动，php-fpm 也没报错，MySQL 进程列表干净，慢查询没爆，整体看主机资源都没压到警戒线。实际症状是：前端页面能响应，接口返回慢，部分请求被卡住，TTFB 超过 160ms，API 服务延迟反复波动。

我先核查备份文件完整性和权限，确认挂载点都没问题，再验证恢复脚本能否正常导入数据库结构和数据。MySQL 日志里没报锁表，journalctl 也没见 fatal 错误，nginx 状态正常，但 curl 测试结果显示 dns、connect、ttfb 都略高，尤其 total time 超出预期，说明链路还有隐性瓶颈。分析后发现恢复流程虽然能还原文件，但数据库和 PHP-FPM 池压力恢复不到正常水平，说明上下游接口没完全跑通。

进一步检查发现主机 IOPS 足够，4K 随机读写和顺序读写都符合 Hetzner 官方参数，但 API 服务在恢复后请求队列长时间未清空。PHP-FPM pool 配置用的是动态模式，max_children 18，max_requests 500，看着够用，但恢复后部分请求卡在 slowlog，说明应用层 IO 或网络没完全恢复，实际压力测试下 error rate 还高于 1%。这类问题不是主机单点故障，而是恢复链路中权限、配置和应用状态结合点没写清楚。

实测数据和终端记录

针对这次备份恢复演练，我跑了一组链路和性能指标，覆盖德国、芬兰、美国三地线路，重点看 API 服务响应和主机 IO、恢复用时等。

provider: Hetzner
scenario: "VPS推荐 / 备份做了，但恢复演练还没过"
regions_checked: "德国纽伦堡、芬兰赫尔辛基、美国弗吉尼亚"
near_region_ping: "41ms"
cross_region_ping: "171ms"
homepage_ttfb_p95: "161ms"
random_4k_iops: "13838"
sequential_read: "346MB/s"
sequential_write: "505MB/s"
single_thread_score: "1273"
twenty_minute_error_rate: "1.09%"
snapshot_restore_time: "13min"
test_time: "2026-06-17 16:01"

德国纽伦堡、芬兰赫尔辛基、美国弗吉尼亚三地线路测下来，近区 ping 在 41ms，跨区 171ms，TTFB p95 是 161ms。对于轻量 API 服务来说，这个延迟属于合理范围，但恢复演练后实际能跑通的链路比预期慢，部分请求 delay 依旧明显。说明备份恢复后服务状态并非完全一致，链路里还有配置差异。

主机 IO 性能表现不错，随机 4K IOPS 13838，顺序读 346MB/s，写 505MB/s。单线程 score 是 1273，快照恢复 13分钟，属于 Hetzner 这类 VPS 商的标准表现。但压力测试时20分钟 error rate 1.09%，说明恢复后部分进程还没完全跑通，慢请求和 php-fpm 队列有残留，挂载点和权限没出问题，应用层才是瓶颈。

测试时间是 2026-06-17 16:01，期间主机资源都稳定，但 snapshot restore 用时和应用恢复存在 gap。运维角度看，不能只信主机快照的完整性指标，也要用 curl、systemctl、journalctl、mysqladmin 这些命令去校验服务实际状态。恢复演练时应设置 rollback window，如果恢复步骤写不全，不能把备份当保障，必须停在回滚边界。

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/
systemctl status nginx --no-pager
journalctl -u php-fpm --since '20 min ago' --no-pager
mysqladmin processlist

权限、配置、脚本都要写到恢复演练里

实际操作时，我先核对备份文件和挂载点，确认权限没缺失，再跑恢复脚本导入数据库。数据一致性校验后发现部分业务表没完全加载，php-fpm 队列积压，慢请求进 slowlog。日志 rotation 没问题，nginx upstream 也没超时，但 MySQL processlist 显示部分连接未释放。前端页面是静态缓存命中，API 服务却没正常响应。主机 IO、网络、内存、CPU 都没到瓶颈，应用层恢复链路才是关键。

curl 测试每项指标都重跑，dns、connect、ttfb 都合格，但 total time 偏高，说明恢复后链路还有隐患。systemctl 和 journalctl 检查 nginx、php-fpm 状态都没挂，慢请求慢慢减少，说明只是恢复流程没同步好。mysqladmin processlist 发现部分请求卡住，数据库权限要重查一遍，尤其是恢复脚本里参数和表结构兼容性。恢复演练必须写明 rollback window，如果步骤不全，不能贸然上线。

这次经验是：Hetzner VPS 主机参数都算合格，备份和恢复流程要写明权限、挂载点、脚本和配置。如果恢复步骤能跑通，才算有保障。对于新手，防火墙和备份流程必须做完整再考虑上线。全球服务器商的线路和成本都比较清晰，但应用层恢复链路演练一旦没跑通，风险就是自己的。

恢复演练时，php-fpm pool 配置和 slowlog 参数直接影响接口响应和压力分布，尤其是 max_children、max_requests、slowlog 超时等。调整这些参数才能保证应用层恢复后压力能正常释放。

pm = dynamic
pm.max_children = 18
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/www-slow.log

pm 用 dynamic，max_children 设到 18，start_servers 4，min_spare_servers 3，max_spare_servers 8，max_requests 500，这样恢复后每个进程都能灵活扩缩。request_slowlog_timeout 3s，慢请求会进 slowlog，/var/log/php-fpm/www-slow.log 可以定位卡住的链路。恢复演练时，压力测试要覆盖 max_requests 和 slowlog 超时，确保 php-fpm 池能撑住高峰请求，慢日志能及时归档，问题能定位到具体进程。

风险是：如果恢复步骤没写明 max_requests 和 slowlog 超时，压力池参数和应用层数据不一致，rollback 就不清楚。演练流程必须写明 rollback window，如果恢复脚本、权限、配置没衔接好，恢复失败就要快速回滚，不然备份等于没做。保证每次恢复演练能跑通所有链路，才能把备份当保障，否则只能停在回滚边界。

Hetzner VPS 在全球服务器商中性价比和线路都算清晰，但运维流程一定要写明备份、恢复、权限、挂载点、脚本和应用状态。这次演练后才发现，恢复链路没跑通，备份只是文件不是保障。轻量 API 服务上线前，先把恢复演练写全，才能安心用 VPS 推荐方案。我的习惯是：日志、命令、配置、脚本挨个查，恢复步骤写不全就不敢上线。