논리적 손상은 소프트웨어 오류, 인적 오류 또는 태업 때문에 발생할 수 있습니다. 하지만 논리적 손상은 표준 고가용성 및 재해 복구 솔루션을 통해 해결할 수 없는 경우가 많습니다. 따라서 논리적 손상이 발생한 계층, 애플리케이션, 파일 시스템 또는 스토리지에 따라 다운타임 및 데이터 손실 요구 사항의 최소를 충족하지 못하는 경우가 있습니다.

최악의 경우는 SAP 애플리케이션의 논리적 손상입니다. SAP 애플리케이션은 서로 다른 애플리케이션이 서로 통신하고 데이터를 교환하는 환경에서 작동하는 경우가 많습니다. 따라서 논리적 손상이 발생한 SAP 시스템을 복원 및 복구하는 것은 권장되는 방법이 아닙니다. 손상이 발생하기 전의 시점으로 시스템을 복원하면 데이터가 손실됩니다. 또한 SAP 환경은 더 이상 동기화되지 않으며 추가 후처리 작업이 필요합니다.

SAP 시스템을 복원하는 대신 별도의 복구 시스템에서 문제를 분석하여 시스템 내의 논리적 오류를 해결하는 것이 더 좋습니다. 근본 원인 분석에는 비즈니스 프로세스 및 애플리케이션 소유자의 참여가 필요합니다. 이 시나리오에서는 논리적 손상이 발생하기 전에 저장된 데이터를 기반으로 복구 시스템(운영 시스템의 클론)을 생성합니다. 복구 시스템 내에서 필요한 데이터를 내보낸 후 운영 시스템으로 가져올 수 있습니다. 이 방법을 사용하면 운영 시스템을 중단할 필요가 없으며, 최상의 시나리오에서는 데이터가 없거나 극히 일부의 데이터만 손실됩니다.

수리 시스템을 설정할 때는 유연성과 속도가 매우 중요합니다. 다음 그림과 같이 NetApp 스토리지 기반 Snapshot 백업을 사용하면 일관된 여러 데이터베이스 이미지를 사용하여 NetApp FlexClone 기술을 사용하여 운영 시스템의 클론을 생성할 수 있습니다. 파일 기반 백업에서 리디렉션된 복원을 사용하여 복구 시스템을 설정하는 경우 몇 시간이 아니라 몇 초 이내에 FlexClone 볼륨을 생성할 수 있습니다.

복구 시스템 생성 워크플로는 섹션에 설명되어 있습니다 "“SnapCenter를 사용한 SAP 시스템 복제.”"

효과적인 재해 복구 전략을 위해서는 필요한 워크플로우를 테스트해야 합니다. 테스트는 전략이 제대로 작동하는지 여부와 내부 문서화가 충분한지 여부를 보여 줍니다. 또한 관리자가 필요한 절차를 교육할 수 있습니다.

SnapMirror를 통한 스토리지 복제를 사용하면 RTO 및 RPO를 위험에 빠뜨리지 않고 재해 복구 테스트를 실행할 수 있습니다. 데이터 복제를 중단하지 않고 재해 복구 테스트를 수행할 수 있습니다.

비동기식 및 동기식 SnapMirror의 재해 복구 테스트에서는 재해 복구 대상에 있는 Snapshot 백업과 FlexClone 볼륨을 사용합니다.

다음 그림은 재해 복구 테스트를 보여 줍니다.

자세한 단계별 설명은 기술 보고서에서 확인할 수 있습니다 "스토리지 복제를 사용한 SAP HANA 재해 복구".