Distrobox 备份：镜像、包清单与共享数据

本文的命令接口按 Distrobox 1.8.2.5 官方脚本核对；镜像标签与发行版包名是示例，使用前确认镜像仍受支持、仓库可用及本机实际版本。示例未做运行验证。

Distrobox 的 guest 包管理通常是命令式的，但镜像备份、包清单和构建声明可以互相补充。需要分开保存容器文件系统、运行配置、共享目录、数据卷与应用数据，才能判断恢复覆盖了哪些资产。

以下三种方案分别解决镜像状态、包意图和创建流程；没有任何一种单独等于完整备份。

1. 快照备份：podman commit#

podman commit 把容器可写层固化为镜像，默认在提交期间暂停容器。它不是内存/进程快照，也不能保证数据库一致性；应先停写、停止服务或进行应用级 dump。默认不包含 bind mount 和 volume 的内容。

备份：

# 将当前容器状态固化为新镜像
podman commit arch my-custom-arch:latest
# 将镜像导出为压缩包存到宿主机
podman save my-custom-arch:latest | bzip2 > my-custom-arch.tar.bz

恢复：

# 从压缩包恢复镜像
bunzip2 -c my-custom-arch.tar.bz | podman load
# 用这个自定义镜像创建新的 distrobox
distrobox create --name arch-restored --image my-custom-arch:latest

如果用的是 Docker 后端：

docker container commit -p distrobox_name image_name_you_choose
docker save image_name_you_choose:latest | gzip > image_name_you_choose.tar.gz

优点：保存 guest 可写层内的软件和配置，不必逐个重装。共享 HOME、额外挂载、卷、容器运行配置和进程内状态需要另行恢复。
缺点：黑盒状态，你不知道镜像里到底装了什么，不够"优雅"。镜像文件会比较大。

2. 包列表导出与重放（轻量级）#

不备份整个系统，只记录你装了哪些包，重装时按列表复原。

备份（在 Arch 容器内）：

# 导出所有显式安装的包
pacman -Qqen > ~/arch-repo-pkglist.txt
# 外来包（包括 AUR），另存列表
pacman -Qqem > ~/arch-foreign-pkglist.txt

由于共享了 HOME，这个文件直接保存在 NixOS 宿主机上。

恢复（新的 Arch 容器内）：

sudo pacman -Syu
sudo pacman -S --needed - < ~/arch-repo-pkglist.txt

优点：文件极小，纯文本，可以放进 Git。
缺点：AUR 软件包无法直接通过 pacman 重放，外来包需要检查来源并由 AUR helper 或自定义包构建流程单独处理。名称列表不能固定包版本、PKGBUILD 或已删除的仓库包。

3. 声明式构建（最推荐，最 NixOS）#

这是真正契合 NixOS 哲学的方法。用 distrobox.ini 的 additional_packages 和适时执行的 hooks，或直接写一个 Dockerfile，把容器内的软件包也变成代码。

3.1 使用 distrobox.ini 钩子（适合少量包）

直接把包列表写在宿主机 NixOS 配置里：

xdg.configFile."distrobox/distrobox.ini".text = ''
  [arch]
  image=quay.io/toolbx/arch-toolbox:latest
  additional_packages=fish eza zoxide starship base-devel cmake
  additional_packages=rustup nodejs
'';

清单让安装意图可追踪；latest 镜像和滚动仓库不会保证结果逐字节一致。AUR helper 通常在首次 guest 初始化后，以普通用户审查并构建，不能在基础包尚未配置的 pre-init hook 里假定 paru 已存在。

3.2 自定义 Dockerfile（适合复杂环境，可追踪构建）

如果你的容器环境极其复杂，写一个 Dockerfile 并用 Git 管理：

FROM quay.io/toolbx/arch-toolbox:latest
RUN pacman -Syu --noconfirm && \
    pacman -S --noconfirm base-devel fish eza zoxide starship cmake rustup

然后在宿主机构建镜像：

podman build -t my-arch-dev:latest -f "$HOME/.config/distrobox/arch.dockerfile" .

在 distrobox.ini 里引用：

[arch]
image=my-arch-dev:latest

优点：便于重建和审查。要进一步固定结果，应固定基础镜像 digest、包仓库快照和下载校验。Dockerfile 和 distrobox.ini 可以用 Git 追踪，和 configuration.nix 放在同一个仓库里。
缺点：包列表变动时需要重新 podman build。

总结建议#

对于绝大多数 NixOS + Distrobox 用户，方案二（导出包列表）结合方案三 A（distrobox.ini 的 additional_packages） 是性价比最高的：

系统核心工具写在 distrobox.ini 里。
开发环境包列表导出成 txt 存 Git 仓库里。
配置文件（如 ~/.config/fish、paru.conf）也用 Git 管理。

这样即使重装整个 NixOS，拉取 Git 仓库 → distrobox-assemble create → 重放包列表，可以重建容器包环境；随后还需恢复数据与导出入口。

4. 共享数据与恢复演练#

默认 HOME 是宿主目录，不在 commit/save 镜像中。自定义 --home 也通常是宿主 bind mount。备份应覆盖：

共享或自定义 home 中实际需要恢复的配置、项目与数据；避免把凭据未经保护放进公开 Git。
podman inspect 记录的挂载、端口、设备、init/root 模式和清单；不能只备份镜像名。
named/anonymous volumes 与额外 bind mounts 的数据，以及数据库的一致性 dump。
distrobox.ini、构建文件、镜像 digest、包列表与必要的上游版本/校验记录。

恢复时先在新容器名和新数据目录演练：load 镜像 → 用记录的参数创建 → 首次进入初始化 → 恢复应用数据 → 检查权限、数据库和工具版本 → 重新导出 app/bin 并验证启动。确认后再替换旧环境；不要让演练容器直接写唯一的生产数据。

distrobox rm 删除 guest 文件系统；--rm-home 还可能删除自定义 home。清理和备份是不同操作，执行任何删除之前先核对真实路径与恢复证据。

参考与延伸

根据技术笔记重新整理，示例使用通用名称。