
我一直用 Obsidian 的 Self-hosted LiveSync 插件和 CouchDB,在电脑、手机之间同步笔记。最近又有了一个需求:让 Linux 服务器也保留一份持续更新的笔记库,方便 Codex、Hermes 等 AI 工具直接读取和修改 Markdown 文件。
其实,LiveSync 的作者已经提供了官方 CLI 工具。它不需要安装 Obsidian,也不需要桌面环境,就能连接已有的 CouchDB,并将笔记映射到服务器文件夹中。
本文记录我使用 Docker Compose + 官方镜像 的部署过程,包括首次同步、进度查看和实际遇到的几个问题。不需要从源码构建。
前提:已经有可正常使用的 Obsidian + Self-hosted LiveSync + CouchDB;Linux 服务器已安装 Docker 与 Docker Compose。本文不涉及 CouchDB 的安装。首次接入前,请先备份原有笔记库及 CouchDB。
一、先了解同步原理
Obsidian(电脑 / 手机)
↕
CouchDB
↕ sync
data/(CLI 本地数据库)
↕ mirror
vault/(Markdown、附件)
↕
Codex / Hermes / 其他 AI 工具CLI 有两个不同的数据目录:
data:保存本地数据库、同步状态以及配置文件,不是拿来直接阅读的笔记。vault:真正的 Markdown 笔记和附件,AI 工具将来操作的就是它。
三个命令也要区分:
| 命令 | 用途 |
|---|---|
sync | 执行 CouchDB 与 CLI 本地数据库之间的一次同步 |
mirror | 执行本地数据库与实际文件目录之间的一次映射/同步 |
daemon | 常驻运行,保持远程数据库及本地文件持续同步 |
因此,sync 成功后 data 已经有很多内容,但 vault 还是空的,并不代表出错。启动 daemon 后,才会进行实际文件镜像并持续监听更新。
二、创建 Docker Compose 项目
以下以 ~/livesync-cli 为安装位置;也可以换成 /opt/livesync-cli,只要后面路径保持一致即可。
mkdir -p ~/livesync-cli/{data,vault}
cd ~/livesync-cli
nano compose.yaml填入:
services:
livesync:
image: ghcr.io/vrtmrz/livesync-cli:edge
container_name: livesync-cli
restart: unless-stopped
volumes:
- ./data:/data
- ./vault:/vault
command: ["--vault", "/vault", "daemon"]这里使用作者发布的 GitHub Container Registry 镜像,不需要下载项目源码,也不需要在宿主机安装 Node.js。
拉取镜像:
docker compose pull先不要执行 docker compose up -d,因为还没有导入 CouchDB 配置。
edge是滚动更新标签。它适合尝鲜,但升级可能改变行为;稳定运行后最好记录当前镜像版本或摘要,更新前先备份。
三、导入现有 LiveSync 配置
在电脑上的 Obsidian 打开命令面板,执行:
LiveSync: Copy current settings as a new setup URI
插件会让你设置一个用于保护 Setup URI 的密码。复制完整链接,通常以以下内容开头:
obsidian://setuplivesync?settings=...然后回到服务器,在 Compose 目录运行:
docker compose run --rm -it livesync setup '你的完整 Setup URI'出现提示后,输入刚才生成 Setup URI 时设置的密码。注意这不一定是 CouchDB 登录密码,也不一定是笔记端到端加密密码。
导入成功时,末尾可能显示:
[Command] setup -> /data/.livesync/settings.json
[Done] Command 'setup' completed命令前面有时还会出现:
[Warning] LiveSync is not configured yet这是初始化时的状态提示。只要最终出现 Command 'setup' completed,就说明配置已写入;但还不能证明远端同步已经成功。
另外,一次性 setup 命令的启动信息可能显示 Vault Path: /data,并不代表你写在 Compose 中的 /vault 挂载失效。后面启动 daemon 时再检查实际输出目录。
隐私提醒:Setup URI 可能包含 CouchDB 地址、账号及加密配置。不要把完整链接发到公开聊天或截图中。写在 Shell 命令行中还可能保留在历史记录里,操作后要注意处理。
四、首次同步笔记
先把 CouchDB 数据拉到 CLI 的本地数据库:
docker compose run --rm livesync sync如果输出包含:
[Info] LiveSync is configured and ready说明 CLI 已经识别了连接配置,但还需要确认 sync 最终没有报错。不要只凭这一行判断同步完成。
首次同步成功后,启动后台服务:
docker compose up -d检查容器:
docker compose ps
docker compose logs -f --tail=100正常情况下,CLI 会逐步把数据库中的笔记和附件写入宿主机的 vault/。此后只要容器持续运行,新建或修改的笔记就会继续双向同步。
首次镜像前要确保 vault 是专门为这套部署准备的目录,不要直接指向另一份正在使用、未经备份的笔记库。
五、如何判断同步进度?
我第一次部署时也遇到过:sync 已经执行完,vault 中的文件却迟迟没有全部出现。
CLI 没有一个直观的“已完成 80%”进度条。最简单的方法是观察文件数量和目录大小:
find ./vault -type f | wc -l
du -sh ./data ./vault想每 5 秒自动刷新一次,可以在 Compose 项目目录执行:
watch -n 5 'find ./vault -type f | wc -l; du -sh ./vault'如果文件数或占用空间持续增长,就说明有文件正在写入。按 Ctrl+C 退出监控,不会停止 Docker 容器。
另外也可以同时看日志和资源占用:
docker compose logs --tail=50
docker stats --no-stream livesync-cli我自己的首次镜像曾经达到约 2,931 个文件、154MB,容器 CPU 使用率一度超过 160%,但内存只用了三百多 MB。这至少说明当时它在密集处理任务,不是简单地“下载速度慢”。首次全量镜像可能涉及大量小文件、附件解密和重组,因此不一定很快。
这些数字只是我当时的观察,不是正常速度的标准。文件数量暂时不增长,也不能单独证明卡死;应结合日志、CPU 和错误信息判断。同步仍在推进时,不建议反复重启容器。
六、验证双向同步
不要只看容器显示 running。最好亲自测试一次:
- 在电脑的 Obsidian 新建一篇
同步测试.md,确认它出现在服务器vault/中。 - 在服务器上修改这篇测试笔记,确认修改能同步回 Obsidian。
- 再检查是否出现重复文件、冲突或意外覆盖。
确认双向同步正常后,Codex、Hermes 才适合开始使用这个目录。
如果 AI 工具也通过 Docker 运行,初期建议只读挂载:
volumes:
- /root/livesync-cli/vault:/workspace/obsidian:ro上面是以 root 用户目录为例,实际部署时改成你的绝对路径。等确认备份和恢复措施完善,再考虑让 AI 写入指定目录。
七、几个容易遇到的问题
1. Cannot open Setup URI
通常是 Setup URI 没有完整复制,或者输入了错误的解密密码。需要的是生成 Setup URI 时设定的保护密码,不要与 CouchDB 密码混淆。
2. Remote database is locked
LiveSync 会在某些数据库重建或重置操作后锁定远端,防止新设备在状态不一致时造成数据损坏。
先检查已有 Obsidian 客户端是否正在重建数据库,再通过原有插件确认和处理锁定。不要为了让新 CLI 连上就贸然强制解锁、重建或覆盖 CouchDB。
3. data 很大,vault 却没有文件
这是 sync 和文件镜像分开的结果。启动 daemon 后再观察 vault,不必因为刚执行完 sync 就认为故障。
如果需要单独执行一次 mirror,应先停掉常驻实例,避免两个进程同时操作相同的数据目录;通常没有必要手动执行。
4. 一直同步不完整或速度很慢
先用 watch 观察文件数是否还在增长,再检查 docker compose logs 与 docker stats。CPU 较高但文件数持续增长时,可能仍处于首次全量镜像阶段;内存充足时盲目加大内存通常无济于事。
5. 怎样查看、重启或更新?
常用命令都在 Compose 项目目录中执行:
# 查看状态
docker compose ps
# 查看日志
docker compose logs --tail=100
# 重启
docker compose restart
# 停止并移除容器(不会删除绑定的 data/vault 目录)
docker compose down
# 后台启动
docker compose up -d需要更新镜像时:
docker compose pull
docker compose up -d更新前先备份 data、vault 和 CouchDB。不要在不确定同步状态时直接删除 data 或反复初始化。
写在最后
这套方案最吸引我的地方,不是又多了一种同步手段,而是让原本主要在 Obsidian 里使用的笔记,变成了一份 AI 工具可以直接读取的普通文件库。
Mac 和手机继续通过 CouchDB 同步,服务器上的 LiveSync CLI 则负责维护一份 Markdown 镜像。这样 Codex、Hermes 就能结合已有笔记做搜索、整理和自动化。
但有一条底线:同步不等于备份。 特别是当 AI 可以修改、移动、删除文件时,这些操作也可能同步到其他设备。建议先只读使用,再逐步开放写入权限,同时保留独立快照或版本备份。
参考:

💬 评论
评论区正在施法中...
信使正在穿越次元壁,即将抖达... *Alohomora!* 🔓
哎呀!魔法失灵了...
遇到了神秘力量的阻挡。请刷新页面重试!