SnapCenter는 서로 다른 Oracle 데이터베이스 구성의 백업을 지원합니다.

지원되는 Oracle 버전에 대한 최신 정보는 를 참조하십시오 "NetApp 상호 운용성 매트릭스 툴".

백업 유형은 생성할 백업 유형을 지정합니다. SnapCenter는 Oracle 데이터베이스에 대한 온라인 및 오프라인 백업 유형을 지원합니다.

"리소스"는 SnapCenter에서 유지 관리하는 호스트의 Oracle 데이터베이스입니다. 사용 가능한 데이터베이스를 발견한 후 이러한 데이터베이스를 리소스 그룹에 추가하여 데이터 보호 작업을 수행할 수 있습니다. SnapCenter에서 다양한 유형과 버전의 Oracle 데이터베이스를 검색하기 위해 수행하는 프로세스에 대해 알고 있어야 합니다.

Oracle RAC(Real Application Clusters) 설정에서 백업 작업을 수행할 기본 노드를 지정할 수 있습니다. 기본 설정 노드를 지정하지 않으면 SnapCenter가 노드를 기본 설정 노드로 자동 할당하고 해당 노드에 백업이 생성됩니다.

선호하는 노드는 RAC 데이터베이스 인스턴스가 있는 클러스터 노드 중 하나 또는 모두가 될 수 있습니다. 백업 작업은 기본 설정 순서대로 이러한 기본 설정 노드에서만 트리거됩니다.

예: RAC 데이터베이스 cdbrac에는 node1의 cdbrac1, node2의 cdbrac2, node3의 cdbrac3 등 세 개의 인스턴스가 있습니다. 노드 1과 노드 2 인스턴스는 노드 2가 첫 번째 기본 설정이고 노드 1이 두 번째 기본 설정인 기본 노드로 구성됩니다. 백업 작업을 수행할 때 노드 2가 첫 번째 기본 설정 노드이므로 이 작업이 먼저 시도됩니다. 플러그인 에이전트가 호스트에서 실행되고 있지 않은 등의 여러 가지 이유로 인해 노드 2가 백업할 상태가 아닌 경우 호스트의 데이터베이스 인스턴스가 지정된 백업 유형에 대해 필요한 상태가 아닌 경우 또는 FlexASM 구성에서 노드 2의 데이터베이스 인스턴스를 로컬 ASM 인스턴스에서 제공하지 않으면 노드 1에서 작업을 시도합니다. 노드 3은 기본 노드 목록에 없으므로 백업에 사용되지 않습니다.

Flex ASM 설정에서 카디널리티가 RAC 클러스터의 노드 수보다 적은 경우 Leaf 노드가 기본 노드로 표시되지 않습니다. Flex ASM 클러스터 노드 역할이 변경된 경우 원하는 노드가 새로 고쳐지도록 수동으로 검색해야 합니다.

Oracle 데이터베이스 백업은 Oracle RMAN(Recovery Manager)으로 카탈로그를 작성해서 Oracle RMAN 저장소에 백업 정보를 저장할 수 있습니다.

나중에 블록 레벨 복구 또는 테이블스페이스 시점 복구 작업에 카탈로그 작성된 백업을 사용할 수 있습니다. 이러한 카탈로그 작성된 백업이 필요하지 않은 경우 카탈로그 정보를 제거할 수 있습니다.

카탈로그를 작성하려면 데이터베이스가 마운트됨 또는 상위 상태여야 합니다. 데이터 백업, 아카이브 로그 백업 및 전체 백업에 대한 카탈로그를 작성할 수 있습니다. 여러 데이터베이스가 있는 리소스 그룹의 백업에 대해 카탈로그 작성을 사용하는 경우 각 데이터베이스에 대해 카탈로그가 수행됩니다. Oracle RAC 데이터베이스의 경우 데이터베이스가 마운트된 상태 이상인 기본 노드에서 카탈로그가 수행됩니다.

기본적으로 대상 데이터베이스 컨트롤 파일은 카탈로그로 사용됩니다. 외부 카탈로그 데이터베이스를 추가하려면 SnapCenter 그래픽 사용자 인터페이스(GUI)의 데이터베이스 설정 마법사를 사용하여 외부 카탈로그의 자격 증명 및 TNS(투명 네트워크 기판) 이름을 지정하여 데이터베이스를 구성할 수 있습니다. 또한 CLI에서 -OracleRmanCatalogCredentialName 및 -OracleRmanCatalogTnsName 옵션과 함께 Configure-SmOracleDatabase 명령을 실행하여 외부 카탈로그 데이터베이스를 구성할 수도 있습니다.

SnapCenter GUI에서 Oracle 백업 정책을 생성하는 동안 카탈로그 작성 옵션을 활성화한 경우, 백업 작업의 일부로 Oracle RMAN을 사용하여 백업 카탈로그를 작성합니다. Catalog-SmBackupWithOracleRMAN 명령을 실행하여 지연된 백업 카탈로그를 수행할 수도 있습니다. 백업을 카탈로그로 작성한 후 Get-SmBackupDetails 명령을 실행하여 카탈로그 작성된 데이터 파일의 태그, 제어 파일 카탈로그 경로, 카탈로그 작성된 아카이브 로그 위치 등과 같은 카탈로그 작성된 백업 정보를 가져올 수 있습니다.

SnapCenter 3.0에서 ASM 디스크 그룹 이름이 16자 이상인 경우 백업에 사용되는 명명 형식은 SC_HASHCODEofDISKGROUP_DBSID_BACKUPID입니다. 그러나 디스크 그룹 이름이 16자 미만인 경우 백업에 사용되는 명명 형식은 DISKGROUPNAME_DBSID_BACKUPID이며, 이는 SnapCenter 2.0에서 사용되는 것과 동일한 형식입니다.

교차 검사를 수행하여 리포지토리 레코드가 물리적 상태와 일치하지 않는 백업에 대한 오래된 RMAN 리포지토리 정보를 업데이트할 수 있습니다. 예를 들어, 사용자가 운영 체제 명령을 사용하여 디스크에서 아카이빙된 로그를 제거할 경우, 제어 파일은 로그가 디스크에 있음을 계속 표시합니다(실제로는 그렇지 않음). crosscheck 작업을 사용하면 제어 파일을 정보로 업데이트할 수 있습니다. Set-SmConfigSettings 명령을 실행하고 enable_crosscheck 매개 변수에 true 값을 할당하여 크로스검사를 활성화할 수 있습니다. 기본값은 false 로 설정됩니다.

'sccli Set-SmConfigSettings-ConfigSettingsTypePlugin-PluginCodeSCO-ConfigSettings' key=enable_crosscheck,value=true"

Uncatalog-SmBackupWithOracleRMAN 명령을 실행하여 카탈로그 정보를 제거할 수 있습니다. SnapCenter GUI를 사용하여 카탈로그 정보를 제거할 수 없습니다. 그러나 백업을 삭제하거나 카탈로그 작성된 백업과 관련된 보존 및 리소스 그룹을 삭제하는 동안 카탈로그 작성된 백업 정보가 제거됩니다.

작업 시간이 ORACLE_PLUGIN_RMAN_catalog_timeout 매개 변수에 지정된 시간 초과 값을 초과했기 때문에 카탈로그 작성 및 카탈로그 작성 취소에 실패한 경우 다음 명령을 실행하여 매개 변수 값을 수정해야 합니다.

"/opt/netapp/snapcenter/spl/bin/sccli Set-SmConfigSettings-ConfigSettingsType Plugin-PluginCode SCO-ConfigSettings" key=oracle_plugin_RMAN_catalog_timeout, value=user_defined_value"

매개 변수 값을 수정한 후 다음 명령을 실행하여 SnapCenter SPL(Plug-in Loader) 서비스를 다시 시작합니다.

'/opt/netapp/snapcenter/spl/bin/spL 재시작'

명령에 사용할 수 있는 매개 변수와 이에 대한 설명은 get-help command_name 을 실행하여 얻을 수 있습니다. 또는 을 참조할 수도 있습니다 "SnapCenter 소프트웨어 명령 참조 가이드".

백업 빈도(스케줄 유형)는 정책에 지정되며 백업 스케줄은 리소스 그룹 구성에 지정됩니다. 백업 빈도 또는 스케줄을 결정하는 가장 중요한 요소는 리소스의 변경 속도 및 데이터의 중요도입니다. 자주 사용하는 리소스를 매일 한 번씩 백업할 수도 있고, 자주 사용하지 않는 리소스를 하루에 한 번 백업할 수도 있습니다. 기타 요인으로는 조직에 대한 리소스의 중요성, SLA(서비스 수준 계약) 및 RPO(복구 시점 목표)가 있습니다.

SLA는 예상되는 서비스 수준을 정의하고 가용성 및 서비스 성능을 비롯한 다양한 서비스 관련 문제를 해결합니다. RPO는 장애 후 정상적인 작업을 재개하기 위해 백업 스토리지에서 복구해야 하는 파일의 사용 기간에 대한 전략을 정의합니다. SLA 및 RPO는 데이터 보호 전략에 기여합니다.

사용량이 많은 리소스의 경우에도 하루에 한 번 또는 두 번 이상 전체 백업을 실행할 필요가 없습니다. 예를 들어 정기적인 트랜잭션 로그 백업만으로도 필요한 백업이 있는지 확인할 수 있습니다. 데이터베이스를 더 자주 백업할수록 SnapCenter는 복원 시 사용해야 하는 트랜잭션 로그를 더 적게 사용하여 복원 작업을 더 빠르게 수행할 수 있습니다.

백업 스케줄은 다음과 같이 두 부분으로 구성됩니다.

기본 스냅샷 복사본 명명 규칙을 사용하거나 사용자 지정된 명명 규칙을 사용할 수 있습니다. 기본 백업 명명 규칙은 스냅샷 복사본 이름에 타임 스탬프를 추가하여 복사본이 생성된 시간을 식별하도록 도와줍니다.

스냅샷 복사본은 다음과 같은 기본 명명 규칙을 사용합니다.

'resourcegroupname_hostname_timestamp'

다음 예제와 같이 백업 리소스 그룹의 이름을 논리적으로 지정해야 합니다.

이 예제에서 구문 요소는 다음과 같은 의미를 가집니다.

또는 * Use custom name format for Snapshot copy * 를 선택하여 리소스 또는 리소스 그룹을 보호하면서 스냅샷 복사본 이름 형식을 지정할 수 있습니다. 예를 들어 customtext_resourcegroup_policy_hostname 또는 resourcegroup_hostname을 입력합니다. 기본적으로 타임스탬프 접미사가 스냅샷 복사본 이름에 추가됩니다.

백업 복사본을 보존할 일 수를 선택하거나 유지할 백업 복사본 수를 최대 255개 사본의 ONTAP로 지정할 수 있습니다. 예를 들어, 조직에서 10일간 백업 복사본 또는 130개의 백업 복사본을 보존해야 할 수도 있습니다.

정책을 생성하는 동안 백업 유형 및 스케줄 유형에 대한 보존 옵션을 지정할 수 있습니다.

SnapMirror 복제를 설정하면 보존 정책이 대상 볼륨에 미러링됩니다.

SnapCenter는 스케줄 유형과 일치하는 보존 레이블이 있는 보존된 백업을 삭제합니다. 리소스 또는 리소스 그룹에 대한 스케줄 유형이 변경된 경우 이전 스케줄 유형 레이블이 있는 백업이 시스템에 남아 있을 수 있습니다.

운영 스토리지 볼륨 또는 SnapMirror 또는 SnapVault 보조 스토리지 볼륨에서 백업 복사본을 확인할 수 있습니다. 보조 스토리지 볼륨을 사용하여 검증하면 운영 스토리지 볼륨의 로드가 감소합니다.

운영 또는 2차 스토리지 볼륨에 있는 백업을 확인하면 모든 운영 및 2차 스냅샷 복사본이 확인됨 으로 표시됩니다.

SnapMirror 및 SnapVault 2차 스토리지 볼륨의 백업 복사본을 확인하려면 SnapRestore 라이센스가 필요합니다.