サーバーがデータを失う理由はさまざまです。誤削除、アップグレードの失敗、侵入、ディスク障害。確実な保険はバックアップだけです。本記事では簡単なものから徹底したものまで 3 つの層を示します。必要に応じて選んでください。

第 1 層：プラットフォームのスナップショット（最も手軽）

スナップショットはディスク全体をある時点で撮った「写真」で、復元すればマシン全体がその瞬間に戻ります。OS のアップグレードや主要設定の変更など大きな作業の前に手動で 1 枚取る、あるいは週次で自動保持するのに向いています。利点は復元が完全で操作が簡単なこと、欠点は粒度が粗く単一ファイルだけを戻せないことです。ご利用プランでのスナップショット対応は 00Shark サポートにご確認ください。

第 2 層：ファイルとデータベースの定期バックアップ

cron で重要データを毎日アーカイブします。最小限で実用的な構成は次のとおりです。

  • サイトファイル：tar でウェブルートをアーカイブする；
  • データベース：mysqldump でエクスポートする（データベースのファイルを直接コピーするより安全）；
  • 直近 7 日分を保持し、それ以前は自動削除してバックアップでディスクを埋めない。

aaPanel を使う場合は「Cron」ページで同じ処理を画面上から設定でき、スクリプトを書く必要はありません。

第 3 層：オフサイトバックアップ（大規模障害への備え）

同じサーバー上のバックアップはディスクとともに失われます。オフサイトへ同期して初めて計画が完成します。rsync で別の VPS へ送る、あるいは rclone でオブジェクトストレージやクラウドドライブへ送ります。3-2-1 の原則を守ってください。コピー 3 つ、媒体 2 種類、オフサイト 1 つです。

最も飛ばされがちな工程：復元演習

復元したことのないバックアップはバックアップではありません。四半期に一度、アーカイブをテスト用ディレクトリに展開し、データベースのダンプを一時データベースに取り込んで、データが無事か確認してください。実際に事故が起きて初めて、バックアップスクリプトが何か月も前から静かに失敗していたと気づく人は少なくありません。