지금까지 이 문서는 사용자와 응용 프로그램이 정기적으로 파일을 만들고 수정 및 삭제하는 일반적인 UNIX 파일 시스템으로서 Oracle Hierarchical Storage Manager and StorageTek QFS Software 솔루션 관리에 대해 설명했습니다. 고도로 통합된 백업 서비스로 주로 작용하는 아카이브와 함께 디스크 캐시에 초점을 맞췄습니다. 이 장에서는 장기간 데이터 보존을 위한 저장소 및 관리 솔루션으로서 아카이브에 다시 초점을 맞춥니다. 이전에 다루었던 관리 원칙과 기법은 관련 항목으로 남습니다. 하지만 지금 디스크 캐시는 아카이브로 파일을 입수하는 수단으로 주로 작용하며, 입수 이후 삭제나 수정은 허용되지 않습니다.
정확한 요구 사항은 다양합니다. 법적 의무 기간 동안 업무나 의료 기록을 보관하는 저장소는 정기적으로 레코드를 폐기해야 할 수 있습니다. 그러나 과학적 데이터, 역사적 계보 기록 또는 디지털 음악, 영화, 텔레비전 프로그램을 저장하는 아카이브는 사실상 영구히 컨텐츠를 저장해야 할 수 있습니다. 이러한 이유로 Oracle HSM은 여러 방법으로 디지털 보존을 지원합니다.
메시지 다이제스트(체크섬)는 파일 파손, 데이터 손상, 무단 수정을 감지할 수 있으므로 하드웨어 문제를 해결하고 부적합한 파일을 아카이브에 저장된 적합한 복사본으로 교체할 수 있습니다.
파일 고정성 속성은 메시지 다이제스트와 작동하여 수퍼 유저만 고정된 파일을 변경할 수 있도록 보장합니다. Oracle HSM이 고정된 파일을 스테이지/아카이브할 때마다 고정성 속성으로 저장된 체크섬을 재검증하여 파일이 변경되지 않았음을 입증합니다.
Oracle HSM WORM(Write Once Read Many) 파일 시스템은 파일을 읽기 전용으로 만들고 지정된 기간 동안 강제 보존할 수 있습니다. 이 파일 시스템은 수퍼 유저가 파일이나 파일 속성(위에 설명된 고정성 속성)을 변경할 수 없도록 구성할 수 있습니다.
이 장은 장기간용 스토리지 솔루션의 기초를 이루는 기본적인 Oracle HSM 데이터 보호 조치(보존용 파일 시스템 구성)를 간략히 검토하는 것부터 시작합니다. 그 다음 구체적으로 데이터 보존을 처리하는 작업을 설명합니다.
모든 보존 솔루션은 적합한 고중복성 파일 시스템으로 시작합니다. 따라서 아직 수행하지 않은 경우 동봉된 Oracle Hierarchical Storage Manager and StorageTek QFS 설치 및 구성 설명서의 구현 장을 검토하십시오. 중복 서버, 네트워크 연결, 스토리지 장치를 제공하여 아카이브에 대한 액세스를 보호합니다. 파일마다 최소 2개 이상의 추가 복사본을 구성하고 각각 독립된 매체에 저장하여 파일 데이터를 보호합니다. 대부분의 경우 복사본 1개는 디스크나 솔리드 상태 스토리지 장치에, 복사본 2개는 테이프 매체에 아카이브하는 것이 이상적입니다. 가능한 경우 Oracle HSM 데이터 무결성 검증 기능을 구현하여 테이프 블록을 올바로 읽고 쓸 수 있도록 보장합니다. 정기적으로 덤프 파일을 생성하고 정기적으로 아카이브 로그를 백업하여 파일 시스템 메타데이터를 보호합니다.
메시지 다이제스트(체크섬)로 보존자는 컨텐츠에 점진적 악화, 하드웨어/운영자 오류 또는 고의적 무단 변경을 나타낼 수 있는 변경사항이 있는지 아카이브된 파일을 테스트할 수 있습니다. 메시지 다이제스트는 간단히 단방향 암호화 해시 함수로 생성된 파일 컨텐츠를 수학적으로 요약한 것입니다. 암호화 해시 함수는 입력 데이터의 변경에 극도로 민감합니다. 입력을 조금만 변경해도 출력이 크게 변경됩니다. 따라서 메시지 다이제스트는 파일 손상 및 무단 변경을 감지하기에 이상적입니다. 파일의 다이제스트를 재계산하고 저장된 다이제스트 값과 결과 값을 비교하면 파일이 변경되었는지 여부가 나타납니다.
Oracle Hierarchical Storage Manager 파일 시스템은 다음 암호화 해시 함수 중 하나를 사용하여 메시지 다이제스트를 입수, 만들기, 저장 및 검증할 수 있습니다.
SHA1 - 보안 해시 알고리즘 계열 암호화 함수의 160비트 멤버
보안 해시 알고리즘은 NIST(National Institute of Standards and Technology)가 2012년 발행한 FIPS(Federal Information Processing Standard) Publication 180-4에 정의되어 있습니다. Oracle HSM은 기본적으로 SHA1을 사용합니다.
SHA256 - 보안 해시 알고리즘 계열의 256비트 멤버
SHA384 - 보안 해시 알고리즘 계열의 384비트 멤버
SHA512 - 보안 해시 알고리즘 계열의 512비트 멤버
MD5 - IETF(Internet Engineering Task Force)가 RFC(Request for Comment) 1321에 정의한 128비트 메시지 다이제스트 함수
지금은 주로 이전의 Storage Archive Manager 구현과 역호환성을 위해 사용되는 독점적 128비트 Oracle HSM 함수입니다.
저장소로 파일을 입수할 때 사용자가 기존 다이제스트 값을 제공하거나, 파일 시스템이 즉시 또는 파일을 처음 아카이브할 때 해당 값을 계산할 수 있습니다. Oracle HSM 파일 시스템은 특수 파일 속성을 사용하여 파일 시스템 메타데이터와 함께 다이제스트 값을 저장합니다. 일단 속성이 설정되면 파일 시스템은 다이제스트를 재계산하고, 해당 파일을 다시 아카이브할 때마다 또는 선택적으로 아카이브 매체에서 디스크 캐시로 파일을 스테이지할 때마다 저장된 값에 대해 결과를 검증합니다.
그러나 Oracle HSM 매체 마이그레이션 기능은 체크섬을 재계산하지 않고 새 매체로 파일을 복사합니다. 매체 마이그레이션에 대한 자세한 내용은 제 8 장 새 스토리지 매체로 마이그레이션을 참조하십시오. 파일을 제대로 복사하지 않으면 파일을 다시 스테이지하고 검증할 때까지 손상이 감지되지 않을 작은 위험이 있습니다. DIV(데이터 무결성 검증)를 사용하면 이 위험이 최소화됩니다(세부정보는 Oracle Hierarchical Storage Manager and StorageTek QFS 설치 및 구성 설명서 참조).
메시지 다이제스트 사용을 시작하기 전에 먼저 파일 시스템 호스트 성능이 적절한지 확인을 수행해야 합니다. 그리고 다음 절을 참조하여 다이제스트 제공, 생성, 검증 지침을 확인할 수 있습니다.
메시지 다이제스트를 빈번히 사용할 계획이면 적절한 성능을 위해 파일 시스템 호스트에 충분한 컴퓨팅 리소스가 있는지 확인합니다. 대부분의 최신 플랫폼은 중앙 프로세서 주기를 소비하지 않고 특화된 계산을 효율적으로 수행할 수 있는 전용 암호화 하드웨어를 포함합니다. 가능한 경우 이 기능을 활용해야 합니다.
잠재적 파일 시스템 호스트의 기능을 확인하려면 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
호스트 운영체제가 Solaris 11.1 이상인지 확인합니다. uname -v 명령을 사용합니다.
이전 버전의 운영체제는 해시 함수의 하드웨어 가속을 지원하지 않습니다. 예제에서는 호스트 운영체제가 Solaris 11.2입니다.
root@solaris:~# uname -v 11.2 root@solaris:~#
명령 세트 구조를 표시합니다. 명령 프롬프트에서 isainfo -v 명령을 입력합니다.
root@solaris:~# isainfo -v
Solaris 11 호스트가 Oracle Sun SPARC T3 이상의 시스템인 경우 isainfo -v 명령의 출력은 sha512, sha256, sha1, md5 암호화 알고리즘을 지원하는 명령 세트를 나열해야 합니다.
예제에서는 Sun SPARC T4-2 호스트가 SHA1, SHA2, MD5 알고리즘 계열에 대한 하드웨어 가속을 제공합니다.
[Sun_SPARC_T4-2]root@solaris:~# isainfo -v
64-bit sparcv9 applications
crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia kasumi
des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc
root@solaris:~#
Solaris 호스트가 x86/64 시스템인 경우 isainfo -v 명령의 출력에 ssse3(Supplemental Streaming SIMD Extensions 3) 명령 세트가 포함될 경우 SHA-1 하드웨어 가속을 지원합니다.
예제에서는 Sun X3-2 호스트가 SHA-1 다이제스트의 하드웨어 가속을 지원합니다.
[Sun_X3-2]root@solaris:~# isainfo -v
64-bit amd64 applications
avx xsave pclmulqdq aes sse4.2 sse4.1 ssse3 popcnt tscp ahf cx16 sse3
sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
root@solaris:~#
이미 메시지 다이제스트와 연관된 파일을 아카이브하는 경우 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 ssum -a algorithm -h digest -G [-u]filename 명령을 입력합니다. 설명:
-a algorithm은 제공된 메시지 다이제스트에 대해 파일을 검증할 때 파일 시스템이 사용할 암호화 해시 함수를 식별합니다.
-h digest는 파일 시스템이 파일 검증에 사용할 메시지 다이제스트를 식별합니다.
-G는 즉시 검증을 지정합니다. 파일 시스템은 hash 파일 속성을 제공된 메시지 다이제스트 값으로 설정하고, 독립적으로 파일의 메시지 다이제스트를 계산하고, 저장된 값과 결과를 비교합니다. 제공된 다이제스트와 계산된 다이제스트가 일치하면 파일 시스템은 파일의 validated 속성을 설정합니다. 그 다음 generate 속성을 설정하여 파일을 다시 아카이브할 때마다 유효성을 다시 검사하도록 합니다.
-u는 use 파일 속성(선택사항)을 설정합니다. 파일을 스테이지할 때마다 파일 시스템은 다이제스트를 재계산하고 hash 속성에 저장된 값에 대해 결과를 검증합니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 SHA256 다이제스트를 제공하고 파일 시스템이 즉시 재계산하면 제공된 값에 대해 data10 파일의 다이제스트 값을 검증합니다. sls -D -h data10 명령으로 파일 속성을 확인하면 generate 및 validated 파일 속성이 설정되었고, algorithm 속성이 SHA-256으로 설정되었고, 다이제스트 값이 계산 후 hash 속성에 저장되었음을 알 수 있습니다.
root@solaris:~# ssum -h f03ce01b3828...f7459503007e -a sha256 -g data10 root@solaris:~# sls -D -h data10 data10: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
필요한 경우 평소에 하듯이 파일을 편집합니다.
예제에서는 마지막 아카이브 이후 data10m이라는 파일을 수정했습니다. sls -D -h 명령이 보여주듯이 어느 쪽도 가장 최근 변경사항을 반영하지 않으므로 S(사용되지 않음) 플래그가 두 복사본에 설정되었습니다. Solaris digest 명령을 사용하여 수정된 파일에 대한 SHA-256 다이제스트 값을 확인하면 파일의 hash 속성이 오래된 다이제스트 값도 저장함을 알 수 있습니다.
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data10m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
필요한 경우 다시 아카이브하기 전에 수정된 파일의 다이제스트 속성을 변경할 수 있습니다.
예제에서는 다이제스트 알고리즘을 SHA256에서 SHA1로 변경하고 즉시 효력을 발휘합니다.
root@solaris:~# ssum -a sha1 -G data10m root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
그렇지 않으면, 파일 시스템이 수정된 파일을 아카이브하기를 기다렸다가 자동으로 다이제스트 관련 속성을 업데이트합니다.
수정된 파일을 아카이브할 때 파일 시스템은 다이제스트 값을 재계산하고, 새 값을 hash 속성에 저장하고, 이전 파일 버전의 아카이브된 복사본에 S(사용되지 않음) 플래그를 설정합니다. 예제에서는 다이제스트 속성을 변경하지 않고 data10m 파일을 편집했습니다. 아카이버는 예정대로 디스크에 copy 1을 새로 만들었고 hash 속성을 업데이트했습니다. 수정되지 않은 파일의 복사본은 아카이버가 copy 2를 만들 때까지 S(사용되지 않음) 플래그가 지정된 채 테이프에 남아 있습니다.
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
파일의 다이제스트를 생성하고 파일 검증을 사용으로 설정하려면 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 ssum -a algorithm -g|G [-u] filename 명령을 입력합니다. 설명:
-a algorithm은 파일의 메시지 다이제스트를 생성할 때 파일 시스템이 사용할 암호화 해시 함수를 지정합니다.
-g는 파일에 대한 generate 파일 속성을 설정합니다. 처음 파일을 아카이브할 때 파일 시스템은 메시지 다이제스트를 계산합니다. 파일을 다시 아카이브할 때마다 파일 시스템은 다이제스트를 재계산하고 저장된 값에 대해 결과를 검증합니다.
-G는 파일에 대한 generate 및 validate 파일 속성을 설정합니다. 파일 시스템은 메시지 다이제스트를 즉시 계산하고 hash 속성에 결과를 저장합니다. 파일을 아카이브할 때마다 파일 시스템은 다이제스트를 재계산하고 저장된 값에 대해 결과를 검증합니다.
-u는 use 파일 속성(선택사항)을 설정합니다. 파일을 스테이지할 때마다 파일 시스템은 다이제스트를 재계산하고 hash 속성에 저장된 값에 대해 결과를 검증합니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 파일 시스템이 SHA256 알고리즘을 사용하여 아카이브 전에 data11 파일의 다이제스트를 계산하도록 합니다. sls -D -h data10 명령으로 파일 속성을 확인하면 파일마다 generate 파일 속성이 설정되었고 algorithm 속성이 SHA-256으로 설정되었음을 알 수 있습니다. 파일이 아직 아카이브되지 않았으므로 다이제스트 값이 아직 계산 후 hash 속성에 저장되지 않았습니다.
root@solaris:~# ssum -a sha256 -g data11 root@solaris:~# sls -D -h data11 data11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90218.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:22 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
필요한 경우 평소에 하듯이 파일을 편집합니다.
예제에서는 마지막 아카이브 이후 data11m이라는 파일을 수정했습니다. sls -D -h 명령이 보여주듯이 어느 쪽도 가장 최근 변경사항을 반영하지 않으므로 S(사용되지 않음) 플래그가 두 복사본에 설정되었습니다. Solaris digest 명령을 사용하여 수정된 파일에 대한 SHA-256 다이제스트 값을 확인하면 파일의 hash 속성이 오래된 다이제스트 값도 저장함을 알 수 있습니다.
root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data11m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
필요한 경우 다시 아카이브하기 전에 수정된 파일의 다이제스트 속성을 변경할 수 있습니다.
예제에서는 다이제스트 알고리즘을 SHA256에서 SHA1로 변경하고 즉시 효력을 발휘합니다.
root@solaris:~# ssum -a sha1 -G data11m root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
그렇지 않으면, 파일 시스템이 수정된 파일을 아카이브하기를 기다렸다가 자동으로 다이제스트 관련 속성을 업데이트합니다.
수정된 파일을 아카이브할 때 파일 시스템은 다이제스트 값을 재계산하고, 새 값을 hash 속성에 저장하고, 이전 파일 버전의 아카이브된 복사본에 S(사용되지 않음) 플래그를 설정합니다.
예제에서는 다이제스트 속성을 변경하지 않고 data11m 파일을 편집했습니다. 아카이버는 예정대로 디스크에 copy 1을 새로 만들었고 hash 속성을 업데이트했습니다. 수정되지 않은 파일의 복사본은 아카이버가 copy 2를 만들 때까지 S(사용되지 않음) 플래그가 지정된 채 테이프에 남아 있습니다.
root@solaris:~# sls -D -h data11m mdata11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
반복적으로 다이제스트를 생성하고 디렉토리의 모든 파일에 대한 검증 속성을 설정하려면 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 ssum -a algorithm -g|G [-u] -r directoryname 명령을 입력합니다. 설명:
-a algorithm은 메시지 다이제스트를 생성할 때 파일 시스템이 사용할 암호화 해시 함수를 지정합니다.
-g는 각 파일마다 generate 파일 속성을 설정합니다. 처음 파일을 아카이브할 때 파일 시스템은 파일의 메시지 다이제스트를 계산합니다. 파일을 다시 아카이브할 때마다 파일 시스템은 다이제스트를 재계산하고 저장된 값에 대해 결과를 검증합니다.
-G는 각 파일마다 generate 및 validate 파일 속성을 설정합니다. 파일 시스템은 즉시 메시지 다이제스트를 계산하고 hash 속성에 결과를 저장합니다. 파일을 아카이브할 때마다 파일 시스템은 다이제스트를 재계산하고 저장된 값에 대해 결과를 검증합니다.
-u는 use 파일 속성(선택사항)을 설정합니다. 파일을 스테이지할 때마다 파일 시스템은 다이제스트를 재계산하고 저장된 값에 대해 결과를 검증합니다.
-r은 지정된 디렉토리의 모든 파일에 대해 명령을 반복적으로 적용합니다.
directoryname은 디렉토리의 경로 및 이름입니다.
첫번째 예제에서는 파일 시스템이 SHA256 알고리즘을 사용하여 아카이브 전에 datasetA 디렉토리의 파일에 대한 다이제스트를 계산하도록 합니다. sls -D -h datasetA 명령으로 파일 속성을 확인하면 파일마다 generate 파일 속성이 설정되었고 algorithm 속성이 SHA-256으로 설정되었음을 알 수 있습니다. 파일이 아직 아카이브되지 않았으므로 다이제스트 값이 아직 계산 후 hash 속성에 저장되지 않았습니다.
root@solaris:~# ssum -a sha256 -g -r datasetA root@solaris:~# sls -D -h datasetA datasetA/pdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... datasetA/pdata20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... root@solaris:~#
두번째 예제에서는 파일 시스템이 SHA256 알고리즘을 사용하여 아카이브 전에 datasetB 디렉토리의 파일에 대한 다이제스트를 즉시 계산하도록 합니다. sls -D -h datasetB 명령으로 파일 속성을 확인하면 파일마다 generate 및 validated 파일 속성이 설정되었고, algorithm 속성이 SHA-256으로 설정되었고, 다이제스트 값이 계산 후 hash 속성에 저장되었음을 알 수 있습니다.
root@solaris:~# ssum -a sha256 -G -r datasetB root@solaris:~# sls -D -h datasetB datasetB/qdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 4d2800eb82b3...520341edde95 ... datasetB/qdata12: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 5b057f1b7b48...88c590d47dec ... root@solaris:~#
필요한 경우 디스크 캐시에 스테이지하기 전에 파일을 검증할 수 있습니다. 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 ssum -u [-a algorithm [-h digest] -g|G] filename 명령을 입력합니다. 설명:
-u는 use 파일 속성을 설정하여 스테이지 전에 검증을 지정합니다. use 속성이 파일에 설정된 경우, 파일 시스템은 메시지 다이제스트를 생성하고 파일의 hash 속성에 저장된 값에 대해 결과를 성공적으로 검증할 때까지 아카이브 매체에서 디스크 캐시로 파일을 복사하지 않습니다.
-a algorithm, -h digest, -g|G는 이전에 설정되지 않은 경우 파일에 필수 algorithm, hash, generate 속성을 설정하는 선택적 매개변수입니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 data102 파일에 대한 검증을 이미 사용으로 설정했습니다. sls -D -h data102 명령이 보여주듯이 generate 및 validated 파일 속성이 설정되었고, algorithm 속성이 SHA-256으로 설정되었고, 다이제스트 값이 계산 후 hash 속성에 저장되었습니다.
root@solaris:~# ssum -a sha256 -F data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
따라서 use 속성을 설정하여 파일 시스템이 스테이지 전에 파일을 검증함을 보장할 수 있습니다. sls -D -h data102 명령이 보여주듯이 use 속성이 지금 설정되어 있습니다.
root@solaris:~# ssum -u data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate use validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
변경 불가능이 아닌 파일이 아직 아카이브되지 않은 경우 아래 절차를 사용하여 메시지 다이제스트 및 검증 속성을 변경할 수 있습니다.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
필요한 경우 다이제스트 알고리즘을 변경합니다. 명령 프롬프트에서 ssum -a newalgorithm filename 명령을 입력합니다. 설명:
-a newalgorithm은 이전에 지정된 다이제스트 알고리즘을 바꾸는 암호화 해시 함수를 지정합니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 보존 정책에 충돌 회피도가 높은 SHA256 함수가 필요합니다. 그러나 sls -D -h 명령이 보여주듯이 data319 파일의 다이제스트 속성을 설정할 때 실수로 SHA1 알고리즘을 지정했습니다. 파일이 아직 아카이브되지 않았으므로 알고리즘을 SHA256으로 성공적으로 변경할 수 있습니다.
root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-1 hash: root@solaris:~# ssum -a sha256 data319 root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
필요한 경우 다이제스트 속성을 지우고 기본 파일 설정을 복원합니다. 명령 프롬프트에서 ssum -d filename 명령을 입력합니다. 설명:
-d는 파일 다이제스트 속성을 기본값으로 재설정합니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 data44 파일에 대한 메시지 다이제스트 및 검증을 구성하려는 의도가 아니었습니다. 그러나 sls -D -h 명령이 보여주듯이 실수로 이를 수행했습니다. 파일이 아직 아카이브되지 않았으므로 아카이브/스테이지 동안 다이제스트 검증을 제어하는 generate 및 use 속성을 성공적으로 지울 수 있습니다. validated, algorithm, hash 속성의 데이터는 남아 있지만 파일 시스템의 동작에 영향을 미치지 않습니다.
root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate use validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~# ssum -d data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
필요한 경우 파일을 아카이브하기 전에 필요한 메시지 다이제스트 및 검증 속성을 재설정합니다. 명령 프롬프트에서 ssum 명령을 적절한 옵션 및 파일 이름과 함께 입력합니다.
예제에서는 qndat44 파일에 메시지 다이제스트를 다시 사용으로 설정하고 아카이브 전에 다이제스트를 검증하기로 했습니다. 그러나 스테이지 전에 검증할 필요는 없습니다. 따라서 generate 속성을 복원하되, use 속성은 복원하지 않습니다.
root@solaris:~# ssum -g data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
보존 요구 사항에서 종종 파일 고정성을 보장하는 메커니즘을 요구합니다. 아카이브는 변경을 방지해야 하고 해당 변경사항이 발생하지 않았음을 입증해야 합니다. 고정성을 제공하기 위해 Oracle HSM 아카이브 파일 시스템은 위에 설명된 메시지 다이제스트 및 다이제스트 관련 파일 속성을, 파일을 변경 불가능으로 만드는 추가 속성과 함께 결합합니다. 일단 파일을 변경 불가능으로 만들면 수퍼 유저 권한을 가진 사람만 상태를 변경할 수 있습니다. 불변성을 엄격한 WORM(Write Once Read Many) 파일 시스템과 결합하면 수퍼 유저조차도 변경할 수 없습니다(세부정보는 WORM 파일 시스템 이해 참조).
다음 방법 중 하나로 파일을 변경 불가능으로 만들 수 있습니다.
아카이브로 입수한 후 파일이 변경되지 않았음을 보장해야 하는 경우 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 ssum -a algorithm [-h digest] -F filename 명령을 입력합니다. 설명:
-a algorithm은 제공된 메시지 다이제스트에 대해 파일을 검증할 때 파일 시스템이 사용할 암호화 해시 함수를 식별합니다.
-h digest는 파일 시스템이 파일 검증에 사용할 메시지 다이제스트를 식별합니다.
-F는 즉시 검증과 불변성을 지정하고 fixity, generate, validated, use 파일 속성을 설정합니다. 파일 시스템은 즉시 메시지 다이제스트를 계산하고 검증합니다. 파일을 스테이지/아카이브할 때 파일 시스템은 메시지 다이제스트를 재계산하고 재검증합니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 SHA256 다이제스트를 제공하고 파일 시스템이 다이제스트를 재계산하면 data20 파일의 값을 검증하고 파일을 변경 불가능으로 만듭니다. sls -D -h data10 명령으로 파일 속성을 확인하면 파일마다 fixity, generate, use, validated 파일 속성이 설정되었고, algorithm 속성이 SHA-256으로 설정되었고, 다이제스트 값이 계산 후 hash 속성에 저장되었음을 알 수 있습니다.
root@solaris:~# ssum -h bfaefde932cf...d450892eda63 -a sha256 -F data20 root@solaris:~# sls -D -h data20 data20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: bfaefde932cf...d450892eda63 root@solaris:~#
이미 메시지 다이제스트와 연관된 파일을 아카이브할 때 아카이브로 입수한 후 파일이 변경되지 않았음을 보장해야 하는 경우 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 ssum -a algorithm [-h digest] -F filename 명령을 입력합니다. 설명:
-a algorithm은 -h digest 매개변수에 지정된 다이제스트를 생성하는 데 사용된 암호화 해시 함수를 식별합니다.
-F는 fixity, generate, validated, use 파일 속성을 설정합니다. 파일 시스템은 즉시 메시지 다이제스트를 계산하고 검증합니다. 파일을 스테이지/아카이브할 때 파일 시스템은 메시지 다이제스트를 재계산하고 재검증합니다.
filename은 파일의 경로 및 이름입니다.
예제에서는 파일 시스템이 SHA256 다이제스트를 계산하면 data200 파일의 값을 검증하고 파일을 변경 불가능으로 만듭니다. sls -D -h data10 명령으로 파일 속성을 확인하면 파일마다 fixity, generate, validated, use 파일 속성이 설정되었고, algorithm 속성이 SHA-256으로 설정되었고, 다이제스트 값이 계산 후 hash 속성에 저장되었음을 알 수 있습니다.
root@solaris:~# ssum -a sha256 -F data200 root@solaris:~# sls -D -h data200 data200: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: efde93cc12cf...d496602e36dd root@solaris:~#
하나 이상의 파일에 대한 메시지 다이제스트 및 고정성 속성을 보려면 Oracle HSM 디렉토리 나열 명령인 sls를 사용합니다. 다음과 같이 하십시오.
파일 시스템 호스트에 root로 로그인합니다:
root@solaris:~#
명령 프롬프트에서 sls -D -h filename 명령을 입력합니다. 설명:
-D는 파일 속성의 세부 표시를 지정합니다.
-h는 화면에 해시(다이제스트) 값을 포함합니다.
filename은 하나 이상의 파일을 경로 및 이름으로 식별합니다.
예제에서는 화면의 checksum 및 hash 필드에 나열된 data02 파일의 다이제스트 속성을 보여줍니다.
root@solaris:~# sls -D -h data02 data02: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate use validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
hash 속성은 f03ce01b3828...f7459503007e 파일의 메시지 다이제스트를 저장합니다.
algorithm 속성은 SHA-256 암호화 해시 함수가 저장된 메시지 다이제스트를 생성했음을 보여줍니다.
generate 속성은 파일 시스템이 독립적으로 메시지 다이제스트를 재계산하고 파일을 아카이브할 때마다 저장된 값에 대해 결과를 검증함을 보여줍니다.
use 속성은 파일 시스템이 독립적으로 메시지 다이제스트를 재계산하고 파일을 스테이지할 때마다 저장된 값에 대해 결과를 검증함을 보여줍니다.
validated 속성은 독립적으로 계산된 메시지 다이제스트가 마지막 검사 시 hash 속성에 저장된 값과 일치함을 보여줍니다.
fixity 속성은 파일을 변경 불가능으로 만든 경우 나타납니다.
법적 또는 아카이브 고려 사항이 필요한 경우 WORM(Write Once Read Many)을 지원하도록 구성된 Oracle HSM 파일 시스템에 해당 디렉토리 및 파일을 만들 수 있습니다. 이 절에서는 WORM 파일 시스템 이해에 초점을 맞추고 WORM 파일 및 디렉토리를 사용할 때 수행할 특정 작업에 대해 설명합니다.
파일 시스템의 WORM 지원 사용에 대한 자세한 내용은 Oracle Hierarchical Storage Manager and StorageTek QFS 설치 및 구성 설명서를 참조하십시오.
WORM(Write Once Read Many) 파일 시스템은 사용자가 지정된 보존 기간 동안 파일을 읽기 전용으로 만들어 데이터를 보호할 수 있습니다. WORM 가능 Oracle HSM 파일 시스템은 기본/사용자 정의 가능 파일 보존 기간, 데이터 및 경로 불변성, 하위 디렉토리의 WORM 설정 상속을 지원합니다.
파일 시스템의 구성 방법에 따라 두 가지 Oracle HSM WORM 모드 중 하나를 사용할 수 있습니다.
표준 준수 모드(기본값)
에뮬레이션 모드
표준 WORM 모드로 마운트된 파일 시스템에서 사용자는 디렉토리에 WORM을 사용으로 설정하고 chmod 4000 path_name 명령(여기서 path_name은 파일/디렉토리의 경로 및 이름)을 실행하여 파일의 읽기 전용 보존 기간을 시작합니다. 이는 UNIX setuid(실행 시 사용자 ID 설정) 권한을 설정합니다. execute 권한이 있는 파일에 setuid 권한을 설정하면 보안 위험이 있으므로 표준 WORM 모드에서는 비실행 파일만 읽기 전용으로 만들 수 있습니다.
WORM 에뮬레이션 모드로 마운트된 파일 시스템에서 사용자는 디렉토리에 WORM을 사용으로 설정하고 chmod 555 path_name 명령(여기서 path_name은 쓰기 가능 파일/디렉토리의 경로 및 이름)을 실행하여 파일의 읽기 전용 보존 기간을 시작합니다. 에뮬레이션 모드에는 setuid 권한이 필요하지 않으므로 실행 파일을 읽기 전용으로 만들고 보존 기간을 지정할 수 있습니다.
표준 및 에뮬레이션 모드는 모두 엄격한 WORM 구현과 덜 제한적인 라이트 구현을 지원합니다. 엄격한 구현과 라이트 구현 모두 파일이나 디렉토리에 보존 기간이 트리거된 이후 데이터나 경로 변경을 허용하지 않습니다. 둘 다 기본 보존 기간을 43,200분(30일)으로 설정합니다. 그러나 라이트 구현은 root 사용자의 제한을 완화합니다.
엄격한 구현에서는 누구도 지정된 보존 기간을 단축하거나 보존 기간이 끝나기 전에 파일이나 디렉토리를 삭제할 수 없습니다. 또한 누구도 sammkfs를 사용하여 현재 보관된 파일과 디렉토리를 보유한 볼륨을 삭제할 수 없습니다. 따라서 엄격한 구현은 가장 까다로운 법적 규정 준수 및 보존 요구 사항을 충족하기에 매우 적합합니다.
라이트 구현에서는 root 사용자가 보존 기간을 단축하고, 파일 및 디렉토리를 삭제하고, sammkfs 명령을 사용하여 볼륨을 삭제할 수 있습니다. 이는 가벼운 데이터 손실에 대해 높은 수준의 보호를 제공하며 파일 시스템과 스토리지 리소스를 관리할 때 유연성이 증대됩니다. 그러나 수퍼 유저에게 이 정도의 통제를 허용하는 파일 시스템은 일부 법적 규정 준수 요구 사항을 충족할 수 없습니다.
WORM 파일에 대한 하드 및 소프트 링크를 만들 수 있습니다. WORM 가능 디렉토리에 상주하는 파일에는 하드 링크만 만들 수 있습니다. 하드 링크를 만든 후에 WORM 특성은 원래 파일과 동일합니다. 소프트 링크도 설정할 수 있지만, 소프트 링크는 WORM 기능을 사용할 수 없습니다. WORM 파일에 대한 소프트 링크는 Oracle HSM 파일 시스템의 아무 디렉토리에 만들 수 있습니다.
WORM 파일 시스템 만들기 및 구성에 대한 자세한 내용은 고객 설명서 라이브러리의 Oracle Hierarchical Storage Manager and StorageTek QFS 설치 및 구성 설명서를 참조하십시오.
디렉토리에 WORM을 사용으로 설정할 때 WORM 파일 지원을 추가하되, 디렉토리의 특성은 변경하지 않습니다. 사용자는 계속해서 WORM 가능 디렉토리 내에 파일을 만들고 편집할 수 있으며, WORM 파일을 포함하지 않는 WORM 가능 디렉토리는 삭제할 수 있습니다. 디렉토리에 WORM을 사용으로 설정하려면 다음과 같이 하십시오.
파일 시스템 서버에 로그인합니다.
user@solaris:~#
디렉토리에 이미 WORM이 사용으로 설정되었는지 확인합니다. sls -Dd directory 명령을 사용합니다. 여기서 directory는 디렉토리의 경로 및 이름입니다. 명령 출력에서 worm-capable 속성을 찾습니다.
대개 디렉토리에는 WORM이 사용으로 설정됩니다. 사용자가 디렉토리에 WORM을 사용으로 설정할 때 모든 현재와 미래 하위 디렉토리가 WORM 기능을 상속하기 때문입니다. 명령에 대한 자세한 내용은 sls 매뉴얼 페이지를 참조하십시오. 첫번째 예제에서 대상 디렉토리 /hsm/hsmfs1/records에 이미 WORM이 사용으로 설정되어 있음을 알 수 있습니다.
user@solaris:~# sls -Dd /hsm/hsmfs1/records/2013/ /hsm/hsmfs1/records/2013: mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1048.1 project: user.root(1) access: Mar 3 12:15 modification: Mar 3 12:15 changed: Mar 3 12:15 attributes: Mar 3 12:15 creation: Mar 3 12:15 residence: Mar 3 12:15 worm-capable retention-period: 0y, 30d, 0h, 0m
그러나 두번째 예제에서는 대상 디렉토리 /hsm/hsmfs1/documents에 WORM이 사용으로 설정되지 않았습니다.
user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28
디렉토리에 WORM이 사용으로 설정되지 않았을 때 파일 시스템이 worm_capable 또는 worm_lite 마운트 옵션으로 마운트된 경우 Solaris 명령 chmod 4000 directory-name(여기서 directory-name은 WORM 파일을 보유할 디렉토리의 경로 및 이름)으로 WORM 지원을 사용으로 설정합니다.
chmod 4000 명령은 디렉토리에 setuid(실행 시 사용자 ID 설정) 속성을 설정하고 표준 WORM 지원을 사용으로 설정합니다. 예제에서는 /hsm/hsmfs1/documents 디렉토리에 WORM을 사용으로 설정하고 sls -Dd로 결과를 확인합니다. 작업을 성공하고 디렉토리에 WORM이 사용으로 설정됩니다.
user@solaris:~# chmod 4000 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
디렉토리에 WORM이 사용으로 설정되지 않았을 때 파일 시스템이 worm_emul 또는 emul_lite 마운트 옵션으로 마운트된 경우 Solaris 명령 chmod 555 directory-name(여기서 directory-name은 WORM 파일을 보유할 디렉토리의 경로 및 이름)으로 WORM 지원을 사용으로 설정합니다.
chmod 555 명령은 디렉토리에 쓰기 권한을 제거하고 WORM 에뮬레이션 지원을 사용으로 설정합니다. 예제에서는 /hsm/hsmfs1/documents 디렉토리에 WORM을 사용으로 설정하고 sls -Dd 명령을 사용하여 결과를 확인합니다. 작업을 성공하고 디렉토리에 WORM이 사용으로 설정됩니다.
user@solaris:~# chmod 555 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
WORM 가능 디렉토리의 파일에 WORM 보호를 활성화할 경우, 보존 기간이 만료될 때까지 파일 시스템은 더 이상 파일 데이터나 데이터 경로에 대한 수정을 허용하지 않습니다. 따라서 주의해서 사용해야 합니다. WORM 보호를 활성화하려면 다음과 같이 하십시오.
파일 시스템 서버에 로그인합니다.
user@solaris:~#
기본값 이외의 일정 기간 동안 파일 시스템에 파일을 보관해야 하는 경우 파일에 액세스 시간을 변경하여 필요한 보존 시간을 지정합니다. Solaris 명령 touch -a -texpiration-date path-name을 사용합니다. 설명:
expiration-date는 4자리 연도, 2자리 월, 2자리 일, 2자리 시, 2자리 분, 선택적으로 2자리 초로 구성된 숫자 문자열입니다.
path-name은 파일의 경로 및 이름입니다.
Oracle Solaris UNIX 유틸리티 touch는 2038년 1월 18일 오후 10시 14분을 넘어 보존 기간을 연장할 수 없습니다. 이 유틸리티는 부호 있는 32비트 숫자를 사용하여 1970년 1월 1일부터 시작하는 시간을 초 단위로 표현합니다. 따라서 이 마감일을 넘어 파일을 보관해야 하는 경우 기본 보존 기간을 사용합니다.
예제에서는 4년 후 2019년 10월 4일 오전 11시 59분에 파일의 보존 기간이 만료되도록 설정합니다.
user@solaris:~# touch -a -t201910141159 /hsm/hsmfs1/plans/master.odt
파일 시스템이 worm_capable 또는 worm_lite 마운트 옵션으로 마운트된 경우 Solaris 명령 chmod 4000 path-name(여기서 path-name은 파일의 경로 및 이름)으로 WORM 보호를 활성화합니다.
chmod 4000 명령은 지정된 파일에 setuid(실행 시 사용자 ID 설정) 속성을 설정합니다. 이 속성을 실행 파일에 설정하면 안전하지 않습니다. 따라서 파일 시스템이 worm_capable 또는 worm_lite 마운트 옵션으로 마운트된 경우 UNIX execute 권한이 있는 파일에 WORM 보호를 설정할 수 없습니다.
예제에서는 master.odt 파일에 WORM 보호를 활성화합니다. sls -D로 결과를 확인합니다. retention 속성이 지금 active로 설정되고 retention-period가 4년으로 설정되어 있습니다.
user@solaris:~# chmod 4000 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
파일 시스템이 worm_emul 또는 emul_lite 마운트 옵션으로 마운트된 경우 Solaris 명령 chmod 555 path-name(여기서 path-name은 파일의 경로 및 이름)으로 WORM 보호를 활성화합니다.
chmod 555 명령은 디렉토리에 쓰기 권한을 제거합니다. 따라서 필요한 경우 실행 파일을 WORM으로 보호할 수 있습니다. 예제에서는 master-plan.odt 파일에 WORM 보존 기간을 활성화합니다. sls -D로 결과를 확인합니다. retention 속성이 지금 active로 설정되고 retention-period가 4년으로 설정되어 있습니다.
user@solaris:~# chmod 555 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
지정된 검색 조건을 충족하는 WORM 파일을 찾고 나열하려면 sfind 명령을 사용합니다. 다음과 같이 하십시오.
파일 시스템 서버에 로그인합니다.
user@solaris:~#
WORM으로 보호되고 활발히 보관 중인 파일을 나열하려면 sfind starting-directory -ractive 명령을 사용합니다. 여기서 starting-directory는 나열 프로세스를 시작하려는 디렉토리의 경로 및 이름입니다.
user@solaris:~# sfind /hsm/hsmfs1/ -ractive /hsm/hsmfs1/documents/2013/master-plan.odt /hsm/hsmfs1/documents/2013/schedule.ods /samma1/records/2013/progress/report01.odt /samma1/records/2013/progress/report02.odt /samma1/records/2013/progress/report03.odt ... user@solaris:~#
보존 기간이 만료된 WORM 보호 파일을 나열하려면 sfind starting-directory -rover 명령을 사용합니다. 여기서 starting-directory는 나열 프로세스를 시작하려는 디렉토리의 경로 및 이름입니다.
user@solaris:~# sfind /hsm/hsmfs1/ -rover /samma1/documents/2007/master-plan.odt /samma1/documents/2007/schedule.ods user@solaris:~#
지정된 날짜 및 시간 후에 보존 기간이 만료될 WORM 보호 파일을 나열하려면 sfind starting-directory -rafter expiration-date 명령을 사용합니다. 설명:
starting-directory는 나열 프로세스를 시작하려는 디렉토리의 경로 및 이름입니다.
expiration-date는 4자리 연도, 2자리 월, 2자리 일, 2자리 시, 2자리 분, 선택적으로 2자리 초로 구성된 숫자 문자열입니다.
예제에서는 2015년 1월 1일 자정을 지나 1분 후에 보존 기간이 만료되는 파일을 나열합니다.
user@solaris:~# sfind /hsm/hsmfs1/ -rafter 201501010001 /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
적어도 지정된 시간 동안 파일 시스템에 남아야 하는 WORM 보호 파일을 나열하려면 sfind starting-directory -rremain time-remaining 명령을 사용합니다. 설명:
starting-directory는 검색이 시작되는 디렉토리 트리의 위치입니다.
time-remaining은 시간 단위와 쌍을 이루는 음이 아닌 정수 문자열로 y(연도), d(일), h(시간), m(분)을 나타냅니다.
예제에서는 /hsm/hsmfs1/ 디렉토리에서 적어도 3년 이상 보관할 모든 파일을 찾습니다.
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
지정된 시간 이상 동안 파일 시스템에 남아야 하는 WORM 보호 파일을 나열하려면 sfind starting-directory -rlonger time 명령을 사용합니다. 설명:
starting-directory는 검색이 시작되는 디렉토리 트리의 위치입니다.
time-remaining은 시간 단위와 쌍을 이루는 음이 아닌 정수 문자열로 y(연도), d(일), h(시간), m(분)을 나타냅니다.
예제에서는 /hsm/hsmfs1/ 디렉토리에서 3년 90일 이상 보관할 모든 파일을 찾습니다.
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y90d /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
영구적으로 파일 시스템에 남아야 하는 WORM 보호 파일을 나열하려면 sfind starting-directory -rpermanent 명령을 사용합니다.
예제에서는 /hsm/hsmfs1/ 디렉토리 아래의 어떤 파일도 영구적으로 보관되지 않습니다.
user@solaris:~# sfind /hsm/hsmfs1/ -rpermanent user@solaris:~#