Backup Service
ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、 こちら までご連絡ください。

バックアップページからのデータの復元

プロジェクトの開発中に、データを復元したり、プロジェクトを以前の状態にロールバックしたりする必要がある場合があります。 バックアップをある環境に復元しても、各サービスのデータは復元されますが、環境が使用しているビルドは変更されません

また、カスタムSQLスクリプトを使用して、データ復元の一環としてデータベースの追加更新を行うこともできます。

重要

バックアップ サービスがバージョン 5.x より古い場合、ダウンタイムが発生する可能性があります。

重要

選択した環境のAdminロールを持つユーザーのみが、Liferay Cloudコンソールを介して環境を手動で復元できます。

バックアップページから環境を復元する

各環境の バックアップ ページには、最近取得されたすべてのバックアップ(自動および手動)のリストがあります。 このページから環境へバックアップを復元すると、各サービスが使用しているデータは復元されますが、各サービスが使用しているビルドやDockerイメージは変更されません

警告

復元するバックアップの バックアップ サービスのバージョンは、復元が正常に完了するように、復元前のターゲット環境と一致している必要があります。 データベース スキーマの不一致によるエラーを回避するには、Liferay フィックスパック レベル も一致する必要があります。 環境に現在デプロイされているものとは異なるビルドを必要とするバックアップを復元する場合は、復元を開始する前に 適切なビルドをデプロイ してください。

以下の手順で、バックアップから環境を復元します。

  1. プロジェクトで選択した環境に移動します。

  2. 画面左側の環境メニューにある[Backups]をクリックします。

  3. プロジェクト環境の復元に使用したいバックアップの アクション ボタン(⋮)をクリックします。

  4. 「復元」をクリック…

    [アクション] ボタンをクリックし、[復元先...] をクリックします。

  5. データベースのバックアップのみを復元する場合は、チェックボックスをオンにします。 これは、データベース スキーマの変更をテストして、ストレージ コストを削減し、非本番環境を最適化する場合に役立ちます。

    警告

    データベースのみの復元は、実稼働環境では推奨されません。 高速ではありますが、ドキュメント ライブラリなしでバックアップを復元すると、データベースとドキュメント ライブラリが同期されなくなる可能性があります。

  6. ドロップダウンの [Environment] メニューをクリックして、復元したい環境を選択します。

    復元する環境を選択します。

    管理者は、アクセスできる環境のみを復元できます。

  7. 下に表示される チェックボックス をすべてクリックします。 復元を開始するボタンを有効にするには、これらのボックスをチェックする必要があります。

  8. [Restore to Environment] をクリックして、復元処理を開始します。

    復元を確認するには、すべてのチェックボックスをクリックします。

復元プロセス中に、ターゲット環境のサービスが再起動します。

復元の状態は、バックアップ サービスの ログ とアクティビティ ページの 全般 セクションで追跡できます。

データ復元でのカスタムSQLスクリプトの適用

また、カスタム SQL スクリプトを使用して、通常のデータ復元でデータベースの追加更新を行うこともできます。 この方法では、別々に管理しているデータベースのバックアップにスクリプトを適用できるため、機密データのサニタイズに最適です。

SQL スクリプトは次の形式をサポートします。

  • .sql は個々のスクリプトに使われます。
  • .zip.tgz.gz は、圧縮ファイル内の複数のスクリプトに使用されます。

PostgreSQL用SQLスクリプトの準備

PostgreSQL のスクリプトは、シークレット lcp-secret-database-nameで指定されたデータベースでのみ実行されます。 修飾子なし、または public スキーマを持つテーブルを指定します (例: update journalarticle または update public.journalarticle)。

lcp-secret-database-user シークレットで指定されたデータベース ユーザーは、次のオプションを使用して psql コマンドでスクリプトを実行するために使用されます。

  • --single-transaction: すべてのコマンドを 1 つのトランザクション内で実行します。
  • -v ON_ERROR_STOP=1: 発生したすべてのエラーを強制的にスクリプトの実行を停止し、復元プロセスでエラーを報告します。

次の例のように、バックアップ ログでスクリプト実行の詳細を確認できます。

バックアップ ログには、実行された SQL スクリプトの詳細が含まれます。

スクリプトの実行中にエラー (構文エラーなど) が発生すると、復元プロセスが失敗し、復元ログにエラーが報告されます。 ここではエラーの例です:

スクリプトの実行中にエラーが発生すると、復元プロセスが中止され、復元ログにエラー メッセージが記録されます。

SQL スクリプトを、適切な環境固有の backup/configs/[ENV]/scripts/ フォルダーに配置します。 スクリプトは英数字順に実行されることに注意してください。

MySQL用SQLスクリプトの準備

MySQL 用のスクリプトは、実行するデータベースを正確に参照する必要があります (例: USE lportal; または lportal.User_)。

SQL スクリプトを、適切な環境固有の backup/configs/[ENV]/scripts/ フォルダーに配置します。 スクリプトは英数字順に実行されることに注意してください。

データの復元の実行

SQLスクリプトの準備ができたら、以下の手順でカスタムSQLスクリプトをデータリストアに適用します。

  1. バックアップ サービスを展開して 、カスタム SQL スクリプトをオンラインで含めます。

  2. 上記の手順に従って、 バックアップページから環境を復元する

データベースが復元されると、バックアップ サービスの スクリプト フォルダーにある SQL スクリプトが実行されます。

Jun 20 14:46:41.795 build-39 [backup-57488f8b8-rjq4f] Running Script: SanitizeOrg.sql
Jun 20 14:46:41.970 build-39 [backup-57488f8b8-rjq4f] Running Script: SanitizeUsers.sql