自宅サーバ移設でバックアップが停止：完了条件を見直した初日

深夜00:16、自宅で回している自動処理・定期ジョブの移設は切り替わりました。専用機へ移した先は動いており、その時点では大きな異常も見えていませんでした。

ところが翌日、バックアップの最後の成功が移設前日の12:35で止まっていることに気づきました。それ以降の3回は、すべて「そこはマウントポイントではない」というエラーで失敗していました。移設と同じ操作で、共有ストレージを指すマウントが構成から外れたと推定しています。意図的に削除した記録はありません。

今回から始める移設ログは、完成した構築記ではありません。判断がまだ途中のものも、そのまま記録します。新しい環境が動いたことと、古い環境で止まったものを観測できていることは、別の確認項目です。

バックアップは、正しく失敗して止まっていた

失敗したバックアップは、安全弁によって未マウントのローカルディスクへの書き込みを止めていました。空のバックアップで既存の正常な世代を上書きすることもありませんでした。

これは困る失敗ではありますが、壊れ方としては正しいものでした。行き先が確認できないなら処理を止める。バックアップでは、この停止が最後の防波堤になります。

同じように、失敗が成功に見えるケースは以前にも扱いました。連続SKIPが成功に見えてしまう失敗の型と同様に、処理が静かに止まっても、必要になる日まで被害は表面化しません。

移設中に走った回は途中で中断され、転送用の作業ディレクトリだけが残りました。少なくとも、半端な成果物をバックアップとして確定させる事態は避けられました。

同じ移設で、別の処理は行き先を失ったまま動いていた

一方で、すべての処理に同じ安全弁があったわけではありません。別の処理は、未マウントのパスへ約1.3MBをローカルに書き続けていました。この書き込みは、マウントが外れる前日から続いていました。

こちらは停止せず、動いているように見えます。ただし本来の共有ストレージには届いていません。安全弁のあるバックアップは「失敗して止まった」。安全弁のない処理は「動いているつもりで行き先を失った」。同じマウント外れでも、検出のされ方は正反対でした。

移設後の確認で数えるべきなのは、新しい環境で起動した処理だけではありません。バックアップ、退避、世代管理のように、止まっても当日は困らない処理が、以前どおり完了しているかを確認する必要があります。

応急の退避と、恒久対応は分ける

発見したその日のうちに、新しい機から旧環境のファイルを読み、別筐体へ退避アーカイブを1本作成しました。サイズは9.2GiBです。圧縮検査を通し、469,930エントリの一覧と主要ディレクトリの存在も確認しました。

「アーカイブを作成できた」だけでは、退避完了とは言いにくいものです。最低限、読めること、想定した規模であること、必要な場所が含まれることまで確認しました。バックアップを持つ理由そのものは、データ全損経験から始めた3-2-1バックアップの記録にもつながっています。

恒久対応では、旧環境のマウントを直す選択ではなく、新環境が同じ仕事を引き取る選択をしました。旧環境は畳む予定であり、そこを直しても移設後に捨てる資産を増やすだけになるためです。旧環境側には手を加えません。

応急対応は、今あるデータを安全な場所へ置くことです。恒久対応は、次回から同じ仕事をどこで担うかを決めることです。この二つを混ぜると、復旧した安心感だけが残り、引き継ぎ漏れを見落としやすくなります。

移設中は、消さない側に倒す

世代の削除は既定で無効にしました。超過分は毎回ログに列挙するだけで、自動では削除しません。

消す操作は取り消せません。移設直後は、どの処理がどこまで引き継がれ、どこに欠損があるのかという判断材料が不足しています。この期間だけでも削除を止めておけば、容量の問題は残りますが、復旧の選択肢まで失うことは避けられます。

サーバ移行の完了条件は、まだ決め直している途中です

今回の切替は00:16に成功しました。しかし、バックアップは移設前日の12:35を最後に止まり、翌日まで気づけませんでした。

引越しは、移した先ではなく移した元を静かに壊します。

この回で出せる結論は、ここまでです。移設の完了条件を「新しい方が動いた」に置くと、止まった側は誰にも観測されません。何も起きない種類の処理が止まったことを、どうすれば当日に気づけるのか。その答えはまだ解けていません。

暫定的に、引き継ぐ仕事は新環境が担うこと、取り消せない操作は移設中は既定で止めることを決めました。次回は、移設済みの処理が旧環境でも動き続け、同じ仕事が二重に走った件を扱います。壊れ方を見つけるたびに、移設の完了条件を増やしていく予定です。