고객 호스팅 인스턴스의 경우 Looker 사용자의 홈 디렉터리(모든 일반 및 숨겨진 하위 디렉터리 포함)의 사본을 만들어 간단히 기본 Looker 설치 백업을 만들 수 있습니다. 이 작업을 scp, rsync 또는 모든 표준 백업 애플리케이션을 통해 수행할 수 있습니다. 마찬가지로 기본 Looker 설치를 복원하려면 파일을 복원하고 Looker를 시작하기만 하면 됩니다.
클러스터링된 환경을 비롯한 일부 구성에서 Looker는 애플리케이션 설정, 사용자 계정, 기타 데이터에 외부 MySQL 데이터베이스를 사용합니다. 이 경우 Looker 홈 디렉터리 외에도 MySQL 데이터베이스의 백업을 만드는 것이 좋습니다.
이러한 백업을 매일 만드는 것이 좋습니다. 또한 분기에 한 번 테스트 복원을 실행하는 것이 좋습니다.
디렉터리 구조
Looker 사용자의 홈 디렉터리(일반적으로 /home/looker)에 있는 표준 하위 디렉터리가 여기에 설명되어 있습니다.
folder 홈
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 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 백업 만들기
모든 표준 백업 애플리케이션은 물론 rsync와 같은 명령줄 도구를 사용하여 Looker 백업을 만들 수 있습니다.
백업 프로세스는 애플리케이션의 사용량이 최대한 적을 때 실행되는 것이 가장 좋습니다. 일반적인 사용자 상호작용 외에도 예약된 Look이 실행 중인 시간, 파생된 테이블이 다시 빌드되는 시간 등을 고려하세요.
클러스터링된 환경
클러스터링된 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 환경 변수를 사용하면 됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-22(UTC)"],[],[],null,["# Creating backups\n\nIf your Looker instance is Looker-hosted, Looker automatically performs regular backups for your instance. See the [Automatic backups for Looker-hosted instances](#automatic) section for more information.\n\nIf your instance is customer-hosted, then you will need to create your own backups. See the [Backup strategy for customer-hosted instances](#customer-hosted) section for more information.\n\nAutomatic backups for Looker-hosted instances\n---------------------------------------------\n\nLooker-hosted instances are backed up automatically, once every 24 hours. Each backup contains a record of all the data in the instance's internal database and in the instance's file server, which is most of the operational data for the Looker instance. However, the data for [Elite System Activity](/looker/docs/elite-system-activity) is not backed up.\n\nBackups are retained for 30 days. To access and restore a backup, [contact Support](/looker/docs/best-practices/looker-support-details).\n| **Caution:** Disabling the Looker API disables the ability to create instance backups.\n\nBackup strategy for customer-hosted instances\n---------------------------------------------\n\n| **Warning:** If your instance is customer-hosted, do not modify LookML files directly on the filesystem of your instance. This can cause unexpected errors in your Git workflow. To make changes to your LookML files, follow the steps at [Using version control and deploying](/looker/docs/version-control-and-deploying-changes).\n\nFor customer-hosted instances, you can create a backup of a basic Looker installation simply by making a copy of the Looker user's home directory (including all normal and hidden subdirectories). You can use `scp`, `rsync`, or any standard backup application. Similarly, restoring a basic Looker installation just requires restoring the files and starting up\nLooker.\n\nIn some configurations, including clustered environments, Looker uses an external MySQL database for application settings, user accounts, and other data. In this case we recommend creating a backup of the MySQL database, in addition to the Looker home directory.\n\nWe highly recommend that you create these backups daily. We also recommend performing a test restoration once per quarter.\n\n### Directory structure\n\nThe standard subdirectories under the Looker user's home directory (usually **/home/looker**) are described here.\n\n- *folder* home\n - *folder* looker\n - *folder* .ssh\n - *folder* looker\n - *folder* .cache\n - *folder* .db\n - *folder* .ssl\n - *folder* .tmp\n - *folder* deploy_keys\n - *folder* log\n - *folder* models\n - *folder* models-user-1\n\n\n**SSL Note:** By default the SSL directory only contains a self-signed SSL cert, which does not need to be retained. However, if you store any additional files in this directory --- such as SSL certificates signed by a certificate authority --- this directory should be added to your backup.\n\nFiles outside of the Looker home directory, which should be added to your backup, include the following:\n\n\u003e Although it doesn't typically cause problems, some customers have reported issues if they include the `looker/.db/looker.lck` file in their backups. You can safely exclude this file if necessary.\n\n### Creating a backup\n\nYou can create a backup of your Looker instance with any standard backup application, as well as with command line tools such as rsync.\n\nIt is best for the backup process to run when the application is as lightly used as possible. In addition to normal user interaction, consider the times that scheduled Looks might be running, derived tables might be rebuilding, etc.\n\n#### Clustered environments\n\nClustered Looker instances store their application configuration, user accounts, and other data in an external MySQL database. We recommend creating a backup of this database at the same time as the Looker application. See the [MySQL documentation](https://dev.mysql.com/doc/refman/5.0/en/backup-and-recovery.html) for more details on how to back up MySQL databases.\n\n### Generating a keystore-independent backup\n\nA customer-hosted installation that has [migrated to AES-256 GCM encryption](/looker/docs/migrating-to-aes-256-gcm-encryption) and is not using AWS KMS can use this procedure to create a backup of their Looker instance that is independent of their local Customer Master Key (CMK). This procedure provides a method for migrating a customer-hosted instance to a Looker-hosted instance without having to provide a CMK, or for moving a customer-hosted instance to a new host that does not have access to the same local keystore.\n\nTo create a keystore-independent backup:\n\n1. Stop Looker:\n\n cd looker\n ./looker stop\n\n \u003e If your Looker instance is clustered, make sure to stop every node before proceeding.\n2. Ensure that your Looker instance can access your CMK. If your CMK is stored in a file, you can use the environment variable `LKR_MASTER_KEY_FILE` to point to the path of your CMK file:\n\n export LKR_MASTER_KEY_FILE=\u003cpath_to_CMK_file\u003e\n\n Or, to provide your CMK directly in an environment variable, you can use the `LKR_MASTER_KEY_ENV` environment variable: \n\n export LKR_MASTER_KEY_ENV=\u003cCMK_value\u003e\n\n3. Generate a new key file that will be used to re-encrypt the Key Encryption Key (KEK):\n\n ./looker generate_keyfile_for_backup \u003ckey_file_name\u003e\n\n Where `\u003ckey_file_name\u003e` is the name you want to use for the file that Looker will create and then use to write the new key.\n\n The contents of the new key file will look like: \n\n {\"dbmk\":\"vr1LUwO3q6weY8iS3JykVljSjiD4m6eGk227Cs7Qu9Q=\\n\",\"backup_uid\":\"XCXvRa38mNeqT6+HRBCo2Q==\"}\n\n Where the value for `dbmk` is a Base64 encoding 256 bit encryption key and `backup_uid` is a unique name used when saving the key to the database.\n4. Use the new key file to create a new key entry in Looker's internal database:\n\n ./looker keystore_independent_recrypt \u003ckey_file_name\u003e\n\n Where `\u003ckey_file_name\u003e` is the key file created earlier.\n\n This decrypts the KEK in the internal database using the CMK, then re-encrypts the KEK with the new key and persists that encrypted value to the database.\n5. Create a backup of your Looker instance using your regular backup method.\n\nTo [restore this keystore-independent backup](/looker/docs/restoring-backups#restoring_a_keystore-independent_backup), you will need the new key file created earlier.\n\n### Restoring backups\n\nTo restore a backup of your Looker instance, see the [Restoring backups](/looker/docs/restoring-backups) documentation page.\n\nNext steps\n----------\n\nAfter you have set up backups, you will be ready to [ensure that your Looker instance can access necessary services](/looker/docs/outbound-port-requirements)."]]
