概要

データを維持広域に渡ってnukeしてしまったので、広範囲に影響が出る。

なにしたの

~/mntにSSHFS載せたままrm -r ~/*(#q^D)。

バックアップして、アンマウントし、削除という流れだったのだが、 バックアップ処理中にシャワーを浴びに行ってコンテキストがリセットされてしまったのが致命傷となった。

防げなかった?

ミスを完全に防ぐことは不可能なので、それについては除外するとすれば、基本的に消去されたデータはメインワークステーションのローカルに に保存されているデータである。 普段はグローバルストレージにバックアップされているが、現在はグローバルストレージが停止中であるためバックアップができなかった。

別ディスクへのバックアップそのものは検討されていたが、タイミングが悪かった。 8月以降は体制が変更されてバックアップされていないのも痛かった。

影響範囲

概況

比較的大きいデータは冗長化されたストレージ上にあるため、無事。 また、頻繁に触っているデータに関しても、複数のマシンでMercurialで共有されているから全滅ではない。 さらに、コード関連は 公開しているものに限り GitHubなどから書き戻せるため、こちらも全滅ではない。

SSH関連、パスワードマネジメント関連は無事だったため、最悪の自体は回避できている。

ただし、復元不可能な損失はかなり広範囲に渡って発生した。

ウェブ関連

完全に消失したのはHarukamy’s Memoranda及びReasonset。

それ以外に関しては主に7月下旬まで巻き戻った形になる。

どのサイトも原則として復旧するまで更新はできない。 ただ、ChienomiはWordPressであり、ソースデータを必要としない(そもそもソースデータによって生成することができない)ので、Chienomiは更新可能。

消失したサイトを含め、ビルド済みデータは存在しているため、復旧そのものは可能。 ただし、作業量としては非常に多いものとなり、時間がかかる。

また、更新に関しては更新する予定だった内容や草稿が消えてしまったため、出るはずだった原稿の中に消滅してしまうものが出るだろう。

Mimir Yokohama関連

一部のお客様は教材を損失する被害が出たものの、これらは全て私が書き直したので実質的影響はなし。

内部的に参照するデータ、特に10月での料金改定に関するドキュメントが失われたため、若干混乱があるかもしれない。

小説

最近人気を博している小説については、HEADが別のマシンにあるものであったため、影響は全くない。

コード

公開していないコードは 年単位での巻戻りである。

これはほとんどの人にとって影響がないが、これらの成果物を利用して開発・保守されているものには影響が出る。 (即座に影響が出るものは特にない)

また、内部的にテストしていたコードも失われたため、そのコードを求められた場合も出せなくなった。

全体

復旧作業が必要であること、作業環境が損壊したことなどから請け負える作業量は低下する。

教訓として

事故リスクを低減する方法がなかったかについては、後の祭りではあるが、以下のようなことが考えられる。

rmのエイリアス

alias rm="rm --one-file-system"

というのは現実的で良い方法だと思う。

rmのacross filesystemな事故は今回に限らず何度もやっているし、そうあってほしいケースはだいぶ少ない。

もしくは、いっそ~/binなどをシェルスクリプトにして置き換えてしまってもいい。 それならsudoでの事故も減る。

マウントディレクトリのベースディレクトリの書き込み禁止

mkdir ~/mnt
mkdir ~/mnt/point
sudo chown root:root ~/mnt

という話だが、これはうまくいかない。 rmの再帰は先にあるファイルを順に消していくためエラーにならないからだ。

readonlyマウント

読み込み専用でマウントする、という方法は有効でありそうに思えるけれども、今回の場合書き込みを目的としていたため不可。

マウントポイントを外に出す

今回の場合、バックアップ対象がマウントポイントを内包するため、このように処理しようかと考えたものの、FUSEであったためこのようにしなかった。

これは大きな間違いであった。そもそもSSHFSでマウントする必然性に乏しく、全面的にrsyncで処理すべきだったし、作業的にファイルシステムダンプも行われる予定だったからSSHFSを使用した処理そのもの、そしてそれが適切でないと気づいたときに直ちにアンマウントしなかったことが今回の敗因だと言える。