Velero

経緯

veleroのバックアップの復元テストをしたかったのだけれども、 あまりにも面倒くさくて、Claude Codeに丸投げした。

復元完了後、veleroのrestores/ に復元レポートが保存される。

使用モデル、かかったコストは以下。CLIからは、/statusからのSessionで表示可能。

/status
  Total cost:            $2.81
  Total duration (API):  8m 28s
  Total duration (wall): 36m 20s
  Total code changes:    362 lines added, 0 lines removed
  Usage by model:
      claude-haiku-4-5:  303 input, 24 output, 0 cache read, 0 cache write ($0.0004)
     claude-sonnet-4-5:  281 input, 22.3k output, 5.1m cache read, 252.0k cache write ($2.80)

Veleroを使ってk8sをCloudflare R2にバックアップしている。

k8sシステムのバックアップは、backups/フォルダ内に日付フォルダが作成されて保存される。 私はバックアップを10日分と設定しており、それより前のフォルダはVeleroが勝手に消してくれる。

PVのバックアップにはVelero内部でkopiaが使われていて、差分バックアップしているらしい。

このバックアップのサイズが日に日に増えていっている。 Velero本体側は古いファイルは確実に消されているが、kopia側は内部がよくわかんない。 その原因を調査すべく、我々はアマゾンの奥地へと向かった。

まず、S3 Browser(https://s3browser.com/)を使用してバックアップサイズを確認する。 PV以外が原因の可能性もあるため(kopiaが原因でない可能性もあるため)、念のため

backups/
31.63 MB (33 166 071 bytes)

kopia/
730.84 MB (766 345 759 bytes)

この時点でkopiaが原因であることは確定だが、もう少し深堀してみる。 Veleroは、namespaceごとにkopiaのバックアップリポジトリを作るらしい。 リポジトリごとのサイズを見てみよう。

kopia/kube-system/
960.84 KB (983 897 bytes)

kopia/default/
149.79 MB (157 062 963 bytes)

kopia/commafeed-k8s/
580.12 MB (608 298 899 bytes)

commafeed-k8sのサイズが大きいので、原因が簡単にわからないか見てみよう。

まず、以下のコマンドでkopiaでリポジトリに接続する。

$ kopia repository connect s3 --bucket=velero-backup \
  --access-key=MY_ACCESSS_KEY \
  --secret-access-key=MY_SECRET_ACCESSS_KEY \
  --endpoint=my_endpoint.r2.cloudflarestorage.com \
  --prefix=kopia/commafeed-k8s/