기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
REL09-BP04 데이터의 주기적 복구를 수행하여 백업 무결성 및 프로세스 확인
복구 테스트를 수행하여 백업 프로세스 구현이 복구 시간 목표(RTO) 및 복구 시점 목표(RPO)를 충족하는지 확인합니다.
원하는 결과: 백업의 데이터는 워크로드에 대해 설정된 복구 시간 목표(RTO) 내에 복구가 가능한지 확인하기 위해 잘 정의된 메커니즘을 사용하여 주기적으로 복구됩니다. 백업에서 복원하면 손상되거나 액세스할 수 없는 원본 데이터가 포함되어 있고 복구 시점 목표() 내에 데이터가 손실된 리소스가 발생하는지 확인합니다RPO.
일반적인 안티 패턴:
-
백업을 복원하지만 복원이 사용 가능한 상태인지 확인하기 위해 데이터를 쿼리하거나 검색하지 않습니다.
-
백업이 존재한다고 가정합니다.
-
시스템의 백업이 완전히 작동하며 시스템에서 데이터를 복구할 수 있다고 가정합니다.
-
백업에서 데이터를 복원하거나 복구하는 시간이 워크로드에 RTO 대해 에 속한다고 가정합니다.
-
백업에 포함된 데이터가 워크로드의 RPO 에 속한다고 가정
-
런북을 사용하지 않거나 설정된 자동화 절차를 벗어나 필요에 따라 복원합니다.
이 모범 사례 설정의 이점: 백업 복구를 테스트하면 데이터가 누락되거나 손상될 수 있다는 걱정 없이 필요할 때 데이터를 복원할 수 있고, 워크로드의 경우 에서 복원 및 복구RTO가 가능하며, 모든 데이터 손실이 워크로드의 RPO 경우 에 속하는지 확인할 수 있습니다.
이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 중간
구현 가이드
백업 및 복원 기능을 테스트하면 중단 시 백업 및 복원 수행의 역량에 대한 신뢰도를 높일 수 있습니다. 주기적으로 백업을 새로운 위치에 복원하고 테스트를 실행하여 데이터의 무결성을 확인합니다. 수행해야 하는 몇 가지 일반적인 테스트는 모든 데이터를 사용할 수 있는지, 데이터가 손상되지 않았는지, 액세스 가능한지, 모든 데이터 손실이 워크로드에 RPO 대해 에 속하는지 확인하는 것입니다. 또한 이러한 테스트는 복구 메커니즘이 워크로드의 를 수용할 수 있을 만큼 빠른지 확인하는 데 도움이 될 수 있습니다RTO.
를 사용하면 테스트 환경을 구축하고 백업을 복원하여 RTO 및 RPO 기능을 평가하고 데이터 콘텐츠 및 무결성에 대한 테스트를 실행할 AWS수 있습니다.
또한 Amazon RDS 및 Amazon DynamoDB는 복구()를 허용합니다 point-in-timePITR. 연속 백업을 사용하면 데이터 세트를 지정된 날짜 및 시간의 상태로 복원할 수 있습니다.
모든 데이터를 사용할 수 있고, 이 손상되지 않았으며, 에 액세스할 수 있고, 모든 데이터 손실이 워크로드에 RPO 대해 에 속하는 경우. 또한 이러한 테스트는 복구 메커니즘이 워크로드의 를 수용할 수 있을 만큼 빠른지 확인하는 데 도움이 될 수 있습니다RTO.
AWS Elastic Disaster Recovery 는 Amazon EBS 볼륨의 지속적인 point-in-time 복구 스냅샷을 제공합니다. 소스 서버가 복제 point-in-time되면 구성된 정책에 따라 시간이 지남에 따라 상태가 만성화됩니다. Elastic Disaster Recovery는 트래픽을 리디렉션하지 않고 테스트 및 드릴 목적으로 인스턴스를 시작하여 이러한 스냅샷의 무결성을 확인하는 데 도움이 됩니다.
구현 단계
-
현재 백업되고 있는 데이터 소스와 이러한 백업이 저장되는 위치를 식별합니다. 구현 지침은 REL09-BP01 백업해야 하는 모든 데이터를 식별 및 백업하거나 소스에서 데이터를 복제합니다. 섹션을 참조하세요.
-
각 데이터 소스에 대해 데이터 검증 기준을 설정합니다. 다양한 유형의 데이터에는 다양한 유효성 검사 메커니즘이 필요할 수 있는 다양한 속성이 있습니다. 확신을 갖고 프로덕션에 사용하기 전에 이 데이터가 어떻게 검증될 수 있는지 고려하세요. 데이터를 검증하는 몇 가지 일반적인 방법은 데이터 유형, 형식, 체크섬, 크기 등의 데이터 및 백업 속성을 사용하거나 이러한 속성과 사용자 지정 검증 로직을 결합하는 것입니다. 예를 들어, 복원된 리소스와 백업이 생성된 당시의 데이터 소스의 체크섬 값을 비교해 볼 수 있습니다.
-
데이터 중요도에 따라 데이터를 복원하기 위한 RTO 및 를 설정합니다RPO. 구현 지침은 REL13-BP01 가동 중지 및 데이터 손실에 대한 복구 목표 정의 섹션을 참조하세요.
-
복구 역량을 평가합니다. 백업 및 복원 전략을 검토하여 RTO 및 를 충족할 수 있는지 이해하고 필요에 따라 전략을 RPO조정합니다. AWS Resilience Hub를 사용하여 워크로드 평가를 실행할 수 있습니다. 평가는 복원력 정책을 기준으로 애플리케이션 구성을 평가하고 RTO 및 RPO 대상을 충족할 수 있는지 보고합니다.
-
프로덕션에서 데이터 복원을 위해 현재 확립된 프로세스를 사용하여 테스트 복원을 수행합니다. 이 프로세스는 원본 데이터 소스가 백업되는 방법, 백업 자체의 형식 및 스토리지 위치 또는 다른 소스에서의 데이터 복제 여부에 따라 달라집니다. 예를 들어, AWS Backup과 같은 관리형 서비스를 사용하는 경우 백업을 새 리소스에 간단하게 복원할 수 있습니다. AWS Elastic Disaster Recovery 를 사용한 경우 복구 드릴을 시작할 수 있습니다.
-
데이터 유효성 검사를 위해 이전에 설정한 기준에 따라 복원된 리소스에서 데이터 복구 유효성을 검사합니다. 복원되고 복구된 데이터에 백업 시 가장 최신 레코드 또는 항목이 포함되어 있나요? 이 데이터는 워크로드RPO의 에 해당되나요?
-
복원 및 복구에 필요한 시간을 측정하고 이를 설정된 와 비교합니다RTO. 이 프로세스는 워크로드에 RTO 대해 에 속합니까? 예를 들어, 복원 프로세스가 시작됐을 때의 타임스탬프와 복구 검증이 완료됐을 때의 타임스탬프를 비교하여 프로세스에 걸린 시간을 계산합니다. 모든 AWS API 통화는 타임스탬프가 지정되어 있으며 이 정보는 에서 사용할 수 있습니다AWS CloudTrail. 이 정보가 복원 프로세스가 시작된 시간에 대한 세부 정보를 제공하지만 검증이 완료된 종료 타임스탬프는 검증 로직에서 기록되어야 합니다. 자동화된 프로세스를 사용하는 경우 Amazon DynamoDB
와 같은 서비스를 사용하여 이 정보를 저장할 수 있습니다. 또한 많은 AWS 서비스가 특정 작업이 발생할 때 타임스탬프 정보를 제공하는 이벤트 기록을 제공합니다. 내에서 AWS Backup백업 및 복원 작업은 작업 이라고 하며 이러한 작업에는 복원 및 복구에 필요한 시간을 측정하는 데 사용할 수 있는 메타데이터의 일부로 타임스탬프 정보가 포함됩니다. -
데이터 검증에 실패하거나 복원 및 복구에 필요한 시간이 워크로드에 RTO 대해 설정된 시간을 초과하는 경우 이해관계자에게 알립니다. 이 랩 에서와 같이
자동화를 구현할 때 Amazon Simple Notification Service(Amazon SNS)와 같은 서비스를 사용하여 이메일 또는 이해관계자SMS에게 푸시 알림을 보낼 수 있습니다. 이러한 메시지는 Amazon Chime, Slack 또는 Microsoft Teams와 같은 메시징 애플리케이션에 게시하거나 Systems Manager 를 사용하여 작업을 생성하는 데 사용할 수도 있습니다 . OpsItems AWS OpsCenter -
이 프로세스를 주기적으로 실행하도록 자동화합니다. 예를 들어 또는 의 상태 머신과 같은 AWS Lambda 서비스를 사용하여 복원 및 복구 프로세스를 자동화할 AWS Step Functions 수 있으며 Amazon을 사용하여 아래 아키텍처 다이어그램과 같이 이 자동화 워크플로를 주기적으로 호출할 EventBridge 수 있습니다. 를 사용하여 데이터 복구 검증을 자동화 AWS Backup
하는 방법을 알아봅니다. 또한 이 Well-Architected 실습 은 여기에 있는 여러 단계에 대해 자동화를 수행하는 한 가지 방법에 대한 실습 경험을 제공합니다.
그림 9. 자동화된 백업 및 복원 프로세스
구현 계획의 작업 수준: 보통~높음(유효성 검사 기준의 복잡성에 따라 달라짐).
리소스
관련 문서:
관련 예제:
