테이프는 장기간 데이터 저장 및 보존을 위한 신뢰성 높은 안정적 매체입니다. 그러나 수명은 유한합니다. 시간이 갈수록 일상적인 기계적 프로세스(마운트, 장력, 읽기/쓰기)로부터 마모 손상이 누적됩니다. 새로운 고성능 드라이브가 제공되면서 이전 드라이브는 지원이 힘들고 호환 매체는 더 비싸고 찾기가 어렵습니다. 그래서 어떤 점에서 새 매체로 아카이브를 이관해야 합니다.
Oracle HSM 계층적 파일 시스템에서 구 매체를 새 매체로 교체하는 것은 복잡한 과정입니다. 테이프 매체는 파일 시스템의 중요한 부분입니다. 파일 시스템 메타데이터는 각 파일 데이터의 여러 복사본 위치(일부는 디스크에, 일부는 테이프에 있음)를 기록합니다. 따라서 테이프를 복사하면서 마이그레이션된 파일 복사본의 새 위치를 반영하도록 파일 시스템 inode가 업데이트되어야 합니다. 동시에, 아카이브 및 스테이지와 같은 정상적 파일 시스템 작동을 방해하지 않고 복사본을 만들도록 매체 및 드라이브를 관리해야 합니다.
Oracle Hierarchical Storage Manager는 두 가지 방법으로 매체 마이그레이션의 복잡성을 관리합니다. 각자 요구 사항에 따라 장점이 있습니다.
Oracle HSM 6.1에 도입된 매체 마이그레이션 기능은 한 라이브러리 드라이브에 마운트된 매체의 전체 볼륨을 다른 곳에 마운트된 매체로 복사합니다. 이 과정에서 파일 시스템 메타데이터를 업데이트하지만 수동으로 로드된 드라이브는 지원되지 않습니다. 이 방식은 시스템 오버헤드와 관리자 작업량을 최소화합니다. 드라이브가 아카이브/스테이지에 필요하지 않을 때 백그라운드에서 볼륨이 복사됩니다. 사용되는 드라이브 수와 하루 중 마이그레이션이 발생할 시간을 지정할 수 있습니다. 또는 드라이브가 유휴 상태일 때마다 Oracle HSM이 볼륨을 마이그레이션할 수 있습니다. 드라이브나 볼륨이 아카이브/스테이지 작업에 필요한 경우 높은 우선순위 작업에 매체 마이그레이션 프로세스를 양보합니다. 올바르게 구성된 StorageTek T1000D 이상의 대상 드라이브가 사용 가능한 경우 T10000 확장 복사 기능과 Oracle HSM xcopy 옵션을 사용하여 마이그레이션할 수 있습니다. 일단 요청하면 서버 리소스를 사용하지 않고 드라이브가 자체적으로 복사를 처리합니다. 그렇지 않으면, 여전히 Oracle HSM server-copy 옵션을 사용하여 서버 로드를 최소화할 수 있습니다. 그러면 파일 시스템 서버가 구성 가능한 I/O 버퍼를 통해 드라이브 간에 볼륨을 복사합니다.
정상적인 아카이브 프로세스에서 아카이브 파일을 한번에 하나씩, 데이터를 마이그레이션할 수도 있습니다. 구 매체에서 디스크 캐시로 파일을 스테이지하고 새 매체로 다시 아카이브하도록 시스템을 구성합니다. 이 파일별 접근법은 파일 그룹화/배포 방법을 효율적으로 제어할 수 있습니다. 그러나 더 많은 관리가 필요합니다. 관리자가 디스크 캐시 및 드라이브 리소스를 할당하므로 정상적 파일 시스템 작동에 방해를 최소화해야 하는 경우 신중히 계획해야 합니다.
이 문서의 나머지 부분에서 프로세스를 안내합니다.
전체 볼륨 마이그레이션 또는 파일 스테이지 후 대체 매체로 다시 아카이브 방법으로 데이터 마이그레이션
더 진행하기 전에 다음 단계를 수행합니다.
매체 마이그레이션을 시작하기 전에, 일반적으로 Oracle HSM 아카이브 데이터를 보호하는 복구 메커니즘이 전환 작업 동안과 그 후에 유효한지 확인합니다. 치명적인 하드웨어 장애와 사용자 오류는 마이그레이션 작업 동안 언제든 발생할 수 있습니다. 따라서 항상 현존하는 samfsdump 복구 지점 파일에서 파일 및/또는 전체 파일 시스템을 복구할 수 있는지 확인해야 합니다.
마이그레이션 후 얼마 동안 새로운 대상 볼륨이 아닌 소스 테이프 볼륨을 참조하는 복구 지점 파일에 따라 복구가 달라집니다. 주요 하드웨어 장애로 파일 시스템이 사용 안함으로 설정되고 구 테이프를 사용할 수 없는 경우 복구할 수 없습니다.
따라서 최소한, 새 매체에서 현재 파일 시스템을 복원하기에 충분한 복구 지점을 새로 만들 때까지 구 테이프를 보존할 계획을 세웁니다. 특정 시점으로 파일을 복원해야 하는 경우 구 매체를 더 오래(아니면 무기한으로) 보관할 수 있어야 합니다. 이상적으로, 구 볼륨에 쉽게 액세스할 수 있도록 라이브러리에서 유지 관리해야 합니다.
대상 라이브러리에 마이그레이션된 파일을 보유하기에 충분한 매체가 있는지 확인합니다. 새 테이프에 레이블 지정 또는 기존 테이프에 레이블 재지정에 설명된 대로, 모든 볼륨에 올바로 레이블이 지정되었는지 확인합니다. 볼륨에 레이블이 없으면 마이그레이션을 실패합니다.
선택할 마이그레이션 방식은 아카이브 상태와 사용자 및 응용 프로그램 요구 사항에 따라 달라집니다. 아래 절차를 사용하여 결정을 내리십시오.
마이그레이션 동안 아카이브를 계속 작동할지 여부를 결정합니다.
아카이브를 중지하고 모든 리소스를 마이그레이션에 독점적으로 투여하면 작업을 간소화하고 빠르게 완성할 수 있습니다. 그러나 아카이브가 활발히 사용 중이면 실용적이지 않습니다.
전체 볼륨이 아닌 아카이브 파일 그룹을 선택적으로 마이그레이션하거나 아카이브 파일 그룹 간에 지정된 관계를 유지해야 하는 경우 스테이지 후 다시 아카이브 방식을 사용합니다. 파일 스테이지 후 대체 매체로 다시 아카이브로 이동합니다.
간단히 구 볼륨을 새 매체로 복사하거나 마이그레이션이 파일 시스템 작동에 미치는 영향을 최소화해야 하는 경우 볼륨 마이그레이션 방식을 사용합니다.
대상 드라이브로 사용할 수 있는 광 섬유 채널 Oracle StorageTek T10000D 이상의 드라이브가 없는 경우, 또는 소스와 대상 테이프가 공통 블록 크기를 공유하지 않는 경우 server-copy 방식을 사용합니다.
이 모드에서 Oracle HSM 소프트웨어는 소스 드라이브에서 파일 시스템 서버에 구성 가능한 I/O 버퍼로 유효한 아카이브 파일만 복사합니다. 소스와 대상 블록 크기가 다르면 대상 블록 크기가 더 큰 경우에 한해 소프트웨어가 자동으로 조정합니다. 그러면 소프트웨어는 버퍼에서 대상 드라이브로 테이프 블록을 전송합니다.
광 섬유 채널 StorageTek T10000D 이상의 대상 드라이브가 있고, 드라이브가 모두 현재 펌웨어를 실행 중이고, 소스와 대상 테이프가 동일한 블록 크기를 공유하며, 소스와 대상 드라이브가 동일한 SAN(스토리지 영역 네트워크) 스위치를 동해 연결된 경우 Oracle HSM xcopy 옵션을 사용합니다.
xcopy를 지정하면 파일 시스템 서버가 SCSI 복사 요청을 드라이브로 보내고, T10000D 드라이브는 첫번째 유효한 아카이브 파일부터 시작해서 블록 단위로 소스를 대상 테이프로 복사합니다. 어떤 이유로 xcopy 작업을 실패하면 마이그레이션 소프트웨어가 자동으로 server-copy 방식으로 전환합니다. xcopy 방식은 성능을 극대화하고 서버 오버헤드를 최소화합니다.
드라이브 및 펌웨어 요구 사항에 대한 자세한 내용은 다운로드 ZIP 파일 또는 파일 시스템 서버 /opt/SUNWsamfs/doc/README.txt에서 릴리스 노트와 README.txt를 참조하십시오.
소스 볼륨에 만료된 파일이 상대적으로 적은 경우 xcopy 옵션을 eod(데이터 끝) 모드로 사용합니다.
이 모드에서 T10000 드라이브는 첫번째 유효 파일과 테이프의 EOD(데이터 끝) 표시 사이에 발견된 모든 아카이브 파일을 복사합니다. 이 파일 중 일부가 사용되지 않는 경우 유효 파일과 함께 대상 볼륨으로 복사됩니다.
소스 볼륨에 만료된 파일이 많은 경우 xcopy 옵션을 repack 모드로 사용합니다.
이 모드에서 T10000 드라이브는 만료되지 않은 아카이브 파일만 대상 볼륨으로 복사합니다.
파일 스테이지 후 대체 매체로 다시 아카이브로 이동합니다.
server-copy 또는 direct-copy 방식을 선택하고 migrationd.cmd 파일을 만들어 마이그레이션을 구성합니다. 다음 작업을 수행합니다.
migrationd.cmd 파일 만들기Oracle HSM 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
텍스트 편집기에서 /etc/opt/SUNWsamfs/migrationd.cmd 파일을 엽니다.
예제에서는 vi 편집기에서 새 파일을 열고 처음 주석을 추가합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements
소량의 볼륨만 마이그레이션해야 하는 경우 각 소스 볼륨, 대상 볼륨 및 마이그레이션 방향을 지정합니다. 각 소스 볼륨에 대해 migrate = from source to destination 형식의 행을 입력합니다. 설명:
media_type은 소스를 보유할 매체 종류를 식별하는 2자 코드입니다(세부정보는 부록 A 장비 유형 용어집 참조).
VSN은 라이브러리에서 테이프 볼륨을 식별하는 고유한 볼륨 일련 번호입니다.
예제에서는 구 LTO(li) 테이프 VOL305에서 새 Oracle StorageTek T10000(ti) 테이프 카트리지 VOL820으로 데이터를 마이그레이션합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # Migrate a single volume. migrate = from li VOL305 to ti VOL820
대량의 볼륨을 마이그레이션해야 하는 경우 소스 및 대상 볼륨에 대한 매체 풀을 정의합니다. vsnpool = poolname library equipment_number media_type VSNlist 형식의 행을 입력하여 각 풀을 정의합니다. 설명:
name은 풀을 고유하게 식별합니다.
equipment_number는 mcf 파일에서 소스 볼륨을 보유할 라이브러리에 지정하는 순서 번호입니다.
media_type은 소스를 보유할 매체 종류를 식별하는 2자 코드입니다(세부정보는 부록 A 장비 유형 용어집 참조).
VSNlist는 공백으로 구분된 리터럴 VSN 목록이거나, VSN 그룹 및 범위를 식별하는 정규 표현식입니다.
예제에서는 구 LTO4(li) 테이프 볼륨에서 새 LTO6(ti) 테이프 카트리지로 데이터를 마이그레이션합니다. 마이그레이션할 라이브러리 20에서 LTO4 볼륨을 나타내는 소스 풀 pool1 행을 추가합니다. 이들은 VOL000 ~ VOL299 범위의 VSN을 가진 볼륨과 2개의 단일 볼륨 VOL300 및 VOL304를 포함합니다. 그 다음 라이브러리 30에서 LTO6 볼륨 범위를 나타내는 대상 풀 pool2 행을 추가합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # pool1 contains the source volumes vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 li ˆVOL50[0-9]
소스 및 대상 매체 풀을 정의했으면 마이그레이션 방향을 지정합니다. migrate = from sourcepool to destinationpool 형식의 행을 입력합니다. 설명:
sourcepool은 마이그레이션할 데이터를 포함하는 매체 풀입니다.
destinationpool은 마이그레이션된 데이터를 수신할 매체 풀입니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 ti ˆVOL50[0-9] # Migrate data from tapes in pool1 to tapes in pool2. migrate = from pool1 to pool2
server-copy 마이그레이션 방식을 배타적으로 사용하려면 xcopy 기능을 사용 안함으로 설정합니다. xcopy = off 형식의 행을 입력합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Disable xcopy and the StorageTek T10000 Extended Copy feature. xcopy = off
StorageTek T10000 확장 복사 기능을 배타적으로 사용하고 이 기능을 지원하는 드라이브를 사용할 수 없을 때 데이터를 마이그레이션하지 않으려면 xcopy 마이그레이션만 사용으로 설정합니다. xcopy = only 형식의 행을 입력합니다.
예제에서는 xcopy만 사용으로 설정합니다. 소스나 대상 드라이브 중 어느 것도 확장 복사 기능을 지원하지 않으면 마이그레이션 소프트웨어가 자동으로 마이그레이션을 취소합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, cancel migration. xcopy = only
가능한 경우 StorageTek T10000 확장 복사 기능을 활용하려면 xcopy 마이그레이션 방식을 사용으로 설정합니다. xcopy = on 형식의 행을 입력합니다.
예제에서는 마이그레이션 기간 동안 호환 드라이브를 항상 사용할 수 없더라도 xcopy를 사용으로 설정합니다. 소스나 대상 드라이브 중 어느 것도 확장 복사 기능을 지원하지 않으면 마이그레이션 소프트웨어가 자동으로 server-copy 모드로 전환합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, automatically switch # to the server buffer copy. xcopy = on
xcopy 방식을 사용하여 소량의 만료된 파일을 포함한 테이프 볼륨을 마이그레이션하려면 xcopy가 데이터 끝(eod) 모드로 실행하도록 설정합니다. xcopy_eod = on 형식의 행을 입력합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = on
xcopy 방식을 사용하여 대량의 만료된 파일을 포함한 테이프 볼륨을 마이그레이션하려면 xcopy가 repack 모드로 실행하도록 설정합니다. xcopy_eod = off 형식의 행을 입력합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = off
xcopy가 높은 우선순위의 아카이브/스테이지 작업에 의해 중단되기 전에 복사해야 하는 최소량의 데이터를 지정합니다. xcopy_minsize = amountunits 형식의 행을 입력합니다. 설명:
amount는 정수입니다.
units는 킬로바이트 k, 메가바이트 M, 기가바이트 G, 테라바이트 T, 페타바이트 P, 엑사바이트 E입니다.
이 값은 효율적인 T10000 드라이브 활용과 다른 작업을 위한 드라이브 가용성 사이의 절충안을 정의합니다. 값이 클수록 더 효율적으로 드라이브에 데이터를 쓸 수 있습니다. 값이 작을수록 아카이브/스테이지를 위한 드라이브 가용성이 증가합니다. 예제에서는 최소 복사 크기를 30GB로 설정합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_eod = on # xcopy can be interrupted after 30GB copied. xcopy_minsize = 30G
매일 마이그레이션 작업 실행이 허용되는 기간을 정의합니다. runtime = window 형식의 행을 입력합니다. 여기서 window는 다음 값 중 하나입니다.
always - 드라이브와 매체가 아카이브/스테이지에 필요하지 않을 때마다 마이그레이션 데몬이 데이터를 마이그레이션합니다. 드라이브나 매체가 아카이브/스테이지에 필요할 때 마이그레이션 데몬이 이를 사용 중인 경우 마이그레이션 데몬이 양보합니다.
start_time end_time - 여기서 start_time 및 end_time은 각각 허용 기간이 시작하고 끝나는 시간으로, 24시간제의 시 분(HHMM)으로 표현합니다.
samcmd, migstart, migidle 또는 migstop 명령을 실행하여 언제든 이 지시어를 대체할 수 있습니다.
마이그레이션 서비스는 볼륨과 드라이브를 스테이저/아카이버가 요구할 때 이를 포기합니다. 따라서 피크 시간 동안 아카이브/스테이지에 문제가 발생하지 않는 한, 기본값인 always를 수락해야 합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_minsize = 30G # Run all of the time. Migration daemon will yield VSNs and drives when # resources are wanted by the SAM-QFS archiver and stager. run_time = always
로그 디렉토리를 지정하여 로깅을 사용으로 설정합니다. logdir = path 형식의 행을 입력합니다. 여기서 path는 디렉토리 경로 및 디렉토리 이름입니다.
디렉토리가 정의되면 마이그레이션 데몬은 각 소스 볼륨에서 마이그레이션할 각 아카이브 파일의 대상을 기록합니다. 각 소스 볼륨에는 media_type.VSN이라는 고유의 로그 파일이 있습니다. 설명:
media_type은 소스 매체의 종류를 식별하는 2자 코드입니다(세부정보는 부록 A 장비 유형 용어집 참조).
VSN은 소스 볼륨을 식별하는 고유한 볼륨 일련 번호입니다.
예를 들어, VSN VOL300을 가진 소스 볼륨의 로그 파일은 li.VOL300이 됩니다.
아카이버 로그와 마찬가지로 이 마이그레이션 로그는 재해 복구 동안 매우 유용할 수 있습니다. 자세한 내용은 복구 지점 및 아카이브 로그 이해 및 Oracle Hierarchical Storage Manager and StorageTek QFS Software 파일 시스템 복구 설명서를 참조하십시오. 따라서 가능한 경우 항상 로그 디렉토리를 지정하십시오. Oracle HSM 소프트웨어나 하드웨어 장애의 영향을 받지 않을 위치(예: /var/adm/)를 선택합니다. 예제에서는 /var/adm/hsm_migration_logs 디렉토리를 지정합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... run_time = always # Log directory for the migration logs. logdir = /var/adm/hsm_migration_logs
마이그레이션 inode 데이터베이스의 홈 디렉토리를 지정합니다. dbdir = path 형식의 행을 입력합니다. 여기서 path는 절대 디렉토리 경로 이름입니다.
각 소스 볼륨에 대해 inode 데이터베이스가 만들어지고 마이그레이션 기간 동안 유지됩니다. 소스 볼륨에서 발견된 각 아카이브 복사본에 대해 224바이트의 데이터베이스 레코드 하나가 만들어집니다. 따라서 소스 매체에 맞는 가장 큰 복사본 수를 수용하기에 충분한 디스크 공간이 있는 위치를 선택해야 합니다. 예를 들어, 각 Oracle StorageTek T10000D 볼륨은 최대 8,200,104,892개의 아카이브 복사본을 보유할 수 있습니다. 따라서 주어진 시간에 마이그레이션할 각 T10000D 볼륨에 대해 약 1.67TB의 데이터베이스 공간이 필요합니다. 자세한 내용은 migration.cmd (1m) 매뉴얼 페이지를 참조하십시오.
기본 데이터베이스 위치는 /var/opt/SUNWsamfs/sammig/db입니다. 예제에서는 기본 디렉토리를 지정합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... logdir = /var/adm/hsm_migration_logs # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db
대상 장치에 대한 마이그레이션 버퍼 크기를 설정합니다. buffsize = media_type blocks 형식의 행을 입력합니다. 설명:
media_type은 소스를 보유할 매체 종류를 식별하는 2자 코드입니다(세부정보는 부록 A 장비 유형 용어집 참조).
size는 [2-8192] 범위의 정수입니다. 여기서 정수 값은 버퍼가 보유할 수 있는 테이프 블록 수를 지정합니다. 기본값은 64입니다.
예제에서는 Oracle StorageTek T10000 테이프 블록의 기본 개수를 보유하기에 충분한 공간을 할당합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64
라이브러리당 마이그레이션에 사용할 수 있는 최대 드라이브 수를 지정합니다. max_drives = library-list 형식의 행을 입력합니다. 설명:
library-list는 공백으로 구분된 라이브러리 항목 목록으로, 각각 library equipment-number device-count 형식을 사용합니다.
equipment-number는 mcf 파일에서 라이브러리에 지정된 장비 순서 번호입니다.
device-count는 지정된 라이브러리에서 사용할 수 있는 드라이브 수입니다. 기본적으로 device-count는 라이브러리의 드라이브 수로 설정됩니다.
마이그레이션 서비스는 볼륨과 드라이브를 스테이저/아카이버가 요구할 때 이를 포기합니다. 따라서 아카이브/스테이지에 문제가 발생하지 않는 한, 기본 설정을 수락하고 사용 가능한 드라이브를 마이그레이션에 사용하도록 허용해야 합니다. 예제에서는 실제로 드라이브 사용량을 제한해야 합니다. 따라서 라이브러리 20에서 8개, 라이브러리 30에서 6개, 라이브러리 40에서 2개 드라이브를 마이그레이션에 할당합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2
동시에 실행할 수 있는 마이그레이션 관련 복사 작업의 최대 개수를 지정합니다. max_copy = processes 형식의 행을 입력합니다. 여기서 processes는 정수입니다.
기본값이 최대값이며, mcf 파일에 나열된 모든 라이브러리에 구성된 드라이브 수를 2로 나눈 값과 같습니다. 예제에서는 최대 8개의 동시 복사 프로세스를 할당합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Up to 8 sam-migcopy process can be run simultaneously. max_copy = 8
동시에 실행할 수 있는 마이그레이션 관련 테이프 스캔 작업의 최대 개수를 지정합니다. max_scan = processes 형식의 행을 입력합니다. 여기서 processes는 정수입니다.
마이그레이션 소스 VSN에 아카이브 복사본을 식별하기 위해 sam-migrationd 데몬은 mcf에 구성된 모든 파일 시스템을 스캔하고 디스크 캐시에서 모든 inode를 읽어서 각 inode의 vsn 필드를 마이그레이션 소스 볼륨의 VSN(볼륨 일련 번호)과 비교합니다. 이 과정에서 파일 시스템의 메타데이터 작동이 증가하므로 파일 시스템 성능에 악영향을 미칠 수 있습니다.
수용 가능한 파일 시스템 성능과 마이그레이션 속도가 가장 균형을 이루는 값을 선택하거나, 대부분의 경우 기본값인 4를 수락합니다. 가장 빨리 마이그레이션하기 위해 파일 시스템을 중지하려면 max_scan을 0으로 설정합니다. 그러면 모든 소스 볼륨이 한꺼번에 스캔됩니다. 예제에서는 정상적 파일 시스템 작동에 영향을 미치지 않고 최대 8개 동시 스캔 프로세스가 가능한 것을 경험으로 알 수 있습니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Run up to 8 sam-migcopy processes simultaneously. max_copy = 8 # Scan up to 8 VSNs simultaneously. max_scan = 8
파일을 저장하고 편집기를 닫습니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd
...
max_copy = 8
# Scan up to 8 VSNs simultaneously.
max_scan = 8
:wq
root@solaris:~#
이 절의 지침은 셸 명령 프롬프트에서 samcmd 명령을 사용하여 명령을 입력하는 방법을 설명합니다. 그러나 모든 명령은 samu 인터페이스에서 :command 형식(여기서 command는 명령의 이름)으로도 입력할 수 있습니다.
현재 Oracle HSM 메타데이터 서버에 root로 로그인하지 않은 경우 지금 로그인합니다.
root@solaris:~#
이전 마이그레이션이 현재 활성 또는 미완료 상태가 아닌지 확인합니다. 먼저, 현재 마이그레이션 상태를 확인합니다. samcmd x 명령을 사용합니다.
다른 마이그레이션 복사 작업이 진행 중이면 이 명령은 소스와 대상 볼륨을 매체 유형 및 VSN, 복사 모드, 완료율, 현재 복사 상태에 따라 나열합니다.
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart source dest cmod perc status li VOL004 li VOL042 - 60% Copy idled
그렇지 않고 다른 마이그레이션 복사 작업이 실행 중이 아니면 이 명령은 아무 작업도 나열하지 않습니다.
root@solaris:~# samcmd x Migration status samu ver time date Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 0 Status: Idle: Waiting for :migstart source dest cmod perc status
그 다음, 현재 소스(S) 및/또는 대상(D) 볼륨의 상태를 확인합니다. samcmd y 명령을 사용합니다.
첫번째 예제에서는 나열된 소스와 대상 볼륨에 대한 end time 작업이 10/16 12:14입니다. 소스 볼륨의 복사가 완료 상태입니다. 따라서 현재 실행 중인 작업이 없습니다.
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa01 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOLa80 10/16 12:12 10/16 12:14 avail 550.00M
두번째 예제에서는 소스와 대상 볼륨에 대한 end time 작업이 none입니다. 소스 볼륨이 대상 볼륨으로 아직 복사되는 중입니다. 따라서 마이그레이션 작업이 아직 실행 중입니다.
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa02 10/16 12:12 none copy 0/35023 164.50M 0 D li VOLa81 10/16 12:12 none copy 148.75M
마지막으로, 라이브러리 카탈로그에서 볼륨 목록을 확인합니다. samcmd v 명령을 사용합니다. 출력에서 다음 플래그를 찾습니다.
R은 볼륨이 읽기 전용임을 의미합니다. 마이그레이션을 시작할 때 소스 볼륨은 읽기 전용으로 표시됩니다.
S(소스)는 이 볼륨에서 아직 데이터가 복사 중임을 의미합니다.
D(대상)는 이 볼륨으로 아직 데이터가 복사 중임을 의미합니다.
m은 소스 볼륨이 마이그레이션을 마쳤음을 의미합니다.
e는 소스 볼륨이 오류로 인해 마이그레이션을 실패했음을 의미합니다.
예제에서는 VOLa01 볼륨을 VOLa80으로 성공적으로 마이그레이션했습니다. VOLa02 볼륨은 VOLa81로 아직 마이그레이션되는 중입니다. 마이그레이션에 실패했습니다.
root@solaris:~# samcmd v Robot catalog samcmd version HH:MM:SS month day year Robot VSN catalog by slot : eq 800 slot access time count use flags ty vsn count 64 0 2015/06/29 17:00 1 95% -il---b--Rm- li VOLa01 1 2015/07/02 17:43 2 89% -il-o-b--RS- li VOLa02 2 2015/07/02 18:31 2 89% -il-o-b--Re- li VOLa03 ... 51 2015/10/16 15:18 2 82% -il-o-b----- li VOLa80 52 2015/10/16 15:25 2 84% -il-o-b---D- li VOLa81
작업이 실행 중이면 완료할 때까지 기다립니다.
그렇지 않고 이미 진행 중인 마이그레이션이 없다고 확신하면 볼륨 마이그레이션을 수행합니다.
이 절의 지침은 셸 명령 프롬프트에서 samcmd 명령을 사용하여 명령을 입력하는 방법을 설명합니다. 그러나 모든 명령은 samu 인터페이스에서 :command 형식(여기서 command는 명령의 이름)으로도 입력할 수 있습니다.
현재 Oracle HSM 메타데이터 서버에 root로 로그인하지 않은 경우 지금 로그인합니다.
root@solaris:~#
소스 파일 시스템이 마운트되었는지 확인합니다.
migrationd.cmd 파일을 활성화합니다. samcmd migconfig 명령을 사용합니다.
구성을 성공하면 이 명령은 Configuring migration 메시지를 표시하고 세부정보는 로그 파일을 참조하라고 알려줍니다.
root@solaris:~# samcmd migconfig samcmd: migconfig: Configuring migration (see /var/opt/SUNWsamfs/sammig/logfile) root@solaris:~#
그렇지 않으면 오류와 함께 명령이 중지됩니다. 구성 명령을 실행하기 전에 마이그레이션 프로세스를 중지하지 못했거나, 테이프 볼륨이 마이그레이션되기를 기다리는 동안 마이그레이션을 중지했습니다.
root@solaris:~# samcmd migconfig samcmd: migconfig: Can't configure migration, migration status is not stop, or migration job is pending root@solaris:~#
마이그레이션 구성을 표시합니다. samcmd y 명령을 사용합니다.
구성을 성공했으면 지정된 볼륨이 나열되고 소스 볼륨의 상태가 sched_wait(예약됨, 대기 중)이고, 대상 볼륨의 상태가 avail(사용 가능)입니다. 예제에서는 구성을 성공했습니다.
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 none none sched_wait 0/0 0 0 D li VOL501 none none avail 0
구성을 성공했으면 마이그레이션을 시작합니다. samcmd migstart 명령을 사용합니다.
root@solaris:~# samcmd migstart samcmd: migstart: State changed to start root@solaris:~#
마이그레이션의 상태를 확인합니다. samcmd x 및 samcmd y 명령을 사용합니다.
예제에서는 마이그레이션을 방금 시작 중입니다. Migration status 화면이 보여주듯이 작업 상태가 지금 Run이고, 1개 복사가 s(서버) 복사 모드(cmod)를 사용하여 진행 중이고, 복사가 0% 완료되었고, 0개 inode가 업데이트되었고, 소스 볼륨이 아직 Loading 상태입니다.
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 0% Loading li.VOL001
Migration vsn list 화면이 보여주듯이 2개 볼륨(1개 소스와 1개 대상)이 현재 처리되는 중입니다. 두 볼륨의 상태는 지금 copy이며 소스가 대상으로 복사되는 중임을 보여줍니다. 이 시점에서 0 바이트가 소스에서 대상으로 복사되었고 35023개 inode 중 아무것도 업데이트되지 않았습니다.
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 0 0 D li VOL501 10/16 12:12 none copy 0
다시 samcmd x 및 samcmd y 명령을 사용하여 마이그레이션 상태를 정기적으로 재확인합니다.
예제에서는 Migration status 화면이 보여주듯이 복사가 지금 23% 완료되었고 560개(0x00000230) 테이프 블록을 소스에서 읽어왔습니다.
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 24% 0x00000230 blocks read
Migration vsn list 화면이 보여주듯이 164.50 메가바이트를 소스 볼륨에서 읽어왔고 148.75 메가바이트를 대상 볼륨에 썼습니다.
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 164.50M 0 D li VOL501 10/16 12:12 none copy 148.75M
마이그레이션이 완료되면 종료 상태를 확인합니다. samcmd x 및 samcmd y 명령을 사용하고 마이그레이션 로그 파일을 조사합니다.
예제에서는 소스와 대상 볼륨이 더 이상 Migration status 화면에 나열되지 않고 지금 1개 복사가 완료되었음을 보여줍니다. 마이그레이션 상태는 아직 Run이고 migidle 또는 migstop 명령을 입력할 때까지 계속 유지됩니다.
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 1 Status: Run source dest cmod perc status
Migration vsn list 화면이 보여주듯이 550.00 메가바이트를 소스 볼륨에서 읽어왔고 550.50 메가바이트를 대상 볼륨에 썼습니다. 모든 35023개 inode가 마이그레이션된 아카이브 복사본의 새 위치를 반영하도록 업데이트되었습니다.
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOL012 10/16 12:12 10/16 12:14 avail 550.00M
마이그레이션 데몬의 로그 파일은 각 마이그레이션 단계를 나열하고 요약 결론을 보여줍니다. 예제에서는 Solaris tail 명령을 사용하여 가장 최근 항목을 봅니다.
root@solaris:~# tail /var/opt/SUNWsamfs/sammig/logfile date time Info: Schedule: Create VsnList file. date time Info: Schedule: VsnList file created, source: 1, destination: 1. date time Info: Schedule: Migration status changed to Start. date time Info: 'li.VOL001' Filesystem scan: Started date time Info: 'li.VOL001' Filesystem scan: Completed, total copy bytes: 517.2M, inodes: 35023, multi vsn copy: 0, removable-media file: 0, obsolete copy: 0 date time Info: 'li.VOL001' Copy: Started, pid: 2459 destination 'li.VOL012' date time Info: 'li.VOL001' Copy: Mode - server copy date time Info: 'li.VOL001' Copy: Server copy started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check succeeded, 5 inodes checked, 0 tar header error found. date time Info: 'li.VOL001' Copy: Completed, pid: 2459, exit status: 12, signal: 0 date time Info: 'li.VOL001' Update inode: Started, source position: 0 date time Info: 'li.VOL001' Update inode: Completed. date time Info: 'li.VOL001' Log: Started, source position: 0 date time Info: 'li.VOL001' Log: Completed. date time Summ: 'li.VOL001' date time Summ: 'li.VOL001' =============== Summary =============== date time Summ: 'li.VOL001' Status: Complete date time Summ: 'li.VOL001' Copy mode: Server copy date time Summ: 'li.VOL001' Start at: date time date time Summ: 'li.VOL001' End at: date time date time Summ: 'li.VOL001' Bytes: 550.00M date time Summ: 'li.VOL001' Archive copies: 35023 date time Summ: 'li.VOL001' Read error copies: 0 date time Summ: 'li.VOL001' Multi vsn copies: 0 date time Summ: 'li.VOL001' Removable-Media file: 0 date time Summ: 'li.VOL001' ---Dest--- ---Bytes--- ---Copies--- date time Summ: 'li.VOL001' li VOL501 550.00M 35023 root@solaris:~#
마지막으로, 볼륨 마이그레이션 로그를 안전한 위치로 복사해야 합니다.
이 로그는 각 소스 볼륨에서 마이그레이션된 각 아카이브 파일 복사본의 대상 볼륨과 시작 위치를 기록합니다. 이 정보는 파일이나 파일 시스템을 복구해야 하는 경우 매우 중요합니다. 따라서 Oracle은 복구 지점 및 아카이버 로그 파일과 함께 이 파일의 백업 복사본을 보관할 것을 강력히 권장합니다. 제 7 장 구성 및 파일 시스템 백업 및 Oracle Hierarchical Storage Manager and StorageTek QFS 설치 및 구성 설명서의 해당 장을 참조하십시오.
마이그레이션 데몬은 migrationd.cmd 파일에 지정된 디렉토리에 마이그레이션 로그 파일을 만듭니다. 마이그레이션된 각 볼륨에 대해 media_type.VSN이라는 파일을 만듭니다. 설명:
media_type은 소스 매체의 종류를 식별하는 2자 코드입니다(세부정보는 부록 A 장비 유형 용어집 참조).
VSN은 소스 볼륨을 식별하는 고유한 볼륨 일련 번호입니다.
예제에서는 지정된 로그 디렉토리 /var/adm/hsm_migration_logs/에서 NFS 마운트 원격 파일 시스템의 파일 시스템 복구 리소스를 보관할 디렉토리로 볼륨 로그를 복사합니다.
root@solaris:~# ls /var/adm/hsm_migration_logs/ li.VOL001 li.VOL002 li.VOL003 li.VOL004 li.VOL005 li.VOL006 ... ti.801 ... root@solaris:~# cp /var/adm/hsm_migration_logs/*.* /zfs/recover/hsmfs1/2015mig/
모든 파일을 다시 아카이브했으면 요구 사항에 따라 테이프를 처리합니다(마이그레이션 이후 구 매체 처리 참조).
여기서 중지합니다. 마이그레이션이 완료되었습니다.
스테이지 후 다시 아카이브 방식을 사용하여 구 매체에서 새 매체로 아카이브 파일을 마이그레이션하려면 정상적 파일 시스템 작동을 방해하지 않고 마이그레이션할 파일을 식별하고, 디스크 캐시로 스테이지하고, 새 매체에 기록해야 합니다. 이 장에서는 프로세스의 다음 단계를 다룹니다.
스테이지 후 다시 아카이브 프로세스의 세부정보는 주로 사용 가능한 디스크 스토리지 양과 사용 가능한 이동식 매체 드라이브 수에 따라 달라집니다. 데이터 마이그레이션 동안 Oracle HSM 스테이저는 이전 이동식 볼륨을 이전 매체 형식을 읽을 수 있는 드라이브로 로드하고 아카이브된 파일을 디스크 캐시로 복원합니다. 그런 다음 Oracle HSM 아카이버는 새 매체 형식을 쓸 수 있는 드라이브를 사용하여 파일을 새 이동식 볼륨으로 다시 아카이브합니다. 따라서 이상적으로, 주어진 테이프 볼륨의 모든 파일을 한꺼번에 디스크로 스테이지한 후 즉시 새 매체로 아카이브하게 됩니다.
이를 위해 마이그레이션 기간 동안 엄청난 리소스를 투입해야 합니다.
전체 테이프 용량에 해당하는 디스크 공간
구 테이프 형식을 읽는 드라이브의 배타적 사용
새 형식에 쓰는 드라이브의 배타적 사용
마이그레이션이 완료될 때까지 파일 시스템을 중지할 수 있으면 위 사항은 문제가 되지 않습니다. 그러나 진행 중인 파일 시스템 및 아카이브 작업을 지나치게 방해하지 않고 운용 설정의 데이터를 마이그레이션하려면 약간 생각할 필요가 있습니다. 디스크 공간이나 테이프 드라이브에 공급이 부족한 경우 마이그레이션에 상당량 할애할 수 있는 리소스를 식별하고 마이그레이션 프로세스를 조정해야 합니다. 따라서 다음과 같이 하십시오.
정상적 파일 시스템 작동을 방해하지 않고 마이그레이션에 사용할 수 있는 디스크 캐시 양을 추정합니다.
마이그레이션에 투입할 여유가 있는 테이프 드라이브 수를 추정합니다.
제한된 수의 테이프 드라이브만 사용할 수 있는 경우 스테이징 및 아카이빙 프로세스에 스로틀링을 적용하여 마이그레이션 프로세스가 정상적 작동을 방해하지 않도록 합니다.
위의 예상치를 바탕으로 스테이징 및 아카이빙 매개변수를 결정합니다. 주어진 시간에 사용 가능한 디스크 공간이 보유할 마이그레이션 파일의 최대 개수와, 파일이 캐시에서 새 매체로 이동할 수 있는 최대 속도를 결정합니다.
리소스를 추정했으면 마이그레이션 사후 구 매체 처리 계획을 수행합니다.
새 매체를 archiver.cmd 파일에 추가하고 항상 새 매체를 사용하여 복사본을 만들도록 아카이브 복사 지시어를 수정합니다.
텍스트 편집기에서 /etc/opt/SUNWsamfs/archiver.cmd 파일을 엽니다.
아카이빙 정책은 복사본 2부를 명시합니다. 둘 다 교체하려는 매체 유형에 쓰여집니다. 예제에서는 vi 편집기에서 파일을 엽니다. DLT 카트리지(유형 lt)를 교체하려고 합니다.
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 lt .* endvsns
복사본 2의 지시어에서 지정된 매체 유형을 새 매체의 식별자로 변경하고 파일을 저장하고 텍스트 편집기를 닫습니다.
예제에서는 구 DLT 테이프에서 새 LTO 카트리지로 데이터를 마이그레이션하려고 합니다. 따라서 복사본 2에서 구 매체 유형 lt(DLT)를 li(LTO)로 변경합니다.
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 li .* endvsns :wq root@solaris:~#
archiver.cmd 파일에 구문 오류가 있는지 확인합니다. archiver -lv 명령을 실행하고 오류가 발견되지 않을 때까지 오류를 수정합니다.
archiver -lv 명령은 한 행씩 파일을 출력합니다. 만일 오류가 발생하면 오류가 발생한 지점에서 실행이 중지됩니다.
root@solaris:~# archiver -lv Reading '/etc/opt/SUNWsamfs/archiver.cmd'. 1: # ============================================= 2: # /etc/opt/SUNWsamfs/archiver.cmd 3: # --------------------------------------------- 4: # Global Directives 5: logfile = /var/opt/SUNWsamfs/archiver.log 6: # --------------------------------------------- 7: # File System Directives: 8: fs = samqfsms 9: all . 10: 1 5m ... root@solaris:~#
수정된 archiver.cmd 파일에 오류가 없으면 samd config 명령을 사용하여 이를 현재 구성에 로드합니다.
root@solaris:~# samd config Configuring SAM-FS root@solaris:~#
그런 다음 카트리지에서 카트리지로 데이터 마이그레이션을 수행합니다.
데이터 마이그레이션을 위한 스테이징 및 아카이빙 방식은 GNU find 명령의 Oracle HSM 확장인 sfind를 사용하는 것입니다. sfind 명령을 사용하여 지정된 테이프 볼륨에서 파일을 찾고 모든 발견된 파일에 대해 stage 및 rearchive 명령을 실행할 수 있습니다.
sfind, stage, rearchive 명령에 익숙하지 않으면 지금 각각의 매뉴얼 페이지를 검토해야 합니다. 그런 다음 마이그레이션할 데이터를 보유한 각 테이프 카트리지에 대해 다음과 같이 하십시오
파일 시스템 호스트에 root로 로그인합니다.
root@solaris:~#
마이그레이션하려는 파일이 저장된 파일 시스템의 마운트 지점 디렉토리로 이동합니다.
예제에서는 /hsm/hsmfs1에 마운트된 hsmfs1 파일 시스템에 저장되어 있는 파일의 아카이브된 복사본을 마이그레이션합니다.
root@solaris:~# cd /hsm/hsmfs1 root@solaris:~#
테이프 볼륨을 선택합니다.
매체 유형에서 매체 유형으로 데이터를 마이그레이션할 때 한번에 하나씩 볼륨을 작업합니다. 아래 예제에서는 볼륨 일련 번호 VOL008을 사용합니다.
먼저, 선택한 볼륨에서 성공적으로 스테이지할 수 없는 손상된 파일이 있는지 검색합니다. Oracle HSM 명령 sfind . -vsn volume-serial-number -damaged를 사용합니다. 여기서 volume-serial-number는 라이브러리에서 볼륨을 고유하게 식별하는 영숫자 문자열입니다.
예제에서는 현재 작업 디렉토리(.)에서 검색을 시작합니다. -vsn 매개변수는 현재 테이프 VOL008에서 발견된 파일로 검색을 제한합니다. -damaged 플래그는 성공적으로 스테이지할 수 없는 파일로 검색을 제한합니다.
root@solaris:~# sfind . -vsn VOL008 -damaged
손상된 파일에 대한 sfind 검색 작업으로 결과가 반환되면 파일을 수정합니다. undamage -m media-type -vsn volume-serial-number file 명령을 사용합니다. 설명:
media-type은 부록 A에 나열된 2자리 매체 유형 코드 중 하나입니다.
volume-serial-number는 볼륨을 고유하게 식별하는 영숫자 문자열입니다.
file은 손상된 파일의 경로 및 이름입니다.
일부 경우에는 일시적 I/O 오류로 인해 복사본이 손상된 것으로 표시될 수 있습니다. Oracle HSM undamage 명령은 이러한 조건을 해결합니다. 예제에서는 아카이브 파일 복사본 /hsm/hsmfs1/data0008/20131025DAT가 손상된 것으로 보고되었습니다. 따라서 이 파일의 손상을 해결하고 손상된 파일을 다시 검색해봅니다.
root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged
sfind 명령에서 이 파일이 다시 손상된 것으로 나열되면 복사본을 사용할 수 없는 것입니다. 아카이브에 다른 손상되지 않은 파일 복사본이 있는지 확인합니다. 사용 가능한 복사본을 나열하려면 sls -D file 명령을 사용합니다. 여기서 file은 파일의 경로 및 이름입니다. 발견된 복사본의 상태를 확인하려면 sfind file -vsn volume-serial-number 명령을 사용합니다.
예제에서는 undamage 명령이 복사본을 수정할 수 없습니다. 따라서 sls를 사용하여 /hsm/hsmfs1/data0008/20131025DAT 파일의 모든 복사본을 나열합니다.
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sls -D /hsm/hsmfs1/data0008/20131025DAT 20131025DAT: mode: -rw-r--r-- links: 1 owner: root group: other length: 319279 admin id: 7 inode: 1407.5 project: system(0) offline; archdone; stage -n; copy 1: ---- May 21 07:12 1e4b1.1 lt VOL008 copy 2: ---- May 21 10:29 109c6.1 lt VOL022 ...
테이프 볼륨 VOL022는 파일의 두번째 복사본을 보유합니다. 따라서 sfind를 사용하여 두번째 복사본을 확인합니다.
root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged
복사본을 사용할 수 없으며 파일의 손상되지 않은 복사본이 하나 존재하는 경우 파일을 다시 아카이브합니다. 그런 다음 아카이브가 두 개의 올바른 복사본을 보유하면 손상된 복사본을 아카이브 해제합니다.
예제에서는 VOL008 볼륨의 /hsm/hsmfs1/data0008/20131025DAT 파일 복사본 1을 사용할 수 없지만 sfind 명령에서 복사본 2에 대한 손상을 찾지 못했습니다. 따라서 VOL008 볼륨에서 손상된 복사본을 아카이브 해제하기 전에 -c 옵션과 함께 archive 명령을 실행하여 유효한 복사본 1을 만듭니다.
root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged root@solaris:~# archive -c 1 /hsm/hsmfs1/data0008/20131025DAT ... root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
사용 가능한 복사본이 존재하지 않으면 파일이 캐시에 있는지 확인합니다. sfind . -vsn volume-serial-number -online 명령을 사용합니다.
예제에서는 VOL008 볼륨의 복사본 1과 VOL022 볼륨의 복사본 2 모두 손상되고 사용할 수 없습니다. 따라서 디스크 캐시에서 파일을 온라인으로 사용할 수 있는지 확인합니다.
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online
사용 가능한 복사본이 존재하지 않지만 파일이 캐시에 있는 경우 파일을 아카이브합니다. 그런 다음 아카이브가 두 개의 올바른 복사본을 보유하면 손상된 복사본을 아카이브 해제합니다.
예제에서는 VOL008 볼륨의 복사본 1과 VOL022 볼륨의 복사본 2가 모두 사용 불가능하므로 VOL008 볼륨에서 손상된 복사본을 아카이브 해제하기 전에 archive 명령을 실행하여 두 개의 유효한 복사본을 만듭니다.
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
사용 가능한 복사본이 존재하지 않고, 파일이 디스크 캐시에 없으면 데이터가 손실된 것입니다. 중요한 데이터인 경우 데이터 복구 회사 전문가에게 도움을 요청하십시오. 그렇지 않으면 손상된 복사본을 아카이브 해제합니다.
예제에서는 VOL008 볼륨의 복사본 1과 VOL022 볼륨의 복사본 2 모두 사용할 수 없습니다. sfind 명령은 디스크 캐시에서 파일을 찾을 수 없습니다. 데이터가 중요하지 않습니다. 따라서 VOL008 볼륨에서 손상된 복사본을 아카이브 해제합니다.
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
손상된 파일에 대한 sfind 검색이 결과를 반환하지 않으면 현재 테이프의 파일을 디스크 캐시에 스테이지합니다. sfind . -vsn volume-serial-number -offline -exec stage {}\; 명령을 사용합니다.
-vsn 매개변수는 현재 테이프에서 발견된 파일로 검색을 제한합니다. 항상 한 번에 테이프 하나씩 마이그레이션합니다.
-offline 매개변수는 이미 캐시에 없는 파일로 sfind 출력을 한층 더 제한하므로 데이터를 덮어쓰지 않습니다.
-exec stage {}\; 인수는 sfind가 반환하는 각 경로 및 파일 이름을 사용하며 이를 Oracle HSM stage 명령에 대한 인수로 사용합니다. 그런 다음 stage 명령은 지정된 파일을 디스크 캐시로 복원합니다. 적합한 파일이 모두 스테이지될 때까지 프로세스가 반복됩니다.
예제에서는 sfind -vsn VOL008 -damaged 명령이 출력을 반환하지 않습니다. 따라서 sfind를 사용하여 VOL008에서 검색되고 캐시에 없는 파일을 모두 스테이지합니다.
root@solaris:~# sfind . -vsn VOL008 -damaged root@solaris:~# sfind . -vsn VOL008 -offline -exec stage {}\;
테이프에서 파일이 스테이지되었으면 선택적으로 다시 아카이브합니다. sfind . -vsn volume-serial-number -online -exec rearch -r -m media-type {}\; 명령을 사용합니다. 여기서 media-type은 마이그레이션 중인 매체 유형입니다.
-vsn 매개변수는 현재 테이프에서 발견된 파일로 검색을 제한합니다. 항상 한 번에 테이프 하나씩 마이그레이션합니다.
-online 매개변수는 캐시에 있는 파일로 sfind 출력을 한층 더 제한하므로 데이터를 덮어쓰지 않습니다.
-exec rearch -r -m media-type {}\; 인수는 sfind가 반환하는 각 경로 및 파일 이름을 사용하며 이를 Oracle HSM rearch -r -m media-type 명령에 대한 인수로 사용합니다. -r 인수는 하위 디렉토리를 통해 프로세스를 반복적으로 실행합니다. -m 인수는 소스 매체에 있는 파일만 다시 아카이브합니다.
예제에서 -vsn 매개변수 값은 VOL008이고 -m 매개변수 값은 DLT 매체인 lt를 지정합니다.
root@solaris:~# sfind . -vsn VOL008 -online -exec rearch -r -m lt {}\;
sfind 검색이 더 이상 파일을 발견하지 않을 때까지 앞의 단계를 반복합니다.
모든 파일이 다시 아카이브되었을 때 계획한 대로 테이프를 처리합니다(마이그레이션 이후 구 매체 처리 참조).
모든 구 매체에서 새 매체로 데이터가 마이그레이션될 때까지 이 절차를 반복합니다.
마이그레이션을 완료한 후 구 매체가 반드시 모든 가치를 잃는 것은 아닙니다. 따라서 이들의 처리 방법을 신중히 고려하십시오.
최소한, 새로운 대체 매체만 사용하여 파일 시스템의 모든 파일을 복구하기에 충분한 새 복구 지점 파일을 축적할 때까지 구 매체를 보관하십시오.
스토리지 공간이 허용한다면 구 매체를 무기한으로 보관하십시오. 호환 드라이브를 사용할 수 있는 한, 구 매체는 유용한 백업 및 복구 리소스가 될 수 있습니다.
라이브러리 공간이 부족한 경우 구 매체를 내보내고 오프사이트 스토리지에 보관하십시오.
구 매체를 재사용할 수 있고 보유 데이터가 더 이상 필요하지 않으면 구 볼륨에 레이블을 재지정하십시오. 예를 들어, 이전 Oracle StorageTek T10000C 드라이브의 매체에 레이블을 재지정하여 새로운 T10000D 드라이브와 함께 사용할 수 있습니다.
그렇지 않고 구 볼륨이나 매체의 데이터에 더 이상 남은 가치가 없으면 라이브러리에서 볼륨을 내보내고 적절히 처리하십시오.