Azure Storage 재해 복구 계획 및 장애 조치(failover)

  • 아티클

Microsoft는 Azure 서비스를 항상 사용할 수 있도록 하기 위해 노력합니다. 그러나 계획되지 않은 서비스 중단이 발생할 수 있습니다. 적절한 재해 복구 계획의 주요 구성 요소에는 다음을 위한 전략이 포함됩니다.

이 문서에서는 전역 중복 스토리지 계정(GRS, GZRS 및 RA-GZRS)에 대한 장애 조치(failover)와 중단 및 후속 장애 조치(failover)가 있는 경우 애플리케이션이 고가용성이 되도록 디자인하는 방법을 중점적으로 설명합니다.

적절한 중복 옵션 선택

Azure Storage는 내구성 및 고가용성을 보장하기 위해 스토리지 계정의 여러 복사본을 유지 관리합니다. 계정에 대해 선택하는 중복 옵션은 애플리케이션에 필요한 복원력의 정도에 따라 달라집니다.

LRS(로컬 중복 스토리지)를 사용하면 스토리지 계정의 복사본 3개가 단일 데이터 센터 내에 자동으로 저장되고 복제됩니다. ZRS(영역 중복 스토리지)를 사용하면 복사본이 동일한 지역 내의 세 개의 개별 가용성 영역에 각각 저장되고 복제됩니다. 가용성 영역에 대한 자세한 내용은 Azure 가용성 영역을 참조하세요.

스토리지 계정의 단일 복사본 복구는 LRS 및 ZRS를 사용하여 자동으로 수행됩니다.

전역 중복 스토리지 및 장애 조치(failover)

전역 중복 스토리지(GRS, GZRS 및 RA-GZRS)를 사용하면 Azure는 데이터를 수백 마일 이상 떨어진 보조 지리적 지역에 비동기적으로 복사합니다. 이렇게 하면 주 지역에 중단이 있는 경우 데이터를 복구할 수 있습니다. LRS 및 ZRS와 전역 중복 스토리지를 구분하는 기능은 주 지역에 중단이 있는 경우 보조 지역으로 장애 조치(failover)하는 기능입니다. 장애 조치(failover) 프로세스는 스토리지 계정 서비스 엔드포인트에 대한 DNS 항목을 업데이트하여 보조 지역의 엔드포인트가 스토리지 계정의 새 기본 엔드포인트가 되도록 합니다. 장애 조치(failover)가 완료되면 클라이언트는 새 기본 엔드포인트에 쓰기 시작할 수 있습니다.

RA-GRS 및 RA-GZRS 중복 구성은 주 지역에 중단이 있는 경우 보조 엔드포인트에 대한 읽기 액세스의 추가 혜택과 함께 지역 중복 스토리지를 제공합니다. 기본 엔드포인트에서 중단이 발생하는 경우 보조 지역에 대한 읽기 권한을 위해 구성되고 고가용성을 위해 설계된 애플리케이션이 보조 엔드포인트에서 계속 읽을 수 있습니다. 스토리지 계정의 최대 가용성 및 내구성을 위해 RA-GZRS를 권장합니다.

Azure Storage의 중복성에 대한 자세한 내용은 Azure Storage 중복성을 참조하세요.

스토리지 계정 장애 조치(failover) 계획

Azure Storage 계정은 다음 두 가지 유형의 장애 조치(failover)를 지원합니다.

1Microsoft 관리 장애 조치(failover)는 개별 스토리지 계정, 구독 또는 테넌트에 대해 시작할 수 없습니다. 자세한 내용은 Microsoft 관리 장애 조치(failover)를 참조하세요.
2 재해 복구 계획은 고객 관리 장애 조치(failover)를 기반으로 해야 합니다. 극단적인 상황에서만 사용되는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요.

각 유형의 장애 조치(failover)에는 고유한 사용 사례 집합, 데이터 손실에 대한 상응하는 예상, 계층 구조 네임스페이스가 사용하도록 설정된 계정에 대한 지원(Azure Data Lake Storage Gen2)이 있습니다. 이 표에서는 각 장애 조치(failover) 유형의 이러한 측면을 요약합니다.

Type 장애 조치(failover) 범위 사용 사례 예상 데이터 손실 지원되는 HNS
고객 관리 스토리지 계정 주 지역에 대한 스토리지 서비스 엔드포인트를 사용할 수 없게 되지만 보조 지역을 사용할 수 있습니다.

중단으로 인해 잠재적으로 영향을 받을 수 있는 스토리지 계정의 장애 조치(failover) 작업을 수행하도록 Microsoft에서 권고하는 Azure 권고를 받았습니다.		 예 예(미리 보기 상태)
Microsoft 관리 전체 지역 또는 배율 단위 심각한 재해로 인해 주 지역을 완전히 사용할 수 없게 되지만 보조 지역을 사용할 수 있습니다. 예 예

고객 관리형 장애 조치(failover)

스토리지 계정의 스토리지 서비스에 대한 데이터 엔드포인트를 주 지역에서 사용할 수 없게 되면 보조 지역으로 장애 조치(failover)할 수 있습니다. 장애 조치(failover)가 완료되면 보조 지역이 새 주 지역이 되고 사용자는 새 주 지역의 데이터에 계속 액세스할 수 있습니다.

고객 관리 계정 장애 조치(failover)가 사용자 및 애플리케이션에 미치는 영향을 완전히 이해하려면 장애 조치(failover) 및 장애 복구 프로세스의 모든 단계에서 발생하는 작업을 파악하는 것이 유용합니다. 프로세스 작동 방식에 대한 자세한 내용은 고객 관리 스토리지 계정 장애 조치(failover)가 작동하는 방식을 참조하세요.

Microsoft에서 관리하는 장애 조치(failover)

큰 재해로 인해 적절한 시간 내에 원래 주 지역을 복구할 수 없는 것으로 간주되는 극단적인 상황에서 Microsoft는 지역 장애 조치(failover)를 시작할 수 있습니다. 이 경우에 사용자의 조치가 필요하지 않습니다. Microsoft에서 관리하는 장애 조치(failover)가 완료될 때까지 스토리지 계정에 대한 쓰기 액세스 권한이 없습니다. 애플리케이션은 스토리지 계정이 RA-GRS 또는 RA-GZRS용으로 구성된 경우 보조 지역에서 읽을 수 있습니다.

Important

재해 복구 계획은 고객 관리 장애 조치(failover)를 기반으로 해야 합니다. 극단적인 상황에서만 사용될 수 있는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요. 지역 또는 배율 단위와 같은 전체 물리적 단위에 대해 Microsoft에서 관리하는 장애 조치(failover)가 시작됩니다. 개별 스토리지 계정, 구독 또는 테넌트에 대해서는 시작할 수 없습니다. 개별 스토리지 계정을 선택적으로 장애 조치(failover)하는 기능에는 고객 관리 계정 장애 조치(failover)를 사용합니다.

데이터 손실 및 불일치 예상

주의

스토리지 계정 장애 조치(failover)에는 일반적으로 일부 데이터 손실과 잠재적으로 파일 및 데이터 불일치가 포함됩니다. 재해 복구 계획에서 계정 장애 조치(failover)를 시작하기 전에 계정 장애 조치(failover)가 데이터에 미치는 영향을 고려하는 것이 중요합니다.

데이터는 비동기적으로 주 지역에서 보조 지역으로 기록되므로 주 지역에 대한 쓰기가 보조 지역으로 복사되기 전에 항상 지연이 발생합니다. 주 지역을 사용할 수 없는 경우 가장 최근 쓰기가 보조 지역에 아직 복사되지 않았을 수 있습니다.

장애 조치(failover)가 발생하면 보조 지역이 새 주 지역이 됨에 따라 주 지역의 모든 데이터가 손실됩니다. 장애 조치(failover)가 발생하면 보조 지역으로 이미 복사된 모든 데이터가 유지됩니다. 그러나 보조 지역에 복사되지 않은 주 데이터베이스에 기록된 모든 데이터는 영구적으로 손실됩니다.

새 주 지역은 장애 조치(failover) 후 로컬 중복(LRS)이 되도록 구성됩니다.

스토리지 계정에 다음 중 하나 이상을 사용하도록 설정한 경우 파일 또는 데이터 불일치가 발생할 수도 있습니다.

마지막 동기화 시간

마지막 동기화 시간 속성은 주 지역의 데이터가 보조 지역에 기록될 것으로 보장되는 가장 최근 시간을 나타냅니다. 계층 구조 네임스페이스가 있는 계정의 경우 동일한 마지막 동기화 시간 속성이 ACL을 포함하여 계층 구조 네임스페이스에서 관리하는 메타데이터에도 적용됩니다. 마지막 동기화 시간 전에 기록된 모든 데이터 및 메타데이터는 보조 지역에서 사용할 수 있지만, 마지막 동기화 시간 이후에 기록된 데이터 및 메타데이터는 보조 지역에 기록되지 않았을 수 있으므로 손실될 수 있습니다. 중단이 있는 경우 이 속성을 사용하여 계정 장애 조치(failover)를 시작하여 발생할 수 있는 데이터 손실 크기를 예상합니다.

모범 사례로, 마지막 동기화 시간을 사용하여 예상되는 데이터 손실을 예측할 수 있도록 애플리케이션을 디자인합니다. 예를 들어, 모든 쓰기 작업을 기록하는 경우 마지막 쓰기 작업의 시간을 마지막 동기화 시간과 비교하여 보조 지역과 동기화되지 않은 쓰기를 확인할 수 있습니다.

마지막 동기화 시간 속성을 확인하는 방법에 대한 자세한 내용은 스토리지 계정에 대한 마지막 동기화 시간 속성 확인을 참조하세요.

Azure Data Lake Storage Gen2에 대한 파일 일관성

계층 구조 네임스페이스를 사용하도록 설정한(Azure Data Lake Storage Gen2) 스토리지 계정에 대한 복제는 파일 수준에서 발생합니다. 즉, 주 지역에서 중단이 발생하면 컨테이너 또는 디렉터리의 일부 파일만 보조 지역에 성공적으로 복제되었을 수 있습니다. 스토리지 계정 장애 조치(failover) 후 컨테이너 또는 디렉터리의 모든 파일에 대한 일관성은 보장되지 않습니다.

변경 피드와 BLOB 데이터 불일치

변경 피드가 사용하도록 설정된 지역 중복 스토리지 계정의 스토리지 계정 장애 조치(failover)는 변경 피드 로그와 BLOB 데이터 및/또는 메타데이터 간에 불일치를 초래할 수 있습니다. 이러한 불일치는 변경 로그에 대한 업데이트와 주 지역에서 보조 지역으로 BLOB 데이터 복제 모두의 비동기 특성으로 인해 발생할 수 있습니다. 불일치가 예상되지 않는 유일한 상황은 모든 현재 로그 레코드가 로그 파일로 성공적으로 플러시되고 모든 스토리지 데이터가 주 지역에서 보조 지역으로 성공적으로 복제된 경우입니다.

변경 피드의 작동 방식에 대한 자세한 내용은 변경 피드 작동 방식을 참조하세요.

다른 스토리지 계정 기능을 사용하려면 Azure Blob Storage의 운영 백업, 개체 복제 및 블록 Blob에 대한 특정 시점 복원과 같은 변경 피드를 사용하도록 설정해야 합니다.

특정 시점 복원 불일치

고객 관리 장애 조치(failover)는 블록 Blob을 포함하는 범용 v2 표준 계층 스토리지 계정에 대해 지원됩니다. 그러나, 스토리지 계정에서 고객 관리 장애 조치(failover)를 수행하면 해당 계정에 대해 가능한 가장 빠른 복원 지점이 다시 설정됩니다. 블록 Blob에 대한 특정 시점 복원에 대한 데이터는 장애 조치 완료 시간까지만 일치합니다. 따라서 장애 조치(failover) 완료 시간 이후의 특정 시점까지만 블록 Blob을 복원할 수 있습니다. Azure Portal의 스토리지 계정 중복 탭에서 장애 조치(failover) 완료 시간을 검사 수 있습니다.

예를 들어 보존 기간을 30일로 설정했다고 가정합니다. 장애 조치(failover) 이후 30일이 지나면 해당 30일 이내에 원하는 시점으로 복원할 수 있습니다. 그러나 장애 조치(failover) 이후 30일 미만이 경과한 경우 보존 기간에 관계없이 장애 조치 이전의 시점으로 복원할 수 없습니다. 예를 들어 장애 조치(failover) 이후 10일이 지난 경우 가능한 가장 빠른 복원 지점은 과거 30일이 아니라 과거 10일입니다.

장애 조치(failover)의 시간과 비용

장애 조치(failover)가 시작된 후 완료되는 데 걸리는 시간은 다양할 수 있지만 일반적으로 1시간 미만이 소요됩니다.

고객 관리 장애 조치(failover)는 장애 조치(failback) 후 지역 중복을 잃게 됩니다. 스토리지 계정은 장애 조치(failover) 중에 새 주 지역의 LRS(로컬 중복 스토리지)로 자동으로 변환되고 원래 주 지역의 스토리지 계정은 삭제됩니다.

계정에 GRS(지역 중복 스토리지) 또는 RA-GRS(읽기 액세스 지역 중복 스토리지)를 다시 사용하도록 설정할 수 있지만 LRS에서 GRS 또는 RA-GRS로 변환하면 추가 비용이 발생합니다. 데이터를 새 보조 지역으로 다시 복제하기 위해 네트워크 송신 요금이 발생합니다. 또한 계정이 지역 중복을 위해 구성되기 전에 보관된 모든 BLOB을 온라인 계층으로 리하이드레이션해야 하며 비용이 발생합니다. 가격 책정에 대한 자세한 내용은 다음을 참조하세요.

스토리지 계정에 대해 GRS를 다시 사용하면 계정의 데이터가 새 보조 지역으로 복제되기 시작합니다. 복제 시간은 다음을 포함하는 다양한 요인에 따라 다릅니다.

  • 스토리지 계정의 개체 수 및 크기 많은 작은 개체를 복제하는 것이 더 적은 수의 더 큰 개체를 복제하는 것보다 더 오래 걸릴 수 있습니다.
  • CPU, 메모리, 디스크 및 WAN 용량과 같은 백그라운드 복제에 사용할 수 있는 리소스입니다. 라이브 트래픽은 지역 복제보다 우선합니다.
  • 스토리지 계정에 BLOB이 포함된 경우 스토리지 계정당 스냅샷 수.
  • 스토리지 계정에 테이블이 포함된 경우 데이터 분할 전략. 복제 프로세스는 사용하는 파티션 키 수를 초과하여 확장할 수 없습니다.

지원되는 스토리지 계정 형식

모든 지역 중복 제품은 Microsoft 관리 장애 조치(failover)를 지원합니다. 또한 다음 표와 같이 일부 계정 유형은 고객 관리형 계정 장애 조치를 지원합니다.

장애 조치(failover) 유형 GRS/RA-GRS GZRS/RA-GZRS
고객 관리형 장애 조치(failover) 범용 v2 계정
범용 v1 계정
레거시 Blob Storage 계정		 범용 v2 계정
Microsoft에서 관리하는 장애 조치(failover) 모든 계정 유형 범용 v2 계정

클래식 스토리지 계정

Important

고객 관리형 계정 장애 조치는 ARM(Azure Resource Manager) 배포 모델을 사용하여 배포된 스토리지 계정에 대해서만 지원됩니다. 클래식이라고도 하는 ASM(Azure Service Manager) 배포 모델은 지원되지 않습니다. 클래식 스토리지 계정이 고객 관리형 계정 장애 조치에 적합하도록 하려면 먼저 ARM 모델로 마이그레이션해야 합니다. 업그레이드를 수행하려면 스토리지 계정에 액세스할 수 있어야 하므로 주 지역은 현재 실패 상태일 수 없습니다.

주 지역에 영향을 미치는 재해가 발생한 경우 Microsoft는 계층 클래식 스토리지 계정에 대한 장애 조치(failover)를 관리합니다. 자세한 내용은 Microsoft 관리형 장애 조치(failover)를 참조하세요.

Azure Data Lake Storage Gen2

Important

계층 구조 네임스페이스(Azure Data Lake Storage Gen2)가 있는 계정에 대한 고객 관리형 계정 장애 조치는 현재 미리 보기로 제공되며 다음 지역에서만 지원됩니다.

  • (아시아 태평양) 인도 중부
  • (아시아 태평양) 동남 아시아
  • (유럽) 북유럽
  • (유럽) 스위스 북부
  • (유럽) 스위스 서부
  • (유럽) 서유럽
  • (북아메리카) 캐나다 중부
  • (북아메리카) 미국 동부 2
  • (북아메리카) 미국 중남부

미리 보기를 옵트인하려면 Azure 구독에서 미리 보기 기능 설정을 참조하고 AllowHNSAccountFailover를 기능 이름으로 지정하세요.

베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.

주 지역에 영향을 미치는 심각한 재해가 발생한 경우 Microsoft는 계층 구조 네임스페이스가 있는 계정에 대한 장애 조치(failover)를 관리합니다. 자세한 내용은 Microsoft 관리형 장애 조치(failover)를 참조하세요.

지원되지 않는 기능 및 서비스

다음 기능 또는 서비스는 계정 장애 조치(failover)에서 지원되지 않습니다.

  • Azure 파일 동기화는 고객이 시작한 스토리지 계정 장애 조치(failover)를 지원하지 않습니다. Azure 파일 동기화에서 클라우드 엔드포인트로 사용되는 Azure 파일 공유를 포함하는 스토리지 계정은 장애 조치(failover)하지 않아야 합니다. 이러한 계정을 장애 조치(failover)하면 동기화가 더 이상 진행되지 않고, 새로 계층화된 파일의 경우 예기치 않은 데이터 손실이 발생할 수도 있습니다. 자세한 내용은 Azure 파일 동기화를 사용한 재해 복구 모범 사례를 참조하세요.
  • 프리미엄 블록 Blob을 포함하는 스토리지 계정은 장애 조치(failover)할 수 없습니다. 프리미엄 블록 Blob을 지원하는 스토리지 계정은 현재 지역 중복을 지원하지 않습니다.
  • 고객 관리 장애 조치(failover)는 개체 복제 정책의 원본 또는 대상 계정에 대해 지원되지 않습니다.
  • SFTP(SSH 파일 전송 프로토콜)가 활성화된 계정을 장애 조치하려면 먼저 계정에 대해 SFTP를 비활성화해야 합니다. 장애 조치가 완료된 후 SFTP를 다시 사용하려면 SFTP를 다시 활성화하기만 하면 됩니다.
  • NFS(Network File System) 3.0(NFSv3)은 스토리지 계정 장애 조치(failover)에 대해 지원되지 않습니다. NFSv3을 사용하도록 설정한 상태에서 전역 중복성을 위해 구성된 스토리지 계정을 생성할 수 없습니다.

장애 조치(failover)는 계정 마이그레이션용이 아닙니다.

스토리지 계정 장애 조치(failover)는 데이터 마이그레이션 전략의 일부로 사용하면 안 됩니다. 장애 조치(failover)는 서비스 중단에 대한 임시 솔루션입니다. 스토리지 계정을 마이그레이션하는 방법에 대한 자세한 내용은 Azure Storage 마이그레이션 개요를 참조하세요.

보관된 BLOB을 포함하는 스토리지 계정

보관된 BLOB을 포함하는 스토리지 계정은 계정 장애 조치(failover)를 지원합니다. 그러나 고객 관리 장애 조치(failover)가 완료된 후에는 계정이 지역 중복을 위해 구성되기 전에 보관된 모든 BLOB을 온라인 계층으로 리하이드레이션해야 합니다.

스토리지 리소스 공급자

Microsoft는 Azure Storage 리소스로 작업하기 위한 두 가지 REST API를 제공합니다. 두 API는 Azure Storage에 대해 수행할 수 있는 모든 작업의 기초를 형성합니다. Azure Storage REST API를 사용하면 Blob, 큐, 파일, 테이블 데이터를 포함하여 스토리지 계정의 데이터로 작업할 수 있습니다. Azure Storage 리소스 공급자 REST API를 사용하면 스토리지 계정 및 관련 리소스를 관리할 수 있습니다.

장애 조치(failover)가 완료되면 클라이언트는 새 주 지역에서 Azure Storage 데이터를 다시 읽고 쓸 수 있습니다. 그러나 Azure Storage 리소스 공급자는 장애 조치(fail over)되지 않으므로 리소스 관리 작업은 주 지역에서 계속 수행되어야 합니다. 주 지역을 사용할 수 없는 경우 스토리지 계정에서 관리 작업을 수행할 수 없습니다.

Azure Storage 리소스 공급자가 장애 조치(failover)되지 않으므로 위치 속성은 장애 조치(failover)가 완료된 후 원래 기본 위치를 반환합니다.

Azure 가상 머신

Azure VM(Virtual Machines)은 계정 장애 조치(failover)의 일부로 장애 조치(failover)되지 않습니다. 주 지역을 사용할 수 없으며 보조 지역으로 장애 조치(failover)할 경우 장애 조치(failover) 후에 VM을 다시 만들어야 합니다. 또한 계정 장애 조치(failover)와 관련된 잠재적인 데이터 손실이 있습니다. Microsoft는 Azure의 가상 머신과 관련하여 다음과 같은 고가용성 및 재해 복구 지침을 권장합니다.

VM이 종료되면 임시 디스크에 저장된 데이터가 손실됩니다.

Azure 관리되지 않는 디스크

모범 사례로, 관리되지 않는 디스크를 Managed Disks로 변환하는 것이 좋습니다. 그러나 Azure VM에 연결된 관리되지 않는 디스크를 포함하는 계정을 장애 조치(failover)해야 할 경우 장애 조치(failover)를 시작하기 전에 VM을 종료해야 합니다.

관리되지 않는 디스크는 Azure Storage에 페이지 Blob으로 저장됩니다. VM을 Azure에서 실행 중인 경우 VM에 연결된 모든 관리되지 않는 디스크가 임대됩니다. BLOB에 임대가 있으면 계정 장애 조치(failover)를 계속할 수 없습니다. 장애 조치(failover)를 수행하려면 다음 단계를 수행합니다.

  1. 시작하기 전에 관리되지 않는 디스크, 해당 LUN(논리 단위 번호) 및 해당 디스크가 연결된 VM을 기록해 둡니다. 이렇게 하면 장애 조치(failover) 후에 디스크를 보다 쉽게 다시 연결할 수 있습니다.
  2. VM을 종료합니다.
  3. VM을 삭제하지만 관리되지 않는 디스크의 VHD 파일은 유지합니다. VM을 삭제한 시간을 기록해 둡니다.
  4. VM을 삭제한 이후에 해당하는 마지막 동기화 시간이 업데이트될 때까지 기다립니다. 장애 조치(failover)가 발생할 때 보조 엔드포인트가 VHD 파일로 완전히 업데이트되지 않은 경우 새 주 지역에서 VM이 제대로 작동하지 않을 수 있으므로 이 단계가 중요합니다.
  5. 계정 장애 조치(failover)를 시작합니다.
  6. 계정 장애 조치(failover)가 완료되고 보조 지역이 새 주 지역이 될 때까지 기다립니다.
  7. 새 주 지역에서 VM을 만들고 VHD를 다시 연결합니다.
  8. 새 VM을 시작합니다.

VM이 종료되면 임시 디스크에 저장된 데이터가 손실됩니다.

장애 조치(failover) 대신 데이터 복사

스토리지 계정이 보조 지역에 대한 읽기 권한으로 구성된 경우 보조 엔드포인트에서 읽도록 애플리케이션을 디자인할 수 있습니다. 주 지역에서 중단이 발생할 경우 장애 조치(failover)하지 않으려는 경우 AzCopy 또는 Azure PowerShell와 같은 도구를 사용하여 보조 지역의 스토리지 계정에 있는 데이터를 영향을 받지 않는 지역의 다른 스토리지 계정으로 복사할 수 있습니다. 그런 다음, 읽기 및 쓰기 가용성을 위해 애플리케이션에서 해당 스토리지 계정을 가리키도록 할 수 있습니다.

고가용성을 위한 디자인

처음부터 고가용성을 위해 애플리케이션을 디자인하는 것이 중요합니다. 애플리케이션을 디자인하고 재해 복구를 계획하기 위한 지침에 대해서는 다음 Azure 리소스를 참조하세요.

Azure Storage 데이터에 대해 고가용성을 유지하기 위한 다음 모범 사례를 기억하세요.

  • Disks:Azure Backup을 사용하여 Azure Virtual Machines에서 사용하는 VM 디스크를 백업합니다. 또한 지역 재해가 발생한 경우 Azure Site Recovery를 사용하여 VM을 보호하는 것이 좋습니다.
  • 블록 Blob:일시 삭제를 설정하여 개체 수준 삭제 및 덮어쓰기에 대해 보호하거나 AzCopy, Azure PowerShell 또는 Azure 데이터 이동 라이브러리를 사용하여 다른 지역에 있는 다른 스토리지 계정에 블록 Blob을 복사합니다.
  • 파일:Azure Backup을 사용하여 파일 공유를 백업합니다. 또한 실수로 인한 파일 공유 삭제로부터 보호하기 위해 일시 삭제를 사용하도록 설정합니다. GRS를 사용할 수 없을 때 지역 중복을 위해 AzCopy 또는 Azure PowerShell을 사용하여 다른 지역의 다른 스토리지 계정에 파일을 복사합니다.
  • 테이블:AzCopy를 사용하여 다른 지역에 있는 다른 스토리지 계정으로 테이블 데이터를 내보냅니다.

중단 추적

고객은 Azure Service Health 대시보드를 구독하여 Azure Storage 및 다른 Azure 서비스의 상태를 추적할 수 있습니다.

쓰기 오류의 가능성에 대비하도록 애플리케이션을 디자인하는 것이 좋습니다. 애플리케이션은 주 지역의 가동 중단 가능성을 경고하는 방식으로 쓰기 오류를 공개해야 합니다.

참고 항목