バックアップの作成

警告: インスタンスがセルフホスト型の場合は、インスタンスのファイル システム上の LookML ファイルを直接変更しないでください。直接変更すると、Git ワークフローで予期しないエラーが発生する可能性があります。LookML ファイルを変更するには、バージョン管理機能の使用とデプロイの手順に従います。

セルフホスト型のインスタンスの場合は、Looker ユーザーのホーム　ディレクトリ（通常のサブディレクトリと非表示のサブディレクトリのすべてを含む）のコピーを作成するだけで、Looker の基本インストールのバックアップを作成できます。これは、scp、rsync、または任意の標準バックアップ アプリケーションで実施できます。同様に、Looker の基本インストールを復元するには、ファイルを復元して Looker を起動するだけです。

クラスタ化環境などの一部の構成では、Looker がアプリケーション設定、ユーザー アカウント、その他のデータ用に外部 MySQL データベースを使用します。この場合は、Looker のホーム ディレクトリに加えて、MySQL データベースのバックアップを作成することをおすすめします。

これらのバックアップは、毎日作成することを強くおすすめします。また、四半期に 1 回、テスト復元を行うことをおすすめします。

ディレクトリ構造

Looker ユーザーのホーム ディレクトリ（通常は /home/looker）にある標準のサブディレクトリについて説明します。

• home
  • looker
  • .ssh
  • looker
    • .cache
    • .db
    • .ssl
    • .tmp
    • deploy_keys
    • log
    • モデル
    • models-user-1

ディレクトリ	バックアップが必須	間隔を変更	説明
.ssh	はい	まれ	Looker 4.6 以前で作成された LookML プロジェクトの Git 認証に使用される SSH 認証鍵
looker/.cache	いいえ	よく使う連絡先	一時的なキャッシュ ファイル
looker/.db	はい、バックエンド DB が MySQL に移行している場合を除く	よく使う連絡先	Looker の内部データベース
looker/.snapshots	いいえ	更新時	更新中に、Looker jar と .db ディレクトリのバックアップ コピーがここに保存されます。
looker/.ssl	未定	まれ	自己署名 SSL 証明書（注を参照）
looker/.tmp	いいえ	よく使う連絡先	一時ファイル
looker/deploy_keys	はい	まれ	Looker 4.8 以降で作成された LookML プロジェクトの Git 認証に使用される SSH 認証鍵
looker/log	未定	よく使う連絡先	ログファイル（保持ポリシーで必要な場合のみ）
looker/models	いいえ	変数	本番環境モデル、ソース リポジトリ（通常は GitHub）からコピー
looker/models-user-*	はい	変数	各ユーザーの開発モデルは、ユーザーの ID 番号とともに別のディレクトリに保存されています

SSL 注: デフォルトでは、SSL ディレクトリに含まれる自己署名 SSL 証明書を保持する必要はありません。ただし、このディレクトリに証明書機関によって署名された SSL 証明書などの追加ファイルを保存する場合は、このディレクトリをバックアップに追加する必要があります。

バックアップに追加する必要がある Looker ホーム ディレクトリ外のファイルは次のとおりです。

ディレクトリ	バックアップが必須	間隔を変更	説明
/etc/init.d/looker	はい	まれ	Looker のシステム起動スクリプト
SSL 証明書	はい	まれ	SSL 証明書を使用している場合は、必要なファイルがすべて含まれていることを確認します。

通常は問題になりませんが、バックアップに looker/.db/looker.lck ファイルが含まれている場合の問題がお客様から報告されています。このファイルは、必要に応じて安全に除外できます。

Looker バックアップの作成

Looker のバックアップは、標準のバックアップ アプリケーションや、コマンドライン ツール（rsync など）を使用して作成できます。

バックアップ プロセスは、アプリケーションの使用頻度が可能な限り低いときに実行することをおすすめします。通常のユーザー操作に加えて、スケジュール設定されたルックの実行時間や、派生テーブルの再ビルド時間などを考慮してください。

クラスタ化された環境

クラスタ化された Looker では、アプリケーション構成、ユーザー アカウントなどのデータを外部の MySQL データベースに保存できます。Looker アプリケーションと同時に、このデータベースのバックアップの作成をおすすめします。MySQL データベースのバックアップ方法については、MySQL のドキュメントをご覧ください。

キーストア非依存のバックアップの生成

AES-256 GCM 暗号化に移行され、AWS KMS を使用しないセルフホスト型インストールでは、この手順で、ローカルの顧客マスター鍵（CMK）に依存しない Looker インスタンスのバックアップを作成できます。これにより、セルフホストのお客様は、CMK を提供せずに Looker でホストされるインストールに移行したり、同じローカルのキーストアにアクセスできない新しいホストのセルフホスト型インストールに移行したりできます。

キーストアに依存しないバックアップを作成するには:

1. Looker を停止します。

   cd looker
   ./looker stop
   

   Looker がクラスタ化されている場合は、作業を続行する前にすべてのノードを停止してください。

2. Looker が CMK にアクセスできることを確認します。CMK がファイルに保存されている場合は、環境変数 LKR_MASTER_KEY_FILE を使用して CMK ファイルのパスを指定します。

   export LKR_MASTER_KEY_FILE=<path_to_CMK_file>
   

   または、環境変数で CMK を直接指定するには、LKR_MASTER_KEY_ENV 環境変数を使用します。

   export LKR_MASTER_KEY_ENV=<CMK_value>
   

3. 鍵暗号鍵（KEK）の再暗号化に使用する新しい鍵ファイルを生成します。

   ./looker generate_keyfile_for_backup <key_file_name>
   

   ここで、<key_file_name> は、Looker が作成して新しい鍵の書き込みに使用するファイルに使用する名前です。

   新しいキーファイルの内容は、次のようになります。

   {"dbmk":"vr1LUwO3q6weY8iS3JykVljSjiD4m6eGk227Cs7Qu9Q=\n","backup_uid":"XCXvRa38mNeqT6+HRBCo2Q=="}
   

   ここで、dbmk の値は、Base64 エンコードの 256 ビット暗号鍵であり、backup_uid は鍵をデータベースに保存するときに使用する一意の名前です。

4. 新しい鍵ファイルを使用して、Looker の内部データベースに新しい鍵エントリを作成します。

   ./looker keystore_independent_recrypt <key_file_name>
   

   ここで、<key_file_name> は、前に作成した鍵ファイルです。

   これにより、CMEK を使用して内部データベース内の KEK が復号され、新しい鍵で KEK が再暗号化され、その暗号化された値がデータベースに保持されます。

5. 通常のバックアップ方法を使用して Looker のバックアップを作成します。

このキーストア非依存バックアップを復元するには、前に作成した新しい鍵ファイルを使用する必要があります。

バックアップを復元する

Looker のバックアップを復元するには、ドキュメント ページのバックアップの復元をご覧ください。

次のステップ

バックアップを設定したら、Looker が必要なサービスにアクセスできることを確認できます。