1. 为什么要做这个客户端命令行备份的日常与痛点1.1 restic 有多好用就有多“劝退”先交代一下背景。我一直用 restic 做私人和工作文件的备份这个工具是用 Go 写的开源备份程序核心卖点就三个加密、去重、多平台。加密是仓库级别的 AES-256去重是内容定义的块级去重也就是说你备份两个几乎一样的目录第二次跑基本上秒完因为只有新增或修改的块会被真正写进仓库。多平台这个没什么好说的macOS、Linux、Windows 都能跑仓库格式统一我在公司 Linux 机器上备份的数据拿回家里 Mac 上照样能恢复。命令行用起来确实很爽基本的备份流程就两条命令# 初始化仓库 restic -r /Volumes/Backup/restic-repo init # 执行备份 restic -r /Volumes/Backup/restic-repo --password-file ~/.restic-pass backup ~/Documents但问题也恰恰出在“命令”这两个字上。restic 的命令体系相当完整backup、restore、snapshots、mount、forget、prune、check、key、cache、cat 等等每一个还带一票子参数。你要是不看文档光是搞明白--keep-last、--keep-daily、--keep-weekly这几个保留策略参数之间的配合就得花不少时间。我给我同事推荐了好几次每次都是“挺好的工具但命令行太麻烦了”收场。我自己用倒是没问题但家里另一台 Mac 是我对象在用的总不能让每个人都去记restic backup --exclude-file...这种命令吧。备份这种事最核心的诉求就是“静默可靠地发生”而不是每天逼着人打开终端敲命令。1.2 Mac 生态里缺一个“零配置”的备份入口说句实话macOS 自带 Time Machine 做得已经不错了但它有几个我接受不了的问题。第一它是整机级快照备份粒度太大我想单独备份某个工作目录Time Machine 帮不上忙第二Time Machine 的备份格式只有 macOS 自己能读如果我要换平台或者想借助对象存储做异地容灾它基本没戏第三当外接硬盘连上之后Time Machine 有时候会在系统负载比较高的时候自己跑起来体验就一个字吵。还有人可能觉得 iCloud 云盘也算备份这里我必须多说一句云盘同步不等于备份。如果某天你手滑误删了文件同步盘会在几秒钟之内把所有设备上的同一份文件全部删掉。我见过太多这种案例了最后只能靠“恢复历史版本”的功能碰运气而很多云盘的历史版本保留时间是有限的。真正的备份应该像 restic 这种每次备份生成一个不可变的快照删除操作不会反向传染到历史快照里边。所以在 Mac 上做一个 restic 菜单栏客户端对我来说几乎是顺理成章的需求。菜单栏是 macOS 里最“安分”的常驻位置不会占据 Dock 位置也不会在 CommandTab 切换里出现放一个备份小图标再合适不过。客户端要解决的问题很清楚让人不用碰命令行也能完成“初始化仓库—配置备份目录—定时备份—查看快照—恢复文件”这一整条链路。而且我的想法很明确它就是一个 restic 的前端外壳不是要重写一个备份引擎restic 本身足够成熟我只管把交互做好。这个项目完全免费开源代码放在 GitHub 上见者有份。所以我才想把这篇文章写下来把技术选型、核心实现、踩过的坑都摊开说说给想做类似菜单栏工具的人一个参考。2. 技术选型与整体架构给 CLI 套一个原生外壳2.1 菜单栏应用的三种做法为什么选了 SwiftUImacOS 菜单栏应用的主流做法有三条路Electron、PyObjC、SwiftUI/AppKit。Electron 我不太想碰一个备份工具常驻内存打开活动监视器一看光一个壳子就要吃几百 MB 内存和一个完整的 Chromium 进程这放在一个本该“轻量低调”的菜单栏应用上属实有点荒谬。PyObjC 的好处是写起来快但分发的时候要么打包成 app要么让用户用 pip 装依赖对普通用户来说门槛反而更高而且纯 Python 做出来的菜单栏交互细节始终感觉差那么一口气。最终我选了 SwiftUI。macOS 13 开始SwiftUI 提供了原生的MenuBarExtra控件可以直接把视图挂到菜单栏上不用再手动创建NSStatusItem。如果你还在用老系统比如 macOS 12 或者更早那MenuBarExtra就用不了只能用 AppKit 的NSStatusItem来兜底。我的做法是写一个很薄的兼容层系统是 macOS 13 就走MenuBarExtra否则走NSStatusItem SwiftUI 的NSHostingView来承载界面。这里有一个关键的信息性配置菜单栏应用没有 Dock 图标也没有顶部菜单栏需要在 Info.plist 里设置LSUIElement YES。设置完之后应用启动后只会在菜单栏显示图标CommandTab 里也看不到它。这个属性在开发阶段尤其重要因为它决定了一个纯粹常驻型工具的整体体验特别是用户可能长时间开着它如果每次都弹 Dock 图标很快就会烦到卸载。选 SwiftUI 还有一个实际好处状态管理方便。备份这种任务本质上就是“状态机”——空闲、备份中、备份完成、备份失败、正在恢复——用Published属性加ObservableObject可以很自然地驱动界面更新。菜单栏标题实时显示备份进度百分比就靠这一套机制。2.2 整体架构GUI 壳 restic 子进程整个应用的架构用一句话概括就是“GUI 壳 restic 子进程”。应用本体不做任何备份逻辑只负责收集参数、调用restic命令、解析输出、展示结果。为什么不是把 restic 作为 Go 库直接编进来我自己也认真考虑过这个问题restic 的源码里其实有restic/repository这种包理论上可以在 Go 里直接调用但这么做有几个麻烦。第一个麻烦是升级。restic 迭代速度很快修 bug、新增后端支持、优化 prune 算法这些事情都发生得很频繁。如果我把它作为 Go 库编进我的二进制里每次 restic 发新版本我都要重新拉源码、重新编译、重新分发。但如果我只是调用命令行工具用户完全可以通过 Homebrew 独立升级restic我的应用只需要在启动时检查一下 restic 版本就行。第二个麻烦是 CLI 本身就是稳定的接口。restic 提供了--json输出模式机器可读解析成本低而且客户端将来如果想支持新的 restic 功能比如某种新后端只要新版本的 restic 命令出来了我的客户端不需要跟着发版就能用。这种设计最省心。应用内部的分层大概是这样的最底层是ResticRunner负责拼接参数、启动Process、处理 stdout/stderr中间层是BackupService和SnapshotService负责把命令行数据转化为 Swift 的数据模型最上层是 SwiftUI 的菜单栏视图。数据流是单向的界面触发一个动作服务层启一个异步任务任务结束后把结果发回MainActor上的状态对象UI 自动刷新。简单、直接、不容易出并发问题。2.3 关键参数设计仓库、排除规则、保留策略菜单栏客户端虽然追求零配置但备份这件事天然需要几个核心参数我把它们设计成了用户可以随时调整的配置项。仓库地址是第一个必须让用户指定的参数。restic 支持本地目录、SFTP、S3、Azure、Google Cloud、Backblaze B2、REST server 等等客户端里我提供两种最常见的入口一种是直接填路径比如/Volumes/Backup/restic-repo另一种是填 sftp 或 s3 的 URL。为了不引入过多配置复杂度对象存储的密钥对我没有做成复杂的表单而是直接把“环境变量”透传给了 restic 子进程这样一来无论用户用什么后端只要他在配置文件里把对应的环境变量写出来客户端就能工作。排除规则是备份场景里特别容易踩坑的地方。大多数人的第一个备份任务跑完之后发现仓库容量吓人往往是因为把node_modules、.git、缓存目录、虚拟机磁盘镜像这些不需要备份的东西全塞进去了。我在客户端里内置了一批默认排除项包括.git、node_modules、__pycache__、.DS_Store、Library/Caches这类明显不需要备份的目录同时开放了一个规则编辑器用户可以自己加通配符。这里有一个细节值得专门说必须把仓库自身的路径排除掉。否则备份目录包含仓库目录时restic 会把仓库里已有的加密包文件再次读进来产生无意义的数据膨胀严重时会让备份时间成倍增加。这个坑我初期就踩过所以后来干脆在 UI 上做了硬性提示发现仓库路径在备份范围内时直接警告。保留策略我给了用户三档预设轻量、标准、稳妥。轻量对应--keep-last 3 --keep-daily 3 --keep-weekly 2 --keep-monthly 2适合磁盘空间紧张的用户。标准对应--keep-last 5 --keep-daily 7 --keep-weekly 4 --keep-monthly 12适合大多数个人用户。稳妥则是--keep-last 10 --keep-daily 14 --keep-weekly 8 --keep-monthly 24适合对历史版本有较长回溯需求的用户。这三档对应的就是restic forget的参数组合客户端只是把它翻译成命令并没有做任何魔法。3. 核心功能拆解与实现细节3.1 初始化仓库与“三步上手”交互首次启动的引导流程我做了三个步骤选仓库、选备份目录、设置密码。这三个步骤的设计顺序是有讲究的先定仓库再选数据目录是因为 restic 的本地仓库本质上是一个目录它必须先被初始化备份才有去处。第一步仓库配置界面上是一个下拉框里面列出“本地文件夹”、“SFTP 远程目录”、“S3 兼容对象存储”三个选项。本地文件夹直接用NSOpenPanel让用户选一个目录拿到的路径就是仓库地址。SFTP 和 S3 的字段稍微多一点需要用户填地址、用户名、bucket 名这些信息。为了不让界面一开始就显得吓人我把后两个选项默认折叠起来用“高级”标签包住。第二步选备份目录这步可以使用NSOpenPanel的多选模式用canChooseDirectories true和canChooseFiles false把范围限定在目录。用户选完目录之后我立刻在后台跑一次restic cat config来探测仓库是否可访问如果仓库不存在界面会提示“这是一个全新的仓库点击下一步将自动初始化”。这样用户不用理解restic init的含义只需要知道“我选择了备份目的地”就行。第三步设置密码这部分直接决定后续所有备份的安全性。restic 的仓库密码用 AES-256 加密保护没有密码等于没有备份。我把密码输入框做成允许用户选择“记住到钥匙串”的选项默认是勾选的。一旦选了记住密码就会写入 macOS Keychain后续备份不需要再次输入。如果用户不想存客户端会在每次执行备份前弹窗询问虽然更安全但日常使用会很啰嗦所以我鼓励大部分用户直接存钥匙串。初始化动作本身其实就是一条命令restic -r /path/to/repo init --repository-version 2需要说明的是--repository-version 2这个参数restic 仓库从 v1 升级到 v2 之后重写和删除操作的效率有明显提升新库建议直接创建为 v2省得以后迁移。客户端默认加上这个参数除非用户明确在高级设置里把它关了。3.2 备份任务怎么跑输出怎么解析备份是核心中的核心实现上必须处理好三个问题参数拼接、子进程输出解析、并发控制。restic 备份命令的基础形态是restic -r repo --json backup path1 path2 --exclude... --exclude...但这里有个细节多个排除规则不能在命令行里用--exclude a --exclude b这种逗号合并的方式传递必须一个--exclude对应一个值。如果用户自定义了 20 条排除规则命令参数里就有 20 个--exclude。这个处理在 Swift 里并不复杂用一个数组往参数列表里 append 就行。真正麻烦的是环境变量和密码传递。我用Process启动 restic 时会设置environment为当前进程的环境变量的带继承副本然后额外注入RESTIC_REPOSITORY和RESTIC_PASSWORD。密码从 Keychain 取出后直接放到环境变量里这样 restic 子进程能拿到密码而密码也不会出现在任何命令行参数列表中进程列表ps aux能看到完整命令参数所以正确答案一定是环境变量或密码文件不能是--password-file路径指向一个临时明文文件那个文件一旦被人看到就完了。环境变量方案当然也不是绝对安全同一用户权限下别的进程理论上可以读/proc或等效接口获取另一个进程的环境但在 macOS 的日常威胁模型下这个风险基本可以接受。如果你追求更高安全等级restic 还支持--password-command客户端可以调用一个 helper 脚本来动态获取密码这个我在高级设置里也做了不过默认不开启。子进程的输出解析必须用--json模式这一点非常重要。如果不开--jsonrestic 的输出是带 ANSI 颜色、进度条、百分比回车的文本机器解析起来会疯掉。开了--json之后restic 的 stdout 就是一行一个 JSON 对象每个事件都带message_type字段。做备份时最关心的是两种事件status和summary。status事件大概长这样{message_type:status,percent:37.5,total_files:1284,files_done:473,total_bytes:2147483648,bytes_done:805306368}这个事件在备份过程中会持续输出我用它来更新菜单栏标题。summary事件在备份结束时输出里面包含files_new、files_changed、total_bytes_processed、snapshot_id等字段用来在界面里展示“本次备份新增了多少文件、多少数据”和最终生成的快照 ID。实现上我使用Pipe来读取 stdout用readabilityHandler持续把数据追加进一个 buffer每次读到换行符就尝试解析一行 JSON解析成功就根据message_type分发到对应的状态处理函数。这里有个比较容易踩坑的点readabilityHandler是在子线程上被调用的绝对不能直接在主线程改 SwiftUI 状态必须把解析出来的状态数据用Task { MainActor in ... }包装一下再更新 UI否则你会得到一堆 “Publishing changes from background threads” 的运行时警告甚至直接崩溃。并发控制相对简单我用一个BackupState枚举加Published var currentTask: BackupTask?来标记当前是否有备份在跑。定时任务和手动点击备份按钮都会先检查这个状态非空就直接返回并且菜单项置灰。restic 仓库本身就带锁机制同一时间只允许一个写进程即使客户端这边判断漏了仓库锁也会自动挡掉第二个备份这点 restic 做得还是挺让人放心的。3.3 快照浏览、文件级恢复与挂载备份做完用户最关心的是“我能不能找到我要的文件并恢复”。restic 的快照列表可以用一条命令拿到restic -r repo --json snapshots返回的 JSON 是一个数组每个元素包含id快照短 ID、time、hostname、paths、tags等字段。我在界面里用一个列表把这些快照展示出来按照时间倒序排列每条显示备份时间和包含的目录路径用户选中某一条之后可以进一步看到这次快照的统计信息。文件级恢复是我实现得比较小心的一个功能。restic 提供了restore命令可以恢复整个快照也可以恢复指定路径。如果用户只是误删了一个文件恢复整个快照再把文件拷出去成本太高了。所以我的界面里做了一个“浏览快照”的入口点击之后实际上调用的是restic -r repo ls snapshot-id --jsonls命令会列出快照里的所有文件路径我用一个树形列表展示用户勾选想恢复的文件就能生成对应的 restore 命令restic -r repo restore snapshot-id --include selected-file-path --target user-chosen-destination这里--include可以指定一个路径前缀restic 会只恢复匹配的文件快照体量大时恢复速度会快很多。还有一个经常被问到的功能是挂载。restic 支持restic mount把仓库挂载成一个只读文件系统然后用 Finder 像浏览普通文件夹一样浏览历史快照。理论上这是最直观的恢复方式但 macOS 上mount依赖 FUSE需要用户预先安装 macFUSE 这个第三方内核扩展。内核扩展这种东西有的用户会因为安全顾虑不愿意装有些企业环境会限制所以我没有把 mount 做成默认功能而是放在“高级”菜单里。用户如果已经装了 macFUSE点一下“挂载最新快照”就能在/Volumes/restic-mount下看到按快照 ID 命名的目录。没装 macFUSE 的用户我就在界面上给一个“如何安装 macFUSE”的引导但不会逼着他们装。3.4 定时备份与电源策略定时备份是菜单栏工具能不能“省心”的关键。我用一个Timer在应用内部调度最小间隔支持 15 分钟、30 分钟、1 小时、6 小时、每天五个挡位。每次触发时检查三件事当前是否有备份在跑、上一次备份是否失败过太多次、以及电源适配器是否连接。前两个条件都好理解第三个条件可能有人会问为什么备份还要关心插没插电因为备份任务会持续读取大量文件在 MacBook 上跑起来功耗明显升高如果用电池跑轻则电池掉得飞快重则在系统负载高的时候拖慢其他应用。我做的策略是如果是笔记本且未插电定时任务自动推迟菜单栏图标上显示一个“待机”小标记插上电之后马上补跑。这个策略个人用下来觉得非常舒服相当于把 macOS 的电源感知和备份需求结合在了一起。备份间隔的实现上没有用launchd的StartInterval因为launchd是系统级的如果应用已经退出了定时任务还是会被系统拉起这时候没有 GUI 也无所谓但我并不希望养一个用户不可见的后台进程在偷偷备份这会引发很多隐私信任问题。用应用内 Timer 的好处是应用退出定时就停了“备份要用户自己在菜单栏点开过”这个隐含约定反而能给用户安全感。当然应用内 Timer 有个缺点如果 Mac 一直休眠Timer 不会执行。我的解决办法是在applicationDidBecomeActive或者菜单栏点击时检查“距上次备份时间”如果超过预设间隔且当前满足备份条件就自动触发一次补备份。这套逻辑等同于“调度 补跑”很大程度上弥补了 Timer 的盲区。4. 安全设计与误操作防护4.1 加密密钥怎么保存Keychain 与环境变量的取舍restic 的仓库密码是数据的唯一保险如果丢了任何快照都解不开。所以客户端在保存密码这件事上不能马虎。我把密码写入 macOS Keychain用SecItemAdd和SecItemCopyMatching来读写服务名写死成com.example.resticmenuAccount 字段记仓库地址。每次执行备份前从 Keychain 读出来再放到子进程的环境变量里。这个方案的好处是密码不会出现在任何配置文件里而且 Keychain 的数据本身是加密存储、受系统保护别的普通应用读不到。有人可能会说“存钥匙串不是等于没设密码吗”这个观点我部分同意。钥匙串里的密码在用户已登录的情况下可以被同用户的进程读取和 SSH key 的保存逻辑类似。如果你对安全等级有更高要求客户端的高级设置里有“每次手动输入密码”的选项选了这个之后所有备份和恢复操作都会先弹一个密码输入框再带着这个密码去执行。代价是定时备份没法用了因为半夜三点没人来敲密码。所以这个选项更适合那种“我就偶尔手动备份一次”的用户把它当成一个可选项而不是默认项我认为是最合理的做法。4.2 保留策略、删除快照与 prune 的“防手滑”机制restic 的forget命令和prune命令经常被放在一起说但它们的职责完全不同。forget是更新快照的保留策略把不符合保留规则的快照标记为“待删除”它只动元数据不会立刻释放仓库空间。prune才是真正扫描仓库、删除无引用的数据包并压缩仓库体积的重操作。prune会读取大量数据块速度很慢而且一旦执行就没有后悔药可吃所以我在客户端里做了两类保护。第一类保护是把“删除快照”这个动作改成两段式。用户先选中一个或多个不需要的快照点击删除界面弹出确认框明确列出即将删除的快照 ID、时间点和路径要求输入仓库密码或者点击“我确认要删除”的复选框才能继续。确认之后调用的是restic forget而不是prune。这一步只删除快照的引用仓库空间暂时不会变所以即便后悔了理论上还有一定操作余地虽然不作为标准流程来承诺。第二类保护是默认关闭自动 prune。定时备份跑完一轮之后会顺带执行forget根据保留策略清理过期快照但prune只在用户主动点击“压缩仓库”按钮时才会执行。按钮旁边放了一行灰色小字“此操作会重写仓库数据耗时较长且不可撤销。”这样做的原因是避免用户在不知情的情况下触发一次耗电又耗磁盘 IO 的重型操作尤其是仓库在远程对象存储上时一次 prune 可能产生几千次请求账单会非常感人。如果你确实想自动化我也留了一个开关开启之后会在每天凌晨低峰期自动执行一次prune但默认是关闭的。稳妥至上这是备份工具应该有的态度。5. 实际开发中的坑与排查实录5.1 GUI 环境变量“幽灵”问题Terminal 能备份App 里却报 command not found开发过程中我碰到的第一个大坑是这个场景从终端手动跑 restic 一切正常但在 App 里点击“备份”子进程报exec: restic: executable file not found in $PATH。第一反应是“restic 没装”但终端明明能跑。后来才反应过来macOS 上的 GUI 应用和终端应用的 PATH 环境变量不是一回事。终端里用户 shell 会加载~/.zshrc/~/.zprofile之类的配置文件把/opt/homebrew/binApple Silicon 的 Homebrew 路径加进 PATH。而 GUI 应用是由 launchd 直接拉起的继承的是一个很精简的 PATH通常只有/usr/bin:/bin:/usr/sbin:/sbin。Homebrew 装的 restic 装在/opt/homebrew/bin/resticGUI 应用的子进程根本找不到它。解决方案也很直白客户端启动时先做一次 restic 路径探测依次检查/opt/homebrew/bin/restic、/usr/local/bin/restic、/usr/bin/restic、/opt/local/bin/restic找到第一个存在且可执行的就把路径缓存下来。如果都没找到就在界面引导用户安装。绝对不要依赖which restic因为which的结果同样受 PATH 影响。这个问题没有复杂的理论就是启动环境的不同但如果不清楚这层机制很容易在原地打转很久。5.2 不读 stdout 吗restic 的进度条和 JSON 是两回事最初做进度显示的时候我偷了个懒想直接读stdout的普通文本用正则抽进度。结果发现默认输出的进度条是靠\r回车符刷新的而且是不是 TTY 环境输出格式还不一样。在非 TTY 环境下restic 会退化成简单的百分比输出但在 App 里启动的子进程它的标准输出连接的是 Pipe不是终端所以 restic 会认为自己在非交互环境输出的东西有时候和你预期差得挺远。后来我老老实实用--json参数并且所有输出解析都是基于 JSON 的。需要特别提醒的是restic 的日志和错误信息有一部分是打到 stderr 的尤其是备份失败的 warning、Fatal错误全部都在 stderr。你不能只看 stdout否则用户以为备份成功了实际上早就失败了。我在代码里专门建了一条stderr的读取链路把 stderr 的最后 50 行保存在内存里一旦备份失败界面直接展示这些日志让用户能第一时间看到具体错误原因。这个细节帮我在后续调试中省了非常多的时间。5.3 签名、公证与 Gatekeeper免费开源也不能忽略分发体验macOS 对未签名应用的管控越来越严格。如果你把一个没有签名的应用压缩包分发给别人第一次打开很可能被 Gatekeeper 拦下来用户得右键“打开”再确认一次弹出来的警告文字还挺吓人的。这种体验对开源工具来说非常致命普通用户看到“无法验证开发者身份”基本就放弃使用了。实际上个人开发者也能做签名和公证。只要你有 Apple ID就可以申请免费的 Developer ID Application 证书用于本地签名。分发前的公证notarization也是在 Xcode 里就能完成的流程核心步骤就三步构建 Release 版本用Product Archive Distribute App走一遍公证流程然后把导出的应用包发给用户。如果你习惯命令行也可以用xcrun notarytool submit ResticMenuApp.zip --keychain-profile AC_PASSWORD --wait xcrun stapler staple ResticMenuApp.app第一行把应用提交给 Apple 的公证服务等待结果第二行把公证凭证“钉”到应用上这样用户下载后就不会再报“已损坏”或者“无法验证开发者”之类的错误。开源项目的签名证书是免费的只是 Apple 需要每年续一下开发者账号的会员资格实际上是开发者计划年费不过个人开发者的费用不算高为了分发体验我认为值得如果你暂时不想注册付费账号也可以先让用户用右键打开的方式绕过 Gatekeeper但我的建议是既然开源分发就别在这个环节上劝退用户做一下公证体验会好非常多。5.4 外接硬盘断开、仓库锁残留和 EOF 异常备份到本地外接硬盘时最典型的意外是备份过程中硬盘突然被拔出或者系统休眠导致 USB 连接断开。restic 遇到这种情况会写一个锁文件如果进程被强制杀掉这个锁会残留在仓库目录里。restic 的锁机制本身有超时策略默认 30 分钟超时后新进程可以强制抢占所以大多数情况下不用用户干预。但如果仓库在外部网络盘上比如 SMB 或 NFS锁的超时判断可能没那么快用户会看到“仓库被锁定”的报错。我在客户端里遇到这种情况时会提示用户“如果确定没有其他备份进程在运行可以等待 5 分钟后重试”并且不会自作主张去删除锁文件因为万一真有另一个进程在写仓库删锁会造成数据损坏。另一个容易忽略的坑是用Process跑 restic 时如果应用在前台触发了applicationWillTerminate而备份还没跑完直接退出会杀掉子进程备份就被腰斩了。我的做法是在退出前查一下BackupState如果是“备份中”先弹出确认框告诉用户当前备份还没结束退出将导致本次备份失败。如果用户坚持退出那就接受这个结果仓库锁会在超时后自动失效不影响下一次备份。这个行为虽然简单但对数据安全的观感影响挺大。宁可让进度显示多几秒也不要让用户觉得“一点退出整个备份就完了还完得很不对劲”。6. 开源与后续一点心得6.1 为什么决定开源License 怎么选这个项目从一开始就打算开源。原因很朴素restic 本身就是开源的我只是在它上面包了一个 GUI 外壳如果我不开源别人出于信任用了这个工具结果却看不到内部逻辑那就等于要求用户在备份工具上“盲盒式”信任我这说不过去。开源能让人看到每一行代码怎么处理密码、怎么调用 restic、怎么处理异常至少在数据安全这种敏感场景里透明是获得信任的底线。License 我选了 MIT。理由也很直接MIT 对用户几乎没有任何负担可以自由使用、修改、再分发甚至商用也不用在广告里署名。restic 本身的许可证是 BSD 2-Clause两个协议兼容性没有问题我可以放心里用自己的壳。会有开发者担心 MIT 让别人白嫖代码但对于一个个人开源的菜单栏工具来说被更多人用起来比防着别人抄更有价值。真要说商业化这个领域本来也卷不到哪去做得好不如用得爽社区反馈反而能带来更多改进灵感。6.2 后续还想加什么功能层面我接下来比较想做三件事。第一是给通知中心加备份完成通知目前只是菜单栏闪现一下经常会被错过。第二是做多仓库支持现在一份配置对应一个仓库有用户反馈说想把工作和私人的备份分开存到不同位置这个需求听起来很合理。第三是导入导出配置方便用户在多台 Mac 之间同步备份计划不过配置文件里不会包含密码只包含仓库地址、排除规则、保留策略密码仍然留在各台机器的 Keychain 里这样更安全。顺手再分享一个我开发时觉得很好用但很容易被忽略的 restic 子命令restic check --read-data。这个命令会读取仓库里所有数据包并做完整性校验相当于给备份做一次“体检”。我建议任何用 restic 的人不管是不是用我的客户端每个月都手动跑一次这个命令确保仓库没坏。GUI 客户端我也把这个命令做成了一个菜单项放在“维护”子菜单里跑一次可能需要几分钟但换来的安心感非常值。最后说点个人体会吧。做一个菜单栏小工具最难的部分其实不是 UI 怎么写得好看而是如何把一个功能强大的 CLI 工具的各种边界情况都处理到“普通用户感知不到”。restic 的命令参数很多每一条命令都可能因为仓库状态、网络情况、权限问题失败而 GUI 要做的不是把错误一股脑抛给用户而是尽可能提前判断、给出友好提示、必要时提供修复引导。这活儿没什么灵光一现就是一遍遍模拟用户场景、故意弄坏环境、观察行为是不是还能兜住然后一项项补漏洞。这也是我写这个项目最花时间、也最有收获的地方。
