ArkVault：一款 BorgBackup 图形界面工具，能让硬盘重新构建您的 Linux 系统

将备份硬盘插入一台尚未进行任何配置的全新 Linux 系统，你不仅能恢复文件，还能还原整个系统环境。ArkVault 会在加密备份数据旁写入一个引导式恢复工具包，这样硬盘本身便知晓如何重建整个系统：配置文件、SSH 密钥、启动器符号链接以及 systemd 服务单元等，一应俱全。

最终效果展示

这些截图是在使用模拟数据进行测试时截取的，并非我真实机器上的文件列表。

共有四个配置选项，每个选项都会显示其占用空间大小的实时估算值；凡是涉及敏感信息（如SSH密钥）的配置项旁都会出现锁形图标。只需点击一个按钮，即可备份所有已选中的内容。

这正是该工具的核心功能：恢复向导会读取驱动器上的备份信息，并清晰展示所有被备份的内容，敏感项目旁也会显示锁形图标。

此外还提供了拖放模式，方便用户快速创建不属于主目录中的临时备份集合。

指标	数值
代码量	约7,900行Python代码，压缩包内含50个文件
Pip依赖项	无。GTK由系统提供，requirements.txt故意留空
测试情况	全部93项测试均通过，无需使用pytest
压缩包大小	116 KB（Borg二进制文件并未打包在内；安装程序会自行下载）
沙盒恢复测试	8个项目均成功恢复到全新的$HOME目录中
在我机器上的每日备份耗时	51秒至1分31秒（2026年9月3日至15日）
每次备份涉及的文件数量	222–225个（2026年9月11日至16日）
重复数据去重效果	原本188.45 GB的快照数据最终仅占用18.24 GB空间（2026年9月9日统计）
许可协议	MIT协议，完全免费使用

Borg究竟能为你做些什么

ArkVault并非独立的备份引擎。它只是 BorgBackup 的前端界面，真正执行备份工作的还是BorgBackup本身：

• 加密功能：采用 repokey-blake2 加密方式。加密密钥存储在仓库中，并受密码保护。即便有人盗走了硬盘，也什么都得不到。
• 重复数据删除：基于内容特征进行分块处理，因此即使对一个变化缓慢的主目录创建十个快照，也不会占用十倍的空间。
• 压缩功能：使用 zstd 压缩算法，压缩级别为6。这种设置能在保证不错过任何数据的前提下实现良好的压缩效果。
• 保留策略：默认情况下 borg prune 会保留7个每日快照、4个每周快照以及6个每月快照（此设置可自定义）。这样一来，旧快照会逐渐被清理，硬盘空间也不会被占满。

为何不可变发行版促使我们采用不同的设计思路

我最初是在 Bazzite 上开发此工具的。Bazzite 是一个基于 Fedora 的不可变式发行版，其根文件系统为只读模式。后来这台机器又切换到了 Bluefin，后者同样存在相同的限制。这些限制直接决定了整个工具的设计方式：

• 所有内容均安装到 ~/.local 目录下；绝不会对 / 目录进行任何修改。
• 创建虚拟环境时需使用 --system-site-packages 参数，这样 GTK4/PyGObject 就能直接从宿主系统中调用，而无需在只读的根文件系统上重新编译相关依赖。
• 在此类系统中执行 pip install borgbackup 会失败（缺少 liblz4 头文件且没有对应的预编译包），因此安装程序会直接下载官方发布的 独立版 Borg 二进制文件——该文件由 PyInstaller 打包而成，且内置了 FUSE 支持。
• 整个系统中完全不需要使用 sudo。唯一需要管理员权限的操作——格式化磁盘——则通过 polkit/pkexec 机制来完成。

核心思路：通过驱动器来重建整个系统

Borg 并不知道哪些文件至关重要、它们需要什么权限，也不清楚文件恢复后还需要执行哪些操作才能让系统重新运转。普通的备份工具只能把文件还原回来，之后用户仍需自行记住各文件的位置以及需要重新启用的 systemd 服务单元。而 ArkVault 则会在每次备份时将这些信息一并写入驱动器：

• arkvault-repo/：加密后的 Borg 备份仓库。
• ArkVault-App/：ArkVault 的自包含版本，包含源代码与安装程序；该目录通过原子方式复制（先写入临时目录再重命名），因此即便复制过程被中断，也不会在驱动器上留下不完整的内容。
• arkvault-install-map.json 以及 RESTORE-README.md：前者记录了所有备份内容的信息，后者则是无需任何工具即可阅读的纯文本操作指南。

该安装映射文件会标记出哪些项目属于机密信息；不过其中并不会包含这些内容的实际数据。

备份过程究竟做了什么

整个备份流程其实很直接：先确定目录中的哪些文件需要备份（缺失的路径则被跳过），可选地让那些写入操作频繁的服务暂时停止运行以确保数据库状态一致，接着执行 borg create 和 borg prune，最后将恢复工具包写入到硬盘中。

第二种模式：生成普通文件夹镜像

Borg 仓库中的数据经过了去重、加密处理，因此无法直接读取。要读取这些数据，需要使用 Borg 或 ArkVault——这倒也没什么问题，直到你面对一台既没装 Borg 也没装 ArkVault 的机器为止。

于是就有了第二种模式：arkvault mirror。该模式会将数据以普通的、基于 $HOME 路径的文件夹形式写入驱动器。恢复数据时只需执行 bash <drive>/restore.sh，或者直接把文件夹拖回来即可。不过这种方式只会生成一份当前状态的数据副本，既没有历史记录也没有去重功能。

有两方面原因使得“直接复制文件夹”的做法并不靠谱：

• 敏感数据依然需要加密。 exFAT 文件系统不支持 Unix 权限设置，因此直接复制的 .ssh 文件夹会变成任何人都能读取的状态。所有标记为敏感的项目都会被打包进一个用 GPG 加密的 tar 文件中（这样就能保留原有权限信息）；而 restore.sh 会在恢复时解密并重新设置权限。
• exFAT 不区分大小写。 如果某个目录结构中同时存在 Foo/ 和 foo/，复制后它们会合并为一个目录，这种数据丢失情况看起来却像是操作成功。ArkVault 会在复制前检查是否存在大小写冲突或非法字符；若存在此类情况，它会将这些目录无损地保存为 .tar.gz 文件，并将原因记录在清单文件中。

无论使用哪种模式，恢复工具包都会被写入驱动器，因此任意一种模式都能为下一台机器提供恢复所需的“地图”。

那些防止误操作的机制

大部分工作都花在了这些安全防护措施上：

• 系统磁盘格式化保护机制。 误格式化了错误的磁盘可是备份工具最常见的灾难性错误。ArkVault通过遍历 /sys/class/block/*/slaves 来解析 LUKS/LVM 设备映射链，从而定位到物理磁盘；由于加密后的根分区对应的映射名称与实际磁盘名称毫无关联，简单的名称比对根本无法识别。如果连系统磁盘都枚举不出来，程序就会 强制拒绝所有操作，绝不会执行任何格式化操作。当然，用户仍需手动输入确切的设备名称以作确认。
• 恢复时的路径限制机制。 若安装配置信息存在错误或被篡改，系统也能防止数据被写入目标主目录之外的地方：程序会解析符号链接的上级目录，但刻意不跟随最末端的符号链接；任何试图跳出主目录的部署操作都会被拒绝。
• 日志中的敏感信息清理机制。 密码以及所有标记为敏感的信息都会被清除——既通过精确文本匹配，也借助正则表达式来过滤诸如 apiKey: 和 Bearer 之类的敏感模式。
• 密码恢复指南机制。 首次备份时会生成一个不可选中的密码提示单，这样就不会意外将密码复制到剪贴板；同时“我已记下密码”选项未被勾选时，关闭按钮也处于禁用状态。该提示单绝不会被写入磁盘。一旦丢失密码，备份数据也就永远无法恢复了。
• FAT32 不被允许作为备份存储目标。 因其 4 GB 的文件大小限制会破坏 Borg 的正常运作；而 exFAT 虽被允许使用，但会弹出相应警告，毕竟 Borg 本身也会在内部存储 Unix 元数据。
• 空存档不被接受。 若所有源路径均不存在（比如磁盘未挂载或目录名输入有误），ArkVault 就会拒绝生成看似“成功完成”的空存档文件。
• 随时可手动验证数据完整性。 用户可通过用户界面或命令行运行 borg check 来执行真正的完整性检查；此外，“浏览快照”功能还会通过 FUSE 以只读方式挂载存档，方便用户在完全信任之前仔细检查其内容。

设置方法

你需要 GTK4/libadwaita 的 PyGObject 绑定、udisks2 以及 polkit。在 Fedora/GNOME 系统中这些组件已预装；在 Debian/Ubuntu 上只需一条命令即可安装：

sudo apt install python3-gi gir1.2-gtk-4.0 gir1.2-adw-1

接着运行安装程序，该程序可重复执行且不会造成问题：

bash install.sh

安装程序会将应用复制到 ~/.local/share/arkvault 目录下，创建带有 --system-site-packages 参数的虚拟环境，下载官方的 Borg 独立二进制文件，最后生成 ~/.local/bin/arkvault 可执行文件以及桌面快捷方式。之后：

arkvault probe

一切应该都显示正常。直接运行 arkvault 即可启动图形界面；其核心功能同样适用于无界面的命令行模式：

arkvault probe|backup|restore|list|check

真正关键的一步是：编辑目录配置列表。 默认提供的仅为示例内容。core/discovery.py、profiles.py、core/quiesce.py、core/containers.py 以及 core/installmap.py 中均有标记为“EDIT ME”的段落。这份配置列表正是用来定义新安装环境下需要恢复的项目，没人能替你编写它。

目录配置本身以纯 Python 代码形式存在于 core/discovery.py 文件中。每条记录包含相对于用户主目录的路径、相关标记及说明文字。这些路径会在运行时才被检测，因此列出不存在的项目也不会引发问题。以下是默认提供的配置示例：

_SETTINGS = [
    (".bashrc", False, "Bash rc"),
    (".gitconfig", False, "Git identity and settings"),
    (".ssh", True, "SSH keys/config/known_hosts (PRIVATE KEYS)"),
    (".config/rclone", True, "rclone remotes (may embed tokens)"),
]

放置于用户主目录下的应用亦可附带重新部署指令；恢复向导会执行这些指令或将其列入手动操作清单。该文件中还包含一个已注释掉的 Node.js 应用的示例配置：

redeploy = {"steps": [
    {"kind": "npm", "dir": "my-node-app", "cmd": "npm ci"},
    {"kind": "symlink", "link": ".local/bin/my-app",
     "target": "my-node-app/cli.js"},
    {"kind": "desktop-entry",
     "path": ".local/share/applications/my-app.desktop"},
    {"kind": "privileged-script", "script": "my-node-app/install.sh",
     "via": "pkexec", "manual": True,
     "desc": "Installs udev rules / system units (needs root)"},
]}

我在初始列表中删除了部分 shell 配置文件。压缩包版本中还提供了创建 Python 虚拟环境的步骤（即 "kind": "pip"）。

首先执行一次备份操作，并将恢复信息表保存至非备份驱动器上；随后点击“将应用复制到驱动器”。若需自动执行备份，README-SETUP 中提供了相应的 systemd 用户定时任务模板；该模板会从密钥环或 ARKVAULT_PASSPHRASE 环境变量中获取密码。

恢复测试（沙盒环境）

我尚未用这个驱动器来恢复我的真实机器。我所做的只是在沙盒环境中进行一次完整测试：使用压缩包中的文件结构，针对一个虚拟的 $HOME 目录进行操作。

1. 解压源代码后运行 install.sh，该脚本确实下载了 27.9 MB 的 Borg 数据。
2. 执行 arkvault probe：一切正常。
3. 使用 arkvault backup 将 3 个示例配置文件备份到临时目录中：共 8 个项目被备份；仓库也用 repokey-blake2 成功初始化，同时生成了 install-map、RESTORE-README 以及自包含包文件。
4. 先执行 arkvault list，再执行 arkvault check：均顺利通过。
5. 最后执行 arkvault restore，将备份内容恢复到另一个全新的主目录中：所有 8 个项目都被正确还原到对应路径，系统还输出了手动检查清单以供确认。

在这个相同的文件结构下，无依赖项的测试套件实现了 93/93 的通过率。这证明了相关机制在示例数据上的有效性；不过这并不能保证对大型真实主目录也能成功恢复。

来自我自己机器的数据

同一套工具通过 systemd 用户定时器，每晚凌晨 02:00 自动备份我的机器。以下数据均来自该定时器的日志以及 Borg 自身的 --stats 输出结果：

项目	数值
每次备份捕获的项目数量	222–225个（2026年9月11日至16日）
每次备份时生成的 SQLite 数据库快照数量	27–39个，总大小约1.4–1.7 GB（2026年9月11日至16日）
某次快照情况（2026年9月9日）	原始数据大小为17.45 GB，压缩后为14.12 GB；去重后仅剩1.62 GB
所有快照总体情况（2026年9月9日）	原始数据总量为188.45 GB，压缩后为146.78 GB；去重后仅剩18.24 GB（压缩率约10倍）
仓库在磁盘上的实际大小（2026年9月16日）	31 GB
2026年9月3日至15日期间的每日备份耗时	51秒至1分31秒不等
2026年9月16日的备份耗时	3分8秒
内存使用峰值	1.7–2.6 GB（2026年9月3日至16日）

每晚新增到仓库的数据量仅为0.85–1.6 GB左右，正因如此，对一个大小为15–18 GB的数据集进行每日备份的成本也保持在较低水平。目前我还未查明为何9月16日的备份耗时是平日的三倍。9月9日时 Borg 报告的数据量为18 GB，而一周后磁盘上的仓库大小却达到了31 GB；这一差异主要由两部分因素造成：首先是连续七晚产生的新数据，其次是那些已被删除但所占空间仍未被释放的快照。因为 Borg 仅在运行 borg compact 时才会释放仓库空间，而 ArkVault 从未执行过该命令。在记录这些数据的三个夜晚里，Borg 均以警告状态退出（退出代码为100）。ArkVault 也将此情况视为警告而非成功的备份操作。

注意事项

• 此压缩包修复了原安装脚本中的一个bug。 Borg的GitHub发布页面提供了GPG签名文件 .asc，但缺少 .sha256 校验文件；因此安装程序在获取校验值时返回404错误，随后 set -e 命令导致安装过程提前终止。此问题在此处已修复；另外还新增了一个可选环境变量 ARKVAULT_BORG_SHA256，可用于指定一个可信的哈希值。在我的机器上并未出现该问题，因为Borg二进制文件早已存在，所以下载流程根本没执行。
• FAT32格式会悄悄搞砸你的备份工作。 ArkVault能检测到FAT32格式并拒绝使用，不过很多U盘出厂时默认就是这种格式。
• 清理操作本身并不会缩小仓库体积。 ArkVault在每次备份后都会运行 borg prune，但不会执行 borg compact。当前版本的Borg（我的机器上为1.4.4）只有在执行压缩操作后才会释放磁盘空间。建议定期对仓库运行 borg compact，或者将其加入定时任务中。
• 备份过程中断会导致仓库锁状态异常。 可使用 borg break-lock 来清除该锁（图形界面中也有对应按钮）；设置 BORG_LOCK_WAIT=120 则能让并发的备份任务进入等待状态，而非立即失败。
• 以WAL模式运行的实时 SQLite 数据库 需要同时备份其 db、wal 与 shm 文件；或者先停止服务再备份。正因如此才设置了“暂停服务”步骤。该步骤位于 finally 代码块中，这样即便备份中途失败，相关服务也能正常恢复。
• 将数据恢复到其他用户名下也是可行的，因为所有目标路径均是以用户主目录为基准进行记录的。那些无法映射到新用户的文件则会被列入手动处理清单，而不会被悄无声息地忽略。
• 没有GNOME密钥环（比如无图形界面的服务器或CI环境）？此时程序会改用内存中的密码与提示方式来完成操作，而非直接报错。
• 一个隐蔽的bug： 以往执行 python -m arkvault backup ... 时程序看似正常结束，其实什么也没做：图形界面的参数解析器误将子命令当作普通参数处理并直接返回0。现在 __main__.py 会明确处理CLI子命令。请务必确认备份操作确实生成了归档文件，而不只是返回0而已。
• 已卸载的工具仍会出现在目录列表中。 我曾卸载某个工具，之后每晚的备份都会提示该工具的文件夹存在但内容缺失。ArkVault会继续执行其他备份操作，并在运行日志中重复该警告。解决办法是从目录列表中手动删除对应条目即可。
• 随包附带的目录示例是特意留空的。 我实际使用的目录列表里详细记录了重要数据的具体位置——这些信息显然不该出现在公开发布的压缩包中。您会获得一个包含“Projects/Settings”结构的干净示例，以及一个可正常重新部署的样例（即上文“设置方法”部分所述），但其中并无我的个人路径信息。

相关链接：如何让AI将任意项目适配到你的系统 以及 该工具所备份的系统栈详情。ArkVault正是借助AI编程助手开发而成的。

下载

• Download ArkVault source (zip) 116 KB

仅限个人使用免费。如果它替你省下了一下午的时间，欢迎点旁边的咖啡按钮支持一下。