Zerobyte：基于 Restic 的自托管备份自动化工具

如果你直接用 restic 备份，排程、保留策略，以及确认“昨晚的任务到底有没有成功”，通常都要靠你自己维护的脚本。Zerobyte 是基于 Restic 的备份自动化工具：加密、压缩、去重和保留策略仍由 Restic 完成，它在上面加了一层网页界面，把备份拆成三类对象：卷（要备份的来源）、仓库（备份存放的位置）和备份任务（何时运行、用什么参数）。GitHub 上该仓库在 2026 年 11 月 10 日显示 7,302 颗星，最新版本为 v0.44.2。

截图来自项目 README。每张卡片是一个备份任务，排程以 cron 表达式显示，例如 00 02 * * * 表示每天凌晨 2 点。截图中的日期不代表当前运行状态。

核心功能

• 多种备份来源：卷可以是 NFS、SMB、WebDAV 或 SFTP 共享，也可以是本地目录。README 把卷定义为“要备份和监控的源数据”。
• 多种存放位置：仓库支持 S3 兼容存储（README 举了 Amazon S3、MinIO、Wasabi、DigitalOcean Spaces 等）、Google Cloud Storage、Azure Blob Storage，以及通过 rclone 接入的 40 多家云盘服务。
• 排程与保留策略：备份任务既设定运行频率，也设定保留哪些快照。README 的示例是每日备份保留 7 天、每周备份保留 4 周。排程依赖容器里的 TZ 时区设置，README 把它称为“对准确排程至关重要”。
• 进度与通知：Backups 页面显示每个任务的进度和状态。备份前后可以调用 webhook，通知可以发到 ntfy、Slack、Discord、Pushover 或 Telegram。
• 可调的 Restic 参数：任务可以附加自定义 Restic 参数，README 的例子是 --read-concurrency 1 和 --exclude-larger-than 10G。环境变量 GOMAXPROCS 可以限制 Restic 的线程数，README 建议用它降低备份时的 CPU 压力。

典型使用场景

• 家用服务器或 NAS 用户：把 SMB 或 NFS 共享每天备份到 S3 兼容存储，并套用 README 示例的保留规则。
• 管理几台机器的人：每台机器的数据目录建成一个卷，都写入同一个存储后端，在一个网页里查看每个任务最近是否跑成功。
• 已经在用 rclone 的人：README 说明了如何把 rclone 配置目录挂载进容器，之后就能把备份写到 Google Drive、Dropbox 或 OneDrive 等云盘。

快速上手

README 的做法是先准备一个 compose.yaml，里面设置 APP_SECRET（用 openssl rand -hex 32 生成）、BASE_URL 和 TZ。文件准备好后，在该目录运行：

docker compose up -d

然后访问 http://<服务器 IP>:4096。README 的示例 compose 里还有 SYS_ADMIN 能力和 /dev/fuse 设备，修改前先确认它们与你的环境是否相符。数据目录 /var/lib/zerobyte 不要指向网络共享，README 提醒这会造成权限问题，并明显拖慢性能。

小结

适合：有好几个备份来源、想用一个网页统一管理 Restic 任务的自托管用户。不太适合：只备份一台机器、习惯命令行脚本的人，或者需要细粒度权限控制的团队。

README 写了三条需要先读完的提醒。第一，项目仍处于 0.x 版本，版本之间可能有较大改动。第二，备份操作目前没有细粒度 RBAC，已认证的组织成员都被视为可信操作者。第三，不建议把服务直接暴露在公网上；如果必须暴露，应把端口绑定到 127.0.0.1，再通过带认证的隧道访问。

社区评测（bitdoze 的一篇评测和 restic 论坛的讨论）把它与同样基于 Restic 的 Backrest 放在一起比较：多卷、多来源的集中管理更适合 Zerobyte，单人、靠近数据的小界面更适合 Backrest。这是评测者的看法，不是项目方的对比。

许可证为 AGPL-3.0，主要语言为 TypeScript。只在自己的机器上运行且不改代码时，AGPL 不额外要求什么；如果修改后对外提供网络服务，需要向用户提供修改后的源码。如果你更关心文件的实时同步而不是备份，可以对照 Syncthing：它做设备间的直接同步，Zerobyte 做的是有快照、有保留策略的加密备份。