Azure バックアップ センターを使ってみた

 

Azure バックアップセンターのプレビューが開始されていたので試してみました。

Azure バックアップ センターでは、Azure で管理されるバックアップを一元的に管理する事が出来ます。

    • Azure バックアップセンター

https://docs.microsoft.com/ja-jp/azure/backup/backup-center-overview

特徴はAzureサブスクリプション内(複数のRecovery Serviceコンテナー)の情報を一元的に見る事が出来ます、具体的にはこんな感じの事が出来ます。

      • サブスクリプション内のバックアップアイテムを一覧表示する
      • サブスクリプション内のバックアップジョブ実行結果を一覧表示する
      • Recovery Serviceコンテナーで使用しているバックアップデータ容量(データ転送量時含む)をサマリや一覧表示する。

サブスクリプション内のバックアップジョブ実行結果がすべて一覧表示する事が出来る等、非常に便利な機能となっています。

※現時点では、Recovery Service コンテナーとAzure Database For PostgreSQLでバックアップを取得されるものが対象のようです。

1.Azure バックアップセンターを試してみる

Azure バックアップセンターのメニューを選択すると概要の画面が表示されます。

画面で、過去24時間のバックアップジョブ実行結果やバックアップ対象の数が表示されます。

リンクもちゃんとしており、ジョブ画面の数字を選択するとバックアップジョブの画面へ遷移出来ます。

管理のメニューではサブスクリプション内のRecovery Service コンテナーの情報が見れます。

      • インスタンスのバックアップ:バックアップアイテムの一覧
      • バックアップポリシー:バックアップポリシーの一覧
      • コンテナー:Recovery Service コンテナーの一覧

インスタンスのバックアップを選択するとバックアップ対象と保護状況が一覧表示されます。(別の複数のバックアップアイテムがある環境で見た際もすべて一覧表示されました。)

バックアップポリシーの画面では存在するバックアップポリシーの一覧が表示されます。

※Recovery Service コンテナーが複数の場合等では、DefaultPolicyが一杯並んだりします。(削除していない場合)

コンテナーでは、Recovery Service コンテナーの一覧が表示されます。

監視のメニューではバックアップ実行結果等の情報が見れます。

      • バックアップジョブ:バックアップジョブ実行結果一覧
      • バックアップレポート:バックアップに関する詳細な情報

まず、バックアップジョブでは、すべてのバックアップアイテムのバックアップ状況が表示されます。

※日々のバックアップ設定していない場合でも最終取得日時が表示されます。

バックアップレポートは、Recovery Service コンテナーの診断設定で取得される情報を利用してさらに詳細な情報が確認出来ます。こちらは次の章に記載します。

2.Azure バックアップセンターのバックアップリポートを使うと、Log Analyticsワークスペースからデータ取得して色んな情報が見れます

バックアップレポートではRecovery Service コンテナーの診断設定されたLog Analyticsワークスペースからデータを取得してデータ表示します。

事前にRecovery Service コンテナーの診断設定でLog AnalyticsワークスペースへのLog転送設定を行います。その転送先のLog AnalyticsワークスペースをバックアップレポートのLog Analyticsワークスペースとして選択します。

※指定するのはAzure VMではなく、Recovery Service コンテナーの診断設定転送先になります。

設定後、バックアップレポートの画面でまとめのタブを選択すると、情報が取得出来ている事が分かります。

まとめのタブでは、バックアップアイテムの数や、使用しているストレージ容量(バックアップ)が吹応じされます。

 

バックアップ項目のタブを選択すると、バックアップストレージの利用量の推移等が確認できます。

ジョブのタブを選択すると時系列での表示や成功率、バックアップジョブ単位での転送量等が表示されます。バックアップジョブのメニューで表示される内容より詳細な内容が確認出来ます。

※Log Analyticsワークスペースから情報を取得していますので、診断設定をしていない場合や、別のLog Analyticsワークスペースへ接続しているRecovery Service コンテナーの情報は含まれません。

Azure VMのバックアップジョブ監視

 

Azure VMのバックアップジョブ監視について試してみました。

Azure VMのバックアップ設定はRecovery Services コンテナーにあり、実行ジョブ結果もAzure Portal上で確認可能出来ます。。。

ですが、Azure Monitorの設定を確認をするとバックアップジョブの監視設定がRecovery Services コンテナーのメトリックには存在しません。

Recovery Services コンテナーで取得されるログをLog Analyticsワークスペースへ転送する事でバックアップジョブの監視をAzure Monitorで行う事が出来ます。

今回実施した内容はこちらになります。

      • Recovery Services コンテナーの診断設定
      • Log Analyticsワークスペースでバックアップログの確認
      • Azure Monitorでの監視設定

Recovery Services コンテナーを使ったAzure VMのバックアップ設定はこちらに記載しております。

Azure VMのバックアップ設定

1.Recovery Services コンテナーの診断設定を使ってLog Analyticsへログ転送する

Recovery Services コンテナーのログをLog Analyticsワークスペースへ転送する設定を行います。Log Analyticsへの転送は診断設定で行います。

1)Recovery Services コンテナーを開き診断設定を選択すると下記画面が表示されますので、診断設定を追加するを選択します。

2)診断設定の画面では以下の項目にチェックを選択します。

      • log(以下の項目にチェック)
        • CoreAzureBackup
        • AddonAzureBackupJobs
        • AddonAzureBackupAlerts
        • AddonAzureBackupPolicy
        • AddonAzureBackupStorage
        • AddonAzureBackupProtectedInstance
      • Log Analyticsへの転送:チェックを入れる
        • Log Analyticsワークスペース:転送先を選択
        • ターゲットテーブル:リソース固有

なお、バックアップジョブの監視だけであれば、AddonAzureBackupJobs​のみにチェックで大丈夫です。

これでLog Analyticsワークスペースへのログ転送設定は完了です。

2.Log AnalyticsでRecovery Services コンテナーのログを確認する

Recovery Services コンテナーのログをLog Analyticsで確認します。

バックアップジョブの結果が確認できるログは、AddonAzureBackupJobs​になります。

転送先に指定した、Log Analyticsワークスペースで以下の通りクエリを入力し実行するとバックアップジョブの実行結果が表示されます。

AddonAzureBackupJobs​

| where JobOperation==”Backup”​

バックアップジョブの実行結果はJobStatusで確認します。

        • Complatedの場合はバックアップ成功
        • Failedの場合はバックアップ失敗

この結果を使って、バックアップ失敗時に通知するような設定をAzure Monitorを使って行ってみたいと思います。

3 .Azure VMのバックアップジョブの実行結果をAzure Monitorで監視する

Azure VMのバックアップ監視設定を行います。

今回はバックアップジョブが成功した場合にアラート発生させるようにしています。(意図的に失敗させての確認出来ないのので。。。)

Recovery Services コンテナーのログを転送しているLog Analyticsワークスペースで警告を選択します。

下記画面が表示されるので、新しいアラートルールを選択します。

アラートルールの作成画面が表示されますので、条件の選択をクリックします。

システムロジックの構成画面が表示されますので、Custom Log Searchを選択します。

詳細の入力画面が表示されますので、以下の通り設定します。

検索クエリに以下の通り設定します。

1時間以内に、1VMに対して1回でもバックアップが成功した場合にカウントが発生するクエリとしています。

AddonAzureBackupJobs

| where JobOperation==”Backup”
| where TimeGenerated > ago(1h)
| summarize countif(JobStatus==”Completed”) by BackupItemUniqueId​
| where countif_ > 0

上記クエリを1時間に1回実行し成功結果が1回でもあればアラート発生するよいうに構成しています。

アクショングループやアラートルール名を適時設定し、完了したらアラートルールの作成をクリックします。

これでアラートルールの作成は完了です。

.Azure MonitorでRecovery Services コンテナーのバックアップジョブ実行結果を監視した結果

バックアップジョブで成功した場合にアラートメールでの通知設定した後に実際の確認してみました。

無事以下のような形でメールを受信する事が出来ました。今回の設定の場合、実際のメール本文には下記のような内容が記載されます。

      • BackupItemUniqueId ロケーション名;JOB関連の情報;リソースグループ名;VM名
      • countif_ 成功回数

今回はバックアップジョブの成功を条件にしていますが、Failedを条件にすると失敗の場合にアラート通知も同様に実現出来そうです。

Azure VMのバックアップ設定

 

Azure VMのバックアップ設定について試してみました。

Azure VMのシステムバックアップとして、Azure backupを利用してRecovery Services コンテナーにバックアップデータを保管する構成でやってみました。

    • 各サービスに関するマイクロソフト様解説サイト
      • Azure バックアップ

https://docs.microsoft.com/ja-jp/azure/backup/backup-overview

      • Azure Recovery Services コンテナー

https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-recovery-services-vault-overview

Azure Portal上で確認するとわかるのですが、Azure VMのバックアップ設定自体はAzure Recovery Services コンテナーになります。

Azure Portalで実施する場合は、以下の2つのメニューから実施出来ます。

      • 仮想マシンのメニューからの設定
      • Recovery Services コンテナーのメニューからの設定

Recovery Services コンテナーのメニューから設定すると、複数のAzure VMを設定が可能です。

1.Azure VMのバックアップを仮想マシンのメニューから設定する

仮想マシンのメニューでバックアップを選択すると、バックアップの設定が行えます。

      • Recovery Services コンテナー(新規作成か既存のものを選択)
      • リソースグループ:新規作成の場合のみ指定
      • バックアップポリシーの選択

下記画面ではBackupというRecovery Services コンテナーを新規作成し、バックアップポリシーをデフォルトにしています。

設定自体はこれで完了です。

2.Azure VMのバックアップをRecovery Services コンテナーのメニューから設定する

Recovery Services コンテナーのメニューからAzure VMのバックアップ設定を行ってみます。

Recovery Services コンテナー自体の作成はこちらで試しております。

ARMテンプレートを使ってAzure Recovery Services コンテナーをデプロイ

Azure VMのバックアップ先となるRecovery Services コンテナーを選択すると概要が表示されます。バックアップをクリックします。

バックアップの目標が表示されます。以下の通り選択しバックアップをクリックします。

      • ワークロード:Azure
      • 何をバックアップしますか?:仮想マシン

 

バックアップの画面が表示されます。実施するのは下記2つになります。

      • バックアップポリシーの作成
      • バックアップ対象の仮想マシンを選択

まず、バックアップポリシーの作成を行ってみます。

バックアップの画面で新しいポリシーを作成するを選択すると、バックアップポリシーの設定画面が表示されます。

今回は以下の内容で設定しています。

      • ポリシー名:Backup01
      • バックアップスケジュール
        • 頻度:毎日
        • 時刻:2:00
        • タイムゾーン:日本時間
      • インスタントリストア
        • インスタント回復スナップショットの保持期間:1日
      • 保持期間:10日

設定画面はこのような感じになります。OKをクリックすれば設定は完了です。

次にバックアップ対象の仮想マシンの選択を行います。

バックアップの画面で追加をクリックすると仮想マシンの選択画面が表示されますので、バックアップ対象のAzure VMを選択します。

   

最後に、バックアップの画面で、バックアップの有効化をクリックすればAzure VMのバックアップ設定が完了です。

バックアップジョブの監視の監視についてはこちらで試しております。

Azure VMのバックアップジョブ監視

—–

3.Azure VMの初回バックアップを取得する

設定が終わった仮想マシンのメニューでバックアップを選択すると下記画面が表示されます。

Azure VMのバックアップ設定を行った段階では、初回バックアップは取得されておらず警告メッセージが表示されています。

今すぐバックアップで初回バックアップを取得すればAuzre VMのバックアップが開始されます。

初回バックアップ取得が完了した時点で、警告のメッセージは表示されなくなります。

4.Azure VMのバックアップを停止する

Azure VMのバックアップ停止を行う場合はバックアップの停止を行います。

バックアップ停止対象の仮想マシンのメニューでバックアップを選択すると下記画面が表示されます。バックアップの停止をクリックします。

バックアップの停止の画面が表示されます。

      • バックアップデータの保持:バックアップのジョブだけが削除され、取得済みのバックアップデータは保持されます。(課金は停止しません。)
      • バックアップデータの削除:バックアップジョブ、バックアップデータ共に削除されます。(課金も停止します。)

バックアップデータが必要が無ければ削除を選択します。バックアップの停止をクリックすればバックアップが停止します。

ARMテンプレートを使ってAzure Recovery Services コンテナーをデプロイ

 

Azure Recovery Services コンテナーはAzure VM等のバックアップやリストアに使用されるAzureのサービスです。

色々な機能が提供されていますので、機能内容はマイクロソフト様のサイトでご確認下さい。自分はシンプルにバックアップソフトとバックアップストレージがセットで提供されるサービスと理解しています。

https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-recovery-services-vault-overview

今回は、Azure Recovery Services コンテナー作成を、Azure PortalとAzure Resource Manager(ARM)テンプレートを利用して実施してみました。

Azure Portalで実施した内容を踏まえて、ARMテンプレートでのデプロイをやっていみました。

ARMテンプレートを使ってデプロイするにあたっては、以下の3つのファイルを作成しています。

      • Azure Recovery Services コンテナーを定義するARMテンプレート(JSONファイル)
      • Azure Recovery Services コンテナーのパラメータを指定するCSV
      • ARMテンプレートをデプロイするPower Shell

ARMテンプレートを使った場合は、複数のコンテナーを一括でデプロイできるようにパラメータをCSVから読み込むようにしています。

作成したものは GitHub上にも公開しております。

https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/RecoveryServices_20200522

今回はRecovery Services コンテナーの作成のみを実施しております。Azure VMのバックアップ設定についてはこちらに記載しております。

Azure VMのバックアップ設定

—–

1 .Azure Portal上でRecovery Services コンテナーを新規作成する

Azure Portalを利用したRecovery Services コンテナーを作成は以下の手順で実施しました。

      • Recovery Services コンテナーの作成
      • バックアップ ストレージの冗長選択(ローカル冗長ストレージ (LRS) と Geo 冗長ストレージ (GRS))
      • 論理削除(14日間保持)、物理削除(即時削除)の選択

バックアップストレージの冗長選択はバックアップ設定した後では変更不可である為最初に設定します。また、論理削除にしておくと、Recovery Services コンテナーが削除が論理的にデータ保存されている14日間出来なくなります。その為必要に応じて設定変更します。

Azure Portalを利用した作成手順はマイクロソフト様のサイトに公開されています。今回は勉強もかねて実施してみました。

https://docs.microsoft.com/ja-jp/azure/backup/backup-create-rs-vault

最初に、Recovery Services コンテナーの作成を行います。

Azure Portal上のすべてのサービスでRecoveryと入力すると、Recovery Services コンテナーのメニューが表示されれますのでこれを選択します。

Recovery Services コンテナーに移動しますので、+追加をクリックします。

一般的な使い方で指定するのは、以下の内容になるかと思います。実際に利用するリソースに合わせて設定します。

      • リソースグループ
      • 資格情報コンテナー名(名前ですね。)
      • リージョン
      • タグ(プレビューで追加になってました。)

まず、リソースグループ、資格情報コンテナー名、リージョンを選択し、次へクリックします。

次にタグの設定を必要に応じて実施します。

設定したら、確認および作成をクリックします。確認画面が表示されますので、作成をクリックします。Recovery Services コンテナーが作成されます。

Recovery Services コンテナーで作成後に、最初にやるべき設定として2つあります。利用環境に応じて適時設定します。

      • 冗長設定(Geo冗長→ローカル冗長)
      • セキュリティ設定(論理削除→物理削除)

作成したRecovery Services コンテナーのメニューにあるプロパティを選択します。

バックアップ構成という項目が表示されているかと思います。ここで更新をクリックします。下記画面が表示されます。ストレージレプリケーションの種類を選択します。

デフォルトGeo冗長になっております。

別リージョンにリカバリするやDCが全部吹っ飛んでもリカバリするんだ、というような別リージョンに保管する要件が無い場合はローカル冗長(LRS)に変更します。

マイクロソフト様のサイトを見て頂ければわかりますが、料金が2倍違います。(保管場所が2重になるので、容量も2倍。という事で料金も2倍という事だと思います。。。)

https://azure.microsoft.com/ja-jp/pricing/details/backup/

設定変更した場合は、忘れずに保存します。

次に、セキュリティ設定を行います。

即時物理削除したい場合は、論理削除を無効に設定します。こちらは後からでも変更可能です

設定変更した場合は保存します。論理削除の保存期間は14日間固定のようで変更はできないようです。

.Recovery Services コンテナーのAzure Resource Manager(ARM)テンプレート

マイクロソフト様が公開されているARMテンプレートを参考にし、デフォルト値のみを変更しています。

https://github.com/Azure/azure-quickstart-templates/blob/master/101-recovery-services-vault-create/azuredeploy.json

https://docs.microsoft.com/ja-jp/azure/site-recovery/quickstart-create-vault-template?tabs=CLI

基本は参考通りなのですが、以下の点だけ修正しています。

    • バックアップ構成のデフォルト値をローカル冗長になるようにしています。
    • バックアップアラート部分等は設定してません。
    • TAGの設定はしていません。
    • 論理削除はデフォルトの通り有効になります。(無効にする方法が見当たりませんでした。)

skuNameと、skuTierは固定値になります。その為、Parametersの指定ではなく、variablesでの指定としています。

ARMテンプレートでは、バックアップポリシーの規定をしてませんが、Azure Portalを利用して作成した時と同様に、HourlyLogBackupとDefaultPolicyは作成されます。

Recovery Services コンテナーのARMテンプレートはこういう形になりました。

{
  “$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#”,
  “contentVersion”: “1.0.0.0”,
  “parameters”: {
    “vaultName”: {
      “type”: “string”,
      “metadata”: {}
   },
    “changeStorageType”: {
      “type”: “bool”,
      “defaultValue”: true ,
      “metadata”: {}
    },
    “vaultStorageType”: {
      “type”: “string”,
      “defaultValue”: “LocallyRedundant”,
      “allowedValues”: [
        “LocallyRedundant”,
        “GloballyRedundant”
      ],
      “metadata”: {}
    },
    “location”: {
      “type”: “string”,
      “defaultValue”: “[resourceGroup().location]”,
      “metadata”: {}
    }
  },
  “variables”: {
    “skuName”: “RS0”,
    “skuTier”: “Standard”
  },
 “resources”: [
   {
     “type”: “Microsoft.RecoveryServices/vaults”,
     “apiVersion”: “2018-01-10”,
     “name”: “[parameters(‘vaultName’)]”,
     “location”: “[parameters(‘location’)]”,
     “sku”: {
       “name”: “[variables(‘skuName’)]”,
       “tier”: “[variables(‘skuTier’)]”
     },
   “properties”: {}
   },
   {
     “condition”: “[parameters(‘changeStorageType’)]”,
     “type”: “Microsoft.RecoveryServices/vaults/backupstorageconfig”,
     “apiVersion”: “2018-01-10”,
     “name”: “[concat(parameters(‘vaultName’), ‘/vaultstorageconfig’)]”,
     “dependsOn”: [
         “[resourceId(‘Microsoft.RecoveryServices/vaults/’, parameters(‘vaultName’))]”
     ],
     “properties”: {
         “StorageModelType”:”[parameters(‘vaultStorageType’)]”
     }
   }
 ]
}

3.Azure Recovery Services コンテナーのパラメータ設定CSV作成する

Azure Recovery Services コンテナーを作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ(ResourceGroupName)
    • リージョン(location)
    • コンテナー名(vaultName)
    • ストレージの種類の変更(changeStorageType)
    • コンテナー ストレージの種類(vaultStorageType)

ストレージの種類の変更と、コンテナーストレージの種類の組み合わせは下記の通りになります。

    • ローカル冗長の場合は、changeStorageTypeをTrue、vaultStorageTypeをLocallyRedundantに指定します。
    • Geo冗長のの場合は、changeStorageTypeをfalse、vaultStorageTypeをGloballyRedundantに指定します。

上記を踏まえてCSVをサンプルで作成以下のようになります。

RG1にローカル冗長、RG2にGeo冗長でデプロイする想定にしています。

ResourceGroupName,location,vaultName,changeStorageType,vaultStorageType
RG1,japaneast,rsc-01,true,LocallyRedundant
RG2,japanwest,rsc-02,false,GloballyRedundant

4.Azure Recovery Services コンテナーをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してデプロイを実施します。

changeStorageTypeについては、bool形式である為そのままCSVを読み込むとエラーになりました。調べた結果、明示的にBool指定が必要だという事がわかりましたので、# Bool Value行でStriingからBoolに変換しエラーにならないようにしています。

#RecoveryServicesコンテナー Template Deploy

$TemplateFilePath = “ARMテンプレートファイルのパス”
$ImportCSVPath = “パラメータを指定するCSVファイルのパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath 

# Template Deploy
foreach( $c in $csv ){

# Bool Value
[Bool]$boolValue = [System.Convert]::ToBoolean($c.changeStorageType)

# Deploy Command
New-AzResourceGroupDeployment `
  -ResourceGroupName $c.ResourceGroupName `
  -TemplateFile $TemplateFilePath `
  -location $c.location `
  -changeStorageType $boolValue `
  -vaultStorageType $c.vaultStorageType `
  -vaultName $c.vaultName
}

デプロイが成功すると、Power Shellの実行ログにProvisioningState : Succeededと表示され、実際にAzure Portal上で確認すると設定通り出来ている事が確認できました。

ARMテンプレートを使った場合は、論理削除の設定は有効になっています。