企业官网建设流程全解析

1. 自托管笔记的核心诉求：Trilium能解决什么，为什么跑在PVE上

玩PVE的人，多半都有个通病：什么东西都想往自己服务器上塞。我也不例外，在用了一堆在线笔记软件之后，最终决定把个人笔记迁回自托管。经过一番比较，我选定了一款叫 Trilium 的开源笔记服务，并把它部署在 PVE 里的 Linux 虚拟机上。整个过程并不复杂，但中间有不少细节值得专门记录下来——尤其是如果你之前只熟悉 PVE 装软路由、开Windows虚拟机，对“怎么在虚拟机里把一个Node.js应用跑成正式服务”这件事没那么熟的话，这篇教程正好能帮你少走弯路。适合谁看？日常有笔记整理习惯、手里有PVE环境、想彻底掌控自己数据的朋友，看完应该能直接用起来。

1.1 我为什么把个人笔记从商业服务搬到Trilium

在线笔记软件不是不好，但长期用下来有几个点让我越来越难受：免费版限制设备数量，高级版按年付费，数据格式封闭，导出要么没有要么残缺。更关键的是，笔记内容属于很私人的数据，放在别人的服务器上，总有一种“借来的书架”的不确定感。Trilium 解决的就是这个问题——它是完全开源的，数据默认保存在你自己的服务器上，导出支持 Markdown、HTML，甚至可以给笔记内容加密。一旦厂商跑路、服务调整或者我单纯想换机器，数据始终是我自己手里那部分。

Trilium 真正打动我的，是它的树状层级笔记结构。你可以像文件夹一样无限嵌套地组织知识库，而不是像大多数笔记软件那样只能躺在一个平铺列表里。配合全文搜索、标签、属性、双链引用，它非常适合作长期知识积累，写技术文档、读书笔记、工作记录都够用。界面虽然是偏传统的Web应用风格，但功能和可定制性完全对得起它的开源身份。如果你对这个项目不熟，可以把它理解成一个“自己部署的、长在你自己服务器上的知识管理系统”。

1.2 PVE虚拟化平台带来的管理优势

为什么非要放在 PVE 里，而不是直接装在一台物理机上？原因很简单：PVE 给自托管服务提供了三个核心能力——隔离、快照、迁移。PVE（Proxmox VE）本质是一个基于 Debian 的开源虚拟化平台，你在浏览器里管理虚拟机，可以随时对整台虚拟机做快照和备份。Trilium 这种笔记服务，最怕的就是数据库损坏、升级失败、系统盘炸掉，但在 PVE 里，只要在升级前做一个快照，出问题直接回滚，几乎是零成本止损。这个优势是物理机部署比不了的，也是我推荐“PVE + 虚拟机 + Trilium”组合的根本原因。

另外，个人使用场景下，单独为笔记服务买一台物理机非常浪费。PVE 上可以同时跑软路由、下载机、媒体服务器、监控系统，Trilium 只用给它分配一小部分资源即可。以后如果你想把笔记服务迁移到另一台服务器，直接把虚拟机备份文件拷过去恢复，或者导出笔记zip文件导入，两条路都行。这种“一切尽在掌控”的感觉，才是自托管的真正价值。

2. 部署形态选型：LXC容器、KVM虚拟机、Docker原生二选一

在正式开始操作之前，先花点时间把部署形态想清楚。PVE 里运行一个服务，通常有两条路：LXC 容器，或者 KVM/QEMU 虚拟机。Trilium 本身也有两种安装方式：原生二进制包，或者 Docker 容器。这四个选项组合起来看似很多，其实理清楚之后选择并不难。

2.1 PVE的LXC与KVM虚拟机：笔记服务该怎么选

PVE 的 LXC 容器和 KVM 虚拟机是两种完全不同的虚拟化方式。LXC 容器和你的宿主机共享同一个内核，所以创建速度快、内存占用低，开一个容器可能只占几十MB内存，适合跑那种“装好就能跑、不需要折腾系统内核”的服务。KVM 虚拟机则是一个完整的、独立的操作系统，有自己独立的内核、独立的启动流程，资源占用高一些，但隔离性更好，排障时也更有“真实服务器”的感觉，遇到网络、权限、内核模块这类问题时不会受宿主机牵连。

我把两者的特点整理成了一个简单对比表：

如果你问我个人怎么选，我会推荐 KVM 虚拟机。虽然 LXC 更轻，但 Trilium 属于长期运行、数据价值极高的服务，虚拟机方式的生命周期管理更干净，出了问题也不会影响到同一个宿主机上的其他容器。如果你的PVE内存非常紧张，用 LXC 也不是不行，只是后面配置用户权限和数据目录时要格外注意容器内文件权限和宿主机映射的问题。

2.2 Trilium的两种安装路线：原生Node.js与Docker

安装方式上，Trilium 官网提供的 Linux 二进制包已经内置了 Node.js 运行时，所以“原生部署”其实并不需要你自己安装 Node.js，而是解压、配置、跑起来就行。这条路线的好处是服务就像普通进程一样直接跑在系统里，日志、资源占用、端口监听都一目了然；坏处是升级时要手动下载新包、停服务、替换文件，路径和权限都需要自己维护。

Docker 路线则是把 Trilium 整个装进容器镜像里，数据和配置通过 volume 挂载到宿主机目录。好处是升级变成“拉镜像 + 重建容器”两条命令，数据卷隔离得很干净；坏处是多了一层容器网络，排障时要用docker logs而不是直接看宿主机日志，同时镜像本身是社区维护的，需要关注镜像更新节奏。我在第 5 章和第 6 章会把两条路线都走一遍，你可以根据自己的运维习惯选。如果你不喜欢折腾系统目录，直接跳到第 6 章用 Docker 即可；如果你想彻底搞清楚 Trilium 的运行机制，建议先看第 5 章。

3. PVE中创建Linux运行环境：虚拟机创建的关键步骤

确定了用 KVM 虚拟机之后，下一步就是在 PVE 里把这个虚拟机造出来。这里面的关键不只是“点下一步”，而是你要提前想好资源分配、网络模型和端口规划，否则后面发现问题再改，会牵扯到重新装系统或者改一堆配置。

3.1 准备系统镜像与创建虚拟机

我推荐用 Debian 稳定版或者 Ubuntu Server LTS 作为 Trilium 的操作系统，理由很简单：它们是长期维护版本，安全更新跟得上，而且 Triliium 的部署资料最多。不建议用 CentOS Stream 或者过于激进的新版本，个人笔记服务不差那点新特性，稳定压倒一切。

在 PVE 里操作的第一步是把系统 ISO 上传到存储。进入 PVE Web 界面，找到 Datacenter 或节点下的 local 存储，选择“ISO 镜像”标签页，点击“上传”，把下载好的 Debian ISO 传上去。然后点击右上角“创建虚拟机”，填写 VM ID 和名称，在“操作系统”标签选择刚才上传的 ISO，客户机系统类型选 Linux，版本按 ISO 对应的版本选即可。磁盘大小建议 16GB 到 32GB，原因后面会讲，别抠这点空间。创建完成后启动虚拟机，正常安装系统。安装过程中的分区直接使用整个磁盘，如果只跑 Trilium，不需要手动划分复杂分区。

如果你已经预先配置好了 cloud-init 模板，这一步可以更快：直接在 PVE 里克隆一个 Debian 模板虚拟机，然后在 cloud-init 里设置 IP、用户名和 SSH 密钥。PVE 9.0 和 Debian 13 环境下的 cloud-init 流程已经非常成熟，适合批量创建场景。不过新手第一次跑，走一遍 ISO 安装反而能让你对系统结构更熟悉，所以我这篇以 ISO 安装为主线。

3.2 资源分配建议：CPU、内存、磁盘的合理值

Trilium 是一个典型的 Node.js 单进程应用，资源需求并不高，但也不能给得太抠，否则打开大型笔记或者全文搜索时会明显卡顿。我自己的配置是 2 核 CPU、4GB 内存、32GB 磁盘，运行非常流畅。如果你笔记量不大，2GB 内存其实也能跑，但浏览器端打开大文档时可能会等一两秒。

给你一个参考区间：

磁盘这里我多说一句：Trilium 的文档数据库和附加文件都会落在数据目录里，参加社区活动或者长期收集资料的人，笔记里塞大量截图、PDF 很常见，几个月下来数据增长几个GB一点都不夸张。所以磁盘宁大勿小，而且PVE里给虚拟机扩容磁盘不算太难，但“以后再说”的心态会让你每次扩容都要多一次操作。

3.3 网络模型与端口规划

PVE 里虚拟机默认网卡连接在 vmbr0 桥接网络上，只要宿主机能上网，虚拟机配置好 IP 后局域网就能直接访问。我强烈建议给虚拟机配置静态 IP，而不是 DHCP，否则哪天路由器重启导致 IP 变了，笔记访问入口也跟着变，非常烦人。

端口规划上，Trilium 默认监听 8080 端口，但 PVE 宿主本身占用 8006，同一台宿主上如果还跑着其他服务，8080 很容易冲突。我个人的做法是把 Trilium 监听端口改成一个不常用的高端口，比如 18080，然后以后有需要再用反向代理把 80/443 转发到这个端口。这样既避免了和现有服务吵架，又给未来 HTTPS 方案预留了位置。安装时先规划好端口，后面防火墙和 systemd 配置都会顺很多。

4. Linux系统初始化：环境准备与安全基线

虚拟机装好系统、能 SSH 登录之后，别急着下载 Trilium。先把系统的底子打牢，否则后面权限、防火墙、SSH 安全问题会让你反复折腾。这一章的步骤不多，但每一条都值得做。

4.1 更新系统与安装常用工具

第一步永远是更新系统。Debian/Ubuntu 系执行：

apt update && apt upgrade -y

然后安装几个后面一定会用到的常用工具：

apt install -y curl wget git vim htop ufw rsync ca-certificates

这些工具看着普通，但实际用起来全是必需品：curl 和 wget 用来下载 Trilium 安装包，vim 用来编辑配置文件，htop 看系统负载，ufw 做防火墙，rsync 做手动数据同步。如果你用的是最小化安装，缺了这些工具到后面会非常难受。

4.2 创建专用运行用户与目录结构

Trilium 虽然在笔者的测试环境里很稳定，但任何 Web 服务都有被攻击的可能。不要用 root 用户去跑 Trilium，这是自托管服务的第一原则。创建一个专用账号，把权限收窄：

useradd -r -s /usr/sbin/nologin trilium mkdir -p /opt/trilium /var/lib/trilium chown -R trilium:trilium /opt/trilium /var/lib/trilium

这里的目录规划是：可执行文件放/opt/trilium，数据目录放/var/lib/trilium。为什么要把程序和运行数据分开？因为备份时你只需要备份数据目录，升级时只需要替换程序目录，两者混在一起会平添很多麻烦。后面配置 systemd 时，只需要让服务以trilium用户运行，目录读写权限就限制在合理范围内，万一日后有安全问题，攻击者也拿不到系统 root。

4.3 SSH加固与防火墙配置

接下来做基本安全配置。如果你的虚拟机只暴露在局域网，SSH 加固可能没那么紧迫，但我个人习惯是能加固就加固，反正成本极低。编辑/etc/ssh/sshd_config：

PermitRootLogin prohibit-password PasswordAuthentication no

然后重启 SSH 服务。注意，如果禁用密码登录，你一定要提前把公钥加到~/.ssh/authorized_keys，否则会把自己锁在门外。如果你是新手、还在学习阶段，可以先保留密码登录，等以后熟练了再改，不要一开始就给自己制造障碍。

防火墙方面，Debian/Ubuntu 自带 ufw，配置很简单：

ufw allow OpenSSH ufw allow 18080/tcp ufw enable

这里只放行 SSH 和未来 Trilium 要用的端口。PVE 上的其他虚拟机访问这个服务时走局域网 IP 加端口即可，不需要额外打开不必要的入站端口。做完之后用ufw status确认规则，这个自检动作会让后面省心很多。

5. Trilium安装实录：原生Node.js部署步骤

原生部署 Trilium，重点就三件事：下载对的包、把端口和数据目录配好、用 systemd 变成常驻服务。本意上它和部署一个静态程序很像，但因为涉及数据库文件，所以每一步我都尽量解释清楚为什么。

5.1 下载Trilium发行包与版本选择

去 Trilium 的 GitHub Releases 页面，找到最新的trilium-linux-x64-版本号.tar.xz安装包。这里特别提醒一句：千万不要图新鲜下载 nightly 版本，除非你愿意陪它一起经历未知 bug。个人笔记这种工具，稳定版永远是首选。

下载并解压到/opt/trilium：

cd /tmp wget https://github.com/zadam/trilium/releases/download/v0.63.7/trilium-linux-x64-0.63.7.tar.xz tar -xJf trilium-linux-x64-0.63.7.tar.xz mv trilium-linux-x64 /opt/trilium chown -R trilium:trilium /opt/trilium

上面版本号v0.63.7只是示例，实际版本请以 Release 页面的最新稳定版为准。这个发行包里面已经带好了 Node.js 运行时，你不需要、也不应该在系统里再装一套 Node.js，这正是官方二进制包最省心的地方。

5.2 配置数据目录与启动参数

Trilium 支持用环境变量覆盖默认配置，其中最常用的是TRILIUM_DATA_DIR和TRILIUM_PORT。TRILIUM_DATA_DIR指定数据目录，TRILIUM_PORT指定监听端口。你也可以在数据目录的config.ini里写：

port=18080

但我个人更推荐用环境变量，因为这样所有配置都集中在 systemd 服务文件里，换机器、备份、排查时一眼就能看出服务当时是怎么启动的。

首次启动时，Trilium 会在数据目录里自动生成配置文件和 SQLite 数据库文件。默认情况下数据目录下就是一个document.db文件，这个文件包含你所有笔记内容。SQLite 对个人笔记场景完全够用，不需要一开始就上 PostgreSQL；等到你的笔记规模真的到了上万篇、需要多人并发编辑时，再迁移数据库也不迟。那时再考虑 PostgreSQL 也不难。

5.3 systemd服务化与开机自启

手动前台启动 Trilium 很容易，但真正要让它成为“服务”，必须交给 systemd 管理。创建/etc/systemd/system/trilium.service文件：

[Unit] Description=Trilium Notes Server After=network.target [Service] Type=simple User=trilium Group=trilium Environment=TRILIUM_DATA_DIR=/var/lib/trilium Environment=TRILIUM_PORT=18080 WorkingDirectory=/opt/trilium ExecStart=/opt/trilium/trilium.sh Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl enable --now trilium systemctl status trilium

看到active (running)就说明服务起来了。这时候打开浏览器，访问http://虚拟机IP:18080，第一次访问会让你设置管理员账号和密码。到这里，Trilium 的核心部署就算完成了。接下来如果你只是在本机或局域网用，直接开始记笔记即可。

6. Docker Compose路线：适合喜欢容器化的朋友

如果你看到上一章那一堆 systemd 配置就头疼，或者你本来就习惯用 Docker 管理一切服务，那可以直接走 Docker 路线。这条路线会把服务抽象成一个容器，数据单独挂载，升级重建容器即可，非常清爽。

6.1 在Linux中安装Docker与Compose

Debian/Ubuntu 上安装 Docker，最简单的办法是官方脚本：

curl -fsSL https://get.docker.com | sh systemctl enable --now docker

这个脚本会自动安装 Docker Engine 和 Compose 插件，装完以后可以用docker --version和docker compose version验证。有些朋友不喜欢curl | sh这种方式，你也可以用apt install docker.io docker-compose-v2，效果类似，只是版本可能稍微旧一点，但稳定性足够。Trilium 不是那种需要最新 Docker 特性的应用，所以不用刻意追新。

6.2 docker-compose.yml示例与数据卷设计

Trilium 官方没有推自己的 Docker 镜像，社区里使用最广的是nriver/trilium。我的目录结构是这样：

/opt/trilium-docker/ ├── docker-compose.yml └── trilium-data/

docker-compose.yml内容如下：

services: trilium: image: nriver/trilium:latest container_name: trilium restart: unless-stopped ports: - "18080:8080" volumes: - /opt/trilium-docker/trilium-data:/root/trilium-data environment: - TRILIUM_DATA_DIR=/root/trilium-data

启动命令：

cd /opt/trilium-docker docker compose up -d

注意容器内默认数据目录路径是/root/trilium-data，所以我把宿主机目录挂载到这个路径。如果镜像更新后默认路径有变化，以镜像文档为准。数据卷的好处是：你删掉容器重建，只要不动trilium-data目录，笔记数据就不会丢。这也是 Docker 路线最大的安全感来源。

6.3 原生部署与Docker部署的取舍经验

两条路线我都实际跑过，给你一个最直观的对比：

原生部署适合想搞懂原理的人。日志直接看journalctl -u trilium，端口监听用ss查，所有东西都在系统进程树里一目了然，出问题排障最直接。代价是升级时你得自己下载新包，停服务，替换文件，再启动。Docker 部署则适合“不想花太多精力维护”的人，升级就是改镜像版本号加两行命令，数据卷隔离降低误操作风险，但排障时会多一层容器封装，习惯用docker logs之后也没什么障碍。

我的建议是：如果这台虚拟机上你还打算跑别的自托管服务，干脆全部走 Docker，统一管理；如果只是纯粹给笔记开一个专用虚拟机，原生部署也挺好，毕竟维护这一个服务的工作量并不大。

7. 备份、恢复与升级：笔记服务长期可用的保障

部署完成只是开始，真正体现自托管服务质量的，是备份恢复和升级。Trilium 这种笔记工具，存的是你积累的知识和想法，丢了比系统崩溃还难受，所以这一章的优先级其实比任何功能配置都高。

7.1 Trilium自带备份机制与手动导出

Trilium 自带的备份机制有两层。第一层是数据目录里的自动备份，它会在backup目录下定期生成数据库备份文件，备份间隔可以在配置里调整。第二层更简单的备份方式，是直接在 Trilium 界面的设置页找到“Backup”按钮，点一下就会下载一个包含全部笔记的 zip 文件。这个 zip 适合手动导出，也适合迁移到另一台设备时导入。

别只依赖自动备份。我个人的固定习惯是：每周手动导出一份 zip，存到 PVE 宿主机的备份目录或者另一台机器上。为什么？因为自动备份文件和 Trilium 在同一个数据目录里，如果虚拟机系统盘本身坏了，两者会一起遭殃。手动导出一份放在系统外的备份，才是真正的“逃生通道”。

7.2 PVE层的整机备份（vzdump）

PVE 对虚拟机做整机备份是最值得利用的功能。在 PVE Web 界面的 VM 备份页可以选择立即备份或创建备份计划，默认会生成一个 vma 格式的压缩备份文件，里面包含整台虚拟机的磁盘内容。这意味着连操作系统、Node.js 运行时、Trilium 程序、全部配置和数据都一起备份了。万一系统崩溃或升级失败，你不需要重新装系统，直接恢复 VM 镜像即可。

有一点需要注意：虚拟机运行时执行 Backup，等于在“活着”的状态下拷贝磁盘文件，虽然 PVE 能保证磁盘层面的数据一致性，但应用层比如数据库可能处于写入中，极端情况下恢复后可能丢掉最后几秒的数据。最稳妥的办法是先在虚拟机里systemctl stop trilium，备份完成再启动；如果不想停服，可以开启 QEMU Guest Agent 并配置文件系统冻结，让备份做到应用级一致。个人使用场景下，数据丢失几秒钟可以接受，我一般直接在线备份，省事。

7.3 从备份恢复与升级的实操流程

手动 zip 备份的恢复很简单：在 Trilium 设置页选择“Import”，选中你保存的 zip 文件，导入后笔记树就能恢复回来。vzdump 备份的恢复更快：在 PVE 的存储里找到备份文件，点恢复，指定一个新的 VMID，等它跑完就能开机。两条路覆盖的场景不同，我建议两个备份机制都保留，互为兜底。

升级流程上，原生部署最稳的做法是：

systemctl stop trilium cp -r /var/lib/trilium /var/lib/trilium.bak # 下载新版本包并解压到 /opt/trilium systemctl start trilium

Docker 部署的升级则简化为：

docker compose pull docker compose up -d

升级之后一定别忘了做验证：打开网页，登录，搜索一篇旧笔记，看看附件和主题是否正常。很多升级问题要等实际用起来才会暴露，光看服务状态是测不出来的。

8. 让Trilium更顺手：HTTPS反代、自定义主题与多端同步

基础服务跑起来之后，很多人会想让它更好用一些。这里我分享三个使用率最高的进阶操作：HTTPS访问、自定义界面、多设备同步。这些配置不是必须的，但做完了之后，Trilium 的可用性会上一个台阶。

8.1 用Caddy开启HTTPS与域名访问

如果 Trilium 只在局域网访问，那 IP 加端口是最简单的方案。但如果你给它绑定了一个域名，或者需要从办公室、在外网访问，那就应该用反向代理开启 HTTPS。我推荐 Caddy，原因是配置极简，它会自动申请和管理 Let's Encrypt 证书，省掉了 Nginx 那套证书续期流程。

在另一台 Linux 上安装 Caddy，然后写一个 Caddyfile：

note.example.com { reverse_proxy 192.168.1.10:18080 }

把域名和虚拟机 IP 替换成你自己的，然后caddy reload。Caddy 会自动为note.example.com申请证书，之后用 HTTPS 访问这个域名就能打开 Trilium。这里有一个我自己的原则：任何暴露到公网的服务，至少要有两个安全措施——强密码认证和 HTTPS。Trilium 自带密码登录和 TOTP 双因子认证，如果你打算公网访问，在设置里把二步验证打开，别偷懒。

8.2 自定义主题：让界面变成自己的风格

Trilium 的自定义能力很强，入口在“选项 → 外观 → 自定义CSS/自定义JS”。你可以在这里写全局 CSS 来改变字体、颜色、行距，也可以从社区下载其他人写好的主题。不少玩过“trilium自定义主题”的朋友都是从改一个字体开始的，比如想让正文更宽松：

.note-content { line-height: 1.8; font-size: 16px; }

实际生效的 class 名称可能会随版本改动，建议你用浏览器开发者工具先选中目标元素，再写自定义 CSS。自定义 JS 则可以做一些快捷键或界面微调。主题只是前端内容，不影响后端数据，可以随便折腾，大不了重新清空代码恢复默认。

8.3 多设备访问与同步方案

Trilium 自带同步机制，支持一台主实例和多个从实例。如果你有台式机、笔记本，可以把主实例放在 PVE 虚拟机上，在设置中开启同步并设置同步密码，其他设备安装 Trilium 桌面端，填写主实例的地址、账号和密码，就能把笔记树同步到本地。这样即使你在没有网络的地方，也能用桌面端浏览和编辑笔记，联网后再同步。

这里要强调一下：Trilium 的同步更偏向“单用户多设备”，不是 Notion 那种多人实时协作工具。手机端虽然有 Web 界面可以浏览，但官方 App 体验一般。所以我的用法是：主力编辑在电脑浏览器或桌面端，手机端偶尔查资料用网页凑合一下。如果你手机上访问比较频繁，可以考虑直接用 PWA 或单纯把网页添加到主屏幕，至少比在浏览器里输完整地址强。

9. 实测踩坑记录：排障思路与最终自检

部署一套服务，不踩几个坑是不完整的。我自己在部署和维护 Trilium 的过程中，遇到过一些很典型的坑，这里把完整的排障思路分享出来，希望你能少走我走过的弯路。

9.1 最常见的三类故障与排查链路

第一次部署时最常遇到的问题是“页面打不开”。我的排查链路是这样的：先在虚拟机里执行systemctl status trilium，确认服务有没有在运行；然后执行ss -lntp | grep 18080，确认端口有没有监听；接着在虚拟机内curl 127.0.0.1:18080，再在宿主机或局域网电脑上curl 192.168.1.10:18080。如果虚拟机内能通、外部不通，基本就是防火墙问题，执行ufw status检查 18080 有没有放行。如果服务根本没起来，就journalctl -u trilium -e看日志，权限错误会在里面直接看到。

第二类典型问题是数据目录权限错误。现象是启动日志里出现EACCES: permission denied，或者页面能开但写不了笔记。原因大多是我在 5.1 节那样的操作流程里，某个目录没有正确chown给trilium用户。修复很简单：chown -R trilium:trilium /var/lib/trilium /opt/trilium，然后重启服务。这个坑出现频率很高，但排查成本极低。

第三类是升级后登录异常或数据库迁移报错。比如日志里出现“schema version”相关的错误，通常是因为你从稳定版跳到了不兼容的版本，或者从经典版切换到社区分支 TriliumNext 时没做数据迁移。解决办法是回滚到升级前的备份，先恢复数据再按官方文档执行迁移。这也侧面说明了一个道理：升级前不做快照，等于拿自己的笔记数据当小白鼠。

9.2 备份体积膨胀与数据库清理

Trilium 的自动备份是整库打包，如果你的笔记里塞了大量图片、PDF，备份体积会随着时间逐渐膨胀，甚至比你实际数据还要大好几倍。我的对策是定期清理backup目录里的旧文件，只保留最近几份；同时在笔记里尽量使用压缩后的图片，不是每个截图都要原图。如果文档量真的到了几万篇以上，SQLite 仍然扛得住，但这时候建议你把自动备份间隔调长一点，或者干脆迁移到 PostgreSQL。普通个人笔记用户远不需要担心这个级别的问题，但有备份策略的意识，是从新手进阶到老手的标志。

9.3 部署完成后的自检清单

最后给你一个部署完成后的自检清单，照着过一遍，基本能确认服务状态健康。

这些检查项里，最容易忽略的是“备份验证”。很多人创建了备份计划就再也不管了，直到要恢复时才后悔备份文件早就写坏了。我的经验是：每季度至少做一次“演练式恢复”，在另一台临时虚拟机上把备份恢复起来，确认数据可用。这听起来像在给自己找事做，但真到救命那一步，你会感谢自己当初多花的那十几分钟。