VPS 用途指南：按任务选择 Docker 应用与恢复检查
从订阅、笔记、书签、项目资料和音乐等任务选择教程，核对账号权限、共机资源、数据备份与恢复，再决定是否购买。
已经有一台 VPS，想用它保存笔记、订阅更新或管理私人资料，可以先选一件经常要做的事，再部署对应应用。应用装好以后，账号权限、数据增长、备份和升级都要继续维护；把界面打开，只完成了第一步。
下面按用途连接具体教程。每个入口都应先用少量无敏感数据试运行，核对写入、匿名访问和恢复，再搬正式资料。已有机器有余量，可以继续使用；暂时没有时间维护时，也不必为了尝试一个工具另买 VPS。
先选一件事，确认哪些资料必须带走
| 你要解决的问题 | 部署教程 | 恢复时要核对什么 |
|---|---|---|
| 集中订阅 RSS，在不同设备继续阅读 | Miniflux 订阅与阅读记录迁移 | 账号、分类、订阅、历史文章、已读和收藏；OPML 只保留订阅清单 |
| 备份或迁移已有的 Immich 3.3.3 相册 | Immich 原图与相册恢复 | 原图、相册关系、用户、完整媒体目录与同一停写窗口的数据库；恢复后再试新上传，缩略图不能代替原图 |
| 归档扫描件，按中文正文找合同或票据 | Paperless-ngx 中文 OCR 与文档恢复 | 原件、归档版本、缩略图、文档元数据与普通账号权限；OCR 文字和时间精度另核对 |
| 随手记短笔记、上传少量附件 | Memos 短笔记 | 笔记、附件、用户和匿名访问范围，恢复后再试一次新写入 |
| 收藏网页，整理标签和备注 | Linkding 私人书签 | 书签与账号，以及实际启用的快照、缩略图等资产；浏览器书签导出不能代替全备份 |
| 建立资料树，在电脑间同步笔记 | TriliumNext 笔记同步 | 较早笔记、附件与同步方向；恢复副本先不接正式桌面端 |
| 管理任务、讨论和项目附件 | Vikunja 待办与项目资料 | 数据库和附件来自同一个停写窗口，成员权限、评论与附件下载都要检查 |
| 保存私人代码及相关议题 | Forgejo 私有 Git | 仓库、账号、权限、议题、附件、LFS 和配置；一次 clone 不等于实例备份 |
| 记录家务和重复维护事项 | Donetick 家庭任务 | 成员、完成历史、重复周期和配置，恢复演练先停通知 |
| 从手机访问自己的音乐库 | Navidrome 私人音乐库 | 音乐文件、应用数据、账号与播放资料；数据库恢复不替你找回音乐文件 |
| 发现网站故障并收到通知 | Uptime Kuma 监控 | 监控项、历史记录和通知绑定，测试副本不要发送正式告警 |
| 回看 VPS 变慢时的资源占用 | Beszel 主机与容器曲线 | Hub 完整历史、密钥与每台 Agent 的配置和持久身份；恢复后核对旧记录，再等新采样 |
这些用途的数据范围不同。只想同步几个书签，先看 Linkding 的普通镜像；大量保存网页快照时，再单独估算归档开销。已有桌面笔记的 TriliumNext 用户，则应先确定哪一份笔记库是原件，不能在两端各建一个新库以后期待自动合并。
私人音乐库还涉及文件使用权和播放网络，项目任务涉及成员与附件权限。先把这些条件写下来，再决定是否把资料放到公网可访问的实例里。
让入口受控，再测试真正的操作
部署先使用回环端口和 SSH 转发，完成首个管理员初始化。接自己的域名以后，配置 HTTPS，并把应用要求的实际访问地址一并更新；代理在宿主机和容器里时，上游地址不同，不能照抄另一个环境的 127.0.0.1。
访问设置各有不同。Memos 要分别检查管理员、普通成员和匿名窗口；Vikunja 要核对成员加入后的注册开关和私人项目权限；Forgejo 要用普通账户实际 push，再检查未登录者读不到私人仓库。管理员成功操作，不能替代普通账户的权限验证。
每个应用选一个能代表用途的动作：笔记上传后再下载附件，书签导入后核对标签，RSS 标成已读并收藏，任务完成后查看下次日期，音乐在常用手机客户端完整播放。监控工具还要把通知绑定到项目，检查一次自己控制的故障和恢复，不能只凭“测试消息已发送”认定正式通知配置完成。
基础入口设置见宿主机 Caddy 与 HTTPS。具体应用的地址、认证和注册参数继续按对应教程核对，不为解决登录错误而接受任意来源、关闭证书校验或把所有数据目录设成任何人可写。
共用机器时，把应用之间的影响算进去
几个低负载私人应用可以先在已有机器上试部署，但每个项目应有独立的服务名、端口、数据落点和版本记录。端口冲突先检查实际占用者与Compose 合并后的最终映射，不要停止一个自己还没确认用途的容器。
容量按所有应用的总开销安排。图片、网页快照、音乐和任务附件会占盘；数据库导出和恢复也需要空间。转码、网页归档和 CI 构建应单独观察，不能用一个空白笔记实例的占用推算整台机器能承载的服务数量。
监控的位置还要单独考虑。把 Uptime Kuma 和被监控的网站放在同一台 VPS，两者可能随整机故障一起停止；确实需要知道整机断网、关机时，要安排不会与业务机同时失效的检查节点。其他应用是否需要独立机器，则按资料、权限和故障影响判断，不要求每个工具都买一台服务器。
硬件与地区的比较放在Docker 应用 VPS 配置页；这里的目录用来选择任务和教程，不替代每个应用自己的安装前提。
一份能打开的导出文件，还不是恢复结果
OPML、书签 HTML、个人笔记导出和 Git clone 都有用途，但覆盖的资料不同。Miniflux 的阅读状态在数据库中，Navidrome 的音乐在文件目录中，Vikunja 的附件也不能靠数据库单独恢复。
按实际部署列出数据库、文件、配置、凭证与镜像版本。小型 SQLite 实例可以依对应教程暂停应用后保存完整数据目录；外部 PostgreSQL 则用对应数据库工具取得一致备份，再和附件等文件安排同一个停写窗口。备份失败时恢复原服务并留下错误记录，不把残缺文件当作成功副本。
恢复演练另用目录、项目名和端口，保留原实例。先停用测试副本的通知、邮件和 webhook，再核对较早资料、权限和实际下载或播放。确认恢复内容与预期相符，之后才安排域名切换。新版本迁移过数据库以后，回退也需要匹配的旧数据，不能只换回旧镜像。
备份放到独立且受保护的位置；唯一副本仍在原 VPS 磁盘上时，机器或磁盘出问题，副本也可能一起失去。同步会传播误删，收藏会受应用设置影响，两者都不能代替备份。维护方法见Docker 应用备份与迁移。
需要购买时，先定长期要承担的维护
先试一个真正有用的应用，观察数据增长和恢复所需空间，再决定是否增加服务或规格。订阅、成员、附件、保留周期和并发操作都会影响资源；这份目录不提供未经测量的统一最低配置，也不承诺某个套餐能运行全部应用。
需要新 Linux 实例时，可比较 雨云 RCS 的应用配置与地区 和 Evoxt 的 Linux 实例与地区。核对续费、流量、磁盘，以及独立备份存储的费用；确认自己的应用需要什么 Docker 权限和访问条件，再按短周期试部署。已有合适机器可以继续用，预算也要留给备份与恢复空间，不能只看首期服务器价格。
把旧数据恢复、新数据写入、普通用户权限和自己的访问网络都验证一遍，再搬正式资料。以后新增应用时，继续沿同样的验收步骤，避免服务越装越多，却不知道每份数据究竟存在哪里。
