選ぶ知識を、あなたの力に。
当サイトはプロモーションを含みます
記事一覧へVPS

VPSのバックアップ方法|スナップショット・ファイル・DBの使い分け

公開 2026.09.12 約10分
VPSから複数の保存先へバックアップするイメージ

VPSのスナップショット、ファイル、データベースのバックアップ方法と、世代管理・暗号化・復元テストを解説します。

VPSのバックアップは、管理画面でスナップショットを1つ作るだけでは不十分です。OS全体を戻すスナップショット、日々のファイル、整合性を保ったデータベースを組み合わせ、VPSとは別の場所へ保存します。

重要なのは取得回数ではなく、「いつの状態まで戻せるか」と「何時間で復旧できるか」です。復旧目標を先に決めると、必要な頻度と保存世代を選べます。

バックアップ設計の結論

小規模なWebサイトでも、次の3層が基本です。

横にスクロールできます →
対象用途
スナップショットOS・ディスク全体更新失敗、構成変更から素早く戻す
ファイルバックアップ設定、画像、アプリファイル単位の復元、別VPSへの移行
DBバックアップMySQL・MariaDBなど記事・ユーザー・取引データを整合した状態で戻す

保存先は同じVPS内だけにせず、別アカウントまたは別ストレージを利用します。

RPOとRTOを決める

RPOは許容できるデータ損失の時間、RTOは復旧までの許容時間です。1日分失ってよいブログなら日次バックアップ、注文や会員データがあるならより短い間隔が必要です。

「毎日3時に取得」「30日保存」だけでなく、「誰が、どの手順で、どこへ復元するか」まで文章にします。

スナップショットの使い方

OS更新、Webサーバー設定変更、アプリの大規模更新前に取得します。短時間で全体を戻せる反面、同じ事業者・アカウント内にあることが多く、アカウント停止や広域障害には弱い方法です。

実行中データベースを含むディスクスナップショットは、アプリ停止や事業者推奨手順が必要な場合があります。整合性が必要なデータは別途ダンプを取得してください。

ファイルをバックアップする

対象にはアプリ本体、アップロード画像、Nginx設定、systemdユニット、証明書の再発行情報、復旧手順を含めます。キャッシュや再生成可能な依存パッケージまで全量保存すると、容量と時間を浪費します。

rsyncを使う例です。保存先と鍵の管理を確認してから実行してください。

rsync -aH --delete /var/www/example/ backupuser@backup-host:/backup/example/current/

--deleteは同期元で消えたファイルを保存先でも削除します。世代管理のない保存先に使うと誤削除まで反映されるため、初回は--dry-runで確認します。

データベースをバックアップする

MySQL・MariaDBの小規模環境では、論理ダンプが分かりやすい方法です。

mysqldump --single-transaction --routines --triggers database_name > database.sql

認証情報をコマンド履歴へ直接書かず、安全な設定ファイルや秘密管理を使います。大規模DBでは、ダンプ時間、ロック、レプリケーション、物理バックアップを含めて設計します。

復元例は次のとおりです。

mysql database_name < database.sql

本番へ直接戻す前に、隔離した検証環境で復元とアプリ起動を確認します。

3-2-1ルールを目安にする

重要データは、3つのコピー、2種類の媒体、1つを別拠点に置く考え方が知られています。VPS本体、事業者のスナップショット、別事業者のオブジェクトストレージなど、同時に失われにくい構成にします。

同じ認証情報で全保存先を操作できると、侵害や誤操作で一括削除される危険があります。バックアップ専用権限、削除保護、バージョニングを検討してください。

暗号化と秘密情報の扱い

バックアップにはデータベース、個人情報、設定ファイルが含まれます。転送時と保存時の暗号化を有効にし、暗号鍵をバックアップと同じ場所だけに置かないようにします。

秘密鍵やAPIキーは、必要性を判断して個別に保管します。失効・再発行できる情報は、復旧時に再発行する手順を用意する方が安全な場合もあります。

自動化と監視

cronやsystemd timerで取得を自動化しても、ジョブ失敗に気付かなければ意味がありません。終了コード、保存容量、最終成功時刻、古い世代の削除を監視します。

バックアップ成功通知だけでなく「24時間成功がない」「容量が急減した」といった異常も通知対象にします。

復元テストの手順

  1. 新しい検証用VPSを用意する
  2. OSと必要パッケージを再現する
  3. 設定とアプリファイルを戻す
  4. DBを復元する
  5. DNSを変えずhostsなどで表示確認する
  6. ログイン、投稿、画像、定期処理を確認する
  7. 実際にかかった時間と不足手順を記録する

四半期に一度など定期的に試し、OSやアプリ変更後は手順書も更新します。

WordPressのバックアップ対象

最低限、wp-contentwp-config.phpに相当する設定、データベースが必要です。WordPress本体は再取得できますが、利用バージョンを記録します。プラグインによるバックアップだけに依存せず、管理画面へ入れない状況でも復元できる方法を持ってください。

まとめ

VPSのバックアップは、スナップショット、ファイル、DBを分けて取得し、VPS外へ世代保存します。復元テストで所要時間と不足ファイルを確認して初めて、使えるバックアップになります。公開前の防御はセキュリティ初期設定も確認してください。

本記事は情報提供を目的としたもので、契約・投資判断はご自身の責任で行ってください。