TMCであるクラスタで取ったバックアップを別のクラスタで使う方法を調べた時のメモ。
なお、ここではクラスタの情報が消えた時などを考慮して通常手順であるData Protectionの「RESTORE FROM ANOTHER CLUSTER」に頼らないやり方となっている。（要は変則的）
TMCのバックアップの仕様
Veleroを使ってバックアップしているのだが、どこにバックアップを保存しているかというと、S3のバケット直下ではなく、階層を掘ってバックアップしている。
MinIOに保存したバックアップをmcコマンドで見てみる。
なお、バックアップはvelero-backupというバケットに保存している。
$ mc ls -r tmc-backup
[2023-02-16 19:56:59 JST] 29B STANDARD velero-bucket/01GR5GP72MF984ND40JTWNW6FG/backups/test-backup-tmc/test-backup-tmc-csi-volumesnapshotclasses.json.gz
[2023-02-16 19:56:59 JST] 29B STANDARD velero-bucket/01GR5GP72MF984ND40JTWNW6FG/backups/test-backup-tmc/test-backup-tmc-csi-volumesnapshotcontents.json.gz
[2023-02-16 19:56:58 JST] 29B STANDARD velero-bucket/01GR5GP72MF984ND40JTWNW6FG/backups/test-backup-tmc/test-backup-tmc-csi-volumesnapshots.json.gz
：（省略）
階層を書くと以下のような感じになる。
velero-bucket/
└── 01GR5GP72MF984ND40JTWNW6FG/
├──backups/
| └── test-backup-tmc/
├──restic/
：（省略）
01GR5GP72MF984ND40JTWNW6FGというのが恐らくクラスタ固有につけられた名前で、複数のクラスタが同じバケットにバックアップした際、バックアップオブジェクトが衝突するのを防ぐためにこのようなハッシュ値的な名前をつけているものと思われる。
これはkubernetes内ではbackupstoragelocationsリソース(略称bsl)で管理されており、以下で確認することが出来る。
$ kubectl get bsl -n velero
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT
velero imurata-h2o-location Available 4s 2m49s
これの中身を見ると、このようなものが見つかる。
objectStorage:
bucket: velero-bucket
prefix: 01GR5GP72MF984ND40JTWNW6FG/
ここでバケットの名前とパスを管理している。
TMCで別クラスタのバックアップを利用する
クラスタAとクラスタBで同じTarget Locationを設定してもそれぞれのバックアップは見えない。
これは前述の通りで、
- クラスタAのバックアップ保管先：velero-bucket/01GR5GP72MF984ND40JTWNW6FG/
- クラスタBのバックアップ保管先：velero-bucket/01GSCZS4K72YXZ19CQC07B8TG2/
といった感じでクラスタごとに暗黙的に階層が掘られているからである。
なので、クラスタBの01GSCZS4K72YXZ19CQC07B8TG2をクラスタAのものに書き換えてしまえばよい。
クラスタBでkubectl edit bsl -n velero <Target Location名>を実行してspec.objectStorage.prefixをクラスタAのものに変更して保存する。
保存後、kubectl get bsl -n veleroでLAST VALIDATEDが1周するのを待つ（最大1分）。
$ kubectl get bsl -n velero
NAME PHASE LAST VALIDATED AGE DEFAULT
imurata-h2o-location Available 52s 3h58m
1周したら、TMC側でバックアップが見えるようになっていることが確認できる。
