고객 호스팅 인스턴스의 경우 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/.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 백업 만들기
모든 표준 백업 애플리케이션은 물론 rsync와 같은 명령줄 도구를 사용하여 Looker 백업을 만들 수 있습니다.
백업 프로세스는 애플리케이션의 사용량이 최대한 적을 때 실행되는 것이 가장 좋습니다. 일반적인 사용자 상호작용 외에도 예약된 Look이 실행 중인 시간, 파생된 테이블이 다시 빌드되는 시간 등을 고려하세요.
클러스터링된 환경
클러스터링된 Looker는 애플리케이션 구성, 사용자 계정, 기타 데이터를 외부 MySQL 데이터베이스에 저장합니다. Looker 애플리케이션과 동시에 이 데이터베이스의 백업을 만드는 것이 좋습니다. MySQL 데이터베이스 백업 방법에 대한 자세한 내용은 MySQL 문서를 참조하세요.
키 저장소 독립 백업 생성
AES-256 GCM 암호화로 마이그레이션되었지만 AWS KMS를 사용하지 않는 고객 호스팅 설치에서는 이 절차를 사용하여 로컬 고객 마스터 키(CMK)와 독립적인 Looker 인스턴스 백업을 만들 수 있습니다. 이를 통해 자체 호스팅 고객은 CMK를 제공하지 않고도 Looker 호스팅 설치로 이동하거나 고객 호스팅 설치를 동일한 로컬 키 저장소에 액세스할 수 없는 새 호스트로 옮길 수 있습니다.
키 저장소 독립형 백업을 만들려면 다음 안내를 따르세요.
Looker를 중지합니다.
cd looker ./looker stopLooker가 클러스터링된 경우 계속하기 전에 모든 노드를 중지해야 합니다.
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>은 앞에서 만든 키 파일입니다.이렇게 하면 CMK를 사용하여 내부 데이터베이스의 KEK를 복호화한 다음 새 키로 KEK를 다시 암호화하고 암호화된 값을 데이터베이스에 유지합니다.
일반적인 백업 방법을 사용하여 Looker의 백업을 만듭니다.
이 키 저장소 독립형 백업을 복원하려면 이전에 만든 새 키 파일이 필요합니다.
백업 복원
Looker 백업을 복원하려면 백업 복원 문서 페이지를 참고하세요.
다음 단계
백업을 설정하면 Looker에서 필요한 서비스에 액세스할 수 있도록 준비됩니다.