みなさまこんにちは！ネットワールドSEの長岡です。
Part2から引き続き、「BlueXP backup and recovery」をAWS環境で使ってオンプレのデータをバックアップしてみた！ということでご紹介していきたいと思います。
前回はConnector編でした。
Part3ではバックアップ編で行こうと思います。
backup and recoveryの説明はこちら
ふむふむなるほど、読むのが大変。
私はゲームは説明書読まずにまずやってみる派です。
ということでまずはやってみていきましょう。
BlueXPログイン後の「+ Add Working Environment」を押して、On-PremisesのDiscoverを押します。
オンプレミスNetAppの登録をしていきます。
ここのIPは「Cluster mgmt LIF」のIPを入力します。
環境は様々かと思いますが、今回の検証環境ではインターネットVPNなため、
オンプレミスNetAppにはインターネット通信できるrouteを追加しております。
これはデータ用のSVMではなく、ClusterのSVMに追加してあげる必要があります。
その他にもSnapMirrorのライセンスが必要、ONTAPのバージョン、ネットワーク要件などがありますので、詳細はドキュメントをご確認ください。
ちなみに、バックアップの転送で使用するインターフェイスは、「Intercluster LIF」を使います。（SnapMirrorなどで使うLIFになります）
なので、オンプレミスのNetAppには予め「Intercluster LIF」をNodeごとに1つ、作成しておきましょう。
登録が成功すると、オンプレミスのNetApp君がひょっこり現れます。
続けてBlueXP画面左のメニューから、「Protection」→「Backup and recovery」→「Volume」を押していきましょう。
なんだかそれっぽい画面が出てきました。
もう既にちょっと満足感（早い）
画面を下にスクロールすると、オンプレミスNetApp内にあるVolume達が見えてきます。
バックアップを取りたいVolumeを選択し、Bulk actions:の「Manage Backup」をクリックします。
Continueで進めます。
Providerを選びます。もちろんAWSで。
Provider Settingsでは、AWS関連の情報を入力していきます。
バックアップを保存するS3バケットは、ここから作成することもできますし、
今あるバケットを選択することもできます。
検証では今あるバケットを選択しております。
ちなみに、バケットの名前は先頭に、「netapp-backup」を付ける必要があるようです。
検証初期の頃は特に意識せずバケット名つけておりましたが、あとからドキュメントを熟読していくとコッソリ記載がありました。
更にちなみに・・・今回の環境はインターネットVPNなので意識しないのですが、もし環境がAWS Private Linkを使っていて、プライベートエンドポイントとの通信にポート443（HTTPS）を使用している場合は、VPC S3エンドポイントから証明書をコピーし、オンプレミスNetAppに追加してあげる必要があるようです。
（ポート80（HTTP）の場合は必要なし）
この辺りはドキュメントの熟読をお勧めします（手抜き）
次にBackup Policyを決めていきます。
デフォルトで用意されているものはこちら。
何が違うの？というご質問はもっともです。
これらは、オンプレミスNetAppに元々いるsnapmirror policyになっております。
詳しく見てみましょう。
コマンドで見た詳細はこちら。
「CloudBackupDefault」と「DailyBackup」はSnapMirror Labelがdailyなものを7世代保持するポリシーで、「XDPDefault」はSnapMirror Labelがdailyなものを7世代保持、weeklyなものを52世代保持するポリシーになっているようですね。
「CloudBackupDefault」と「DailyBackup」の違いは自動的に差分転送するかしないかの違いのようです。
ここで勘が鋭い方はお気づきかもしれませんが、すべてPolicyTypeがvaultになっております。
そうなのです、BlueXP backup and recoveryとはクラウドへバックアップするSnapVaultのことだったのです！（ドヤ顔）
一般的にNetAppのONTAPでよく使われるものはSnapMirrorかと思います。
policy-typeでいうとasync-mirrorやmirror-vaultになりますね。
災害対策にも使われていて、別の筐体へレプリケーションをして、いざってときは運用を切り替えて使えたりしてとても便利ですよね。
対してSnapVaultは主にアーカイブ目的で利用されており、複製されたVolumeはR/Oのみで書き込みはできませんが、元のVolumeよりもより多くのSnapshotを世代保存が可能です。
そしてそのSnapVaultを使うときに必要なのが、SnapMirror Labelの設定になります。
（なんだか説明が細かくなってきた・・・）
SnapMirror LabelはオンプレミスNetAppのSnapshot Policyに設定するものになります。
これをやっておかないと、BlueXP backup and recoveryでバックアップを行っても世代管理をしてくれず、悲しい結果になってしまいます。
オンプレミスNetAppでVolumeを作成すると、デフォルトでは「default」という"snapshot policy"が適用されます。
これを細かく見てみると、実はSnapMirror Labelが設定されているんですね。
なので、何も考えずにVolumeを作ってsnapshot policyは「default」になっており、
BackupのPolicyは「DailyBackup」を選んでおくと、自動的に毎日夜間に差分転送され、
dailyのSnapshotがBlueXP backup and recoveryでは7世代保持される、といった内容となります。
もちろん別のポリシーを作成して世代数などを変えることもできますので、この辺りは柔軟に変更可能です。
1つ注意点としてはこういった仕組み上、オンプレミスNetAppには必ずSnapshotが1世代は必要になるということと、1世代としていた場合でもBlueXP backup and recoveryを行う限り直近のSnapshotは転送用にLockされるので削除ができず、どうしても最低2世代になるのでご注意ください。
（ややこしい記載になってしまいましたが、オンプレミスNetAppでSnapshotなしはできないよってことが伝わると嬉しいです）
すみません、脱線しましたが、続きいきましょう！
最後に「Active Backup」を押して完了です。
最初はSnapMirrorと同じで、初期同期が実施されます。
これにかかる時間はデータ量次第ですが、オンプレミスNetAppの「snapmirror show」でどんな感じか確認可能です。
こちらは初期同期が終わった状態です。
（隠している部分はバケット名になります）
S3バケットを直接覗いてみるとこんな形になります。
何にもわからないので意識する必要はなさそうです。
あんまり大量のデータがずっと流れるのは困るなぁ・・・とお困りですか？
安心してください！ありますよ！
backup and recoveryの画面から「Backup Settings」→「Advanced Settings」と移動すると、「Max Transfer Rate」という項目があり、ここで帯域制御をかけることも可能です。
ちなみにここでいれた設定値は、オンプレミスNetAppのoptionsの中の「replication.throttle.outgoing.max_kbs_objstore」に反映される感じのようです。
それではPart3はここまでで、次回Part4はリストア編をお送りしようと思います。
ありがとうございました。
過去作はこちら。
Part1
Part2
