이 절에서는 전체 Oracle HSM 파일 시스템이 손상되거나 손실된 경우 사용하는 복구 프로세스를 설명합니다. 절차는 관련 파일 시스템의 유형 및 마련된 백업 유형 및 복구 준비에 따라 달라집니다. 그러나 수행해야 하는 두 가지 기본적인 작업이 있습니다.
시작하기 전에 Oracle HSM 메타데이터 서버의 손실로부터 복구하는 경우 계속 진행하기 전에 제 3 장에 설명된 대로 Oracle HSM 구성 복원을 완료합니다. 이 장의 절차에서는 파일 시스템 손실 이전에 Oracle HSM 소프트웨어가 정상적으로 설치 및 구성되어 있다고 간주합니다.
파일 및 디렉토리를 복구하려면 먼저 둘 곳이 있어야 합니다. 따라서 복구 프로세스의 첫번째 단계는 빈 대체 파일 시스템을 만드는 것입니다. 다음과 같이 하십시오.
sammkfs 명령을 사용하여 파일 시스템 다시 만들기파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
파일 시스템이 현재 마운트된 경우 마운트 해제합니다. umount mount-point 명령을 사용합니다. 여기서 mount-point는 파일 시스템이 마운트된 디렉토리입니다.
이 예에서는 /hsmfs1 파일 시스템을 마운트 해제합니다.
root@solaris:~# umount /hsmfs1 root@solaris:~#
/etc/opt/SUNWsamfs/mcf 파일을 텍스트 편집기에서 엽니다. 하드웨어 구성을 확인합니다. 하드웨어를 변경했어야 하는 경우 적절히 파일을 편집하고 변경사항을 저장합니다.
이 예에서는 2개의 실패한 디스크 장치에 대한 장비 식별자를 교체한 장치의 식별자로 바꿉니다. 장비 서수는 변경되지 않고 그대로 유지됩니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #----------------------- --------- --------- --------- ------ ------------- hsmfs1 100 ms hsmfs1 on /dev/dsk/c1t3d0s3 101 md hsmfs1 on /dev/dsk/c1t4d0s5 102 md hsmfs1 on # Tape library /dev/scsi/changer/c1t2d0 800 rb lib800 on .../lib800_cat /dev/rmt/0cbn 801 li lib800 on /dev/rmt/1cbn 802 li lib800 on :wq root@solaris:~#
mcf 파일에서 오류를 검사합니다. sam-fsd 명령을 사용합니다.
sam-fsd 명령은 Oracle HSM 구성 파일을 읽고 소프트웨어를 초기화합니다. 오류가 발견되면 실행을 중지합니다.
root@solaris:~# sam-fsd
sam-fsd 명령이 mcf 파일에서 오류를 찾을 경우 파일을 편집하여 오류를 해결하고 이전 단계에 설명된 대로 다시 검사합니다.
아래의 예에서는 sam-fsd가 장치에서 지정되지 않은 문제를 보고합니다. 장비 식별자 필드의 오타일 수 있습니다.
root@solaris:~# sam-fsd Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem qfsms sam-fsd: Problem with file system devices.
대개 이러한 오류는 부주의한 타이핑 실수의 결과입니다. 여기에서는 mcf 파일을 편집기에서 열면 두번째 md 장치인 장치 102에 대한 장비 이름의 슬라이스 번호 부분에서 0 대신에 문자 o를 입력했다는 것을 알 수 있습니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf ... qfsms 100 ms qfsms on /dev/dsk/c0t0d0s0 101 md qfsms on /dev/dsk/c0t3d0so 102 md qfsms on
오류를 해결하고 파일을 저장한 후 다시 검사합니다.
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf ... qfsms 100 ms qfsms on /dev/dsk/c0t0d0s0 101 md qfsms on /dev/dsk/c0t3d0s0 102 md qfsms on :wq root@solaris:~# sam-fsd
sam-fsd 명령이 오류 없이 실행될 경우 mcf 파일이 올바른 것입니다. 다음 단계로 진행하십시오.
이 예에서는 sam-fsd가 오류 없이 실행됩니다.
root@solaris:~# sam-fsd Trace file controls: sam-amld /var/opt/SUNWsamfs/trace/sam-amld ... Would start sam-archiverd() Would start sam-stagealld() Would start sam-stagerd() Would start sam-amld() root@solaris:~#
Oracle HSM 소프트웨어가 mcf 파일을 읽고 그에 따라 재구성하도록 지정합니다.
root@solaris:~# samd config Configuring SAM-FS root@solaris:~#
교체 파일 시스템을 만듭니다. sammkfs family-set-name 명령을 사용합니다. 여기서 family-set-name은 파일 시스템의 이름입니다.
이 예에서는 파일 시스템 hsmfs1을 다시 만듭니다.
root@solaris:~# sammkfs hsmfs1 Building 'hsmfs1' will destroy the contents of devices: /dev/dsk/c0t0d0s0 /dev/dsk/c0t3d0s0 Do you wish to continue? [y/N]yes total data kilobytes = ... root@solaris:~#
필요한 경우 파일 시스템에 대한 마운트 지점 디렉토리를 다시 만듭니다.
이 예에서는 /hsmfs1 디렉토리를 다시 만듭니다.
root@solaris:~# mkdir /hsmfs1 root@solaris:~#
운영체제의 /etc/vfstab 파일을 백업합니다.
root@solaris:~# cp /etc/vfstab /etc/vfstab.backup root@solaris:~#
텍스트 편집기에서 /etc/vfstab 파일을 엽니다. /etc/vfstab 파일에 복원하는 파일 시스템에 대한 마운트 매개변수가 포함되지 않은 경우 마운트 매개변수를 복원해야 합니다.
이 예에서는 Oracle HSM 서버가 교체 호스트에 설치됩니다. 따라서 파일에는 복원하는 파일 시스템 hsmfs1에 대한 마운트 매개변수가 포함되지 않습니다.
root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ...
가능하다면 마운트 매개변수를 복원해야 하는 경우 원래 /etc/vfstab 파일의 백업 복사본을 열고 필요한 라인을 현재 /etc/vfstab 파일에 복사합니다. 변경 작업이 완료되었으면 파일을 저장하고 편집기를 닫습니다.
이 예에서는 백업 복사본 /zfs1/sam_config/20140127/etc/vfstab가 있습니다. 따라서 백업 복사본에서 hsmfs1 파일 시스템에 대한 라인을 복사하고 현재 /etc/vfstab 파일에 붙여넣습니다.
root@solaris:~# vi /zfs1/sam_config/20140127/etc/vfstab.20140127 #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :q
root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :wq root@solaris:~#
파일 시스템을 마운트합니다.
이 예에서는 파일 시스템 hsmfs1을 마운트합니다.
root@solaris:~# mount /hsmfs1 root@solaris:~#
이제 디렉토리 및 파일 복원을 시작합니다.
기본 파일 시스템을 다시 만들었으면 디렉토리 및 파일 복원을 시작할 수 있습니다. 두 가지 가능한 방식이 있습니다.
정기적으로 복구 지점을 만들고 안전하게 저장한 경우 samfsdump(qfsdump) 복구 지점 파일에서 파일 및 디렉토리를 복원하는 것이 가장 좋습니다.
이 방식은 파일 시스템 메타데이터를 복원하므로 파일 시스템을 즉시 완전한 작동 상태로 되돌립니다. 아카이브 파일 시스템은 아카이브 매체의 데이터에 즉시 액세스하고 사용자가 파일에 액세스할 때 즉시 또는 필요에 따라 파일을 디스크 캐시에 다시 스테이징할 수 있습니다. 파일은 원래 속성으로 복원됩니다.
복구 지점에 메타데이터는 물론 데이터도 포함된 경우 이 방식은 타사 응용 프로그램으로 백업되지 않은 독립형(비아카이브) 파일 시스템을 복원할 수 있는 유일한 방법이기도 합니다.
복구 스크립트 및 Oracle HSM star 유틸리티를 사용하여 복구 지점 파일 없이 아카이브 매체에서 파일 및 디렉토리를 복원합니다.
samfsdump(qfsdump) 복구 지점 파일에서 파일 및 디렉토리 복원가능하면 언제나 사용 가능한 최근 복구 지점 파일을 기준으로 파일 시스템 복구 작업을 수행해야 합니다. 이 방식은 Oracle HSM 파일 시스템 실패로부터 복구하기 위한 가장 빠르고 신뢰할 수 있으며 철저하고 가장 덜 수고스러운 방법입니다. 따라서 복구 지점 파일이 있는 경우 다음과 같이 수행하십시오.
파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
아직 그렇게 하지 않은 경우 아카이브 및 재활용 프로세스 중지의 절차를 사용하여 아카이브 및 재활용을 중지합니다.
사용 가능한 최근 복구 지점 파일을 찾습니다.
이 예에서는 독립된 파일 시스템 /zfs1에서 잘 알려진 위치인 hsmfs1_recovery 하위 디렉토리에 파일 시스템 hsmfs1에 대한 날짜별 복구 지점 파일을 만들었습니다. 따라서 최신 파일 20140324를 쉽게 찾을 수 있습니다.
root@solaris:~# ls /zfs1/hsmfs1_recovery/ 20140321 20140322 20140323 20140324 root@solaris:~#
다시 만든 파일 시스템에 대한 마운트 지점 디렉토리로 변경합니다.
이 예에서는 다시 생성된 파일 시스템이 /hsmfs1에 마운트됩니다.
root@solaris:~# cd /hsmfs1 root@solaris:~#
현재 디렉토리에 상대적인 전체 파일 시스템을 복원합니다. samfsrestore -T -f recovery-point-file -g logfile 명령 또는 QFS 전용 명령 qfsrestore -T -f recovery-point-file -g logfile을 사용합니다. 설명:
-T는 명령이 종료될 때 처리된 파일과 디렉토리 수 및 오류 및 경고 수를 포함한 복구 통계를 표시합니다.
-f recovery-point-file은 선택한 복구 지점 파일의 경로와 이름을 지정합니다.
-g logfile은 복구 지점이 만들어질 때 온라인이었던 디렉토리 및 파일 목록을 만들고 logfile로 지정된 파일에 목록을 저장합니다.
아카이브 파일 시스템을 복원하는 경우 이 파일은 아카이브 매체에서 파일을 자동으로 스테이징하는 데 사용할 수 있으므로 디스크 캐시는 복구 지점이 만들어진 시점과 동일한 상태입니다.
이 예에서는 파일 시스템 hsmfs1을 복구 지점 파일 /zfs1/hsmfs1_recovery/20140324에서 복원합니다. /root/20140324.log 파일에 온라인 파일을 기록합니다(아래의 명령은 한 라인으로 입력하며 줄바꿈이 백슬래시로 이스케이프되어 있음).
root@solaris:~# samfsrestore -T -f /zfs1/hsmfs1_recovery/20140324 \ -g /root/20140324.log samfsdump statistics: Files: 52020 Directories: 36031 Symbolic links: 0 Resource files: 8 File segments: 0 File archives: 0 Damaged files: 0 Files with data: 24102 File warnings: 0 Errors: 0 Unprocessed dirs: 0 File data bytes: 0 root@solaris:~#
독립형(비아카이브) 파일 시스템을 복원한 경우 복구 지점 파일에 저장되었던 파일 시스템 메타데이터 및 파일 데이터가 복원됩니다. 여기에서 중지합니다.
그렇지 않으면 필요한 경우 아카이브된 파일을 재스테이징합니다.
대부분의 경우 파일 시스템 복구 이후 아카이브 매체에서 디스크로 파일을 다시 스테이징하지 마십시오. 사용자가 필요에 따라 파일에 액세스하여 스테이징하도록 하십시오.
이 방식은 사용자 필요에 따라 스테이징 우선 순위를 자동으로 지정하고 일정 시간 동안 오프라인이었을 수 있는 파일 시스템의 가용성을 극대화합니다. 필요한 파일만 즉시 스테이징되므로 전체 스테이징 노력이 일정 기간에 걸쳐 분산됩니다. 이 방식은 드라이브와 같은 파일 시스템 리소스가 높은 우선 순위의 작업(예: 새로운 파일 아카이브 및 긴급하게 필요한 사용자 데이터 스테이징)에 항상 사용될 수 있도록 합니다.
또한 이 방식은 복구와 관련된 관리 노력을 줄여줍니다.
오류 이전에 디스크 캐시에 있던 파일을 다시 스테이징해야 하는 경우 /opt/SUNWsamfs/examples/restore.sh logfile 명령을 사용합니다. 여기서 logfile은 samfsrestore(qfsrestore) 명령의 -g 옵션을 사용하여 만든 로그 파일의 경로와 파일 이름입니다.
restore.sh 스크립트는 로그 파일에 나열된 파일을 스테이징합니다. 이러한 파일은 samfsrestore(qfsrestore) 복구 지점 파일이 만들어질 때 온라인 상태였던 파일입니다.
수천 개의 파일을 스테이징해야 하는 경우 로그 파일을 여러 작은 파일로 분할하는 것을 고려해 보십시오. 그런 다음 각 파일에 대해 하나씩 restore.sh 스크립트를 실행하십시오. 그러면 스테이징 노력이 일정 기간에 걸쳐 분산되고 아카이브 및 사용자가 시작한 스테이징에 대한 간섭을 줄일 수 있습니다.
samfsrestore 프로세스는 테이프에서 해당 파일 시스템을 찾아 파일 시스템 내의 적절한 위치에 복원할 수 있도록 파일 시스템 메타데이터의 복사본을 복구 지점 파일에서 복원합니다. 하지만 복구 지점 파일은 파일 시스템이 손실되기 전에 생성됩니다. 따라서 불가피하게 메타데이터 중 일부는 복구 지점이 생성된 후 변경된 데이터 위치를 가리키는 것이 보통입니다. 파일 시스템은 이러한 파일의 레코드를 포함하고 있지만 그 내용을 찾을 수 없으므로 해당 파일에 각각 damaged 플래그를 설정합니다.
손상된 파일에 대한 데이터가 실제로 손실되는 경우도 있지만 복원된 메타데이터가 단지 오래된 경우도 있습니다. 단지 복원된 메타데이터가 현재 위치를 기록하지 않아 복원된 파일 시스템이 복구 지점 생성 후 아카이브되었거나 마이그레이션된 파일의 데이터를 찾지 못할 수도 있습니다. 이 경우 직접 데이터를 찾고 복원된 메타데이터를 업데이트하여 파일의 손상을 해제할 수 있습니다.
누락된 데이터를 찾고 메타데이터를 업데이트하며 파일 손상을 해제하려면 아카이버 로그 및 매체 마이그레이션 로그 파일(있는 경우)을 사용합니다. 다음과 같이 하십시오.
아직 그렇게 하지 않은 경우 파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
사용 가능한 최근 아카이버 로그 파일을 찾습니다.
서버에서 아카이버 로그를 여전히 사용할 수 있는 경우 최근 정보가 포함되어 있을 수 있습니다. 그렇지 않은 경우 백업 복사본을 사용해야 합니다.
이 예에서는 아카이버 로그 파일 hsmfs1.archiver.log가 서버의 /var/adm/ 하위 디렉토리에 있습니다. 또한 독립된 파일 시스템 /zfs1에서 잘 알려진 위치 hsmfs1_recovery/archlogs 하위 디렉토리에 날짜별 아카이버 로그 파일 복사본이 있습니다. 따라서 최근 파일인 hsmfs1.archiver.log 및 최근 백업인 20150324가 모두 있습니다.
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
파일이 최근에 교체 매체로 마이그레이션된 경우 마이그레이션 로그도 찾습니다.
매체 마이그레이션 로그는 migrationd.cmd 파일에 지정된 로깅 디렉토리에 있는 각 소스 볼륨에 대해 생성됩니다. 로그 이름은 media-type.vsn으로 지정됩니다. 여기서 media-type은 부록 B 장비 유형 용어집에 설명된 2자로 된 코드 중 하나이고, vsn은 소스 볼륨을 식별하는 6자로 된 영숫자 볼륨 일련 번호입니다.
매체 마이그레이션 로그 형식은 아카이버 로그와 동일한 복구 정보를 포함하며, 동일한 방식으로 사용될 수 있습니다. 몇 가지 형식 차이점에 대한 설명은 부록 A 아카이버 및 마이그레이션 로그 이해 항목을 참조하십시오.
새로 복원된 파일 시스템에서 손상된 파일을 식별합니다. sfind mountpoint -damaged 명령을 사용합니다. 여기서 mountpoint는 복구된 파일 시스템이 마운트된 디렉토리입니다.
이 예에서는 /hsmfs1 디렉토리에서 검색을 시작하고 6개의 손상된 파일을 찾습니다.
root@solaris:~# sfind /hsmfs1 -damaged ./genfiles/ay0 ./genfiles/ay1 ./genfiles/ay2 ./genfiles/ay5 ./genfiles/ay6 ./genfiles/ay9 root@solaris:~#
아카이버 로그의 최근 복사본에서 손상된 각 파일과 관련된 항목을 검색합니다. grep "file-name-expression" archiver-log 명령을 사용합니다. 여기서 file-name-expression은 손상된 파일과 일치하는 정규 표현식이고 archiver-log는 검사하는 아카이버 로그 복사본의 경로와 이름입니다.
이 예에서는 정규 표현식 genfiles\/ay0을 사용하여 최신 로그 파일에서 genfiles/ay0 파일에 관련된 항목을 검색합니다.
root@solaris:~# grep "genfiles\/ay0 " /var/adm/hsmfs1.archiver.log
파일에 대한 항목을 찾을 경우 매체 유형, 볼륨 일련 번호 및 데이터 파일이 아카이브된 아카이브(tar) 파일의 위치를 메모합니다. 또한 파일 복원 방법에 영향을 주는 파일 유형도 메모합니다.
이 예에서는 genfiles/ay0 파일에 대한 항목을 찾습니다. 로그 항목은 LTO(li) 볼륨 VOL012를 사용하여 2015년 3월 4일 9:49 PM에 아카이브되었음(A)을 표시합니다. 파일은 16진수 위치 0x78(78)의 테이프 아카이브 파일에 저장되어 있습니다. 이 파일은 정규 파일이며 f 유형입니다.
root@solaris:~# grep "genfiles\/ay0 " /var/adm/hsmfs1.archiver.log A 2015/03/04 21:49:15 li VOL012 SLOT12 allsets.1 78.1 hsmfs1 7131.14 8087 genfiles/ay0 f 0 51 root@solaris:~#
아카이버 로그 항목의 필드에 대한 자세한 설명은 부록 A 아카이버 및 마이그레이션 로그 이해를 참조하십시오.
현재 아카이버 로그 복사본에서 손상된 파일에 대한 항목을 찾지 못할 경우 복구 지점 파일이 만들어진 이후 만들어진 백업 아카이브 로그를 사용하여 검색을 반복합니다.
아카이버 로그는 자주 교체됩니다. 따라서 여러 아카이버 로그 복사본을 보존하고 있을 경우 현재 아카이버 로그 기간 이전에 만들어진 아카이브 복사본을 사용하여 손상된 파일을 복구할 수 있습니다.
samfsrestore 프로세스는 테이프에서 해당 파일 시스템을 찾아 파일 시스템 내의 적절한 위치에 복원할 수 있도록 파일 시스템 메타데이터의 복사본을 복구 지점 파일에서 복원합니다. 하지만 복구 지점 파일은 파일 시스템이 손실되기 전에 생성됩니다. 복구 지점이 생성된 후에 생성 및 아카이브된 파일의 메타데이터는 복구 지점에 포함될 수 없습니다.
대개 일부 파일은 마지막 복구 지점이 만들어진 이후 및 파일 시스템 손실 이전에 아카이브됩니다. 이러한 파일에 대한 메타데이터는 복구 지점 파일에 없으므로 파일이 손상되더라도 samfsrestore가 파일을 복구할 수 없습니다. 하지만 파일 데이터는 아카이브 매체에 상주하므로 메타데이터를 다시 생성하고 아카이브 로그를 사용하여 파일 시스템의 적절한 위치에 파일을 복구할 수 있습니다. 파일 시스템 손실 전에 파일이 교체 매체로 마이그레이션된 경우 매체 마이그레이션 로그도 사용할 수 있습니다.
아직 그렇게 하지 않은 경우 파일 시스템 메타데이터 서버에 root로 로그인합니다.
root@solaris:~#
사용 가능한 최근 아카이버 로그 파일을 찾습니다.
서버에서 아카이버 로그를 여전히 사용할 수 있는 경우 최근 정보가 포함되어 있을 수 있습니다. 그렇지 않은 경우 백업 복사본을 사용해야 합니다.
이 예에서는 아카이버 로그 파일 hsmfs1.archiver.log가 서버의 /var/adm/ 하위 디렉토리에 있습니다. 또한 독립된 파일 시스템 /zfs1에서 잘 알려진 위치 hsmfs1_recovery/archlogs 하위 디렉토리에 날짜별 아카이버 로그 파일 복사본이 있습니다. 따라서 최근 파일인 hsmfs1.archiver.log 및 최근 백업인 20150324가 모두 있습니다.
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
파일이 최근에 교체 매체로 마이그레이션된 경우 마이그레이션 로그도 찾습니다.
매체 마이그레이션 로그는 migrationd.cmd 파일에 지정된 로깅 디렉토리에 있는 각 소스 볼륨에 대해 생성됩니다. 로그 이름은 media-type.vsn으로 지정됩니다. 여기서 media-type은 부록 B 장비 유형 용어집에 설명된 2자로 된 코드 중 하나이고, vsn은 소스 볼륨을 식별하는 6자로 된 영숫자 볼륨 일련 번호입니다.
매체 마이그레이션 로그 형식은 아카이버 로그와 동일한 복구 정보를 포함하며, 동일한 방식으로 사용될 수 있습니다. 몇 가지 형식 차이점에 대한 설명은 부록 A 아카이버 및 마이그레이션 로그 이해 항목을 참조하십시오.
아카이버 로그의 최근 복사본에서 복구 지점이 만들어진 이후에 만들어진 항목을 검색합니다. grep "time-date-expression" archiver-log 명령을 사용합니다. 여기서 time-date-expression은 검색을 시작할 날짜 및 시간과 일치하는 정규 표현식이고 archiver-log는 검사하는 아카이버 로그 복사본의 경로와 이름입니다.
이 예에서는 2015년 3월 24일 2:02 AM에 파일 시스템이 손실되었습니다. 마지막 복구 지점 파일은 2015년 3월 23일 2:10 AM에 만들어졌습니다. 따라서 정규 표현식 ˆA 2015\/03\/2[45]를 사용하여 3월 23일 또는 24일에 기록된 아카이브 파일의 최신 로그 파일을 검색합니다.
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/hsmfs1.archiver.log
복원되지 않은 파일의 아카이브된 복사본에 대한 항목을 찾을 경우 경로, 이름, 파일 유형, 매체 유형 및 위치 정보를 메모합니다.
파일 유형은 정규 파일의 경우 f, 이동식 매체 파일의 경우 R, 세그먼트화된 파일의 데이터 세그먼트의 경우 S로 나열됩니다. 매체 유형은 2자리 문자 코드입니다(부록 B 장비 유형 용어집 참조).
백업 복사본을 찾으려면 복사본을 저장하는 매체 볼륨의 볼륨 일련 번호가 필요합니다. 복사본이 마그네틱 테이프와 같이 순차 액세스 매체에 저장된 경우에도 아카이브(tar) 파일의 시작 위치를 나타내는 16진수 값을 메모합니다. 복사본이 아카이브 디스크와 같이 랜덤 액세스 매체에 저장된 경우 볼륨 일련 번호에 대한 tar 파일의 상대 경로와 파일 이름을 메모합니다. 마지막으로 파일이 세그먼트화된 경우 세그먼트 길이를 메모합니다.
아래의 예에서 아카이버 로그 항목은 마지막 복구 지점이 만들어진 이후에 다음 파일이 아카이브되었음을 표시합니다.
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/hsmfs1.archiver.log A 2015/03/23 10:43:18 li VOL002 all.1 111.1 hsmfs1 1053.3 69 genfiles/hops f 0 0 A 2015/03/23 10:43:18 li VOL002 all.1 111.3 hsmfs1 1051.1 104 genfiles/anic f 0 0 A 2015/03/23 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0 A 2015/03/23 13:09:06 li VOL004 all.1 212.20 hsmfs1 1534.2 1497 genfiles/genA9 f 0 0 A 2015/03/23 13:10:15 li VOL004 all.1 212.3f hsmfs1 1533.2 6491 genfiles/genA2 f 0 0 A 2015/03/23 13:12:25 li VOL003 all.1 2.5e hsmfs1 1532.2 17717 genfiles/genA13 f 0 0 A 2015/03/23 13:12:28 li VOL003 all.1 2.7d hsmfs1 1531.2 14472 genfiles/genA4 f 0 0 A 2015/03/23 13:12:40 li VOL003 all.1 2.9c hsmfs1 1530.2 19971 genfiles/genA45 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.308 hsmfs1 1510.2 7797 spcfiles/spcC5 f 0 0 A 2015/03/23 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/23 14:04:11 li VOL013 all.1 76a.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/23 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51 A 2015/03/23 18:28:51 li VOL036 all.1 12d.1 hsmfs1 11731.1 89128448 rf/rf81 f 0 210 A 2015/03/23 18:28:51 li VOL034 all.1 15f.0 hsmfs1 11731.1 525271552 rf/rf81 f 1 220 root@solaris:~#
다음 정보를 메모합니다.
8개의 정규(유형 f) 파일이 LTO(li) 매체에서 아카이브됨(A): VOL002 볼륨의 0x111 위치에 genfiles/hops 및 genfiles/anic, VOL004 볼륨의 0x212 위치에 genfiles/genA0, genfiles/genA9 및 genfiles/genA2, 그리고 VOL003 볼륨의 0x212 위치에 genfiles/genA13, genfiles/genA4 및 genfiles/genA45가 있습니다.
2개의 정규(유형 f) 파일이 디스크(dk) 매체에서 아카이브됨(A): DISKVOL1 볼륨의 아카이브 파일 DISKVOL1 \f2에 spcfiles/spcC4 및 spcfiles/spcC5가 있습니다.
1개의 세 부분으로 세그먼트화된(유형 S) 파일이 LTO(li) 매체에서 아카이브됨: bf/dat011이며, 두 세그먼트는 VOL013 볼륨의 0x76a 위치에서 시작하고 한 세그먼트는 1409aa4 위치에서 시작합니다. 세그먼트 /1은 10485760바이트, 세그먼트 /2는 10485622바이트, 그리고 세그먼트 /3은 184바이트 길이입니다.
1개의 정규(유형 f) 볼륨 오버플로우 파일이 LTO(li) 매체에서 아카이브됨(A): rf/rf81이며, VOL036 볼륨의 0x12d 위치에서 시작하고 VOL034 볼륨의 0x15f 위치에서 계속됩니다.
아카이버 로그 항목의 필드에 대한 자세한 설명은 부록 A 아카이버 및 마이그레이션 로그 이해를 참조하십시오.
복구 지점 파일이 만들어진 이후 만들어진 백업 아카이브 로그를 사용하여 검색을 반복합니다.
아카이버 로그는 자주 교체됩니다. 따라서 여러 아카이버 로그 복사본을 보존하고 있을 경우 현재 아카이버 로그 기간 이전에 만들어진 아카이브 복사본을 사용하여 손상된 파일을 복구할 수 있습니다.
이제 손상 및/또는 누락된 파일을 복원합니다.
매체 볼륨 및 매체에서 아카이브(tar) 파일의 위치를 안다면 누락되거나 손상된 파일 복원은 tar 파일에 액세스하고 필요한 데이터 파일을 추출하기만 하면 가능합니다. 아카이브 파일이 아카이브 디스크 장치에 상주하는 경우 tar 파일이 파일 시스템 마운트 지점 아래에서 랜덤 액세스 가능한 디렉토리에 상주하므로 간단합니다. 하지만 tar 파일이 테이프와 같은 대용량 순차 액세스 매체에 상주하는 경우 복잡해집니다. 대개 아카이브 파일이 랜덤 액세스 디스크 장치에 스테이징될 때까지 아카이브 파일에서 필요한 데이터 파일을 추출할 수 없습니다. 아카이브 파일은 클 수 있으므로 이 작업은 복구 상황에서 시간이 오래 걸리고 까다로울 수 있습니다. 따라서 아래의 절차에서는 아카이브 파일을 메모리로 읽고 디스크에서 읽는 것처럼 사용 가능하게 만드는 Oracle HSM 명령 request를 사용합니다.
가능한 많은 손상 및 누락된 정규 파일을 복원하십시오. 각 파일에 대해 다음과 같이 수행하십시오.
볼륨에 걸쳐 있지 않은 정규 파일 복구를 시작합니다. 손실 및 손상된 정규 파일 복원 절차를 수행합니다.
그런 다음 세그먼트화된 파일을 복구합니다. 손실 및 손상된 세그먼트화된 파일 복원 절차를 수행합니다.
그런 다음 볼륨에 걸쳐 있는 정규 파일을 복원합니다. 손실 및 손상된 볼륨 오버플로우 파일 복원 절차를 수행합니다.
복사본이 있으며 누락되고 손상된 파일을 모두 복원한 후 wait 지시어를 archiver.cmd 파일에서 제거하여 아카이브를 다시 사용으로 설정합니다. -ignore 매개변수를 recycler.cmd 파일에서 제거하여 재활용을 다시 사용으로 설정합니다.
파일 시스템이 가능한 원래 조건과 가까워졌습니다. 여전히 손상되거나 누락된 파일은 복구할 수 없습니다.
복사본이 있는 누락 파일과 손상된 파일을 모두 복원한 경우 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.
복구 지점 파일을 사용하지 않고 아카이브 매체에서 직접 파일 시스템을 복구할 수 있습니다. 다음과 같이 하십시오.
옵티컬 매체에서 파일을 복원하려는 경우 여기서 중지하고 오라클 고객 지원 센터로 문의하십시오.
파일 시스템에 대한 NFS(네트워크 파일 시스템) 공유를 사용 안함으로 설정합니다.
아카이브 및 재활용을 사용 안함으로 설정합니다. 아카이브 및 재활용 프로세스 중지에 설명된 방법을 사용합니다.
복구 프로세스의 배타적 사용을 위해 테이프 드라이브를 예약합니다. samcmd unavail drive-equipment-number 명령을 사용합니다. 여기서 drive-equipment-number는 /etc/opt/SUNWsamfs/mcf 파일의 드라이브에 지정된 장비 서수 번호입니다.
samcmd unavail 명령은 아카이브, 스테이징 및 릴리스 프로세스에서 드라이브를 사용하지 못하도록 합니다. 이 예에서는 804 드라이브를 예약합니다.
root@solaris:~# samcmd unavail 804 root@solaris:~#
/opt/SUNWsamfs/examples/tarback.sh 파일을 /tmp와 같은 대체 위치에 복사합니다.
tarback.sh 파일은 지정된 매체 볼륨 세트에서 파일을 복원하는 실행 스크립트입니다. 스크립트는 각 볼륨의 각 아카이브(tar) 파일에 대해 star -n 명령을 실행합니다. 테이프의 백업 복사본에 파일 시스템의 해당하는 파일이 없거나 복사본이 파일 시스템의 해당하는 파일보다 최신인 경우 star -n은 복사본을 복원합니다.
이 예에서는 스크립트를 /tmp에 복사합니다.
root@solaris:~# cp /opt/SUNWsamfs/examples/tarback.sh /tmp/tarback.sh root@solaris:~#
텍스트 편집기에서 tarback.sh 파일의 복사본을 엽니다.
이 예에서는 vi 편집기를 사용합니다.
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" EQ=28 TAPEDRIVE="/dev/rmt/3cbn" # BLOCKSIZE is in units of 512 bytes (e.g. 256 for 128K) BLOCKSIZE=256 MEDIATYPE="lt" VSN_LIST="VSNA VSNB VSNC VSNZ" ...
Oracle HSM 유틸리티 star, load 및 unload가 비표준 위치에 설치된 경우 tarback.sh 파일의 복사본에서 기본 명령 경로를 편집합니다.
이 예에서는 모든 유틸리티가 기본 위치에 설치되어 있으므로 편집이 필요하지 않습니다.
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" ...
tarback.sh 파일 복사본에서 변수 EQ를 찾습니다. 복구용으로 예약한 드라이브의 장비 서수 번호로 값을 설정합니다.
이 예에서는 EQ=804를 설정합니다.
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
...
tarback.sh 파일 복사본에서 변수 TAPEDRIVE를 찾습니다. 장치에 대한 원시 경로(큰 따옴표로 묶음)로 값을 설정합니다.
이 예에서 804 장치에 대한 원시 경로는 /dev/rmt/3cbn입니다.
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
...
tarback.sh 파일 복사본에서 변수 BLOCKSIZE를 찾습니다. 원하는 블록 크기의 512바이트 단위 숫자로 값을 설정합니다.
이 예에서는 LTO-4 드라이브에 대해 256KB 세그먼트 크기를 원합니다. 따라서 512를 지정합니다.
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
...
tarback.sh 파일 복사본에서 변수 MEDIATYPE을 찾습니다. 부록 B에서 드라이브가 지원하는 매체 유형에 대해 나열되는 2자리 문자의 매체 유형 코드로 값을 설정합니다. 매체 유형은 큰 따옴표로 묶습니다.
이 예에서는 LTO-4 드라이브를 사용합니다. 따라서 li를 지정합니다.
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="li"
...
tarback.sh 파일 복사본에서 변수 VSN_LIST를 찾습니다. 값으로 파일의 백업 복사본을 포함할 수 있는 테이프를 식별하는 VSN(볼륨 일련 번호)의 공백으로 구분된 목록을 제공합니다. 목록은 큰 따옴표로 묶습니다.
이 예에서는 VOL002, VOL003, VOL004, VOL013, VOL034 및 VOL036 볼륨을 지정합니다.
EQ=804 TAPEDRIVE="/dev/rmt/3cbn" BLOCKSIZE=512 MEDIATYPE="lt" VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036" ...
tarback.sh 파일 복사본을 저장합니다. 편집기를 닫습니다.
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036"
...
:wq
root@solaris:~#
/tmp/tarback.sh 스크립트를 실행합니다.
root@solaris:~# /tmp/tarback.sh
필요에 따라 사용자 및 그룹 소유권, 모드, 확장 속성 및 ACL(액세스 제어 목록)을 복원된 파일마다 다시 생성합니다.
/tmp/tarback.sh 스크립트로는 이 유형의 메타데이터를 복원할 수 없습니다.
/tmp/tarback.sh 스크립트를 실행했으며 파일 복구를 완료한 경우 아카이브 파일 시스템을 일반 작업으로 복원으로 이동합니다.