장기 보관 백업 복원

독립형 유틸리티를 사용하여 Cloud Storage 버킷에서 직접 장기 보관 백업을 복구할 수 있으므로 활성 Backup and DR 어플라이언스가 없어도 데이터에 액세스할 수 있습니다.

이 문서에서는 이 독립형 복구 유틸리티를 사용하여 백업 및 DR OnVault 및 Compute Engine 백업 이미지를 검색, 확인, 마운트, 복원하는 방법을 설명합니다.

개요

장기 보관된 백업은 규정 준수 및 보관을 위해 OnVault 정책을 사용하여 Cloud Storage 버킷에 저장됩니다. 백업 인프라와 관계없이 데이터에 액세스할 수 있도록 하려면 독립형 복구 유틸리티를 사용하여 스토리지 버킷에서 직접 이 데이터를 검색, 확인, 복원하면 됩니다. 이는 원래 백업/복구 어플라이언스를 사용할 수 없는 재해 복구 또는 폐기 시나리오에 중요합니다.

시작하기 전에

장기 보관 백업을 복원하기 전에 다음 섹션을 완료하세요.

필요한 역할 얻기

장기 보관 백업을 복원하는 데 필요한 권한을 얻으려면 관리자에게 대상 Cloud Storage 버킷에 대한 백업 및 DR Cloud Storage 운영자 (roles/backupdr.cloudStorageOperator) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

기타 기본 요건

장기 보관 백업을 복원하기 전에 다음 기본 요건을 충족하는지 확인하세요.

  1. 복구를 시작하기 전에 OnVault 스토리지에서 데이터를 사용할 수 있는지 확인하세요. 백업/복구 어플라이언스 풀에서 기존 백업을 확인하고 관련 OnVault 보호 정책을 할당하여 OnVault로 마이그레이션합니다.

  2. 영구 디스크 스냅샷이 포함된 복구 시나리오의 경우 모든 백업 메타데이터가 타겟 Cloud Storage 버킷에 복제되었는지 확인합니다. 복구 유틸리티는 이 메타데이터를 사용하여 스냅샷 이미지를 분류하고 처리합니다. 데이터 전송을 용이하게 하고 메타데이터가 Cloud Storage 버킷에 있는지 확인하려면 Cloud Customer Care에 문의하세요.

  3. 이 도구를 실행하는 호스트 시스템이 다음 요구사항을 충족하는지 확인합니다.

    • gcloud CLI: PATH 환경 변수 (특히 gcloud storage)에 설치되어 액세스할 수 있습니다.
    • 인증: gcloud auth login를 실행하거나 애플리케이션 기본 사용자 인증 정보 (ADC) 또는 서비스 계정 키를 사용하여 활성 사용자 인증 정보로 구성됩니다.

  4. 복구 유틸리티와 함께 사용할 Cloud Storage 버킷 이름과 해당 Google Cloud 프로젝트 ID 목록을 확인하고 보관합니다.

복구 유틸리티 배포

복구 프록시 또는 대상 애플리케이션 호스트로 사용할 VM 인스턴스를 구성한 다음 독립형 복구 도구를 배포합니다.

어플라이언스, 호스트, 이미지 검색

독립형 복구 유틸리티는 명령어에 대해 버킷 및 프로젝트 값(--bucket 및 --project) 쌍을 허용합니다. 이 유틸리티는 다음 작업을 지원합니다.

  • 애플리케이션 나열
  • 백업 표시
  • 백업 만료
  • 백업 이미지 마운트
  • 백업 이미지 마운트 해제

백업 이미지 마운트

복구 마운트를 실행하려면 먼저 백업 이미지 이름을 식별해야 합니다.

사용 가능한 백업을 나열하여 백업 이미지 이름을 확인합니다.

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

그런 다음 비대화형 복구 마운트를 실행하려면 다음 샘플과 유사한 명령어를 사용하여 선택한 백업 이미지를 지정된 복구 프록시 또는 타겟 데이터베이스 서버에 직접 마운트합니다.

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

다음을 바꿉니다.

  • BUCKET_NAME: Cloud Storage 버킷의 이름
  • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
  • APPLIANCE_NAME: 백업/복구 어플라이언스의 이름 또는 ID입니다.
  • HOST_NAME: 소스 호스트의 호스트 이름 또는 ID입니다.
  • APPLICATION_NAME: 보호된 애플리케이션의 이름 또는 ID입니다.
  • IMAGE_NAME: 마운트할 활성 백업 이미지의 이름입니다.
  • MOUNT_POINT: (선택사항) 백업이 마운트되는 로컬 디렉터리 경로입니다. 기본값은 /tmp/recovery_folder입니다.

추출이 완료되면 마운트 지점 디렉터리에서 백업된 데이터를 볼 수 있습니다.

애플리케이션 복원

원시 데이터베이스 파일에 액세스하려면 MOUNT_POINT/restored_data/로 이동하세요. 워크로드 유형 및 마운트 구성의 복구 경로를 선택합니다.

Microsoft SQL

  1. 파일 찾기: db_volume/ 디렉터리에서 기본 .mdf 및 .ldf 데이터베이스 파일을 식별합니다.
  2. 직접 연결 (동일한 호스트): 타겟 데이터베이스 인스턴스를 중지합니다. SQL Server Management Studio를 열고 데이터베이스 연결을 선택한 다음 복구 마운트 지점 디렉터리의 데이터 및 로그 파일을 가리키는 파일 경로를 지정합니다.
  3. 복사 및 연결 (다른 호스트): 대상 데이터베이스 인스턴스를 중지합니다. .mdf 및 .ldf 파일을 타겟 서버 로컬 스토리지 드라이브로 전송한 다음 SQL Server Management Studio를 사용하여 연결합니다.

Oracle

  1. 파일 찾기: 유틸리티는 RMAN 데이터베이스 백업 및 Archive log 볼륨 그룹을 온라인으로 가져오는 동안 init.ora 또는 spfile 파일과 .dbf 데이터 파일을 자동으로 감지합니다.
  2. 데이터베이스 복구: 타겟 Oracle 인스턴스를 종료하거나 NOMOUNT 모드로 시작합니다. 직접 검증을 위해 마운트된 .dbf 파일을 가리키도록 초기화 매개변수 (예: 제어 파일)를 업데이트하거나 영구 복구를 위해 .dbf 파일을 로컬 스토리지 또는 자동 스토리지 관리 (ASM) 스토리지에 복사합니다.
  3. 데이터베이스 열기: 인스턴스를 MOUNT 상태로 가져오고, 마운트된 TransactionLog 볼륨 그룹에서 필요한 복구 로그를 적용한 다음 데이터베이스를 엽니다.

VMware Engine VM

데이터베이스 애플리케이션 복구 외에도 Google Cloud VMware Engine(VMware Engine) 가상 머신 보호에는 가상 디스크 익스텐트와 함께 전체 하드웨어 구성이 포함됩니다.

  1. 파일 마운트 및 찾기: 백업 이미지 마운트에 설명된 대로 백업 이미지를 마운트합니다. 이 유틸리티는 기본 마운트 경로 내에 스파스 가상 디스크 (vol00.raw)를 생성합니다. 그런 다음 디스크를 연결하여 db_volume/ 디렉터리 아래에 게스트 운영체제 파일 시스템을 노출합니다. VMware 구성 메타데이터 (.ovf, .vmx, Catalog.xml 포함)는 log_files/ 폴더 내에 정리됩니다.
  2. VM을 직접 복원: 매니페스트 파싱을 위해 기본 디스크를 보호하도록 대상 VM을 비활성화합니다. 작업자 프로세스는 로컬 스토리지에서 데이터 블록을 읽고 VMware 가상 디스크 개발 키트 (VDDK) 라이브러리를 사용하여 VMDK에 쓴 다음 VM을 자동으로 다시 시작합니다.

Compute Engine PD 스냅샷

로컬 파일 시스템으로 마운트된 OnVault 백업과 달리 Compute Engine 영구 디스크 스냅샷은 새 영구 디스크를 초기화하고 이를 타겟 Compute Engine 인스턴스에 직접 연결하여 복원됩니다.

  1. 타겟 백업 및 메타데이터 식별: Cloud Storage 버킷에 영구 디스크 스냅샷 메타데이터 카탈로그 파일(pdsnapshot_catalog.json)이 있는지 확인합니다. 영구 디스크 관리자 유틸리티를 사용하여 카탈로그에 나열된 사용 가능한 백업을 검토하고 복구에 사용할 특정 IMAGE ID를 선택합니다.
  2. 볼륨 복원 및 연결: attach 명령어를 사용하여 백업 스냅샷에서 영구 디스크 생성을 자동화합니다. 이 단일 작업은 관련 볼륨을 모두 대상 가상 머신에 생성하고 연결합니다.
  3. 운영체제 수준에서 기기 마운트: 연결이 완료되면 대상 Compute Engine 인스턴스에 연결하여 lsblk와 같은 도구를 사용하여 새로 매핑된 블록 기기를 식별합니다. 파일 시스템을 수동으로 마운트하여 복구된 데이터에 액세스하거나 애플리케이션 복구 프로세스를 시작합니다.

SAP HANA PD

로컬 파일 시스템으로 직접 마운트되는 OnVault 백업과 달리 SAP HANA 영구 디스크 스냅샷을 복원하려면 새 영구 디스크를 프로비저닝하고 이를 타겟 Compute Engine 인스턴스에 연결해야 합니다.

  1. 메타데이터 확인 및 백업 이미지 찾기: Cloud Storage 버킷에서 영구 디스크 스냅샷 메타데이터 카탈로그 파일을 사용할 수 있는지 확인합니다. 영구 디스크 관리자 도구를 사용하여 카탈로그화된 백업을 검사하고 복구에 필요한 IMAGE ID을 선택합니다.
  2. 디스크 프로비저닝 및 볼륨 연결: attach 명령어를 실행하여 선택한 백업 스냅샷에서 영구 디스크 생성을 자동화합니다. 이 단계에서는 필요한 모든 볼륨을 생성하고 단일 작업으로 타겟 가상 머신에 연결합니다.
  3. 운영체제 수준에서 기기 마운트: 디스크가 연결된 후 대상 SAP HANA VM에 연결하고 lsblk와 같은 도구를 사용하여 새로 할당된 블록 기기를 확인합니다. 파일 시스템을 수동으로 마운트하여 복구된 데이터에 액세스하거나 애플리케이션 수준 복원을 시작합니다.
  4. SAP HANA 복구: SAP HANA 데이터, 로그, 보관 로그 볼륨을 마운트한 후 시스템 데이터베이스를 시작하고(필요한 경우 PITR(point-in-time recovery) 포함) 테넌트 데이터베이스를 복구하고 초기화합니다.

IBM Db2 PD

로컬 파일 시스템으로 직접 마운트되는 OnVault 백업과 달리 IBM Db2 영구 디스크 스냅샷을 복원하려면 새 영구 디스크를 프로비저닝하고 대상 Compute Engine 인스턴스에 연결해야 합니다.

  1. 백업 이미지 찾기 및 메타데이터 검증: 영구 디스크 스냅샷 메타데이터 카탈로그 파일이 지정된 Cloud Storage 버킷에 있는지 확인합니다. 영구 디스크 관리자 도구를 사용하여 카탈로그화된 백업을 검사하여 복구에 필요한 타겟 IMAGE ID를 식별하고 선택합니다.
  2. 볼륨 연결 및 디스크 프로비저닝: attach 명령어를 실행하여 지정된 백업 스냅샷에서 영구 디스크를 자동으로 만듭니다. 이 단일 단계에서는 필요한 모든 볼륨을 프로비저닝하고 타겟 가상 머신에 직접 연결합니다.
  3. 운영체제 파일 시스템 마운트: 디스크를 연결한 후 타겟 IBM Db2 VM에 연결하여 lsblk와 같은 도구를 사용하여 새로 매핑된 블록 기기를 식별합니다. 파일 시스템을 수동으로 마운트하여 복원된 데이터에 액세스하거나 애플리케이션 복구를 진행합니다.
  4. 애플리케이션 데이터베이스 복구: Db2 데이터, 트랜잭션 로그, 보관 로그 볼륨을 마운트한 후 각 Db2 데이터베이스 인스턴스를 카탈로그화하고 필요에 따라 데이터베이스 복구를 실행하고 데이터베이스를 온라인 상태로 전환합니다.

MySQL/MariaDB

  1. 파일 찾기: 사용자 데이터베이스, 시스템 스키마, InnoDB 테이블스페이스가 포함된 db_volume/에서 기본 데이터 디렉터리를 찾습니다.

  2. 데이터베이스 복원: 활성 MySQL 또는 MariaDB 서비스를 중지합니다. 직접 테스트하려면 my.cnf에서 datadir 항목을 조정하여 복구 마운트 폴더를 타겟팅합니다. 영구 복원의 경우 데이터베이스 파일을 로컬 저장소 (예: /var/lib/mysql/)에 복사하고 파일 시스템 소유권과 권한이 올바른지 확인합니다.

  3. 온라인 상태로 전환 및 복구: 데이터베이스 서비스를 다시 시작합니다. 바이너리 트랜잭션 로그가 있는 경우 mysqlbinlog 유틸리티를 사용하여 PITR(point-in-time recovery)을 실행합니다.

PostgreSQL

  1. 파일 찾기: db_volume/ 디렉터리에서 핵심 데이터베이스 (base/, global/, pg_wal/) 및 postgresql.conf 구성 파일을 비롯한 PGDATA 애셋을 식별합니다.

  2. 데이터베이스 복원: 대상 PostgreSQL 인스턴스를 종료합니다. 마운트에서 직접 검증하려면 data_directory 또는 PGDATA 환경 변수를 복구 경로로 지정합니다. 영구적으로 복원하려면 전체 디렉터리 구조를 대상 호스트 로컬 스토리지로 전송합니다.

  3. 데이터베이스 열기: 서비스를 다시 시작하여 인스턴스를 온라인 상태로 전환합니다. PITR(point-in-time recovery)이 필요한 경우 recovery.conf 파일을 정의하거나 postgresql.conf 내에서 restore_command를 구성하여(PostgreSQL 12 이상) log_files/ 폴더의 보관된 WAL 로그를 적용한 다음 데이터베이스를 온라인 상태로 전환합니다.

SAP ASE

  1. 파일 찾기: 마운트된 db_volume/ 폴더 내에 있는 특정 사용자 데이터베이스 및 로그 기기와 함께 기본 마스터 기기를 식별합니다.

  2. 데이터베이스 복원: 대상 SAP ASE 인스턴스를 종료합니다. 직접 마운트의 경우 RUN_server 구성을 업데이트하여 마스터 기기 파라미터 (예: -d)를 복구 경로로 리디렉션합니다. 또는 모든 기기 애셋을 영구 저장소 위치로 전송합니다.

  3. 데이터베이스 열기: SAP ASE dataserver 프로세스를 시작합니다. 트랜잭션 로그가 있는 경우 데이터베이스를 온라인 상태로 전환하기 전에 LOAD TRAN 작업을 실행하여 PITR(point-in-time recovery)을 실행합니다.

SAP MaxDB

  1. 볼륨 찾기: db_volume/ 마운트 경로로 이동하여 기본 SAP MaxDB 데이터 및 로그 파일을 찾습니다.

  2. 구성 복원 또는 리디렉션: 대상 SAP MaxDB 프로세스를 중지합니다. 데이터베이스 관리자 (dbmcli)를 사용하여 DataVolumeName과 같은 매개변수를 업데이트하여 복구 마운트를 가리키거나 파일을 로컬 저장소에 직접 복사하여 전체 복원을 실행합니다.

  3. 시작 및 온라인 상태로 전환: 데이터베이스 인스턴스를 시작하고 데이터베이스 관리자를 사용하여 작동 상태를 ONLINE로 설정합니다.

SAP IQ

  1. 파일 찾기: db_volume/ 디렉터리로 이동하여 기본 SAP IQ 메인 스토어, 카탈로그 스토어 (.db), 연결된 모든 임시 스토어 애셋을 식별합니다.

  2. 데이터베이스 복원: 대상 SAP IQ 인스턴스를 종료합니다. 복구 마운트에서 직접 검증을 실행하려면 마운트된 카탈로그 파일을 참조하도록 시작 매개변수를 수정하세요. 영구 복원의 경우 적절한 파일 시스템 소유권 및 권한이 유지되는지 확인하면서 모든 저장소 볼륨을 로컬 스토리지로 전송합니다.

  3. 데이터베이스 열기: start_iq 유틸리티를 실행하여 인스턴스를 온라인 상태로 만들고 데이터 무결성을 확인합니다.

IBM Db2 LVM/덤프

  1. 파일 찾기: db_volume/ 및 log_files/ 마운트 경로로 이동합니다. 보호 방법에 따라 덤프 기반 복구를 위해 LVM 데이터 및 로그 볼륨 또는 특정 백업 이미지 애셋을 식별합니다.
  2. 데이터베이스 복구 (LVM): 대상 Db2 인스턴스를 종료합니다. 복구 마운트에서 대상 로컬 스토리지로 데이터베이스 데이터와 활성 트랜잭션 로그 볼륨을 전송하여 Db2 사용자 및 그룹의 올바른 파일 시스템 소유권을 보장합니다.
  3. 데이터베이스 복원 (덤프 기반 전체 및 증분): 활성 연결을 중지하고 대상 데이터베이스가 있는 경우 삭제합니다. 특정 백업 타임스탬프와 함께 db2ckrst 도구를 사용하여 필요한 증분 시퀀스를 분류합니다. 규정된 순서대로 각 이미지에 대해 RESTORE 작업을 실행합니다.
  4. 데이터베이스 열기: Db2 인스턴스를 시작합니다. 데이터베이스가 대기 상태로 유지되거나 PITR(point-in-time recovery)이 필요한 경우 db2 rollforward 유틸리티를 사용하여 트랜잭션 로그를 적용하여 복구를 완료하고 인스턴스를 온라인 상태로 전환합니다.

리소스 삭제

데이터베이스 엔진에서 필요한 모든 데이터베이스 파일을 복사하거나 분리한 후에는 잔여 잠금이나 고아 참조를 방지하기 위해 활성 볼륨을 안전하게 마운트 해제하고 연결된 루프 기기를 분리하고 로컬 스테이징 디렉터리를 삭제합니다.

볼륨을 마운트 해제하고 복구 디렉터리를 정리하려면 다음 명령어를 실행합니다.

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

다음을 바꿉니다.

  • MOUNT_POINT: 백업이 마운트된 로컬 디렉터리 경로입니다(예: /tmp/recovery_folder).

다음 단계