이 장에서는 개별 파일을 파일 시스템에 복원하기 위한 절차를 설명합니다. 다음 항목을 다룹니다.
복구 지점 파일은 손실되거나 손상된 파일을 복구하는 가장 빠르고 완전하고 신뢰할 수 있으며 가장 덜 수고로운 방법입니다. 따라서 복구 지점 파일이 사용 가능한 경우 다음과 같이 수행하십시오.
파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
아직 그렇게 하지 않은 경우 아카이브 및 재활용 프로세스 중지의 절차를 사용하여 아카이브 및 재활용을 중지합니다
대상 파일 시스템에서 복구된 파일을 보관할 임시 복구 디렉토리를 만듭니다.
이 예에서는 다시 만든 파일 시스템인 /hsmfs1에 대한 마운트 지점 아래에 임시 디렉토리 restore를 만듭니다.
root@solaris:~# mkdir /hsmfs1/restore
아카이버가 임시 디렉토리에서 아카이브하지 않도록 합니다. archive -r -n directory 명령을 사용합니다. 설명:
-r -n은 지정된 디렉토리 안이나 아래에 있는 파일의 아카이빙을 재귀적으로 사용 안함으로 설정합니다.
directory는 임시 복구 디렉토리의 경로 및 디렉토리 이름입니다.
root@solaris:~# archive -r -n /hsmfs1/restore
임시 복구 디렉토리로 변경합니다.
root@solaris:~# cd /hsmfs1/restore
사용 가능한 최근 복구 지점 파일을 찾습니다.
이 예에서는 독립된 파일 시스템 /zfs1에서 잘 알려진 위치인 hsmfs1_recovery 하위 디렉토리에 파일 시스템 hsmfs1에 대한 날짜별 복구 지점 파일을 만들었습니다. 따라서 최신 파일 20150324를 쉽게 찾을 수 있습니다.
root@solaris:~# dir /zfs1/hsmfs1_recovery/ 20150321 20150322 20150323 20150324 root@solaris:~#
복구해야 하는 파일이 복구 지점 파일에 있는지 확인합니다. samfsrestore -t -f recovery-point 명령의 출력에서 필요한 파일을 검색합니다. 설명:
-t는 목차를 표시합니다.
-f recovery-point-file은 선택한 복구 지점 파일의 경로와 이름을 지정합니다.
이 예에서는 genw445 파일을 복구하려고 합니다. 따라서 samfsrestore -t 명령을 복구 지점 파일 /zfs1/hsmfs1_recovery/20150324와 함께 실행합니다. 검색을 단순화하기 위해 samfsrestore -t의 출력을 Solaris grep 명령 및 정규 표현식 "genw445"에 연결합니다(아래 명령은 한 라인으로 입력하며 줄바꿈이 백슬래시로 이스케이프되어 있음).
root@solaris:~# samfsrestore -t -f /zfs1/hsmfs1_recovery/20150324 | \ grep "genw445" ./genfiles/genw445 root@solaris:~#
파일의 inode 정보를 현재 디렉토리에 복원합니다. samfsrestore -f recovery-point file 명령을 사용합니다. 설명:
-f recovery-point-file은 선택한 복구 지점 파일의 경로와 이름을 지정합니다.
file은 복구 지점 파일이 복구하고자 하는 파일에 대해 나열하는 정확한 경로와 이름을 지정합니다.
이 예에서는 ./genfiles/genw445를 복구 지점 파일 /zfs1/hsmfs1_recovery/20150324에서 복구합니다(아래 명령은 한 라인으로 입력하며 줄바꿈이 백슬래시로 이스케이프되어 있음).
root@solaris:~# samfsrestore -f /zfs1/hsmfs1_recovery/20150324 \ ./genfiles/genw445 root@solaris:~#
파일이 올바르게 복원되었는지 확인합니다. sls -D file 명령을 사용합니다. 여기서 file은 임시 복구 디렉토리에 대한 파일의 상대 경로와 이름을 지정합니다.
이 예에서는 genfiles/genw445 파일이 임시 디렉토리 hsmfs1/restore/로 복구되었습니다.
root@solaris:~# sls -D genfiles/genw445 genfiles/genw445: mode: -rw-r--r-- links: 1 owner: data group: hsmfs1 length: 14975 inode: 25739.1 offline; archdone; copy 1: ---- Mar 4 11:55 8ae.1 xt 000000 copy 2: ---- Mar 4 15:51 cd3.7f57 xt 000000 access: Mar 4 11:55 modification: Mar 4 21:50 changed: Mar 4 11:50 attributes: Mar 4 21:50 creation: Mar 4 11:50 residence: Mar 4 21:50 root@solaris:~#
파일이 올바르게 복원되면 파일 시스템에서 올바른 위치로 이동합니다.
이 예에서는 genw445 파일을 임시 작업 디렉토리 hsmfs1/restore/genfiles/에서 hsmfs1genfiles/ 안의 원래 위치로 이동합니다.
root@solaris:~# mv -f genfiles/genw445 /hsmfs1/genfiles/genw445 root@solaris:~#
모든 누락된 파일이 복구될 때까지 이 절차를 반복합니다.
복구 절차를 완료합니다. 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.
일정한 개수 이상의 파일을 복구할 때 아카이버 로그 및/또는 매체 마이그레이션 로그를 사용하는 것은 언제나 번거롭고 노력이 많이 드는 프로세스입니다. 따라서 가급적이면 복구 지점으로 필요한 파일을 복원할 수 없는 경우에만 이 절의 절차를 사용하십시오.
아카이브 매체에서 파일을 복구하는 프로세스는 기본적으로 모든 경우에 동일하지만 파일 유형에 따라 세부 사항이 달라질 수 있습니다. 따라서 복원하는 파일 유형에 알맞은 절차를 선택하십시오.
매체에서 복사본을 복구할 때 예상하는 정확한 위치로 파일을 복원하지 못할 수 있습니다. 파일은 아카이브 복사본이 만들어진 시점의 해당 위치로 복원됩니다. 따라서 이후에 이동된 파일은 손실된 당시에 있었던 디렉토리로 복원되지 않습니다.
복구해야 하는 각 파일에 대해 다음과 같이 수행하십시오.
아직 그렇게 하지 않은 경우 파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
아직 그렇게 하지 않은 경우 아카이브 및 재활용 프로세스 중지의 절차를 사용하여 아카이브 및 재활용을 중지합니다
복원하는 파일 시스템의 루트 디렉토리로 변경합니다.
Oracle HSM 아카이브 파일은 파일 시스템 루트 디렉토리에 상대적인 복사본을 저장합니다. 따라서 원래 위치로 복원하려면 루트 디렉토리에서 복원하는 것이 좋습니다.
이 예에서는 hsmfs1 파일 시스템의 루트로 변경합니다.
root@solaris:~# cd /hsmfs1 root@solaris:~#
정규 파일이 마지막으로 아카이브된 기간 동안의 아카이버 로그를 가지고 있는 경우 파일에 대한 최근 항목을 찾습니다.
첫번째 예에서는 정규(유형 f) 파일 genA0의 항목을 찾습니다.
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
두번째 예에서는 정규(유형 f) 파일 spcC4의 항목을 찾습니다.
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0
필요한 파일의 로그 항목을 찾으면 매체 유형, 매체의 볼륨 일련 번호 및 파일 시스템의 루트 디렉토리에 대한 파일의 상대 경로와 이름을 메모합니다.
첫번째 예에서는 genA0 파일이 LTO(li) 테이프 볼륨(VSN(볼륨 일련 번호)이 VOL004)에 있습니다. 이 파일은 원래 파일 시스템 디렉토리 /hsmfs1/genfiles/에 저장되었습니다.
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
두번째 예에서는 spcC4 파일이 디스크 아카이브(dk)(볼륨 일련 번호가 DISKVOL1)에 있습니다. 이 파일은 원래 파일 시스템 디렉토리 /hsmfs1/socfiles/에 저장되었습니다.
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0
필요한 파일이 마그네틱 테이프와 같이 순차 액세스 매체에 있는 경우에도 아카이브(tar) 파일의 시작 위치를 나타내는 16진수 값을 메모합니다.
이 예에서는 genA0 파일이 0x212(212) 위치에서 시작하는 테이프에 있습니다.
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
필요한 파일이 아카이브 디스크와 같이 랜덤 액세스 매체에 저장된 경우 볼륨 일련 번호에 대한 tar 파일의 상대 경로와 파일 이름을 메모합니다.
이 예에서는 디스크 볼륨이 DISKVOL1인 루트 디렉토리 바로 아래의 f2 하위 디렉토리에 spcC4 파일이 있습니다.
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0
복원하는 파일이 디스크 매체에 아카이브된 경우 누락되거나 손상된 파일의 아카이브 복사본을 디스크 볼륨의 tar 파일에서 추출합니다. star -xv -f tarfile file 명령을 사용합니다. 설명:
tarfile은 아카이브 파일 이름입니다.
file은 복원해야 하는 파일의 파일 시스템 루트 디렉토리에 대한 상대 경로와 이름입니다.
star 명령은 지정된 파일을 아카이브 파일에서 복원하는 GNU tar의 향상된 Oracle HSM 버전입니다.
이 예에서는 데이터 파일 socfiles/spcC4를 tar 파일 DISKVOL1/f2에서 추출합니다. 파일이 /hsmfs1/socfiles/spcC4에 복원됩니다.
root@solaris:~# star -xvf DISKVOL1/f2 socfiles/spcC4
필요한 파일을 디스크 아카이브에서 복원한 경우 필요한 파일이 모두 복원될 때까지 계속 손실 및 손상된 정규 파일을 복원합니다.
복원하는 파일이 마그네틱 테이프와 같이 이동식 매체에 아카이브된 경우 복원된 파일 시스템에서 임시 아카이브 파일을 보관할 디렉토리를 만듭니다.
이 예에서는 /hsmfs1/tars 디렉토리를 만듭니다.
root@solaris:~# mkdir /hsmfs1/tars
아카이브된 복사본을 보관하는 아카이브 파일에 대한 tar 헤더의 시작 위치에 매체를 두고 매체에서 메모리로 아카이브를 읽습니다. request -m media-type -v volume-serial-number -p 0xposition path/requestfile 명령을 사용합니다. 여기서
-m media-type은 부록 B에 나열된 2자리 매체 유형 코드 중 하나를 지정합니다.
-v volume-serial-number는 매체 볼륨을 식별하는 6자리 영숫자 코드를 지정합니다.
-p 0xposition은 아카이버 로그 항목에서 메모한 16진수 시작 위치를 지정합니다.
path는 임시 복구 디렉토리에 대한 경로입니다.
requestfile은 request 명령이 매체에서 읽는 인 메모리 tar 파일에 사용할 이름입니다.
이 예에서는 LTO(li) 볼륨 VOL012의 0x78 위치에서 시작되는 요청 파일 /hsmfs1/tars/currentrequest를 만듭니다.
root@solaris:~# request -m li -v VOL012 -p 0x78 /hsmfs1/tars/currentrequest
누락되거나 손상된 파일의 아카이브 복사본을 이전 단계에서 만든 인 메모리 tar 파일에서 추출합니다. star -xv -f requestfile 명령을 사용합니다. 설명:
requestfile은 인 메모리 tar 파일의 이름입니다.
file은 복원해야 하는 파일의 파일 시스템 루트 디렉토리에 대한 상대 경로와 이름입니다.
star 명령은 요청 파일(아카이브 파일의 인 메모리 복사본)에서 지정된 파일을 복원하는 GNU tar의 향상된 Oracle HSM 버전입니다.
이 예에서는 데이터 파일 genfiles/genA0을 요청 파일 tars/currentrequest에서 추출합니다. 파일이 /hsmfs1/genfiles/genA0에 복원됩니다.
root@solaris:~# star -xvf tars/currentrequest genfiles/genA0
필요한 파일 속성을 설정합니다.
samfsdump 또는 qfsdump 복구 지점 파일을 사용하지 않고 tar 파일에서 파일을 복원할 경우 원본 파일 속성이 손실됩니다. 기본 속성값을 사용하여 해당 파일에 대해 .inodes 파일을 처음부터 만들어야 합니다.
모든 필요한 파일이 복구될 때까지 이 절차를 반복합니다.
필요한 경우 손실 및 손상된 세그먼트 파일 및/또는 볼륨 오버플로우 파일을 복원합니다.
그렇지 않으면 복구 절차를 마칩니다. 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.
세그먼트화된 파일 복원은 정규 파일 복원과 상당히 유사합니다. 하지만 파일 자체보다 개별 세그먼트를 복구하게 됩니다. 따라서 파일을 복원하려면 세그먼트를 단일 파일로 리어셈블링한 다음 결과를 다시 세그먼트화해야 합니다. 복구해야 하는 각 파일에 대해 다음과 같이 수행하십시오.
아직 그렇게 하지 않은 경우 파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
아직 그렇게 하지 않은 경우 아카이브 및 재활용 프로세스 중지의 절차를 사용하여 아카이브 및 재활용을 중지합니다.
세그먼트화된 파일이 마지막으로 아카이브된 기간 동안의 아카이버 로그가 있을 경우 세그먼트화된(유형 S) 파일에 대한 항목을 검색합니다. 필요한 파일의 세그먼트에 대한 최신 항목을 선택합니다.
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/03 14:04:11 li VOL013 all.1 2476f.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51
세그먼트에 대한 최신 항목을 찾은 후에는 다음 세부정보를 메모합니다.
매체 유형
파일을 저장하는 매체 볼륨의 볼륨 일련 번호
세그먼트가 포함된 아카이브(tar) 파일의 16진수 시작 위치
파일 시스템의 루트 디렉토리에 대한 세그먼트화된 파일의 상대 경로 및 이름
파일에 있는 세그먼트 수
이 예에서는 dat011 파일이 3개의 세그먼트(1, 2 및 3)로 나뉩니다. 3개의 세그먼트는 모두 하나의 LTO(li) 테이프 볼륨(볼륨 일련 번호 VOL013)에 있는 3개의 아카이브 파일에 저장됩니다. 3개의 아카이브 파일은 0x76a(76a), 0x2476f(2476f) 및 0x1409aa4(1409aa4) 위치에서 시작됩니다.
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/03 14:04:11 li VOL013 all.1 2476f.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51
복원하는 파일 시스템의 루트 디렉토리로 변경합니다.
Oracle HSM 아카이브 파일은 파일 시스템 루트 디렉토리에 상대적인 복사본을 저장합니다. 따라서 원래 위치로 복원하려면 루트 디렉토리에서 복원하는 것이 좋습니다.
이 예에서는 hsmfs1 파일 시스템의 루트로 변경합니다.
root@solaris:~# cd /hsmfs1
복원된 파일 시스템에서 임시 아카이브 파일을 보관할 디렉토리를 만듭니다.
이 예에서는 /hsmfs1/tars 디렉토리를 만듭니다.
root@solaris:~# mkdir /hsmfs1/tars
하나 이상의 파일 세그먼트의 아카이브된 복사본을 보관하는 각 아카이브 파일의 시작 위치에 매체를 두고 매체에서 메모리로 아카이브를 읽습니다. request -m media-type -v volume-serial-number -p 0xposition path/requestfile 명령을 사용합니다. 여기서
-m media-type은 부록 B에 나열된 2자리 매체 유형 코드 중 하나를 지정합니다.
-v volume-serial-number는 매체 볼륨을 식별하는 6자리 영숫자 코드를 지정합니다.
-p 0xposition은 아카이버 로그 항목에서 메모한 16진수 시작 위치를 지정합니다.
path는 임시 복구 디렉토리에 대한 경로입니다.
requestfile은 request 명령이 매체에서 읽는 인 메모리 tar 파일에 사용할 이름입니다.
이 예에서는 두 개의 요청 파일을 만들어야 합니다. 첫번째 요청 파일인 /hsmfs1/tars/request76a는 LTO(li) VOL013의 0x76a 위치에서 시작되는 아카이브 파일을 로드합니다. 이 아카이브에는 처음 두 세그먼트가 모두 포함됩니다. 두번째 요청 파일인 /hsmfs1/tars/request1409aa4는 이 경우 동일한 볼륨(세그먼트는 라이브러리의 어느 볼륨에나 상주할 수 있음)에 있는 0x1409aa4 위치에서 아카이브 파일을 로드합니다.
root@solaris:~# request -m li -v VOL013 -p 0x76a /hsmfs1/tars/request76a root@solaris:~# request -m li -v VOL013 -p 0x1409aa4 \ /hsmfs1/tars/request1409aa4
누락되거나 손상된 파일에 대한 백업 복사본의 각 세그먼트를 이전 단계에서 만든 인 메모리 tar 파일에서 추출합니다. star -xv -f requestfile segment 명령을 사용합니다. 여기서 requestfile은 인 메모리 tar 파일의 이름이고 segment는 복원해야 하는 파일에 대한 각 세그먼트의 파일 시스템 루트 디렉토리에 대한 상대 경로와 이름입니다.
star 명령은 요청 파일을 사용하여 가리키는 아카이브 파일에서 지정된 파일을 복원하는 GNU tar의 향상된 Oracle HSM 버전입니다.
이 예에서는 데이터 파일 bf/dat011의 세 세그먼트 중 두 개를 요청 파일(인 메모리 tar 파일) tars/request76a에서 추출하고, 한 개를 요청 파일 tars/request1409aa4에서 추출합니다. 파일이 세 개의 분리된 조각으로 /hsmfs1/bf/dat011/ 디렉토리에 복원됩니다.
root@solaris:~# star -xvf tars/request76a bf/dat011/1 root@solaris:~# star -xvf tars/request76a bf/dat011/2 root@solaris:~# star -xvf tars/request1409aa4 bf/dat011/3
/hsmfs1/bf/dat011의 내용을 나열하면 각 복원된 세그먼트에 대해 순차적으로 번호가 지정된 하나의 파일을 보게 됩니다.
root@solaris:~# ls /hsmfs/bf/dat011 total 40968 -rw-rw---- 1 root other 10485760 Mar 5 17:06 1 -rw-rw---- 1 root other 10485760 Mar 5 17:06 2 -rw-rw---- 1 root other 184 Mar 5 17:07 3 root@solaris:~#
복원된 세그먼트를 하나의 세그먼트화되지 않은 임시 파일로 리어셈블링합니다.
이 예에서는 /hsmfs1/bf/dat011/ 디렉토리의 세 세그먼트를 연결하여 /hsmfs1/bf/dat011file 파일을 만듭니다.
root@solaris:~# cat /hsmfs/bf/dat011/1 /hsmfs/bf/dat011/2 \ /hsmfs/bf/dat011/3 > /hsmfs/bf/dat011file root@solaris:~#
/hsmfs1/bf/의 내용을 나열하면 세그먼트가 포함된 디렉토리와 함께 새로운 파일이 나타납니다.
root@solaris:~# ls -l /hsmfs/bf/dat011* drwxr-xr-x 2 root root 4096 Mar 5 17:06 dat011 -rw-rw---- 1 root other 20971704 Mar 5 17:14 dat011file root@solaris:~#
세그먼트 및 해당 세그먼트가 포함된 디렉토리를 제거합니다.
root@solaris:~# rm -r /hsmfs/bf/dat011/ root@solaris:~#
세그먼트화된 파일의 원래 경로와 이름을 사용하여 빈 파일을 만듭니다. touch file 명령을 사용합니다. 여기서 file은 원래 경로와 파일 이름입니다.
이 예에서는 복원 중인 세그먼트 파일의 원래 이름인 /hsmfs/bf/dat011로 빈 파일을 만듭니다.
root@solaris:~# touch /hsmfs/bf/dat011 root@solaris:~#
새로 만든 빈 파일에서 Oracle HSM 세그먼트 속성을 설정합니다. segment -l segment-length file 명령을 사용합니다. 여기서 segment-length는 아카이버 로그 항목에서 메모한 세그먼트 길이이고 file은 세그먼트화된 파일의 원래 경로와 이름입니다.
이 예에서는 아카이버 로그가 dat011 파일에 대한 세그먼트 길이를 10485760(파일이 세번째 세그먼트에서 끝나므로 매체의 데이터 길이가 세그먼트 길이보다 작음)으로 표시합니다.
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/03 14:04:11 li VOL013 all.1 76a.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51
따라서 빈 파일에 대한 세그먼트 길이를 10485760으로 설정합니다.
root@solaris:~# segment -l 10485760 /hsmfs/bf/dat011 root@solaris:~#
세그먼트화되지 않은 임시 파일을 빈 세그먼트화된 파일에 복사합니다.
이 예에서는 dat011file을 dat011에 복사합니다.
root@solaris:~# cp /hsmfs/bf/dat011file /hsmfs/bf/dat011 root@solaris:~#
sls -2K hsmfs/bf/dat011 명령을 사용하여 세그먼트를 나열하면 다음과 같이 나열됩니다. 따라서 파일이 복원되었습니다.
root@solaris:~# sls -2K /hsmfs/bf/dat011 -rw-rw---- 1 root other 20971704 Mar 5 17:12 hsmfs/bf/dat011 ---------- ----- sI {3,0,0,0} -rw-rw---- 1 root other 10485760 Mar 5 17:12 hsmfs/bf/dat011/1 ---------- ----- sS -rw-rw---- 1 root other 10485760 Mar 5 17:12 hsmfs/bf/dat011/2 ---------- ----- sS -rw-rw---- 1 root other 184 Mar 5 17:12 hsmfs/bf/dat011/3 ---------- ----- sS
기타 필요한 파일 속성을 설정합니다.
samfsdump 또는 qfsdump 복구 지점 파일을 사용하지 않고 tar 파일에서 파일을 복원할 경우 원본 파일 속성이 손실됩니다. 기본 속성값을 사용하여 해당 파일에 대해 .inodes 파일을 처음부터 만들어야 합니다.
이제 파일이 복원되었습니다. 세그먼트화되지 않은 임시 파일을 삭제합니다.
이 예에서는 dat011file을 삭제합니다.
root@solaris:~# rm /hsmfs/bf/dat011file root@solaris:~#
모든 필요한 파일이 복구될 때까지 이 절차를 반복합니다.
복구 절차를 완료합니다. 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.
볼륨 오버플로우 파일은 매체 볼륨에 걸쳐 있는 정규 파일입니다. 따라서 볼륨 오버플로우 파일 복원은 다른 정규 파일 복원과 상당히 유사합니다. 하지만 아카이브에서 데이터 파일을 추출하기 전에 여러 볼륨에 상주하는 아카이브 파일의 섹션을 디스크의 단일 아카이브 파일로 합쳐야 합니다. 따라서 복구해야 하는 각 파일에 대해 다음과 같이 수행하십시오.
아직 그렇게 하지 않은 경우 파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
아직 그렇게 하지 않은 경우 아카이브 및 재활용 프로세스 중지의 절차를 사용하여 아카이브 및 재활용을 중지합니다.
볼륨 오버플로우 파일이 마지막으로 아카이브된 기간 동안의 아카이버 로그를 가지고 있는 경우 파일에 대한 최근 항목을 찾습니다. 매체의 볼륨 일련 번호, 파일에 대한 각 섹션의 길이, 파일 시스템의 루트 디렉토리에 대한 파일의 상대 경로와 이름 및 파일의 섹션 수를 메모합니다.
이 예에서는 /hsmfs1/rf/rf81 파일이 VOL036 및 VOL034의 두 볼륨에 상주하는 f 유형의 정규 파일이고 0 및 1의 두 섹션을 가지므로 볼륨 오버플로우임을 알 수 있습니다.
A 2015/03/03 18:28:51 li VOL036 all.1 12d.1 hsmfs1 11731.1 89128448 rf/rf81 f 0 210 A 2013/08/23 18:28:51 li VOL034 all.1 15f.0 hsmfs1 11731.1 525271552 rf/rf81 f 1 220
복원하는 파일 시스템의 루트 디렉토리로 변경합니다.
Oracle HSM 아카이브 파일은 파일 시스템 루트 디렉토리에 상대적인 복사본을 저장합니다. 따라서 원래 위치로 복원하려면 루트 디렉토리에서 복원하는 것이 좋습니다.
이 예에서는 hsmfs1 파일 시스템의 루트로 변경합니다.
root@solaris:~# cd /hsmfs1
진행하기 전에 파일 시스템에 복구하는 파일 크기의 두 배 이상의 파일을 수용할 만큼 충분한 여유 공간이 있는지 확인합니다.
이 예의 파일인 rf/rf81의 경우, 파일에 대한 두 섹션의 크기를 기준으로 약 1.2GB의 여유 공간이 필요합니다(2 x (89128448 + 525271552) = 1228800000바이트).
복원된 파일 시스템에서 임시 아카이브 파일을 보관할 디렉토리를 만듭니다.
이 예에서는 /hsmfs1/tars 디렉토리를 만듭니다.
root@solaris:~# mkdir /hsmfs1/tars
하나 이상의 파일 세그먼트의 아카이브된 복사본을 보관하는 각 아카이브 파일의 시작 위치에 매체를 두고 매체에서 메모리로 아카이브를 읽습니다. request -m media-type -v volume-serial-number -p 0xposition path/requestfile 명령을 사용합니다. 여기서
-m media-type은 부록 B에 나열된 2자리 매체 유형 코드 중 하나를 지정합니다.
-v volume-serial-number는 매체 볼륨을 식별하는 6자리 영숫자 코드를 지정합니다.
-p 0xposition은 아카이버 로그 항목에서 메모한 16진수 시작 위치입니다.
path는 임시 복구 디렉토리에 대한 경로입니다.
requestfile은 request 명령이 매체에서 읽는 인 메모리 tar 파일에 사용할 이름입니다.
이 예에서는 두 개의 요청 파일을 만듭니다. 첫번째 요청 파일, /hsmfs1/tars/requestVOL036은 LTO(li) VOL036의 0x12d 위치에서 시작하는 아카이브 파일을 로드합니다. 두번째 요청 파일인 /hsmfs1/tars/requestVOL034는 LTO(li) VOL034의 0x15f 위치에서 시작되는 아카이브 파일을 로드합니다.
root@solaris:~# request -m li -v VOL036 -p 0x12d /hsmfs1/tars/requestVOL036 root@solaris:~# request -m li -v VOL034 -p 0x15f /hsmfs1/tars/requestVOL034
만든 각 인 메모리 tar 파일을 아카이브 파일의 섹션으로 디스크에 저장합니다. dd if= requestfile of=archive_section 명령을 사용합니다. 여기서 requestfile은 인 메모리 tar 파일의 경로와 이름이고 archive_section은 아카이브 파일에 대한 각 섹션의 경로와 이름입니다.
이 예에서는 요청 파일(인 메모리 tar 파일), tars/requestVOL036 및 tars/requestVOL034를 tars/archive_part1 및 tars/archive_part2로 저장합니다.
root@solaris:~# dd if=tars/requestVOL036 of=tars/archive_part1 root@solaris:~# dd if=tars/requestVOL034 of=tars/archive_part2 root@solaris:~#
섹션을 하나의 아카이브 파일로 리어셈블링합니다.
이 예에서는 두 섹션 tars/archive_part1 및 tars/archive_part2를 연결하여 하나의 아카이브 파일 /tars/archive_complete를 만듭니다.
root@solaris:~# cat tars/archive_part1 tars/archive_part2 > \ tars/archive_complete root@solaris:~#
누락되거나 손상된 볼륨 오버플로우 파일의 백업 복사본을 이전 단계에서 만든 아카이브(tar) 파일에서 추출합니다. star -xv -f tarfile file 명령을 사용합니다. 여기서 tarfile은 아카이브 파일의 이름이고 file은 복원해야 하는 볼륨 오버플로우 파일의 파일 시스템 루트 디렉토리에 대한 상대 경로와 이름입니다.
star 명령은 요청 파일을 사용하여 가리키는 아카이브 파일에서 지정된 파일을 복원하는 GNU tar의 향상된 Oracle HSM 버전입니다.
이 예에서는 볼륨 오버플로우 파일 rf/rf81을 tar 파일 tars/archive_complete에서 추출합니다.
root@solaris:~# star -xvf tars/archive_complete rf/rf81
기타 필요한 파일 속성을 설정합니다.
samfsdump 또는 qfsdump 복구 지점 파일을 사용하지 않고 tar 파일에서 파일을 복원할 경우 원본 파일 속성이 손실됩니다. 기본 속성값을 사용하여 해당 파일에 대해 .inodes 파일을 처음부터 만들어야 합니다.
이제 볼륨 오버플로우 파일이 복원되었습니다. 임시 파일을 삭제합니다.
이 예에서는 dat011file을 삭제합니다.
root@solaris:~# rm tars/archive_* root@solaris:~#
모든 필요한 파일이 복구될 때까지 이 절차를 반복합니다.
복구 절차를 완료합니다. 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.
손상된 아카이브 복사본은 디스크 캐시로 다시 스테이징할 수 없는 파일의 복사본입니다. 때로는 간헐적인 하드웨어 관련 I/O 문제로 인해 파일이 단순히 스테이징을 실패하고 쉽게 해결할 수도 있습니다. 그렇지 않은 경우 손상된 복사본은 손상되고 데이터를 복구할 수 없습니다. 이러한 경우 유일한 옵션은 대체 복사본에서 파일을 복구하는 것입니다.
손상된 복사본을 식별하고 관리하려면 다음과 같이 수행하십시오.
손상된 아카이브 복사본이 있는 파일을 식별합니다. sfind mountpoint -any_copy_d 명령을 사용합니다. 여기서 mountpoint는 복구된 파일 시스템이 마운트된 디렉토리입니다.
이 예에서는 /hsmfs1 디렉토리에서 검색을 시작하고 손상된 복사본이 있는 3개의 파일을 찾습니다.
root@solaris:~# sfind /hsmfs1 -any_copy_d ./genfiles/ab09 ./genfiles/ab11 ./genfiles/ay12 root@solaris:~#
찾은 각 파일에 대해 손상된 복사본을 식별합니다. sls -D file 명령을 사용합니다. 여기서 file은 확인할 경로와 파일 이름입니다.
손상된 복사본은 D로 플래그가 표시됩니다. 이 예에서는 /hsmfs1/genfiles/ab09의 copy 2 및 /hsmfs1/genfiles/ab11의 copy 1이 손상되었습니다.
root@solaris:~# sls -D /hsmfs1/genfiles/ab09 /hsmfs1/genfiles/ab09: mode: -rw-r----- links: 1 owner: root group: other length: 306581 admin id: 0 inode: 11748.11 project: system(0) copy 1: ---- Mar 11 13:52 76f.421bc li VOL011 copy 2: ---D Mar 31 14:02 286.1324f li VOL021 access: Mar 11 13:50 modification: Mar 11 13:50 changed: Mar 11 13:50 attributes: Mar 11 13:50 creation: Mar 11 13:50 residence: Mar 11 13:50 root@solaris:~# sls -D /hsmfs1/genfiles/ab11 /hsmfs1/genfiles/ab11: mode: -rw-r----- links: 1 owner: root group: other length: 380051 admin id: 0 inode: 1460.1 project: system(0) copy 1: ---D Mar 01 10:21 431.21bc6 li VOL024 access: Mar 01 10:21 modification: Mar 01 10:21 changed: Mar 01 10:21 attributes: Mar 01 10:21 creation: Mar 01 10:21 residence: Mar 01 10:21 root@solaris:~#
대체 복사본이 있는 경우 손상된 복사본을 아카이브 해제합니다. unarchive -c CopyNumber file 명령을 사용합니다. 여기서 CopyNumber는 복사본 번호를 나타내는 정수이고 file은 손상된 파일의 경로와 파일 이름입니다. 여기에서 중지합니다.
손상된 복사본을 아카이브 해제할 경우 Oracle HSM는 나머지 복사본에서 스테이징하고 다음에 아카이버 프로세스가 실행될 때 추가 아카이브 복사본을 만듭니다. 이 예에서는 /hsmfs1/genfiles/ab09의 다른 손상되지 않은 복사본이 있으므로 손상된 복사본인 copy 2를 아카이브 해제합니다.
root@solaris:~# unarchive -c 2 /hsmfs1/genfiles/ab09 root@solaris:~#
다른 복사본이 없는 경우 손상된 복사본을 손상 해제합니다. undamage -cCopyNumber file 명령을 사용합니다. 여기서 CopyNumber는 복사본 번호를 나타내는 정수이고 file은 손상된 파일의 경로와 파일 이름입니다.
때로는 간헐적인 하드웨어 관련 I/O 오류로 인해 파일이 스테이징을 실패합니다. 손상 플래그를 지우고 다시 스테이징하면 문제가 해결될 수 있습니다. 이 예에서는 /hsmfs1/genfiles/ab11의 복사본이 하나만 있습니다.
root@solaris:~# undamage -c1 /hsmfs1/genfiles/ab11
복사본 스테이징을 시도합니다. stage -c CopyNumber -I file 명령을 사용합니다. 여기서 CopyNumber는 복사본 번호를 나타내는 정수이고 file은 파일의 경로와 파일 이름입니다.
선택적 -I(immediate) 매개변수는 스테이징 작업을 대기열의 맨 위로 올립니다.
root@solaris:~# stage -c 1 -I /hsmfs1/genfiles/ab11
스테이징을 성공할 경우 여기에서 중지합니다.
스테이징을 다시 실패할 경우 Oracle HSM는 손상 플래그를 다시 설정합니다. 손상된 복사본에 대한 sls -D 명령 출력에서 주요 inode 번호를 메모합니다.
이 예에서는 /hsmfs1/genfiles/ab11 파일의 inode 번호가 1460입니다.
root@solaris:~# sls -D /hsmfs1/genfiles/ab11 /hsmfs1/genfiles/ab11: mode: -rw-r----- links: 1 owner: root group: other length: 380051 admin id: 0 inode: 1460.1 project: system(0) copy 1: ---D Mar 01 10:21 431.21bc6 li VOL024 ... root@solaris:~#
가능한 원인을 찾습니다. 먼저, Oracle HSM /var/adm/sam-log 파일에서 손상된 복사본이 있는 파일의 inode에 해당하는 스테이징 관련 메시지를 찾습니다.
검색은 다양한 방법으로 수행할 수 있습니다. 이 예에서는 Solaris cat 명령을 사용하여 로그 파일의 내용을 나열하고 출력을 grep 및 inode 번호와 일치하는 정규 표현식에 연결합니다. 두 가지 메시지를 찾았습니다. 둘 다 I/O 오류를 나타내고 하나는 테이프 드라이브 중 하나인 장비(eq) 서수 번호 804를 명시적으로 나타냅니다.
root@solaris:~# cat /var/adm/sam-log | grep "inode 1460" Mar 11 15:35:44 server1 genu-20[8899]: Stage request canceled for inode 1460 (eq 804): I/O error. Jan 11 15:35:44 server1 samfs[8894]: /sam4 inode 1460.1 - Archive copy 1 marked damaged: I/O error
/var/adm/sam-log 파일에서 특정 Oracle HSM 장비 서수 번호를 나타낼 경우 장치 로그 /var/opt/SUNWsamfs/devlog/drive-equipment-number를 검사합니다. 여기서 drive-equipment-number는 /var/adm/sam-log 파일에 나열된 서수 번호입니다.
문제가 특정 드라이브와 관련된 것으로 보일 경우 samcmd unavail drive-equipment-number 명령을 사용하여 스테이징 프로세스에서 해당 드라이브를 사용하지 못하도록 합니다. 그런 다음 복사본을 손상 해제하고 다시 스테이징을 시도합니다.
root@solaris:~# samcmd unavail 804 root@solaris:~# stage -c 1 -I /hsmfs1/genfiles/ab11 root@solaris:~# undamage -c1 /hsmfs1/genfiles/ab11 root@solaris:~#
스테이징을 다시 실패하거나 결함이 있는 드라이브가 하나가 아닌 것으로 보이는 경우 로그 항목을 사용하여 파일 복구에 설명된 대로 request 및 star 명령 또는 tar 및 dd와 같은 Solaris 유틸리티를 사용하여 복사본 복구를 시도합니다.
그래도 파일을 복구할 수 없고 데이터 값이 이를 보증하는 경우 데이터 복구 서비스를 받습니다. Oracle StorageTek 테이프 매체에 대한 지원이 필요한 경우 Oracle StorageTek 엔터프라이즈 테이프 데이터 복구 서비스를 받습니다. My Oracle Support(support.oracle.com)에 로그인합니다. 서비스 요청을 열고 요청 범주 아래에 있는 목록에서 테이프 드라이브 모델을 선택한 다음 하위 범위 아래에 있는 목록에서 Media Issues(매체 문제)를 선택합니다.
복구할 수 없는 파일일 경우 손상된 복사본을 아카이브 해제합니다. unarchive -c CopyNumber file 명령을 사용합니다. 여기서 CopyNumber는 복사본 번호를 나타내는 정수이고 file은 손상된 파일의 경로와 파일 이름입니다.
root@solaris:~# unarchive -c 1 /hsmfs1/genfiles/ab11 root@solaris:~#
로그 파일에 나타난 모든 드라이브 또는 매체 문제를 해결합니다.
이전 단계에서 아카이브, 스테이징 및 재활용 프로세스를 사용 안함으로 설정할 경우 지금 다시 사용으로 설정합니다. 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.
그렇지 않은 경우 여기서 중지합니다.