個人開発では、バックアップを取っているつもりで安心している人が多いと思います。ただ、取っただけで戻せるかどうかは、実際にやってみないと分かりません。一度復元を試し、その手順を記録しておく方法をまとめました。
バックアップの対象を書き出す
ソースコード、データベース、設定ファイル、鍵や証明書など、失うと困るものを一覧にします。対象を洗い出すだけで、取り忘れていたものに気づくことがあります。
保存先と取得の頻度を横に並べる
各対象について、どこに、どのくらいの間隔で保存しているかを一行で書きます。保存先が本体と同じ場所にあるものは、印を付けておきます。クラウドの同期は、バックアップとは別物として扱うほうが、誤解が起きにくくなります。
復元を試す場所を本番とは別に用意する
復元の練習は、本番の環境ではなく、別のフォルダや仮の環境で行います。壊れても困らない場所でやれば、手順を落ち着いて確かめられます。試す前に、本番のデータを上書きしない設定になっているかを、一度確認します。
やった操作を一行ずつ書き取る
復元のとき実際に打ったコマンドや、開いた画面を順に書き取ります。記憶に頼らず、その場で書くのがコツです。つまずいた箇所も、そのまま残します。画面の録画やターミナルの履歴を併用すると、書き漏れを減らせます。
戻せなかったものと原因を記録する
復元できなかったファイルや、欠けていたデータがあれば、原因の推測と一緒に書きます。見つかった穴は、次回のバックアップ方法を直す材料になります。失敗の記録は、責める材料ではなく、次の改善点の一覧として扱います。
かかった時間を測っておく
復元に何分、何時間かかったかを書いておきます。障害が起きたときに、どのくらいで元に戻せるかを見積もる目安になります。手順のどこで時間を取られたかも、一緒に書いておくと見直しやすくなります。
次に試す時期を決めてカレンダーに入れる
復元の確認は、一度で終わりではありません。環境や構成が変わるので、半年後などに次の日を決めて予定に入れます。日付があるだけで、先送りしにくくなります。
取った手順の記録は、将来の自分や引き継ぐ人への手紙にもなります。個人開発の取り組みについては、Burning Tribeでも紹介しています。