こんにちは。
今回は、Azure Backup を使ったバックアップの基本の「キ」的なまとめです。
ということで早速ですが、バックアップを計画する際には、どのような復旧計画に基づいたバックアップ計画なのかということがとても大切になります。
これがないと、どのようなバックアップを取得すればいいのか？ということが決められないですし、せっかく取得したバックアップから予定通りの復旧をすることができないっていうケースも出てきちゃいます。
とても、当たり前のことだと思いますが、意外とこの部分をすっ飛ばして落とし穴にはまっている方は少なくないように感じます。
ということで、Azure VM を Azure Backup でバックアップする方法を基に、復旧方法をやり方をご理解いただけるとうれしいです。
Azure Backup を使った復旧方法
以下のドキュメントで、Azure VM を Azure Backup を利用した場合の復旧方法が記載されています。
Create new-create VM：障害が発生した時点のVMは残しておいて、新しくVMを作って復旧する方法です。
VM の復旧を行う場合は、以下のマトリックスになります。
VM の作り方
- Create new ：新たにVM を作る(ひとまず、残しておく)
- Replace Existing ： 今ある VM に上書きする(気持ちよく入れ替える)
VM のリストア方法
- VM の作成
- ストレージに VHD ファイルを作成して、その後ユーザがカスタマイズしながら復旧
Azure Backup のポータルだと、以下の赤枠を選択した場合のオプションですね。
これらは、VM の障害に対して利用する復旧方法です。
VM 自体をリストアするので、復旧時間は割と長くかかるって考えていいと思います。
また、どのオプションを使うかというのは、バックアップを取得した状態から障害が発生するまでの間に発生したデータの扱いや、ネットワーク構成など、リストア計画に影響がでてきます。
上記に追加して、ファイルやフォルダのリストアがあるって感じですね。
ポータルですと、青枠を押した時に利用できます。
これは、文字通り単一もしくは複数のファイルを復旧する方法です。
ファイルの復旧ですので、VM 自体をリストアする方法に比べると比較的短時間で復旧することができます。(つまり障害からの回復時間が短い)
様々な要件によって、これらを使い分けて使う感じになると思います。
Restore VM を利用するケース
Restore VM を使うケースをざっくり言っちゃうと、時間やデータの鮮度はひとまず置いておいて、VM がまっさらな状態からでも復旧させないといけないような場合。
こんなケースが該当すると思います。
- 原因がわからないけど、OS が立ち上がらない
- 原因がわかないけど、ミドルウェアが正常に動作しない
- 他の VM 障害に引きずられて、対象 VM を同じタイミングの状態に戻さなければいけない。(どこまで一緒にすればいいか考えている時間がない)
単体の VM 障害でどうにもならないときに使うのが主目的になるのかなって思います。原因がわかっているならば、パッチをあてるとか設定を変更するとか、そんな方法を使ってリストアはしないですよね。
では、データのみの復元にも使うかというと、ここは考えどころだと思います。というのは、以下のポイントで考慮が必要だからです。
- リストア開始からの復旧時間が長い。(この方法だとすべてのファイルをリストアするので、時間がかかる。)
- バックアップ間隔の最小値が、1日(1日複数回のバックアップを実行するスケジュールを設定できない)
Azure Backup よりも細かいスケジュールで Backup を行う方法としては、追加ディスクに定期的に必要な範囲だけのデータをバックアップをする仕組みを構築し、VM 全体のバックアップは Azure Backup に委ねるなんて方法もありますね。
File Recvery を使う場合
File Recovery を使う場合は、ファイルを復元したい場合です。まぁー、そのまんまですね。
ファイルサーバみたいな環境であれば、誤ってファイルを消してしまった場合の対策になります。ただ、本当にファイルサーバのファイルを復元するだけでしたら、Windows Server であれば、共有フォルダのボリュームシャドーコピー(VSS)を使ってあげた方が、利用者がファイルを復元できるのでとても運用が楽ですよね。もし、VSS に残ってないけど、どうしても必要なんだって場合は、File Recovery を使って管理者が復元するという流れになります。
もう一個が、Restore VM のパターンとの組み合わせの方法的に、アプリケーションが持っているデータを、ダンプしたデータファイルをリストアするときです。
ダンプしたデータを VM に戻してあげて、あとはそれを利用しているアプリケーションに合わせてデータをリストアしてあげるというケースです。
この時に、OS/ミドルウェアが動く状態であれば、それはリストアしないでデータだけをリストアしてあげることで、障害復旧時間を縮めることができます。
ただ、ここまではとっても、オンプレ的な復元ですよね。
クラウド的な復元計画
クラウドの最大の魅力って、壊れたら捨てて新しく置き換えるのが簡単にできることだと思います。
なので、環境が壊れたらどうするか？
答えはわかりますね。捨てちゃえばいいんです。
その代わり、捨てた後にすぐに環境を作れる準備が必要です。ARM テンプレートなどを使って Infrastructure as Code によるインストレーションの自動化、Configuration の自動化、アプリケーションの自動デプロイメントとか。
もちろんこれをやるためには、アプリケーションとデータの分離などシステムアーキも重要になりますね。
この辺については、別記事でまとめたいと思います。
まとめ
バックアップの運用を考える際には、復旧計画が必要で、その計画に合わせてどのようなバックアップを行う必要があるかを少しでもつかんでいただけるとありがたいです。
また、Azure Backup は、Azure の VM だけではなくハイブリッドの構成でも非常に有効なサービスだと考えています。
例えば、オンプレミスとか別クラウドの VM に対してですね。
私がハイブリッド構成で、Azure Backup をオススメするのは、以下の2つが大きな理由です。。
- Microsoft Azure の ストレージは、物理的には 3 つの Disk に保存する仕組みとなっているので、HW トラブルによるデータ損失がない。(消えないバックアップを作ることができる。)
- Microsoft Azure のネットワーク使用時の課金体系が、Micorosft Azureにデータが流入する(バックアップの動作)には課金されず、データをリストアする際にしか課金されない。
逆に、Azure の VM をバックアップする場合に、外部サービスを利用する理由というのは今のところ思いつかないのですが。。。
何かあった時の最後の頼みの綱となるバックアップですので、十分な検討をして頂き、いざというときに困らない構成を組んでおきたいものですね。
コメント