セルフホスト型のインスタンスの場合は、Looker ユーザーのホーム ディレクトリ(通常のサブディレクトリと非表示のサブディレクトリのすべてを含む)のコピーを作成するだけで、Looker の基本インストールのバックアップを作成できます。これは、scp
、rsync
、または任意の標準バックアップ アプリケーションで実施できます。同様に、Looker の基本インストールを復元するには、ファイルを復元して Looker を起動するだけです。
クラスタ化環境などの一部の構成では、Looker がアプリケーション設定、ユーザー アカウント、その他のデータ用に外部 MySQL データベースを使用します。この場合は、Looker のホーム ディレクトリに加えて、MySQL データベースのバックアップを作成することをおすすめします。
これらのバックアップは、毎日作成することを強くおすすめします。また、四半期に 1 回、テスト復元を行うことをおすすめします。
ディレクトリ構造
Looker ユーザーのホーム ディレクトリ(通常は /home/looker)にある標準のサブディレクトリについて説明します。
- folder home
- folder looker
- folder .ssh
- folder looker
- folder .cache
- folder .db
- folder .ssl
- folder .tmp
- folder deploy_keys
- folder log
- folder モデル
- folder 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 でホストされるインストールに移行したり、同じローカルのキーストアにアクセスできない新しいホストのセルフホスト型インストールに移行したりできます。
キーストアに依存しないバックアップを作成するには:
Looker を停止します。
cd looker ./looker stop
Looker がクラスタ化されている場合は、作業を続行する前にすべてのノードを停止してください。
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>
鍵暗号鍵(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
は鍵をデータベースに保存するときに使用する一意の名前です。新しい鍵ファイルを使用して、Looker の内部データベースに新しい鍵エントリを作成します。
./looker keystore_independent_recrypt <key_file_name>
ここで、
<key_file_name>
は、前に作成した鍵ファイルです。これにより、CMEK を使用して内部データベース内の KEK が復号され、新しい鍵で KEK が再暗号化され、その暗号化された値がデータベースに保持されます。
通常のバックアップ方法を使用して Looker のバックアップを作成します。
このキーストア非依存バックアップを復元するには、前に作成した新しい鍵ファイルを使用する必要があります。
バックアップを復元する
Looker のバックアップを復元するには、ドキュメント ページのバックアップの復元をご覧ください。
次のステップ
バックアップを設定したら、Looker が必要なサービスにアクセスできることを確認できます。