4.21. OADP Data Mover
4.21.1. OADP Data Mover について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift API for Data Protection (OADP) には、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアに移動するために使用できる、ビルトイン Data Mover が含まれています。ビルトイン Data Mover を使用すると、クラスターの障害、誤削除、または破損が発生した場合に、リモートオブジェクトストアからステートフルアプリケーションを復元できます。スナップショットデータを読み取り、統合リポジトリーに書き込むためのアップローダーメカニズムとして Kopia を使用します。
OADP は、以下で CSI スナップショットをサポートします。
- Red Hat OpenShift Data Foundation
- Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のクラウドストレージプロバイダー
4.21.1.1. Data Mover のサポート リンクのコピーリンクがクリップボードにコピーされました!
OADP 1.3 でテクノロジープレビューとして導入された OADP 組み込みの Data Mover が、コンテナー化されたワークロードと仮想マシンのワークロードの両方で完全にサポートされるようになりました。
サポート対象
OADP 1.3 で作成した Data Mover バックアップは、OADP 1.3、1.4 以降を使用して復元できます。これはサポート対象です。
サポート対象外
Data Mover 機能を使用して OADP 1.1 または OADP 1.2 で作成したバックアップは、OADP 1.3 以降を使用して復元することはできません。したがって、これはサポート対象外です。
OADP 1.1 および OADP 1.2 はサポート対象外です。OADP 1.1 または OADP 1.2 の DataMover 機能はテクノロジープレビューであり、サポート対象ではありませんでした。OADP 1.1 または OADP 1.2 で作成した DataMover バックアップは、それ以降のバージョンの OADP では復元できません。
4.21.1.2. ビルトイン Data Mover の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ビルトイン Data Mover を有効にするには、CSI プラグインを組み込み、DataProtectionApplication カスタムリソース (CR) でノードエージェントを有効にする必要があります。ノードエージェントは、データ移動型モジュールをホストする Kubernetes デーモンセットです。これには、Data Mover のコントローラー、アップローダー、リポジトリーが含まれます。
DataProtectionApplication マニフェストの例
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
nodeAgent:
enable: true
uploaderType: kopia
velero:
defaultPlugins:
- openshift
- aws
- csi
defaultSnapshotMoveData: true
defaultVolumesToFSBackup:
featureFlags:
- EnableCSI
# ...
- 1
- ノードエージェントを有効にするフラグ。
- 2
- アップローダーの種類。使用できる値は、
resticまたはkopiaです。ビルトイン Data Mover は、uploaderTypeフィールドの値に関係なく、デフォルトのアップローダーメカニズムとして Kopia を使用します。 - 3
- デフォルトプラグインのリストに含まれる CSI プラグイン。
- 4
- OADP 1.3.1 以降では、
fs-backupをオプトアウトするボリュームにのみ Data Mover を使用する場合、trueに設定します。ボリュームにデフォルトで Data Mover を使用する場合はfalseに設定します。
4.21.1.3. ビルトイン Data Mover のコントローラーとカスタムリソース定義 (CRD) リンクのコピーリンクがクリップボードにコピーされました!
ビルトイン Data Mover 機能には、バックアップと復元を管理するための CRD として定義された 3 つの新しい API オブジェクトが導入されています。
-
DataDownload: ボリュームスナップショットのデータダウンロードを表します。CSI プラグインは、復元するボリュームごとに 1 つのDataDownloadオブジェクトを作成します。DataDownloadCR には、ターゲットボリューム、指定された Data Mover、現在のデータダウンロードの進行状況、指定されたバックアップリポジトリー、プロセス完了後の現在のデータダウンロードの結果に関する情報が含まれます。 -
DataUpload: ボリュームスナップショットのデータアップロードを表します。CSI プラグインは、CSI スナップショットごとに 1 つのDataUploadオブジェクトを作成します。DataUploadCR には、指定されたスナップショット、指定された Data Mover、指定されたバックアップリポジトリー、現在のデータアップロードの進行状況、およびプロセス完了後の現在のデータアップロードの結果に関する情報が含まれます。 -
BackupRepository: バックアップリポジトリーのライフサイクルを表し、管理します。OADP は、namespace の最初の CSI スナップショットバックアップまたは復元が要求されると、namespace ごとにバックアップリポジトリーを作成します。
4.21.1.4. 増分バックアップのサポートについて リンクのコピーリンクがクリップボードにコピーされました!
OADP は、コンテナー化されたワークロードと OpenShift Virtualization ワークロードの両方で、block および Filesystem の永続ボリュームの増分バックアップをサポートしています。次の表は、File System Backup (FSB)、Container Storage Interface (CSI)、および CSI Data Mover のサポート状況をまとめたものです。
| ボリュームモード | FSB - Restic | FSB - Kopia | CSI | CSI Data Mover |
|---|---|---|---|---|
| ファイルシステム | S [1]、I [2] | S [1]、I [2] | S [1] | S [1]、I [2] |
| ブロック | N [3] | N [3] | S [1] | S [1]、I [2] |
| ボリュームモード | FSB - Restic | FSB - Kopia | CSI | CSI Data Mover |
|---|---|---|---|---|
| ファイルシステム | N [3] | N [3] | S [1] | S [1]、I [2] |
| ブロック | N [3] | N [3] | S [1] | S [1]、I [2] |
- バックアップをサポート
- 増分バックアップをサポート
- サポート対象外
CSI Data Mover バックアップでは、uploaderType に関係なく Kopia が使用されます。
4.21.2. CSI スナップショットのバックアップおよび復元のデータ移動 リンクのコピーリンクがクリップボードにコピーされました!
OADP 1.3 Data Mover を使用して、永続ボリュームのバックアップと復元を実行できます。
4.21.2.1. CSI スナップショットを使用した永続ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OADP Data Mover を使用して、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。
前提条件
-
cluster-adminロールでクラスターにアクセスできる。 - OADP Operator がインストールされている。
-
CSI プラグインを組み込み、
DataProtectionApplicationカスタムリソース (CR) でノードエージェントを有効にしている。 - 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。
-
metadata.labels.velero.io/csi-volumesnapshot-class: "true"のキー/値ペアをVolumeSnapshotClassCR に追加している。
手順
次の例のように、
Backupオブジェクトの YAML ファイルを作成します。BackupCR の例kind: Backup apiVersion: velero.io/v1 metadata: name: backup namespace: openshift-adp spec: csiSnapshotTimeout: 10m0s defaultVolumesToFsBackup:1 includedNamespaces: - mysql-persistent itemOperationTimeout: 4h0m0s snapshotMoveData: true2 storageLocation: default ttl: 720h0m0s3 volumeSnapshotLocations: - dpa-sample-1 # ...- 1
fs-backupをオプトアウトするボリュームにのみ Data Mover を使用する場合、trueに設定します。ボリュームにデフォルトで Data Mover を使用する場合はfalseに設定します。- 2
- CSI スナップショットのリモートオブジェクトストレージへの移動を有効にするには、
trueに設定します。 - 3
ttlフィールドは、作成されたバックアップの保持期間とバックアップされたデータのバックアップを定義します。たとえば、バックアップツールとして Restic を使用している場合、バックアップの有効期限が切れるまで、バックアップされたデータ項目と永続ボリューム(PV)のデータコンテンツが保存されます。ただし、このデータを保存すると、ターゲットのバックアップの場所により多くの領域が使用されます。追加のストレージは、頻繁なバックアップで消費されます。バックアップは、他の期限切れでないバックアップがタイムアウトする前でも作成されます。
注記XFS ファイルシステムを使用してボリュームをフォーマットし、ボリュームの容量が 100% になっている場合は、
no space left on deviceエラーが発生してバックアップが失敗します。以下に例を示します。Error: relabel failed /var/lib/kubelet/pods/3ac..34/volumes/ \ kubernetes.io~csi/pvc-684..12c/mount: lsetxattr /var/lib/kubelet/ \ pods/3ac..34/volumes/kubernetes.io~csi/pvc-68..2c/mount/data-xfs-103: \ no space left on deviceこのシナリオでは、バックアップが正常に完了するように、ボリュームのサイズを変更するか、
ext4などの別のファイルシステムタイプを使用することを検討してください。マニフェストを適用します。
$ oc create -f backup.yamlスナップショットの作成が完了すると、
DataUploadCR が作成されます。
検証
DataUploadCR のstatus.phaseフィールドを監視して、スナップショットデータがリモートオブジェクトストアに正常に転送されたことを確認します。使用される値は、In Progress、Completed、Failed、またはCanceledです。オブジェクトストアは、DataProtectionApplicationCR のbackupLocationsスタンザで設定されます。次のコマンドを実行して、すべての
DataUploadオブジェクトのリストを取得します。$ oc get datauploads -A出力例
NAMESPACE NAME STATUS STARTED BYTES DONE TOTAL BYTES STORAGE LOCATION AGE NODE openshift-adp backup-test-1-sw76b Completed 9m47s 108104082 108104082 dpa-sample-1 9m47s ip-10-0-150-57.us-west-2.compute.internal openshift-adp mongo-block-7dtpf Completed 14m 1073741824 1073741824 dpa-sample-1 14m ip-10-0-150-57.us-west-2.compute.internal次のコマンドを実行して、
DataUploadオブジェクトのstatus.phaseフィールドの値を確認します。$ oc get datauploads <dataupload_name> -o yaml出力例
apiVersion: velero.io/v2alpha1 kind: DataUpload metadata: name: backup-test-1-sw76b namespace: openshift-adp spec: backupStorageLocation: dpa-sample-1 csiSnapshot: snapshotClass: "" storageClass: gp3-csi volumeSnapshot: velero-mysql-fq8sl operationTimeout: 10m0s snapshotType: CSI sourceNamespace: mysql-persistent sourcePVC: mysql status: completionTimestamp: "2023-11-02T16:57:02Z" node: ip-10-0-150-57.us-west-2.compute.internal path: /host_pods/15116bac-cc01-4d9b-8ee7-609c3bef6bde/volumes/kubernetes.io~csi/pvc-eead8167-556b-461a-b3ec-441749e291c4/mount phase: Completed1 progress: bytesDone: 108104082 totalBytes: 108104082 snapshotID: 8da1c5febf25225f4577ada2aeb9f899 startTimestamp: "2023-11-02T16:56:22Z"- 1
- これは、スナップショットデータがリモートオブジェクトストアに正常に転送されたことを示しています。
4.21.2.2. CSI ボリュームスナップショットの復元 リンクのコピーリンクがクリップボードにコピーされました!
Restore CR を作成することで、ボリュームスナップショットを復元できます。
OAPD 1.3 のビルトイン Data Mover を使用して、OADP 1.2 から Volsync バックアップを復元することはできません。OADP 1.3 にアップグレードする前に、Restic を使用してすべてのワークロードのファイルシステムバックアップを実行することが推奨されます。
前提条件
-
cluster-adminロールでクラスターにアクセスできる。 -
データの復元元となる OADP
BackupCR がある。
手順
次の例のように、
RestoreCR の YAML ファイルを作成します。RestoreCR の例apiVersion: velero.io/v1 kind: Restore metadata: name: restore namespace: openshift-adp spec: backupName: <backup> # ...マニフェストを適用します。
$ oc create -f restore.yaml復元が開始されると、
DataDownloadが作成されます。
検証
DataDownloadCR のstatus.phaseフィールドをチェックすることで、復元プロセスのステータスを監視できます。使用される値は、In Progress、Completed、Failed、またはCanceledです。すべての
DataDownloadオブジェクトのリストを取得するには、次のコマンドを実行します。$ oc get datadownloads -A出力例
NAMESPACE NAME STATUS STARTED BYTES DONE TOTAL BYTES STORAGE LOCATION AGE NODE openshift-adp restore-test-1-sk7lg Completed 7m11s 108104082 108104082 dpa-sample-1 7m11s ip-10-0-150-57.us-west-2.compute.internal次のコマンドを入力して、特定の
DataDownloadオブジェクトのstatus.phaseフィールドの値を確認します。$ oc get datadownloads <datadownload_name> -o yaml出力例
apiVersion: velero.io/v2alpha1 kind: DataDownload metadata: name: restore-test-1-sk7lg namespace: openshift-adp spec: backupStorageLocation: dpa-sample-1 operationTimeout: 10m0s snapshotID: 8da1c5febf25225f4577ada2aeb9f899 sourceNamespace: mysql-persistent targetVolume: namespace: mysql-persistent pv: "" pvc: mysql status: completionTimestamp: "2023-11-02T17:01:24Z" node: ip-10-0-150-57.us-west-2.compute.internal phase: Completed1 progress: bytesDone: 108104082 totalBytes: 108104082 startTimestamp: "2023-11-02T17:00:52Z"- 1
- CSI スナップショットデータが正常に復元されたことを示します。
4.21.2.3. OADP 1.3 の削除ポリシー リンクのコピーリンクがクリップボードにコピーされました!
削除ポリシーは、システムからデータを削除するためのルールを決定します。保存期間、データの機密性、コンプライアンス要件などの要素に基づいて、削除をいつどのように行うかを指定します。規制を遵守し、貴重な情報を保護しながら、データの削除を効果的に管理します。
4.21.2.3.1. OADP 1.3 の削除ポリシーガイドライン リンクのコピーリンクがクリップボードにコピーされました!
OADP 1.3 の次の削除ポリシーガイドラインを確認してください。
-
OADP 1.3.x でいずれかのタイプのバックアップおよびリストア方法を使用する場合は、
VolumeSnapshotClassカスタムリソース (CR) のdeletionPolicyフィールドをRetainまたはDeleteに設定できます。
4.21.3. Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
Data Protection Application (DPA) の特定の環境変数を使用すると、Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのデフォルト値をオーバーライドできます。
4.21.3.1. Kopia のハッシュ、暗号化、スプリッターアルゴリズムをオーバーライドするように DPA を設定する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift API for Data Protection (OADP) のオプションを使用すると、ハッシュ、暗号化、スプリッターのデフォルトの Kopia アルゴリズムをオーバーライドして、Kopia のパフォーマンスを向上させたり、パフォーマンスメトリクスを比較したりできます。DPA の spec.configuration.velero.podConfig.env セクションで次の環境変数を設定できます。
-
KOPIA_HASHING_ALGORITHM -
KOPIA_ENCRYPTION_ALGORITHM -
KOPIA_SPLITTER_ALGORITHM
前提条件
- OADP Operator がインストールされている。
- クラウドプロバイダーから提供された認証情報を使用してシークレットを作成した。
Data Protection Application (DPA) の分割、ハッシュ、および暗号化のための Kopia アルゴリズムの設定は、Kopia リポジトリーの初回作成時にのみ適用され、後で変更することはできません。
異なる Kopia アルゴリズムを使用するには、オブジェクトストレージに、バックアップの以前の Kopia リポジトリーが含まれていないことを確認してください。Backup Storage Location (BSL) で新しいオブジェクトストレージを設定するか、BSL 設定でオブジェクトストレージの一意の接頭辞を指定します。
手順
次の例に示すように、ハッシュ、暗号化、およびスプリッター用の環境変数を使用して DPA を設定します。
DPA の例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication #... configuration: nodeAgent: enable: true1 uploaderType: kopia2 velero: defaultPlugins: - openshift - aws - csi3 defaultSnapshotMoveData: true podConfig: env: - name: KOPIA_HASHING_ALGORITHM value: <hashing_algorithm_name>4 - name: KOPIA_ENCRYPTION_ALGORITHM value: <encryption_algorithm_name>5 - name: KOPIA_SPLITTER_ALGORITHM value: <splitter_algorithm_name>6
4.21.3.2. Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのオーバーライドの使用例 リンクのコピーリンクがクリップボードにコピーされました!
この使用例では、ハッシュ、暗号化、スプリッター用の Kopia 環境変数を使用してアプリケーションのバックアップを作成する方法を示します。バックアップは AWS S3 バケットに保存します。その後、Kopia リポジトリーに接続して環境変数を検証します。
前提条件
- OADP Operator がインストールされている。
- Backup Storage Location として AWS S3 バケットが設定されている。
- クラウドプロバイダーから提供された認証情報を使用してシークレットを作成した。
- Kopia クライアントがインストールされている。
- 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。
手順
次の例に示すように、Data Protection Application (DPA) を設定します。
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name>1 namespace: openshift-adp spec: backupLocations: - name: aws velero: config: profile: default region: <region_name>2 credential: key: cloud name: cloud-credentials3 default: true objectStorage: bucket: <bucket_name>4 prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - openshift - aws - csi5 defaultSnapshotMoveData: true podConfig: env: - name: KOPIA_HASHING_ALGORITHM value: BLAKE3-2566 - name: KOPIA_ENCRYPTION_ALGORITHM value: CHACHA20-POLY1305-HMAC-SHA2567 - name: KOPIA_SPLITTER_ALGORITHM value: DYNAMIC-8M-RABINKARP8 次のコマンドを実行して DPA を作成します。
$ oc create -f <dpa_file_name>1 - 1
- 設定した DPA のファイル名を指定します。
次のコマンドを実行して、DPA が調整されたことを確認します。
$ oc get dpa -o yaml次の例に示すように、バックアップ CR を作成します。
バックアップ CR の例
apiVersion: velero.io/v1 kind: Backup metadata: name: test-backup namespace: openshift-adp spec: includedNamespaces: - <application_namespace>1 defaultVolumesToFsBackup: true- 1
- クラスターにインストールされているアプリケーションの namespace を指定します。
次のコマンドを実行してバックアップを作成します。
$ oc apply -f <backup_file_name>1 - 1
- バックアップ CR ファイルの名前を指定します。
次のコマンドを実行して、バックアップが完了したことを確認します。
$ oc get backups.velero.io <backup_name> -o yaml1 - 1
- バックアップの名前を指定します。
検証
次のコマンドを実行して、Kopia リポジトリーに接続します。
$ kopia repository connect s3 \ --bucket=<bucket_name> \1 --prefix=velero/kopia/<application_namespace> \2 --password=static-passw0rd \3 --access-key="<aws_s3_access_key>" \4 --secret-access-key="<aws_s3_secret_access_key>" \5 注記AWS S3 以外のストレージプロバイダーを使用している場合は、コマンドにバケットエンドポイントの URL パラメーター
--endpointを追加する必要があります。次のコマンドを実行して、バックアップ用に DPA で設定した環境変数を Kopia が使用していることを確認します。
$ kopia repository status出力例
Config file: /../.config/kopia/repository.config Description: Repository in S3: s3.amazonaws.com <bucket_name> # ... Storage type: s3 Storage capacity: unbounded Storage config: { "bucket": <bucket_name>, "prefix": "velero/kopia/<application_namespace>/", "endpoint": "s3.amazonaws.com", "accessKeyID": <access_key>, "secretAccessKey": "****************************************", "sessionToken": "" } Unique ID: 58....aeb0 Hash: BLAKE3-256 Encryption: CHACHA20-POLY1305-HMAC-SHA256 Splitter: DYNAMIC-8M-RABINKARP Format version: 3 # ...
4.21.3.3. Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのベンチマーク リンクのコピーリンクがクリップボードにコピーされました!
Kopia のコマンドを実行して、ハッシュ、暗号化、およびスプリッターアルゴリズムのベンチマークを実行できます。ベンチマークの結果に基づいて、ワークロードに最も適したアルゴリズムを選択できます。この手順では、クラスター上の Pod から Kopia ベンチマークコマンドを実行します。ベンチマークの結果は、CPU 速度、使用可能な RAM、ディスク速度、現在の I/O 負荷などによって異なります。
前提条件
- OADP Operator がインストールされている。
- 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。
- Container Storage Interface (CSI) スナップショットを使用してアプリケーションのバックアップを実行した。
Data Protection Application (DPA) の分割、ハッシュ、および暗号化のための Kopia アルゴリズムの設定は、Kopia リポジトリーの初回作成時にのみ適用され、後で変更することはできません。
異なる Kopia アルゴリズムを使用するには、オブジェクトストレージに、バックアップの以前の Kopia リポジトリーが含まれていないことを確認してください。Backup Storage Location (BSL) で新しいオブジェクトストレージを設定するか、BSL 設定でオブジェクトストレージの一意の接頭辞を指定します。
手順
以下の例のように、
must-gatherPod を設定します。必ず OADP バージョン 1.3 以降のoadp-mustgatherイメージを使用してください。Pod 設定の例
apiVersion: v1 kind: Pod metadata: name: oadp-mustgather-pod labels: purpose: user-interaction spec: containers: - name: oadp-mustgather-container image: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 command: ["sleep"] args: ["infinity"]注記Kopia クライアントは
oadp-mustgatherイメージで利用できます。以下のコマンドを実行して Pod を作成します。
$ oc apply -f <pod_config_file_name>1 - 1
- Pod 設定用の YAML ファイルの名前を指定します。
Kopia がリポジトリーに接続できるように、Pod の Security Context Constraints (SCC) が
anyuidであることを確認します。$ oc describe pod/oadp-mustgather-pod | grep scc出力例
openshift.io/scc: anyuid次のコマンドを実行して、SSH 経由で Pod に接続します。
$ oc -n openshift-adp rsh pod/oadp-mustgather-pod次のコマンドを実行して、Kopia リポジトリーに接続します。
sh-5.1# kopia repository connect s3 \ --bucket=<bucket_name> \1 --prefix=velero/kopia/<application_namespace> \2 --password=static-passw0rd \3 --access-key="<access_key>" \4 --secret-access-key="<secret_access_key>" \5 --endpoint=<bucket_endpoint> \6 注記これはコマンドの例です。コマンドはオブジェクトストレージプロバイダーによって異なる場合があります。
ハッシュアルゴリズムをベンチマークするには、次のコマンドを実行します。
sh-5.1# kopia benchmark hashing出力例
Benchmarking hash 'BLAKE2B-256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE2B-256-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE2S-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE2S-256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE3-256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE3-256-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA224' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA256-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA3-224' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA3-256' (100 x 1048576 bytes, parallelism 1) Hash Throughput ----------------------------------------------------------------- 0. BLAKE3-256 15.3 GB / second 1. BLAKE3-256-128 15.2 GB / second 2. HMAC-SHA256-128 6.4 GB / second 3. HMAC-SHA256 6.4 GB / second 4. HMAC-SHA224 6.4 GB / second 5. BLAKE2B-256-128 4.2 GB / second 6. BLAKE2B-256 4.1 GB / second 7. BLAKE2S-256 2.9 GB / second 8. BLAKE2S-128 2.9 GB / second 9. HMAC-SHA3-224 1.6 GB / second 10. HMAC-SHA3-256 1.5 GB / second ----------------------------------------------------------------- Fastest option for this machine is: --block-hash=BLAKE3-256暗号化アルゴリズムをベンチマークするには、次のコマンドを実行します。
sh-5.1# kopia benchmark encryption出力例
Benchmarking encryption 'AES256-GCM-HMAC-SHA256'... (1000 x 1048576 bytes, parallelism 1) Benchmarking encryption 'CHACHA20-POLY1305-HMAC-SHA256'... (1000 x 1048576 bytes, parallelism 1) Encryption Throughput ----------------------------------------------------------------- 0. AES256-GCM-HMAC-SHA256 2.2 GB / second 1. CHACHA20-POLY1305-HMAC-SHA256 1.8 GB / second ----------------------------------------------------------------- Fastest option for this machine is: --encryption=AES256-GCM-HMAC-SHA256スプリッターアルゴリズムをベンチマークするには、次のコマンドを実行します。
sh-5.1# kopia benchmark splitter出力例
splitting 16 blocks of 32MiB each, parallelism 1 DYNAMIC 747.6 MB/s count:107 min:9467 10th:2277562 25th:2971794 50th:4747177 75th:7603998 90th:8388608 max:8388608 DYNAMIC-128K-BUZHASH 718.5 MB/s count:3183 min:3076 10th:80896 25th:104312 50th:157621 75th:249115 90th:262144 max:262144 DYNAMIC-128K-RABINKARP 164.4 MB/s count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144 # ... FIXED-512K 102.9 TB/s count:1024 min:524288 10th:524288 25th:524288 50th:524288 75th:524288 90th:524288 max:524288 FIXED-8M 566.3 TB/s count:64 min:8388608 10th:8388608 25th:8388608 50th:8388608 75th:8388608 90th:8388608 max:8388608 ----------------------------------------------------------------- 0. FIXED-8M 566.3 TB/s count:64 min:8388608 10th:8388608 25th:8388608 50th:8388608 75th:8388608 90th:8388608 max:8388608 1. FIXED-4M 425.8 TB/s count:128 min:4194304 10th:4194304 25th:4194304 50th:4194304 75th:4194304 90th:4194304 max:4194304 # ... 22. DYNAMIC-128K-RABINKARP 164.4 MB/s count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144