SynologyNAS kopiaによるbackblazeへのバックアップメモ
yunakopiaとは？
公式より
高速かつ安全なオープンソースのバックアップソフトウェア
https://kopia.io/
高速な増分バックアップ、クライアント側のエンドツーエンド暗号化、圧縮、データ重複排除を備えた、Windows、macOS、Linux 用のクロスプラットフォーム バックアップ ツールです。 CLI と GUI が含まれています。
https://github.com/kopia/kopia/
動作確認の前に、気になるポイント
少し老舗のソフトでkopiaと比較されるものとして、resticというものがあり、
私はもともと、バックアップに、こちらを利用しています。
バックアップ速度について
kopiaとの比較記事を読むと、resticはシングルスレッド（？）のため、kopia(並列性がある）と比較すると
遅いというものが目に入る
ただし、単一の大きいファイルに関して言えば、s3にバックアップする場合、s3の１ファイルを複数に分けてアップする機能に対応しているが、kopiaは対応していないのでresticの方が早いらしい（現時点では不明）
堅牢性について
resticを使ってると、堅牢性を感じる場面が多く安心感があるのだが、kopiaはどうなのだろう？
（例えば、バックアップ中に電源が落ちても、再実行することでその続きからバックアップしてくれるし、バックアップファイルが壊れることもない。安全な設計になっていると思われる）
バージョンアップによる後方互換性
後方互換性は？
resticのforumで、比較の話題が。
kopiaが出たばかりの2020年に立てられているので、現在（2024年3月）ではもう少し両者とも成熟してきていると思われるが、気になるのはkopiaをやめてresticを採用したという方のコメント。
@2022/11
コピアは十分に成熟していません。一部のアップデートでは互換性が失われます。まだゴールデンタイムの準備ができていません。 Restic は欠落していた重要な要素である圧縮をサポートするようになったので、私はもう Kopia には注目しません。
https://forum.restic.net/t/kopia-vs-restic-comparison/2893/38
GUIについて
restic公式では、cliしか用意されておらず、GUIでリポジトリの情報を見たりできません。
※ユーザーが作成しているrestic-browserというものはあります
万が一のタイミングで、
できれば、windowsから直接repositoryにアクセスして、個別にファイルを見れると便利なので、
この辺りも期待したいところ。
yunakopiaで出てくる用語について
snapshot
ファイル/ディレクトリのpoint-in-time backupです。各snapshotには、必要なときに復元できるファイル/ディレクトリが含まれています。
repository
snapshotが保存されるストレージの場所です。コピアは、クラウド/リモート、ネットワーク、およびローカルのストレージの場所をサポートしており、すべてのリポジトリは指定したパスワードで暗号化されます。
policy
snapshotの作成/管理方法をコピアに指示するルールのセットです。これには、圧縮、snapshotの保持、自動的にsnapshotを取得するタイミングのスケジューリングなどの機能が含まれます。
構成について
実際は、NAS（検証機：Synology DS220j）からのバックアップが要件なので、
NASからバックアップできるか、を前提に検証していきます。
また、バックアップ先（repository）は、コストパフォーマンスからBackblase B2を採用します
Backblaze B2は、resticでもバックアップを行っていますが、大量のファイルを送信していると、
connectionが切れることがあります。
resticはその場合、リトライすることで継続してバックアップ処理を進められますが、kopiaの場合はどうなるか、についても検証します。
yuna参考記事：
▼kopia公式 Getting-started
▼kopia→backblazeの事例（2022）
yunaダウンロード
kopiaはCLI、GUI両方に対応していますが、今回は、NAS上で使うことから、CLIベースのkopiaを使います。
ということで、公式からbinaryファイルをダウンロードします
公式の最新リリースページの、assetから適切なバイナリを選択してダウンロード
今回はNASがarm64のCPUなので、kopia-0.16.1-linux-arm64.tar.gz を選択
（都合上sudoが必要なので付けてます）
$ sudo wget https://github.com/kopia/kopia/releases/download/v0.16.1/kopia-0.16.1-linux-arm64.tar.gz
$ sudo tar -xzvf kopia-0.16.1-linux-arm64.tar.gz
#バージョンと動作確認
$ sudo kopia-0.16.1-linux-arm64/kopia --version
0.16.1 build: 4f1c994c39ff76270f71c5b3dcec774df8b3c4e5 from: kopia/kopia
CLIによるrepository作成
参考：
$ ./kopia repository create b2 \
--bucket=<bucket name(bucket idではなく名前)> \
--key-id=<Application keyID> \
--key=<applicationKey> \
--cache-directory /volume1/homes/xxxxxxxxxxx/.cache/kopia
#Kopiaのencryptionパスワードを問われるので、２回入力する
Enter password to create new repository:
Re-enter password for verification:
#以下、処理内容が表示され、リポジトリが初期化される。
Initializing repository with:
block hash: BLAKE2B-256-128
encryption: AES256-GCM-HMAC-SHA256
splitter: DYNAMIC-4M-BUZHASH
Connected to repository.
NOTICE: Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use.
To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false
Alternatively you can remove the file "/root/.config/kopia/repository.config.update-info.json".
Retention:
Annual snapshots: 3 (defined for this target)
Monthly snapshots: 24 (defined for this target)
Weekly snapshots: 4 (defined for this target)
Daily snapshots: 7 (defined for this target)
Hourly snapshots: 48 (defined for this target)
Latest snapshots: 10 (defined for this target)
Ignore identical snapshots: false (defined for this target)
Compression disabled.
To find more information about default policy run 'kopia policy get'.
To change the policy use 'kopia policy set' command.
NOTE: Kopia will perform quick maintenance of the repository automatically every 1h0m0s
and full maintenance every 24h0m0s when running as root@ds220j_nas.
上記、色々と処理結果が表示されるが、重要なポイントをピックアップ
Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use.
To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false
Alternatively you can remove the file "/root/.config/kopia/repository.config.update-info.json".
どうやら自動的にupdateチェックがかかるらしい。
できれば手動で管理したいので、取り急ぎupdate checkを無効にする。
configファイルの削除だと、またrepository connectなどしたときに作成されてしまうので、
環境変数KOPIA_CHECK_FOR_UPDATES=false のセットを行うことでの対応とする。
※なお、上記ファイルの中身は以下の通り
{"nextCheckTimestamp":"2024-03-30T02:36:47.769160032+09:00","nextNotifyTimestamp":"2024-03-30T02:36:47.769161514+09:00","availableVersion":""}
ちなみに、デフォルトでconfig関係のファイルは、
$HOME/.config/kopia
ここの中に保存されるらしい。
rootでkopia実行した場合は、/root/.config/kopia ここになる。
$ ls -la /root/.config/kopia
total 20
drwx------ 2 root root 4096 Mar 29 02:52 .
drwx------ 3 root root 4096 Mar 29 02:52 ..
-rw------- 1 root root 576 Mar 29 02:52 repository.config
-rw------- 1 root root 28 Mar 29 02:52 repository.config.kopia-password
-rw------- 1 root root 143 Mar 29 02:52 repository.config.update-info.json
cacheの方の構成はこんな感じ
sudo ls -la /volume1/homes/xxxxxxx/.cache/kopia
total 44
drwx------ 8 root root 4096 Mar 29 03:04 .
drwx------ 4 root root 4096 Mar 29 03:04 ..
drwx------ 2 root root 4096 Mar 29 03:04 blob-list
-rw------- 1 root root 291 Mar 29 03:04 CACHEDIR.TAG
drwx------ 2 root root 4096 Mar 29 03:04 contents
drwx------ 2 root root 4096 Mar 29 03:04 index-blobs
drwx------ 2 root root 4096 Mar 29 03:04 indexes
-rw------- 1 root root 30 Mar 29 03:04 kopia.blobcfg
-rw------- 1 root root 1101 Mar 29 03:04 kopia.repository
drwx------ 2 root root 4096 Mar 29 03:04 metadata
drwx------ 2 root root 4096 Mar 29 03:04 own-writes
パスワードをtoken化して、都度入力不要にする
バックアップは自動で行いたいので、都度パスワード入力無しでも処理できるようにしておく必要がある。
sudo ./kopia repository status -t -s
処理結果。
下記のtoken部分（xxxxでマスキングしてます）を使うことで、今後password入力なしで処理が行えます。
Config file: /root/.config/kopia/repository.config
Description: Repository in B2: <repository bucket name>
Hostname: ds220j_nas
Username: root
Read-only: false
Format blob cache: 15m0s
Storage type: b2
Storage capacity: unbounded
Storage config: {
"bucket": "<repository bucket name>",
"keyID": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"key": "*******************************"
}
Unique ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hash: BLAKE2B-256-128
Encryption: AES256-GCM-HMAC-SHA256
Splitter: DYNAMIC-4M-BUZHASH
Format version: 3
Content compression: true
Password changes: true
Max pack length: 21 MB
Index Format: v2
Epoch Manager: enabled
Current Epoch: 0
Epoch refresh frequency: 20m0s
Epoch advance on: 20 blobs or 10.5 MB, minimum 24h0m0s
Epoch cleanup margin: 4h0m0s
Epoch checkpoint every: 7 epochs
To reconnect to the repository use:
$ kopia repository connect from-config --token xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
NOTICE: The token printed above can be trivially decoded to reveal the repository password. Do not store it in an unsecured place.
試しにconnect
sudo ./kopia repository connect from-config --token xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Connected to repository. が表示されればOK
yunaSnapshotの作成
上記、repositoryにconnectした状態で、
$ sudo ./kopia snapshot create /volume1/サンプルディレクトリ
Snapshotting root@ds220j_nas:/volume1/サンプルディレクトリ ...
* 0 hashing, 2 hashed (92 B), 0 cached (0 B), uploaded 204 B, estimated 92 B (100.0%) 0s left
Created snapshot with root k48c836a5ca2f1bcc300052abe165e9af and ID 6fa6b049bfbe036b4c1852bfca62f3df in 1s
Running full maintenance...
Looking for active contents...
Looking for unreferenced contents...
GC found 0 unused contents (0 B)
GC found 0 unused contents that are too recent to delete (0 B)
GC found 7 in-use contents (1.5 KB)
GC found 2 in-use system-contents (1.2 KB)
Rewriting contents from short packs...
Total bytes rewritten 0 B
Not enough time has passed since previous successful Snapshot GC. Will try again next time.
Skipping blob deletion because not enough time has passed yet (59m59s left).
Cleaning up old index blobs which have already been compacted...
Cleaned up 0 logs.
Finished full maintenance.
うまくsnapshot作成できた。
これ以降、同じコマンドで、自動的に増分のSnapshotを作成してくれます。
yunaSnapshot リストの取得
ディレクトリに対して、snapshotを取得できます。（これresticでできたっけ？）
$ sudo ./kopia snapshot list /volume1/サンプルディレクトリ
root@ds220j_nas:/volume1/サンプルディレクトリ
2024-03-29 03:27:11 JST k48c836a5ca2f1bcc300052abe165e9af 92 B d--------- files:2 dirs:5 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
Managing Snapshots
上記リスト中のIDを用いて、対象ディレクトリの内部が確認できる
$ sudo ./kopia ls -l k48c836a5ca2f1bcc300052abe165e9af
rw-r--r-- 6148 2019-06-22 19:01:45 PDT aea2fe8e5ed3104806957f48648c957e .DS_Store
-rw-r--r-- 78 2019-05-09 22:33:06 PDT c829f2205d0ba889ebb354464e14c97a .gitignore
-rw-r--r-- 1101 2019-05-09 22:33:06 PDT 5c4da68139ab0a92a56c334988c75e2a CONTRIBUTING.md
-rw-r--r-- 11357 2019-05-09 22:33:06 PDT 28614f260fab7463e3cd9c410a501c3f LICENSE
-rw-r--r-- 1613 2019-06-22 19:01:17 PDT 5c1f9d67a2b1e2d34fc121ba774266b4 Makefile
-rw-r--r-- 2286 2019-05-09 22:33:06 PDT 83a5b758d8409550010786e254096606 README.md
drwxr-xr-x 11264 2019-05-09 22:33:06 PDT kc76b1a9ddf378f803f1710df1150ded6 assets/
drwxr-xr-x 6275 2019-06-02 23:08:14 PDT kf3b4b410df41570345dbc2a8043ee29b cli2md/
-rw-r--r-- 3749 2019-05-14 19:00:21 PDT 8c9e27bed2f577b31b07b07da4bdfffb config.toml
drwxr-xr-x 879721 2019-06-22 20:15:45 PDT k24eb31a05b81d1a83c47c40a4f7b9f0e content/
-rwxr-xr-x 727 2019-05-09 22:33:06 PDT 2c08f511019f1f5f45f889909c755a9b deploy.sh
drwxr-xr-x 1838 2019-05-14 19:00:21 PDT k024f1106e0cd56e2c6611cf884a30894 layouts/
drwxr-xr-x 13682567 2019-06-22 18:57:48 PDT k181d6990e75dd783bd50dae36591622a node_modules/
-rw-r--r-- 94056 2019-06-22 18:57:49 PDT ed474fb638d2a3b1c528295d1586466a package-lock.json
-rw-r--r-- 590 2019-05-09 22:33:06 PDT ee85ae1f1cdb70bbd9e335be9762c251 package.json
drwxr-xr-x 7104710 2019-06-22 19:01:38 PDT keb814d92fe795b96795d5bdbfa816ad6 public/
drwxr-xr-x 904965 2019-06-22 20:13:56 PDT k7bf88a7ca076b03f0dafc93ab5fa2263 resources/
drwxr-xr-x 38701570 2019-06-01 20:11:32 PDT kdb9f41fc8db5c45b1aec06df001be995 themes/
各フォルダ・ファイルの詳細も確認できる（フォルダ・ファイルのIDを指定）
$ sudo ./kopia show 17b62b972722585a8a95df3744d8d80b
→これはファイル名だけ取得
#ファイル詳細
$ sudo ./kopia content show -j xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
{
"stream": "kopia:directory",
"entries": [
{
"name": "assets",
"type": "d",
"mode": "0755",
"mtime": "2019-05-14T18:24:15-07:00",
"uid": 501,
"gid": 20,
"obj": "kc76b1a9ddf378f803f1710df1150ded6",
"summ": {
"size": 11264,
"files": 2,
"dirs": 3,
"maxTime": "2019-05-09T22:33:06-07:00"
}
},
...
{
"name": "package.json",
"type": "f",
"mode": "0644",
"size": 590,
"mtime": "2019-05-09T22:33:06-07:00",
"uid": 501,
"gid": 20,
"obj": "ee85ae1f1cdb70bbd9e335be9762c251"
}
],
"summary": {
"size": 61414615,
"files": 12500,
"dirs": 798,
"maxTime": "2019-06-22T20:15:45.301289096-07:00"
}
}
#ファイル詳細（日本語名を含むファイルで試してみた）
$ sudo ./kopia content show -j 17b62b972722585a8a95df3744d8d80b
ERROR errors indenting JSON: invalid character 'å' looking for beginning of value
日本語名を含むファイルだと、エラーになる？
yunaSnapshotのmountと、リストア
（省略）
yunaPoliciesの設定
Policiesは、Kopia スナップショットの取得と保持方法を指定するために使用できます。
・無視するファイル
・時間毎、日毎、週毎、月毎、年毎のスナップショット数
・スナップショットの作成頻度
・ファイルを圧縮するかどうか
Policiesは、以下の３種類で設定できます。
・単一ディレクトリ
・user@host
・グローバル ポリシー
policyの細かな設定をjsonファイルを編集することで行える
（が、ここでは行わず、kopia policy set で個別にコマンドからセットする方法を使うことにする）
$ sudo ./kopia policy edit --global
個別にセットする場合はこちら
$ sudo ./kopia policy set --add-ignore public/ --add-ignore node_modules/
現在のPoliciesを確認するには
このコマンド
$ sudo ./kopia policy show --global
Policy for (global):
Retention:
Annual snapshots: 3 (defined for this target)
Monthly snapshots: 24 (defined for this target)
Weekly snapshots: 4 (defined for this target)
Daily snapshots: 7 (defined for this target)
Hourly snapshots: 48 (defined for this target)
Latest snapshots: 10 (defined for this target)
Ignore identical snapshots: false (defined for this target)
Files policy:
Ignore cache directories: true (defined for this target)
No ignore rules:
Read ignore rules from files: (defined for this target)
.kopiaignore
Scan one filesystem only: false (defined for this target)
Error handling policy:
Ignore file read errors: false (defined for this target)
Ignore directory read errors: false (defined for this target)
Ignore unknown types: true (defined for this target)
Scheduling policy:
Scheduled snapshots:
None.
Manual snapshot: false (defined for this target)
Uploads:
Max parallel snapshots (server/UI): 1 (defined for this target)
Max parallel file reads: - (defined for this target)
Parallel upload above size: 2.1 GB (defined for this target)
Compression:
Compressor: none (defined for this target)
Compress files regardless of extensions.
Compress files of all sizes.
No actions defined.
OS-level snapshot support:
Volume Shadow Copy: never (defined for this target)
Logging details (0-none, 10-maximum):
Directory snapshotted: 5 (defined for this target)
Directory ignored: 5 (defined for this target)
Entry snapshotted: 0 (defined for this target)
Entry ignored: 5 (defined for this target)
Entry cache hit: 0 (defined for this target)
Entry cache miss: 0 (defined for this target)
Policiesの中の、気になるポイントだけ
スケジュールは、デフォルトで
Scheduled snapshots:
None.
となっている。手動で取りたいのでこれでOK.
圧縮アルゴリズム
Synology NASのような、そこまでスペックの良くないマシンを使うのであれば、
あまり重いアルゴリズムを使わないほうが良いかも。（zstdはメモリ使用量が大きい）
Repeating 1 times per compression method (total 466.7 MiB).
Compression Compressed Throughput Memory Usage
------------------------------------------------------------------------------------------------
0. s2-default 127.1 MiB 4 GiB/s 3126 375.4 MiB
1. s2-better 120.1 MiB 3.4 GiB/s 2999 351.7 MiB
2. s2-parallel-8 127.1 MiB 2.8 GiB/s 2981 362.2 MiB
3. s2-parallel-4 127.1 MiB 2.3 GiB/s 2951 344.1 MiB
4. pgzip-best-speed 96.7 MiB 2.1 GiB/s 4127 324.1 MiB
5. pgzip 86.3 MiB 1.2 GiB/s 4132 298.7 MiB
6. lz4 131.8 MiB 458.9 MiB/s 17 321.7 MiB
7. zstd-fastest 79.8 MiB 356.2 MiB/s 22503 246 MiB
8. zstd 76.8 MiB 323.7 MiB/s 22605 237.8 MiB
9. deflate-best-speed 96.7 MiB 220.8 MiB/s 45 310.8 MiB
10. gzip-best-speed 94.9 MiB 165 MiB/s 40 305.2 MiB
11. deflate-default 86.3 MiB 143.1 MiB/s 34 311 MiB
12. zstd-better-compression 74.2 MiB 104 MiB/s 22496 251.4 MiB
13. pgzip-best-compression 83 MiB 55.9 MiB/s 4359 299.1 MiB
14. gzip 83.6 MiB 40.5 MiB/s 69 304.8 MiB
15. zstd-best-compression 68.9 MiB 19.2 MiB/s 22669 303.4 MiB
16. deflate-best-compression 83 MiB 5.6 MiB/s 134 311 MiB
17. gzip-best-compression 83 MiB 5.1 MiB/s 137 304.8 MiB
ここでは、s2-betterを使ってみる。
$ sudo ./kopia policy set --global --compression s2-better
run-missed
予定されていた時刻に実行されなかった場合、後から実行するか？の設定
説明：
--run-missed Run missed time-of-day or cron snapshots (’true’, ‘false’, ‘inherit’)
日中に実行されて重くなってしまうのは避けたい。
デフォルトでtrueになっていたので、falseにする。
$ sudo ./kopia policy set --global --run-missed false
アップロード速度検証
resticと違って、エラーで処理が終了することがなかった。
自動的に再接続してるのかも？
Synologyの2TBファイルを扱うとして、
1.5TB= 約667GBだと、単純計算で210時間=8.8日
初回のアップはそれなりに時間がかかることが想定されるが、なんとか運用はできそうか。
（※ プログラミング開発系でファイル数が非常に多いので、一般的な事務フォルダなどであればもっと小さいと思われる）
アップしたファイル
Linux, mac, windows、３つのノートPCの開発系のディレクトリをバックアップのために
NASにsyncしているので、それらをまとめてクラウドバックアップを取ってみました。
ファイルサイズ：79.1GB
files: 40402
directories: 256159
インターネット通信速度：一般的な家庭の光通信（※後に実測値を入れます）
時間：11時間7分
詳細なsnapshotデータ
$ kopia snapshot list
root@ds220j_nas:/volume1/linux-mint-project
2024-03-29 05:50:42 JST k87e0b4b14420d6f5d464ca06e29dfa3f 63 GB d--------- files:114055 dirs:20836 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
root@ds220j_nas:/volume1/macos-air-m1
2024-03-29 15:14:58 JST k8bd2fef60376ee0017f3e1990b01880e 6.5 GB d--------- files:30023 dirs:8551 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
root@ds220j_nas:/volume1/windows-carbon
2024-03-29 04:41:14 JST ke123be1a7b87ef89222e62d771897377 9.6 GB d--------- files:112081 dirs:11015 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
バックアップ中断してもデータ整合性が取れるか検証
バックアップの途中でNASの電源を落として、正しくバックアップが継続できるかを検証してみる。
→正常にバックアップ完了し、リストアテストしてもデータの破損は無かった。
yunaresticとのパフォーマンス比較
本来は５回テストして平均を出すべきだが、取り急ぎ１回だけ実行して様子見
テストするファイル群
Linux, mac, windows、３つのノートPCの開発系のディレクトリをバックアップのために
NASにsyncしているので、それらをまとめてクラウドバックアップを取る。
ファイルサイズ：79.1GB
files: 40402
directories: 256159
インターネット通信速度：一般的な家庭の光通信（※後に実測値を入れます）
空のリポジトリに、全ファイルバックアップ実行
kopia(compression method: s2-better)
total: 73.2 GB（backblaze上のファイルサイズ）
時間：11時間7分
restic
total: 62.6 GB（backblaze上のファイルサイズ）
時間：9時間6 分
resticの方が1.2倍速い
全ファイルアップロード後、差分なし状態でバックアップ実行
ファイル差分を洗い出す処理のみでの比較です
開始時刻：Sat Mar 30 16:09:02 JST 2024
終了時刻：Sat Mar 30 16:19:15 JST 2024
トータル： 0 hour(s) 10 minute(s) 13 second(s)
開始時刻：Fri Mar 29 00:00:02 JST 2024
終了時刻：Fri Mar 29 00:03:14 JST 2024
トータル： 0 hour(s) 3 minute(s) 12 second(s)
resticの方が３倍速い
結論
一度しか比較してないが、
これだけ見るとrestic 0.16.4 の方がアップロードも、圧縮効率も、再実行も全てに置いて上回った。