システムの復元

復元の概要

ディザスタ リカバリ システム(DRS)には、システムを復元するプロセスを実行するためのガイドとなるウィザードが用意されています。

バックアップ ファイルは暗号化されており、それらを開いてデータを復元できるのは DRS システムのみです。 ディザスタ リカバリ システムには、次の機能があります。
  • 復元タスクを実行するためのユーザ インターフェイス。

  • 復元機能を実行するための分散システム アーキテクチャ。

マスター エージェント

クラスタの各ノードで自動的にマスター エージェント サービスが起動されますが、マスター エージェントはパブリッシャ ノード上でのみ機能します。 サブスクライバ ノード上のマスター エージェントは、何の機能も実行しません。

ローカル エージェント

サーバには、バックアップおよび復元機能を実行するローカル エージェントが搭載されています。

マスター エージェントを含むノードをはじめ、Cisco Unified Communications Manager クラスタ内の各ノードには、バックアップおよび復元機能を実行するために独自のローカル エージェントが必要です。


(注)  


デフォルトでは、ローカル エージェントは IM and Presence ノードをはじめ、クラスタ内の各ノードで自動的に起動されます。


復元の前提条件

  • バージョンの要件を満たしていることを確認してください。

    • すべての Cisco Unified Communications Manager クラスタ ノードは、同じバージョンの Cisco Unified Communications Manager アプリケ−ションを実行している必要があります。

    • すべての IM and Presence Service クラスタ ノードは、同じバージョンの IM and Presence Service アプリケーションを実行している必要があります。

    • バックアップ ファイルに保存されているバージョンが、クラスタ ノードで実行されるバージョンと同じでなければなりません。

    バージョンの文字列全体が一致している必要があります。 たとえば、IM and Presence データベース パブリッシャ ノードがバージョン 11.5.1.10000-1 の場合、すべての IM and Presence サブスクライバ ノードは 11.5.1.10000-1 であり、バックアップ ファイルに保存されているバージョンも 11.5.1.10000-1 でなければなりません。 現在のバージョンと一致しないバックアップ ファイルからシステムを復元しようすると、復元は失敗します。

  • サーバの IP アドレス、ホスト名、DNS 設定および導入タイプが、バックアップ ファイルに保存されている IP アドレス、ホスト名、DNS 設定および導入タイプと一致していることを確認します。

  • バックアップを実行した後にクラスタ セキュリティ パスワードを変更した場合、元のパスワードのレコードを記録しておきます。元のパスワードが分からなければ、復元は失敗します。

復元後の SAML SSO 再有効化


重要


この項は、リリース 12.5(1)SU7 にのみ適用されます。

DRS を使用してシステムを復元した後に、SAML SSO がクラスタ内のいずれかのノードで断続的に無効になる場合があります。 影響を受けたノードで SAML SSO を再度有効にするには、次の手順を実行する必要があります。

  1. Cisco Unified CM Administration で、[システム(System)] > [SAMLシングルサインオン(SAML Single Sign-On)] の順に選択します。

  2. [すべての無効なサーバの修正(Fix All Disabled Servers)] をクリックします。

    [SAMLシングルサインオンの設定(SAML Single Sign-On Configuration)] ウィンドウが表示されます。[次へ(Next)] をクリックします。

  3. [SSOテストの実行(Run SSO Test)] をクリックします。

  4. 「SSO のテストに成功しました(SSO Test Succeeded!)」メッセージが表示されたら、ブラウザウィンドウを閉じ、[完了(Finish)] をクリックします。


    (注)  


    SAML SSO の再有効化中に、Cisco Tomcat が起動されます。 SAML SSO がすでに有効になっているノードには影響がありません。

復元タスク フロー

復元プロセス中、[Cisco Unified CM の管理(Cisco Unified Communications Manager OS Administration)] または [Cisco Unified CM IM and Presence OS の管理(Cisco Unified IM and Presence OS Administration)] に関するタスクを実行しないでください。

手順

  コマンドまたはアクション 目的

ステップ 1

最初のノードのみの復元

(オプション)クラスタ内の最初のパブリッシャ ノードだけを復元する場合は、この手順を使用します。

ステップ 2

後続クラスタ ノードの復元

(オプション)クラスタ内のサブスクライバ ノードを復元する場合は、この手順を使用します。

ステップ 3

パブリッシャの再構築後の 1 回のステップでのクラスタの復元

(オプション)パブリッシャがすでに再構築されている場合、1 回のステップでクラスタ全体を復元するには、次の手順に従ってください。

ステップ 4

クラスタ全体の復元

(オプション)パブリッシャ ノードを含む、クラスタ内のすべてのノードを復元するには、この手順を使用します。 主要なハード ドライブで障害またはアップグレードが発生した場合や、ハード ドライブを移行する場合には、クラスタ内のすべてのノードの再構築が必要になる場合があります。

ステップ 5

前回正常起動時の設定へのノードまたはクラスタの復元

(オプション)前回正常起動時の設定にノードを復元する場合に限り、この手順を使用します。 ハード ドライブ障害やその他のハードウェア障害の後には使用しないでください。

ステップ 6

ノードの再起動

ノードを再起動するには、この手順を使用します。

ステップ 7

復元ジョブ ステータスのチェック

(オプション)復元ジョブ ステータスを確認するには、この手順を使用します。

ステップ 8

復元履歴の表示

(オプション)復元履歴を表示するには、この手順を使用します。

最初のノードのみの復元

再構築後に最初のノードを復元する場合は、バックアップ デバイスを設定する必要があります。

この手順は、Cisco Unified Communications Manager の最初のノード(パブリッシャ ノードとも呼ばれます)に対して実行できます。 その他の Cisco Unified Communications Manager ノードおよびすべての IM and Presence サービス ノードは、セカンダリ ノードまたはサブスクライバと見なされます。

始める前に

クラスタ内に IM and Presence サービス ノードがある場合は、最初のノードを復元するときに、ノードが実行されており、アクセス可能であることを確認してください。 これは、この手順の実行中に有効なバックアップ ファイルを見つけるために必須です。

手順


ステップ 1

ディザスタ リカバリ システムから、[復元(Restore)] > [復元ウィザード(Restore Wizard)] を選択します。

ステップ 2

[復元ウィザード ステップ 1(Restore Wizard Step 1)]ウィンドウの [バックアップ デバイスの選択(Select Backup Device)]領域で、復元する適切なバックアップ デバイスを選択します。

ステップ 3

[次へ(Next)]をクリックします。

ステップ 4

[復元ウィザード ステップ 2(Restore Wizard Step 2)]ウィンドウで、復元するバックアップ ファイルを選択します。

(注)  

 

バックアップ ファイル名から、バックアップ ファイルが作成された日付と時刻がわかります。

ステップ 5

[次へ(Next)]をクリックします。

ステップ 6

[復元ウィザード ステップ 3(Restore Wizard Step 3)]ウィンドウで、[次へ(Next)]をクリックします。

ステップ 7

復元する機能を選択します。

(注)  

 

バックアップ対象として選択した機能が表示されます。

ステップ 8

[次へ(Next)]をクリックします。 [復元ウィザード ステップ 4(Restore Wizard Step 4)] ウィンドウが表示されます。

ステップ 9

ファイル整合性チェックを実行する場合は、[SHA1 メッセージ ダイジェストを使用してファイル整合性チェックを実行する(Perform file integrity check using SHA1 Message Digest)] チェックボックスをオンにします。

(注)  

 

ファイル整合性チェックは任意で、SFTP バックアップの場合にだけ必要です。

ファイル整合性チェックの処理は CPU およびネットワーク帯域幅を大量に消費するため、復元プロセスの処理速度が低下します。

ステップ 10

復元するノードを選択します。

ステップ 11

[復元(Restore)]をクリックして、データを復元します。

ステップ 12

[次へ(Next)]をクリックします。

ステップ 13

復元するノードの選択を求められたら、最初のノード(パブリッシャ)だけを選択します。

注意    

 

このときに後続(サブスクライバ)ノードは選択しないでください。復元を試みても失敗します。

ステップ 14

(オプション)[サーバ名の選択(Select Server Name)] ドロップダウン リストから、パブリッシャ データベース復元元のサブスクライバ ノードを選択します。 選択したサブスクライバ ノードが稼働しており、クラスタに接続されていることを確認してください。

ディザスタ リカバリ システムでバックアップ ファイルのすべてのデータベース以外の情報が復元され、選択した後続ノードから最新のデータベースが取り出されます。

(注)  

 

このオプションは、選択したバックアップ ファイルに CCMDB データベース コンポーネントが含まれている場合にのみ表示されます。 まず、パブリッシャ ノードだけが完全に復元されますが、ステップ 14 を実行し、後続のクラスタ ノードを再起動すると、ディザスタ リカバリ システムはデータベース レプリケーションを実行し、完全にすべてのクラスタ ノードのデータベースが同期されます。 これにより、すべてのクラスタ ノードに最新のデータを使用していることが保障されます。

ステップ 15

[復元(Restore)]をクリックします。

ステップ 16

パブリッシャ ノードにデータが復元されます。 復元するデータベースとコンポーネントのサイズによっては、復元が完了するまでに数時間かかることがあります。

(注)  

 

最初のノードを復元すると、Cisco Unified Communications Manager データベース全体がクラスタに復元されます。 そのため、復元しているノードの数とデータベースのサイズによっては、数時間かかることがあります。 復元するデータベースとコンポーネントのサイズによっては、復元が完了するまでに数時間かかることがあります。

ステップ 17

[復元ステータス(Restore Status)]ウィンドウの [完了率(Percentage Complete)]フィールドに 100% と表示されたら、サーバを再起動します。 クラスタ内のすべてのノードの再起動は最初のノードのみへの復元の場合に必要となります。 後続ノードを再起動する前に、必ず最初のノードを再起動してください。 サーバの再起動方法については、「次の作業」の項を参照してください。

(注)  

 

Cisco Unified Communications Manager ノードだけを復元する場合は、Cisco Unified Communications Manager and IM and Presence Service サービス クラスタを再起動する必要があります。

IM and Presence サービスのパブリッシャ ノードのみを復元する場合は、IM and Presence サービス クラスタを再起動する必要があります。


次のタスク

後続クラスタ ノードの復元

この手順は、Cisco Unified Communications Manager のサブスクライバ(後続)ノードにのみ適用されます。 インストールされる最初の Cisco Unified Communications Manager ノードはパブリッシャ ノードです。 その他すべての Cisco Unified Communications Manager ノードおよびすべての IM and Presence サービス ノードはサブスクライバ ノードです。

クラスタ内の 1 つ以上の Cisco Unified Communications Manager サブスクライバ ノードを復元するには、次の手順に従います。

始める前に

復元操作を実行する場合は事前に、復元のホスト名、IP アドレス、DNS 設定、および配置タイプが、復元するバックアップ ファイルのホスト名、IP アドレス、DNS 設定、および配置タイプに一致することを確認します。 ディザスタ リカバリ システムでは、ホスト名、IP アドレス、DNS 設定、および配置タイプが異なると復元が行われません。

サーバにインストールされているソフトウェアのバージョンが復元するバックアップ ファイルのバージョンに一致することを確認します。 ディザスタ リカバリ システムは、一致するソフトウェア バージョンのみを復元操作でサポートします。 再構築後に後続ノードを復元している場合は、バックアップ デバイスを設定する必要があります。

手順


ステップ 1

ディザスタ リカバリ システムから、[復元(Restore)] > [復元ウィザード(Restore Wizard)] を選択します。

ステップ 2

[復元ウィザード ステップ 1(Restore Wizard Step 1)]ウィンドウの [バックアップ デバイスの選択(Select Backup Device)]領域で、復元するバックアップ デバイスを選択します。

ステップ 3

[次へ(Next)]をクリックします。

ステップ 4

[復元ウィザード ステップ 2(Restore Wizard Step 2)]ウィンドウで、復元するバックアップ ファイルを選択します。

ステップ 5

[次へ(Next)]をクリックします。

ステップ 6

[復元ウィザード ステップ 3(Restore Wizard Step 3)]ウィンドウで、復元する機能を選択します。

(注)  

 

選択したファイルにバックアップされた機能だけが表示されます。

ステップ 7

[次へ(Next)]をクリックします。 [復元ウィザード ステップ 4(Restore Wizard Step 4)] ウィンドウが表示されます。

ステップ 8

[復元ウィザード ステップ 4(Restore Wizard Step 4)]ウィンドウで、復元するノードを選択するよう求められたら、後続ノードのみを選択します。

ステップ 9

[復元(Restore)]をクリックします。

ステップ 10

後続ノードにデータが復元されます。 復元ステータスの確認方法については、「次の作業」の項を参照してください。

(注)  

 

復元プロセス中、[Cisco Unified CM の管理(Cisco Unified Communications Manager Administration)] または [ユーザ オプション(User Options)] に関するタスクを実行しないでください。

ステップ 11

[復元ステータス(Restore Status)]ウィンドウの [完了率(Percentage Complete)]フィールドに 100% と表示されたら、復元した 2 次サーバを再起動します。 クラスタ内のすべてのノードの再起動は最初のノードのみへの復元の場合に必要となります。 後続ノードを再起動する前に、必ず最初のノードを再起動してください。 サーバの再起動方法については、「次の作業」の項を参照してください。

(注)  

 

最初の IM and Presence サービス ノードが復元されたら、 IM and Presence サービスの後続ノードを再起動する前に、必ず最初の IM and Presence サービス ノードを再起動してください。


次のタスク

パブリッシャの再構築後の 1 回のステップでのクラスタの復元

復元するデータベースとコンポーネントのサイズによっては、復元が完了するまでに数時間かかることがあります。 パブリッシャがすでに再構築されている場合、または新しくインストールされた場合に、1 回のステップでクラスタ全体を復元する場合は、次の手順に従います。

手順


ステップ 1

ディザスタ リカバリ システムから、[復元(Restore)] > [復元ウィザード(Restore Wizard)] を選択します。

ステップ 2

[復元ウィザード ステップ 1(Restore Wizard Step 1)]ウィンドウの [バックアップ デバイスの選択(Select Backup Device)]領域で、復元するバックアップ デバイスを選択します。

ステップ 3

[次へ(Next)]をクリックします。

ステップ 4

[復元ウィザード ステップ 2(Restore Wizard Step 2)]ウィンドウで、復元するバックアップ ファイルを選択します。

バックアップ ファイル名から、バックアップ ファイルが作成された日付と時刻がわかります。

クラスタ全体を復元するクラスタのバックアップ ファイルだけを選択します。

ステップ 5

[次へ(Next)]をクリックします。

ステップ 6

[復元ウィザード ステップ 3(Restore Wizard Step 3)]ウィンドウで、復元する機能を選択します。

画面には、復元する機能のうち、バックアップ ファイルに保存された機能のみが表示されます。

ステップ 7

[次へ(Next)]をクリックします。

ステップ 8

[復元ウィザード ステップ 4(Restore Wizard Step 4)]ウィンドウで、[1 ステップでの復元(One-Step Restore)]をクリックします。

このオプションは、復元用に選択されたバックアップ ファイルがクラスタのバックアップ ファイルであり、復元用に選択された機能に、パブリッシャとサブスクライバの両方のノードに登録された機能が含まれている場合にのみ [復元ウィザード ステップ 4(Restore Wizard Step 4)]ウィンドウに表示されます。 詳細については、最初のノードのみの復元および後続クラスタ ノードの復元を参照してください。

(注)  

 

「パブリッシャがクラスタ対応になりませんでした。 1 ステップでの復元を開始できません(Publisher has failed to become cluster aware. Cannot start one-step restore)」というステータス メッセージが表示されたら、パブリッシャ ノードを復元してからサブスクライバ ノードを復元する必要があります。 詳細については、「関連項目」を参照してください。

このオプションでは、パブリッシャがクラスタ対応になり、そのためには 5 分かかります。 このオプションをクリックすると、ステータス メッセージに"「パブリッシャがクラスタ対応になるまで 5 分間待機してください。この期間にバックアップまたは復元処理を開始しないでください。(Please wait for 5 minutes until Publisher becomes cluster aware and do not start any backup or restore activity in this time period.)」"と表示されます。

この待ち時間の経過後に、パブリッシャがクラスタ対応になると、"「パブリッシャがクラスタ対応になりました。 サーバを選択し、[復元(Restore)] をクリックしてクラスタ全体の復元を開始してください(Publisher has become cluster aware. Please select the servers and click on Restore to start the restore of entire cluster)」"というステータス メッセージが表示されます。

この待ち時間の経過後、パブリッシャがクラスタ対応にならない場合、「パブリッシャがクラスタ対応にならなかったため、 1 ステップでの復元を開始できず、 通常の 2 ステップでの復元を実行してください。(Publisher has failed to become cluster aware. Cannot start one-step restore. Please go ahead and do a normal two-step restore.)」というステータス メッセージが表示されます。 クラスタ全体を 2 ステップ(パブリッシャとサブスクライバ)で復元するには、最初のノードのみの復元後続クラスタ ノードの復元 で説明する手順を実行してください。

ステップ 9

復元するノードの選択を求められたら、クラスタ内のすべてのノードを選択します。

最初のノードを復元すると、ディザスタ リカバリ システムが自動的に後続ノードに Cisco Unified Communications Manager データベース(CCMDB)を復元します。 そのため、復元しているノードの数とデータベースのサイズによっては、数時間かかることがあります。

ステップ 10

[復元(Restore)]をクリックします。

クラスタ内のすべてのノードでデータが復元されます。

ステップ 11

[復元ステータス(Restore Status)]ウィンドウの [完了率(Percentage Complete)]フィールドに 100% と表示されたら、サーバを再起動します。 クラスタ内のすべてのノードの再起動は最初のノードのみへの復元の場合に必要となります。 後続ノードを再起動する前に、必ず最初のノードを再起動してください。 サーバの再起動方法については、「次の作業」の項を参照してください。


次のタスク

クラスタ全体の復元

主要なハード ドライブで障害またはアップグレードが発生した場合や、ハード ドライブを移行する場合には、クラスタ内のすべてのノードの再構築が必要です。 クラスタ全体を復元するには、次の手順を実行します。

ネットワーク カードの交換やメモリの増設など他のほとんどのハードウェア アップグレードでは、次の手順を実行する必要はありません。

手順


ステップ 1

ディザスタ リカバリ システムから、[復元(Restore)] > [復元ウィザード(Restore Wizard)] を選択します。

ステップ 2

[バックアップ デバイスの選択(Select Backup Device)]エリアで、復元する適切なバックアップ デバイスを選択します。

ステップ 3

[次へ(Next)]をクリックします。

ステップ 4

[復元ウィザード ステップ 2(Restore Wizard Step 2)]ウィンドウで、復元するバックアップ ファイルを選択します。

(注)  

 

バックアップ ファイル名から、バックアップ ファイルが作成された日付と時刻がわかります。

ステップ 5

[次へ(Next)]をクリックします。

ステップ 6

[復元ウィザード ステップ 3(Restore Wizard Step 3)]ウィンドウで、[次へ(Next)]をクリックします。

ステップ 7

[復元ウィザード ステップ 4(Restore Wizard Step 4)]ウィンドウで復元ノードの選択を求められたら、すべてのノードを選択します。

ステップ 8

[復元(Restore)]をクリックして、データを復元します。

第 1 ノードを復元すると、ディザスタ リカバリ システムが自動的に後続ノードに Cisco Unified Communications Manager データベース(CCMDB)を復元します。 そのため、ノードの数とデータベースのサイズによっては、最大数時間かかることがあります。

すべてのノードでデータが復元されます。

(注)  

 

復元プロセス中、[Cisco Unified CM の管理(Cisco Unified Communications Manager Administration)] または [ユーザ オプション(User Options)] に関するタスクを実行しないでください。

復元するデータベースとコンポーネントのサイズによっては、復元が完了するまでに数時間かかることがあります。

ステップ 9

復元プロセスが完了したら、サーバを再起動します。 サーバの再起動方法の詳細については、「次の作業」セクションを参照してください。

(注)  

 

必ず最初のノードを再起動してから、後続ノードを再起動してください。

最初のノードが再起動し、Cisco Unified Communications Manager の復元後のバージョンが実行されたら、後続ノードを再起動します。

ステップ 10

レプリケーションはクラスタのリブート後に自動的に設定されます。 『Cisco Unified Communications ソリューション コマンドライン インターフェイス リファレンス ガイド』の説明に従って "utils dbreplication runtimestate" CLI コマンドを使用して、すべてのノードで [レプリケーションステータス(Replication Status)] の値を確認します。 各ノードの値は 2 になっているはずです。

(注)  

 

クラスタのサイズによっては、後続ノードの再起動後に、後続ノードでのデータベース レプリケーションが完了するまでに時間がかかる場合があります。

ヒント

 
レプリケーションが正しくセットアップされない場合は、『Command Line Interface Reference Guide for Cisco Unifed Communications Solutions』の説明に従って「utils dbreplication rebuild」CLI コマンドを使用します。

次のタスク

前回正常起動時の設定へのノードまたはクラスタの復元

前回正常起動時の設定にノードまたはクラスタを復元するには、次の手順に従います。

始める前に

  • 復元ファイルに、バックアップ ファイルで設定されているホスト名、IP アドレス、DNS 設定、および配置タイプが含まれていることを確認します。

  • サーバにインストールされている Cisco Unified Communications Manager のバージョンが復元するバックアップ ファイルのバージョンに一致することを確認します。

  • この手順は、前回正常起動時の設定にノードを復元する場合にのみ使用してください。

手順


ステップ 1

ディザスタ リカバリ システムから、[復元(Restore)] > [復元ウィザード(Restore Wizard)] を選択します。

ステップ 2

[バックアップ デバイスの選択(Select Backup Device)]エリアで、復元する適切なバックアップ デバイスを選択します。

ステップ 3

[次へ(Next)]をクリックします。

ステップ 4

[復元ウィザード ステップ 2(Restore Wizard Step 2)]ウィンドウで、復元するバックアップ ファイルを選択します。

(注)  

 

バックアップ ファイル名から、バックアップ ファイルが作成された日付と時刻がわかります。

ステップ 5

[次へ(Next)]をクリックします。

ステップ 6

[復元ウィザード ステップ 3(Restore Wizard Step 3)]ウィンドウで、[次へ(Next)]をクリックします。

ステップ 7

復元ノードを選択するように求められたら、該当するノードを選択します。

選択したノードにデータが復元されます。

ステップ 8

クラスタ内のすべてのノードを再起動します。 後続の Cisco Unified Communications Manager ノードを再起動する前に、最初の Cisco Unified Communications Manager ノードを再起動します。 クラスタに Cisco IM and Presence ノードもある場合は、最初の Cisco IM and Presence ノードを再起動してから、後続の IM and Presence ノードを再起動します。 詳細については、「次の作業」の項を参照してください。


ノードの再起動

データを復元したら、ノードを再起動する必要があります。

パブリッシャ ノード(最初のノード)を復元したら、最初にパブリッシャ ノードを再起動する必要があります。 サブスクラバ ノードは必ず、パブリッシャ ノードが再起動し、ソフトウェアの復元されたバージョンを正常に実行し始めた後で再起動してください。


(注)  


CUCM パブリッシャ ノードがオフラインの場合は、IM and Presence サブスクライバ ノードを再起動しないでください。 このような場合は、サブスクライバ ノードが CUCM パブリッシャに接続できないため、ノード サービスの開始に失敗します。



注意    


この手順を実行すると、システムが再起動し、一時的に使用できない状態になります。


再起動する必要があるクラスタ内のすべてのノードでこの手順を実行します。

手順


ステップ 1

[Cisco Unified OS の管理(Cisco Unified OS Administration)] から、[設定(Settings)] > [バージョン(Version)] を選択します。

ステップ 2

ノードを再起動するには、[再起動(Restart)]をクリックします。

ステップ 3

レプリケーションはクラスタのリブート後に自動的に設定されます。 utils dbreplication runtimestate CLI コマンドを使用して、すべてのノードで [レプリケーション ステータス(Replication Status)] 値を確認します。 各ノードの値は 2 になっている必要があります。CLI コマンドの詳細については、「Cisco Unified Communications (CallManager) Command References」を参照してください。

レプリケーションが正しくセットアップされない場合は、『Command Line Reference Guide for Cisco Unified Communications Solutions』の説明に従って utils dbreplication reset CLI コマンドを使用します。

(注)  

 

クラスタのサイズによっては、後続ノードの再起動後に、後続ノードでのデータベース レプリケーションが完了するまでに数時間かかる場合があります。


次のタスク

(オプション)復元のステータスを表示するには、復元ジョブ ステータスのチェックを参照してください。

復元ジョブ ステータスのチェック

次の手順に従って、復元ジョブ ステータスをチェックします。

手順


ステップ 1

ディザスタ リカバリ システムで、[復元(Restore)] > [現在のステータス(Current Status)] を選択します。

ステップ 2

[復元ステータス(Restore Status)]ウィンドウで、ログ ファイル名のリンクをクリックし、復元ステータスを表示します。


復元履歴の表示

復元履歴を参照するには、次の手順を実行します。

手順


ステップ 1

[Disaster Recovery System] で、[復元(Restore)] > [履歴(History)] を選択します。

ステップ 2

[復元履歴(Restore History)]ウィンドウで、ファイル名、バックアップ デバイス、完了日、結果、バージョン、復元された機能、失敗した機能など、実行した復元を表示できます。

[復元履歴(Restore History)]ウィンドウには、最新の 20 個の復元ジョブだけが表示されます。

データ認証

トレース ファイル

トラブルシューティングを行う際、またはログの収集中には、トレース ファイルの保存先として次の場所が使用されます。

マスター エージェント、GUI、各ローカル エージェント、および JSch ライブラリのトレース ファイルは次の場所に書き込まれます。

  • マスター エージェントの場合、トレース ファイルは platform/drf/trace/drfMA0* にあります。

  • 各ローカル エージェントの場合、トレース ファイルは platform/drf/trace/drfLA0* にあります。

  • GUI の場合、トレース ファイルは platform/drf/trace/drfConfLib0* にあります。

  • JSch の場合、トレース ファイルは platform/drf/trace/drfJSch* にあります。

詳細については、『Command Line Interface Reference Guide for Cisco Unified Communications Solutions』(http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-command-reference-list.html)を参照してください。

コマンドライン インターフェイス

ディザスタ リカバリ システムでは、次の表に示すように、バックアップおよび復元機能のサブセットにコマンドラインからアクセスできます。 これらのコマンドの内容とコマンドライン インターフェイスの使用方法の詳細については、『Command Line Interface(CLI)Reference Guide for Cisco Unified Presence』(http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-command-reference-list.html)を参照してください。

表 1. ディザスタ リカバリ システムのコマンドライン インターフェイス

コマンド

説明

utils disaster_recovery estimate_tar_size

SFTP/Local デバイスからのバックアップ tar の概算サイズを表示し、機能リストのパラメータを 1 つ要求します。

utils disaster_recovery backup

ディザスタ リカバリ システムのインターフェイスに設定されている機能を使用して、手動バックアップを開始します。

utils disaster_recovery jschLogs

JSch ライブラリのロギングを有効または無効にします。

utils disaster_recovery restore

復元を開始します。復元するバックアップ場所、ファイル名、機能、およびノードを指定するためのパラメータが必要です。

utils disaster_recovery status

進行中のバックアップ ジョブまたは復元ジョブのステータスを表示します。

utils disaster_recovery show_backupfiles

既存のバックアップ ファイルを表示します。

utils disaster_recovery cancel_backup

進行中のバックアップ ジョブをキャンセルします。

utils disaster_recovery show_registration

現在設定されている登録を表示します。

utils disaster_recovery device add

ネットワーク デバイスを追加します。

utils disaster_recovery device delete

デバイスを削除します。

utils disaster_recovery device list

すべてのデバイスを一覧表示します。

utils disaster_recovery schedule add

スケジュールを追加します。

utils disaster_recovery schedule delete

スケジュールを削除します。

utils disaster_recovery schedule disable

スケジュールを無効にします。

utils disaster_recovery schedule enable

スケジュールを有効にします。

utils disaster_recovery schedule list

すべてのスケジュールを一覧表示します。

utils disaster_recovery backup

ディザスタ リカバリ システムのインターフェイスに設定されている機能を使用して、手動バックアップを開始します。

utils disaster_recovery restore

復元を開始します。復元するバックアップ場所、ファイル名、機能、およびノードを指定するためのパラメータが必要です。

utils disaster_recovery status

進行中のバックアップ ジョブまたは復元ジョブのステータスを表示します。

utils disaster_recovery show_backupfiles

既存のバックアップ ファイルを表示します。

utils disaster_recovery cancel_backup

進行中のバックアップ ジョブをキャンセルします。

utils disaster_recovery show_registration

現在設定されている登録を表示します。

アラームおよびメッセージ

アラームおよびメッセージ

ディザスタ リカバリ システムは、バックアップまたは復元手順の実行時に発生するさまざまなエラーのアラームを発行します。 次の表に、ディザスタ リカバリ システムのアラームの一覧を記載します。

表 2. ディザスタ リカバリ システムのアラームとメッセージ

アラーム名

説明

説明

DRFBackupDeviceError

DRF バックアップ プロセスでデバイスへのアクセスに関する問題が発生しています。

DRS バックアップ プロセスでデバイスへのアクセス中にエラーが発生しました。

DRFBackupFailure

シスコ DRF バックアップ プロセスが失敗しました。

DRS バックアップ プロセスでエラーが発生しました。

DRFBackupInProgress

別のバックアップの実行中は、新規バックアップを開始できません。

DRS は、別のバックアップの実行中は新規バックアップを開始できません。

DRFInternalProcessFailure

DRF 内部プロセスでエラーが発生しました。

DRS 内部プロセスでエラーが発生しました。

DRFLA2MAFailure

DRF ローカル エージェントが、マスター エージェントに接続できません。

DRS ローカル エージェントが、マスター エージェントに接続できません。

DRFLocalAgentStartFailure

DRF ローカル エージェントが開始されません。

DRS ローカル エージェントがダウンしている可能性があります。

DRFMA2LAFailure

DRF マスター エージェントがローカル エージェントに接続しません。

DRS マスター エージェントがローカル エージェントに接続できません。

DRFMABackupComponentFailure

DRF は、少なくとも 1 つのコンポーネントをバックアップできません。

DRS は、コンポーネントのデータをバックアップするようにリクエストしましたが、バックアッププロセス中にエラーが発生し、コンポーネントはバックアップされませんでした。

DRFMABackupNodeDisconnect

バックアップされるノードが、バックアップの完了前にマスター エージェントから切断されました。

DRS マスター エージェントが Cisco Unified Communications Manager ノードでバックアップ操作を実行しているときに、そのノードはバックアップ操作が完了する前に切断されました。

DRFMARestoreComponentFailure

DRF は、少なくとも 1 つのコンポーネントを復元できません。

DRS は、コンポーネントのデータを復元するようにリクエストしましたが、復元プロセス中にエラーが発生し、コンポーネントは復元されませんでした。

DRFMARestoreNodeDisconnect

復元されるノードが、復元の完了前にマスター エージェントから切断されました。

DRS マスター エージェントが Cisco Unified Communications Manager ノードで復元操作を実行しているときに、そのノードは復元操作が完了する前に切断されました。

DRFMasterAgentStartFailure

DRF マスター エージェントが開始されませんでした。

DRS マスター エージェントがダウンしている可能性があります。

DRFNoRegisteredComponent

使用可能な登録済みコンポーネントがないため、バックアップが失敗しました。

使用可能な登録済みコンポーネントがないため、DRS バックアップが失敗しました。

DRFNoRegisteredFeature

バックアップする機能が選択されませんでした。

バックアップする機能が選択されませんでした。

DRFRestoreDeviceError

DRF 復元プロセスでデバイスへのアクセスに関する問題が発生しています。

DRS 復元プロセスは、デバイスから読み取ることができません。

DRFRestoreFailure

DRF 復元プロセスが失敗しました。

DRS 復元プロセスでエラーが発生しました。

DRFSftpFailure

DRF SFTP 操作でエラーが発生しています。

DRS SFTP 操作でエラーが発生しています。

DRFSecurityViolation

DRF システムが、セキュリティ違反となる可能性がある悪意のあるパターンを検出しました。

DRF ネットワーク メッセージには、コード インジェクションやディレクトリ トラバーサルなど、セキュリティ違反となる可能性がある悪意のあるパターンが含まれています。 DRF ネットワーク メッセージがブロックされています。

DRFTruststoreMissing

ノードで IPsec 信頼ストアが見つかりません。

ノードで IPsec 信頼ストアが見つかりません。 DRF ローカル エージェントが、マスター エージェントに接続できません。

DRFUnknownClient

パブリッシャの DRF マスター エージェントが、クラスタ外部の不明なサーバーからクライアント接続リクエストを受け取りました。 リクエストは拒否されました。

パブリッシャの DRF マスター エージェントが、クラスタ外部の不明なサーバーからクライアント接続リクエストを受け取りました。 リクエストは拒否されました。

DRFBackupCompleted

DRF バックアップが正常に完了しました。

DRF バックアップが正常に完了しました。

DRFRestoreCompleted

DRF 復元が正常に完了しました。

DRF 復元が正常に完了しました。

DRFNoBackupTaken

現在のシステムの有効なバックアップが見つかりませんでした。

アップグレード/移行または新規インストール後に、現在のシステムの有効なバックアップが見つかりませんでした。

DRFComponentRegistered

DRF により、リクエストされたコンポーネントが正常に登録されました。 DRF により、リクエストされたコンポーネントが正常に登録されました。

DRFRegistrationFailure

DRF 登録操作が失敗しました。

内部エラーが原因で、コンポーネントに対する DRF 登録操作が失敗しました。

DRFComponentDeRegistered

DRF は正常にリクエストされたコンポーネントの登録をキャンセルしました。

DRF は正常にリクエストされたコンポーネントの登録をキャンセルしました。

DRFDeRegistrationFailure

コンポーネントの DRF 登録解除リクエストが失敗しました。

コンポーネントの DRF 登録解除リクエストが失敗しました。

DRFFailure

DRF バックアップまたは復元プロセスが失敗しました。

DRF バックアップまたは復元プロセスでエラーが発生しました。

DRFRestoreInternalError

DRF 復元オペレーションでエラーが発生しました。 復元は内部的にキャンセルされました。

DRF 復元オペレーションでエラーが発生しました。 復元は内部的にキャンセルされました。

DRFLogDirAccessFailure

DRF は、ログ ディレクトリにアクセスできませんでした。

DRF は、ログ ディレクトリにアクセスできませんでした。

DRFDeRegisteredServer

DRF がサーバーのすべてのコンポーネントを自動的に登録解除しました。

サーバーが Unified Communications Manager クラスタから切断されている可能性があります。

DRFSchedulerDisabled

設定された機能がバックアップで使用できないため、DRF スケジューラは無効になっています。

設定された機能がバックアップで使用できないため、DRF スケジューラは無効になっています

DRFSchedulerUpdated

機能が登録解除されたため、DRF でスケジュールされたバックアップ設定が自動的に更新されます。

機能が登録解除されたため、DRF でスケジュールされたバックアップ設定が自動的に更新されます

復元の連携動作と制約事項

復元の制約事項

ディザスタ リカバリ システムを使用して Cisco Unified Communications Manager または IM and Presence Service を復元する場合、以下の制約事項が適用されます。

表 3. 復元の制約事項

制約事項

説明

エクスポートの制限

制限されたバージョンにのみ制限済みバージョンの DRS バックアップのリストア、制限されていないバージョンからのバックアップは制限されていないバージョンでのみリストアすることができます。 Cisco Unified Communications Manager の米国輸出無制限バージョンにアップグレードした場合、その後でこのソフトウェアの米国輸出制限バージョンへアップグレードしたり、新規インストールを実行したりすることはできません。

プラットフォームの移行

ディザスタ リカバリ システムを使用してプラットフォーム間で(たとえば、Windows から Linux へ、または Linux から Windows へ)データを移行することはできません。 復元は、バックアップと同じ製品バージョンで実行する必要があります。 Windows ベースのプラットフォームから Linux ベースのプラットフォームへのデータ移行については、『Data Migration Assistant User Guide』を参照してください。

HW の交換と移行

DRS 復元を実行してデータを新しいサーバに移行する場合、新しいサーバに古いサーバが使用していたのと同じ IP アドレスとホスト名を割り当てる必要があります。 さらに、バックアップの取得時に DNS が設定されている場合、復元を実行する前に、同じ DNS 設定がある必要があります。

サーバの交換の詳細については、『Replacing a Single Server or Cluster for Cisco Unified Communications Manager』ガイドを参照してください。

また、ハードウェアの交換後は、証明書信頼リスト(CTL)クライアントを実行する必要もあります。 後続ノード(サブスクライバ)サーバーを復元しない場合には、CTL クライアントを実行する必要があります。 他の場合、DRS は必要な証明書をバックアップします。 詳細については、『Cisco Unified Communications Manager セキュリティガイド』の「"CTL クライアントのインストール"」と「"CTL クライアントの設定"」の手順を参照してください。

クラスタ間のエクステンション モビリティ

バックアップ時にリモート クラスタにログインしていた Extension Mobility Cross Cluster ユーザは、復元後もログインしたままとなります。


(注)  


DRS バックアップ/復元は CPU 指向の高いプロセスです。 バックアップと復元の対象となるコンポーネントの 1 つに、スマートライセンスマネージャがあります。 このプロセスの間、スマート ライセンス マネージャ サービスが再起動します。 リソース使用率が高い場合があります。メンテナンス期間中のスケジュールを設定してください。

Cisco Unified Communications サーバ コンポーネントの復元が正常に完了した後、Cisco Unified Communications Manager を Cisco Smart Software Manager または Cisco スマート ソフトウェア マネージャ サテライトに登録してください。 バックアップを実行する前にこの製品がすでに登録されている場合は、製品を再登録してライセンス情報を更新します。

製品を Cisco Smart Software Manager または Cisco Smart Software Manager サテライトに登録する方法の詳細については、お使いのリリース向けのCisco Unified Communications Manager システムコンフィギュレーションガイドを参照してください。

トラブルシューティング

小規模な仮想マシンへの DRS 復元の失敗

問題

IM and Presence サービス ノードをディスク容量がより小さい VM に復元すると、データベースの復元が失敗することがあります。

原因

大きいディスク サイズから小さいディスク サイズに移行したときに、この障害が発生します。

ソリューション

2 個の仮想ディスクがある OVA テンプレートから、復元用の VM を展開します。