NetApp Snapshot 기술을 사용하면 몇 분 안에 데이터베이스 백업을 만들 수 있습니다. 스냅샷 복사본을 만드는 데 필요한 시간은 스냅샷 복사본이 스토리지 플랫폼에서 물리적 데이터 블록을 이동하지 않기 때문에 데이터베이스 크기와 무관합니다. 또한, 스냅샷 기술을 사용해도 모든 작업이 스토리지 시스템에서 실행되므로 라이브 SAP 시스템의 성능에 영향을 미치지 않습니다. 따라서 대화가 가장 많은 기간이나 일괄 작업 기간을 고려하지 않고도 스냅샷 복사본 생성을 예약할 수 있습니다. NetApp 고객의 SAP는 일반적으로 하루 중 여러 번의 온라인 스냅샷 백업을 예약합니다. 예를 들어, 6시간마다 백업하는 것이 일반적입니다. 이러한 스냅샷 백업은 일반적으로 장기 보존을 위해 제거되거나 더 저렴한 스토리지로 계층화되기 전에 기본 스토리지 시스템에 3~5일 동안 보관됩니다.

스냅샷 복사본은 복원 및 복구 작업에도 주요 이점을 제공합니다. 복원 작업은 백업 상태에 따라 파일 시스템의 데이터를 다시 가져옵니다. 복구 작업은 데이터베이스 로그 백업을 사용하여 데이터베이스 상태를 특정 시점으로 롤포워드하는 데 사용됩니다.

NetApp SnapRestore 기술을 사용하면 현재 사용 가능한 스냅샷 백업을 기반으로 전체 데이터베이스 또는 데이터베이스의 일부만 복원할 수 있습니다. 복원 과정은 데이터베이스 크기에 관계없이 몇 초 안에 완료됩니다. 하루 동안 여러 개의 온라인 스냅샷 백업을 만들 수 있으므로, 하루에 한 번 백업하는 기존 방식에 비해 복구 프로세스에 필요한 시간이 크게 줄어듭니다. 최대 24시간이 아닌 몇 시간 전의 스냅샷 복사본으로 복원을 수행할 수 있으므로 전방 복구 중에 적용해야 하는 트랜잭션 로그가 줄어듭니다. 기존 스트리밍 백업에 비해 복원 및 복구에 필요한 시간이 크게 단축됩니다.

스냅샷 백업은 활성 온라인 데이터와 동일한 디스크 시스템에 저장되므로 NetApp 스냅샷 복사 백업을 보조 위치에 대한 백업을 대체하는 것이 아니라 보완하는 용도로 사용할 것을 권장합니다. 대부분의 복원 및 복구 작업은 기본 스토리지 시스템의 SnapRestore 사용하여 관리됩니다. 보조 위치에서 복원하는 작업은 스냅샷 복사본이 들어 있는 기본 스토리지 시스템을 사용할 수 없는 경우에만 필요합니다. 기본 저장소에서 더 이상 사용할 수 없는 백업을 복원해야 하는 경우에도 보조 백업을 사용할 수 있습니다.

보조 위치에 대한 백업은 기본 저장소에 생성된 스냅샷 복사본을 기반으로 합니다. 따라서 SAP 데이터베이스 서버와 네트워크에 부하를 발생시키지 않고 기본 스토리지 시스템에서 직접 데이터를 읽을 수 있습니다. 기본 저장소는 보조 저장소와 직접 통신하고 SnapVault 또는 ANF 백업 기능을 사용하여 백업 데이터를 대상에 복제합니다.

SnapVault 와 ANF 백업은 기존 백업에 비해 상당한 이점을 제공합니다. 모든 데이터가 소스에서 목적지로 전송되는 초기 데이터 전송 후, 이후의 모든 백업은 변경된 블록만 보조 저장소로 복제합니다. 따라서 기본 스토리지 시스템의 부하와 전체 백업에 필요한 시간이 크게 줄어듭니다. 변경된 블록만 대상에 저장되므로, 추가적인 전체 데이터베이스 백업은 디스크 공간을 상당히 적게 차지합니다.

다음 그림은 스냅샷 백업 작업을 사용하는 고객의 HANA Studio를 보여줍니다. 이 이미지는 스냅샷 백업 기술을 사용하면 HANA 데이터베이스(약 4TB 크기)가 1분 20초 만에 백업되고, 파일 기반 백업 작업으로는 4시간 이상 걸리는 것을 보여줍니다.

전체 백업 워크플로 런타임에서 가장 큰 부분은 HANA 데이터베이스 스냅샷 작업을 실행하는 데 필요한 시간입니다. 스토리지 스냅샷 백업 자체는 HANA 데이터베이스 크기에 관계없이 몇 초 안에 완료됩니다.

이 섹션에서는 파일 기반 및 스토리지 기반 스냅샷 백업의 복구 시간 목표(RTO)를 비교합니다. RTO는 데이터베이스를 복원하고 복구한 다음 시작하는 데 필요한 시간의 합계로 정의됩니다.

백업 실행은 모든 데이터 보호 전략에서 중요한 부분입니다. 시스템 장애로부터 복구할 수 있도록 정기적으로 백업이 예약됩니다. 이것이 가장 확실한 사용 사례이지만 백업 및 복구 작업의 속도가 더욱 빠른 것이 중요한 다른 SAP 라이프사이클 관리 작업도 있습니다.

SAP HANA 시스템 업그레이드는 업그레이드 전에 온디맨드 백업을 수행하고 업그레이드가 실패할 경우 복원 작업을 수행하는 것이 전체 계획된 가동 중지 시간에 상당한 영향을 미치는 사례입니다. 4TB 데이터베이스의 예를 들어보면, 스냅샷 기반 백업 및 복원 작업을 사용하면 계획된 가동 중지 시간을 8시간 줄일 수 있고, 오류를 분석하고 수정하는 데 8시간을 더 사용할 수 있습니다.

또 다른 사용 사례는 일반적인 테스트 주기로, 다양한 데이터 세트나 매개변수를 사용하여 여러 번의 반복을 거쳐 테스트를 수행해야 하는 경우입니다. 빠른 백업 및 복원 작업을 활용하면 테스트 주기 내에서 저장 지점을 쉽게 만들고 테스트가 실패하거나 반복이 필요한 경우 시스템을 이전 저장 지점으로 재설정할 수 있습니다. 이를 통해 테스트를 더 일찍 완료하거나 동시에 더 많은 테스트를 실시하고 테스트 결과를 개선할 수 있습니다.

스냅샷 백업이 구현되면 HANA 데이터베이스 복사본이 필요한 여러 다른 사용 사례를 처리하는 데 사용할 수 있습니다. 사용 가능한 스냅샷 백업의 내용을 기반으로 새 볼륨을 만들 수 있습니다. 이 작업의 실행 시간은 볼륨 크기에 관계없이 몇 초입니다.

가장 인기 있는 사용 사례는 SAP 시스템 새로 고침으로, 프로덕션 시스템의 데이터를 테스트 또는 QA 시스템으로 복사해야 하는 경우입니다. ONTAP 또는 ANF 클로닝 기능을 활용하면 몇 초 만에 프로덕션 시스템의 스냅샷 복사본에서 테스트 시스템의 볼륨을 프로비저닝할 수 있습니다. 그런 다음 새 볼륨을 테스트 시스템에 연결하고 HANA 데이터베이스를 복구해야 합니다.

두 번째 사용 사례는 프로덕션 시스템의 논리적 손상을 해결하는 데 사용되는 복구 시스템을 만드는 것입니다. 이 경우, 운영 시스템의 이전 스냅샷 백업을 사용하여 복구 시스템을 시작합니다. 복구 시스템은 손상이 발생하기 전의 데이터가 있는 운영 시스템의 동일한 복제본입니다. 그런 다음 수리 시스템을 사용하여 문제를 분석하고 손상되기 전에 필요한 데이터를 내보냅니다.

마지막 사용 사례는 복제를 중단하지 않고 재해 복구 장애 조치 테스트를 실행하여 재해 복구 설정의 RTO 및 복구 지점 목표(RPO)에 영향을 미치지 않는 기능입니다. ONTAP SnapMirror 복제 또는 ANF 지역 간 복제를 사용하여 데이터를 재해 복구 사이트로 복제하는 경우, 운영 스냅샷 백업도 재해 복구 사이트에서 사용할 수 있으며, 이를 사용하여 재해 복구 테스트를 위한 새 볼륨을 만들 수 있습니다.