LiveCycle のバックアップと回復方法

LiveCycle の使用方法を特定したら、バックアップの必要があるファイル、バックアップの頻度、および使用可能にするバックアップウィンドウを決定する必要があります。

重要: LiveCycle 実装の他の側面と同様に、バックアップと回復の方法は、実稼働環境で使用する前に開発環境またはステージング環境で作成およびテストし、データ損失が発生せずにソリューション全体が期待どおり機能することを確認する必要があります。

Adobe Experience Manager (AEM) は LiveCycle の統合機能の一部です。したがって、Correspondence Management Solution とサービス (例えば Forms Manager) は LiveCycle の AEM 部分に保存されているデータを基にしているので、AEM のバックアップを取ることと、LiveCycle バックアップと同期することが必要です。データの喪失を防ぐために、LiveCycle 固有データのバックアップを何らかの方法で取り、GDS および AEM (レポジトリ) をデータベースリファレンスと相関させる必要があります。データベース、GDS、AEM、および Content Storage Root ディレクトリは、元と同じ DNS 名でコンピューターに復元する必要があります。

バックアップの種類

LiveCycle のバックアップ方法には、次の 2 種類のバックアップがあります。

システムイメージ:
ハードドライブまたはコンピューター全体の機能が停止した場合に、コンピューターの内容を復元するのに使用できる完全なシステムバックアップです。システムイメージバックアップは、LiveCycle の実稼働デプロイメントの前にのみ必要となるバックアップです。社内ポリシーで、システムイメージバックアップが必要な頻度を示します。

LiveCycle 固有のデータ:
アプリケーションデータは、データベース、グローバルドキュメントストレージ (GDS)、および AEM レポジトリ内に存在し、リアルタイムでバックアップを取る必要があります。GDS は、プロセス内で使用される長期間有効なファイルの保存に使用されるディレクトリです。該当するファイルには、PDF、ポリシー、フォームテンプレートなどがあります。
注意: Content Services(非推奨)をインストールする場合、コンテンツ保存場所のルートディレクトリもバックアップします(コンテンツ保存場所のルートディレクトリ(Content Services のみ)を参照)。

データベースは、フォームの生成結果、サービス設定、プロセスの状態、および GDS ファイルへのデータベース参照を保存するために使用されます。データベースへのドキュメントの保存を有効にすると、GDS 内の永続データと永続ドキュメントもデータベースに保存されます。データベースは、次の方法でバックアップおよび回復できます。

  • スナップショットバックアップモードでは、LiveCycle システムが無制限にバックアップモードになるか、または指定された時間(分)だけバックアップモードになり、その時間が経過するとバックアップモードが無効になります。スナップショットバックアップモードを開始または終了するには、次のいずれかのオプションを使用します。回復シナリオの後、スナップショットバックアップモードは有効になりません。

    • Administration Console のバックアップ設定ページを使用します。スナップショットモードを開始するには、「セーフバックアップモードで稼動する」チェックボックスを選択します。スナップショットモードを終了するには、このチェックボックスの選択を解除します。

    • LCBackupMode スクリプト(データベース、GDS、AEM レポジトリ、およびコンテンツ保存場所のルートディレクトリのバックアップを参照)を使用します。スナップショットバックアップモードを終了するには、スクリプトの引数で continuousCoverage パラメーターを false に設定するか、leaveContinuousCoverage オプションを使用します。

    • 提供されているバックアップ/回復 API(『LiveCycle API Reference』を参照)を使用します。

  • ローリングバックアップモードでは、システムが常にバックアップモードになり、前のセッションが解放されるとすぐに新しいバックアップモードセッションが初期化されます。ローリングバックアップモードにはタイムアウトは関連付けられません。LCBackupMode スクリプトまたは API を呼び出してローリングバックアップモードを終了すると、新しいローリングバックアップモードセッションが開始します。このモードでは継続的なバックアップがサポートされ、GDS ディレクトリから古いドキュメントや不要なドキュメントを消去できるので便利です。ローリングバックアップモードは、「Backup and Recovery」ページではサポートされません。回復シナリオの後、ローリングバックアップモードは引き続き有効になります。継続的なバックアップモード(ローリングバックアップモード)を終了するには、LCBackupMode スクリプトで leaveContinuousCoverage オプションを使用します。

注意: ローリングバックアップモードを終了すると、すぐに新しいバックアップモードセッションが開始します。ローリングバックアップモードを完全に無効にするには、スクリプトで leaveContinuousCoverage オプションを使用します。これによって、既存のローリングバックアップセッションが上書きされます。スナップショットバックアップモードでは、バックアップモードを通常の操作と同じように終了できます。

データ損失を防ぐために、LiveCycle 固有のデータは、GDS およびコンテンツ保存場所のルートディレクトリのドキュメントがデータベース参照と関連付けられるような方法でバックアップする必要があります。

重要: GDS がデータベース内ではなく、ファイルシステムに保存されている場合は、GDS バックアップの前にデータベースバックアップを実行します。

バックアップと回復に関する考慮事項

LiveCycle を異なる環境に回復する場合、次のような変更点があるので、ここで説明するガイドラインに従ってください。

  • LiveCycle サーバーの IP アドレス、ホスト名またはポートの変更

  • ドライブ文字またはディレクトリパスの変更

  • 異なるデータベースのホスト、ポートまたは名前への変更

通常、このような回復シナリオは、アプリケーションサーバー、データベースサーバーまたは LiveCycle サーバーをホストするサーバーのハードウェアエラーにより発生します。LiveCycle サーバーのホスト名または IP アドレスが変わる場合、ここで説明する LiveCycle 固有の設定に加え、必要に応じて、ロードバランサーやファイアウォールなど LiveCycle デプロイメントの他の部分についても変更する必要があります。

変更できないもの

バックアップから LiveCycle を回復するとき、データベースサーバーや他の多くのパラメーターを変更できる場合でも、アプリケーションサーバーの種類とデータベースの種類は変更できません。例えば、LiveCycle バックアップを回復する場合、アプリケーションサーバーを JBoss から WebLogic に変更することや、データベースを Oracle から DB2 に変更することはできません。さらに、回復した LiveCycle では、フォントディレクトリなど、同じファイルシステムパスを使用する必要があります。

回復後の再起動

回復後に LiveCycle を再起動する前に、次の手順を実行します。

  1. メンテナンスモードでシステムを起動します。

  2. 次の操作を実行して、Form Manager をメンテナンスモードで LiveCycle と同期させてください。

    1. http://<サーバー>:<ポート>/lc/fm に行き、adminstrator/password 資格情報を使ってログインします。

    2. 右上角にあるユーザーの名前(この場合は Super Administrator)をクリックします。

    3. Admin Options をクリックします。

    4. Start をクリックして、レポジトリのアセットを同期します。

  3. クラスター環境では、マスターノード(AEM に関して)はスレーブノードよりも前に立ち上げなければなりません。

  4. システムの通常処理が有効になるまで、Web、SOAP、EJB のプロセスイニシエーターなど、内部ソースまたは外部ソースからプロセスが開始されないようにします。

メイン LiveCycle データベースを移動または変更した場合は、ご使用のアプリケーションサーバーに対応するインストールガイドを参照して、LiveCycle データソースの IDP_DS および EDC_DS のデータベース接続情報を更新します。

LiveCycle のホスト名または IP アドレスの変更

クラスター環境でキャッシュに UDP ではなく TCP を使用している場合、キャッシュロケーターの設定を更新する必要があります。ご使用のアプリケーションサーバーに対応する設定ガイドの「キャッシュロケーターの設定(TCP を使用するキャッシュのみ)」を参照してください。

LiveCycle ノードのファイルシステムパスの変更

スタンドアロンノードのファイルシステムパスを変更する場合、環境設定内の該当する参照、他のシステム設定、カスタムアプリケーションおよびデプロイされた LiveCycle アプリケーションを更新する必要があります。一方、クラスターの場合、すべてのノードに同じファイルシステムパス設定を使用する必要があります。また、グローバルドキュメントストレージ(GDS)のルートディレクトリを設定し、回復したデータベースと同期している回復した GDS のコピーを示すようにします。アプリケーションサーバーを再起動しても存続する必要があるデータが GDS に含まれる可能性があるので、GDS パスの設定は重要です。

クラスター環境では、レポジトリのファイルシステムパス設定は、バックアップの前と復旧の後で、すべてのクラスターノードに対して同じでなければなりません。

ファイルシステムパスを変更したら、[LiveCycle root]\sdk\misc\Foundation\SetGDSCommandline フォルダーの LCSetGDS スクリプトを使用して、GDS パスを設定します。詳しくは、同じフォルダー内の ReadMe.txt ファイルを参照してください。古い GDS ディレクトリパスを使用できない場合は、LiveCycle を起動する前に、LCSetGDS スクリプトを使用して GDS に新しいパスを設定する必要があります。

重要: これは、GDS の場所の変更にこのスクリプトを使用する必要がある唯一の状況です。LiveCycle の実行中に GDS の場所を変更するには、Administration Console を使用します(一般的な LiveCycle の設定を参照)。

GDS パスの設定後、メンテナンスモードで LiveCycle サーバーを起動し、Administration Console を使用して、新しいノードについて残りのファイルシステムパスを更新します。すべての必要な設定が更新されたことを確認してから、LiveCycle を再起動し、テストします。