中断されたプルーニング後に重複排除バックアップリポジトリが読み取り専用になるのはなぜですか？
中断されたプルーン処理の後に、排他的ロック、ストレージエラー、イミュータブルなバックエンド、または不完全なメンテナンス状態によって変更が妨げられると、リポジトリが読み取り専用になることがあります。
「読み取り専用」は、ファイルシステムの実際のマウントモードではなく、バックアップクライアントの安全対策による応答である場合があります。キャンセルされたプルーン処理によって、排他的ロック、未完了のパックまたはインデックス処理、クリーンアップ用ワークスペースの不足、あるいは読み取りは許可するものの削除を拒否するバックエンド操作が残ることがあります。一方、I/Oエラーや整合性エラーの後に、OSがリポジトリのファイルシステムを読み取り専用で再マウントする場合もあります。ロックを削除したりプルーンを再実行したりする前に、最初の書き込みを拒否している層を特定してください。
読み取り専用を報告した最初の操作を記録する
リポジトリの一覧コマンドを実行し、続けて非破壊のチェックを1つ実行して、クライアント、バックエンド、オペレーティングシステムのログに記録された最初のエラーを保存します。
Resticのドキュメントでは、プルーンはリポジトリデータを書き換える処理であり、参照されていないコンテンツを削除したり、部分的に使用されたファイルを再パックしたりするため、排他的アクセスが必要だと説明されています。
一覧表示はできるのに、ロックの作成やメタデータの書き込みを伴うすべての操作が失敗する場合は、古いロック、バックエンドの書き込み権限、オブジェクト保持設定を切り分けてください。
中断されたプルーン処理が残した排他的ロックを確認する
バックアップツールでリポジトリのロックを一覧表示し、各ロックを所有するホスト、プロセス、作成時刻、コマンドを確認します。
Borgのドキュメントでは、リポジトリを変更するコマンドが同時書き込みを防ぐためにリポジトリロックを使用すると説明されており、実行中のロックを解除するとリポジトリの状態が損なわれる可能性があると警告しています。
古いロックは、所有者が確実に終了していることを確認したうえで、サポートされているコマンドからのみ削除してください。
ファイルシステムが読み取り専用で再マウントされたか確認する
マウントテーブル、カーネルログ、ファイルシステムの健全性、ストレージプールの状態、最近のUSB、SATA、ネットワーク、コントローラーのエラーを確認します。
Linuxのext4ドキュメントでは、errors=remount-roを安全対策として挙げています。これは、ストレージ障害によってリポジトリが本当に読み取り専用になる仕組みを示しています。
ハードウェアまたはファイルシステムのエラーが続いている間は、読み書き可能な状態への再マウントを強制しないでください。ログを保存し、まずストレージを修復してください。
途中まで進んだプルーン、コンパクト、インデックスの状態を調べる
どの段階で中断されたかを特定します。期限切れスナップショットの選択、参照の削除、データの再パック、インデックスの再構築、メタデータのコミットのいずれかです。
Borgのプルーンリファレンスでは、プルーンとコンパクトは別の手順であると説明されています。そのため、アーカイブが有効なまま、容量回収だけが完了していない場合があります。
別の破壊的な処理を実行する前に、リポジトリのチェックコマンドを使用してください。パック、インデックス、セグメントを手動で削除してはいけません。
オブジェクトロック、イミュータビリティ、バックエンド認証情報を確認する
クラウドリポジトリでは、オブジェクト保持、リーガルホールド、バケットポリシー、バージョニング、削除権限、認証情報のローテーションを確認します。
AWSは、S3 Object Lockによって保護された保持期間中の削除や上書きが防止されると説明しています。そのため、読み取りはできてもプルーンが失敗することがあります。
プルーンを成功させるためだけに、イミュータブルな保持設定を弱めないでください。バックアップツールがサポートするリポジトリ設計を使用してください。
空き容量、inode、プルーン用ワークスペースを確認する
ファイルシステムのバイト容量、inode、クォータ、スナップショット用の予約容量、一時ディレクトリ、オブジェクトストアの上限、ローカルキャッシュの空き容量を確認します。
GNU Coreutilsでは、dfでブロックとinodeの使用量を確認できると説明されています。これにより、ファイルシステム全体の容量不足なのか、リポジトリレベルのロックまたは権限エラーなのかを切り分けられます。
ファイルシステムが満杯の場合は、リポジトリオブジェクトを削除するのではなく、一時的な容量を追加するか、検証済みの無関係なデータを削除してください。
チェック、ロック解除、管理されたメンテナンス実行で復旧する
最後に正常だった復元ポイントを保護し、スケジュールを停止して、サポートされているチェックを実行します。確実に古いロックだと確認できた場合のみロックを解除し、ログを記録しながらメンテナンスを1回だけ実行してください。
ZimaSpaceの容量が満杯になったバックアップ先の復旧ガイドでは、関連する原則として、リポジトリを個別のファイルの集合ではなく、管理対象の構造として扱うよう説明しています。
一覧表示、チェック、バックアップ、保持処理、テスト復元がすべて、強制的なロック解除や手動削除なしで成功すれば、問題は解決しています。
よくある質問
ロックファイルを手動で削除してもよいですか？
最初に行うべきではありません。ロックを所有するプロセスが存在しないことを確認し、バックアップツールがサポートするロック解除操作を使用してください。
クラッシュ後、すぐにプルーンを再実行すべきですか？
いいえ。別の破壊的なメンテナンスを実行する前に、リポジトリ、インデックス、ファイルシステム、バックエンドの健全性を確認してください。
読み取り専用になるということは、バックアップデータが安全だという意味ですか？
必ずしもそうではありません。パックの欠落、ストレージエラー、イミュータブルなオブジェクト、不完全なインデックスによって、復元が妨げられることもあります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
