古いように見えるからといって、Btrfsのsend親を削除しないでください。まず、新しい読み取り専用スナップショットが送信元と送信先の両方に存在し、次の増分サイクルに利用できることを確認します。
ホームNASでは、送信元と送信先のスナップショットが似た名前を持っていても、レプリケーションにおける役割が異なることがよくあります。ローテーションジョブがスナップショットの経過時間だけを見て、次の送信の基点となるペアを識別しない場合、クリーンアップは危険になります。まず読み取り専用の一覧を作成し、最後に成功した送信元と送信先のペアを特定して、それを基点に新しい子スナップショットをテストします。その後、別の増分受信が完了するまで、以前の送信先スナップショットを保持してください。
両方のシステムで現在の親ペアを一覧化する
送信元のサブボリューム、すべての読み取り専用sendスナップショット、そして受信先にあるすべての受信済みスナップショットを一覧表示します。パス、作成時刻、読み取り専用状態、サブボリュームID、UUID、親子関係、および利用可能であれば受信時の識別情報を記録します。最後に成功した送信元スナップショットと、実際に受信されたコピーを対応付けてください。名前が似ているだけのディレクトリを対応付けてはいけません。
正常に動作するBtrfsのsendおよびreceiveシーケンスでは、次の増分ストリームの親として使用する前に、以前のスナップショットを両方のシステムで利用できる状態に保ちます。
ペアが明確に存在し、読み取り専用である場合は、保護対象としてマークします。名前だけが一致している場合は、続行する前に受信時の関係とレプリケーションログを確認します。送信先のコピーが存在しない場合は、クリーンアップを中止し、新しいフル送信または別の検証済みベースを計画してください。送信元のスナップショットを削除しても、受信先の失われた履歴を修復することはできません。
新しいスナップショットを次の親にできることを確認する
一覧の保存後に、次の読み取り専用送信元スナップショットを作成します。保護対象の送信元スナップショットを明示的な親として指定し、新しい子スナップショットを意図した送信先またはステージングパスに送信します。終了ステータスとログを保存し、受信したスナップショット上で変更されたファイルと変更されていないファイルをサンプル比較します。
増分レプリケーションスクリプトでは、依存関係を明確にする必要があります。実用的なスナップショットローテーションワークフローは、sendロジックが想定するスナップショットが所定の場所に残っている場合にのみ機能します。
受信が成功し、送信先のスナップショットを読み取れることを確認してから、新しいペアをクリーンアップ候補に昇格させます。親が見つからないというエラー、書き込み可能な送信元スナップショット、誤ったデータセット、またはストリームが予想外にフルコピーと同等になった場合は、テストに失敗しています。パスを修正するかベースを再構築する間、古いペアには手を加えないでください。
親の役割が先に進んだ後でのみクリーンアップする
何かを削除する前に、保持記録を更新します。新たに検証した送信元と送信先のスナップショットをアクティブなペアとしてマークし、直前のペアを短期的なフォールバックとして保持します。そのうえで、クリーンアップジョブが削除する予定の古いスナップショットをプレビューします。プレビューには、次の送信または復元計画で不要になった祖先だけが含まれている必要があります。
ファイルの変更は新しいスナップショットに引き継ぎ、既存のベースから送信できます。そのため、将来の増分履歴は、古い読み取り専用スナップショットを編集することではなく、保持されたスナップショットの関係に依存します。
アクティブな親、フォールバックペア、最新の受信済みスナップショット、または未検証の孤立スナップショットが削除対象に含まれている場合は、クリーンアップを中止します。スナップショットは少数ずつ削除し、各グループの削除後に両方のシステムを再度一覧表示します。送信元と送信先の個別のローテーションジョブが、同じ保護ペア記録を共有せずに独立して進まないようにしてください。
フォールバックを廃止する前に、次の増分サイクルを実行する
クリーンアップ後、制御したファイル変更を1つ加えて、新しい読み取り専用スナップショットを作成します。新たに昇格した親から、次の増分送信を実行します。この2回目のサイクルによって、クリーンアップ記録、スクリプト、送信先の状態がすべて一致していることを確認できます。最初の送信が成功しただけでは、クリーンアップ後の環境はテストできていません。
スナップショットが使用中のため削除できない場合は、親の対応付けが間違っていると判断する前に、アクティブなBtrfs送信パスから保持ロジックを切り分けてください。
2番目の子スナップショットが正常に受信され、想定したファイルが存在し、アクティブなペアが読み取り専用のままで、次回のスケジュール実行で自動的にそのペアが選択されれば、チェックリストは合格です。その結果を確認してから、フォールバックを廃止してください。次の送信で親が見つからない、誤ったサブボリュームが対象になる、または予期しないフル転送が提案される場合は、停止して以前のペアを保護対象に戻します。
サポートとヒント
もっと読む

ロックの競合を避けて Restic のバックアップ、Forget、Prune ジョブをスケジュールする方法
頻繁なバックアップ、対象を限定した保持、物理的なプルーニング、チェック、再試行、リストア検証を分離した、完全なマルチホスト対応Resticスケジュール。

Resticのプルーニングジョブによってスケジュール済みバックアップがブロックされるのを防ぐ方法
共有Resticリポジトリ向けの予防計画。バックアップの実行時間帯とプルーンを分離し、ロック、再試行、アラートを維持します。

アクティブなバックアップを中断せずに古いResticロックを解除する方法
アクティブなバックアップを保護し、古い状態のみを削除して、通常のスケジュールで復旧を確認する、影響を最小限に抑えたResticのロック解除ワークフロー。

