バックアップと復元を小さく仕組み化する
個人開発で本当に取り返しがつかないのは、コードの失敗ではなくデータの消失です。コードは書き直せますが、利用者が積み上げたデータは戻せません。そして事故は、操作ミス、削除処理の不具合、サービスの障害や解約忘れといった、ありふれた形でやってきます。
この記事では、個人開発の規模に合った、続けられるバックアップと復元の仕組みを整理します。
守るものを3種類に分ける
まず、自分のサービスの何を守るのかを書き出します。多くの場合、次の3種類に分かれます。
コード：GitHubなどのリモートリポジトリに置いてあれば、それ自体が複製になっています。手元のパソコンにしかないコードをなくすことが、まず避けるべき事故です
データベース：利用者の登録情報や投稿など、サービスの本体です。最優先で守ります
「これを失ったらサービスを続けられるか」で優先順位を付けると、守る対象が明確になります。秘密情報そのものの控えは個人開発の秘密情報を安全に管理するの方針に従い、バックアップとは別の安全な場所に保管します。
別の場所に、自動で、複数世代
バックアップの置き方には定番の考え方があります。
別の場所に置く：本番と同じサービス、同じサーバーの中だけに置いたバックアップは、そのサービスの障害や解約と一緒に消えます。少なくとも一つは別の場所に置きます
自動で取る：手動のバックアップは必ず忘れます。マネージドのデータベースなら自動バックアップ機能を有効にし、ない場合は定期実行の仕組みで書き出します
複数世代を残す：最新の1つだけだと、「壊れたデータで上書きされた」ときに戻れません。日次で数日分など、時間をさかのぼれる形にします
GitHubのリポジトリについても、リモートにあるから絶対安全と考えず、必要ならローカルへの複製やアーカイブの書き出しで手元にも控えを持てます。
復元できて初めてバックアップと呼べる
最も多い失敗は、「バックアップは取っていたが、復元したことが一度もなく、いざというとき戻せなかった」です。
バックアップファイルから、本番とは別の環境にデータを復元してみます
復元したデータでアプリが動くか、件数や中身が合っているかを確認します
復元にかかった時間と手順をメモに残します
この一周を、仕組みを作ったときに一度、その後は数か月に一度行います。手順のメモがあれば、事故当日に慌てて調べずに済みます。
事故のときの順番を決めておく
データの事故が起きたときの行動を、先に3行で決めておきます。
まず被害を広げない（書き込みを止める、メンテナンス表示を出す）
最新の正常なバックアップを特定する
手順メモに従って復元し、利用者に状況を告知する
告知の文面や経路は更新を伝え続ける仕組みをつくるで用意した経路が使えます。障害対応を含む日々の運用リズムは公開後30日を無理なく運用するで整理しています。
最小のバックアップチェック
[ ] コードがリモートリポジトリにある
[ ] データベースの自動バックアップが有効
[ ] バックアップが本番と別の場所にもある
[ ] 複数世代が残る設定になっている
[ ] 復元を一度実際に試した
[ ] 復元手順のメモがある
[ ] 環境変数と外部サービス設定の一覧がある全部そろっていなくても、上から順に一つずつ埋めれば、そのぶんだけ取り返しのつかない事故が減ります。
次に読む記事
削除処理そのものの安全性は個人開発のセキュリティを最初の一歩から固めるで扱っています。サービスをたたむときのデータの扱いは個人開発サービスの終わらせ方を決めておくで整理しています。