기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 데이터 리포지토리에서 변경 내용 가져오기
연결된 데이터 리포지토리에서 Amazon FSx 파일 시스템으로 데이터 및 POSIX 메타데이터에 대한 변경 내용을 가져올 수 있습니다. 관련 POSIX 메타데이터에는 소유권, 권한 및 타임스탬프가 포함됩니다.
파일 시스템에 변경 내용을 가져오려면 다음 방법 중 하나를 사용합니다.
+ 연결된 데이터 리포지토리에서 새 파일, 변경 또는 삭제된 파일을 자동으로 가져오도록 파일 시스템을 구성합니다. 자세한 내용은 [S3 버킷에서 업데이트 자동 가져오기](autoimport-data-repo-dra.md) 섹션을 참조하세요.
+ 데이터 리포지토리 연결을 만들 때 메타데이터를 가져오는 옵션을 선택합니다. 이렇게 하면 데이터 리포지토리 연결을 생성한 후 즉시 데이터 리포지토리 가져오기 작업이 시작됩니다.
+ 온디맨드 데이터 리포지토리 가져오기 작업을 사용합니다. 자세한 내용은 [데이터 리포지토리 작업을 사용하여 변경 내용 가져오기](import-data-repo-task-dra.md) 섹션을 참조하세요.
데이터 리포지토리 자동 가져오기 및 가져오기 작업을 동시에 실행할 수 있습니다.
데이터 리포지토리 연결에 대해 자동 가져오기를 켜면 S3에서 객체가 생성, 수정 또는 삭제될 때 파일 시스템이 파일 메타데이터를 자동으로 업데이트합니다. 데이터 리포지토리 연결을 생성할 때 메타데이터를 가져오는 옵션을 선택하면 파일 시스템이 데이터 리포지토리의 모든 객체에 대한 메타데이터를 가져옵니다. 데이터 리포지토리 가져오기 작업을 사용하여 가져오는 경우 파일 시스템은 마지막 가져오기 이후 생성되거나 수정된 객체의 메타데이터만 가져옵니다.
FSx for Lustre는 애플리케이션이 파일 시스템의 파일에 처음 액세스할 때 데이터 리포지토리에서 파일의 내용을 자동으로 복사하여 파일 시스템으로 로드합니다. 이러한 데이터 이동은 FSx for Lustre에서 관리되며 애플리케이션에 영향을 미치지 않습니다. 이후 이러한 파일에 대한 읽기는 1밀리초 미만의 지연 시간으로 파일 시스템에서 직접 제공됩니다.
전체 파일 시스템 또는 파일 시스템 내의 디렉터리를 미리 로드할 수도 있습니다. 자세한 내용은 [파일 시스템에 파일 미리 로드](preload-file-contents-hsm-dra.md) 섹션을 참조하세요. 여러 파일의 사전 로드를 동시에 요청하면 FSx for Lustre는 Amazon S3 데이터 리포지토리에서 파일을 병렬로 로드합니다.
FSx for Lustre는 POSIX 호환 객체 키가 있는 S3 객체만 가져옵니다. 데이터 리포지토리 자동 가져오기 및 가져오기 작업 모두 POSIX 메타데이터를 가져옵니다. 자세한 내용은 [데이터 리포지토리에 대한 POSIX 메타데이터 지원](posix-metadata-support.md) 섹션을 참조하세요.
**참고**
FSx for Lustre는 S3 Glacier Flexible Retrieval 및 S3 Glacier Deep Archive 스토리지 클래스에서 심볼릭 링크(symlink)에 대한 메타데이터 가져오기를 지원하지 않습니다. 심볼릭 링크가 아닌 S3 Glacier Flexiver Flexival 또는 S3 Glacier Deep Archive 객체의 메타데이터를 가져올 수 있습니다. 즉, 올바른 메타데이터를 사용하여 FSx for Lustre 파일 시스템에 inode가 생성됩니다. 그러나 파일 시스템에서 이 데이터를 읽으려면 먼저 S3 Glacier Flexible Retrieval 또는 S3 Glacier Slacier Deep Archive 객체를 복원해야 합니다. S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스에 있는 Amazon S3 객체에서 FSx for Lustre로 파일 데이터를 직접 가져올 수 없습니다.
# S3 버킷에서 업데이트 자동 가져오기
객체가 S3 버킷에 추가, 변경 또는 삭제될 때 파일 시스템의 메타데이터를 자동으로 업데이트하도록 FSx for Lustre를 구성할 수 있습니다. FSx for Lustre는 S3의 변경에 따라 파일 및 디렉터리 목록을 생성, 업데이트 또는 삭제합니다. S3 버킷의 변경된 객체가 더 이상 메타데이터를 포함하지 않는 경우 FSx for Lustre는 현재 권한을 포함하여 파일의 현재 메타데이터 값을 유지합니다.
**참고**
업데이트를 자동으로 가져오려면 FSx for Lustre 파일 시스템과 연결된 S3 버킷이 같은 AWS 리전 에 위치해야 합니다.
데이터 리포지토리 연결을 생성할 때 자동 가져오기를 구성할 수 있으며, FSx 관리 콘솔, AWS CLI또는 AWS API를 사용하여 언제든지 자동 가져오기 설정을 업데이트할 수 있습니다.
**참고**
동일한 데이터 리포지토리 연결에서 자동 가져오기와 자동 내보내기를 모두 구성할 수 있습니다. 이 항목에서는 자동 가져오기 기능에 대해서만 설명합니다.
**중요**
자동 가져오기 정책이 모두 활성화되고 자동 내보내기가 비활성화된 상태에서 S3에서 객체를 수정하면 해당 객체의 내용을 항상 파일 시스템의 해당 파일로 가져옵니다. 파일이 대상 위치에 이미 있는 경우 해당 파일을 덮어씁니다.
모든 자동 가져오기 및 자동 내보내기 정책이 활성화된 상태에서 파일 시스템과 S3에서 파일을 수정하면 파일 시스템의 파일이나 S3의 객체를 다른 사람이 덮어쓸 수 있습니다. 한 위치에서 나중에 편집해도 다른 위치에서 이전에 편집한 내용을 덮어쓴다는 보장은 없습니다. 파일 시스템과 S3 버킷 모두에서 동일한 파일을 수정하는 경우 애플리케이션 수준의 조정을 통해 이러한 충돌을 방지해야 합니다. FSx for Lustre는 여러 위치에서의 쓰기 충돌을 방지하지 않습니다.
가져오기 정책은 연결된 S3 버킷의 콘텐츠가 변경될 때 FSx for Lustre가 파일 시스템을 업데이트하는 방법을 지정합니다. 데이터 리포지토리 연결의 가져오기 정책은 다음 중 하나에 해당될 수 있습니다.
+ **신규** - FSx for Lustre는 연결된 S3 데이터 리포지토리에 새 객체가 추가될 때만 파일 및 디렉터리 메타데이터를 자동으로 업데이트합니다.
+ **변경됨** - FSx for Lustre는 데이터 리포지토리의 기존 객체가 변경될 때만 파일 및 디렉터리 메타데이터를 자동으로 업데이트합니다.
+ **삭제됨** - FSx for Lustre는 데이터 리포지토리의 객체가 삭제될 때만 파일 및 디렉터리 메타데이터를 자동으로 업데이트합니다.
+ **신규, 변경됨, 삭제됨의 모든 조합** - FSx for Lustre는 S3 데이터 리포지토리에서 지정된 작업이 발생할 경우 파일 및 디렉터리 메타데이터를 자동으로 업데이트합니다. 예를 들어 객체가 S3 리포지토리에 추가(**신규**)되거나 제거(**삭제됨**)될 때 파일 시스템이 업데이트되고, 객체가 변경되면 업데이트되지 않도록 지정할 수 있습니다.
+ **정책이 구성되지 않음** - FSx for Lustre는 객체가 S3 데이터 리포지토리에 추가, 변경 또는 삭제될 때 파일 시스템의 파일 및 디렉터리 메타데이터를 업데이트하지 않습니다. 가져오기 정책을 구성하지 않으면 데이터 리포지토리 연결에 대한 자동 가져오기가 비활성화됩니다. [데이터 리포지토리 작업을 사용하여 변경 내용 가져오기](import-data-repo-task-dra.md)에 설명된 대로 여전히 데이터 리포지토리 가져오기 작업을 사용하여 메타데이터 변경 내용을 수동으로 가져올 수 있습니다.
**중요**
자동 가져오기는 다음 S3 작업을 연결된 FSx for Lustre 파일 시스템과 동기화하지 않습니다.
S3 객체 수명 주기 만료를 사용하여 객체 삭제
버전 관리가 활성화된 버킷에서 현재 객체 버전 영구 삭제
버전 관리 활성화 버킷에서 객체 삭제 취소
대부분의 사용 사례에서는 가져오기 정책을 **신규**, **변경됨**, **삭제됨**으로 구성하는 것이 좋습니다. 이 정책은 연결된 S3 데이터 리포지토리에서 이루어진 모든 업데이트를 파일 시스템으로 자동으로 가져오도록 합니다.
연결된 S3 데이터 리포지토리의 변경 내용을 기반으로 파일 시스템 파일 및 디렉터리 메타데이터를 업데이트하도록 가져오기 정책을 설정하면 FSx for Lustre는 연결된 S3 버킷에 이벤트 알림 구성을 생성합니다. 이벤트 알림 구성에는 `FSx` 이름이 지정됩니다. S3 버킷의 `FSx` 이벤트 알림 구성을 수정하거나 삭제하지 마세요. 수정하거나 삭제하면 업데이트된 파일 및 디렉터리 메타데이터를 파일 시스템으로 자동으로 가져올 수 없습니다.
FSx for Lustre가 연결된 S3 데이터 리포지토리에서 변경된 파일 목록을 업데이트하면 파일이 쓰기 잠겨 있더라도 로컬 파일을 업데이트된 버전으로 덮어씁니다.
FSx for Lustre는 파일 시스템을 업데이트하기 위해 최선을 다합니다. FSx for Lustre는 다음과 같은 상황에서 파일 시스템을 업데이트할 수 없습니다.
+ FSx for Lustre에 변경되거나 새 S3 객체를 열 수 있는 권한이 없는 경우. 이 경우 FSx for Lustre는 객체를 건너뛰고 계속합니다. DRA 수명 주기 상태는 영향을 받지 않습니다.
+ FSx for Lustre에 버킷 수준 권한이 없는 경우(예: `GetBucketAcl`). 이로 인해 데이터 리포지토리 수명 주기 상태가 **잘못 구성**될 수 있습니다. 자세한 내용은 [데이터 리포지토리 연결 수명 주기 상태](dra-lifecycles.md) 섹션을 참조하세요.
+ 연결된 S3 버킷의 `FSx` 이벤트 알림 구성이 삭제되거나 변경된 경우 이로 인해 데이터 리포지토리 수명 주기 상태가 **잘못 구성**될 수 있습니다. 자세한 내용은 [데이터 리포지토리 연결 수명 주기 상태](dra-lifecycles.md) 섹션을 참조하세요.
자동으로 가져올 수 없는 파일 또는 디렉터리에 대한 정보를 기록하려면 CloudWatch Logs [로깅을 활성화](cw-event-logging.md#manage-logging)하는 것이 좋습니다. 로그의 경고 및 오류에는 실패 이유에 대한 정보가 포함됩니다. 자세한 내용은 [데이터 리포지토리 이벤트 로그](data-repo-event-logs.md) 섹션을 참조하세요.
## 사전 조건
FSx for Lustre가 연결된 S3 버킷에서 새 파일, 변경 또는 삭제된 파일을 자동으로 가져오려면 다음 조건이 필요합니다.
+ 파일 시스템과 연결된 S3 버킷은 같은 AWS 리전에 위치합니다.
+ S3 버킷에는 잘못 구성된 **수명 주기 상태**가 없습니다. 자세한 내용은 [데이터 리포지토리 연결 수명 주기 상태](dra-lifecycles.md) 섹션을 참조하세요.
+ 계정에는 연결된 S3 버킷에서 이벤트 알림을 구성하고 수신하는 데 필요한 권한이 있습니다.
## 지원되는 파일 변경 유형
FSx for Lustre는 연결된 S3 버킷에서 발생하는 파일 및 디렉터리에 대한 다음과 같은 변경 사항 가져오기를 지원합니다.
+ 파일 콘텐츠 변경.
+ 파일 또는 디렉터리 메타데이터 변경.
+ 심볼릭 링크 대상 또는 메타데이터 변경.
+ 파일 및 디렉터리 삭제. 연결된 S3 버킷에서 파일 시스템의 디렉터리에 해당하는 객체(즉, 키 이름이 슬래시로 끝나는 객체)를 삭제하는 경우 FSx for Lustre는 비어 있는 경우에만 파일 시스템에서 해당 디렉터리를 삭제합니다.
## 가져오기 설정 업데이트
데이터 리포지토리 연결을 생성할 때 연결된 S3 버킷에 대한 파일 시스템의 가져오기 설정을 지정할 수 있습니다. 자세한 내용은 [S3 버킷 링크 생성](create-linked-dra.md) 섹션을 참조하세요.
또한 가져오기 정책을 포함하여 가져오기 설정을 언제든지 업데이트할 수 있습니다. 자세한 내용은 [데이터 리포지토리 연결 설정 업데이트](update-dra-settings.md) 섹션을 참조하세요.
## 자동 가져오기 모니터링
S3 버킷의 변경 비율이 자동 가져오기에서 이러한 변경 사항을 처리할 수 있는 속도를 초과하는 경우 FSx for Lustre 파일 시스템으로 가져오는 해당 메타데이터 변경 사항이 지연됩니다. 이 경우 `AgeOfOldestQueuedMessage` 지표를 사용하여 자동 가져오기로 처리되기를 기다리는 가장 오래된 변경 사항의 보존 기간을 모니터링할 수 있습니다. 이러한 지표에 대한 자세한 내용은 [FSx for Lustre S3 리포지토리 지표](fs-metrics.md#auto-import-export-metrics) 섹션을 참조하세요.
메타데이터 변경 사항 가져오기 지연이 14일(`AgeOfOldestQueuedMessage` 지표를 사용하여 측정)을 초과하는 경우, 자동 가져오기로 처리되지 않은 S3 버킷의 변경 사항은 파일 시스템으로 가져오지 않습니다. 또한 데이터 리포지토리 연결 수명 주기가 **잘못 구성**된 것으로 표시되고 자동 가져오기가 중지됩니다. 자동 내보내기를 활성화한 경우 자동 내보내기는 FSx for Lustre 파일 시스템의 변경 사항을 계속 모니터링합니다. 하지만 추가 변경 사항은 FSx for Lustre 파일 시스템에서 S3로 동기화되지 않습니다.
데이터 리포지토리 연결을 **잘못 구성됨** 수명 주기 상태에서 **사용 가능** 수명 주기 상태로 되돌리려면 데이터 리포지토리 연결을 업데이트해야 합니다. [Update-data-repository-association](https://docs.aws.amazon.com/cli/latest/reference/fsx/update-data-repository-association.html) CLI 명령(또는 해당 [UpdateDataRepositoryAssociation](https://docs.aws.amazon.com/fsx/latest/APIReference/API_UpdateDataRepositoryAssociation.html) API 작업)을 사용하여 데이터 리포지토리 연결을 업데이트할 수 있습니다. 필요한 유일한 요청 파라미터는 업데이트하려는 데이터 리포지토리 연결의 `AssociationID`입니다.
데이터 리포지토리 연결 수명 주기 상태가 **사용 가능**으로 변경되면 자동 가져오기(활성화된 경우 자동 내보내기)가 다시 시작됩니다. 다시 시작하면 자동 내보내기가 재개되어 파일 시스템 변경 사항을 S3에 동기화합니다. 가져오지 않았거나 데이터 리포지토리 연결이 잘못 구성된 상태였을 때 가져온 FSx for Lustre 파일 시스템과 S3에 있는 새 객체 및 변경된 객체의 메타데이터를 동기화하려면 [데이터 리포지토리 가져오기 작업](import-data-repo-task-dra.md)을 실행합니다. 데이터 리포지토리 가져오기 작업은 S3 버킷의 삭제를 FSx for Lustre 파일 시스템과 동기화하지 않습니다. S3를 파일 시스템과 완전히 동기화(삭제 포함)하려면 파일 시스템을 다시 생성해야 합니다.
메타데이터 변경 사항 가져오기 지연이 14일을 초과하지 않도록 하려면 `AgeOfOldestQueuedMessage` 지표에 경보를 설정하고 `AgeOfOldestQueuedMessage` 지표가 경보 임곗값을 초과할 경우 S3 버킷의 활동을 줄이는 것이 좋습니다. 단일 샤드가 S3로부터 가능한 변경 사항을 지속적으로 전송하는 S3 버킷에 연결된 FSx for Lustre 파일 시스템의 경우, FSx for Lustre 파일 시스템에서 자동 가져오기만 실행되는 경우, 자동 가져오기는 14일 이내에 7시간 동안 S3 변경 사항 백로그를 처리할 수 있습니다.
또한 단일 S3 작업으로 자동 가져오기에서 14일 동안 처리할 수 있는 것보다 더 많은 변경 사항을 생성할 수 있습니다. 이러한 유형의 작업의 예로는 S3로의 AWS Snowball 업로드 및 대규모 삭제가 포함되지만 이에 국한되지는 않습니다. FSx for Lustre 파일 시스템과 동기화하려는 S3 버킷을 대규모로 변경하는 경우, 자동 가져오기 변경 사항이 14일을 초과하지 않도록 하려면 파일 시스템을 삭제하고 S3 변경이 완료되면 다시 생성해야 합니다.
`AgeOfOldestQueuedMessage` 지표가 증가하고 있는 경우 S3 버킷의 `GetRequests`, `PutRequests`, `PostRequests` 및 `DeleteRequests` 지표에서 자동 가져오기로 전송되는 변경 사항의 비율 및/또는 수를 증가시킬 수 있는 활동 변경 사항이 있는지 검토하세요. 사용 가능한 S3 지표에 대한 자세한 내용은 *Amazon S3 사용 설명서*의 [Amazon S3 모니터링](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html)을 참조하세요.
사용 가능한 모든 FSx for Lustre 지표 목록은 [Amazon CloudWatch를 사용한 모니터링](monitoring-cloudwatch.md) 섹션을 참조하세요.
# 데이터 리포지토리 작업을 사용하여 변경 내용 가져오기
데이터 리포지토리 가져오기 작업은 S3 데이터 리포지토리에서 새로 추가되거나 변경된 객체의 메타데이터를 가져와서 S3 데이터 리포지토리의 모든 새 객체에 대한 새 파일 또는 디렉터리 목록을 생성합니다. 데이터 리포지토리에서 변경된 모든 객체의 경우 해당 파일 또는 디렉터리 목록이 새 메타데이터로 업데이트됩니다. 데이터 리포지토리에서 삭제된 객체에는 아무런 조치가 취해지지 않습니다.
Amazon FSx 콘솔 및 CLI를 사용하여 메타데이터 변경 내용을 가져오려면 다음 절차를 따르세요. 여러 DRA에 대해 하나의 데이터 리포지토리 작업을 사용할 수 있다는 점에 유의하세요.
## 메타데이터 변경 내용을 가져오기(콘솔)
1. [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/)에서 Amazon FSx 콘솔을 엽니다.
1. 탐색 창에서 **파일 시스템**을 선택한 다음 Lustre 파일 시스템을 선택합니다.
1. **데이터 리포지토리** 탭을 선택합니다.
1. **데이터 리포지토리 연결** 패널에서 가져오기 작업을 만들 데이터 리포지토리 연결을 선택합니다.
1. **작업** 메뉴에서 **작업 실행**을 선택합니다. 파일 시스템이 데이터 리포지토리에 연결되지 않은 경우에는 이 옵션을 사용할 수 없습니다. **가져오기 데이터 리포지토리 만들기 작업** 페이지가 표시됩니다.
1. (선택 사항) **가져올 데이터 리포지토리 경로**에 해당 디렉터리 또는 파일의 경로를 제공하여 연결된 S3 버킷에서 가져올 디렉터리 또는 파일을 최대 32개까지 지정합니다.
**참고**
제공한 경로가 유효하지 않으면 작업이 실패합니다.
1. (선택 사항) 작업 완료 후 작업 완료 보고서를 생성하려면 **완료 보고서**에서 **활성화**를 선택합니다. *작업 완료 보고서*는 **보고서 범위**에 제공된 범위를 충족하는 작업으로 처리된 파일에 대한 세부 정보를 제공합니다. Amazon FSx가 보고서를 전송할 위치를 지정하려면 연결된 S3 데이터 리포지토리의 상대 경로를 **보고서 경로**에 입력합니다.
1. **생성(Create)**을 선택합니다.
**파일 시스템** 페이지 상단의 알림에는 방금 생성한 작업이 진행 중이라는 내용이 표시됩니다.
작업 상태 및 세부 정보를 보려면 파일 시스템의 **데이터 리포지토리** 탭에서 **데이터 리포지토리 작업** 창으로 스크롤합니다. 기본 정렬 순서는 목록의 맨 위에 가장 최근 작업을 표시합니다.
이 페이지에서 작업 요약을 보려면 방금 생성한 작업의 **작업 ID**를 선택합니다. 작업의 **요약** 페이지가 표시됩니다.
## 메타데이터 변경 내용을 가져오기(CLI)
+ [https://docs.aws.amazon.com/cli/latest/reference/fsx/create-data-repository-task.html](https://docs.aws.amazon.com/cli/latest/reference/fsx/create-data-repository-task.html) CLI 명령을 사용하여 FSx for Lustre 파일 시스템에서 메타데이터 변경 내용을 가져올 수 있습니다. 해당 API 작업은 [https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateDataRepositoryTask.html](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateDataRepositoryTask.html)입니다.
```
$ aws fsx create-data-repository-task \
--file-system-id fs-0123456789abcdef0 \
--type IMPORT_METADATA_FROM_REPOSITORY \
--paths s3://bucketname1/dir1/path1 \
--report Enabled=true,Path=s3://bucketname1/dir1/path1,Format=REPORT_CSV_20191124,Scope=FAILED_FILES_ONLY
```
데이터 리포지토리 작업을 생성한 후 Amazon FSx는 작업 설명을 JSON으로 반환합니다.
연결된 데이터 리포지토리에서 메타데이터를 가져오는 작업을 생성한 후 데이터 리포지토리 가져오기 작업의 상태를 확인할 수 있습니다. 데이터 리포지토리 보기에 대한 자세한 내용은 [데이터 리포지토리 작업 액세스](view-data-repo-tasks.md) 섹션을 참조하세요.
# 파일 시스템에 파일 미리 로드
선택 사항으로, 콘텐츠 개별 파일 또는 디렉터리를 파일 시스템에 미리 로드할 수 있습니다.
## HSM 명령을 사용하여 파일 가져오기
Amazon FSx는 파일에 처음 액세스할 때 Amazon S3 데이터 리포지토리에서 데이터를 복사합니다. 이 접근 방식 때문에 파일에 대한 초기 읽기 또는 쓰기 작업에는 약간의 지연 시간이 발생합니다. 애플리케이션이 이러한 지연 시간에 민감하고 애플리케이션이 액세스해야 하는 파일 또는 디렉터리를 알고 있는 경우 선택적으로 개별 파일 또는 디렉터리의 콘텐츠를 미리 로드할 수 있습니다. 다음과 같이 `hsm_restore` 명령을 사용하여 관리할 수 있습니다.
`hsm_action` 명령(`lfs` 사용자 유틸리티와 함께 실행)을 사용하여 파일 콘텐츠가 파일 시스템에 로드되었는지 확인할 수 있습니다. 반환 값이 `NOOP`이면 파일이 로드되었음을 나타냅니다. 파일 시스템이 마운트된 컴퓨팅 인스턴스에서 다음 명령을 실행합니다. *path/to/file*을 파일 시스템에 미리 로드하는 파일의 경로로 바꿉니다.
```
sudo lfs hsm_restore path/to/file
sudo lfs hsm_action path/to/file
```
다음 명령을 사용하여 전체 파일 시스템 또는 파일 시스템 내의 전체 디렉터리를 미리 로드할 수 있습니다. (후행 앰퍼샌드를 사용하면 명령이 백그라운드 프로세스로 실행됩니다.) 여러 파일의 사전 로드를 동시에 요청하는 경우 Amazon FSx는 Amazon S3 데이터 리포지토리에서 파일을 병렬로 로드합니다. 파일이 이미 파일 시스템에 로드된 경우, `hsm_restore` 명령은 파일을 다시 로드하지 않습니다.
```
nohup find local/directory -type f -print0 | xargs -0 -n 1 -P 8 sudo lfs hsm_restore &
```
**참고**
연결된 S3 버킷이 파일 시스템보다 큰 경우 모든 파일 메타데이터를 파일 시스템으로 가져올 수 있어야 합니다. 하지만 파일 시스템의 남은 스토리지 공간에 맞는 만큼의 실제 파일 데이터만 로드할 수 있습니다. 파일 시스템에 스토리지가 더 이상 남아 있지 않을 때 파일 데이터에 액세스하려고 하면 오류가 발생합니다. 이 경우 필요에 따라 스토리지 용량을 늘릴 수 있습니다. 자세한 내용은 [스토리지 용량 관리](managing-storage-capacity.md) 단원을 참조하십시오.
## 검증 단계
아래 나열된 bash 스크립트를 실행하여 아카이브(릴리스) 상태의 파일 또는 객체 수를 검색할 수 있습니다.
특히 파일 수가 많은 파일 시스템에서 이 스크립트의 성능을 개선하기 위해 CPU 스레드 수가 `/proc/cpuproc` 파일을 기반으로 자동으로 결정됩니다. 즉, 더 많은 vCPU 수의 Amazon EC2 인스턴스로 성능이 더 빨라집니다.
1. bash 스크립트를 설정합니다.
```
#!/bin/bash
# Check if a directory argument is provided
if [ $# -ne 1 ]; then
echo "Usage: $0 /path/to/lustre/mount"
exit 1
fi
# Set the root directory from the argument
ROOT_DIR="$1"
# Check if the provided directory exists
if [ ! -d "$ROOT_DIR" ]; then
echo "Error: Directory $ROOT_DIR does not exist."
exit 1
fi
# Automatically detect number of CPUs and set threads
if command -v nproc &> /dev/null; then
THREADS=$(nproc)
elif [ -f /proc/cpuinfo ]; then
THREADS=$(grep -c ^processor /proc/cpuinfo)
else
echo "Unable to determine number of CPUs. Defaulting to 1 thread."
THREADS=1
fi
# Output file
OUTPUT_FILE="released_objects_$(date +%Y%m%d_%H%M%S).txt"
echo "Searching in $ROOT_DIR for all released objects using $THREADS threads"
echo "This may take a while depending on the size of the filesystem..."
# Find all released files in the specified lustre directory using parallel
# If you get false positives for file names/paths that include the word 'released',
# you can grep 'released exists archived' instead of just 'released'
time sudo lfs find "$ROOT_DIR" -type f | \
parallel --will-cite -j "$THREADS" -n 1000 "sudo lfs hsm_state {} | grep released" > "$OUTPUT_FILE"
echo "Search complete. Released objects are listed in $OUTPUT_FILE"
echo "Total number of released objects: $(wc -l <"$OUTPUT_FILE")"
```
1. 다음과 같이 스크립트 실행 파일을 만듭니다.
```
$ chmod +x find_lustre_released_files.sh
```
1. 다음 예제와 같이 스크립트를 실행합니다.
```
$ ./find_lustre_released_files.sh /fsxl/sample
Searching in /fsxl/sample for all released objects using 16 threads
This may take a while depending on the size of the filesystem...
real 0m9.906s
user 0m1.502s
sys 0m5.653s
Search complete. Released objects are listed in released_objects_20241121_184537.txt
Total number of released objects: 30000
```
릴리스된 객체가 있는 경우 다음 예제와 같이 원하는 디렉터리에서 일괄 복원을 수행하여 파일을 S3에서 FSx for Lustre로 가져옵니다.
```
$ DIR=/path/to/lustre/mount
$ nohup find $DIR -type f -print0 | xargs -0 -n 1 -P 8 sudo lfs hsm_restore &
```
파일이 수백만 개가 있는 경우 `hsm_restore`에 시간이 다소 걸립니다.