Limits of Podman System Backup Regarding Host Configuration Inclusion

Direct Answer

As of Podman 4.3+, podman system backup does not include host configuration files (e.g., registries.conf, storage.conf, policy.json, containers.conf) and there is no built‑in flag to add them. Whether such a flag should exist depends on the restore scenario: for same‑host disaster recovery, manual backup of config is simpler and safer; for portable migration, automatic inclusion risks embedding host‑specific paths that break on the target system.

Confirmed Facts

• Backup scope: podman system backup stops the Podman service and archives only the graphroot directory (images, containers, volumes, networks).
• Config locations: Rootful installs use /etc/containers/; rootless installs use $HOME/.config/containers/. These are outside graphroot and are not captured.
• No flag exists: Current releases provide no option to bundle these files automatically.

Likely Behavior of a Hypothetical --include-config Flag

• Rootful mode: Would collect system‑wide files from /etc/containers/. These often contain absolute paths, certificate references, and distribution‑specific defaults that are not portable across hosts.
• Rootless mode: Would collect user‑scoped files from $HOME/.config/containers/. While more portable, they still encode user namespace mappings and storage paths tied to the original UID/GID.
• Risk: Automatic bundling can violate rootless isolation assumptions and introduce host‑specific dependencies that cause restore failures on a different machine or user.

Verification Steps for Restore Fidelity

1. Before backup, run podman info --debug and save the output. Note graphRoot, runRoot, config file directories, and storage driver.
2. Compute checksums of the configuration files that matter for your setup (e.g., sha256sum /etc/containers/registries.conf $HOME/.config/containers/storage.conf). Store the results.
3. Perform the backup (graphroot archive) and manually copy the config files to a separate, version‑controlled location.
4. Restore on the target system: extract the graphroot archive, place config files in the appropriate location (/etc/containers/ for rootful, $HOME/.config/containers/ for rootless).
5. Run podman info --debug again and compare with the saved output. Verify that graphroot, runroot, and storage driver match.
6. Re‑compute checksums of the restored config files and compare with the pre‑backup values.
7. Functional test: start a representative container that relies on registry configuration and policy (e.g., pull an image from a configured registry, run a container with a specific security policy). Confirm behavior matches the original environment.

One Missing Diagnostic Detail

Is this backup intended for same‑host disaster recovery or for portable migration to a different host/user? The answer changes the recommendation: same‑host restores favor manual config separation; portable migrations require careful path sanitization and may be better served by a documented manual process rather than an automatic flag.