자주 묻는 질문 – Azure VM의 SAP HANA 데이터베이스 백업

이 문서에서는 Azure Backup 서비스를 사용하여 SAP HANA 데이터베이스를 백업하는 방법에 대한 일반적인 질문과 답변을 제공합니다.

Backup

하루에 지원되는 백업은 몇 건인가요?

하루에 하나의 예약 전체 백업과 여러 주문형 백업을 가질 수 있습니다.

Backup 유형 예약된 백업 주문형 백업
전체 하루에 한 번만 지원됩니다. 하루에 여러 번 지원됩니다.
델타(차등/증분) 하루에 한 번만 지원됩니다.

참고
델타 백업은 특정 날짜에 전체 백업이 예약되지 않은 경우에만 예약할 수 있습니다. 또한 백업 정책에는 하나의 델타 백업 유형(차등/증분)만 예약할 수 있습니다.
하루에 여러 번 지원됩니다.

백업 관련 경고는 어디에서 찾을 수 있나요?

현재 성공한 백업 작업에서는 경고가 생성되지 않습니다. 경고는 실패한 백업 작업에 대해서만 생성됩니다. Azure Portal을 사용하여 Backup 경고를 보는 방법을 알아봅니다.

내 백업(예약/주문형)이 성공적으로 실행되었는지 어떻게 확인하나요?

다음 위치에서 백업 상태(예약/주문형)를 확인할 수 있습니다.

  1. 백업 작업: Azure Backup은 Azure Portal의 백업 작업 섹션에 수동으로 트리거된 모든 작업을 표시합니다.

    Azure Portal에 표시되는 작업에는 데이터베이스 검색 및 등록 작업, 백업 및 복원 작업이 포함됩니다. 로그 백업을 포함한 예약된 작업은 이 섹션에 표시되지 않습니다. SAP HANA 네이티브 클라이언트(Studio/Cockpit/DBA Cockpit)에서 수동으로 트리거된 백업도 여기에 표시되지 않습니다.

    Azure Portal의 백업 작업 섹션에서 수동으로 트리거된 작업을 보여 주는 스크린샷

    데이터베이스 검색 및 등록, 백업 및 복원 작업을 포함한 작업을 보여 주는 스크린샷

  2. 백업 경고: 경고는 SAP HANA 데이터베이스의 백업을 모니터링하는 데 도움이 됩니다. 이를 통해 필요한 이벤트에 집중할 수 있으므로 백업에서 생성하는 많은 이벤트를 자주 확인할 필요가 없습니다. 자세한 내용은 백업 경고 보기를 참조하세요.

  3. Backup 보고서: 보고서는 백업 작업의 상태를 보는 또 다른 방법입니다. 보고서는 다음과 같습니다.

    Azure Portal의 보고서 유형을 보여 주는 스크린샷

    Azure Portal의 다른 유형의 보고서를 보여 주는 스크린샷

    Azure Backup 보고서를 구성하는 방법에 대해 알아봅니다.

  4. SAP HANA 네이티브 클라이언트: SAP HANA 고객인 경우 가장 일반적인 HANA 클라이언트 중 하나인 HANA Studio를 사용할 수도 있습니다. 이 클라이언트에서 백업 콘솔 ->백업 카탈로그로 이동하여 백업 상태를 확인합니다.

    SAP HANA 네이티브 클라이언트의 보고서를 보여 주는 스크린샷

백업 작업 메뉴에서 예약된 백업 작업을 볼 수 있나요?

백업 작업 메뉴는 진행 중이거나 성공했거나 실패한 주문형 백업 작업만 표시합니다. 예약된 작업을 보려면 Azure Monitor를 사용하세요.

LSNValidation 오류로 인해 트리거된 자동 복구 전체 백업의 보존 기간은 어떻게 되나요?

Azure Backup은 자동 복구 전체 백업에 대한 명시적 보존 기간을 설정하지 않습니다. 이 백업은 종속 델타(차등 또는 증분) 및 로그 백업을 유지할 때까지 유지됩니다. 이 자동 복구 백업에서 마지막 종속 백업을 삭제하면 자동 복구 백업도 삭제됩니다.

전체 백업 및 로그 백업을 동시에 실행할 수 있나요?

예. 전체 백업 및 로그 백업을 동시에 실행할 수 있습니다. 이 인스턴스는 다음 방법 중 하나에서 발생합니다.

  • 전체 백업이 진행 중이고 로그 백업이 트리거됨: 진행되는 전체 백업과는 무관하게 로그 백업이 성공해야 합니다. 트리거된 전체 백업이 LSN 체인 중단을 처리하기 위한 전체 수정이 아닌 한.
  • 로그 백업이 진행 중이며 전체 백업이 트리거됨: 두 백업이 동시에 처리되어 성공해야 합니다.

이후 데이터베이스가 백업을 위해 자동으로 추가되나요?

아니요. 현재는 지원되지 않습니다.

인스턴스에서 데이터베이스를 삭제하면 백업은 어떻게 되나요?

SAP HANA 인스턴스에서 데이터베이스를 삭제해도 해당 데이터베이스의 백업이 계속 시도됩니다. 즉, 삭제된 데이터베이스가 백업 항목에서 비정상 상태로 표시되기 시작하지만 여전히 보호되는 것으로 처리됩니다. 이 데이터베이스의 보호를 중지하는 올바른 방법은 이 데이터베이스에 대해 데이터 삭제 시 백업 중지를 수행하는 것입니다.

보호된 데이터베이스의 이름을 변경하면 어떻게 되나요?

이름이 변경된 데이터베이스는 새 데이터베이스로 처리됩니다. 따라서 서비스는 이 상황을 해당 데이터베이스가 발견되지 않은 것처럼 처리하고 백업을 실패 처리합니다. 이름이 변경된 데이터베이스는 새 데이터베이스로 표시되며 보호받도록 구성되어야 합니다.

Azure Backup을 사용하여 SAP HANA 데이터베이스 백업을 시작하려면 어떻게 해야 하나요?

Azure Backup for SAP HANA 데이터베이스를 시작하는 단계별 가이드는 자습서를 참조하세요. CLI를 사용하여 백업을 구성하고 관리할 수도 있습니다.

Azure Backup을 사용하여 SAP HANA 데이터베이스를 백업하기 위한 필수 조건이 있나요?

Azure Backup을 SAP HANA와 함께 사용하기 위한 필수 조건을 참조하세요.

SAP HANA를 SDC에서 MDC로 마이그레이션한 후에도 백업이 작동하나요?

문제 해결 가이드의 이 섹션을 참조하세요.

동일한 HANA 버전 내에서 HANA 인스턴스를 업그레이드한 후 백업이 계속되도록 하려면 어떻게 해야 하나요?

문제 해결 가이드의 이 섹션 을 참조하세요.

가상 머신이 아닌 가상 IP(부하 분산 장치)에 대해 Azure HANA의 백업을 설정할 수 있나요?

현재 가상 IP 또는 프록시에 솔루션을 설정하는 기능은 지원되지 않습니다. 솔루션을 실행하려면 가상 머신이 필요합니다.

주문형 백업(HANA 기본 클라이언트에서 트리거됨)을 Azure 자격 증명 모음 대신 로컬 파일 시스템으로 이동하려면 어떻게 해야 하나요?

SAP HANA 네이티브 클라이언트를 사용하여 Backint 대신 로컬 파일 시스템에 대한 주문형 백업을 트리거할 수 있습니다. SAP 네이티브 클라이언트를 사용하여 작업을 관리하는 방법에 대해 자세히 알아봅니다.

Azure Backup이 사용하도록 설정된 데이터베이스용 HANA 카탈로그를 어떻게 관리하거나 정리할 수 있나요?

BACKUP CATALOG DELETE 문 또는 HANA Studio/Cockpit과 같은 SAP 권장 방법을 사용하여 HANA 카탈로그를 정리할 수 있습니다. SAP 네이티브 클라이언트를 사용하여 작업을 관리하는 방법에 대해 자세히 알아봅니다.

내 HANA 복제 설정으로 SAP HANA 백업을 사용하려면 어떻게 하나요?

현재 Azure Backup에는 HSR 설정을 이해하는 기능이 없습니다. HSR의 기본 노드와 보조 노드는 서로 관련이 없는 두 개의 VM으로 취급됩니다. 먼저 주 노드에서 백업을 구성해야 합니다. 장애 조치(failover)가 발생하면 보조 노드(이제 주 노드가 되는)에 백업을 구성해야 합니다. 백업이 다른 노드로 자동으로 ‘장애 조치(failover)’ 처리되지 않습니다.

지정된 특정 시점에 활성(주) 노드에서 데이터를 백업하려면 장애 조치(failover) 후 주 노드가 된 보조 노드로 보호를 전환할 수 있습니다.

보호 전환을 수행하려면 다음 단계를 따르세요.

이러한 단계는 장애 조치(failover) 후에 수동으로 수행해야 합니다. Azure Portal에 추가로 명령줄/HTTP REST를 통해 이러한 단계를 수행할 수 있습니다. 이러한 단계를 자동화하려면 Azure Runbook을 사용할 수 있습니다.

스위치 보호를 수행해야 하는 방법에 대한 자세한 예는 다음과 같습니다.

이 예에서는 HSR 설정에 노드 1(주) 및 노드 2(보조) 노드가 두 개 있습니다. 백업은 노드 1에 구성됩니다. 위에서 설명한 것처럼 노드 2에서 백업 구성을 아직 시도하지 마세요.

첫 번째 장애 조치(failover)가 발생하면 노드 2가 주 서버가 됩니다. 그런 다음

  1. 데이터 보존 옵션을 통해 노드 1(이전 주 노드)의 보호를 중지합니다.
  2. 노드 2(현재 주 노드)에서 사전 등록 스크립트를 실행합니다.
  3. 노드 2에서 데이터베이스를 검색하고, 백업 정책을 할당하고, 백업을 구성합니다.

그런 다음 노드 2에서 첫 번째 전체 백업이 트리거되고 완료된 후 로그 백업이 시작됩니다.

다음 장애 조치(fail over)가 발생하면 노드 1은 다시 주 노드가 되고 노드 2는 보조가 됩니다. 이제 프로세스를 반복합니다.

  1. 데이터 보존 옵션을 통해 노드 2의 보호를 중지합니다.
  2. 노드 1에서 등록 전 스크립트를 실행합니다(다시 주 노드가 되었음).
  3. 그런 다음 필요한 정책을 통해 노드 1에서 백업을 다시 시작합니다(이전에 노드 1에서 백업이 중지되었음).

그런 다음 전체 백업이 노드 1에서 다시 트리거되고 완료된 후 로그 백업이 시작됩니다.

참고 항목

사용자 지정 백업 사용자를 입력으로 사용하여 사전 등록 스크립트를 실행하면 HSR 백업을 더 잘 관리하는 데 도움이 될 수 있습니다. 이는 HSR 설정의 두 노드가 모두 동일한 백업 키를 사용하도록 하여 백업 동기화 및 실패 문제를 줄이기 때문입니다.

HSR 설정의 보조/비활성 노드에서 보호를 중지하지 않으면(데이터 유지 포함) 어떻게 되나요?

  1. HANA 시스템 복제(HSR)의 경우 보조 노드는 연결을 전혀 허용하지 않습니다. 백업이 구성되면 Azure Backup 서비스가 주기적으로 ping을 실행하고 실패합니다. 때때로 이러한 실패한 시도는 기본 노드에 반영됩니다. 여러 번 실패하면 사용자가 잠기고 기본 노드가 ODBCConnectionError와 함께 실패하기 시작합니다.

    Microsoft는 모든 사용자가 이 문제를 경험하지 않는다는 것을 관찰했습니다. 보조 노드에서 사용자 연결이 실패할 때 사용자가 기본 노드에서 잠기는 원인을 조사하는 것이 좋습니다.

  2. 사전 등록 스크립트를 실행하면 기본 노드에서 사용자 정보가 새 암호로 업데이트됩니다. 그러면 백업을 시도하기 위한 연결이 다시 설정됩니다. 그러나 동일한 시나리오를 다시 경험할 수 있습니다.

  3. 또한 보조 노드에서 실패한 백업(전체 백업)은 경고를 만듭니다.

위의 문제를 방지하려면 노드가 보조 노드가 된 후(연결이 시도되지 않고 사용자가 잠기지 않도록) 노드에 대한 보호를 중지하고 기본 노드가 되면 보호를 다시 시작하는 것이 좋습니다. HSR 설정에서 이러한 잠금 상황에 직면하지 않고 경고가 발생하는 것이 편하다면 서비스가 인계 및 장애 복구를 처리하도록 두 노드 모두에서 백업을 구성할 수 있습니다.

Azure Backup이 제공하는 백업 및 복원 처리량 성능은 무엇이며 이 최대 처리량을 사용하도록 HANA 시스템을 설정하는 방법은 무엇인가요?

Azure Backup이 HANA 워크로드에 제공하는 백업 및 복원 처리량 성능을 참조하세요.

개선된 성능을 활용하도록 HANA 시스템을 설정하려면 다음 리소스를 사용합니다.

참고 항목

백업 처리량 성능을 제한할 수도 있습니다. 자세히 알아보기.

SAP HANA “global.ini” 파일에서 “parallel_backup_using_backint” 속성을 편집하여 백업 성능을 변경할 수 있나요?

현재 SAP HANA용 Azure Backup은 parallel_backup_using_backint 속성 값으로 1을 허용합니다. 그러나 Azure Backup은 성능 향상을 위해 해당 단일 스트림을 여러 스트림으로 분할합니다.

HSR은 스냅샷을 사용하는 데이터베이스 인스턴스 백업을 지원하나요?

현재는 HSR에 대해 Backint 기반 백업만 지원됩니다. 스냅샷은 아직 지원되지 않습니다.

“준비됨”으로 표시된 서버 또는 “준비되지 않음”으로 표시된 서버에서만 인스턴스 재검색을 실행해야 하나요?

“준비되지 않음”으로 표시된 서버에서 인스턴스 재검색을 실행하여 상태를 업데이트해야 합니다.

복원

하루에 지원되는 복원은 몇 개입니까?

하루에 HANA 시스템 또는 인스턴스당 최대 10건의 복원을 수행할 수 있습니다. 복원이 취소되거나 실패하면 복원 시도로 간주됩니다.

내 데이터베이스를 복원하려는 HANA 시스템이 표시되지 않는 이유는 무엇인가요?

대상 SAP HANA 인스턴스로 복원하기 위한 모든 전제 조건이 충족되었는지 확인하세요. 자세한 내용은 전제 조건 - Azure VM에서 SAP HANA 데이터베이스 복원을 참조하세요.

데이터베이스에 대한 덮어쓰기 DB 복원이 실패하는 이유는 무엇인가요?

복원하는 동안 무조건 덮어쓰기 옵션이 선택되어 있는지 확인하세요.

“복원의 원본 및 대상 시스템이 호환되지 않습니다” 오류가 표시되는 이유는 무엇인가요?

현재 지원되는 복원 유형은 SAP HANA Note 1642148을 참조하세요.

SLES에서 실행되는 데이터베이스의 백업을 사용하여 RHEL HANA 시스템으로 복원하거나 그 반대로 복원할 수 있나요?

예, SLES에서 실행되는 HANA 데이터베이스에서 트리거된 스트리밍 백업을 사용하여 RHEL HANA 시스템으로 복원할 수 있으며 그 반대의 경우도 마찬가지입니다. 즉, 스트리밍 백업을 사용하여 OS 간 복원이 가능합니다. 그러나 복원하려는 HANA 시스템 및 복원에 사용되는 HANA 시스템이 SAP에 따른 복원에 모두 호환되는지 확인해야 합니다. 호환되는 복원 유형을 확인하려면 SAP HANA Note 1642148(SAP HANA 메모 1642148)을 참조하세요.

파일로 복원하는 동안 파일의 하위 집합만 다운로드할 수 있나요?

예, 여기서 설명한 대로 파일을 부분적으로 다운로드할 수 있습니다.

HSR 설정에 대해 “SYSTEMDB + 테넌트 DB” 복원 중에 SAP HANA 네이티브 환경에서 HSR을 사용하지 않도록 설정해야 하나요?

예. 대상 시스템에서 HSR(HANA 시스템 복제)을 사용하지 않도록 설정한 다음, 복원을 수행해야 합니다. SAP에 따라 HSR 지원 시스템을 복원할 수 없습니다.

정책

SAP HANA 백업에 대한 새 정책을 만드는 동안 사용할 수 있는 다양한 옵션

정책을 만들기 전에 RPO 및 RTO의 요구 사항과 관련 비용 영향을 명확히 해야 합니다.

RPO(복구-지점-목표)는 사용자/고객에 게 허용되는 데이터 손실 정도를 나타냅니다. 로그 백업 빈도에 따라 결정됩니다. 로그 백업이 잦을수록 RPO가 낮고 Azure Backup 서비스에서 지원하는 최소값은 15분입니다. 따라서 로그 백업 빈도는 15분 이상일 수 있습니다.

RTO(복구-시간-목표)는 데이터 손실 시나리오 후 마지막으로 사용 가능한 시점으로 데이터를 복원하는 속도를 나타냅니다. 이는 일반적으로 복원에 필요한 파일 수에 따라 달라지는, HANA에서 사용하는 복구 전략에 따라 달라집니다. 이 경우 비용에도 영향을 미치며, 다음 표는 모든 시나리오와 해당 의미를 이해하는 데 유용합니다.

백업 정책 RTO 비용
일별 전체 + 로그 특정 시점 복원에 대한 전체 복사본 + 필수 로그가 하나만 필요하기 때문에 가장 빠릅니다 전체 복사본이 매일 수행되므로 보존 시간이 될 때까지 백 엔드에 더 많은 데이터가 누적되므로 Costliest 옵션을 사용합니다
주간 전체 + 일별 차등 + 로그 특정 시점 복원에 대한 하나의 전체 복사 + 하나의 차등 복사 + 로그를 요구하기 때문에 위의 옵션보다 느리지만 다음 옵션보다는 빠릅니다 일별 차등은 일반적으로 전체 보다 작고 전체 복사본은 일주일에 한 번만 사용되므로 비용이 저렴한 옵션입니다
주간 전체 + 일별 증분 + 로그 지정 시간 복구를 위해 하나의 전체 복사본 + 'n' 증분 + 로그가 필요하므로 가장 느립니다 일별 증분은 차등보다 작고 전체 복사본은 주별로만 사용 되기 때문에 가장 저렴한 옵션입니다

참고 항목

위의 옵션들은 가장 일반적으로 쓰이는 옵션이지만 저 외에도 옵션은 있습니다. 예를 들어 매주 전체 백업을 하고 주 + 로그를 두 번 이상 사용할 수 있습니다.

따라서 RPO 및 RTO 목적과 비용 고려 사항에 따라 정책을 변형할 수 있습니다.

정책 수정의 영향

백업 항목의 정책을 정책 1(P1)에서 정책 2(P2)로 전환하거나 정책 1(P1)을 편집하는 경우의 영향을 확인할 때 몇 가지 원칙을 염두에 두어야 합니다.

  • 모든 변경 내용도 소급 적용됩니다. 최신 백업 정책은 이전에 수행된 복구 시점에도 적용됩니다. 예를 들어 현재 활성 정책에 따라 일별 전체 보존이 30일이고 10개의 복구 지점이 생성되었다고 가정합니다. 매일 전체 보존이 10일로 변경되면 이전 시점의 만료 시간도 시작 시간 + 10일로 다시 계산되고 만료된 경우 삭제됩니다.
  • 변경 범위에는 백업 날짜, 백업 유형에 보존 포함됩니다. 예를 들어 매일 전체 보존을 매주 일요일에 전체 보존으로 변경하는 경우 일요일에 작성되지 않은 모든 이전 전체 보존은 삭제 표시됩니다.
  • 자식이 활성/만료되지 않음 상태가 될 때까지 부모는 삭제되지 않습니다. 모든 백업 유형에는 현재 활성 정책에 따라 만료 시간이 있습니다. 그러나 전체 백업 유형은 후속 '차등', '증분' 및 '로그'의 부모로 간주됩니다. '차등' 및 '로그'는 다른 보존의 부모가 되지 않습니다. '증분'은 후속 '증분'의 부모가 될 수 있습니다. '부모'가 삭제로 표시된 경우에도 자식 '차등' 또는 '로그'가 만료되지 않으면 실제로 삭제되지 않습니다. 예를 들어 매일 전체 보존을 매주 일요일에 전체 보존으로 변경하는 경우 일요일에 작성되지 않은 모든 이전 전체 보존은 삭제 표시됩니다. 그러나 이전에 수행된 로그가 만료될 때까지 실제로는 삭제되지 않습니다. 즉, 최신 로그 기간에 따라 유지됩니다. 로그가 만료되면 로그와 이러한 전체 보존이 모두 삭제됩니다.

이러한 원칙을 사용하여 다음 표를 읽으면 정책 변경의 의미를 이해할 수 있습니다.

이전 정책/새 정책 일별 전체 + 로그 매주 전체 + 일별 차등 + 로그 매주 전체 + 매일 증분 + 로그
일별 전체 + 로그 - 같은 요일에 있지 않은 이전 전체는 삭제로 표시되지만 로그 보존 기간까지 유지됩니다 같은 요일에 있지 않은 이전 전체는 삭제로 표시되지만 로그 보존 기간까지 유지됩니다
매주 전체 + 일별 차등 + 로그 이전 주별 전체 보존 기간은 최신 정책에 따라 다시 계산됩니다. 이전 차등은 즉시 삭제됩니다 - 이전 차등은 즉시 삭제됩니다
매주 전체 + 매일 증분 + 로그 이전 주별 전체 보존 기간은 최신 정책에 따라 다시 계산됩니다. 이전 증분은 즉시 삭제됩니다 이전 증분은 즉시 삭제됩니다 -

루트 파티션에 만든 /opt/msawb 폴더의 크기를 관리하려면 어떻게 해야 하나요?

다음 옵션 중 하나를 사용하여 루트 폴더의 공간을 관리할 수 있습니다.

  • /opt/msawb에 대한 고유한 LV를 만듭니다.
  • 동일한/다른 디스크의 다른 위치/폴더에 대한 소프트 link/symlink를 만듭니다.
  • 루트 파티션의 공간을 늘립니다.

다음 단계