스냅샷을 데이터 보호 전략으로 사용하는 것에 대해 일반적으로 제기되는 반대 의견 중 하나는 "실제" 데이터와 스냅샷 데이터가 동일한 드라이브에 있다는 것입니다. 이러한 드라이브가 손실되면 기본 데이터와 백업이 모두 손실됩니다.

이는 유효한 문제입니다. 로컬 스냅샷은 일상적인 백업 및 복구 요구에 사용되며 이러한 측면에서 스냅샷은 백업입니다. NetApp 환경의 모든 복구 시나리오 중 거의 99%가 가장 공격적인 RTO 요구 사항까지도 충족하기 위해 스냅샷에 의존합니다.

하지만 로컬 스냅샷만 사용할 수 있는 백업 전략이 되어서는 안 됩니다. 그렇기 때문에 NetApp에서는 스냅샷을 독립 드라이브에 빠르고 효율적으로 복제할 수 있는 SnapMirror 복제 같은 기술을 제공합니다. 스냅샷과 스냅샷 복제를 갖춘 제대로 설계된 솔루션을 사용하면 분기별 아카이브로 테이프 사용을 최소화하거나 완전히 제거할 수 있습니다.

정합성 보장 그룹 백업에는 단일 원자 시점에서 데이터 세트(또는 여러 데이터 세트) 상태를 캡처하는 작업이 포함됩니다. 데이터베이스의 예를 들어, 여기에는 데이터 파일, 로그 파일 같은 모든 데이터베이스 구성 요소와 데이터베이스와 직접 연결된 기타 파일이 포함됩니다. Oracle RDBMS, Microsoft SQL Server, SAP HANA, PostgreSQL, MySQL 및 MariaDB. 정합성 보장 그룹 백업을 사용하여 VMware 구성을 보호하는 것은 유사한 방식으로 모든 데이터 저장소와 ESX 부팅 LUN을 단일 원자적 시점에 캡처하는 것입니다.

이러한 일관성 그룹 스냅샷의 생성은 기본적으로 충돌을 시뮬레이션하기 때문에 이러한 백업을 자주 충돌 시에도 정합성 보장 백업이라고 합니다. 복구 시나리오에 대한 지원과 관련된 문제가 있을 수 있지만 일반적으로 복구 절차가 필요하지 않다는 것을 이해하는 것이 중요합니다. 정합성 보장 그룹 백업을 복원한 후 애플리케이션이 시작되면 일반적인 로그 복구 프로세스, 파일 시스템 저널 재생 및 기타 작업을 수행하여 백업 시점에 전송 중인 모든 입출력을 재생합니다. 그러면 응용 프로그램이 평소와 같이 시작됩니다.

기본적으로, 데이터 손상 없이 전원 장애 또는 서버 충돌을 견딜 수 있는 모든 응용 프로그램은 이러한 방식으로 보호할 수 있습니다. 이러한 작동 방식은 다양한 공급업체의 동기식 및 비동기식 미러링 제품으로 보호되는 엄청난 수의 애플리케이션을 통해 입증될 수도 있습니다. 재해가 갑자기 기본 사이트에 발생하면 복제 사이트에 재해가 발생한 시점의 원래 환경에 대한 일관된 이미지가 포함됩니다. 다시 한 번 특별한 복구 절차가 필요하지 않습니다.

이 접근 방식의 RPO는 일반적으로 백업 지점으로 제한됩니다. 일반적으로 단일 볼륨 스냅샷의 최소 RPO는 1시간입니다. 예를 들어, 48개의 시간별 스냅샷과 30일간의 야간 스냅샷을 사용하는 것이 적절하므로 과도한 수의 스냅샷을 보존할 필요가 없습니다. 1시간 미만의 RPO를 달성하는 것은 어려우므로 먼저 NetApp 프로페셔널 서비스와 상의하여 환경, 확장 및 데이터 보호 요구사항을 파악한 후에는 권장하지 않습니다.

RTO는 일반적으로 몇 초 단위로 측정할 수 있습니다. 응용 프로그램이 종료되고 볼륨이 복구되며 응용 프로그램이 다시 시작됩니다.

가장 간단한 방법은 모든 파일 또는 LUN을 단일 볼륨 정합성 보장 그룹에 배치하는 것입니다. 이렇게 하면 ONTAP에서 직접 스냅샷 생성을 예약할 수 있습니다. 데이터 세트가 여러 볼륨으로 확장되는 경우에는 일관성 그룹 스냅샷(CG-snapshot)이 필요합니다. 이는 System Manager 또는 RESTful API 호출을 사용하여 구성할 수 있으며 SnapCenter은 정의된 볼륨 목록에서 단순한 일관성 그룹 스냅샷을 생성할 수 있습니다.

이 섹션에서는 안전한 오프사이트 스토리지 및 재해 복구를 위해 데이터를 원격 사이트로 복제하는 원격 데이터 보호에 대해 설명합니다. 이 표는 동기 미러링 데이터 보호를 다루지 않습니다. 이 요구 사항에 대해서는 및 를 포함한 NetApp MetroCluster 설명서를 참조하십시오 "MetroCluster""SnapMirror 활성 동기화"

DR RPO는 사용 가능한 네트워크 대역폭 및 보호되는 데이터의 총 크기에 따라 제한됩니다. 초기 베이스라인 전송이 생성된 후 업데이트는 변경된 데이터만 기반으로 하며, 이는 일반적으로 예외가 존재하지만 전체 데이터 공간 중 낮은 비율입니다.

예를 들어, 주간 변경률이 10%인 10TB 데이터베이스의 경우 시간당 평균 약 6GB의 총 변경 사항이 발생합니다. 10GB의 연결을 통해 이 데이터베이스를 전송하는 데 약 6분이 소요됩니다. 변경률은 데이터베이스 변경률의 변동에 따라 다르지만 전체적으로 업데이트 간격이 15분이므로 RPO는 15분 이내여야 합니다. 100개의 데이터베이스가 있는 경우 데이터를 전송하는 데 600분이 필요합니다. 따라서 1시간의 RPO는 불가능합니다. 마찬가지로, 주간 변경률이 10%인 단일 데이터베이스 100TB의 복제본은 1시간 내에 안정적으로 업데이트할 수 없습니다.

복제 오버헤드 및 동시 복제 작업 수 제한 등 추가적인 요인이 복제에 영향을 미칠 수 있습니다. 그러나 사용 가능한 대역폭을 기준으로 단일 볼륨 복제 전략을 전반적으로 계획할 수 있으며 복제 RPO는 일반적으로 1시간으로 달성할 수 있습니다. 1시간 미만의 RPO는 달성하는 것이 더 어려우며 NetApp 프로페셔널 서비스를 상담한 후에만 수행해야 합니다. 사이트 간 네트워크 연결이 매우 양호하여 15분이 걸리는 경우도 있습니다. 그러나 전반적으로 1시간 미만의 RPO가 필요한 경우 다중 볼륨 로그 재생 아키텍처를 통해 더 나은 결과를 얻을 수 있습니다.

재해 복구 시나리오에서 정합성 보장 그룹 복제를 사용하는 RTO는 우수하며 일반적으로 스토리지 관점에서 몇 초 이내에 측정됩니다. 가장 간단한 방법은 단순히 미러를 중단하는 것이며 데이터베이스를 시작할 준비가 된 것입니다. 데이터베이스 시작 시간은 일반적으로 약 10초이지만 트랜잭션이 많이 기록되는 대용량 데이터베이스에는 몇 분이 걸릴 수 있습니다.

RTO를 결정하는 데 있어 가장 중요한 요소는 스토리지 시스템이 아니라 해당 시스템이 실행되는 애플리케이션과 호스트 운영 체제입니다. 예를 들어, 복제된 데이터를 1-2초 내에 사용할 수 있지만 이는 데이터만 나타냅니다. 또한 데이터를 사용하는 데 사용할 수 있는 응용 프로그램 바이너리가 있는 올바르게 구성된 운영 체제도 있어야 합니다.

경우에 따라 고객이 운영 체제에서 미리 발견된 스토리지를 사용하여 재해 복구 인스턴스를 사전에 준비해 둔 경우도 있습니다. 이러한 경우 재해 복구 시나리오를 활성화하려면 미러를 해제하고 애플리케이션을 시작하는 것만으로도 충분합니다. 운영 체제와 관련 애플리케이션이 데이터베이스와 함께 ESX 가상 시스템 디스크(VMDK)로 미러링될 수도 있습니다. 이 경우 애플리케이션을 시작할 수 있도록 VMDK를 신속하게 부팅하기 위해 자동화에 투자한 고객 수에 따라 RPO가 결정됩니다.

보존 시간은 부분적으로 스냅샷 제한에 의해 제어됩니다. 예를 들어, ONTAP의 볼륨은 1,024개의 스냅샷을 포함할 수 있습니다. 경우에 따라 고객은 멀티플렉싱된 복제를 사용하여 제한을 늘렸습니다. 예를 들어 2000일 분량의 백업이 필요한 경우 대체 날짜에 업데이트가 수행되는 두 개의 볼륨에 소스를 복제할 수 있습니다. 이 경우 필요한 초기 공간을 늘려야 하지만 여러 개의 전체 백업이 필요한 기존 백업 시스템보다 훨씬 효율적인 접근 방식을 제공합니다.