ローカルNASリポジトリでは、リポジトリファイルのオーバーヘッドやHDDのシーク動作がスループットを制限していることが測定で示されない限り、resticの16 MiBのデフォルト値を維持してください。NASが数テラバイト規模のリポジトリを回転ディスクに保存している場合は、それより大きな値を検討する前に、32 MiBまたは64 MiBのパックをベンチマークするのが妥当です。
パックサイズは、resticの重複排除チャンクサイズと同じではありません。Resticはまずファイルデータをコンテンツ定義blobに分割し、その後blobをパックファイルにまとめます。目標パックサイズを変更すると、リポジトリ内でそれらのblobをどのようにまとめるかが変わりますが、リポジトリのチャンカー多項式やコンテンツハッシュは変わりません。
まずは16 MiBのデフォルト値から始める
現在のresticの調整ガイダンスでは、パックサイズのデフォルト目標値は16 MiBとされています。また、ローカルHDDに保存された一部のリポジトリでは、パックファイルを大きくするとリポジトリ内のファイル数を減らし、バックアップ性能を向上させられる場合があることも示されています。
restic version
restic -r /mnt/nas/restic-repo snapshots
restic -r /mnt/nas/restic-repo stats --mode raw-data
調整する前に、resticのバージョン、リポジトリのサイズ、スナップショット数、ストレージの種類、現在のバックアップ所要時間を記録してください。リポジトリがすでにバックアップ時間枠内に完了している場合、パックサイズを大きくしても、実用的な効果が得られないまま複雑さが増す可能性があります。
パックサイズで実際に変わるものを理解する
Resticのリポジトリ形式の設計では、ファイル内容がコンテンツ定義blobに分割され、それらのblobがパックファイルにまとめられることが説明されています。
ソースファイル
|
コンテンツ定義チャンク化
|
重複排除されたblob
|
パックのグループ化
|
リポジトリのデータファイル
通常、パックの目標サイズを大きくすると、より少数の大きなリポジトリファイルになります。これにより、回転ディスクでメタデータ処理やファイルオープンのオーバーヘッドに費やす時間を短縮できる場合があります。ただし、同一のファイル内容がより適切に重複排除されるわけではありません。
NASが本当にパックサイズに制限されているか確認する
調整する前に、通常の増分バックアップ中にリポジトリのディスクを監視してください。スループットが低いまま、多数の短いシークやメタデータ操作で忙しくなっているローカルHDDのリポジトリは、すでに高速なシーケンシャル書き込みを行っているSSDのリポジトリよりも、調整の有力な候補です。
iostat -xz 2
ディスク使用率が継続的に高い状態、await時間の増加、大規模なシーケンシャル書き込みと比べて低いスループットがないか確認します。CPU使用率とソースの読み取り速度も確認してください。圧縮、ハッシュ計算、ソースI/O、ネットワークがボトルネックの場合、パックサイズを増やしても解決しません。
比較可能なリポジトリで16、32、64 MiBをベンチマークする
最も明確に比較するには、テスト用に使い捨てのリポジトリを作成します。同じソースデータセット、NASボリューム、resticのバージョン、バックエンド接続数を使用してください。
restic --pack-size 16 -r /mnt/nas/test-restic-16 init
restic --pack-size 16 -r /mnt/nas/test-restic-16 backup /srv/testdata
restic --pack-size 32 -r /mnt/nas/test-restic-32 init
restic --pack-size 32 -r /mnt/nas/test-restic-32 backup /srv/testdata
restic --pack-size 64 -r /mnt/nas/test-restic-64 init
restic --pack-size 64 -r /mnt/nas/test-restic-64 backup /srv/testdata
経過時間、リポジトリディスクのスループット、一時領域の使用量、生成されたデータファイル数を測定します。可能であれば、ページキャッシュの影響で結果が決まらないよう、実行を繰り返します。
パックサイズを増やす前に一時領域を確保する
Resticでは、一時領域の必要量をおおよそ次のように示しています。
パックサイズ ×(バックエンド接続数 + 1)
バックエンド接続が5つで、目標サイズが64 MiBの場合、最低384 MiBの一時領域が必要です。現在、ローカルバックエンドのデフォルト接続数はほとんどのリモートバックエンドより少ないですが、同じルールが適用されます。
df -h "${TMPDIR:-/tmp}"
export TMPDIR=/mnt/fast-temp/restic
mkdir -p "$TMPDIR"
一時パックを大きくすると、メモリ使用量が増え、キャッシュに残らずSSDストレージへ到達する一時書き込みが増える可能性もあります。
リポジトリを書き込むコマンドでは同じパックサイズ設定を使用する
Resticでは、リポジトリを変更するすべてのコマンドでパックサイズ設定を指定する必要があります。ジョブ全体で1つの環境変数を使用します。
export RESTIC_REPOSITORY=/mnt/nas/restic-repo
export RESTIC_PACK_SIZE=64
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
restic backup /srv/data
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic prune
パックサイズを変更しても重複排除のチャンク分割は再定義されませんが、サイズの異なるパックが残る可能性があります。設定を統一すると、今後のメンテナンスやパフォーマンス比較の解釈が容易になります。
既存のパックが自動的にサイズ変更されるとは限らない
新しいパックサイズ設定は、新しく作成されたデータまたは再パックされたデータに適用されます。既存のパックファイルは、単に設定を変更しただけでは書き換えられません。 RESTIC_PACK_SIZE 変更。
意図的に既存の小さいパックをプルーンで再パックしたい場合、現在のresticでは--repack-smaller-thanを使用できます。まずプルーンの再パックオプションを確認してください。
restic prune --dry-run --repack-smaller-than 32M
まずはドライランから始めてください。すべてのパックファイルの見た目を均一にするためだけに、完全な再パックを強制しないでください。
チューニング後に整合性を検証する
restic check
restic check --read-data-subset=5%
リポジトリのサイズに合った検証スケジュールを選択してください。resticのリポジトリのトラブルシューティングガイダンスでは、整合性チェックをリポジトリの損傷を診断する基礎として扱っています。
より広範なバックアップ設計では、ローカルリポジトリに別の独立したコピーを組み合わせてください。ZimaOSの3-2-1バックアップ戦略では、ローカルの冗長性と別の保存先が異なる障害モードに対処する理由を説明しています。
この判断ルールを使う
- バックアップがすでに所定の時間内に完了している場合や、ボトルネックが別の箇所にある場合は、16 MiBのままにしてください。
- 大容量HDDリポジトリでメタデータ処理や小ファイル操作にかなりの時間がかかる場合は、32 MiBを試してください。
- 32 MiBで効果があり、一時領域の使用量にも余裕がある場合は、64 MiBを試してください。
- 効果が頭打ちになったり、一時的なI/Oが増えたりしたら、増やすのをやめてください。
最適なパックサイズとは、新たなボトルネックを生じさせずに、リポジトリのオーバーヘッドを測定可能な範囲で削減できる最小値です。
resticのパックサイズに関するFAQ
パックサイズを大きくすると、resticの重複排除の効果は向上しますか?
いいえ。重複排除は、Blobがパックファイルにまとめられる前のBlob/チャンクレイヤーで行われます。
パックサイズを変更すると、古いパックファイルは書き換えられますか?
いいえ。既存のパックは、通常のプルーンまたは再パック処理で書き換えられるまで残ります。
ローカルHDD NASでは、最初にどのパックサイズを試すべきですか?
ベースラインとして16 MiBを使用し、同じワークロードで32 MiBと64 MiBをベンチマークしてください。
サポートとヒント
もっと読む

Home AssistantはWi-Fiでは動作するが、イーサネットまたはVPNでは接続できない
各ネットワーク経路を個別にテストし、インターフェースとルーティングの状態を確認して、直接IP接続と検出による接続を区別したうえで、失敗したレイヤーだけを修復します。

保護されていないデータを残さずにHome Assistantを廃止する方法
交換またはアーカイブを証明し、すべての信頼パスを無効化し、データを保持する各デバイスをサニタイズして、文書化された保護済みのリカバリコピーのみを保持する。

ホームサーバー上のHome Assistantで自動更新を利用すべきですか?
家庭への影響、互換性リスク、観察期間、復旧準備の状況を考慮して、手動更新、通知のみ、または段階的な自動更新を選択してください。

