VPSのスナップショットは、ディスク全体をある時点の状態で丸ごと保存する機能で、更新作業の前に取っておけば数分で元に戻せます。ただし、多くは「電源を急に切ったのと同じ状態」の保存で、しかも同じ事業者の中に置かれるため、それだけではバックアップとして足りません。この記事では、スナップショットとバックアップの違い、データベースを壊さずに取得する手順、保存期間の決め方、復元時の注意点を説明します。
スナップショットで保存されるもの
スナップショットは、VPSの仮想ディスクをブロック単位で記録したものです。OS、設定ファイル、WordPressのファイル、データベースのデータファイルなど、ディスク上にあるものはすべて含まれます。復元すると、ディスクが取得時点の状態に戻ります。
含まれないのは、メモリ上にしかないデータです。データベースがまだディスクに書き出していない変更や、アプリケーションが処理中だった内容は残りません。この性質を「クラッシュ整合性（crash-consistent）」と呼びます。電源断から再起動したときと同じで、ファイルシステムやデータベースは起動時の回復処理で多くの場合は正常に戻りますが、それが保証されるわけではありません。
スナップショットだけでは足りない理由
スナップショットとバックアップは、守れる範囲が違います。
スナップショットが得意なのは、「OSやPHPのアップデートで動かなくなった」「設定を壊した」「プラグイン更新でサイトが真っ白になった」といった、サーバーそのものは健在なときの巻き戻しです。全体を一度に戻せるので、復旧が速いのが利点です。
一方で、次のような事態には弱い面があります。
- 保存先が同じ事業者の基盤の中にある。障害や災害、事業者側のトラブルでVPSとスナップショットの両方が使えなくなる可能性がある
- 管理画面のアカウントが乗っ取られたり、契約や支払いのトラブルで停止されたりすると、スナップショットにも手が届かない
- 「先週消してしまった1記事だけ戻したい」のような部分的な復元がしにくい。全体を戻すと、それ以降の投稿やコメントも消える
- 改ざんやマルウェアに気づくのが遅れると、保存期間内のスナップショットがすべて感染後のものになっていることがある
そのため、スナップショットは「素早い巻き戻し用」と位置づけ、別の場所にデータベースのダンプとファイルのバックアップを置くのが基本です。よく言われる3-2-1ルール（3つのコピー、2種類の媒体、1つは別の場所）の考え方が参考になります。
事業者ごとの機能の違い
スナップショットの機能は、国内VPS・海外クラウドを問わず多くの事業者が提供していますが、細部はそれぞれ異なります（2026年10月現在）。確認しておきたいのは次の点です。
- 取得時にサーバーの停止が必要か、稼働中に取れるか
- 手動のみか、自動取得（スケジュール）があるか。自動バックアップは有料オプションになっていることが多い
- 保存できる世代数や容量の上限、料金のかかり方（容量課金か、無料枠があるか）
- 復元方法が「今のディスクを上書き」か「新しいサーバーとして作成」か
- 別リージョンへのコピーや、イメージとして別サーバーの作成に使えるか
料金や上限は改定されることがあるので、利用中のサービスの公式ドキュメントで最新の内容を確認してください。
データベースの整合性を保って取得する
WordPressのようにMySQL/MariaDBが動いているサーバーでは、取得の仕方で安全性が変わります。InnoDBはクラッシュからの回復機能を持っているので稼働中のスナップショットでも多くの場合は起動できますが、次のいずれかの対策を取るとより安心です。
方法1：取得前に論理ダンプを取る
いちばん手軽で効果が大きい方法です。スナップショットの直前に mysqldump でダンプを作っておけば、万一データファイルが回復できなくても、ダンプから戻せます。
mysqldump --single-transaction --routines --triggers \
-u backup_user -p wordpress_db | gzip > /var/backups/wordpress_db_$(date +%F_%H%M).sql.gz--single-transaction を付けると、InnoDBのテーブルをロックせずに、一貫した時点の内容を取り出せます。サイトを止めずに取れるので、日常のバックアップにも使えます。
方法2：書き込みを止めてから取得する
より厳密にしたい場合は、スナップショットを取る間だけデータベースへの書き込みを止めます。MySQLでは FLUSH TABLES WITH READ LOCK で、テーブルの内容をディスクに書き出したうえで書き込みを止められます。
-- mysql クライアントで接続したまま実行する
FLUSH TABLES WITH READ LOCK;
-- この状態で管理画面からスナップショットを取得する
-- 取得の開始（または完了）を確認したら解除する
UNLOCK TABLES;ここでのつまずきは、ロックが「そのセッションが続いている間だけ」有効なことです。コマンドを打ってすぐに mysql クライアントを抜けると、その時点でロックは解除されます。接続したままスナップショットを取り、終わってから UNLOCK TABLES を実行してください。ロック中は投稿の保存やコメントが待たされるので、アクセスの少ない時間帯に行います。
方法3：サービスを止めて取得する
数分の停止が許されるなら、Webサーバーとデータベースを止めてから取得するのが一番単純で確かです。
sudo systemctl stop nginx php8.3-fpm mysql
sync
# 管理画面でスナップショットを取得
sudo systemctl start mysql php8.3-fpm nginxサービス名は環境によって異なります（apache2、mariadb、php-fpm など）。systemctl list-units --type=service で確認してから実行してください。
事業者によっては、ゲストエージェント（qemu-guest-agent など）を入れておくと、取得時にファイルシステムの書き込みを一時的に凍結してくれる機能があります。対応している場合は有効にしておくとよいでしょう。
保存期間と取得のタイミング
保存期間は、「問題に気づくまでにどれくらいかかるか」から逆算します。更新直後の不具合ならすぐ気づきますが、改ざんやデータの欠損は数週間後に見つかることもあります。
一例として、次のような組み合わせがあります。
- 定期：毎日1世代を7日分、加えて週1世代を4週分
- 臨時：OSのアップグレード、PHPのバージョン変更、WordPress本体や主要プラグインの更新の直前に1つ
- 外部：データベースのダンプとwp-content配下は、別の事業者やクラウドストレージに毎日転送
臨時で取ったスナップショットは、作業が問題なく終わって数日たったら削除します。放置すると容量課金がかさみ、世代数の上限で定期分が取れなくなることがあります。
復元するときの注意点
復元は、取得時点以降の変更がすべて失われる操作です。実行前に、現在の状態のダンプやスナップショットを取っておくと、復元先を間違えたときにも戻れます。
復元後には次の点を確認します。
- 取得後に投稿された記事やコメント、注文などのデータが消えていないか。必要なら、外部に取っておいたダンプから差分を補う
- 新しいサーバーとして復元した場合、IPアドレスが変わっていないか。DNSのAレコードやファイアウォールの許可設定を見直す
- SSL証明書が取得時点のものに戻り、期限切れになっていないか
- cronやバックアップの自動実行が二重に動いていないか
そして、復元は一度は練習しておくことをおすすめします。「新しいサーバーとして復元」ができる事業者なら、本番に影響を与えずに、スナップショットから起動してサイトが表示されるかを確かめられます。
まとめ
- スナップショットはディスク全体の時点保存で、更新作業前の巻き戻しに向いている
- 多くはクラッシュ整合性で、同じ事業者の基盤に置かれる。外部へのバックアップと併用する
- データベースは、直前の mysqldump、
FLUSH TABLES WITH READ LOCKを保持したままの取得、サービス停止のいずれかで整合性を高める - 保存期間は問題に気づくまでの時間から決め、臨時のスナップショットは作業後に整理する
- 復元は取得後のデータを失う操作。事前の退避と、IP・証明書・cronの確認を忘れずに