今回はSQL Serverが稼働しているVMも通常の仮想マシンと同じバックアップポリシーでバックアップを取得したらどうなるか実験してみます。
まず復元するためにはストレージアカウントを作成しておく必要があるため、新規に作成します。
ストレージアカウントアカウントができたら、バックアップから復元してみます。
復元ポイントの整合性は「クラッシュコンシステント」と「アプリケーションコンシステント」というのがありました。これらの違いはWindows OSのVSSによる整合性があるかないかの違いのようです。「クラッシュコンシステント」はVSSの整合性なし。「アプリケーションコンシステント」は整合性ありとなります。
今回、午後5:50に取得したバックアップはVMを起動したまま取得したのですが、午後9:00の方はVMを停止した状態でした。停止した状態の方がなんとなく、整合性がとれていそうなんですが、VSSが起動していないということでクラッシュコンシステントになっていると思われます。
今回はVMが起動している状態で取得したバックアップ（アプリケーションコンシステント）の方から復元してみます。
仮想マシン名を新たに設定し、別名のVMとして復元します。
先ほど作成したストレージアカウントを選択します。
復元はRecovery Servicesコンテナーのバックアップジョブから確認できます。
復元は13分ほどで完了しました。
復元したVMに早速ログインしてみます。
無事復元されていましたが、ホスト名はバックアップ取得時のもの（freesql）だったので、
本番環境と並行して起動させる場合は、別のネットワークに所属させたほうが良いかもしれません。
バックアップ取得中にトランザクションを開始していたのですが、
ロールバックされた状態で復元しました。
0 件のコメント:
コメントを投稿