[HANA] 2039883 - FAQ: SAP HANA database and storage snapshots

Storage snapshot의 장단점

• 장점 
  • 기본적으로 network, 전체적인 I/O 성능 및 HANA DB 자체의 영향을 거의 주지 않으며 대량의 데이터의 빠른 백업을 제공
  • 반대로 빠른 DB 복구 (RTO)를 제공
  • Storage 업체에 따라 다름 (중복제거기술 등 감소된 disk space를 제공)
• 단점
  • Database의 내부적인 integrity check가 불가 (checksum calculation)
    • Storage snapshot은 손상된 데이터 page를 포함할 수 있음
  • 각 서비스의 특정 data volume뿐만 아니라 전체 DB의 전체 데이터를 고려함
  •  스토리지 시스템에서만 사용할 수 있고 다른 위치 또는 Media에 복제되지 않은 Storage snapshot은 재해 발생 시 Storage system 자체의 백업으로 사용할 수 없음

 

 

사용 방법

• 3단계로 수행 됨
  • STEP1 : PREPARE
    • HANA DB에서 PREPARE를 request 
    • BACKUP DATA CREATE SNAPSHOT
    • 여러 storage volume group간의 I/O consistency를 보장하기 위해서 HANA DB는 system wide savepoint에 기반한 internal snapshot을 생성함 
      • 각 database service의 data volume에 저장됨
      • 이후 recovery에 사용될 해당 data의 snapshot으로 freeze됨
      • 따라서 추가적인 storage system level에서의 action이 필요하지 않음
    • snapshot of a SAP HANA data volume must be an atomic operation
    • Internal snapshot은 각각의 데이터 볼륨을 가지고 있는 모든 SAP HANA database service에 걸쳐서 생성됨
      • 영향받는 HANA Host들의 갯수에 독립적임
  • STEP2
    • 모든 DB service의 전체 DB에 대한 Storage snapshot을 storage system의 기능으로 생성 함
  • STEP3: CONFIRM, ABANDON
    • Storage snapshot 성공/실패여부를 DB에 알림
    • BACKUP DATA CLOSE SNAPSHOT BACKUP_ID <backup_id> SUCCESSFUL <external_id>
      BACKUP DATA CLOSE SNAPSHOT BACKUP_ID <backup_id> UNSUCCESSFUL <external_id>
      • DB service가 storage snapshot 생성 도중에 restart된 경우에 명령이 실패할 수 있음
  • Storage 벤더에서 HANA storage snapshot 기능을 포함한 plugins을 제공 (벤더에 확인 필요)
• 기타 내용
  
  • 백업 대상
    • 모든 HANA database seervice의 데이터 볼륨을 고려해야 함
    • Log area는 Point-in-time option을 포함한 DB 복구를 수행하기 위해서 storage snapshot에 포함되지 말아야 함
      • Log backups과 아직 백업되지 않은 log segments는 snapshot  restore 후에 복구될 수 있음
    • 데이터볼륨에 추가해서 HANA database metadata 정보가 필요
      
      • name server 데이터 볼륨이 저장된 곳과 동일한 directory에 OS파일로 위치
  • 백업 가능 상태
    • HANA DB 상태는 ONLINE 상태여야 함 (PREPARE, CONFIRM 명령을 수행할 수 있는 상황)
  • HANA backup catalog에 storage snapshot 저장됨
    • snapshot 생성이 fail된 경우에도 저장됨
    • 단계는 PREPARE, CONFIRM or ABANDON
  • HANA DB의 복구를 위한 사용방법
    • 복구하는 경우에 데이터 영역에 storage snapshot이 존재해야 함
    • Storage system 에서 snapshot을 자동으로 복원할 수 없음 --> manual로 복구 해야 함
    • 적합한 storage snapshot은 storage sytem admin console 또는 HANA studio의 recovery wizard에서 표시되는 HANA backup catalog를 통해서 확인 가능
    • 데이터 area의 storage snapshot의 가용성은 HANA backup catalog overview에서 확인 가능
      • snapshot이 가용하면 Green 표시
      • Refresh 버튼을 통해서 상태 변경 가능 
    • Restore된 storage snapshot과 연계된 log backup으로 point-in-time recovery 가능
      • 한편으로 HANA DB는 storage snapshot만을 사용하여 복구 가능 --> 이경우 로그 영역이 암시적으로 초기화되고 redo log가 적용되지 않음
      • 반면 특정 시점 복구는 로그 백업을 사용하여 수행할 수 있으며 아직 백업되지 않은 로그 세그먼트를 사용하여 임의의 특정 시점에 도달할 수 있음
    • HANA backup catalog에 저장되지 않은 storage snapshot의 사용은 가능
      • Backup catalog가 예외적인 상황으로 re-create 되면 storage snapshot은 catalog에 더이상 저장되지 않음
      • 그런 경우에도 유효한 storage snapshot을 복구할 수 있음
      • storage system admin console을 이용해 적합한 snapshot을 확인해야 함
      • snapshot의 수동 restore 후에 recovery 마법사에서 유용한 snapshot을 보여줌
    • DB recovery 도중에 DB의 internal snapshot은 drop 됨
      • DB recovery가 실패하고 재수행되어야 한다면 storage snapshot은 다시 한번 Restore 되어야 함
    • HANA replication을 위해 snapshot과 internal snapshot간의 interface가 있는가?
      •