徹夜明けで意識が朦朧とした先日の朝、テストサーバー上で開発中のデータを本番サーバーに展開しようとして、rsync の方向を間違えた。開発中データ展開時の作業は、プロジェクトごとに異なる点が多い。スクリプト化してもあまり汎用性がないため、手動でやっていたのがマズかった。そのとき rsync に付加していたオプションは "-av --delete --force"。地道に進めていた作業が全てビットの闇に葬り去られ、しかも何が削除されて何が古いデータで上書きされたのかを、これ見よがしに見せ付けられる羽目になった。背筋が寒くなる瞬間だ。(※ rsync は方向に注意！)
しかし我が家のファイルサーバーでは、毎日早朝に dar で週 1回の完全バックアップ、毎日複数回の増分バックアップを自動実施している。最後のバックアップから 「やっちまった」瞬間までのデータは諦めるしかないが、幸いにして最後のバックアップからの経過時間が比較的短く、被害は軽微。固まったのも数秒ですぐに落ち着きを取り戻し、バックアップ・データからリストアして事なきを得た。重要なデータのバックアップの頻度は、(バックアップ作成中の負荷を見ながら) 少々偏執的なくらいにしておいた方が、こう言うときは役に立つ。
定期的なバックアップが重要なのは当然だが、自動化されていないと、せっかくのバックアップ・データもいざと言うときに使えない可能性がある。特に今回のようなオペレーション・ミスの場合、最も重要なのはバックアップ・データの鮮度。いつ発生するかわからない 「万が一」のそのとき、バックアップ・データが古くて役に立たない (存在しないのは論外)、と言う悲劇は避けたいものだ。またバックアップの際は、Linux の LVM や Windows Server の VSS のようにファイルシステムより下のレイヤーやファイルシステム自体でスナップショットやそれに類する機能が使えると、利便性が高い。
ちなみに全ての仮想サーバーのバックアップも、停止、コールド・バックアップ、起動を順番に繰り返すスクリプトで完全自動化済みだ。クラスタリングしてある仮想サーバーをバックアップのために停止させる際、相棒が何らかの理由で動作していない場合はまず相棒の起動を試み、重要度の高いサービスが極力途切れないようにしている。
この rsync 事故の後、すかさず 「テストサーバー」→「本番サーバー」 のデータ展開用スクリプトを書いたことは言うまでもない。
