はじめに
IBM CloudのVPCの仮想サーバーにアタッチしたBlock bolumeには、"Retention Policy"というバックアップ世代管理のポリシーをつけることができます。一番古い世代のバックアップが削除される時は、それ以前の世代のバックアップとマージされているのか、挙動を確認してみました。
用意するリソース
- VSI for VPC
- 2vCPU, 4GiB
- CentOS Stream9
- Boot volume 100GB
- Backup policy for VPC
手順
1. VSIの最初のリソース容量を確認
作成したVSIにSSH接続し、ファイルシステムごとのリソース容量を確認してみます。
df -h --total
VSI作成時点では合計2.2GB使用されていました。
ダミーデータを5GB分追加してみます。
dd if=/dev/zero of=1G.dummy bs=1M count=1000
今回は1Gずつ追加しました。
合計7.1GBになりました。
2. Backup Policyの作成
バックアップの頻度、世代数などのポリシーを作成し、仮想サーバーのストレージボリュームに適用します。
Infrastructure> Storage> Backup Policies
ポリシーに定義されたスケジュールに合わせてバックアップを自動的に取得してくれます。
- ロケーション：東京
- 詳細：ポリシーの名前、リソースグループを指定(後から変更できないので注意)
- 対象リソースの種類：個別のBlock Volume
- 今回は「backup-egawa」タグのついたリソースに対してこのポリシーを割り当てています。今回バックアップ取得対象とするBlock storageにもこのタグをつけておきます。
- バックアッププラン
- 1時間に1回バックアップされ、3世代分が保持されるポリシーを作成しました。
Create backup policyをクリックして作成します。
Backup policyを適用すると、Applied resourceに先ほどタグ付けしたBlock storageのBoot volumeが表示されます。
3. バックアップ挙動確認
Policy適用直後は、まだBackupが取られておらず空の状態です。
2時間後に再度見てみると、2つバックアップが取られていました。
1世代目(10:39)は7GBなので、手順1のコマンドで確認した通りBlock storageの最初の容量と同等です。
2世代目(11:39)は1GBとあります。この1時間(1世代目〜2世代目の間)にダミーデータは追加していません。
続いて、4世代目(13:39)が取られると、1世代目(10:39)が自動削除されます。
このタイミングで2世代目(11:39)が1GB→2GBになりました。
7GB(1世代目)+1GB(2世代目)で8GBになると予想していましたが、単純に削除される一番古い世代の容量とその次の世代の容量が足されるわけでは無いようです。
わかったこと・考えられること
- Block storage for VPCのバックアップは、単純に削除される一番古い世代の容量とその次の世代の容量が足されるわけでは無い
- バックアップは増分のみが表示されるが、リストア時には増分のみでなく全てのデータが必要
- その容量はユーザーからは見ることができないが、最新のバックアップから完全なリストアができることを考えると、IBM Cloudが裏側でリストアに必要なデータを管理していると考えられる