やらかしちゃった ときのテッパンネタといえば「削除してしまった」。
crontab database ～君がしでかしてくれたもの～ から、
今年は ホスティングサーバの/binディレクトリをrm -rfしてしまったおじさんの昔話
本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話
管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 がなかなか胃に来る。
結論：手段はある
しかし、人類は努力してきたのだ。がこの記事の結論です。
**「履歴」**の話です。誤削除にまつわる人類の工夫の足跡、安全な設計を考えたい人のヒントになるかもしれない。
序：消したくないのに消えるものと戦ってきた人々
GoogleDriveのファイルがなくなる...
ざっくり、ファイルの権限手続きに伴いアクセスが不穏になる話というのがあります。
退職者アカウントを削除するときです。
アカウントを削除する際には、そのユーザが所有しているファイル等を他のユーザに譲渡するか確認されます。
ここで共有されているファイルがあるにもかかわらず、権限譲渡を行わないままユーザを削除すると悲劇が起きます。該当ファイルを使用していた他のメンバーからファイルがキレイになくなります。
消すつもりはないのに消えたCtrl+Z...
Windowsにも、欠陥と言われる動作があります。
Windows 10の「Ctrl＋Z」にご用心 コピーしたファイルを編集してから押すと無警告で“完全削除”される、windows10 エクスプローラーの欠陥について。Ctrl+Z → Ctrl+Y でデータ消失
以下の手順を踏んだ際に発生します。
ファイルをコピーする
コピーしたファイルを編集する
編集したファイルを上書き保存して終了する
エクスプローラ上で「Ctrl＋Z」をする
編集したファイルが消える
やってみたら確かに消えます。（笑い事ではない人すみません。）
DELETE FROM テーブル名...
なぜRDB（リレーショナルデータベース）は「DELETE FROM テーブル名」でうっかりwhere句をつけ忘れるとテーブルのデータが全削除されるような危ない仕様になっているのでしょうか？
...！？等という質問。
「それは『なぜUnix系OSはrootでrm -rf /とタイプするだけで惨劇が起きるような仕様なのでしょうか？』という質問と似ていますね。」ーーー。
むしろ全レコード削除はいいほうで、UPDATEでWHEREをつけ忘れても同じことが起きますが、こちらのほうがデータの一貫性が失われ、システムが動いている間にインシデントが起きると他のテーブルのデータにまでデータの汚染が波及する可能性があり、もっと悲惨です。
手動でのデータ変更はトラッキングできず、再現性がありません。
と回答されている。人々は間違えることはある。いやだからこそ、誤った行動を防ぐために人々は知恵を絞ってきた。
破：知恵、それは論理削除
人類は消しても消えないように工夫してきた。論理削除というやつです。
論理削除と物理削除
1分でわかる論理削除 -メリットとデメリットを考える-
削除機能の設計(物理削除とは/論理削除とは)
なぜ論理削除が必要なのか：
ユーザーからその存在を隠蔽したいが、データとしては残しておきたい （例えば、業務事情により当該データを使用禁止にしたいが、一時的なのですぐに元に戻せるようにしたい場合）
誤って削除した場合に備え、すぐにデータを復元できるようにしておきたい
一方で論理削除は人類には難しい：
バグを生み出す原因になる (例：WHERE句への論理削除フラグの付け忘れ)
データ量増大やそれに伴う検索性能の劣化 ※論理削除データが多い場合
つまり通常のデータ（未削除のデータ）と削除済みのデータが1つのテーブルに、たとえば履歴化されて混在するため、削除したデータ量が増えるとそれに伴い検索性能が劣化する。また不整合データを作成しないように履歴を壊さないように業務アプリ側も慎重に慎重に工夫しないと、また不具合となる。それだけ知恵を絞らないといけないことなのです。以下、事例。
ごみ箱への削除
Wikipedia「ごみ箱」：
ごみ箱が単なる削除と異なるのは、実際に削除されるまではファイルの削除を取りやめる事ができるという点である。これにより誤操作によるファイル消失を防ぐ事ができるほか、情報という目に見えないものを扱ったファイルを、実体を持った対象として認識させる心理的な作用も働く。また多くは ファイルアイコンをドラッグ操作でごみ箱へと移動するため、操作概念が明確で誤りが起こりにくい。
メールボックスなどでも、メールを削除したけど実際はユーザにも分かる形で移動しているので自分でも戻せる。更にGmail なら、ユーザーの完全に削除されたメールを復元する 事もできる。完全に消しているわけではない。
Windowsのごみ箱の実体 は「$Recycle.Bin」という特殊な仮想フォルダ。
何なら Windowsの「ごみ箱」を作業フォルダにしてる人がいる？ 意外な使い方がネットで話題に という、端的に「ごみ箱」を作業フォルダとしてすでに使う運用をしている者もいるようだ...。
消しても消えないようにできているのである。
削除後のUndo, ロールバック
なぜ私はVimを使い始めたのか：アンドゥ機能事始め
アンドゥの履歴をツリー状にかつ無制限に保存できる。
だけでなく「Windows更新プログラムの構成に失敗しました。変更を元に戻しています」って、これってMicrosoftのバグですか？ とても迷惑です…。 なんていうのを見ることがありますね。
Windows Updateやインストーラーの類が変更を元に戻すロールバックモードに入るということは、想定しなかった事態が起き、このまま進めることができない状態になったケースが大多数であると考えられます。
例えば、インストーラーが上書きしようとした新しいファイルが何らかの形でロックされていて上書きできなかった、ディスク容量が不足していた、ディスクやファイルが破損していた、インストーラーが削除しようとした古いモジュールが何らかの依存関係により削除できなかった、などというケースが多いと考えられます。
PCはなるべくきれいに使おう、に尽きるのだけど、そんな人を救う策としてロールバックの機構が装備されているとも思うところなのです。
アカウント削除後のアカウント
なぜSNSのアカウントを削除しても随分経った後に復元できてしまうのですか？これは削除したと言えるのでしょうか？
SNSも、過去アカウントは復活できるようになっているようだ。
Twitter アカウント復活のヘルプ
Facebook ログインできない古いFacebookアカウントの利用を再開するにはどうすればよいですか。
なぜかというとこれは上記Quora：
念の為、って感じだと僕は認識しています。
もしかしたら、アカウントを削除したユーザが問い合わせてきて、そのアカウントを復元させてくれと言いだすかもしれないですし、サービス内で統計情報などを作る際にも使われるかもしれません。
つまりサービス内でアカウントを削除したとしても、DB上から完全に削除されることは稀だということです。なるべくサーバーに負荷を与えず、処理を行うことを考えれば、DBから全てのデータを削除するのではなく、ある値（deleteDataとします）が0であれば、削除されていない状態、1であれば削除されている状態。
との回答。サーバに負荷を与えることなく、アカウントを使用できない状態にする。
なるほど中身はともあれアプリケーション設計上、一般的に行われているものとして想像がつきます。
削除後のFrashback query
さらにそんな開発者を救うことがある機構。冒頭に DELETE FROM テーブル名 の話題を出したが、それでもフラッシュバッククエリというものが効くことがある。
http://oracle-abc.myoa.info/flashback-query
SELECT * FROM テーブル名
AS OF TIMESTAMP TO_TIMESTAMP('2021-01-08 01:00:00', 'YYYY-MM-DD HH24:MI:SS');
SELECT * FROM テーブル名
AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '2' HOUR);
Postgresにも昔そのようなものがあったらしい。
https://dba.stackexchange.com/questions/359/what-other-databases-have-a-feature-similar-to-oracles-flashback-query/362#362
rm後の復元
削除したファイルをlsofで復元する
Linuxにて削除(rm)してしまったファイルを復元する【CentOS】
「今度は間違えないようにcpやらmvやらしてあげてくださいねー！」とあります。
ハードディスク内のデータを本当の意味で完全消去する方法 なんていうナレッジもある。
意外と、大概のものは消えない。
削除後のRevert
最後にお馴染みGitの例。削除しても削除したという履歴がむしろ残る。Revert。
【gitコマンド】いまさらのrevert
既存のコミットを取り消すためのコマンドです。
「取り消したいコミットを打ち消すようなコミットを新しく作成する」という処理によって、既存のコミットを取り消します。新しくコミットを追加しているだけなので、既存コミットの履歴が消えるわけではありません(コミットログをみると残っています)。
どんな変更があったのかということが(revertしたということも含めて)残るので、リモートにpushされて公開されているコミットに対しても安全に使うことができます。
テクニックは色々あります。
Gitでやらかした時に使える19個の奥義
git 上のいろんなことをなかったことにする
Gitで直前のコミットをなかったことにする
というかGitを領収書の管理で使いたいので税務署に電話してみた なんて人もいる...
そう。**「履歴」**こそ、人類が自らの誤削除と戦って編み出してきた知恵なのです。
急：結論
それでも消しちゃうのが人間ってもので、いやー、アプリケーション設計開発って本当に難しいですね～、という何ともな世間話的結論になってしまうのですが、エンジニアなら知っておきたい障害報告&再発防止策の考え方 もあるのでここでは以下引用。冒頭で紹介した管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 にはこんなことが書かれていました。
あわててはいけません。まずは落ち付きます。今なら「全集中、鯖の呼吸」とつぶやくべきところです。たぶんサーバと一体化し、最善の一手となるキーに一筋の光が見えます……（知らんけど）
最後の手段はある。これは気分として重要です。
うっかり削除と戦ってきた我々人類、最後の手段はあります。消した事実は消えないが、黙ってバックアップ（あるよね？）から復旧しよう。そしてよい再発防止策 を考えよう。参考まで良い再発防止策とは、
- その種類の問題について二度と意識することがなくなる解決策
- その種類の問題を開発時に自動的に検知することができる解決策
- その種類の問題が発生しても自動的に復旧することができる解決策
- その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策
消しても消えない安全なアプリケーション設計生活を祈りたい。
以上趣味による、削除と戦ってきた 履歴 設計事例まとめでした。