rootless Podmanのバックアップと復旧設計

compute-serverのバックアップ設計

rootless Podmanのcompute-serverを、OS再インストールやNVMe初期化後に戻す手順を整理しました。インフラ構築の復旧設計として、コンテナのデータと周辺設定を分けて保存します。

ZFSは使わず、ext4/XFS + tar.zst + rcloneを使います。保存するものと再生成するものを分ける方針です。

背景・動機

Postgres、Trino、Dagsterのデータ以外に、user systemdやnamespaceの設定も必要です。/mnt/dataだけでは環境を戻せません。

ユーザー、/etc/subuid、/etc/subgid、loginctl enable-lingerを復旧条件に含めます。保存対象と、復旧時に再設定する対象を決めます。

大きなblobはrclone copyで転送し、symlinkを含むsnapshotsやrefsはrsync -aHで構造を維持します。

目的

OS再インストールやNVMe初期化後に、rootless Podmanの構成とデータを再現する設計です。

• ZFS を使わず、ext4/XFS + rclone + tar.zst で再現性と単純さを両立する
• 復旧時に必要な前提条件を、UID/GID、subuid/subgid、linger まで含めて固定する
• バックアップ対象と非対象をはっきり分け、余計なものを抱え込まない

ディレクトリ構成

保存場所と復旧用途です。

/home/ksh3と/etcも対象にし、user systemdとnamespaceを戻せるようにします。

バックアップ方針

システム構成バックアップ（毎日）

日次対象は/usr/local、/etc、/home/ksh3、/srv/backup/pkglist.txt、/etc/apt/sources.list.d/です。

  sudo dpkg --get-selections | awk '!/deinstall|purge/ {print $1}' \
  > /srv/backup/pkglist.txt

tar --use-compress-program="zstd -T0 -19" \
    -cf /srv/backup/system-$(date +%Y-%m-%d_%H-%M).tar.zst \
    /etc /usr/local /home/ksh3 \
    /srv/backup/pkglist.txt /etc/apt/sources.list.d \
    --exclude='/home/ksh3/.cache' --exclude='/home/ksh3/.local/share/Trash'
  

pkglist.txtで不足パッケージを確認します。再生成できる/home/ksh3/.cacheとTrashは除外します。

構成は容量が比較的限られるため、CPU並列のzstd -T0 -19で圧縮します。

データ領域バックアップ（週次または手動）

永続データは/mnt/dataに集め、週次または必要時に保存します。

  tar --use-compress-program="zstd -T0 -5" \
    -cf /srv/backup/mnt-data-$(date +%Y-%m-%d).tar.zst -C /mnt data
  

大きいデータは時間を優先し、圧縮を-5に下げます。

設定とデータのアーカイブを分け、OS・設定を戻してからデータを戻します。

転送先（storage-server）

アーカイブをstorage-serverへ送ります。

  rclone copy /srv/backup/*.tar.zst storage:/srv/backups/compute/ --progress
  

圧縮済みファイルの転送には、symlink処理が不要なrclone copyを使います。

ログはPrometheus / Lokiで集中管理する前提で、root側のログを除外します。

復旧手順（再インストール後）

最小環境整備

再インストール後、取得・展開・Podman起動の最小ツールを入れます。

  sudo apt update
sudo apt install -y zstd rclone podman podman-compose
  

zstd、rclone、podmanを使える状態にします。

バックアップ取得

storage-serverからアーカイブを取得します。

  rclone copy storage:/srv/backups/compute/latest/ /tmp/restore/
sudo tar -I zstd -xf /tmp/restore/system-YYYY-MM-DD.tar.zst -C /
sudo tar -I zstd -xf /tmp/restore/mnt-data-YYYY-MM-DD.tar.zst -C /
  

取得元はlatestです。この別名の更新方法と世代・保持期間は、まだ決める必要があります。

ユーザーと権限復旧

ユーザー、所有権、namespace、lingerを戻します。

  sudo useradd -m -u 1000 -s /bin/bash ksh3
sudo chown -R ksh3:ksh3 /home/ksh3 /mnt/data /opt /usr/local
echo "ksh3:100000:65536" | sudo tee /etc/subuid /etc/subgid
loginctl enable-linger ksh3
  

UIDは1000に揃え、既存データの権限とマッピングを維持します。

Podman環境再構築

条件が揃ったらPodmanを再起動します。

  sudo -u ksh3 podman system migrate
sudo -u ksh3 systemctl --user daemon-reload
sudo -u ksh3 systemctl --user enable --now pod-*.service
# または:
cd /opt/containers/compose
for d in *; do [ -d "$d" ] && cd "$d" && podman-compose up -d && cd ..; done
  

user systemdかpodman-compose up -dで復旧します。どちらもUID/GIDとsubuid/subgidの復元が前提です。

補足ポイント

補足の復旧条件です。

ネットワークは保存せず、再生成する方針です。

SSH鍵はこのバックアップに含めず、別に扱います。

保存対象と復旧条件

方針は次のとおりです。

• バックアップ対象は /usr/local, /etc, /home/ksh3, /srv/backup/pkglist.txt, /etc/apt/sources.list.d, /mnt/data
• 形式は tar.zst + rclone
• 鍵類は除外して安全性を確保する
• 再現条件は同一 UID/GID、subuid/subgid の復元、linger の有効化
• 復旧後は /opt/containers/compose から podman-compose up、または user systemd で再稼働できる

完全復旧の目標は20-30分です。実測結果ではなく、戻す対象を明確にした設計上の目標です。

今後の改善

残る作業です。

• storage:/srv/backups/compute/latest/ をどう更新するかを決めて、世代管理と保持期間を明文化する
• symlink を含む資産やモデル群では rclone と rsync をどう使い分けるかを、backup 系メモとも接続して整理する
• 復旧後に実行する smoke test を用意し、Podman サービス群が正しく戻ったかを機械的に確認できるようにする

次は復旧の自動化、世代管理、復旧後の確認を整えます。