現在表示中:

AEM でリポジトリコンテンツをバックアップおよび復元するには、次の 2 つの方法があります。

  • リポジトリの外部バックアップを作成して、安全な場所にそのバックアップを保存することができます。リポジトリが壊れた場合、以前の状態に復元できます。
  • リポジトリコンテンツの内部バージョンを作成できます。内部バージョンはコンテンツと共にリポジトリ内に保存されるので、変更または削除したノードやツリーを迅速に復元できます。

一般

ここで説明する手法は、システムバックアップおよび復元に適用されます。

消失したコンテンツのごく一部のバックアップや復元をおこなう必要がある場合、システムの復元はかならずしも必要ではありません。

  • 別のシステムからパッケージ経由でデータを取得できます。
  • または、バックアップを一時システムに復元し、コンテンツパッケージを作成して、それをシステムのそのコンテンツが消失した場所にデプロイすることができます。

詳しくは、以下の「パッケージバックアップ」を参照してください。

タイミング

バックアップは、データストアのガベージコレクションと同時に実行しないでください。同時に実行すると、この両方のプロセスの結果に悪影響を及ぼす可能性があります。

一般的には、バックアップが実行された後にリビジョンのクリーンアップを実行することをお勧めします。

オフラインバックアップ

オフラインバックアップはいつでも実行できます。このバックアップをおこなうには AEM を停止する必要がありますが、オンラインバックアップと比較して、所要時間については非常に効率的です。

ほとんどの場合、ファイルシステムのスナップショットを使用して、その時点でのストレージの読み取り専用コピーを作成することになります。オフラインバックアップを作成するには、次の手順を実行します。

  • アプリケーションを停止します。
  • スナップショットのバックアップを作成します。
  • アプリケーションを起動します。

通常、スナップショットのバックアップは数秒しかかからないので、全体的な停止時間は数分未満になります。

オンラインバックアップ

このバックアップ方式では、AEM など、リポジトリ下にデプロイされているアプリケーションも含めて、リポジトリ全体のバックアップを作成します。バックアップには、コンテンツ、バージョン履歴、設定、ソフトウェア、ホットフィックス、カスタムアプリケーション、ログファイル、検索用インデックスなどが含まれます。クラスター化を使用していて、(物理的に、またはソフトリンクを使用して)crx-quickstart のサブディレクトリが共有フォルダーとして指定されている場合、共有ディレクトリもバックアップされます。

後でリポジトリ全体(とアプリケーション)を復元できます。

この方式は、ホットバックアップまたはオンラインバックアップとして処理されるものであり、リポジトリの実行中に実行できます。そのため、バックアップの実行中もリポジトリの使用は可能です。 この方式は、デフォルトの Tar ストレージベースのリポジトリインスタンスで有効です。

バックアップの作成には次のオプションがあります。

  • AEM の統合バックアップツールを使用して、ディレクトリにバックアップします。
  • ファイルシステムのスナップショットを使用して、ディレクトリにバックアップします。

どちらの場合も、バックアップによってリポジトリのイメージ(スナップショット)が作成されます。その後、システムのバックアップエージェントによって、そのイメージが実際に専用のバックアップシステム(テープドライブ)に送信されます。

注意:

AEM オンラインバックアップ機能をカスタム blobstore 設定がある AEM インスタンスに使用する場合は、データストアのパスを crx-quickstart ディレクトリ以外の任意の場所に設定することをお勧めします。

警告:

オンラインバックアップのバックアップ対象はファイルシステムのみです。リポジトリコンテンツやリポジトリファイルをデータベースに保存している場合は、そのデータベースを個別にバックアップする必要があります。AEM を MongoDB で使用している場合、MongoDB のネイティブバックアップツールの使用方法のドキュメントを参照してください。

AEM オンラインバックアップ

リポジトリのオンラインバックアップでは、バックアップファイルを作成、ダウンロードおよび削除できます。これは「ホット」(つまり「オンライン」)バックアップ機能であるので、リポジトリが通常どおり読み取り/書き込みモードで使用されているときに実行できます。

バックアップの開始時に、「ターゲットパス」か「遅延」(またはその両方)を指定できます。

ターゲットパス

バックアップファイルは通常、クイックスタート jar ファイル(.jar)が格納されているフォルダーの親フォルダーに保存されます。例えば、AEM jar ファイルが /InstallationKits/AEM の下にある場合、バックアップは /InstallationKits の下に生成されます。ターゲットとする場所を選んで指定することもできます。

TargetPath がディレクトリの場合、リポジトリのイメージはこのディレクトリに作成されます。同じディレクトリが複数回(または常に)バックアップの保存用に使用される場合は、次のようになります。

  • リポジトリ内で修正されたファイルは、TargetPath 内でも同様に修正されます。
  • リポジトリ内で削除されたファイルは、TargetPath 内でも削除されます。
  • リポジトリ内で作成されたファイルは、TargetPath 内でも作成されます。

注意:

TargetPath が拡張子 .zip のファイル名に設定されている場合、リポジトリは一時ディレクトリにバックアップされ、その後この一時ディレクトリのコンテンツが圧縮されて ZIP ファイルに格納されます。

この方式は次の理由で推奨されません。

  • バックアップ処理中に追加のディスク領域が必要になります(一時ディレクトリと zip ファイル分)。
  • 圧縮処理はリポジトリによって行われるので、パフォーマンスに影響する場合があります。
  • バックアッププロセスの遅延につながります。
  • Java 1.6 までは、4 GB までのサイズの ZIP ファイルしか作成できません。

ZIP をバックアップ形式として作成する必要がある場合は、ディレクトリにバックアップしてから、圧縮プログラムを使用して ZIP ファイルを作成してください。

遅延

リポジトリのパフォーマンスが影響を受けないように、遅延時間をミリ秒単位で指定します。

デフォルトでは、リポジトリのバックアップはフルスピードで実行されます。他のタスクの速度を低下させないように、オンラインバックアップの作成速度を下げることができます。

通常、1 ミリ秒の遅延により CPU 使用率は 10%程度になり、10 ミリ秒の遅延により CPU 使用率は 3%未満になります。秒単位の遅延の総時間は次の式で見積もることができます。

    リポジトリサイズ(MB) * 遅延(ミリ秒) / 2(zip オプションを使用する場合)
    または / 4(ディレクトリにバックアップする場合)

つまり、1 ミリ秒の遅延を指定して 200 MB のリポジトリをディレクトリにバックアップする場合、バックアップ時間は約 50 秒増加します。

注意:

 処理の内部詳細については、AEM オンラインバックアップの仕組みを参照してください。

バックアップを作成するには:

  1. 管理者(admin)として AEM にログインします。

  2. ようこそ画面から、左側のメニューに移動して、ツール運営バックアップを選択します。

  3. バックアップコンソールが開きます。必要に応じて、「ターゲットパス」と「遅延」を指定します。

    注意:

    バックアップコンソールは、次のアドレスからもアクセスできます。

        http://<hostname>:<port-number>/libs/granite/backup/content/admin.html

  4. 開始」をクリックします。進行状況バーに、バックアップの進行状況が示されます。

    注意:

    いつでも実行中のバックアップをキャンセルできます。

  5. バックアップが完了すると、コンソールの左側のウィンドウに zip ファイルが表示されます。

    注意:

    不要になったバックアップファイルは、このコンソールを使用して削除できます。左側のウィンドウでバックアップファイルを選択し、「削除」をクリックします。

    注意:

    ディレクトリにバックアップした場合:バックアッププロセスの完了後、CRX によってターゲットディレクトリに書き込まれることはありません。

AEM オンラインバックアップの自動化

可能であれば、オンラインバックアップは、朝など、システムの負荷が少ないときに実行してください。デフォルトでは、リビジョンのクリーンアップは午前 2 時から 5 時の間に実行され、これもシステムの速度低下の原因となります。つまり、オンラインバックアップの実行に適した時間は午前 5 時ということになります。

バックアップは、wget または curl HTTP クライアントを使用して自動化できます。以下に、curl を使用したバックアップの自動化の例を示します。

デフォルトのターゲットディレクトリへのバックアップ

警告:

以下の例では、curl コマンドの様々なパラメーターをお使いのインスタンスに合わせて設定する必要があります。例えば、hostname(localhost)、ポート(4502)、管理者パスワード(xyz)およびファイル名(backup.zip)が該当します。

curl -u admin:admin -X POST http://localhost:4502/system/console/jmx/com.adobe.granite:type=Repository/op/startBackup/java.lang.String?target=backup.zip

バックアップファイル/ディレクトリは、サーバー上で、crx-quickstart フォルダーを含むフォルダーの親フォルダーに作成されます(ブラウザーを使用してバックアップを作成する場合と同様)。例えば、/InstallationKits/crx-quickstart/ ディレクトリに AEM をインストールしている場合、バックアップは /InstallationKits ディレクトリに作成されます。

curl コマンドはすぐに終了するので、このディレクトリを監視して、zip ファイルが作成されているかをかならず確認してください。バックアップの作成中、一時ディレクトリ(ディレクトリ名は、最終の zip ファイルの名前に基づいて付けられる)が出現し、最終的にこのディレクトリが zip で圧縮されます。次に例を示します。

  • 作成される zip ファイルの名前:backup.zip
  • 一時ディレクトリの名前:backup.f4d5.temp

デフォルトのターゲットディレクトリ以外へのバックアップ

通常、バックアップファイルまたはディレクトリは、crx-quickstart フォルダーを含むフォルダーの親フォルダー内に作成されます。

バックアップ(どちらの種類でも)を別の場所に保存する場合は、curl コマンドの target パラメーターに絶対パスを設定できます。

例えば、/Backups/2012 ディレクトリに backupJune.zip を生成するには、次のコマンドを実行します。

curl -u admin:admin -X POST http://localhost:4502/system/console/jmx/com.adobe.granite:type=Repository/op/startBackup/java.lang.String?target=/Backups/2012/backupJune.zip"

警告:

異なるアプリケーションサーバー(JBoss など)を使用している場合、ターゲットディレクトリに書き込みできないという理由でオンラインバックアップが期待どおりに動作しないことがあります。その場合は、サポートまでお問い合わせください。

ファイルシステムのスナップショットのバックアップ

AEM を使用すると、JMX 呼び出しによってディスクへの書き込みを防ぐことができます。これは CRX バックアップツールによって内部で使用されますが、外部処理でも使用できます。

ここで説明する処理は、大容量のリポジトリに特に適しています。

注意:

このバックアップ方式を使用する場合は、システムでファイルシステムのスナップショット機能がサポートされる必要があります。例えば、Linux の場合、ファイルシステムを論理ボリュームに配置する必要があります。

  1. CRX がデプロイされているファイルシステムのスナップショットを作成します。

  2. ファイルシステムのスナップショットをマウントします。

  3. バックアップを実行してスナップショットのマウントを解除します。

データストアを別個にバックアップ

メインリポジトリの外側で設定されているファイルデータストアは、バックアップには含まれません。これによってオンラインバックアップおよびバックアップディレクトリのサイズが削減されます。ただし、データストアもバックアップする必要があります。ファイルデータストアディレクトリ内のファイルは不変なので、増分バックアップを行ったり(rsync を使用するなど)、オンラインバックアップを実行後にバックアップしたりできます。

注意:

データストアのバックアップとリビジョンのクリーンアップは、同時には実行しないでください。

AEM オンラインバックアップの仕組み

AEM オンラインバックアップは、バックアップ対象のデータと作成されるバックアップファイルの整合性を確保するための一連の内部アクションにより構成されます。以下に、関心のある開発者向けに、これらの内部アクションについて示します。

  1. オンラインバックアップでは次のアルゴリズムを使用します。
  2. zip ファイル作成時の最初の手順は、ターゲットディレクトリを作成または指定することです。
    1. zip ファイルにバックアップする場合、一時ディレクトリが作成されます。ディレクトリ名は backup. で始まり、.temp で終わります(例:backup.f4d3.temp)。
    2. ディレクトリにバックアップする場合、ターゲットパスに指定された名前が使用されます。既存のディレクトリを使用できますが、それが存在しない場合は新しいディレクトリが作成されます。
      バックアップの開始時に、ターゲットディレクトリ内に backupInProgress.txt という空のファイルが作成されます。このファイルは、バックアップの完了時に削除されます。
  3. すべてのファイルがソースディレクトリからターゲットディレクトリ(または zip ファイルの作成時には一時ディレクトリ)にコピーされます。このサブプロセスの進行状況バーは、zip ファイルが作成されるときには 0 ~ 70%、zip ファイルが作成されない場合は 0 ~ 100%となります。
  4. バックアップが既存のディレクトリに作成される場合は、ターゲットディレクトリ内にある「古い」ファイルが削除されます。古いファイルとは、ソースディレクトリ内に存在しないファイルのことです。
  5. ファイルのターゲットディレクトリへのコピーは、以下の 4 段階で実行されます。
    1. コピーの第 1 段階(進行状況インジケーターは zip ファイルの作成時は 0 ~ 63%、zip ファイルが作成されない場合は 0 ~ 90%)では、リポジトリの通常運用と並行して、すべてのファイルがコピーされます。
    2. コピーの第 2 段階(進行状況インジケーターは zip ファイルの作成時は 63 ~ 66.5%、zip ファイルが作成されない場合は 90 ~ 95%)では、コピーの第 1 段階の開始以降にソースディレクトリ内で作成または変更されたファイルのみがコピーされます。リポジトリのアクティビティに応じて、処理されるファイルがない場合もあれば、(コピーの第 1 段階では通常長い時間がかかるので)多数のファイルが処理される場合もあります。
    3. コピーの第 3 段階(進行状況インジケーターは zip ファイルの作成時は 66.5 ~ 68.6%、zip ファイルが作成されない場合は 95 ~ 98%)では、コピーの第 2 段階の開始以降にソースディレクトリ内で作成または変更されたファイルのみがコピーされます。リポジトリのアクティビティに応じて、コピーされるファイルがない場合もあれば、(ファイルコピーの第 2 段階は通常短時間で終了するので)ごく少数のファイルがコピーされる場合もあります。
    4. ファイルコピーの第 1 段階から第 3 段階まではすべて、リポジトリの運用中に並行して実行されます。最後となるファイルコピーの第 4 段階では、最初にリポジトリの書き込み操作をロックします(書き込み操作が一時停止されます。例外をスローするのではなく、待機します)。コピーの第 3 段階の開始以降にソースディレクトリ内で作成または変更されたファイルのみがコピーされます。リポジトリのアクティビティに応じて、コピーされるファイルがない場合もあれば、(コピーの第 2 段階は通常すぐに実行されるので)非常に少数のファイルが処理される場合もあります。その後、リポジトリへのアクセスが再開されます。進行状況インジケーターは、zip ファイルの作成時には 68.6 ~ 70%、zip ファイルが作成されない場合は 98 ~ 100%になります。
  6. ターゲットに応じて、次の処理が実行されます。
    1. zip ファイルが指定されている場合、この時点でこのファイルが一時ディレクトリから作成されます。進行状況インジケーターは 70 ~ 100%を示します。その後、一時ディレクトリが削除されます。
    2. ターゲットがディレクトリの場合は、バックアップが完了したことを示すために、backupInProgress.txt という空のファイルが削除されます。

バックアップの復元

注意:

この種の復元では、アプリケーション、すべてのコンテンツ、ログファイルを含むリポジトリ全体が復元されます。

バックアップからバックアップを復元するには:

  1. システム上でバックアップ画像を復元します。データストアを別個にバックアップした場合は、データストアも正しい場所に復元されることを確認してください。

    バックアップを zip ファイルとして作成した場合は、以下を使用してこの zip ファイルを解凍します。

    jar -xvf backupJune.zip
  2. Unix システムでは、以下のスクリプトの「x」ビットは、zip ファイルでは保持されません。

    • server/start
    • server/stop
    • server/serverctl

    これらは、バックアップを復元後に手動で調整する必要があります。

  3. これで、リポジトリが使用できる状態になりました。通常の起動スクリプトを使用してリポジトリを起動できます。

この方法には、以下のような独自の特徴があります。

  • 追加のディスク利用は少なく、スナップショットでは、元のデータ上のデータが変更された場合に限り領域が消費されます。
  • スナップショットは非常に高速かつ効率的であり、メタデータのみが重複するので、スナップショットの作成に必要な時間は少なくなります(データのコピーよりも大幅に少ない)。

パッケージバックアップ

コンテンツをバックアップおよび復元するには、いずれかのパッケージマネージャーを使用できます。コンテンツパッケージ形式を使用してコンテンツのバックアップおよび復元が行われます。パッケージマネージャーでは、パッケージをより柔軟に定義および管理できます。

これらの個別のコンテンツパッケージ形式の機能およびトレードオフについて詳しくは、ユーザーガイドのパッケージの使用方法を参照してください。

バックアップの範囲

パッケージマネージャーまたはコンテンツジッパーを使用してノードをバックアップすると、CRX では次の情報が保存されます。

  • 選択したツリーの下にあるリポジトリコンテンツ。
  • バックアップするコンテンツに使用されているノードタイプの定義
  • バックアップするコンテンツに使用されている名前空間の定義

バックアップの際に、AEM では次の情報が失われます。

  • バージョン履歴

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー