托管型还是非托管型 VPS，您需要哪种？

托管型与非托管型 VPS：简短结论

选择托管型还是非托管型 VPS，本质上是工作量问题，而不是产品问题。非托管型 VPS 意味着您负责打补丁、配置防火墙、执行备份、进行监控，以及凌晨 2 点重启服务器。托管型 VPS 意味着服务商代您完成其中一部分工作，但不同主机提供的托管范围可能差异很大。唯一有用的比较方式，是列出每个方案可以替您承担哪些任务，再根据您自己的工时评估价格。

“托管”没有统一定义。有些服务商所说的托管，是为操作系统安装补丁，并由人工响应工单。另一些服务商所说的托管，只是安装了控制面板，除此之外的所有工作都由您负责。还有些服务商提供带有响应时间承诺的书面服务合同。两个方案可能都使用“托管”这个词，但在所有重要方面都完全不同。因此，应先阅读服务范围说明，再查看价格。如果您还没有确定这台机器的用途，那么先了解 VPS 实际可以做什么 会更重要。

必须有人负责的任务

每台运行中的服务器都有同一组工作。在非托管方案中，这些工作由您负责。在托管方案中，您付费让服务商从这份清单中接手部分工作。逐项检查，并在每项旁边写下负责人姓名。

• 操作系统补丁，以及内核更新要求执行的重启。
• 防火墙规则。添加或删除服务时，必须确保规则仍然正确。VPS 的 ufw 防火墙基础介绍了初始规则集。
• SSH 访问：密钥管理、禁用密码登录、有人离职时吊销其密钥，以及将自己锁在服务器外时的恢复访问方式。
• 备份、异地副本，以及您实际执行过的恢复操作。
• 监控，包括确认服务器可访问、磁盘空间充足、服务仍在运行，以及证书尚未过期。
• 日志检查，以及发现日志中存在异常时的处理方式。
• Web 服务器、数据库、反向代理以及队列（如果使用）的服务配置。
• 证书续期，以及自动续期停止工作后的修复。
• 容量管理，包括在内存耗尽之前发现内存即将耗尽，而不是等 out of memory (OOM) killer 替您发现。
• 事件响应，包括在您无法自行选择的时间保持清醒并确保他人能够联系到您。

其中大多数工作都属于例行任务，可以交给脚本处理。事件响应无法完全自动化，因为它需要有人做出判断。托管方案销售的正是这种能力。因此，下面的检查清单大部分问题都集中在支持范围，而不是补丁管理上。

托管服务通常不包括的内容

买方最容易在这里产生误解，因此必须准确理解。托管合同通常涵盖操作系统和服务商安装的软件。应用层的问题通常不在其范围内。

您自己的代码由您负责。 应用返回 500 错误不属于服务器故障。服务商会确认 Web 服务器进程正在运行，然后将工单退回给您。这是合理的责任边界，也是买方预期与实际购买服务之间最大的差距。

应用层问题通常不在服务范围内。 查询速度缓慢的数据库、更新后出现故障的插件、配置错误的缓存、停止清空的邮件队列，都位于责任边界之上。即使底层软件由服务商安装，这些问题通常也不在托管范围内。

大多数数据恢复也不在服务范围内。 服务商的备份用于保护服务商保存的整台服务器映像，适用于主机硬件故障的情况。这类备份很少针对以下场景设计：您删除了一行数据、执行了错误的迁移，或在六周前损坏了文件但直到今天才发现。请确认保留期限、是否可以提取单个文件，以及由谁执行恢复。

您安装的软件由您负责。 如果您安装 Docker，服务商通常负责主机，而容器内的所有内容由您负责。

手动修改可能导致支持失效。 某些合同规定，客户直接修改组件配置后，该组件就不再属于支持范围。如果您计划调整配置，请先确认相关条款。

将自己的时间成本与每月差额比较

查看面前的两份报价，记下每月差额。这个金额就是服务商为从上面的清单中移除这些工作而收取的费用。现在，为你在这笔交易中承担的部分估算一个金额。

• 你的一小时值多少钱？这份清单自动化后，每月需要你投入多少小时？
• 运行在这台服务器上的业务每停机一小时，会损失多少钱？

启用自动更新和外部监控的稳定 Ubuntu 服务器几乎不需要日常维护。多数月份甚至完全不需要处理。脚本接管例行工作后，这些工作成本很低。真正昂贵的是中断，而托管方案出售的正是对中断的处理能力。如果服务器运行的是个人兴趣项目，宕机不会造成损失，那么不托管显然更合适。如果服务器承载订单，则应认真评估支持合同是否确实能缩短故障时间，因为托管服务商仍然需要读取你的工单、复现故障并采取措施。

差额还会随服务器数量增加而变化。托管费用通常按服务器收取，而自动化脚本只需编写一次即可复制到其他服务器。第二台服务器会降低你为第一台服务器编写的脚本的平均成本，因此在承诺支付按服务器收取的费用前，请先阅读如何管理多台 Linux 服务器。要了解比较双方的基础成本，VPS 每月实际需要多少钱可用于确定下限；当工作负载足够大、托管溢价相对总成本可以忽略时，还应考虑VPS 与独立服务器之间的取舍。

付款购买托管高级服务前要向主机商询问的问题

付款前先询问，并要求对方以书面形式回答。销售页面不是服务范围文档。

1. 具体包含哪些服务？请对方提供逐项清单，不要只看宣传册。
2. 支持范围是否包括我安装的软件，还是只包括你们安装的软件？
3. 你们是否会自动安装补丁？内核更新是否会在未事先征得我同意的情况下重启服务器？
4. 如果你们安装的补丁导致我的应用无法运行，由谁负责？
5. 你们是否执行备份？备份存储在哪里？保留多长时间？由谁执行恢复？
6. 你们最近是否恢复过客户服务器？恢复花了多长时间？
7. 工单响应时间是多少？周日 03:00 的响应时间是否不同？
8. 我是否保留 root 访问权限？使用 root 访问权限是否会减少你们提供的支持范围？
9. 费用按服务器收取，还是按账户收取？
10. 如果我终止服务，可以带走什么？如果配置存在专有控制面板中，可能很难导出。

第 5 个问题决定了其他大多数问题的答案。主机商如果能准确回答，说明他们以前确实执行过恢复。含糊的回答意味着他们从未测试过恢复，而未经测试的备份只能算是一份副本。第 5 个问题还涉及存储位置：副本实际存放在哪里，不仅是技术问题，也是法律问题；选择托管国家时真正需要关注的因素对此有详细说明。

自动化管理的中间路径

大多数技术读者既不想走两个极端。他们希望使用非托管方案，把例行工作交给机器，自己只处理机器无法判断的事情。应在第一天完成设置。新 VPS 上的前十分钟是选择非托管方案后的实际起点，而强化 SSH 访问安全也应在同一次初始会话中完成。

自动安全更新

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

该文件现在应包含 APT::Periodic::Update-Package-Lists "1"; 和 APT::Periodic::Unattended-Upgrade "1";。文件缺失，或任一行包含 0，都表示不会执行任何操作，您也不会收到通知。

在不修改系统的情况下进行测试。请注意，软件包名称是 unattended-upgrades，但命令使用单数形式：

sudo unattended-upgrade --dry-run --debug

输出会列出它检查过的每个软件包。如果没有待处理更新，最后会显示类似 No packages found that can be upgraded unattended 的一行。实际执行记录会写入 /var/log/unattended-upgrades/unattended-upgrades.log，因此请检查该位置，不要凭猜测判断。

内核更新不会立即生效，必须重启机器，因为运行中的内核是在启动时加载的。等待重启时会出现文件 /var/run/reboot-required。您可以监控该文件，也可以让机器在 /etc/apt/apt.conf.d/50unattended-upgrades 中自动处理重启：

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

用户登录时，Automatic-Reboot-WithUsers "false" 会阻止重启。对于您需要交互使用的服务器，这样更安全；对于没有用户登录的服务器，则没有作用。Ubuntu 上完整的无人值守升级配置介绍了阻止列表语法和邮件选项。

在其他位置运行的监控

在服务器上运行的监控无法告诉您服务器已宕机，因为监控本身也会随之停止。请将检查任务放在第二台主机或外部服务上。使用 Uptime Kuma 进行状态监控是常见的自托管方案，并且应部署在被监控服务器之外的另一台机器上。

至少监控四项：可达性、磁盘使用量、应用是否在实际端口响应，以及证书过期时间。磁盘问题最容易被忽略。日志文件或数据库每天增长一点，可能在其他指标无法预测的时刻耗尽磁盘空间，导致服务器停止运行。最初的症状通常是服务无法写入数据后退出。

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

还应添加心跳检查。服务器上的计时器会在每次备份或健康检查成功后调用一个 URL；监控在该调用停止到达时发出告警。这样，即使服务器不再响应，也能自行触发告警；如果故障出在网络路径上，仅执行拉取检查的监控无法做到这一点。

至少恢复过一次的备份

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init 只会打印一次 created restic repository <id> at sftp:...。对已存在的存储库执行该命令时，命令会失败，而不是覆盖存储库。这正是您需要的行为。请将该密码短语的副本保存在服务器之外的位置：没有它就无法读取存储库，而且没有恢复途径。

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots 应列出您刚刚创建的任务，并显示今天的日期。restic check 会验证存储库结构，并打印 no errors were found。现在执行大多数人会跳过的步骤：

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

您预期的文件要么存在，要么不存在，现在确认只需十分钟。然后将该任务交给计时器执行，使其不依赖您手动操作。写入 /etc/systemd/system/restic-backup.service：

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

并写入 /etc/systemd/system/restic-backup.timer：

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers 会显示下一次运行时间和剩余时间。结果为空，表示您启用的是服务而不是计时器，这是此处最常见的错误。Persistent=true 会在下一次启动后执行错过的任务，因此机器即使整夜关机，也能完成备份。VPS 上的 Restic 备份进一步介绍存储库布局和保留策略，systemd 服务和计时器则逐行解释单元文件。

自动化无法替代的工作

自动化无法替代判断。02:00 执行的自动重启不会考虑应用能否正常恢复，因此请确认每项服务都能自行启动，然后在您清醒时主动重启服务器：

systemctl is-enabled nginx docker
sudo reboot

无人值守升级也可能安装破坏应用的软件包，而整个流程不会知道发生了什么。监控会发现此类问题，因此启用自动更新后，监控不是可选项。机器负责例行工作。故障处理仍由您负责。

托管服务何时值得付费

应客观看待托管服务。在以下4种情况下，选择托管服务是合理的。

• 团队中没有人负责 Linux，而且没有计划雇人处理。
• 合规要求明确指定负责打补丁的一方，而这方不能是您。
• 您使用的技术栈正是主机商擅长的领域，因此其支持团队以前处理过相同的故障。
• 原本负责这些工作的员工成本最高，而其1小时的成本高于托管服务的月度溢价。

托管服务并不一定更安全。与疏于维护的所有者相比，托管方案通常打补丁更快，这确实是一项优势。托管服务还经常会安装控制面板。控制面板是面向网络的大型应用，带有登录页面，也有自身的漏洞历史。这种取舍可能合理，但仍然是一种取舍。

每次决策都归结为同一份清单。列出这10项任务，针对每份报价标明每项任务由谁负责，然后将差额与您1小时时间的价值进行比较。大多数认真分析过这些问题的技术人员，最终会选择非托管方案，再用定时器执行例行任务。这是一种有充分依据的选择，而不只是为了省钱。

FAQ

托管 VPS 与非托管 VPS 有什么区别？

非托管 VPS 只提供服务器本身，其他工作都由您负责，包括打补丁、防火墙、备份、监控，以及内核更新后的重启。托管 VPS 会将其中一部分工作交给服务提供商，通常包括操作系统层和提供商为您安装的软件。具体责任边界由各个服务提供商自行规定，而不是由“托管”这个词决定。因此，在比较两种价格前，应要求对方以书面形式说明每项任务的责任范围。

托管 VPS 是否意味着我不需要自行备份？

不需要。服务提供商的备份通常保护的是整台服务器的镜像，用于主机发生故障的情况。当您误删文件、执行了错误的迁移，或数周前数据已损坏但直到今天才发现时，这类备份通常无法提供帮助。请确认快照保留多长时间、是否可以恢复单个文件，以及由谁执行恢复。然后使用 restic 等工具保留自己的异地副本，并使用 restic restore latest --target /tmp/restore-check 对其进行测试，以确认备份确实可用。

托管 VPS 是否比非托管 VPS 更安全？

并非如此。托管方案的补丁速度通常快于从不登录维护服务器的所有者，这确实可以降低风险。许多托管方案还会安装控制面板，而控制面板是一个面向网络的大型应用，拥有自己的登录页面，也有自身的漏洞历史。与运行控制面板的托管服务器相比，启用自动安全更新、关闭防火墙端口、仅允许使用密钥进行 SSH 登录，且没有额外监听服务的非托管服务器，攻击面更小。

我可以先使用非托管方案，之后再切换到托管方案吗？

通常可以，但这很少只是勾选一个选项。服务提供商通常会在承担管理责任前审计或重建服务器，因为他们不会支持自己无法查看的配置。请确认接入托管服务需要哪些步骤、是否需要重新安装系统，以及之后您自行配置的内容是否仍然不在支持范围内。

使用托管 VPS 时，我还能保留 root 访问权限吗？

大多数托管 VPS 方案允许您保留 root 访问权限，但 root 访问权限会影响支持范围。有些服务提供商会降低或取消对您手动修改过的组件提供的支持；如果工单处理涉及较深层次的问题，有些服务提供商还可能使用自己的模板重建服务器。在修改任何配置前，请先以书面形式确认相关规则，并将配置文件纳入版本控制，这样重建服务器只需花费一小时，而不是整个周末。