AIにComposeを壊され続けたので、15分おきにKopiaで戻せるようにした

投稿者: | 5月 11, 2026
0件のコメント
最近は、VM関連ゼロ。Docker系100という感じ。いくつかはKubernetes。しかし、Kubernetesほどのノードもなく、ノードのスペックもバラバラなので、Dockerで十分。
 
以前のDocker運用は、一度Composeを書いたら数ヶ月変更しないことも普通だった。しかし、AI時代は違う。AIが毎日のように「もっといい設定」「新しい構成」「推奨変更」を提案してくるため、構成変更頻度が異常に高い。
 
実際、最近のDocker構成は、単なるWebアプリ構成ではなく、
  • Open WebUI
  • Ollama
  • ComfyUI
  • MCP
  • など
など、AI関連のコンテナ群が大量に増えていき、Composeファイルもどんどん巨大化する。しかも最近は、AI提案によって設定変更頻度も高い。そのため、Docker構成そのものがかなりAI依存になっており、トライアンドエラーで構成変更することが非常に多い。
 
AIベースで構築すると、
 
うまく動いていた -> AIからの変更提案 -> 適用してみる -> 動かなかった ->元に戻す
 
ということが頻発する。まるで、どこかの政党の『XXXをぶっ壊せ」ばりに壊される。
 
単発であれば、単に戻せばいい。しかし、いくつか適用を重ねた上での不具合で、「だいぶ前に戻したい」となると困る。構成をGitで管理していればいいが、そこまでやっていなかった場合は、もう戻れない。
 
理想論としてはGit管理すべきである。しかし実際には、
  • AI提案をその場で試す
  • compose.ymlを直接編集する
  • 複数ノードに散らばる
  • 環境変数をローカルで変更する
  • 深夜にAIの提案をコピーペーストして試す
といった運用になりやすく、完全なGit管理は意外と難しい。
 
特にホームラボ環境では、「あとで整理しよう」と思ったまま、実験状態が積み重なっていく。なので、15分おきにスナップショットを撮りたいと思った。
 
ここで重要なのは、「長期保管のためのバックアップ」と、「試行錯誤を高速に巻き戻すためのスナップショット」は、目的が違うという点である。今回やりたいのは、災害対策のためのバックアップではない。
 
AI提案による構成破壊から、高速に復旧するためのスナップショットである。もちろんディスク容量があれば長期保管のバックアップも可能だが（実は自分は1年分は保管するようにした。）
 
しかし、手元のストレージは、腹持ちのNVMEであって、NASなどではなく、NASでもHDDなら遅くてたまらない。
昔のバックアップ運用は、
  • HDD NAS
  • nightly backup（夜間バックアップ）
  • rsync
のような世界だった。しかし現在は、
  • NVMe前提
  • Docker volume大量
  • AIモデル巨大
  • metadata大量
  • 小さい変更が頻繁
という世界になっている。
 
AI時代のホームラボでは、従来型のHDDベースバックアップ文化がかなり厳しくなっている。さらに15分おきのスナップショットを撮るとしても、エンタープライズレベルの高額なストレージが必要で、さらにそれなりにスナップショット容量が必要となる。ホームラボでは用意することは不可能。
 
では、ファイルバックアップソフトを入れるという手もあるが、ファイルバックアップソフトは、大抵有償（それも結構いいお値段）だけではなく、
  • バックアップサーバが必要
  • バックアップデータのメタデータを保存しておくバックアップデータベースが、ファイルバックアップの場合巨大になる
  • バックアップストレージが限定されていて、ストレージ毎にサポートされている機能に違いがある
  • バックアップ開始にすごく時間がかかるので、15分おきにバックアップさせるとバックアップがずっと動きっぱなしになる
  • ファイルレベルのリストアにくせがある
  • インスタントリストアができても構成を組む必要がある
  • ソフトウェアによっては、バックアップサーバやバックアップデータのポータビリティがない
 
特に、「バックアップ開始が重い」というのは、従来型バックアップ製品ではかなり大きい問題である。
15分間隔でバックアップしたいのに、毎回のジョブ開始が重く、前のバックアップが終わる前に次が始まるような状態になる。
 
ホームラボ用途ではかなり厳しい。
 
商用のバックアップソフトウェアは、基本設計が、コンテナやAIが一般化する前のものがほとんどである。
そのため、
  • VM単位
  • サーバ単位
  • nightly backup
  • 重厚なバックアップサーバ前提
の思想が強く、
  • Docker Compose
  • AI関連state
  • 頻繁に変化する構成ファイル
  • 15分単位の高速巻き戻し
といった、現在のAIホームラボ用途には必ずしも適していない。いや、ほとんどの商用のバックアップ製品はこのようなケースには向いていないのではと思っている。
よって、商用のファイルバックアップソフトは不採用とした。お金を払ったところで何も解決しない。
 
 
 
解決策はないか？
 
 
 
kopiaでスナップショットをすることにした。Kopiaは無償である。
 
Kopiaを使う理由はかなり明確で、
  • バックアップの構成は、バックアップデータに内包
  • バックアップサーバがなく、バックアップデータを集中管理しないのでデータベース自体がない
  • バックアップ元、バックアップ先のストレージの制限があまりない上に、圧縮、重複排除の機能制限の違いも少ない
  • バックアップ開始が高速
  • ファイルレベルリストアも簡単
  • インスタントリストアは、FUSEを使ってリストアができる
  • バックアップデータのポータビリティが高い
という点が非常に大きい。
 
特に、「バックアップ開始が高速」というのは、15分おき運用ではかなり重要である。
 
さらに、
  • バックアップデータをマウントしてあげれば、CLIだけではなく、KopiaのGUIも使える。
  • エンタープライズストレージで使えるイミュータブル機能も利用可能であり、オブジェクトストレージのオブジェクトロックにも対応できる。
  • 重複排除や圧縮が効くので、このユースケースの場合、長期保管目的でもインパクトが少ない。
これは最近のAI環境ではかなり重要だと思っている。
 
AI生成コードを実行していると、誤って構成やデータを削除するケースもある。
immutable backupやobject lockを使うことで、バックアップそのものを破壊されにくくできる。
 
自分的には、ファイルバックアップは、ライセンスを払って大変な思いをするより、全てのファイルシステムのバックアップのユースケースではテープ保存以外では、無償のKopia一択だと思っている。
 
 
 

前置きはともかく、以下が実際の設定内容。

 

環境

  • Ubuntu Server
  • Docker Stack (Docker Composeの場所）/opt/containers
  • バックアップ先：NFS共有（無理にオブジェクトストレージに保存しない。そもそもバックアップデータのファイル自体がオブジェクトになっているので、屋上奥にしたくない。）

バックアップ元

/opt/containers
 

バックアップ先

/mnt/nfs/kopia-container-host-backup/<hostname>
例：
/mnt/nfs/kopia-container-host-backup/nuc5i5ryh
 

事前準備

NFS マウント確認

mount | grep kopia-container-host-backup
例：
nas01:/volume1/kopia-container-host-backup on /mnt/nfs/kopia-container-host-backup type nfs4
 

Step 1. Kopia インストール

Ubuntu 26.04 / 24.04

kopiaのコマンドライン補完もいれておくようにした。
cat <<‘EOF’ >/tmp/install-kopia.sh
#!/bin/bash
 
# Install Kopia repository
curl -fsSL https://kopia.io/signing-key | gpg –dearmor \
| tee /usr/share/keyrings/kopia-keyring.gpg >/dev/null
 
echo “deb [signed-by=/usr/share/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main” \
| tee /etc/apt/sources.list.d/kopia.list
 
apt update
apt install -y kopia
apt install -y fuse3
kopia –completion-script-bash > /etc/bash_completion.d/kopia
EOF
 
bash /tmp/install-kopia.sh
 
 
 

Step 2. cache/log ディレクトリ作成

cat <<‘EOF’ >/tmp/create-kopia-dirs.sh
#!/bin/bash
 
mkdir -p /var/cache/kopia
mkdir -p /var/log/kopia
 
chmod 700 /var/cache/kopia
chmod 700 /var/log/kopia
EOF
 
bash /tmp/create-kopia-dirs.sh
 
 

Step 3. repository 作成

バックアップ保存先の設定

ホスト名取得

hostname -s
例：
nuc5i5ryh
 

repository 作成

NFSに設定している例。もちろん、ここで、オブジェクトストレージを設定すれば、保存先はオブジェクトストレージになる。
Repository パスワードの設定を指定させられる。
 
Repository password を失うと、repository が残っていても復元できない。  
Kopia は暗号化されているため、NFS上のデータだけを持っていても password がなければ絶対に復旧できない！忘れたら一巻終わり。
 
cat <<‘EOF’ >/tmp/create-kopia-repo.sh
#!/bin/bash
 
HOSTNAME_SHORT=”$(hostname -s)”
 
REPO_PATH=”/mnt/nfs/kopia-container-host-backup/${HOSTNAME_SHORT}”
 
mkdir -p “${REPO_PATH}”
 
kopia repository create filesystem \
–path “${REPO_PATH}” \
–cache-directory /var/cache/kopia
EOF
 
bash /tmp/create-kopia-repo.sh
 
 

Step 4. repository 接続確認

kopia repository status
 
 
例：レポジトリに全てのバックアップ設定が入っている。なので、バックアップのバックアップは、このフォルダを保護しておけばいい。NASなどであれば、このフォルダのスナップショットやリモートバックアップを撮っておくのもあり。
Config file: /root/.config/kopia/repository.config
 
Description: Repository in Filesystem: /mnt/nfs/kopia-container-host-backup/nuc5i5ryh
Hostname: nuc5i5ryh
Username: root
Read-only: false
Format blob cache: 15m0s
 
Storage type: filesystem
Storage capacity: 9.9 TB
Storage available: 8 TB
Storage config: {
“path”: “/mnt/nfs/kopia-container-host-backup/nuc5i5ryh”,
“fileMode”: 384,
“dirMode”: 448,
“dirShards”: null
}
 
Unique ID: 1732397280562b6afda6fdb3ebdd19aa8f8f1a98ea14ebcf4fa6c63a50ccb4aa
Hash: BLAKE2B-256-128
Encryption: AES256-GCM-HMAC-SHA256
Splitter: DYNAMIC-4M-BUZHASH
Format version: 3
Content compression: true
Password changes: true
Max pack length: 21 MB
Index Format: v2
 
Epoch Manager: enabled
Current Epoch: 0
 
Epoch refresh frequency: 20m0s
Epoch advance on: 20 blobs or 10.5 MB, minimum 24h0m0s
Epoch cleanup margin: 4h0m0s
Epoch checkpoint every: 7 epochs
 

Step 5. policy 設定

バックアップ元のポリシーの設定
 
zstd-fastest 圧縮の設定を行い、15分おきにスナップショットを撮るが、長期保管も兼務することにする。
バックアップデータが膨大になるが、圧縮重複排除が効くのでそれほど大きくなることは想定していない。
 
容量に関しては数日のバックアップで初期状態では 322MB 程度、その後 151 snapshot まで増えても 1.7GB 程度だった。
 

retention設定

以下のようにした。

15分毎のバックアップを24時間保持（スナップショットユースケース）
↓
1時間毎のバックアップを1週間保持（スナップショットユースケース）
↓
1日毎のバックアップを30日保持（通常のバックアップユースケース）
↓
1週間毎のバックアップを3ヶ月保持（通常のバックアップユースケース）
↓
1ヶ月毎のバックアップを1年保持（通常のバックアップユースケース）
↓
1年毎のバックアップを3年保持（通常のバックアップユースケース）
 
 
/opt/containersだけ指定してもよかったのだが、ケースによっては、DockerやContainerdの設定や、カスタムスクリプト、systemdの設定を変更するので、バックアップ元として以下を指定をしている。
 
TARGETS=(
“/etc/docker”
“/etc/containerd”
“/etc/systemd/system”
“/usr/local/bin”
“/opt/containers”
)
 
 
個別にkopiaコマンドで実行すればいいのだが、Forループで回している。
cat <<‘EOF’ >/tmp/set-kopia-policy.sh
#!/bin/bash
 
# Set Kopia retention policy for each snapshot root.
# Do not use top-level set -e so that failures are visible per target.
 
TARGETS=(
“/etc/docker”
“/etc/containerd”
“/etc/systemd/system”
“/usr/local/bin”
“/opt/containers”
)
 
for TARGET in “${TARGETS[@]}”; do
if [ ! -d “${TARGET}” ]; then
echo “[SKIP] Not found: ${TARGET}”
continue
fi
 
echo “[INFO] Setting Kopia policy: ${TARGET}”
kopia policy set “${TARGET}” \
–compression=zstd-fastest \
–keep-latest 96 \
–keep-hourly 168 \
–keep-daily 30 \
–keep-weekly 12 \
–keep-monthly 12 \
–keep-annual 3
 
if [ $? -ne 0 ]; then
echo “[ERROR] Failed to set policy: ${TARGET}”
fi
done
 
echo “[INFO] Current policies:”
kopia policy list
EOF
 
bash /tmp/set-kopia-policy.sh
 
例
Setting policy for root@nuc5i5ryh:/opt/containers
– setting “number of annual backups to keep” to 3.
– setting “number of monthly backups to keep” to 12.
– setting “number of weekly backups to keep” to 12.
– setting “number of daily backups to keep” to 30.
– setting “number of hourly backups to keep” to 168.
– setting “number of latest backups to keep” to 96.
 

Step 6. .kopiaignore 作成

スキップするバックアップ元のデータ形式を指定。OpenWebUIにはバックアップを取らなくてもいいファイルがあるので除外することにした。
この設定はバックアップ元のフォルダごとに設定することが可能。

/opt/containers/.kopiaignore

cat <<‘EOF’ >/opt/containers/.kopiaignore
# Runtime/cache
**/.cache/**
**/cache/**
**/tmp/**
**/temp/**
**/__pycache__/**
**/logs/**
**/log/**
 
# Node/Python build artifacts
**/node_modules/**
**/.venv/**
**/venv/**
**/dist/**
**/build/**
 
# Open WebUI cache
open-webui/openwebui/cache/**
 
# NPM logs
npm/data/logs/**
 
# Uptime Kuma screenshots
uptime-kuma/data/screenshots/**
 
# OpenClaw runtime artifacts
open-webui/openclaw/completions/**
open-webui/openclaw/delivery-queue/**
EOF
 
 

Step 7. 初回 snapshot

引数は、バックアップ対象にして一度実行。もちろんForループでまわしてもいい。
 
kopia snapshot create /etc/docker
 
kopia snapshot create /etc/containerd
 
kopia snapshot create /etc/systemd/system
 
kopia snapshot create /usr/local/bin
 
kopia snapshot create /opt/containers
 

Step 8. snapshot 確認

もちろんForループでまわしてもいい。

kopia snapshot list
 
kopia snapshot list /etc/docker
 
kopia snapshot list /etc/containerd
 
kopia snapshot list /etc/systemd/system
 
kopia snapshot list /usr/local/bin
 
kopia snapshot list /opt/containers
 
 
root@nuc5i5ryh:/opt/containers
2026-05-08 13:48:02 UTC kfda5b4614bbaafa0e138198d9d527ad3 294.5 MB drwxr-xr-x files:814 dirs:260 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
 

Step 9. snapshot script 作成

このファイルでバックアップ元のフォルダが指定されている。フォルダを追加するときはこのファイルだけを修正する。

/usr/local/bin/kopia-backup.sh

cat <<‘EOF’ >/usr/local/bin/kopia-backup.sh
#!/bin/bash
 
# Kopia multi-source backup script.
# Comments are written in English for maintainability.
 
LOG_FILE=”/var/log/kopia/backup.log”
KOPIA_CONFIG_PATH=”/root/.config/kopia/repository.config”
GLOBAL_RESULT=0
 
# Backup source list
BACKUP_SOURCES=(
“/etc/docker”
“/etc/containerd”
“/etc/systemd/system”
“/usr/local/bin”
“/opt/containers”
)
 
mkdir -p /var/log/kopia
 
{
echo “==================================================”
echo “Backup started: $(date -Is)”
echo “Host: $(hostname -s)”
echo “==================================================”
 
kopia repository status \
–config-file=”${KOPIA_CONFIG_PATH}”
 
STATUS_RESULT=$?
 
if [ “${STATUS_RESULT}” -ne 0 ]; then
echo “Repository status failed: ${STATUS_RESULT}”
exit “${STATUS_RESULT}”
fi
 
for SOURCE in “${BACKUP_SOURCES[@]}”; do
echo
echo “—————————————-“
echo “Snapshot source: ${SOURCE}”
echo “—————————————-“
 
if [ ! -d “${SOURCE}” ]; then
echo “Source directory does not exist: ${SOURCE}”
GLOBAL_RESULT=1
continue
fi
 
kopia snapshot create “${SOURCE}” \
–config-file=”${KOPIA_CONFIG_PATH}”
 
SNAPSHOT_RESULT=$?
 
echo “Snapshot exit code: ${SNAPSHOT_RESULT}”
 
if [ “${SNAPSHOT_RESULT}” -ne 0 ]; then
GLOBAL_RESULT=”${SNAPSHOT_RESULT}”
fi
done
 
echo
echo “Global exit code: ${GLOBAL_RESULT}”
echo “Backup finished: $(date -Is)”
echo “==================================================”
echo
 
exit “${GLOBAL_RESULT}”
 
} >> “${LOG_FILE}” 2>&1
EOF
 
chmod +x /usr/local/bin/kopia-backup.sh
 

Step 10. systemd service 作成

/etc/systemd/system/kopia-backup.service

cat <<‘EOF’ >/etc/systemd/system/kopia-backup.service
[Unit]
Description=Kopia Backup
After=network-online.target remote-fs.target
Wants=network-online.target remote-fs.target
 
[Service]
Type=oneshot
User=root
Environment=HOME=/root
ExecStart=/usr/local/bin/kopia-backup.sh
EOF
 
systemctl daemon-reload
systemctl start kopia-backup.service
 

Step 11. systemd timer 作成

Cronで回してもいいが、今風だとSystemdのTimerで回す。Cronより確実に回る。
 
15分毎にスナップショットを実行
cat <<‘EOF’ >/etc/systemd/system/kopia-backup.timer
[Unit]
Description=Run Kopia Backup Every 15 Minutes
 
[Timer]
OnBootSec=5min
OnUnitActiveSec=15min
Persistent=true
 
[Install]
WantedBy=timers.target
EOF
 
 

Step 12. timer 有効化

systemctl daemon-reload
 
systemctl enable –now kopia-backup.timer
 
 

Step 13. timer 確認

systemctl list-timers | grep kopia
 
 
次に実行される時間と最後に実行されてからの時間が表示される。（Cronより全然高機能！）
Fri 2026-05-08 14:05:37 UTC 14min Fri 2026-05-08 13:50:37 UTC 5s ago kopia-backup.timer kopia-backup.service
 

Step 14. スクリプトによる手動実行テスト

systemctl start kopia-backup.service
 
 

Step 15. log 確認

tail -f /var/log/kopia/backup.log
 
 
Created snapshot with root kdcd929b635789d97034d553d3f4e3e90 and ID 91f10cd4809561efa45ee6c95dccdaf2 in 0s
Running quick maintenance…
Compacting an eligible uncompacted epoch…
Advancing epoch markers…
Finished quick maintenance.
 
Snapshot exit code: 0
Backup finished: 2026-05-08T16:27:31+00:00
==================================================
 
スナップショットの確認
systemctl list-timers | grep kopia
kopia snapshot list
 
root@nuc5i5ryh:~# systemctl list-timers | grep kopia
Fri 2026-05-08 17:58:31 UTC 7min Fri 2026-05-08 17:43:31 UTC 7min ago kopia-backup.timer kopia-backup.service
 
root@nuc5i5ryh:~# kopia snapshot list
root@nuc5i5ryh:/opt/containers
2026-05-08 13:48:02 UTC kfda5b4614bbaafa0e138198d9d527ad3 294.5 MB drwxr-xr-x files:814 dirs:260 (latest-7,hourly-3)
2026-05-08 16:27:30 UTC kdcd929b635789d97034d553d3f4e3e90 291 MB drwxr-xr-x files:814 dirs:260 (latest-6)
2026-05-08 16:42:30 UTC k17a55974d910ee23b6a55afb4778ee97 291.1 MB drwxr-xr-x files:814 dirs:260 (latest-5)
2026-05-08 16:57:38 UTC k1845f7fa0d64935d1807dbbb50036031 291.2 MB drwxr-xr-x files:814 dirs:260 (latest-4,hourly-2)
2026-05-08 17:12:48 UTC kb74bee5a1047497f674850796f9d04f4 291.2 MB drwxr-xr-x files:814 dirs:260 (latest-3)
2026-05-08 17:28:30 UTC kc956e5afe679b28765da9a0cb81d4e6f 291.3 MB drwxr-xr-x files:814 dirs:260 (latest-2)
2026-05-08 17:43:32 UTC k6c3e13ab3caa4cce81767ac9b23b8345 291.3 MB drwxr-xr-x files:814 dirs:260 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
 
root@nuc5i5ryh:/mnt/nfs/kopia-container-host-backup/nuc5i5ryh# du -sh
322M .
 
 
これでスナップショットの設定は完了
 
 
 

Step 16. restore テスト（重要）

compose.yml restore テスト

まず snapshot 確認：
kopia snapshot list /opt/containers
 
 
root@nuc5i5ryh:/opt/containers
2026-05-08 13:48:02 UTC kfda5b4614bbaafa0e138198d9d527ad3 294.5 MB drwxr-xr-x files:814 dirs:260 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
 

ファイルリストア

/opt/containersの配下を取っているので、/opt/containersがルートになる。
例 /opt/containers/npm/compose.ymlをリストアする場合は、/npm/compose.ymlを指定する。
例：
mkdir -p /tmp/kopia-restore
 
kopia restore \
<snapshot-id>/npm/compose.yml \
/tmp/kopia-restore/
 
 
 
mkdir -p /tmp/kopia-restore
 
kopia restore \
kfda5b4614bbaafa0e138198d9d527ad3/npm/compose.yml \
/tmp/kopia-restore/compose.yml
 

インスタントファイルリストア

Step 1. fuse3 確認

インストール

apt install -y fuse3
 

 

Step 2. mount point 作成

mkdir -p /mnt/kopia
 
 

Step 3. snapshot mount

全 snapshot mount

環境や Kopia のバージョンによって表示構造は多少異なるが、hosts や snapshots 配下から過去データを辿れる。
kopia mount all /mnt/kopia
 
成功すると：
Serving the repository at local directory: /mnt/kopia
 
のようになる。
このターミナルは foreground で動作する。実際のリストアは別ターミナルで。

Step 4. 別ターミナルで確認

find /mnt/kopia | head -50
 
 

典型構造

例えば：
/mnt/kopia/
├── snapshots
├── users
└── hosts
 
 

Step 5. snapshot 探索

compose.yml を探す

find /mnt/kopia -name compose.yml | grep npm
 
例えば：
/mnt/kopia/hosts/nuc5i5ryh/…/npm/compose.yml
 
のように見える。

Step 6. instant recovery テスト

1. 現在ファイル退避

cp \
/opt/containers/npm/compose.yml \
/opt/containers/npm/compose.yml.bak
 
 

2. わざと壊す

echo “# BROKEN” >> /opt/containers/npm/compose.yml
 
 

3. 差分確認

find /mnt/kopia -path ‘*npm/compose.yml’
diff -u \
/opt/containers/npm/compose.yml \
/mnt/kopia/hosts/nuc5i5ryh/任意のsnapshot/npm/compose.yml
 
 

4. instant restore

cp \
/mnt/kopia/hosts/*/*/npm/compose.yml \
/opt/containers/npm/compose.yml
 
 

5. restore 確認

tail /opt/containers/npm/compose.yml
 
# BROKEN が消えていれば成功。

これが強い理由

restore command 不要で：
filesystem copy
だけで戻せる。
 
つまり：
instant file recovery
 
 
例えば、以下のようなケースでは、VM全体を戻さなくてもファイル単位で即復旧できる。
ケース
即戻せるもの
compose壊した
compose.yml
OpenWebUI config破損
data
OpenClaw memory破損
memory
Grafana誤設定
grafana.db
NPM誤変更
data
 

超便利な使い方

過去比較

diff -ru \
/opt/containers/open-webui \
/mnt/kopia/hosts/…/open-webui
 
 

「昨日動いていた状態」

がそのまま見える。

注意点

mount は read-only

なので：
誤更新されない
 
安全。

unmount

終了時：
fusermount3 -u /mnt/kopia
 
 

systemd 常設化も可能

かなりおすすめ。
例えば：
/mnt/kopia-live
 
へ常時 mount。
すると：
過去snapshotを常時参照
 
できる。
 
 

Kopia-UIでの接続

Kopia-UIでは

repository フォルダそのもの
ではなく、
snapshot を GUI から mount
をマウントすることができる。
 
 
Kopia-UIは、以下からダウンロードができる。
Windows, MAC, Linuxなどなんでもあるが、環境に合わせてダウンロードしてインストール。
 
NFSの保存先をマウントするには、KopiaUI（GUI）で
Local Directory or NAS
 
を入力指定する。
 

GUIのホストから見えるパスを入力する。

 
Repositoryパスワードを入力
 
 
これで接続完了
 
接続が完了できると
 
GUIでのリストアができる。ファイルレベルのリストアもインスタントリストアもできる。（ただし、インスタントリストアにはLinuxやMACだとFuseがいるし、Windowsだと役割と機能の追加でWeb Davをサポートさせる必要がある。）
 
ポリシーの変更ができたりする。
 
CLIと同一でCLIコマンドもインストールされる。
 
 
これ、ほんと、騙されたと思ってやっておいた方がいい。バックアップデータは、Repositoryパスワードさえしっかり守っていたら流出することもない。
 
 
Gitは不要とは言っていない。
もちろん、本来はGit管理すべきである。
 
しかし、現実のAIホームラボ運用では、
「試す—> 壊す —> 戻す」
のサイクルが極端に高速化している。それらの多くは、Gitに挙げるほどでもないこともある。Git commit前の試行錯誤状態を保護する仕組みとして、Kopiaのような高速スナップショットはかんり相性が良いのではと思っている。

コメントを残す