翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# データリポジトリからの変更のインポート
データおよび POSIX メタデータを含むメタデータの変更を、リンクされたデータリポジトリから Amazon FSx ファイルシステムにエクスポートできます。関連する POSIX メタデータには、所有権、許可、およびタイムスタンプが含まれます。
変更をファイルシステムにインポートするには、次のいずれかの方法を使用します。
+ リンクされたデータリポジトリに新規ファイル、変更されたファイル、または削除されたファイルを自動的にエクスポートできるようにファイルシステムを設定します。詳細については、「[S3 バケットから更新を自動的にインポートする](autoimport-data-repo-dra.md)」を参照してください。
+ データリポジトリの関連付けを作成する際に、メタデータをインポートするためのオプションを選択します。これにより、データリポジトリの関連付けを作成した直後に、データリポジトリのインポートタスクが開始されます。
+ オンデマンドのデータリポジトリのインポートタスクを使用します。詳細については、「[データリポジトリのタスクを使用して変更をインポートする](import-data-repo-task-dra.md)」を参照してください。
自動インポートとデータリポジトリのインポートタスクは同時に実行できます。
データリポジトリの関連付けで自動インポートを有効にすると、S3 でオブジェクトが作成、変更、または削除されたときに、ファイルシステムによってファイルメタデータが自動的に更新されます。データリポジトリの関連付けの作成時にメタデータをインポートするオプションを選択すると、データリポジトリ内の全オブジェクトのメタデータがファイルシステムによってインポートされます。データリポジトリのインポートタスクを使用してインポートする場合、前回のインポート以降に作成または変更されたオブジェクトのメタデータのみがファイルシステムによってインポートされます。
FSx for Lustre は、アプリケーションがファイルシステム内のファイルに最初にアクセスする際に、データリポジトリからファイルの内容を自動的にコピーしてファイルシステムにロードします。このデータの移動は FSx for Lustre によって管理されており、アプリケーションに対して透過的に行われます。その後に行われるファイルの読み取りは、ミリ秒未満のレイテンシーでファイルシステムから直接提供されます。
ファイルシステム全体またはファイルシステム内のディレクトリをプリロードすることもできます。詳細については、「[ファイルシステムへのファイルのプリロード](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 Flexible Retrieval オブジェクトまたは S3 Glacier Deep Archive オブジェクトのメタデータをインポートできます (つまり、正しいメタデータを使用して FSx for Lustre ファイルシステムで inode が作成されます)。ただし、ファイルシステムからこのデータを読み取るには、始めに S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive オブジェクトを復元する必要があります。S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive ストレージクラスの Amazon S3 オブジェクトから FSx for Lustre へのファイルデータの直接インポートはサポートされていません。
# S3 バケットから更新を自動的にインポートする
FSx for Lustre は、オブジェクトが S3 バケットに追加、変更されたとき、または S3 バケットから削除されたときに、ファイルシステムのメタデータを自動的に更新するように設定できます。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 データリポジトリにオブジェクトが追加、変更されたとき、または S3 データリポジトリから削除されたときに、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` 用などのバケットレベルのアクセス許可がない場合です。この場合、データリポジトリのライフサイクルの状態が **[Misconfigured]** (設定ミス) になります。詳細については、「[データリポジトリの関連付けのライフサイクル状態](dra-lifecycles.md)」を参照してください。
+ リンクされた S3 バケットの `FSx` イベント通知設定が削除または変更された場合。この場合、データリポジトリのライフサイクルの状態が **[Misconfigured]** (設定ミス) になります。詳細については、「[データリポジトリの関連付けのライフサイクル状態](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)」を参照してください。
メタデータの変更のインポートの遅延が (`AgeOfOldestQueuedMessage` メトリクスを使用して測定される) 14 日を超えるた場合、自動インポートによって処理されていない S3 バケット内の変更はファイルシステムにインポートされません。さらに、データリポジトリの関連付けのライフサイクルが **MISCONFIGURED** とマークされ、自動インポートが停止します。自動エクスポートを有効にしている場合、自動エクスポートは引き続き FSx for Lustre ファイルシステムの変更をモニタリングします。ただし、追加の変更は FSx for Lustre ファイルシステムから S3 に同期されません。
データリポジトリの関連付けを **MISCONFIGRED** のライフサイクル状態から **AVAILABLE** のライフサイクル状態に戻すには、データリポジトリの関連付けを更新する必要があります。データリポジトリの関連付けは、[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` だけです。
データリポジトリの関連付けのライフサイクル状態が **AVAILABLE** に変わると、自動インポート (および有効化されている場合は自動エクスポート) が再起動されます。再起動すると、自動エクスポートは S3 に対するファイルシステムの変更の同期を再開します。インポートされていない FSx for Lustre ファイルシステムまたはデータリポジトリの関連付けが構成が間違っていた状態の FSx for Lustre ファイルシステムに対して S3 内の新規オブジェクトと変更されたオブジェクトのメタデータを同期させるには、[データリポジトリのインポートタスク](import-data-repo-task-dra.md)を実行します。インポートデータリポジトリタスクでは、S3 バケット内の削除は FSx for Lustre ファイルシステムと同期されません。S3 をファイルシステムと (削除を含めて) 完全に同期する場合は、ファイルシステムを再作成する必要があります。
メタデータの変更のインポートの遅延が 14 日を超えないようにするために、`AgeOfOldestQueuedMessage` メトリクスにアラームを設定し、`AgeOfOldestQueuedMessage` メトリクスがアラームしきい値を超えた場合に S3 バケット内のアクティビティを減らすことをお勧めします。最大数の変更を S3 から継続的に送信する単一のシャードで S3 バケットに接続されている FSx for Lustre ファイルシステムで自動インポートのみを実行している場合、自動インポートでは 14 日以内に 7 時間分の S3 変更のバックログを処理できます。
さらに、自動インポートが 14 日で処理できるよりも多くの変更が 1 つの S3 アクションで生成されることがあります。このような種類のアクションの例には、S3 への AWS Snowball アップロードや大規模な削除などがあります。S3 バケットで行った大規模な変更を FSx for Lustre ファイルシステムと同期させる場合、自動インポートの変更が 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 つのデータリポジトリタスクを使用できることに注意してください。
## メタデータの変更をインポートするには (コンソール)
1. Amazon FSx コンソール ([https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/)) を開きます。
1. ナビゲーションペインで **[ファイルシステム]** をクリックし、Lustre ファイルシステムを選択します。
1. **[Data repository]** (データリポジトリ) タブを選択します。
1. **[Data repository associations]** (データリポジトリ関連) ペインで、インポートタスクを作成する対象のデータリポジトリの関連付けを選択します。
1. **[Actions]** (アクション) メニューから、**[Import Task]** (タスクのインポート) を選択します。ファイルシステムがデータリポジトリにリンクされていない場合、この選択は利用できません。**[Create import data repository task]** (データリポジトリのインポートタスクの作成) ページが表示されます。
1. (オプション) **[Data repository paths to import]** (インポートするデータリポジトリパス) のディレクトリまたはファイルへのパスを指定することで、リンクされた S3 バケットからインポートするディレクトリまたはファイルを最大 32 個指定します。
**注記**
指定したパスが有効でない場合、タスクは失敗します。
1. (オプション) **[Completion report]** (完了レポート) 直下の **[Enable]** (有効化) をクリックして、タスクの完了後にタスク完了レポートを生成します。*[task completion report]* (タスク完了レポート) に、**[Report scope]** (レポートスコープ) に示されている範囲を満たすタスクによって処理されるファイルの詳細が表示されます。Amazon FSx がレポートを配信する場所を指定するには、**[Report path]** (レポートパス) にリンクされた S3 データリポジトリの相対パスを入力します。
1. **[Create]** (作成) を選択します。
**[File systems]** (ファイルシステム) ページの上部にある通知には、先ほど作成したタスクが表示されます。
タスクのステータスと詳細を表示するには、ファイルシステム用の **[Data Repository]** (データリポジトリ) タブの **[Data Repository Tasks]** (データリポジトリタスク) ペインを下にスクロールします。デフォルトのソート順では、最新のタスクがリストの最上部に表示されます。
このページからタスクサマリーを表示するには、先ほど作成したタスクの **[Task ID]** (タスク ID) を選択します。**[Summary]** (概要) タスクのページが表示されます。
## メタデータの変更をインポートするには (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 は、ファイルが最初にアクセスされたときに Simple Storage Service (Amazon S3) データリポジトリからデータをコピーします。このアプローチにより、ファイルへの最初の読み取りまたは書き込みにはわずかなレイテンシーが発生します。アプリケーションがこのレイテンシーの影響を受けやすく、アプリケーションがアクセスする必要があるファイルやディレクトリがわかっている場合は、オプションで、個々のファイルまたはディレクトリのコンテンツをプリロードできます。以下のように `hsm_restore` コマンドを実行します。
`hsm_action` コマンド (`lfs` ユーザーユーティリティで発行される) を使用して、ファイルの内容がファイルシステムへのロードが完了したことを確認します。`NOOP` の戻り値は、ファイルが正常にロードされたことを示します。ファイルシステムがマウントされたコンピューティングインスタンスから次のコマンドを実行します。*パス / 宛先 / ファイル* ファイルシステムにプリロードするファイルのパスを使用して置き換えます。
```
sudo lfs hsm_restore path/to/file
sudo lfs hsm_action path/to/file
```
次のコマンドを使用して、ファイルシステム全体またはファイルシステム内のディレクトリ全体をプリロードできます。(末尾にアンパサンドをつけると、コマンドはバックグラウンドプロセスとして実行されます。) 複数のファイルのプリロードを同時にリクエストすると、Amazon FSx はファイルを Simple Storage Service (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` には時間がかかることに留意してください。