# 12 – 데이터 복구 계획
**SAP 워크로드에 대한 논리적 데이터 관련 복구를 어떻게 계획합니까?** 비즈니스 요구 사항에서 거슬러 올라가며 비즈니스 데이터를 복구 또는 재구성하는 접근 방식을 정의합니다. 복원력을 설계한 방법에 따라 이 범주에 다양한 시나리오가 포함될 수 있습니다. 최소한 백업 또는 재해 복구(DR) 태세는 우발적인 삭제, 논리적 데이터 손상 및 맬웨어로부터 사용자를 보호해야 합니다. 서비스 복구 시간과 시스템 간 종속성을 고려하여 신중하게 복원 결정을 내려야 합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-12.html)
# 모범 사례 12.1 - 일관된 비즈니스 데이터 복구를 위한 방법 수립
데이터 손실 또는 손상이 발생한 경우 개별 시스템에 대한 비즈니스 데이터 일관성을 보장하는 데 도움이 되는 데이터 복구 계획을 정의합니다.
**제안 사항 12.1.1 - 데이터베이스 상태를 인식하는 백업 메커니즘을 사용하여 데이터베이스 백업 일관성 보장**
SAP는 데이터베이스 공급 업체의 백업 기능(예: brtools)과 통합하고 SAP 트랜잭션 또는 관리 콘솔 내에서 가시성을 제공하기 위한 메커니즘을 제공합니다. 또한 [AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html) 를 포함한 서드 파티 백업 공급 또는 스토리지 솔루션과 통합할 수 있는 옵션이 있습니다. 이러한 지원되는 옵션에는 일관된 복사본을 생성하는 동안(예: 스토리지 스냅샷 사용) 데이터베이스 상태를 인식하거나, 지속적으로 변경 사항을 캡처하거나 데이터베이스를 중단(작업 일시 중지 또는 축소)하는 기능이 있습니다.
개별 데이터베이스 공급 업체용 SAP 가이드와 다음 AWS 설명서를 검토하세요.
+ AWS 설명서: [AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)
+ SAP 설명서: [SAP NetWeaver 및 ABAP Platform의 Guide Finder](https://help.sap.com/viewer/nwguidefinder)
+ SAP on AWS 블로그: [VSS 스냅샷을 사용하여 SAP용 Microsoft SQL Server 데이터베이스를 백업하는 방법](https://aws.amazon.com/blogs/awsforsap/how-to-back-up-microsoft-sql-server-databases-for-sap-with-vss-snapshots/)
+ AWS 블로그: [Amazon EC2 인스턴스의 여러 Amazon EBS 볼륨에서 충돌 일치 스냅샷 생성](https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/#:~:text=AWS%20Storage%20Blog-,Taking%20crash%2Dconsistent%20snapshots%20across%20multiple%20Amazon%20EBS,on%20an%20Amazon%20EC2%20instance&text=Snapshots%20retain%20the%20data%20from,to%20as%20crash%2Dconsistency).)
**제안 사항 12.1.2 – 비즈니스에 중요한 파일 기반 데이터의 내구성 및 복구 가능성을 평가**
데이터베이스에 저장되지 않은 비즈니스 데이터는 별도의 백업 전략이 필요할 수 있습니다.
표준 SAP NetWeaver 시스템에는 파일 기반 인터페이스 파일, SAP 전송 디렉터리 콘텐츠, 로그(예: 배치 로그, 작업 로그, 작업 프로세스 디렉터리 로그)가 포함되는 경우가 많습니다. 비 SAP NetWeaver 시스템 및 문서 관리 솔루션과 같은 지원 시스템에는 평가해야 하는 다른 파일 기반 비즈니스 데이터가 있을 수 있습니다. [Amazon EFS](https://aws.amazon.com/efs/) 또는 [Amazon FSx](https://aws.amazon.com/fsx/) 를 평가하여 이러한 파일 시스템의 가용성 및 내구성을 개선합니다.
파일 시스템 백업은 스냅샷, AWS Backup 또는 서드 파티 백업 솔루션을 사용하여 수행할 수 있습니다.
비즈니스 데이터는 바이너리 및 구성 데이터와 독립적으로 평가해야 하며, SAP 다운로드, 재설치 또는 코드형 인프라를 통해 다시 프로비저닝할 수 있습니다. 다음을 참조하세요.
+ SAP Lens [운영 우수성]: [제안 사항 12.2.1 - 구성 생성 및 변경에 대한 코드형 인프라 접근 방식을 정의](best-practice-12-2.md)
+ SAP Lens [운영 우수성]: [제안 사항 12.2.2 - 루트 볼륨 등 파일 시스템 콘텐츠 백업에 대한 접근 방식을 정의](best-practice-12-2.md)
**제안 사항 12.1.3 – 데이터베이스 백업 및 로그의 내구성 및 위치를 평가**
백업 및 로그에는 라이브 데이터 레코드가 포함되지만 그 자체로는 장애에 취약할 수 있습니다. 활성 데이터 복사본과 관련하여 백업 위치를 평가하여 장애의 영향을 최소화하는 방법을 수립합니다. 다음을 고려하는 것이 중요합니다.
+ 백업을 보호하는 데 걸리는 시간 - 복구 지점에 영향
+ 백업을 검색/복구하는 데 걸리는 시간 - 복구 시간에 영향
자세한 내용은 다음 설명서에서 찾을 수 있습니다.
+ AWS 설명서: [HANA의 AWS Backint Agent](https://aws.amazon.com/backint-agent/)
+ AWS 설명서: [FSR(빠른 스냅샷 복원)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html)
+ AWS 설명서: [Amazon S3 복제 옵션](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html)
**제안 사항 12.1.4 – 특정 시점으로 복구에 대한 요구 사항을 평가**
특정 시점으로 복구 요구 사항이 있는 경우 백업 설계에서 이를 허용합니까? 백업 방법이 데이터베이스를 인식하고 데이터베이스를 일관된 복구 지점으로 롤포워드할 수 있습니까? 일관성에 필요한 파일 기반 복구를 고려했습니까?
다음 사항을 고려하세요.
+ 로그 간격 및 로그 보호 속도
+ 복구 시간을 개선하기 위한 증분 또는 차등 백업
+ 백업 카탈로그 또는 기타 메커니즘이 필요한지 여부
+ 데이터베이스 또는 스토리지 옵션을 사용하여 과거 시점으로 이동할 수 있는지 여부
**제안 사항 12.1.5 – 데이터 손실로 촉발되는 복구 메커니즘을 검토**
데이터 손상, 삭제 또는 되돌릴 수 없는 잘못된 코드 배포와 같은 심각한 데이터 손실 상황에서 복구의 영향을 결정합니다. 데이터베이스 또는 스토리지 기반 복제 사용 시 데이터 손실의 전파를 평가하고 백업과 같은 보조 복원 메커니즘 사용 시 RTO 및 RPO 영향을 평가합니다.
**제안 사항 12.1.6 – 데이터 벙커를 생성**
[제안 사항 10.3.7 – 백업으로부터 복구가 필요한 장애 시나리오를 결정](best-practice-10-3.md) 의 지침에 따라 우발적 삭제 또는 악의적 활동으로부터 백업을 보호하기 위해 데이터 벙커를 생성합니다.
# 모범 사례 12.2 - 구성 데이터 복구를 위한 방법 수립
SAP 워크로드를 실행하는 데 필요한 여러 유형의 데이터는 SAP 데이터베이스에 상주하지 않습니다. 여기에는 운영 체제 구성, 필요한 AWS 리소스를 재생성하기 위한 메타데이터, 파일 시스템에 저장되는 SAP 애플리케이션에 필요한 데이터가 포함됩니다. 데이터 손실이 발생할 경우 이 데이터를 복구 또는 재생성하는 프로세스를 정의합니다.
**제안 사항 12.2.1 - 구성 생성 및 변경에 대한 코드형 인프라 접근 방식을 정의**
수동으로 개별 인스턴스를 직접 변경할 경우 빠르게 시스템 간 구성 일관성이 사라져 백업을 사용하여 상태를 복구하게 될 수 있습니다. 코드형 인프라를 사용하면 애플리케이션 코드를 관리하는 것과 동일한 방식으로 SAP 시스템을 배포하고 변경 사항을 구현할 수 있습니다. 코드 파이프라인과 같은 DevOps 메커니즘은 환경 내에서 일관성과 반복성을 보장할 수 있는 추가 제어 및 테스트를 제공할 수 있습니다.
접근 방식에서 다음 AWS 서비스를 평가해야 합니다.
+ AWS 서비스: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS 서비스: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ AWS 서비스: [AWS Cloud Development Kit](https://aws.amazon.com/cdk/)
+ SAP on AWS 블로그: [SAP용 DevOps](https://aws.amazon.com/blogs/awsforsap/category/devops/)
+ AWS 설명서: [AWS 기반 DevOps 소개](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/welcome.html)
**제안 사항 12.2.2 - 루트 볼륨 등 파일 시스템 콘텐츠 백업에 대한 접근 방식을 정의**
운영 체제 패키지 및 구성, 애플리케이션 바이너리 및 파일 시스템 콘텐츠는 실행 중인 SAP 시스템에는 필수적이지만 핵심 SAP 데이터베이스 백업의 일부는 아닙니다. Amazon Machine Image(AMI), EBS 볼륨 스냅샷 및 기타 백업 옵션을 포함하여 이 데이터를 보호 및 복원하는 메커니즘을 평가합니다.
AMI, 스냅샷 및 파일 시스템 복사본의 빈도와 일관성은 물론 복구의 세분 수준 및 소요 시간도 고려해야 합니다.
시나리오에 따라 코드형 인프라를 사용하면 복원보다는 재생성에 중점을 두어 비업무용 데이터에 대한 백업 요구 사항을 줄일 수 있습니다.
+ SAP 설명서: [필수 파일 시스템 및 디렉터리](https://help.sap.com/viewer/910828cec5d14d6685da380aec1dc4ae/CURRENT_VERSION/en-US/de6cad1446a743d3853dbcae48bddfba.html)
+ AWS 설명서: [백업 및 복구 솔루션 설계](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/design.html)
**제안 사항 12.2.3 – 모든 수동 설정을 문서화**
데이터베이스에 포함되지 않거나 코드로 배포할 수 있거나 볼륨 백업을 사용하여 복원할 수 있는 수동 작업은 모두 기록하여 최악의 시나리오에서도 SAP 시스템을 재생성할 수 있도록 해야 합니다.
# 모범 사례 12.3 - 전체 SAP 자산에 대한 복구 접근 방식 정의
SAP 자산이 여러 SAP 시스템으로 구성된 경우 비즈니스 우선 순위에 따라 각 시스템이 복구되는 순서를 정의하는 세부 접근 방식을 수립해야 합니다. 데이터 손실이 시스템 및 비즈니스 운영 전반에서 일관성에 미치는 영향을 평가합니다.
**제안 사항 12.3.1 – 복원 우선 순위 및 일관성 보장 계획을 포함하는 비즈니스 연속성 계획을 수립**
[안정성]: [제안 사항 10.1.2 – 장애 영향을 기반으로 시스템을 분류](best-practice-10-1.md) 에서 결정된 시스템 분류에 따라 각 SAP 시스템의 복원 우선 순위를 결정하는 비즈니스 연속성 계획(BCP)을 수립합니다. 이 계획은 복원 우선 순위에 대한 시스템 간 일관성 요구 사항 및 멀티 테넌트 데이터베이스 사용의 영향도 고려해야 합니다.
**제안 사항 12.3.2 – 공유 서비스에 대한 종속성을 모두 평가**
복구 접근 방식을 정의할 때 공유 서비스가 SAP 워크로드를 실행하기 위한 기반(예: DNS, Active Directory)의 일부인지 아니면 복원 자체를 수행하는 데 필요한 기반(예: 백업 도구)의 일부인지 고려합니다. 이러한 종속성과 관련된 위험 및 복원 전제 조건을 평가합니다.
**제안 사항 12.3.3 - 재해 발생 시 수행할 런북을 작성**
사전 정의된 런북은 재해 발생 시 입증된 일련의 단계를 수행하도록 하여 중요한 작업을 누락할 위험을 줄입니다.
# 모범 사례 12.4 - 주기적 테스트를 수행하여 복구 절차 검증
소프트웨어 및 절차가 예측 가능한 결과를 제공함을 입증하고 백업 파일의 상태를 검증하기 위해 중대 장애 시나리오로부터 복구를 주기적으로 테스트합니다. 아키텍처, 소프트웨어 또는 지원 담당자에 대한 변경 사항을 평가하여 추가 테스트가 필요한지 여부를 결정해야 합니다.
**제안 사항 12.4.1 - 복구 테스트를 위한 장애 시나리오를 식별**
[안정성]: [제안 사항 10.3.2 – 백업으로부터 복구가 필요한 장애 시나리오를 결정](best-practice-10-3.md) 을 기반으로 복구가 필요한 장애 시나리오를 정의하고 프로세스 및 도구를 검증하는 데 필요한 적절한 수준의 테스트를 결정해야 합니다.
**제안 사항 12.4.2 – 시스템 변경이 복구 접근 방식에 미치는 영향을 결정**
변경의 영향을 평가하기 위한 접근 방식을 정의하고 해당 변경으로 인해 접근 방식이 무효화되지 않는지 확인하는 데 필요한 후속 복구 테스트를 정의합니다. 워크로드 복구에 영향을 줄 수 있는 변경 유형의 예로는 소프트웨어 업그레이드, 패치, 파라미터 변경이 있습니다.
관리형 서비스 파트너 또는 핵심 인력의 변경과 같이 SAP 환경을 지원하는 데 사용되는 운영 모델이 크게 변경된 경우에도 복구 테스트를 계획해야 합니다.
**제안 사항 12.4.3 – 복구 테스트 계획을 정의**
복구가 필요할 수 있는 중대 장애 시나리오를 시뮬레이션할 수 있도록 전체 세트의 테스트가 정의되어 있어야 합니다. 복구 테스트는 초기 구현 중 그리고 구현 이후로 주기적으로 또는 필요할 때마다 계획해야 합니다.
+ SAP Lens [운영 우수성]: [모범 사례 4.3 - 정기적으로 비즈니스 연속성 계획 및 장애 복구 테스트](best-practice-4-3.md) .