はじめに
この記事はこちらの続きです。
バックアップまでは取れたので、これをAzure Web Appsの機能で復元してみます。
復元を行う前に：復元される範囲の確認
本番環境で復元テストをするわけにもいかないので、テスト環境を用意しています。
バックアップ前に簡単なテスト記事とデザイン変更を行っています。
また、プラグインの有効状態なども戻るか見てみたいと思うので、WordPressに自動でインストールされる、Hello Dollyを有効にしておきました。
この時点でバックアップを取ります。これが復元データになるので、ここまでのデータは保持される想定です。
復元を行う前に：復元されない範囲の確認
バックアップ後に、一つの記事を削除し、別の記事を追加します。キャプチャだとわかりにくくなってしまったのですが、Hello Worldの記事がなくなっています。
また、Akismet Anti-Spamのプラグインを削除してみました。
これらの設定は復元後に削除される想定です。
バックアップデータの復元
では、バックアップデータを復元していってみたいと思います。バックアップデータを確認したうえで、「バックアップ」の「復元」をクリックします。
復元元はアプリのバックアップを選びます。ここでは最新のデータを使います。
復元先は「上書き」と「新規または既存のアプリ」が選べます。復元先スロットは現在一つしかないので選べませんが、ひとまずこのまま進めてみます。
（期待としては復元用のスロットがここで新規作成されるのかなと思うのですが…）
復元操作としてはここでOKを押せば終わりなので、結果を待ちます。
復元結果の確認
復元後、特にAzureのリソースは増えていません。
また、予想と異なり、デプロイスロットも増えていませんでした。デプロイスロット分けて戻したいときは、事前にデプロイスロットを用意しておく必要がありそうです。
コンテンツはバックアップ前に戻っています。
また、プラグインも、バックアップ前の状態に戻っています。
記事はDBに、プラグインファイルはWeb Apps上にあるので、どちらもちゃんと戻っていますね。
バックアップデータの利用方法を考える
Web Appsの機能で復元をかけること自体は簡単に出来ました。
ただし、当然といえば当然ですが、バックアップを復元する際のシナリオを考えないと十分活用できないと感じました。
そのためにはアプリがどういう時にどこにデータを持っていて、どこから戻せるか、の知識が必要ですね。
とはいえ、DBのデータ全損、 Web Apps上のコンテンツをうっかり全削除してしまったといったミス、設定失敗してWordPressに管理者もアクセスできなくなった、というケースには有用だと思います。
一方で、メディアだけ消してしまった、間違って記事を消してしまった、というレベルだと、運用ルールからしっかり考える必要がありそうです。メディアはコンテンツのみ別スロットに復元かZipファイルから抽出できそうですが、記事はデータベースなので特定の記事だけというのは難しそうです。
今回の検証はここまでとなります。
舟越 匠（日本ビジネスシステムズ株式会社）
人材開発部に所属。社内向けの技術研修をメインにしつつ、JBS Tech BlogやMS認定資格取得の推進役もやっています。資格としてはAzure Solutions Architect Expertを所持。好きなサービスはPower Automate / Logic Apps。好きなアーティストはZABADAK。
担当記事一覧