サーバーを運用したことのある人なら、ほぼ誰もが同じ話を聞いたか経験しています。打ち間違えたコマンド、ディレクトリを見誤った削除、本番のデータベースを上書きした移行スクリプト——数秒で数年分のデータが消えます。「肝を冷やしただけ」と「壊滅」を分けるのは運ではなく、使えるバックアップがあるかどうかです。

まずスナップショットとバックアップを区別する

スナップショットを取っていれば安心だと考える人は多いのですが、両者の役割は異なります。

  • スナップショット：ある時点の機械全体の複製で、復元が速く、システムの更新や大きな変更の前の「取り消し」に向きます。ただし通常はインスタンスと同じ基盤上に置かれ、粒度が粗いため単一のファイルを取り戻すのには向きません。
  • バックアップ：ファイル単位の複製で、別の場所に保管でき、履歴を複数世代持てます。誤削除、破損、身代金要求型の攻撃に備えるのはこちらです。

結論は両方必要で、互いの代わりにはならないということです。

3-2-1 の原則は今も最も実用的な枠組み

  • データを 3 つ：本番のデータに加えてバックアップを 2 つ。
  • 媒体か場所を 2 種類：バックアップを元データと同じ機械、同じディスクに置かないこと。
  • 1 つは別の場所へ：少なくとも 1 つは別の事業者か別の地域に置き、単一の障害やアカウントの問題ですべてを失わないようにします。

実際の進め方

  • データベースは論理バックアップで別に取る：データのディレクトリをそのまま複製すると、しばしば不整合な状態を掴みます。mysqldump や pg_dump などで論理的に書き出し、圧縮して保管してください。
  • 増分バックアップの道具を使う：restic や borg は重複排除、増分、暗号化に対応し、多数の世代を長く保つ際の容量の負担が、毎日の完全複製よりはるかに軽くなります。
  • 定期実行で自動化する：cron か systemd のタイマーで毎日走らせます。手作業のバックアップは必ず忘れられます。
  • 別の場所へ送る前に暗号化する：バックアップには利用者のデータや資格情報が含まれがちです。オブジェクトストレージへ上げる前に必ず暗号化してください。
  • 保持の方針を決める：たとえば日次を 7 日、週次を 4 週、月次を 6 か月。保管容量が際限なく膨らむのを防ぎます。
  • バックアップの成功を監視する：静かに失敗している定期実行は、バックアップが無いことより危険です。あると思い込んでしまうからです。失敗には通知を付けてください。

最も重要な工程：復元の演習

ほとんどの人が飛ばし、しかし最も飛ばすべきでない部分です。復元の手順を一度も試していないバックアップは、バックアップではありません。四半期に一度、30 分を使って、使い捨てのインスタンスへ最新のバックアップを丸ごと戻してください。データが揃っているか、サービスが立ち上がるか、手順を覚えているかを確かめます。本当に必要になった日に欲しいのは、演習を経た手順であって、誰も開いたことのない書庫の山ではありません。

SharkCloud はインスタンスのスナップショットと柔軟な仕様に対応しており、復元の演習用に一時的なインスタンスをいつでも立てられます。「本当に取り戻せる」という確かさを、わずかな費用で手に入れられます。