与Obsidian同步的博客搭建——持续运维

前一篇已经把博客真正部署到服务器上了，这一篇就不再重复安装和上线步骤，只讲一个更实际的问题，站点跑起来以后，你每天怎么维护它。

这套方案最大的好处，不是在第一次部署时省了多少命令，而是在后面的日常使用里几乎没有发布动作。你继续在 Obsidian 里写，Syncthing 继续同步，服务继续监听文件变化，网页自己更新。对个人博客来说，这种体验比一套很重的后台更值钱。

这一篇会把最常用的几件事收尾讲清楚，内容更新流程、代码更新流程、一键脚本、常见问题排查、资源占用和安全建议。你可以把它当成这套博客的运维速查表。

内容更新流程

先说最舒服的一段链路，也就是平时写文章时的流程：

Obsidian 写文章 → Syncthing 自动同步到服务器 → Watcher 检测到文件变化 → 自动重新扫描 → 网页立即更新

这条链路一旦跑通，后面基本就是零操作发布。

你在本地 Obsidian 里写完一段，按下保存，Syncthing 会把对应的 Markdown 文件同步到服务器上的 /opt/vault。服务端的 watcher 会盯着这个目录，一旦发现文件变化，就会在一个很短的缓冲窗口后重新扫描内容。这里我实际用的是 500ms debounce，意思是连续保存几次时，它会把这些抖动合并掉，避免重复扫描。正常情况下，几秒内网页就能看到最新内容。

这也是这套博客最省心的地方。你不需要 git push，不需要手动构建，不需要重启服务，也不需要登录后台点发布按钮。写完，保存，等几秒，刷新网页，文章就已经在那里了。

如果你主要是写字，而不是天天改程序代码，这个体验会非常顺。博客不再像一个单独的发布系统，更像是你的 Obsidian Vault 自己长了一个网站出口。

代码更新流程

内容更新很轻，但程序代码更新还是要走一次标准流程。比如你改了后端逻辑、模板、前端样式，或者加了新功能，这时候就不能只靠文件同步了，而是要在服务器上重新拉代码、重新编译、替换运行文件、重启服务。

直接用下面这组命令就行：

# 在服务器上
cd /root/bedic-web
git pull
cargo build --release
cp target/release/bedic-web /opt/bedic-web/
cp -r static /opt/bedic-web/
cp -r templates /opt/bedic-web/
systemctl restart bedic-web

这一段的思路很直接：

• /root/bedic-web 是源码和编译目录
• /opt/bedic-web 是真正运行的目录
• 改完代码以后，用 cargo build --release 生成新的可执行文件
• 把二进制、静态资源、模板复制到运行目录
• 最后 systemctl restart bedic-web 让新版本生效

平时内容更新不需要动这套命令，只有程序本身发生变化时才需要跑。把“文章更新”和“代码更新”分开，你的维护成本会低很多，也不容易误操作。

一键更新脚本

如果你后面会频繁改代码，手敲这一串命令还是有点烦，最省事的做法就是写一个 update.sh。

先在服务器上创建脚本：

nano /root/bedic-web/update.sh

内容可以直接写成下面这样：

#!/usr/bin/env bash
set -e

cd /root/bedic-web
git pull
cargo build --release
cp target/release/bedic-web /opt/bedic-web/
cp -r static /opt/bedic-web/
cp -r templates /opt/bedic-web/
systemctl restart bedic-web

保存以后，给它可执行权限：

chmod +x /root/bedic-web/update.sh

以后要更新代码时，只要执行：

/root/bedic-web/update.sh

这样做的好处很实际。第一，你不用每次重新回忆步骤。第二，少打几次命令，就少几次漏复制文件或者少重启服务的机会。第三，后面你想继续往脚本里加检查逻辑也很方便，比如更新前先跑测试，或者更新完成后自动看服务状态。

常见问题排查

这一节最适合收藏。真到线上出问题时，先按顺序查，不要一上来就改代码。

1. 网站无法访问

先看服务本身是不是活着：

systemctl status bedic-web
journalctl -u bedic-web -f
systemctl status caddy
ss -ltnp | grep -E ':3000|:80|:443'

排查顺序通常是这样：

• bedic-web 没起来，先看应用日志
• bedic-web 正常，但域名访问失败，去看 Caddy
• Caddy 正常，但 80、443 没开，检查安全组和端口监听
• 如果是 502 Bad Gateway，大概率还是后端服务没起来或监听地址不对

2. Syncthing 不同步

如果本地文章保存了，服务器没有新文件，先看 Syncthing 状态：

systemctl status syncthing@root

然后用 SSH 隧道打开 Web UI：

ssh -L 8385:127.0.0.1:8384 root@你的服务器IP

浏览器访问：

http://localhost:8385

重点检查三件事：设备是不是已互连，Folder 状态是不是 Up to Date，同步目录是不是确实指向 /opt/vault。很多时候不是程序坏了，而是设备离线、认证没通过，或者文件夹路径配错了。

3. 编译失败

Rust 项目第一次编译就比较吃机器，2核2G 能跑，但确实不算宽裕。先查版本和环境：

source ~/.cargo/env
rustc --version
cargo --version
free -h

如果日志里出现内存不足，最常见的补救办法就是加 swap：

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
free -h

有了 swap 以后，编译速度可能不会变快，但至少不容易在一半的时候被系统直接杀掉。

4. 文章不更新

这种情况最容易让人误会成“同步坏了”或者“程序坏了”，其实常见原因就几个：

• 服务读的 Vault 路径不对，应该确认 VAULT_PATH=/opt/vault
• 文章 frontmatter 里还是 draft: true
• 文件根本没同步到服务器
• watcher 已经检测到变化，但日志里报了解析错误

先盯日志最有效：

journalctl -u bedic-web -f

如果你连续保存好几次，却只看到一次重新扫描，也别慌，这通常就是前面说的 500ms debounce 在工作。它不是丢更新，而是在合并短时间内的重复事件。

性能与资源

这套博客还有一个很适合个人项目的优点，就是运行时很轻。编译阶段会吃一点 CPU 和内存，但真正上线以后，Rust 二进制常驻内存通常也就 10 到 20MB 左右，小服务器完全带得动。

对 2核2G 这种配置来说，真正重的不是访问流量，而是你在服务器上重新编译。只要不是同时塞很多别的服务，这个博客本身不会给机器造成太大压力。内容更新时只是扫描和重新加载，成本也远低于重新构建整站。

安全建议

个人博客不用搞得太复杂，但有三条我还是建议你长期坚持。

第一，定期更新系统：

apt update && apt upgrade -y

第二，备份数据库和关键目录。哪怕现在数据不大，也别等出事以后才想起来：

mkdir -p /root/backups
cp /opt/bedic-web/bedic.db /root/backups/bedic.db.$(date +%F-%H%M%S)

第三，条件允许的话，后面逐步把服务改成非 root 用户运行。前期为了省事直接用 root 没问题，但长期来看，单独建一个运行用户会更稳，也更符合基本的权限隔离思路。

系列总结

到这里，这个系列一共 6 篇就收尾了。

1. 前言，讲为什么要做一套和 Obsidian 同步的博客
2. Rust 后端开发（上），把基础解析和页面渲染跑起来
3. Rust 后端开发（下），补全搜索、分类、内容索引和 watcher
4. 前端美化，把页面做得更耐看，也更适合长期阅读
5. 服务器部署，把服务、反向代理和同步链路真正放到线上
6. 持续运维，也就是这一篇，解决日常更新和排错问题

如果让我用一句话总结这套方案，它不是“最省步骤”的博客系统，但它是“写起来最顺手”的那一类。你不用先迁就平台，再开始写作，而是先在自己熟悉的 Obsidian 里写，网站只是顺着你的写作流自然长出来。

它的优点很明确：

• 写作流畅，Obsidian 和博客几乎是一体的
• 性能好，运行时占用低
• 部署简单，链路清楚
• 后续维护成本低，内容更新几乎零操作

缺点也很真实：

• Rust 有学习曲线
• 首次编译和代码更新时编译时间偏长
• 没有现成的可视化后台，一些操作还是要进服务器处理

不过对个人博客来说，这些缺点很多时候是可以接受的交换。你拿到的是更高的掌控感、更轻的运行成本，还有一条真正贴合自己写作习惯的内容链路。

如果你已经跟着前五篇一路搭到这里，其实最难的部分已经过去了。剩下的事很简单，继续写，继续改，继续让这个站一点点长成你想要的样子。对个人博客来说，能稳定写下去，本身就是最好的运维。