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

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

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

ONTAP Snapshot 복사본을 사용하여 데이터를 보호하는 방법에는 여러 가지가 있으며, 스냅샷은 복제, 재해 복구, 클론 복제를 포함한 다른 ONTAP 기능의 기반입니다. 스냅샷 기술에 대한 전체 설명은 이 문서의 범위를 벗어나지만 다음 섹션에서는 일반적인 개요를 제공합니다.

데이터 세트의 스냅샷을 생성하는 방법에는 두 가지가 있습니다.

데이터 세트의 장애 발생 시 정합성이 보장되는 백업은 단일 시점의 전체 데이터 세트 구조를 캡처하는 것을 의미합니다. 데이터 세트가 단일 NetApp FlexVol 볼륨에 저장된 경우 프로세스는 간단하며 언제든지 스냅샷을 생성할 수 있습니다. 데이터 세트가 여러 볼륨으로 확장되는 경우에는 정합성 보장 그룹(CG) 스냅샷을 생성해야 합니다. CG 스냅샷을 생성하는 옵션에는 NetApp SnapCenter 소프트웨어, 기본 ONTAP 일관성 그룹 기능, 사용자 유지보수 스크립트 등 여러 가지가 있습니다.

충돌 시에도 정합성 보장 백업은 백업 지점 복구가 충분할 때 주로 사용됩니다. 더 세부적인 복구가 필요한 경우 일반적으로 애플리케이션 정합성이 보장되는 백업이 필요합니다.

"애플리케이션 정합성 보장"에서 "정합성 보장"이라는 단어가 잘못된 표현인 경우가 많습니다. 예를 들어 Oracle 데이터베이스를 백업 모드로 설정하는 것을 애플리케이션 정합성 보장 백업이라고 하지만 데이터가 어떤 식으로든 일관되지 않거나 정지되지 않습니다. 백업 내내 데이터가 계속 변경됩니다. 반면 대부분의 MySQL 및 Microsoft SQL Server 백업은 실제로 백업을 실행하기 전에 데이터를 정지합니다. VMware는 특정 파일의 일관성을 유지할 수도 있고 그렇지 않을 수도 있습니다.

"정합성 보장 그룹"이란 스토리지 배열이 여러 스토리지 리소스를 단일 이미지로 관리하는 기능을 의미합니다. 예를 들어, 데이터베이스는 10개의 LUN으로 구성될 수 있습니다. 스토리지에서 이러한 10개의 LUN을 일관된 방식으로 백업, 복원 및 복제할 수 있어야 합니다. LUN의 이미지가 백업 시점에 일치하지 않으면 복구할 수 없습니다. 이러한 10개의 LUN을 복제하려면 모든 복제본이 서로 완벽하게 동기화되어야 합니다.

ONTAP에 대해 설명할 때는 "일관성 그룹"이라는 용어가 자주 사용되지 않습니다. 왜냐하면 일관성이 항상 ONTAP 내의 볼륨 및 애그리게이트 아키텍처의 기본 기능이기 때문입니다. 다른 많은 스토리지 시스템은 LUN 또는 파일 시스템을 개별 유닛으로 관리합니다. 그런 다음 데이터 보호를 위해 "정합성 보장 그룹"으로 구성할 수도 있지만 이 작업은 구성에 있어 추가 단계입니다.

ONTAP는 항상 일관된 로컬 및 복제된 데이터 이미지를 캡처할 수 있었습니다. ONTAP 시스템의 다양한 볼륨이 일반적으로 공식적으로 일관성 그룹으로 설명되어 있는 것은 아니지만, 그것이 바로 그러한 볼륨입니다. 해당 볼륨의 스냅샷은 일관성 그룹 이미지이고, 해당 스냅샷에 대한 복원은 일관성 그룹 복원이며, SnapMirror 및 SnapVault에서 모두 일관성 그룹 복제를 제공합니다.

일관성 그룹 스냅샷(CG-스냅샷)은 기본 ONTAP 스냅샷 기술의 확장입니다. 표준 스냅샷 작업은 단일 볼륨 내에서 모든 데이터의 일관된 이미지를 생성하지만 여러 볼륨 및 여러 스토리지 시스템에 걸쳐 일관된 스냅샷 세트를 생성해야 하는 경우도 있습니다. 그 결과 하나의 개별 볼륨의 스냅샷과 동일한 방식으로 사용할 수 있는 스냅샷 세트가 생성됩니다. 로컬 데이터 복구에 사용하거나, 재해 복구를 위해 복제하거나, 일관된 단일 유닛으로 복제할 수 있습니다.

CG-스냅샷의 가장 큰 용도는 12개의 컨트롤러를 포함하여 약 1PB의 데이터베이스 환경을 위한 것입니다. 이 시스템에서 생성된 CG 스냅샷이 백업, 복구 및 클론 생성에 사용되었습니다.

대부분의 경우 데이터 세트가 여러 볼륨에 걸쳐 있고 쓰기 순서를 보존해야 하는 경우 선택한 관리 소프트웨어에서 CG 스냅샷이 자동으로 사용됩니다. 이러한 경우 CG-스냅샷의 기술적 세부 사항을 이해할 필요가 없습니다. 그러나 복잡한 데이터 보호 요구 사항이 데이터 보호 및 복제 프로세스를 세부적으로 제어해야 하는 경우도 있습니다. 몇 가지 옵션은 자동화 워크플로우 또는 맞춤형 스크립트를 사용하여 CG-스냅샷 API를 호출하는 것입니다. 최상의 옵션과 CG-스냅샷의 역할을 이해하려면 기술에 대한 자세한 설명이 필요합니다.

CG 스냅샷 세트를 생성하는 프로세스는 2단계로 구성됩니다.

쓰기 펜싱은 연속적으로 설정됩니다. 즉, 펜싱 프로세스가 여러 볼륨에 설정되면 나중에 나타나는 볼륨에 계속 커밋되기 때문에 쓰기 I/O가 시퀀스의 첫 번째 볼륨에 고정됩니다. 이는 처음에 쓰기 순서를 보존해야 하는 요구 사항을 위반하는 것처럼 보일 수 있지만, 이는 호스트에서 비동기식으로 실행되며 다른 쓰기에 의존하지 않는 입출력에만 적용됩니다.

예를 들어, 데이터베이스가 많은 비동기식 데이터 파일 업데이트를 발행하고 운영 체제가 I/O를 재주문하고 자체 스케줄러 구성에 따라 업데이트를 완료할 수 있습니다. 애플리케이션 및 운영 체제에서 쓰기 순서를 유지하기 위한 요구 사항을 이미 해제했기 때문에 이러한 유형의 입출력 순서를 보장할 수 없습니다.

반대의 예로 대부분의 데이터베이스 로깅 작업은 동기적입니다. 입출력이 확인되고 이러한 쓰기 순서가 유지되어야 데이터베이스가 더 이상 로그 쓰기를 진행하지 않습니다. 로그 입출력이 펜싱된 볼륨에 도착하면 로그 입출력이 확인되지 않고 애플리케이션이 추가 쓰기를 차단합니다. 마찬가지로 파일 시스템 메타데이터 I/O는 일반적으로 동기식입니다. 예를 들어 파일 삭제 작업은 손실되지 않아야 합니다. xfs 파일 시스템이 있는 운영 체제에서 파일 및 xfs 파일 시스템 메타데이터를 업데이트한 입출력이 펜싱된 볼륨에 있는 해당 파일에 대한 참조를 제거하기 위해 삭제된 경우 파일 시스템 작업이 일시 중지됩니다. 따라서 CG 스냅샷 작업 중에 파일 시스템의 무결성이 보장됩니다.

대상 볼륨에 쓰기 펜싱이 설정된 후에는 스냅샷을 생성할 준비가 됩니다. 볼륨의 상태가 종속 쓰기 관점에서 고정되므로 스냅샷을 정확하게 동시에 생성할 필요가 없습니다. CG-스냅샷을 생성하는 애플리케이션의 결함을 방지하기 위해 초기 쓰기 펜싱에는 구성 가능한 시간 초과가 포함되어 있습니다. 이 시간 초과는 ONTAP가 자동으로 펜싱을 해제하고 정의된 초 후에 쓰기 처리를 재개합니다. 시간 제한 기간이 만료되기 전에 모든 스냅샷이 생성되면 생성된 스냅샷 세트는 유효한 정합성 보장 그룹입니다.

스냅샷 기반 백업에는 다음과 같은 두 가지 기본 접근 방식이 있습니다.

데이터베이스의 충돌 시에도 정합성 보장 백업은 데이터 파일, 재실행 로그, 제어 파일을 비롯한 전체 데이터베이스 구조를 단일 지점에서 캡처하는 것을 의미합니다. 데이터베이스를 단일 NetApp FlexVol 볼륨에 저장하면 프로세스가 단순해지며 언제든 스냅샷을 생성할 수 있습니다. 데이터베이스가 여러 볼륨으로 확장되는 경우에는 일관성 그룹(CG) 스냅샷을 생성해야 합니다. CG 스냅샷을 생성하는 옵션에는 NetApp SnapCenter 소프트웨어, 기본 ONTAP 일관성 그룹 기능, 사용자 유지보수 스크립트 등 여러 가지가 있습니다.

스냅샷에서 충돌 시에도 정합성 보장 백업은 백업 지점 복구가 충분할 때 주로 사용됩니다. 경우에 따라 아카이브 로그를 적용할 수 있지만 더 세분화된 시점 복구가 필요한 경우에는 온라인 백업을 적용하는 것이 좋습니다.

스냅샷 기반 온라인 백업의 기본 절차는 다음과 같습니다.

이 절차를 따르면 백업 모드의 데이터 파일과 백업 모드 중에 생성된 주요 아카이브 로그가 포함된 스냅샷 세트가 만들어집니다. 데이터베이스를 복구하는 데에는 두 가지 요구사항이 있는데, 편의를 위해 제어 파일 같은 파일도 보호해야 하지만 데이터 파일과 아카이브 로그를 반드시 보호해야 합니다.

고객마다 전략은 다르겠지만 이 전략은 거의 모든 경우에 결국은 아래에 설명된 동일한 원칙에 기반을 두고 수립됩니다.

Oracle 데이터베이스를 위해 볼륨 레이아웃을 설계할 때 첫 번째 내려야 할 결정은 볼륨 기반 NetApp SnapRestore(VBSR) 기술을 사용할 것이냐입니다.

볼륨 기반 SnapRestore는 볼륨을 이전 시점으로 거의 즉시 되돌릴 수 있게 합니다. 볼륨의 모든 데이터를 되돌릴 수 있기 때문에 VBSR은 모든 사용 사례에는 적합하지 않을 수 있습니다. 예를 들어, 데이터 파일, 재실행 로그, 아카이브 로그를 비롯한 전체 데이터베이스가 단일 볼륨에 저장되고 이 볼륨이 VBSR을 통해 복원되는 경우 최신 아카이브 로그와 재실행 데이터가 삭제되기 때문에 데이터가 손실됩니다.

VBSR은 복원이 필요하지 않습니다. 대부분의 경우 파일을 기반으로 SFSR(Single File SnapRestore)을 사용하거나 스냅샷에서 액티브 파일 시스템으로 파일을 복사하여 데이터베이스를 복원할 수 있습니다.

VBSR은 데이터베이스가 대규모이거나 최대한 빨리 복구해야 할 경우에 적용하는 것이 좋으며 VBSR을 사용할 시 데이터 파일을 격리해야 합니다. NFS 환경에서는 다른 유형의 파일에 의해 손상되지 않은 전용 볼륨에 기존 데이터베이스의 데이터 파일을 저장해야 하며 SAN 환경에서는 전용 FlexVol 볼륨의 전용 LUN에 데이터 파일을 저장해야 합니다. Oracle 자동 스토리지 관리(ASM)와 같은 볼륨 관리자를 사용하는 경우 디스크 그룹도 데이터 파일 전용이어야 합니다.

이런 방식으로 데이터 파일을 격리하면 다른 파일 시스템을 손상시키지 않고 이전 상태로 되돌릴 수 있습니다.

SAN 환경에 있는 Oracle 데이터의 각 볼륨에 대해 를 참조하십시오 percent-snapshot-space LUN 환경에서 스냅샷에 대한 공간을 예약하는 것은 유용하지 않으므로 0으로 설정해야 합니다. 부분 예약 공간이 100으로 설정된 경우 LUN이 있는 볼륨의 스냅샷은 전체 데이터의 100% 턴오버를 처리하기 위해 스냅샷 예약 공간을 제외하고 볼륨에서 충분한 여유 공간을 필요로 합니다. 부분 예약이 더 낮은 값으로 설정된 경우 이에 따라 더 적은 양의 여유 공간이 필요하지만 항상 스냅숏 예비 공간이 제외됩니다. 즉, LUN 환경에서 스냅샷 예약 공간이 낭비됩니다.

NFS 환경에는 다음 두 가지 옵션이 있습니다.

첫 번째 옵션으로 percent-snapshot-space 0이 아닌 값(일반적으로 약 20%)으로 설정됩니다. 그러면 이 공간이 사용자로부터 숨겨집니다. 하지만 이 값은 활용률의 한계를 생성하지 않습니다. 20%가 예약된 데이터베이스에서 턴오버가 30%인 경우 스냅샷 공간은 20% 예약이라는 경계를 넘어 확장할 수 있으며 미예약 공간을 점유할 수 있습니다.

예약을 20%와 같은 값으로 설정할 때 얻을 수 있는 가장 큰 이점은 일부 공간이 스냅샷에 항상 사용 가능한지 확인하는 것입니다. 예를 들어, 20%가 예약된 1TB 볼륨의 경우 데이터베이스 관리자(DBA)는 800GB의 데이터만 저장할 수 있을 것입니다. 이 구성은 스냅샷 소비를 위해 최소 200GB의 공간을 보장합니다.

시기 percent-snapshot-space 0으로 설정하면 볼륨의 모든 공간을 최종 사용자가 사용할 수 있어 가시성이 향상됩니다. DBA가 확인했을 때 스냅샷을 활용하는 볼륨이 1TB라면 이 1TB 공간이 액티브 데이터와 스냅샷 턴오버 간에 공유된다는 것을 알아야 합니다.

이 두 옵션 중 최종 사용자가 특별히 선호하는 것은 없습니다.

Oracle Doc ID 604683.1은 타사 스냅샷 지원에 관련된 요구사항과 백업 및 복원 작업에 사용할 수 있는 여러 옵션을 설명합니다.

타사 공급업체는 회사의 스냅샷이 다음과 같은 요구 사항을 준수함을 보증해야 합니다.

ONTAP 및 NetApp Oracle 관리 제품은 이러한 요구사항을 준수합니다.