NetApp 스냅 샷을 백업으로 사용할 수 있습니까?

우리 상점은 백업을 위해 NetApp Volume Snapshots에 크게 의존합니다. 우리는 일부 데이터에 대해 전통적인 에이전트 기반 테이프 백업을 사용 하지만 대체로 대부분의 시스템에 대한 스냅 샷에 의존합니다. 또한 우리는 너무 엄격한 변경 관리 정책이나 중앙 구성 관리를하지 않아도 모든서비스 제공 데이터의 백업 여부에 관계없이 당사의 서버 중 일부는 베어 메탈 (실제 문서화없이)에서 재구성해야합니다. 당연히 스냅 샷은 포함 된 전체 서버, 사용자 데이터 및 구성 만 복구 할 수 있기 때문에 관리에 매우 매력적인 제안입니다. NetApp의 가상 스토리지 콘솔을 사용하여 NFS 기반 VMware 데이터 저장소의 스냅 샷을 작성하고 게스트에 직접 제공되는 원시 장치 매핑 (물리적) LUN에 대한 NetApp의 SnapDrive를 사용합니다. 우리는 다른 Filer에 오프 사이트로 중요한 Snapshot을 SnapMirror합니다. 당연히 복원 프로세스를 정기적으로 테스트합니다.

백업 스냅 샷에 대한 의존으로 불편을 느끼지만 도와 드릴 수는 없습니다. 나에게있어 기술이 백업 전략으로 충분하다고 생각하려면 다음 기준을 충족해야합니다.

• 백업은 원 자성이어야합니다. 즉, 백업은 복구를 위해 다른 것에 의존 할 수 없습니다.
• 백업은 대역 외의 백업 인 시스템과 분리해야합니다.
• 백업을 원격 사이트 (오프 사이트)로 복사하거나 전송해야합니다.

NetApp Snapshots는 RoW (Redirect-On-Write) 방법으로 작동한다는 것을 이해하고 있습니다. WAFL의 파일 레이아웃 실제로는있을 이제까지 저장의 각각의 블록을 참조 포인터 세트 (메타?)를 사용한다. 스냅 샷을 만들기 위해 시스템은 볼륨의 메타 데이터 사본을 가져 와서 해당 볼륨의 예약 된 공간에 저장합니다. 모든 쓰기 (생성 / 변경 / 삭제)는 새 블록으로 리디렉션됩니다. 이것은 NetApp의 WAFL을 매우 훌륭하게 만드는 특별한 소스입니다. 읽기를하지 않고 이전 데이터를 예약 된 공간에 쓴 다음 새 데이터를 기존의 Copy-On-Write 스냅 샷과 같이 쓸 수 있기 때문입니다.

NetApp Volume Snapshots의 작동 방식을 정확히 이해하지 못할 수도 있지만 이해가 다소 정확한 경우 NetApp Snapshots가 백업 기준을 충족시키지 못합니다.

• 그들은 원자가 아닙니다 . "스냅 샷"은 실제로 원본 데이터에 대한 포인터 집합입니다. 원본 데이터가 더 이상 존재하지 않으면 메타 데이터가 쓸모가 없습니다.
• 스냅 샷이 시스템에서 분리되지 않았습니다. 누군가 잘못된 볼륨을 삭제하면 스냅 샷이 손실됩니다. NetApp Filer가 작은 새끼 고양이로 폭발하면 백업이 손실됩니다. SnapMirror를 사용하여 스냅 샷을 다른 Filer로 옮길 수 있지만 다시는 실제 블록이 아닌 메타 데이터를 이동시키는 것입니다. 원래 볼륨을 잃어버린 경우 다른 Filer에 복사 된 스냅 샷이 어떻게 도움이되는지 알 수 없습니다.

누군가 NetApp 스냅 샷을 백업으로 간주하는 방법을 설명 할 수 있습니까? 나는 좋은 주관적인 답변을 찾고 있습니다. 사실, 언급 및 경험으로 귀하의 입장을 지원하십시오. 기본 기술에 대한 이해가 정확하지 않은 경우 내 결론이 바뀌는 위치와 이유를 설명하십시오. 상점에서 백업으로 NetApp Snapshots를 사용하는 경우, 사람들이 어떤 종류의 복구 정책을 충족해야하는지에 대한 충분한 컨텍스트 정보를 포함하십시오.

백업은 두 가지 기능을 제공합니다.

• 무엇보다도 데이터를 사용할 수 없게되면 데이터를 복구 할 수 있습니다. 이런 의미에서 스냅 샷은 백업이 아닙니다. 파일러의 데이터가 손실되면 (볼륨 삭제, 스토리지 손상, 펌웨어 오류 등) 해당 데이터에 대한 모든 스냅 샷도 사라집니다.
• 둘째, 훨씬 일반적으로 백업은 실수로 삭제하는 등의 일상적인 문제를 해결하는 데 사용됩니다. 이 사용 사례에서 스냅 샷 은 백업입니다. 그들은 이러한 종류의 복구를 제공하는 가장 좋은 방법 중 하나 일 것입니다. 이전 버전의 데이터를 사용자 나 OS에서 직접 파일을 읽을 수있는 .snapshot 숨겨진 디렉토리로 사용할 수 있기 때문입니다.

보존 정책 없음

즉, 우리는 스냅 샷을 가지고 광범위하게 사용하면서도 Netbackup에서 테이프 또는 데이터 도메인에 대한 야간 증분을 수행합니다. 스냅 샷이 보존 정책을 안정적으로 유지할 수 없기 때문입니다. 사용자에게 일주일 동안 일일 세부 단위에서 한 달 동안 주 단위로 백업 할 수 있다고 알려 주면 스냅 샷으로 약속을 지킬 수 없습니다.

스냅 샷이있는 Netapp 볼륨에서 스냅 샷에 포함 된 삭제 된 데이터는 "스냅 예약"공간을 차지합니다. 볼륨이 가득 차지 않고이 방법으로 구성한 경우 해당 스냅 샷 예약을 지나서 스냅 샷이 사용되지 않은 일부 데이터 공간을 차지하도록 할 수도 있습니다. 그러나 볼륨이 가득 차면 예약 된 공간의 데이터가 지원하는 스냅 샷을 제외한 모든 스냅 샷이 삭제됩니다. 스냅 샷 삭제는 사용 가능한 스냅 샷 공간에 의해서만 결정 되며 보존 정책에 필요한 스냅 샷을 삭제해야하는 경우 스냅 샷이 삭제됩니다.

이 상황을 고려하십시오.

• 정기적 인 스냅 샷과 2 주 보존 요구 사항이 포함 된 전체 볼륨.
• 정상적인 변경 비율에 따라 스냅 샷에 사용중인 예약의 절반을 가정합니다.
• 누군가가 많은 데이터 (스냅 샷 예약보다 많은 데이터)를 삭제하여 일시적으로 변경 속도를 크게 증가시킵니다.

이 시점에서 OnTap이 스냅 샷에 사용하도록 허용 한 데이터 여유 공간만큼이나 스냅 샷 예약이 완전히 사용되었지만 아직 스냅 샷을 잃지 않았습니다. 그러나 누군가가 볼륨을 데이터로 백업하는 즉시 데이터 섹션에 포함 된 모든 스냅 샷이 손실되므로 큰 삭제 직후 복구 지점이 다시 시작됩니다.

요약

Netapp 스냅 샷은 실제 데이터 손실에 대해 다루지 않습니다. 파일러에서 잘못된 삭제 된 볼륨 또는 데이터 손실이 발생하면 데이터를 다시 작성해야합니다.

간단한 일상 복원을 허용하는 매우 간단하고 우아한 방법이지만 실제 백업 솔루션을 대체 할만큼 충분히 신뢰할 수는 없습니다. 대부분의 경우, 일상적인 복원을 간단하고 쉽게 수행 할 수 있지만 사용할 수없는 경우 노출됩니다.

그들은이다 예, 백업. 나는 이전에 일일 증분 대신 개인적으로 사용했지만 여전히 테이프에 매주 찼습니다.

Netapp 이외의 (볼륨에 액세스하는 시스템) 사용자 또는 관리자 오류나 문제로부터 상당히 잘 보호합니다.

netapp 자체의 치명적인 하드웨어 오류로부터 보호하지 않습니다. SnapMirror는 모든 데이터 (스냅 샷의)를 다른 파일러에 복사하므로 [1] 다른 파일러로 SnapMirroring하면 해당 데이터 세트가 단일 파일러의 치명적인 오류로부터 보호되어야합니다.

물론 한 가지 주요 문제는 netapp를 관리하는 누군가가 볼륨을 삭제하면 모든 스냅 샷이 함께 이동한다는 것입니다. 다른 파일러에 대한 SnapMirror는이를 적절히 보호해야합니다.

모든 NetApp 파일러가 동일한 데이터 센터에있는 경우 오프 사이트로 테이프 테이프 백업을 제공하는 방식으로 중대한 재난을 다루는 항목이 없습니다.

적절한 SnapManager 에이전트를 사용하면 스냅 샷을 작성할 때 데이터 일시 정지를 간단히 조정하는 VM 및 모든 데이터베이스 (또는 데이터베이스와 유사한 것)를 더 잘 백업 할 수 있습니다. 지정된 VM과 해당 데이터가 단일 NetApp 볼륨 내에 완전히 포함되어 있으면 해당 VM의 스냅 샷이 충돌 일관성이 있어야합니다. 즉, 서버에서 플러그를 뽑고 드라이브를 이미지화 한 것처럼 좋을 것입니다. 이는 일반적으로 파일 시스템 검사 및 데이터베이스에 해당하는 것을 의미합니다. 데이터베이스의 데이터가 LUN간에 분할 된 경우 데이터가 손상 될 위험이있는 것 같습니다.

그것이 나라면 모든 데이터베이스를 로컬 디스크에 정기적으로 백업하도록 설정하고 사본을 두 개 보관하도록 해당 작업을 설정했습니다. 이를 통해 복구 가능성이 훨씬 향상됩니다.

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

@Basil 의 훌륭한 답변을 읽으 십시오. 그러나 여기에는 2 센트가 있습니다.

스냅 샷은 응용 프로그램을 인식하지 못합니다

기본 스토리지 볼륨의 스냅 샷을 생성한다고해서 해당 볼륨의 데이터를 복구 할 수있는 것은 아닙니다. MS SQL은 이에 대한 좋은 예입니다. @freiheit이 언급 한 것처럼 하드 디스크 장애로부터 복구하는 것보다 낫지 않다고 언급 한 것처럼 스토리지를 스냅 샷하기 전에 데이터베이스가 트랜잭션과 일관성이 있는지 확인해야합니다 . DBA는 스토리지 시스템, 빠른 스토리지의 임시 데이터베이스, 느린 스토리지의 시스템 데이터베이스, 대량 스토리지의 읽기 전용 또는 아카이브 된 데이터 및 그 사이의 작업 데이터를보다 잘 활용하기 위해 SQL의 다른 부분에 다른 LUN을 사용하는 것을 좋아합니다. 해당 볼륨을 스냅 샷하는 경우 데이터베이스를 복구 할 가능성 이 거의 없습니다.

NetApp은 스냅 샷 응용 프로그램을 인식 할 수 있도록 다양한 스냅 도구를 제공합니다. SnapManager for SQL은 그러한 인식을 제공합니다. Microsoft 에코 시스템에는 Exchange 및 SharePoint 용 SnapManager 도구도 있다고 생각합니다. SnapDrive에는이 응용 프로그램 인식 기능이 없습니다. 게스트 내에서 스토리지를 관리하는 편리한 방법 만 제공합니다.

모든 IIS 데이터와 구성을 LUN에 저장하고 해당 LUN을 직접 스냅 샷하는 경우 데이터를 복구 할 수 있다고 보장 할 수 없습니다. 내가 어떻게 알아?

여러 스토리지 유형에 따라 스냅 샷 일정이 다를 수 있습니다

다른 방법으로 서버에 스토리지를 제공하는 경우 스냅 샷 및 복구 그림이 복잡해질 수 있습니다. NetApp의 ONTAP은 다중 프로토콜 오퍼링이며 특정 서버에 둘 이상의 방법 또는 스토리지 유형을 사용하고있을 가능성이 큽니다. 우리 매장에서는 일부 서버가 NFS 기반 데이터 저장소를 통한 C : \ 드라이브와 원시 장치 매핑 된 LUN을 통한 "스토리지"드라이브를 얻습니다. NFS 기반 데이터 스토어가 아닌 RDM LUN의 스냅 샷을 생성했습니다. 이로 인해 서버 복구가 어려워졌습니다.

스냅 샷에는 보장 된 보존 정책이 없습니다.

다시 말하지만 @Basil은 실제로 이것을 잘 다루지 만 반복 할 가치가 있습니다. Snpashot Autodelete가 자연스럽게 삭제되지 않은 스냅 샷을 제거하는 방식으로 Snap Reserve를 채울 수 있습니다. 다시. 귀하 또는 귀하의 고객이 3 주간의 스냅 샷을 사용할 수있을 것으로 예상하는 경우 이는 매우 나쁠 수 있습니다.

스냅 샷이 인라인입니다

이것은 통합 스토리지의 단점입니다. 잘 ... 통합되었습니다. 스냅 샷은 백업하는 동일한 플랫폼에 있습니다. 볼륨이나 파일러가 켜져 있으면 백업도 사라집니다. 내 질문에서 SnapMirror 사본이 전체 사본이 아니라고 잘못 언급 한 것처럼 SnapMirror를 사용하여 스냅 샷을 다른 Filer에 복사하여이를 완화 할 수 있습니다.

나쁜 운영 관행을 계속 유지하는 스냅 샷

내가 주목 한 것은 관리자와 고객이 스냅 샷을 통해 끔찍한 작업 동작을 계속할 수 있다는 것입니다. 우리 환경에서는 문서 및 구성 관리 방법이 매우 좋지 않습니다. 즉, 대부분의 서버는 동일한 기본 (템플릿 또는 이미지)으로 시작하지만 다른 그룹의 사람들이 수동으로 구성합니다. 서버의 수명이 계속되면 서버는 일반적으로 구성 관리를 통해 문서화되거나 구현되지 않은 방식으로 템플릿에서 멀어집니다.

그리고 스냅 샷을 찍으세요! 모든 서버를 스냅 샷 할 수 있기 때문에 기본적인 운영 관행 중 일부를 물러서지 않아도됩니다! 또한 SnapMirror를 사용하여 해당 스냅 샷을 오프 사이트로 이동하여 백업으로 사용할 수 있습니다!

나는 이것이 여기서 배우는 잘못된 교훈이라고 생각합니다. 더 좋은 교훈은 구성 관리 프레임 워크가 변경 로그처럼 단순하더라도 완전 복원을 위해 백업되어야한다는 것입니다. 스냅 샷은 훌륭한 도구이지만 중요한 기본 요소를 억제하는 데 지나치게 의존하고 싶은 유혹이 있습니다.