バックアップの作成

セルフホスト型のインスタンスの場合は、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 など）を使用して作成できます。

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

クラスタ環境

クラスタ化された 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> は、前に作成した鍵ファイルです。

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

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

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

バックアップを復元する

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

次のステップ

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