長時間のバックアップ間隔を空けずにBorgのPruneとCompactを設定する方法
Borgバックアップの長い空白期間を避けるには、バックアップ成功後に保持期間のプルーニングを実行し、リポジトリのコンパクションは頻度を下げ、通常のバックアップ時間帯を避けてスケジュールしてください。 Borg 1.4ではアーカイブの削除と物理的な容量回収が分離されているため、すべてのborg pruneの後にborg compactを実行する必要はありません。
このガイドは、現行のBorg 1.4.x安定版のコマンドモデルを対象としています。Borg 2では、複数の領域でリポジトリとアーカイブの仕様が変更されているため、別のメジャーリリース向けに作成された自動化設定をそのままコピーする前に、インストールされているバージョンを確認してください。
Borgのバージョンとリポジトリを確認する
borg --version
borg info /mnt/backup/borg-repo
borg list /mnt/backup/borg-repoBorg FAQによると、Borgはリポジトリ全体にロックをかけ、書き込みアクセスできるプロセスは一度に1つだけです。長時間のコンパクションが次回のスケジュール済みバックアップと重なると、バックアップはロックが解除されるまで待機するか、ロックのタイムアウトが切れた時点で失敗します。
まずドライランで保持期間を定義する
borg pruneはアーカイブ履歴を破壊的に変更します。Borgのプルーニングのドキュメントでは、--dry-runと--listを使ってテストすることを強く推奨しています。
borg prune --dry-run --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repo1つのリポジトリに複数のマシンやデータセットのバックアップが含まれている場合、アーカイブフィルターは不可欠です。制限のないフィルターを使用すると、Borg 1.4はリポジトリ内のすべてのアーカイブを同じ保持ルールの対象候補として扱います。
バックアップ成功後にのみプルーニングを実行する
#!/bin/sh
set -eu
REPO=/mnt/backup/borg-repo
ARCHIVE='{hostname}-{now:%Y-%m-%d_%H-%M}'
borg create --stats "$REPO::$ARCHIVE" /srv/data
borg prune --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' "$REPO"スケジューラーが起動したから prune するのではなく、新しいバックアップが正常に完了し、保持ポリシーがすでに検証済みの場合に prune してください。
prune してもすぐに空き容量が増えない理由を理解する
Borg 1.2以降、compact は通常のリポジトリ書き込みコマンドから分離されています。Borg のcompact 分離に関する注記では、アーカイブを削除または prune しても、リポジトリのディスク容量がすぐにすべて回収されるわけではないことが説明されています。
borg create
|
新しいアーカイブをコミット
|
borg prune
|
保持対象から古いアーカイブを削除
|
borg compact
|
未使用セグメントの空き容量を回収これはスケジュール設定に役立ちます。毎日のバックアップで、部分的に使用されたリポジトリセグメントを書き換えるための全コストを負担する必要がなくなるためです。
prune よりも compact の実行頻度を下げる
- backup: 毎晩実行;
- prune: バックアップが成功するたび、または週に数回実行;
- compact: 週に1回、負荷の少ない時間帯に実行;
- 完全なリポジトリチェック: より頻度の低い別スケジュールで実行します。
# 毎日のバックアップ + prune
0 1 * * * /usr/local/sbin/borg-backup
# 毎週の compact
0 4 * * 0 /usr/local/sbin/borg-compactバックアップが数時間にわたって実行されることが多い場合は、compact の実行間隔をさらに空けるか、明示的な依存関係を持つタイマーを使用します。
最大限の書き換えを強制する前に、デフォルトの compact しきい値を使用する
現在のcompact ドキュメントでは、デフォルトで10%のしきい値が使用されています。
borg compact --progress /mnt/backup/borg-repoメンテナンス時間を短くすることを優先する場合、このデフォルト値から始めるのが適切です。自動的に次を使用するのは避けてください。 --threshold 0空き容量を少しでも確保できるたびに書き換えるため、大規模なリポジトリでは大幅に時間がかかる場合があります。
メンテナンスが次回のバックアップと衝突するのを防ぐ
ジョブが別の Borg プロセスを待つことが正当な場合は、待機時間に上限を設定したロック待機を指定します。
borg --lock-wait 1800 create /mnt/backup/borg-repo::'{hostname}-{now}' /srv/data適切なスケジューリングの代わりに、非常に長いロック待機時間を設定しないでください。バックアップが実際に開始・終了する時刻を監視してください。
複数のクライアントで1つのリポジトリを共有している場合は、スケジュールをずらしてください。BorgのFAQでは、クライアント間の重複排除が重要でない場合、複数のリポジトリによってロック競合を減らせると説明されています。
レポートがpruneを遅延させている場合はQuick Statsを使う
Borg 1.4.5で追加 --quick-stats 作成、削除、pruneを実行し、必要でない場合は低速なリポジトリ全体の統計取得を避けます。
borg prune --quick-stats --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repocompactが必要になる前に空き容量を確保する
リポジトリのファイルシステムの空き容量がゼロになるまで待たないでください。完全に容量が埋まったファイルシステムでは、Borgは通常のリポジトリ書き込み処理を確実に実行できません。
df -h /mnt/backup
borg info /mnt/backup/borg-repoより広範なNASバックアップ計画については、ZimaOSの3-2-1バックアップガイドが、リポジトリの保持はバックアップ設計の一層にすぎないことを思い出させてくれます。
スケジュールを信頼する前に検証する
- すべてのバックアップで新しいアーカイブが作成されましたか？
- pruneはバックアップの成功後にのみ実行されましたか？
- 保持セットはドライランの計画と一致しましたか？
- 週次のcompactは次のバックアップ前に完了しましたか？
- compactの後に空き容量が増えましたか？
- いずれかのジョブで、Borgのロック解除待ちに予想外の時間がかかりましたか？
compactが次のバックアップと繰り返し重なる場合は、compactの実行頻度を下げ、デフォルトのしきい値を維持し、compactをより空いている時間帯に移動するか、関係のないワークロードを別々のリポジトリに分けてください。
低ギャップのBorgメンテナンスパターン
毎日
01:00 borg create
|
+-- 成功 --> borg prune
|
+-- 失敗 --> 古いアーカイブを保持し、警告
毎週
04:00 borg compact
定期
borg check
選択したファイルを復元テスト基本ルールはシンプルです。pruneは保持ポリシーを守り、compactはストレージを回収します。両者を同じ頻度で実行する必要はありません。
おすすめ商品
サポートとヒント
もっと読む
Home AssistantはWi-Fiでは動作するが、イーサネットまたはVPNでは接続できない
各ネットワーク経路を個別にテストし、インターフェースとルーティングの状態を確認して、直接IP接続と検出による接続を区別したうえで、失敗したレイヤーだけを修復します。
保護されていないデータを残さずにHome Assistantを廃止する方法
交換またはアーカイブを証明し、すべての信頼パスを無効化し、データを保持する各デバイスをサニタイズして、文書化された保護済みのリカバリコピーのみを保持する。
ホームサーバー上のHome Assistantで自動更新を利用すべきですか？
家庭への影響、互換性リスク、観察期間、復旧準備の状況を考慮して、手動更新、通知のみ、または段階的な自動更新を選択してください。
