すべての LTO テープドライブには、最大ネイティブ転送速度が記載されたデータシートが付属しています。これらの数値は実在しますが、示しているのは現実的な運用速度ではなく理論上の上限です。実際には、どの環境でもこの値には届きません。違いは「どれだけ届かないか」だけです。
この記事では、その理由を説明します。
現在入手可能なLTO世代（2025年/2026年時点）
現在、市場には 3 世代の LTO が流通しています。 LTO-7 は技術的にはまだ入手可能ですが、すでに寿命の終わりに近づいています。
| 世代 | ネイティブスピード | 圧縮速度（2.5:1） | ネイティブキャパシティ | 下位互換性 |
|---|---|---|---|---|
| LTO-8 | 360 MB/秒 | 900 MB/秒 | 12TB | LTO-7（読み書き可能） |
| LTO-9 | 400MB/秒 | 1,000 MB/秒 | 18TB | LTO-8（読み書き可能） |
| LTO-10 | 400MB/秒 | 1,000～1,200 MB/秒 | 30TB / 40TB | なし |
この記事の例では LTO-9 を基準として説明しています。 同じ原則はすべての世代に当てはまりますが、ドライブが高速になるほど、各要因がもたらす絶対的な悪影響は大きくなります。 LTO-8 システムで 50 MB/s のボトルネックが発生する場合、LTO-9 でも同じく 50 MB/s の損失になります。しかし、LTO-9 の理論上の上限はより高いため、その 50 MB/s が占める割合はより大きくなるというわけです。
どの速度を基準としているのかについての注記
この記事におけるすべての分析は、LTO-9のネイティブ（非圧縮）転送速度である400MB/秒のみに基づいています。圧縮後の1,000MB/秒という数値は、2つの理由から意図的に除外されています。
まず、メディアやアーカイブ環境では、データは既に圧縮されています。H.264、H.265、JPEG、カメラRAW形式、ZIPアーカイブ、暗号化ファイルなどは、テープドライブのハードウェアコンプレッサーで処理しても、追加の圧縮はほとんど、あるいは全く行われません。1,000 MB/秒という数値を生み出す2.5:1の比率は、このようなコンテンツでは実現しません。ネイティブレートこそが、現実と一致する唯一の数値です。
第二に、圧縮率を含めると、あらゆるマイナス要因が相対的に悪化して見え、改善されることはありません。理論上の上限が400MB/sから1,000MB/sに引き上げられたとしても、特定の環境における実際のスループットが180MB/sであれば、仕様と現実のギャップは55%から82%に拡大します。パフォーマンス分析において圧縮速度を引用することは、不足分をより劇的に見せるか、あるいは180MB/sが実際のワークロードでは決して到達しない数値に「近い」ように見せかけることで、不足分を曖昧にするだけです。
ネイティブレートは、正直な基準値です。以下で説明するすべての偏差は、この基準値と比較して測定されます。
理論上の最大値は、あくまでも”理論上”の最大値です。
LTO-9 の定格 400 MB/s は、理想的な実験室環境で測定された値です。 具体的には、巨大な単一ファイル、完全に圧縮可能なデータ、損失のないデータ供給、フルハイトドライブ、そして途切れず必要なスループットを維持できるハードウェアといった条件が揃っている状態です。 しかし、これらの条件がすべて同時に満たされる本番環境は存在しません。
理論上は 400 MB/s が可能であるものの、現実的な条件下での LTO-9 の実際の書き込み速度は 300〜370 MB/s 程度になることが多く、さらにネットワーク遅延やサーバー負荷によって速度は低下します。
仕様と現実の間にあるこの差は欠陥ではありません。 以下で説明する要因が累積的にスループットを低下させているためであり、どの要因もスループットを増加させて定格値を超えることはありません。
1. データソースが追いつかない
LTO-9ドライブは、データを受信する速度で書き込みを行います。データソース（ディスクアレイ、NAS、バックアップサーバーなど）が400MB/秒の速度でデータを継続的に送信できない場合、ドライブは速度を落としてデータソース側のボトルネックを調整します。データソース側の一般的なボトルネックとしては、IOPSが不十分な回転式HDDアレイ、NASシステムへの1GbEネットワーク接続（理論上の最大速度：125MB/秒）、バックアップサーバーのCPU飽和、多数の小さなファイルを処理する際のファイルシステムのオーバーヘッドなどが挙げられます。
バックアップソフトウェアの性能は、主に環境要因によって左右されます。システムがLTO-9ドライブの400MB/秒という速度から大きく逸脱している場合、ボトルネックは通常、ドライブ自体ではなくホスト環境にあります。
2. 小さなファイル: ソースにおけるファイルシステムのオーバーヘッド
テープは、大容量で連続したデータを書き込むのに最適化されたシーケンシャルメディアです。P5のネイティブバックアップフォーマットでは、テープドライブは常に連続したデータストリームを受信するため、ファイル数はテープのスループットに直接影響しません。しかし、ソース側ではオーバーヘッドが発生します。すべてのファイルに対して、ソースファイルシステム上でオープン、統計情報取得、読み取りの呼び出しが必要となるためです。数十万個の小さなファイルを含むディレクトリの場合、このメタデータ処理が積み重なり、P5がドライブに供給できるデータレートが著しく低下します。
したがって、50万個の小さなプロジェクトファイル、サムネイル、またはオーディオステムのワークロードは、たとえ総データ量が少数の大きなMXFファイルと同じであっても、テープドライブが飽和する前に、ソースファイルシステムとバックアップサーバーのCPUを飽和させてしまうでしょう。
この違いはLTFSにも当てはまりますが、LTFSではファイル数の問題がさらに複雑になります。LTFSはファイルごとのマーカーとブロックアライメントのパディングをテープに直接書き込むため、ソース側だけでなくテープドライブ自体にも影響が及ぶのです。次のセクションでは、この点について詳しく説明します。
3. LTFSは独自のオーバーヘッド層を追加する
LTFS（リニアテープファイルシステム）は、テープカートリッジをファイルシステムのようにフォーマットするため、専用ソフトウェアなしで互換性のあるあらゆるオペレーティングシステムにマウントできます。ただし、この移植性にはスループットの低下という代償が伴います。専用のバックアップソフトウェアを使用してネイティブテープフォーマットで書き込む場合には、このような低下は発生しません。
インデックス書き込みはデータストリームを中断する
すべてのLTFSボリュームは、すべてのファイルとメタデータのXMLベースのインデックスを保持します。このインデックスは、アンマウント時にテープに書き込まれる必要があり、セッション中に一定間隔で同期するように構成できます。同期のたびに、ドライブはインデックスパーティションにシークし、更新されたインデックスを書き込み、その後、書き込みを再開するために元の位置に戻ります。
高密度にデータが蓄積されたLTO-9テープ（18TB、多数のファイル）では、インデックス自体が大きくなり、書き込みのたびに測定可能な遅延が発生します。LTFSフォーマット仕様2.5（ISO/IEC 20919:2021）では、フル同期間の変更のみを記録する増分インデックス方式が導入され、このオーバーヘッドは削減されますが、完全には解消されません。アンマウント時のフルインデックス書き込みは、依然として必須です。
ファイルマーカーとブロックの配置
LTFSの大きな欠点は、追加のファイルマーカー、ブロック境界へのファイルの強制的なアライメント、およびインデックスの強制的な更新によって、読み書き性能が低下することです。これらの要素により、特に小さなファイルの場合、テープ容量の利用効率が非常に悪くなります。
小さなファイルは問題をさらに悪化させる
LTFSは、小さなファイルが主体となるワークロードには適していません。読み出し時のシーク時間はファイルごとに最大1分にも達するため、アクセス時間が非常に長くなります。標準的な推奨事項は、個々の小さなファイルを直接書き込むのではなく、まずtarアーカイブを作成し、それをLTFS経由でLTO-9テープに書き込むことです。
LTFSがそもそも正しい選択肢である場合
LTFSは、特定のユースケースに適したフォーマットです。例えば、大容量ファイルのシーケンシャルワークフロー（ビデオオリジナル、RAW画像セットなど）を一度書き込んで完全なセットとして読み戻す場合や、独自のソフトウェアを共有することなく異なるシステム間でテープを読み取り可能にする必要があるデータ交換シナリオなどが挙げられます。これらのケースでは、オーバーヘッドは許容範囲内であり、移植性のメリットは十分にあります。それ以外のすべてのケースでは、ネイティブのバックアップフォーマットの方がスループットが向上します。
もう一つ注意すべき点があります。LTFSでは、テープを直接マウントしたファイルシステムとして使用することも可能です。Finderやエクスプローラーを使って個々のファイルを閲覧したり開いたりできます。このアクセスパターンでは、ファイルごとに10秒から100秒かかるLTOのシーク時間が支配的な要因となり、前述のスループットに関する考慮事項は、レイテンシーの問題に比べるとほとんど意味をなさなくなります。この使用例では、全く異なる一連のパフォーマンス上の問題が発生し、この記事の範囲を超えてしまいます。
4. パフォーマンス問題の診断：構造化されたアプローチ
理論的な要因を知ることは一つの手段ですが、特定の環境における特定のパフォーマンス低下の原因がそれらの要因のうちどれであるかを判断するには、体系的なアプローチが必要となります。
シナリオ
典型的な構成を考えてみましょう。P5 バックアップ ジョブが 10 GbE ネットワーク経由で NAS ボリュームからデータを読み込み、LTO-9 ドライブに書き込みます。10 GbE インターフェイスの理論上の最大速度は 1,250 MB/s ですが、適切に構成された NAS からの大規模なシーケンシャル読み取りにおける実際の TCP スループットは、現実的には 800～900 MB/s 程度であり、LTO-9 が必要とする速度をはるかに上回ります。ドライブのネイティブ速度が 400 MB/s であることを考慮すると、この構成における現実的な期待値は、一般的なソフトウェアのオーバーヘッドと速度マッチングを考慮して、約250 MB/sとなります。
実際のジョブスループットが120MB/秒しかない場合、何かがおかしい。問題は何がおかしいのかということです。
推測が非効率的な理由
本番環境では、同時に多くの変数が動作しているため、観察だけで原因を特定することは困難です。ネットワーク、NAS、HBA、OSスケジューラ、バックアップソフトウェア、ファイル構造、テープ、ドライブファームウェアなど、これらのいずれもがボトルネックとなる可能性があり、複数の要因が同時に影響を及ぼしている場合もあります。設定を1つ変更して本番ジョブ全体を再実行すると時間がかかり、結果には他の変数によるノイズも含まれてしまいます。
正しいアプローチは、管理されたテスト環境を構築し、最適な条件下で基準値を設定し、その後、変数を一つずつ導入していくことです。
テストベッド：可能な限り最良のベースラインから始める
初期テストベッドの目標は、可能な限り多くの潜在的なボトルネックを排除し、この特定のハードウェア上でドライブとソフトウェアが実際にどれだけの性能を発揮できるかを明確に示す基準点を確立することです。最小限の有効な構成は次のとおりです。
- 少なくとも8GBのRAMと2コアを搭載した最新のサーバーハードウェアを使用し、テスト中は他のアプリケーションを実行しないこと。
- NVMeにOSをインストールする
- P5は同じNVMeにインストールする
- テストデータは、別のNVMeボリューム（OSドライブではない）に保存される
- 復元先として専用のNVMeボリュームを使用する（OSとソースデータの両方から分離）
- 単一のLTOドライブが専用のSAS HBAに直接接続されています。エキスパンダーも共有バスも無し
- 1TBのテストデータ（大容量メディアファイルまたは既に圧縮済みのフォーマットで構成）（実際のワークロードを代表するもの）
- テストデータの完全バックアップ用にバックアッププランが構成されたP5バックアッププール。バックアッププラン（アーカイブプランとは異なり）は、チェックサム生成やプロキシ作成などの追加のオーバーヘッドを除外します。P5 BackupはLTFSをサポートしていないため、ネイティブテープフォーマットが暗黙的に使用され、別途構成する必要はありません。
これにより、NASとネットワークが完全に削除されます。バックアップのデータパスは、NVMe → P5 → SAS HBA → LTO-9ドライブです。復元の場合、LTO-9ドライブ → SAS HBA → P5 → NVMeとなります。この段階で期待される約350～370 MB/sから不足している場合は、HBA構成、ドライバ、OSスケジューリング、P5設定、またはドライブ自体にローカルな問題があることを示しています。
正しく測定する
P5のジョブモニターにはバックアップ中のスループットインジケーターが表示されますが、最終的な測定値はジョブ全体の実行時間です。データ量を、ジョブ準備フェーズ（テープのマウント、位置決め、初期化）を除いた正味バックアップ時間で割ります。ジョブ準備フェーズは、テープの現在位置によって30～120秒かかる場合があります。
1TBのテストデータを350MB/秒でバックアップした場合、準備時間を除くバックアップにかかる時間は約48分です。一方、120MB/秒では、同じ作業に約2時間20分かかります。その差は歴然としています。
変数の逐次導入
ベースラインが確立されたら、変数を一つずつ導入し、変更ごとにバックアップと完全復元を再実行して結果を記録します。
- NVMeソースを本番環境のディスクストレージ（ローカルHDD RAID、SANなど）に置き換えることで、ストレージの読み取りI/Oを要因として分離できます。
- NVMe リストアターゲットを本番環境のリストア先に置き換えることで、ストレージ書き込み I/O を要因として分離できます。書き込みパフォーマンスは、同じハードウェア上でも読み取りパフォーマンスよりも大幅に低い場合が多いため、これはソースとは別にテストされます。
- ネットワークを追加する：ネットワークサーバーまたはNASにP5をクライアントとしてインストールし、10GbE経由でそこからテストデータを読み取ります。これにより、ネットワーク読み取りスループットが分離されます。ソースシステム上で直接実行されるP5エージェントはNFS/SMBプロトコルのオーバーヘッドを回避し、可能な限りクリーンなネットワーク読み取り結果を提供します。
- オプション — NFS/SMB を追加変数としてテストします。P5 クライアントではなく、マウントされたネットワーク共有経由で同じデータをバックアップします。ステップ 3 と比較してスループットが低下した場合は、ファイル共有プロトコルのオーバーヘッドに直接起因します。
- ネットワーク経由で本番環境のNASに復元する– ネットワーク書き込みスループットとNAS書き込みパフォーマンスを読み取りパフォーマンスとは別に分離します
- 本番環境のNASパスに切り替える（ストレージゲートウェイや別のスイッチなど、パスが異なる場合）—ネットワークトポロジーを分離する
- P5をテストサーバーではなく本番サーバーで実行すると、サーバーのハードウェアとOS構成が分離されます。
- 他のプロセスがアクティブな状態で稼働中に実行することで、リソースの競合を分離します。
各ステップにおいて、スループットが前のステップに比べて著しく低下した場合、先ほど導入した変数が原因の一つであると考えられます。バックアップとリストアを各段階で個別にテストすることが重要です。書き込みのみに影響するボトルネックは、バックアップ時の測定では検出されず、リストア時にのみ顕在化する可能性があります。
復元がバックアップよりも遅いことが多い理由、そしてその原因究明方法
よくある顧客からの指摘として、バックアップは期待通りの速度で実行されるものの、リストアは著しく遅いというものがあります。その原因はほぼ常にリストア経路の書き込み側にあり、テープ自体に問題はありません。
バックアップ中、P5はファイルシステムから読み込み、シーケンシャルストリームをテープに書き込みます。テープがボトルネック候補です。リストア中、P5はテープからシーケンシャルに読み込みますが（これは引き続き正常に動作します）、ファイルシステムに書き込みます。そのファイルシステムへの書き込みパスには、独自の制約があります。
- IOPS制限ストレージ：回転式ディスクを搭載したNASは、シーケンシャル読み取り帯域幅は十分でも、P5がリストア中に多数の個別ファイルを書き込む際にIOPSの上限に達してしまう場合があります。テープドライブは、書き込み先の低速なデータ量に合わせて速度調整を行うことで、処理速度を制限します。
- NASのパフォーマンスは非対称です。多くのNASシステムやRAID構成では、書き込みよりも読み込みの方がはるかに高速です。例えば、RAID-6では書き込み時にパフォーマンスの低下が見られますが、読み込み時にはそのような低下は見られません。
- コールドリストアターゲット：バックアップ元は、通常の使用を通じて蓄積されたファイルシステムキャッシュの恩恵を受けることが多いです。一方、新規リストアターゲット（空のディレクトリ、新しくプロビジョニングされたボリュームなど）には、そのようなキャッシュの利点はありません。
- ソースとは異なる保存先：元のバックアップ元とは異なるサーバー、共有、またはボリュームに復元すると、同等のパフォーマンスが得られるという前提がなくなります。
- 多重化バックアップ： P5は、複数のバックアップジョブを同じテープに同時に書き込む（多重化）機能をサポートしています。これにより、複数のデータストリームを単一の連続したテープストリームに結合することで、書き込みスループットが向上します。ただし、個々のジョブのデータブロックは、テープ上で連続ではなくインターリーブされます。リストア時には、ドライブは異なるジョブに属するブロック間で位置を調整する必要があるため、同じデータの非多重化バックアップと比較して、リストアスループットが大幅に低下します。これは設定エラーではなく、リストア時間が重要な要素となる場合に考慮すべき、多重化書き込みに内在するトレードオフです。
テスト環境では、ローカルのNVMeボリュームに復元することで、これらの変数をすべて同時に排除できます。バックアップと復元の両方でNVMeとの間で約350MB/秒の速度で実行できるにもかかわらず、本番環境のNASへの復元が著しく遅い場合、テープ、ドライブ、またはP5ではなく、NASの書き込みパフォーマンスがボトルネックであることが確認されます。
各段階で注目すべき点
NVMeベースラインにおいて、バックアップとリストアの両方でスループットが350MB/sを大幅に下回る場合は、ローカルなボトルネックが考えられます。SAS HBAが他のデバイスと共有されていないことを確認し、HBAドライバのバージョンをチェックし、ドライブのファームウェアが最新であることを確認してください。バックアップは高速だがNVMeへのリストアが遅い場合は、P5のリストア構成の問題、または書き込みパフォーマンスに影響を与えるドライバの問題が考えられます。
NVMeを回転式ディスクに置き換える場合、パフォーマンスの低下は想定内で正常です。問題は、それがディスクアレイの測定されたシーケンシャル読み取り/書き込み速度を下回るかどうかです。これは、ddまたはを使用して個別に検証できますfio。ディスクの性能とP5のスループットの間にギャップがある場合は、ファイルシステムまたはI/Oスケジューラの問題、あるいは予想よりも多くの小さなファイルが存在することを示しています。
10 GbE 経由で NAS を追加する場合は、P5 ジョブを実行する前に、NAS の読み取りおよび書き込みパフォーマンスを個別に測定してください。大きなファイルに対して、などのツールrsyncや簡単なcpテストを実行すると、信頼できる基準点が得られます。P5 バックアップが NAS の読み取り速度と一致するものの、リストアが NAS の書き込み速度を大幅に下回る場合は、テープではなく NAS の書き込みパスがボトルネックとなっています。
ファイル構造の問題、そしてそれがP5に異なる影響を与える理由
時として意外な結果が一つあります。1TBの大容量メディアファイルを使ったテスト環境では良好なパフォーマンスを発揮するが、名目上は同じサイズの実際のプロジェクトディレクトリの運用バックアップには、明らかに時間がかかるのです。
ここで実際に何が起こっているのかを明確に区別することが重要です。P5は、バックアップに含まれる個々のファイルの数に関係なく、テープに連続したストリームとして書き込みます。テープのスループット自体はファイル数によって低下しません。P5のネイティブフォーマットは、LTFSのようにファイルごとのマーカーやアライメントパディングを書き込まないためです。ドライブはストリームとして認識し、それに応じて書き込みを行います。
ファイル数の増加に伴って増大するのは、そのストリームの両側におけるオーバーヘッドです。
- ソース側でのファイルシステム操作：すべてのファイルに対して、オープン、ステータス取得、読み取りの呼び出しが必要です。50万個の小さなファイルの場合、このメタデータ走査は、テープ上ではなく、読み取り対象のNASまたはディスクボリューム、そしてバックアップサーバーのCPU上で負荷が増大します。
- P5における最終インデックス作成：バックアップが完了すると、P5はバックアップされたファイルリストでカタログを更新します。ファイル数が非常に多いディレクトリの場合、このインデックス作成ステップによって全体のジョブ実行時間が長くなる可能性があります。この時間は、実際のテープ書き込みフェーズとは別個のものです。
バックアップのパフォーマンスをジョブ全体の実行時間で測定する場合、これらの要因によって、ファイル数の多いジョブが実際のテープスループットよりも遅く見えることがあります。このようなずれが生じた場合は、ジョブログでテープ書き込みフェーズとインデックス作成フェーズを分離することで、時間の流れをより明確に把握できます。
まとめ
LTO-9のデータシートには、ネイティブ速度が400MB/sと記載されています。以下の各要素は、速度を一方向にのみ変化させます。
| 要素 | スループットが低下する理由 |
|---|---|
| 低速なソースI/O/ネットワーク | ハードの限界 ― LTO-9ドライブは受信データレートに合わせて速度を落とす |
| 多数の小さなファイル（ネイティブ形式） | ソースおよびP5インデックス作成におけるファイルシステムのオーバーヘッド – テープスループット自体には影響なし |
| LTFS: インデックス書き込み | データストリームの定期的な中断およびマウント解除時の中断 |
| LTFS: ファイルマーカー/アライメント | ファイルごとのオーバーヘッド — 小規模ファイルのワークロードでは深刻 |
| LTFS: シークタイム | シーク1回あたり10～100秒。ランダムアクセスは設計上低速です。 |
| — |
最低性能を下回った場合、何が起こるか：スピードマッチングとバックヒッチ
データソースの速度が遅い場合でも、バックアップがすぐに停止するわけではありません。最新のLTOドライブは、入力データレートに合わせてテープ速度を動的に調整することで対応します。これは、速度マッチングまたはデータレートマッチングと呼ばれる仕組みです。これにより、旧世代のドライブに比べてバックヒッチイベントの発生頻度は減少しますが、完全に解消されるわけではありません。
速度マッチングには下限値があります。IBMの公式ドライブ仕様によると、以下のようになります。
| ドライブ | 速度マッチング範囲（ネイティブ） |
|---|---|
| LTO-8 | 112～360 MB/秒 |
| LTO-9 | 180～400 MB/秒 |
| LTO-10 | 180～400 MB/秒（公式発表なし。LTO-9と同じネイティブ速度） |
入力データレートが最小しきい値を下回ると、ドライブはテープの速度をさらに落とすことで補正することができなくなります。テープは停止し、ドライブはデータバッファが再び満たされるまで待機した後、テープを少しだけ元の位置に戻して書き込みを再開します。これがバックヒッチ（シューシャイニングとも呼ばれる）です。データは正しく書き込まれますが、スループットは急激に低下します。
具体的な例を挙げると、1 GbE ネットワーク接続の実際のスループットは 100～110 MB/s 程度で、LTO-9 の最小要件である 180 MB/s を下回っています。1 GbE 経由でソースからデータを読み取る LTO-9 インストール環境では、他の設定がどれほど適切であっても、常にバックヒッチが発生します。
注：ストリーミング速度が最低値を下回っても、直ちに損傷やデータ損失が発生するわけではありません。しかし、慢性的に非効率的な動作モードになります。具体的には、停止と再配置の繰り返しによるヘッドアセンブリとテープ搬送機構の機械的摩耗の増加、ドライブの再配置と再調整に伴うエラー訂正処理の増加、そしてユーザーデータではなく再配置処理にテープが消費されるためメディア効率の低下などが挙げられます。このような状態でシステムが継続的に稼働すると、個々のバックアップが正常に完了したとしても、ドライブとメディアの寿命は徐々に短くなります。
世代が進むにつれて最小しきい値は上昇します。ドライブの速度が速くなるほど、最低しきい値は高くなり、ホスト環境に対する要求も厳しくなります。
本記事の範囲外の要因
上記で述べた要因には共通点があります。それは、いずれも運用上の問題であり、ユーザーが構築・維持する環境によって引き起こされたり、影響を受けたりするということです。NASの動作が遅い、ネットワークが混雑している、ファイル数が多い、LTFSプールを使用しているなど、これらは稼働中のシステムに存在する状況であり、測定、分離、対処が可能です。
以下の要因も原理的にはLTOスループットに影響を与えますが、本稿の範囲外となります。
ドライブの形状（フルハイト vs. ハーフハイト）：フルハイトドライブは、同世代のドライブの中でより高いピーク速度を実現します。これはハードウェア調達時の決定事項であり、稼働中のシステムで変更されるものではありません。環境が提供できる性能の限界に近い状態で動作させる場合にのみ、この点が重要になります。
LTO世代（例：LTO-10とLTO-9）： LTO-10はLTO-9に比べて速度面でのネイティブな向上はありません。購入時の判断材料としては重要ですが、既存のシステムへの導入においては考慮すべき要素ではありません。
LTO-9メディアの最適化：新品で書き込みのないLTO-9カートリッジに対して、一度だけ特性評価を行う必要があります。これは新品テープへの最初の書き込みセッションのみに影響し、継続的なバックアップ性能には影響しません。
仕様はlto.orgおよびIBMのメーカー発表（2025年）に基づいています。
