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

恢复演练的第一步不是回滚

VPS 数据库单节点部署还没做缓存分离时，恢复演练经常成为业务分界线。Leaseweb 的快照和自助备份看起来都在，实际恢复操作却经常遇到脚本超时或挂载点权限不一致。就算 mysqladmin 能跑出来进程列表，FPM 队列也可能因为目录权限错乱无法启动。业务压力测试时，主机层恢复和应用层恢复要分开校对，否则回滚无法写准确边界。

实际故障症状是：备份文件没问题，恢复脚本却卡在数据库链路上。系统日志里 journalctl 和 systemctl status nginx 没报错，但 PHP-FPM 队列排队延迟，MySQL processlist 里出现大量 sleep 状态。跨区访问时 ping 变高，TTFB 上升到 194ms，恢复链路没跑通时，业务数据还没真正回到一致状态。此时先不要急着回滚，应该先核对备份完整性和权限，确认挂载点和恢复脚本可用，再测试数据一致性。

我先检查了备份文件的完整性和挂载点，发现文件权限有部分失效。恢复脚本没写明目录切换，导致恢复操作只能部分完成。这种场景下，Rollback 界限要写清楚——只要恢复步骤没写出来，备份就不能算真正保障。主机层能看到快照恢复时间是 23min，应用层的数据一致性还要手动校验。

实测数据和终端记录

性能和链路指标方面，Leaseweb VPS 在不同区域表现都有数据可查，适合需要全球节点和混合部署的场景。

provider: Leaseweb
scenario: "VPS推荐 / 备份做了，但恢复演练还没过"
regions_checked: "荷兰、德国、英国、美国、新加坡、香港"
near_region_ping: "38ms"
cross_region_ping: "145ms"
homepage_ttfb_p95: "194ms"
random_4k_iops: "15422"
sequential_read: "534MB/s"
sequential_write: "313MB/s"
single_thread_score: "1196"
twenty_minute_error_rate: "0.06%"
snapshot_restore_time: "23min"
test_time: "2026-06-20 10:11"

荷兰、德国、英国、美国、新加坡、香港节点都测过，最近一次恢复演练时，近区 ping 只有 38ms，跨区 ping 达到 145ms。网站首页 TTFB 达到 194ms，VPS 的 IO 性能不错，随机 4k IOPS 能到 15422，顺序读写速度分别是 534MB/s 和 313MB/s。单线程 CPU 得分为 1196，20 分钟内错误率仅 0.06%。快照恢复时间 23 分钟，适合中长期业务的保障需求。

Leaseweb 的产品组合多，带宽和流量边界要提前核对。混合部署时，带宽计费和管理服务分界线必须写进运维文档。实际恢复演练时，跨区访问延迟和 IO wait 都是风险点。全球服务器商的标配资源虽然丰富，但只要快照恢复链路不通，业务恢复流程不一定能自动完成。实际测试时间是 2026-06-20 10:11，每次演练都要更新 rollback 边界。

VPS 推荐场景下，Leaseweb 主机层性能靠谱，但应用层恢复演练还是要手动校对。DNS/CDN 路由和连接数在高并发时容易出现瓶颈，系统自带的快照恢复时间足够覆盖故障窗口，但实际业务对一致性要求高时，还需要额外校验 MySQL 慢查询和 FPM 队列。

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

恢复链路校对不是只看备份文件

实际恢复演练时，我习惯先跑 curl 测试 DNS 和 TTFB，再检查 nginx 和 php-fpm 的状态。journalctl 查 PHP-FPM 最近 20 分钟日志，mysqladmin processlist 校对数据库链路。只要恢复脚本没跑完，业务数据就不能算真正恢复。主机层快照和文件还原没问题，应用层目录权限和配置必须校对。

Leaseweb VPS 运维时，系统服务用 systemd 管控。主机故障和应用故障要分开定位，Nginx upstream timeout 和 MySQL slow query 都有可能造成恢复链路不畅。快照恢复过程里，MemoryMax 和 TasksMax 配置直接影响 FPM 队列能否正常启动。StartLimitIntervalSec 和 StartLimitBurst 保证服务多次重启不会被拉黑，但如果恢复脚本写不完整，rollback 边界还是要手动补上。

我检查了 systemctl status nginx 和 journalctl -u php-fpm，发现有部分任务重启次数过多。这个场景下，MemoryMax=1400M 和 TasksMax=256 保证 FPM 队列不会因为内存耗尽而崩溃。StartLimitIntervalSec=300 和 StartLimitBurst=5 除了防止服务自杀，还能限制异常恢复脚本无限重启。

恢复链路没跑通时，systemd 的重启保护和资源限制配置对数据库和FPM队列保障很有必要。

Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=300
StartLimitBurst=5
MemoryMax=1400M
TasksMax=256

Restart=on-failure 保证服务碰到错误自动重启，RestartSec=5s 让每次重启之间有时间间隔。StartLimitIntervalSec=300 和 StartLimitBurst=5 设置重启阈值，防止服务频繁自杀。MemoryMax=1400M 和 TasksMax=256 控制 FPM 队列和数据库恢复时资源使用，避免内存泄漏导致恢复失败。

风险在于：如果恢复脚本没写完整，这些配置只能防止主机层服务挂掉，应用层的数据一致性还是要手动校对。Rollback 边界必须写明恢复脚本和恢复步骤，不能只依赖快照和自动重启。只要恢复步骤没跑通，备份就不能算真正的保障。

Leaseweb VPS 在全球节点和资源选择上确实适合中长期业务，单节点数据库部署恢复演练必须做好链路校对。备份和快照不是保障，恢复脚本和权限校对才是运维的关键。产品组合多，带宽和管理服务边界提前写清楚，恢复链路没跑通时要先核对权限和数据一致性。实际业务落地，主机层和应用层都要有分界线，不能只看快照时间。