백업 만들기

고객 호스팅 인스턴스의 경우 Looker 사용자의 홈 디렉터리(모든 일반 및 숨겨진 하위 디렉터리 포함)의 사본을 만들어 간단히 기본 Looker 설치 백업을 만들 수 있습니다. 이 작업을 scp, rsync 또는 모든 표준 백업 애플리케이션을 통해 수행할 수 있습니다. 마찬가지로 기본 Looker 설치를 복원하려면 파일을 복원하고 Looker를 시작하기만 하면 됩니다.

클러스터링된 환경을 포함한 일부 구성에서는 Looker가 애플리케이션 설정, 사용자 계정, 기타 데이터에 외부 MySQL 데이터베이스를 사용합니다. 이 경우 Looker 홈 디렉터리 외에 MySQL 데이터베이스의 백업을 만드는 것이 좋습니다.

이러한 백업은 매일 만드는 것이 좋습니다. 또한 분기별로 한 번씩 테스트 복원을 수행하는 것이 좋습니다.

디렉터리 구조

Looker 사용자의 홈 디렉터리(일반적으로 /home/looker)에 있는 표준 하위 디렉터리가 여기에 설명되어 있습니다.

    • 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 백업 만들기

모든 표준 백업 애플리케이션은 물론 rsync와 같은 명령줄 도구를 사용하여 Looker 백업을 만들 수 있습니다.

백업 프로세스는 애플리케이션의 사용량이 최대한 적을 때 실행되는 것이 가장 좋습니다. 일반적인 사용자 상호작용 외에도 예약된 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가 필요한 서비스에 액세스할 수 있는지 확인합니다.