災害復旧ワークフロー
企業は、災害復旧のための実行可能なリソースおよび目的地としてパブリック クラウドを採用しています。 SnapCenter は、このプロセスを可能な限りシームレスにします。この災害復旧ワークフローはクローンワークフローと非常に似ていますが、データベース復旧はクラウドに複製された最新の利用可能なログを通じて実行され、可能なすべてのビジネストランザクションを復旧します。ただし、災害復旧に特有の追加の事前構成手順と事後構成手順があります。
オンプレミスの Oracle 本番環境 DB を DR 用にクラウドにクローンする
-
クローンリカバリが利用可能な最後のログを通じて実行されることを検証するために、小さなテスト テーブルを作成し、行を挿入しました。テスト データは、最後に利用可能なログに完全に回復した後に回復されます。
-
Oracle のデータベース管理ユーザー ID としてSnapCenterにログインします。 [リソース] タブに移動すると、 SnapCenterによって保護されている Oracle データベースが表示されます。
-
Oracle ログ リソース グループを選択し、[今すぐバックアップ] をクリックして、Oracle ログ バックアップを手動で実行し、最新のトランザクションをクラウド内の宛先にフラッシュします。実際の DR シナリオでは、回復可能な最後のトランザクションは、クラウドへのデータベース ログ ボリュームのレプリケーション頻度によって決まり、これは企業の RTO または RPO ポリシーによって決まります。
非同期SnapMirror、災害復旧シナリオにおいて、データベース ログ バックアップ間隔内にクラウドの宛先に到達しなかったデータが失われます。データの損失を最小限に抑えるために、より頻繁なログ バックアップをスケジュールできます。ただし、技術的に達成可能なログ バックアップ頻度には制限があります。 -
セカンダリ ミラー バックアップ上の最後のログ バックアップを選択し、ログ バックアップをマウントします。
-
最後の完全なデータベース バックアップを選択し、[クローン] をクリックしてクローン ワークフローを開始します。
-
ホスト上の一意のクローン DB ID を選択します。
-
ログ ボリュームをプロビジョニングし、Oracle フラッシュ リカバリ領域とオンライン ログのターゲット DR サーバーにマウントします。
Oracle クローン手順ではログ ボリュームは作成されないため、クローン作成前に DR サーバーにプロビジョニングする必要があります。 -
データ ファイル、制御ファイル、および REDO ログを配置するターゲット クローン ホストと場所を選択します。
-
クローンの資格情報を選択します。ターゲット サーバーの Oracle ホーム構成の詳細を入力します。
-
クローン作成前に実行するスクリプトを指定します。必要に応じてデータベース パラメータを調整できます。
-
リカバリ オプションとして [キャンセルまで] を選択すると、利用可能なすべてのアーカイブ ログを通じてリカバリが実行され、セカンダリ クラウド ロケーションに複製された最後のトランザクションが回復されます。
-
必要に応じて、電子メール通知用に SMTP サーバーを構成します。
-
DR クローンの概要。
-
クローンされた DB はクローン完了後すぐにSnapCenterに登録され、バックアップ保護に使用できるようになります。
Oracle の DR 後のクローン検証と構成
-
クラウド内の DR ロケーションでフラッシュ、複製、回復された最後のテスト トランザクションを検証します。
-
フラッシュリカバリ領域を構成します。
-
ユーザー アクセス用に Oracle リスナーを構成します。
-
複製されたソース ボリュームからクローン ボリュームを分割します。
-
クラウドからオンプレミスへのレプリケーションを元に戻し、障害が発生したオンプレミスのデータベース サーバーを再構築します。
|
クローン分割により、通常の操作よりもはるかに高い一時的なストレージスペースの使用率が発生する可能性があります。ただし、オンプレミスの DB サーバーを再構築すると、余分なスペースが解放される可能性があります。 |
オンプレミスの SQL 本番環境 DB を DR 用にクラウドにクローンする
-
同様に、SQL クローン リカバリが最後に利用可能なログを通じて実行されたことを検証するために、小さなテスト テーブルを作成し、行を挿入しました。テスト データは、利用可能な最後のログまで完全に回復した後に回復されます。
-
SQL Server のデータベース管理ユーザー ID を使用してSnapCenterにログインします。 SQL Server 保護リソース グループが表示される [リソース] タブに移動します。
-
ログ バックアップを手動で実行して、パブリック クラウドのセカンダリ ストレージに複製される最後のトランザクションをフラッシュします。
-
クローンの最後の完全な SQL Server バックアップを選択します。
-
クローン サーバー、クローン インスタンス、クローン名、マウント オプションなどのクローン設定を設定します。クローン作成が実行されるセカンダリ ストレージの場所は自動的に入力されます。
-
適用するすべてのログ バックアップを選択します。
-
クローン作成の前または後に実行するオプションのスクリプトを指定します。
-
電子メール通知が必要な場合は、SMTP サーバーを指定します。
-
DR クローンの概要。クローンされたデータベースはすぐにSnapCenterに登録され、バックアップ保護に使用できるようになります。
SQL の DR 後のクローン検証と構成
-
クローンジョブのステータスを監視します。
-
すべてのログ ファイルのクローンおよびリカバリを使用して、最後のトランザクションが複製され、リカバリされたことを確認します。
-
SQL Server ログ バックアップ用に、DR サーバー上に新しいSnapCenterログ ディレクトリを構成します。
-
複製されたソース ボリュームからクローン ボリュームを分割します。
-
クラウドからオンプレミスへのレプリケーションを元に戻し、障害が発生したオンプレミスのデータベース サーバーを再構築します。
どこに助けを求めたらいいですか?
このソリューションとユースケースに関するサポートが必要な場合は、"NetAppソリューション オートメーション コミュニティ サポート Slack チャンネル"質問や問い合わせを投稿するには、ソリューション自動化チャネルを探してください。