본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

NetApp Backup and Recovery의 개체 백업 정책 옵션

10/07/2025 기여자

PDF

NetApp Backup and Recovery를 사용하면 온프레미스 ONTAP 및 Cloud Volumes ONTAP 시스템에 대한 다양한 설정으로 백업 정책을 만들 수 있습니다.

이러한 정책 설정은 개체 저장소 백업에만 적용됩니다. 이러한 설정은 스냅샷이나 복제 정책에 영향을 미치지 않습니다.

참고 NetApp 백업 및 복구 워크로드로 전환하려면 다음을 참조하세요."다양한 NetApp 백업 및 복구 워크로드로 전환" .

백업 일정 옵션

NetApp Backup and Recovery를 사용하면 각 시스템(클러스터)에 대해 고유한 일정을 적용하여 여러 백업 정책을 만들 수 있습니다. 서로 다른 복구 지점 목표(RPO)를 가진 볼륨에 서로 다른 백업 정책을 할당할 수 있습니다.

각 백업 정책에는 백업 파일에 적용할 수 있는 레이블 및 보존 섹션이 제공됩니다. 볼륨에 적용된 스냅샷 정책은 NetApp Backup and Recovery에서 인식하는 정책 중 하나여야 하며, 그렇지 않으면 백업 파일이 생성되지 않습니다.

일정에는 레이블과 보존 값의 두 부분이 있습니다.

*레이블*은 볼륨에서 백업 파일이 생성(또는 업데이트)되는 빈도를 정의합니다. 다음 유형의 라벨 중에서 선택할 수 있습니다.
- 시간별, 일별, 주별, 월별, 연간 기간 중 하나 또는 여러 기간을 조합하여 선택할 수 있습니다.
- 3개월, 1년 또는 7년 동안 백업 및 보존을 제공하는 시스템 정의 정책 중 하나를 선택할 수 있습니다.
- ONTAP System Manager나 ONTAP CLI를 사용하여 클러스터에서 사용자 정의 백업 보호 정책을 만든 경우 해당 정책 중 하나를 선택할 수 있습니다.
보존 값은 각 레이블(기간)에 대해 얼마나 많은 백업 파일을 보존할지 정의합니다. 카테고리나 간격에서 백업의 최대 수에 도달하면 오래된 백업이 제거되어 항상 최신 백업을 보유할 수 있습니다. 또한, 오래된 백업이 클라우드에서 더 이상 공간을 차지하지 않으므로 저장 비용도 절약됩니다.

예를 들어, 7개의 주간 백업과 12개의 월간 백업을 생성하는 백업 정책을 만든다고 가정해 보겠습니다.

매주, 매월 볼륨에 대한 백업 파일이 생성됩니다.
8주차에 첫 번째 주간 백업이 제거되고 8주차의 새로운 주간 백업이 추가됩니다(최대 7개의 주간 백업 유지)
13번째 달에 첫 번째 월별 백업이 제거되고 13번째 달의 새로운 월별 백업이 추가됩니다(최대 12개의 월별 백업 유지)

연간 백업은 개체 스토리지로 전송된 후 소스 시스템에서 자동으로 삭제됩니다. 이러한 기본 동작은 시스템의 고급 설정 페이지에서 변경할 수 있습니다.

DataLock 및 랜섬웨어 보호 옵션

NetApp Backup and Recovery는 볼륨 백업에 대한 DataLock 및 랜섬웨어 보호를 지원합니다. 이러한 기능을 사용하면 백업 파일을 잠그고 검사하여 백업 파일에 랜섬웨어가 있는지 감지할 수 있습니다. 이는 클러스터의 볼륨 백업에 대한 추가 보호가 필요할 때 백업 정책에서 정의할 수 있는 선택적 설정입니다.

이 두 가지 기능은 모두 백업 파일을 보호하여 랜섬웨어 공격 시도가 발생할 경우 항상 유효한 백업 파일에서 데이터를 복구할 수 있도록 합니다. 백업을 잠그고 일정 기간 동안 보관해야 하는 특정 규정 요구 사항을 충족하는 데도 도움이 됩니다. DataLock 및 랜섬웨어 복원력 옵션이 활성화되면 NetApp 백업 및 복구 활성화의 일부로 프로비저닝된 클라우드 버킷에서 개체 잠금 및 개체 버전 관리가 활성화됩니다.

"자세한 내용은 DataLock 및 랜섬웨어 보호 블로그를 참조하세요." .

이 기능은 소스 볼륨에 대한 보호 기능을 제공하지 않으며, 해당 소스 볼륨의 백업에만 보호 기능을 제공합니다. 일부를 사용하세요 "ONTAP 에서 제공하는 랜섬웨어 방지 보호" 소스 볼륨을 보호하세요.

DataLock 및 랜섬웨어 보호 기능을 사용하려는 경우 첫 번째 백업 정책을 만들고 해당 클러스터에 대한 NetApp 백업 및 복구를 활성화할 때 이를 활성화할 수 있습니다. 나중에 NetApp 백업 및 복구 고급 설정을 사용하여 랜섬웨어 검사를 활성화하거나 비활성화할 수 있습니다.
볼륨 데이터를 복원할 때 콘솔이 백업 파일에서 랜섬웨어를 검사하면 백업 파일의 내용에 액세스하기 위해 클라우드 공급자로부터 추가 퇴장 비용이 발생합니다.

DataLock이란 무엇입니까?

이 기능을 사용하면 SnapMirror 통해 클라우드에 복제된 클라우드 스냅샷을 잠글 수 있으며, 랜섬웨어 공격을 감지하고 개체 저장소에서 스냅샷의 일관된 사본을 복구하는 기능을 활성화할 수도 있습니다. 이 기능은 AWS, Azure 및 StorageGRID 에서 지원됩니다.

DataLock은 백업 파일이 일정 기간 동안 수정되거나 삭제되는 것을 방지합니다. 이를 _변경 불가능한 저장소_라고도 합니다. 이 기능은 "객체 잠금"을 위해 객체 스토리지 공급자의 기술을 사용합니다.

클라우드 제공자는 스냅샷 보존 기간을 기준으로 계산되는 보존 기간(RUD)을 사용합니다. 스냅샷 보존 기간은 백업 정책에 정의된 레이블과 보존 횟수를 기준으로 계산됩니다.

최소 스냅샷 보존 기간은 30일입니다. 이것이 어떻게 작동하는지 몇 가지 예를 살펴보겠습니다.

일일 라벨을 선택하고 보존 횟수를 20으로 설정하면 스냅샷 보존 기간은 20일이며, 최소값은 30일로 기본 설정됩니다.
주간 라벨을 선택하고 보존 횟수를 4로 설정하면 스냅샷 보존 기간은 28일이며, 최소값은 30일로 기본 설정됩니다.
월별 라벨을 선택하고 보존 횟수를 3으로 설정하면 스냅샷 보존 기간은 90일입니다.
연간 라벨을 선택하고 보존 횟수를 1로 설정하면 스냅샷 보존 기간은 365일이 됩니다.

보유기간(RUD)은 무엇이고, 어떻게 계산하나요?

보존 기간(RUD)은 스냅샷 보존 기간을 기준으로 결정됩니다. 보존 기간은 스냅샷 보존 기간과 버퍼를 합산하여 계산됩니다.

버퍼는 전송 시간 버퍼(3일) + 비용 최적화 버퍼(28일)로 총 31일이 됩니다.
최소 보존 기간은 30일 + 31일 버퍼 = 61일입니다.

다음은 몇 가지 예입니다.

12개의 보존 기간이 있는 월별 백업 일정을 만들면 백업은 삭제(다음 백업 파일로 대체)되기 전에 12개월(31일 추가) 동안 잠깁니다.
매일 30회, 매주 7회, 매월 12회의 백업을 생성하는 백업 정책을 만들면 3개의 잠긴 보존 기간이 있습니다.
- "30일" 백업은 61일 동안 보관됩니다(30일 + 31일 버퍼).
- "7주" 백업은 11주(7주 + 31일) 동안 보관됩니다.
- "12개월" 백업은 12개월(31일 추가) 동안 보관됩니다.
24개의 보존 기간을 갖는 시간별 백업 일정을 생성하면 백업이 24시간 동안 잠겨 있다고 생각할 수 있습니다. 하지만 최소 기간인 30일보다 짧으므로 각 백업은 61일(30일 + 버퍼 기간 31일) 동안 잠겨 보관됩니다.

DataLock 보존 기간이 만료되면 이전 백업은 삭제되지만, 백업 정책 보존 기간이 만료되면 삭제되지 않습니다.

DataLock 보존 설정은 백업 정책의 정책 보존 설정을 재정의합니다. 백업 파일이 더 오랜 기간 동안 개체 저장소에 저장되므로 저장 비용에 영향을 미칠 수 있습니다.

DataLock 및 랜섬웨어 보호 활성화

정책을 생성할 때 DataLock 및 랜섬웨어 보호 기능을 활성화할 수 있습니다. 정책이 생성된 후에는 이 기능을 활성화, 수정 또는 비활성화할 수 없습니다.

정책을 생성할 때 DataLock 및 랜섬웨어 복원력 섹션을 확장합니다.
다음 중 하나를 선택하세요.
- 없음: DataLock 보호 및 랜섬웨어 복원력이 비활성화되었습니다.
- 잠금 해제: DataLock 보호 및 랜섬웨어 복원력이 활성화되었습니다. 특정 권한이 있는 사용자는 보존 기간 동안 보호된 백업 파일을 덮어쓰거나 삭제할 수 있습니다.
- 잠김: DataLock 보호 및 랜섬웨어 복원력이 활성화되었습니다. 보존 기간 동안 사용자는 보호된 백업 파일을 덮어쓰거나 삭제할 수 없습니다. 이는 규정을 완벽하게 준수하는 것입니다.

"고급 설정 페이지에서 랜섬웨어 보호 옵션을 업데이트하는 방법" .

랜섬웨어 보호란 무엇입니까?

랜섬웨어 보호 기능은 백업 파일을 검사하여 랜섬웨어 공격의 증거를 찾습니다. 랜섬웨어 공격 탐지는 체크섬 비교를 통해 수행됩니다. 이전 백업 파일이 아닌 새로운 백업 파일에서 잠재적인 랜섬웨어가 확인되면, 해당 새로운 백업 파일은 랜섬웨어 공격의 흔적이 없는 가장 최근의 백업 파일로 대체됩니다. (랜섬웨어 공격을 받은 것으로 확인된 파일은 교체된 후 1일 후에 삭제됩니다.)

스캔은 다음과 같은 상황에서 발생합니다.

클라우드 백업 객체에 대한 검사는 클라우드 객체 스토리지로 전송된 직후에 시작됩니다. 백업 파일이 클라우드 저장소에 처음 기록될 때 스캔이 수행되지 않고, 다음 백업 파일이 기록될 때 스캔이 수행됩니다.
랜섬웨어 검사는 복원 프로세스에 백업을 선택하면 시작될 수 있습니다.
언제든지 필요에 따라 스캔을 수행할 수 있습니다.

회수 과정은 어떻게 진행되나요?

랜섬웨어 공격이 감지되면 서비스는 Active Data Console 에이전트 Integrity Checker REST API를 사용하여 복구 프로세스를 시작합니다. 데이터 객체의 가장 오래된 버전이 진실의 원천이며 복구 프로세스의 일부로 현재 버전으로 만들어집니다.

이것이 어떻게 작동하는지 살펴보겠습니다.

랜섬웨어 공격이 발생하면 서비스는 버킷에 있는 객체를 덮어쓰거나 삭제하려고 시도합니다.
클라우드 스토리지는 버전 관리가 가능하므로 백업 개체의 새 버전이 자동으로 생성됩니다. 버전 관리가 켜진 상태에서 객체를 삭제하면 삭제된 것으로 표시되지만 여전히 검색할 수 있습니다. 객체를 덮어쓰면 이전 버전이 저장되고 표시됩니다.
랜섬웨어 검사가 시작되면 두 개체 버전에 대한 체크섬이 검증되고 비교됩니다. 체크섬이 일치하지 않으면 잠재적인 랜섬웨어가 감지된 것입니다.
복구 과정에는 마지막으로 알려진 양호한 사본으로 되돌리는 작업이 포함됩니다.

지원되는 시스템 및 개체 스토리지 공급자

다음 퍼블릭 및 프라이빗 클라우드 공급자의 개체 스토리지를 사용하는 경우 다음 시스템의 ONTAP 볼륨에서 DataLock 및 랜섬웨어 보호를 활성화할 수 있습니다.

소스 시스템	백업 파일 대상 ifdef::aws[]
AWS의 Cloud Volumes ONTAP	아마존 S3 endif::aws[] ifdef::azure[]
Azure의 Cloud Volumes ONTAP	Azure Blob endif::azure[] ifdef::gcp[]
Google Cloud의 Cloud Volumes ONTAP	구글 클라우드 endif::gcp[]
온프레미스 ONTAP 시스템	ifdef::aws[] Amazon S3 endif::aws[] ifdef::azure[] Azure Blob endif::azure[] ifdef::gcp[] Google Cloud endif::gcp[] NetApp StorageGRID

소스 시스템

백업 파일 대상 ifdef::aws[]

AWS의 Cloud Volumes ONTAP

아마존 S3 endif::aws[] ifdef::azure[]

Azure의 Cloud Volumes ONTAP

Azure Blob endif::azure[] ifdef::gcp[]

Google Cloud의 Cloud Volumes ONTAP

구글 클라우드 endif::gcp[]

온프레미스 ONTAP 시스템

ifdef::aws[] Amazon S3 endif::aws[] ifdef::azure[] Azure Blob endif::azure[] ifdef::gcp[] Google Cloud endif::gcp[] NetApp StorageGRID

요구 사항

AWS의 경우:
- 클러스터는 ONTAP 9.11.1 이상을 실행해야 합니다.
- 콘솔 에이전트는 클라우드나 사내에 배포될 수 있습니다.
- 다음 S3 권한은 콘솔 에이전트에 권한을 제공하는 IAM 역할의 일부여야 합니다. 이들은 리소스 "arn:aws:s3:::netapp-backup-*"의 "backupS3Policy" 섹션에 있습니다.
  AWS S3 권한
  s3:GetObjectVersionTagging
  
  s3:GetBucketObjectLockConfiguration
  
  s3:GetObjectVersionAcl
  
  s3:PutObjectTagging
  
  s3:객체 삭제
  
  s3:객체태깅 삭제
  
  s3:객체 보존 가져오기
  
  s3:DeleteObjectVersionTagging
  
  s3:객체 넣기
  
  s3:객체 가져오기
  
  s3:PutBucketObjectLock구성
  
  s3:수명주기구성 가져오기
  
  s3:버킷태깅 가져오기
  
  s3:객체 버전 삭제
  
  s3:리스트버킷버전
  
  s3:리스트버킷
  
  s3:PutBucket태깅
  
  s3:객체태깅 가져오기
  
  s3:PutBucketVersioning
  
  s3:PutObjectVersionTagging
  
  s3:버킷 버전 가져오기
  
  s3:GetBucketAcl
  
  s3:바이패스거버넌스보존
  
  s3:객체 보존 넣기
  
  s3:버킷 위치 가져오기
  
  s3:객체 버전 가져오기
  "필요한 권한을 복사하여 붙여넣을 수 있는 정책에 대한 전체 JSON 형식을 확인하세요." .
Azure의 경우:
- 클러스터는 ONTAP 9.12.1 이상을 실행해야 합니다.
- 콘솔 에이전트는 클라우드나 사내에 배포될 수 있습니다.
Google Cloud의 경우:
- 클러스터는 ONTAP 9.17.1 이상을 실행해야 합니다.
- 콘솔 에이전트는 클라우드나 사내에 배포될 수 있습니다.
StorageGRID 의 경우:
- 클러스터는 ONTAP 9.11.1 이상을 실행해야 합니다.
- StorageGRID 시스템은 11.6.0.3 이상을 실행해야 합니다.
- 콘솔 에이전트는 귀하의 구내에 배포되어야 합니다(인터넷 접속이 가능한 사이트나 불가능한 사이트에 설치 가능)
- 다음 S3 권한은 콘솔 에이전트에 권한을 제공하는 IAM 역할의 일부여야 합니다.
  StorageGRID S3 권한
  s3:GetObjectVersionTagging
  
  s3:GetBucketObjectLockConfiguration
  
  s3:GetObjectVersionAcl
  
  s3:PutObjectTagging
  
  s3:객체 삭제
  
  s3:객체태깅 삭제
  
  s3:객체 보존 가져오기
  
  s3:DeleteObjectVersionTagging
  
  s3:객체 넣기
  
  s3:객체 가져오기
  
  s3:PutBucketObjectLock구성
  
  s3:수명주기구성 가져오기
  
  s3:버킷태깅 가져오기
  
  s3:객체 버전 삭제
  
  s3:리스트버킷버전
  
  s3:리스트버킷
  
  s3:PutBucket태깅
  
  s3:객체태깅 가져오기
  
  s3:PutBucketVersioning
  
  s3:PutObjectVersionTagging
  
  s3:버킷 버전 가져오기
  
  s3:GetBucketAcl
  
  s3:객체 보존 넣기
  
  s3:버킷 위치 가져오기
  
  s3:객체 버전 가져오기

제한

백업 정책에서 보관 저장소를 구성한 경우 DataLock 및 랜섬웨어 보호 기능을 사용할 수 없습니다.
NetApp 백업 및 복구를 활성화할 때 선택하는 DataLock 옵션은 해당 클러스터의 모든 백업 정책에 사용해야 합니다.
단일 클러스터에서 여러 DataLock 모드를 사용할 수 없습니다.
DataLock을 활성화하면 모든 볼륨 백업이 잠깁니다. 단일 클러스터에 대해 잠긴 볼륨 백업과 잠기지 않은 볼륨 백업을 혼합할 수 없습니다.
DataLock 및 랜섬웨어 보호는 DataLock 및 랜섬웨어 보호가 활성화된 백업 정책을 사용하여 새 볼륨 백업에 적용할 수 있습니다. 나중에 고급 설정 옵션을 사용하여 이러한 기능을 활성화하거나 비활성화할 수 있습니다.
FlexGroup 볼륨은 ONTAP 9.13.1 이상을 사용할 때만 DataLock 및 랜섬웨어 보호 기능을 사용할 수 있습니다.

DataLock 비용을 완화하는 방법에 대한 팁

DataLock 기능을 활성화한 상태에서 랜섬웨어 검사 기능을 활성화하거나 비활성화할 수 있습니다. 추가 요금을 피하려면 예약된 랜섬웨어 검사를 비활성화할 수 있습니다. 이를 통해 보안 설정을 사용자 정의하고 클라우드 제공업체로부터 비용이 발생하는 것을 방지할 수 있습니다.

예약된 랜섬웨어 검사가 비활성화된 경우에도 필요할 때 주문형 검사를 수행할 수 있습니다.

다양한 수준의 보호를 선택할 수 있습니다.

랜섬웨어 검사 없는 DataLock: 거버넌스 또는 규정 준수 모드에 있는 대상 저장소의 백업 데이터를 보호합니다.
- 거버넌스 모드: 관리자가 보호된 데이터를 덮어쓰거나 삭제할 수 있는 유연성을 제공합니다.
- 준수 모드: 보존 기간이 만료될 때까지 완전한 삭제 불가성을 제공합니다. 이는 엄격하게 규제되는 환경의 가장 엄격한 데이터 보안 요구 사항을 충족하는 데 도움이 됩니다. 데이터는 수명 주기 동안 덮어쓰거나 수정될 수 없으므로 백업 사본에 대한 가장 강력한 수준의 보호가 제공됩니다.
  
  Microsoft Azure는 대신 잠금 및 잠금 해제 모드를 사용합니다.
랜섬웨어 검사 기능이 있는 DataLock: 데이터에 대한 보안을 한층 더 강화합니다. 이 기능은 백업 사본을 변경하려는 시도를 감지하는 데 도움이 됩니다. 어떠한 시도가 이루어지면 데이터의 새로운 버전이 신중하게 생성됩니다. 검사 빈도는 1, 2, 3, 4, 5, 6, 7일로 변경할 수 있습니다. 검사 주기를 7일로 설정하면 비용이 상당히 줄어듭니다.

DataLock 비용을 완화하기 위한 추가 팁은 다음을 참조하세요.https://community.netapp.com/t5/Tech-ONTAP-Blogs/Understanding-NetApp-Backup-and-Recovery-DataLock-and-Ransomware-Feature-TCO/ba-p/453475[]

또한 DataLock과 관련된 비용에 대한 견적은 다음을 방문하여 얻을 수 있습니다. "NetApp 백업 및 복구 총소유비용(TCO) 계산기" .

보관 저장 옵션

AWS, Azure 또는 Google 클라우드 스토리지를 사용하는 경우 특정 기간이 지나면 오래된 백업 파일을 비용이 덜 드는 보관 스토리지 클래스 또는 액세스 계층으로 옮길 수 있습니다. 표준 클라우드 저장소에 쓰지 않고도 백업 파일을 즉시 보관 저장소로 보내도록 선택할 수도 있습니다. 백업 파일을 보관 저장소로 직접 보내려면 "보관 후 일수"에 *0*을 입력하세요. 이 기능은 클라우드 백업 데이터에 거의 액세스할 필요가 없는 사용자나 테이프 백업 솔루션을 교체하는 사용자에게 특히 유용할 수 있습니다.

보관 계층의 데이터는 필요할 때 즉시 액세스할 수 없으며 검색 비용이 더 많이 들기 때문에 백업 파일을 보관하기로 결정하기 전에 백업 파일에서 데이터를 복원해야 하는 빈도를 고려해야 합니다.

모든 데이터 블록을 보관 클라우드 스토리지로 보내도록 "0"을 선택하더라도 메타데이터 블록은 항상 표준 클라우드 스토리지에 기록됩니다.
DataLock을 활성화한 경우 보관 저장소를 사용할 수 없습니다.
*0*일(즉시 보관)을 선택한 후에는 보관 정책을 변경할 수 없습니다.

각 백업 정책은 백업 파일에 적용할 수 있는 보관 정책 섹션을 제공합니다.

AWS에서 백업은 Standard 스토리지 클래스에서 시작하여 30일 후에 Standard-Infrequent Access 스토리지 클래스로 전환됩니다.

클러스터가 ONTAP 9.10.1 이상을 사용하는 경우 이전 백업을 S3 Glacier 또는 S3 Glacier Deep Archive 스토리지로 계층화할 수 있습니다. "AWS 보관 스토리지에 대해 자세히 알아보세요" .
- NetApp 백업 및 복구를 활성화할 때 첫 번째 백업 정책에서 보관 계층을 선택하지 않으면 _S3 Glacier_가 향후 정책에 대한 유일한 보관 옵션이 됩니다.
- 첫 번째 백업 정책에서 S3 Glacier_를 선택하면 해당 클러스터의 향후 백업 정책에 대해 _S3 Glacier Deep Archive 계층으로 변경할 수 있습니다.
- 첫 번째 백업 정책에서 _S3 Glacier Deep Archive_를 선택하면 해당 계층은 해당 클러스터의 향후 백업 정책에 사용할 수 있는 유일한 아카이브 계층이 됩니다.
Azure에서 백업은 Cool 액세스 계층과 연결됩니다.

클러스터가 ONTAP 9.10.1 이상을 사용하는 경우 이전 백업을 Azure Archive 저장소로 계층화할 수 있습니다. "Azure 보관 저장소에 대해 자세히 알아보세요" .
GCP에서 백업은 Standard 스토리지 클래스와 연결됩니다.

온프레미스 클러스터에서 ONTAP 9.12.1 이상을 사용하는 경우, NetApp 백업 및 복구 UI에서 특정 기간 후에 이전 백업을 아카이브 스토리지로 계층화하여 비용을 더욱 최적화할 수 있습니다. "Google 보관 저장소에 대해 자세히 알아보세요" .
StorageGRID 에서 백업은 Standard 스토리지 클래스와 연결됩니다.

온프레미스 클러스터에서 ONTAP 9.12.1 이상을 사용하고 StorageGRID 시스템에서 11.4 이상을 사용하는 경우 이전 백업 파일을 퍼블릭 클라우드 보관 스토리지에 보관할 수 있습니다.

+ ** AWS의 경우 AWS S3 Glacier 또는 S3 Glacier Deep Archive 스토리지에 백업을 계층화할 수 있습니다. "AWS 보관 스토리지에 대해 자세히 알아보세요" .

+ ** Azure의 경우 이전 백업을 Azure Archive 저장소로 계층화할 수 있습니다. "Azure 보관 저장소에 대해 자세히 알아보세요" .