从 Linux 工具链到个人云服务器：一次自托管系统搭建复盘
这两天，我把一台 Linux 主机逐渐配置成了自己的个人云服务器。
最初只是想在 Linux 上安装一些工具，后来从 Shell、Docker 和磁盘管理开始，逐步加入了远程访问、文件管理、Zotero 同步、Obsidian 同步以及博客写作环境。回头看，这个过程并不是“安装几个软件”这么简单，而是在搭建一个属于自己的数字工作台。
我想解决什么问题
我平时使用 Mac、Windows、iPhone、安卓设备和华为平板，数据分散在不同设备和不同服务中：
- 书籍、论文、音乐和电影需要一个统一的存储位置；
- Zotero 需要稳定的附件同步；
- Obsidian 需要跨设备同步笔记；
- 博客需要方便写作、版本管理和自动发布；
- 笔记本电脑在外网时，也应该能够安全访问家里的服务器。
因此，我没有把所有东西都塞进一个同步软件，而是按照数据类型拆分服务。
最终的整体架构
flowchart TD
A[Mac / Windows / iPhone / 平板] --> B[Tailscale 私有网络]
B --> C[Linux 主机]
C --> D[Nextcloud]
C --> E[CouchDB]
C --> F[GitHub Pages 工作流]
D --> G[Zotero WebDAV]
E --> H[Obsidian Self-hosted LiveSync]
F --> I[博客仓库]
C --> J[大容量 ext4 数据盘]
这里有一个很重要的原则：不同数据使用不同的同步机制。
1
2
3
4
5
Zotero → Nextcloud WebDAV
Obsidian → CouchDB + Self-hosted LiveSync
博客源码 → Git + GitHub Actions
大文件资料 → Nextcloud 文件存储
远程访问 → Tailscale
第一步：从 Shell 和 Linux 基础开始
Linux 主机的很多事情最终都要回到终端完成。Shell 不只是“黑色窗口”，而是管理系统、检查磁盘、查看服务和自动化任务的主要入口。
这次配置中最常用的操作包括：
1
2
3
4
5
6
7
pwd
ls -lah
find /path -maxdepth 2 -type f
df -h
mount
systemctl status docker
docker compose ps
安装软件时，我也尽量把配置写成可重复执行的文件，而不是只在网页界面中点击。这样以后迁移到另一台主机时，可以重新检查配置，而不是依赖记忆。
第二步：用 Docker 管理长期运行的服务
Docker 适合把不同服务隔离开。当前的服务大致分为几类：
- Nextcloud：文件管理和 WebDAV；
- PostgreSQL：Nextcloud 数据库；
- Redis：缓存和文件锁；
- CouchDB：Obsidian LiveSync 的同步后端；
- Syncthing：保留作其他文件同步实验。
Docker Compose 是这套系统的核心入口。它把镜像、环境变量、端口、挂载目录和重启策略统一记录在 compose.yaml 中。
1
2
3
4
docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs --tail=100 nextcloud
一个值得坚持的习惯是：应用配置和应用数据分开保存。容器可以重建，但数据目录不能随意删除。
第三步：重新规划磁盘
这次配置中，系统盘和资料盘承担不同职责：
- LVM/NVMe：Linux 系统、Docker 应用状态、数据库配置；
- 独立 ext4 数据盘：Nextcloud 文件、媒体、书籍、论文和备份；
- 原有 Windows 备份盘：保持原样，不参与格式化。
NTFS 资料盘可以在 Linux 上读写，但如果它要长期承载 Linux 服务的数据，ext4 更自然：权限、属主、软链接、文件锁和容器挂载都更符合 Linux 的工作方式。
不过，格式化磁盘是不可逆操作。实际操作时必须先确认设备名、挂载点和要保留的数据，不能因为“看起来像数据盘”就直接执行格式化。
第四步：用 Tailscale 解决外网访问
我没有直接把 Nextcloud 端口暴露到公网，而是使用 Tailscale 建立私有网络。
这样，服务器和 Mac、手机加入同一个 tailnet 后，可以通过私有域名访问服务；没有加入这个网络的设备无法直接访问。
这套方式的好处是：
- 不需要配置家庭宽带端口转发；
- 不需要把服务直接暴露到公网；
- 笔记本外出时仍然可以访问家里的服务；
- Nextcloud 和 CouchDB 可以继续只监听本机端口，再通过 Tailscale Serve 提供 HTTPS 入口。
安全性并不是“用了 Tailscale 就不用管了”。每个服务仍然应该使用独立账号、应用密码和最小权限。
第五步：用 VS Code 连接 Linux 主机
如果需要直接修改服务器上的 Compose 文件、Shell 脚本或博客配置，VS Code Remote SSH 是很自然的入口。编辑器运行在本地，但文件和终端可以位于远程 Linux 主机上。
这种方式适合：
- 修改
compose.yaml和环境配置； - 查看 Docker 日志；
- 编写部署脚本；
- 检查 Git 状态和提交记录；
- 在服务器上运行 Jekyll、Node 或其他构建工具。
需要区分两件事：VS Code Remote SSH 是远程开发工具，不是文件同步工具。它解决的是“在哪里编辑和执行命令”，而 Tailscale 解决的是“如何安全连接”，Git 和 LiveSync 才分别负责代码版本与笔记同步。
第六步：为 Zotero 和 Obsidian 分开设计同步
Zotero 和 Obsidian 都会产生大量文件，但它们的同步逻辑完全不同，所以没有使用同一个账号或同一个同步目录。
Zotero：WebDAV
Zotero 的附件使用 Nextcloud WebDAV，单独使用 zotero-sync 账号和配额。Zotero 的文献库元数据仍然由 Zotero 自身同步，WebDAV 主要保存附件。
Obsidian：Self-hosted LiveSync
Obsidian 使用 Self-hosted LiveSync，后端是独立的 CouchDB 数据库。它不是把文件简单地定时上传，而是保存同步文档、变化和冲突信息，适合频繁编辑和多设备切换。
端到端加密应该开启，并在所有设备上使用同一个加密密码。这个密码和 CouchDB 登录密码不是一回事，丢失后也可能无法恢复数据。
最重要的规则是：同一个 Vault 不要同时使用 LiveSync、Remotely Save、Nextcloud 桌面客户端和 Syncthing。
第七步：把博客写作纳入 Git 工作流
博客本身是一个 Jekyll + Chirpy 项目。文章是 Markdown 文件，放在 _posts/ 目录中，推送到 GitHub 后由 GitHub Actions 自动构建并发布 GitHub Pages。
我把博客作为一个独立的 Obsidian Vault，而不是和日常笔记混在一起：
1
2
3
4
5
6
Romanrose Blog/
├── _posts/
├── _tabs/
├── _config.yml
├── Gemfile
└── .github/workflows/pages-deploy.yml
写作时使用 Obsidian，版本管理仍然使用 Git：
1
2
3
4
5
git pull --ff-only
# 在 Obsidian 中写作
git add .
git commit -m "Write a new post"
git push
这比把博客仓库同时交给多个同步软件更容易维护。Git 负责版本历史，GitHub Actions 负责发布，Obsidian 负责写作。
这次配置之后的认识
1. 不要让一个工具承担所有职责
Nextcloud 不需要理解 Obsidian，CouchDB 不需要管理电影，Git 也不应该用来同步运行时数据库。每个服务做好自己的事情，整体系统反而更稳定。
2. 数据目录比容器更重要
容器可以删掉重建，数据库和文件数据不行。部署任何服务前，都应该先回答三个问题：
- 数据保存在哪里？
- 容器重启后能否恢复？
- 磁盘损坏后有没有备份？
3. 先建立边界，再追求自动化
用户、配额、数据库和目录隔离，比一开始就追求“所有设备实时同步”更重要。隔离做好后，再逐个打开自动同步功能，出现问题时才容易定位。
4. 自托管的成本主要是维护
自己管理服务器获得了控制权，但也需要自己负责：
- 软件升级；
- 密码和密钥管理；
- 磁盘健康检查；
- 数据备份和恢复演练；
- 服务日志和网络访问控制。
自托管不是把软件装上就结束，而是把数据生命周期真正掌握在自己手里。
结语
这台 Linux 主机现在还不是一个“万能 NAS”，而是一个逐渐成形的个人基础设施：文件由 Nextcloud 管理，Zotero 使用 WebDAV，Obsidian 使用 LiveSync，博客通过 Git 发布，远程访问由 Tailscale 保护。
下一步更重要的工作不是继续安装更多服务，而是完善备份、升级和恢复流程。一个真正可靠的个人云系统，不是服务越多越好，而是每一份重要数据都知道自己在哪里、由谁管理、如何恢复。