先に要点
VPS を借りたけど、バックアップってどこまで必要なの？
DB だけ dump していれば足りる？
設定ファイルまで残すべき？
このあたりは、VPS を触り始めるとかなり現実的にぶつかる話です。
共有レンタルサーバーより自由度が高いぶん、どこまで自分で面倒を見るか を決めないと、いざというときに戻せません。
この記事では、VPS のバックアップを 何世代残すか ではなく、何を残すべきか という観点で整理します。
世代数や RPO / RTO の考え方を先に見たいなら、バックアップは何世代必要？実務で多い考え方・復旧確認・具体的な戻し方を解説 がつながりやすいです。
まず結論: VPSでは「データ」と「再現情報」を分けて残す
VPS のバックアップで大事なのは、全部を一つの方法で済ませようとしないことです。
ざっくり分けると、残したいものは次の4種類あります。
この4つは、壊れたときの困り方も、戻し方も違います。
だから、毎日スナップショットを取っているから大丈夫 だけでは少し弱いです。
VPS 障害で困るのは、OS が落ちることだけではありません。誤削除、アプリ更新ミス、DB破損、設定上書き、証明書更新失敗のように、壊れ方がばらけるので、復旧単位も分けておく方が実際は戻しやすいです。
VPSで最低限残したいもの
1. DB
最優先です。
ブログ、業務システム、EC、会員管理など、多くのアプリでは一番失うと困るのが DB です。
特に残したいのはこのあたりです。
- MySQL / PostgreSQL のダンプ
- 可能なら日次以上の世代
- 復旧に使う手順メモ
DB はファイルコピーだけで雑に済ませるより、論理バックアップやサービスに合った方法で取る方が安全です。
2. アップロードファイル・生成ファイル
ユーザーがアップした画像、添付ファイル、エクスポートファイル、アプリが生成した成果物です。
よくあるのは、
- DB は戻った
- でも画像や添付がない
という事故です。
たとえば WordPress の uploads、Laravel の storage/app/public、アプリの添付ディレクトリなど、DB 外にある実データ は別で見た方が安全です。
3. アプリ設定
.env、API キー、メール設定、外部接続先、署名鍵などです。
ここは軽く見られがちですが、実務ではかなり重要です。
コードが戻っても、設定がないと本番復旧できません。
ただし、秘密情報を含むので、保管方法は雑にしない方がよいです。
4. サーバー設定
見落としやすいのがここです。
このへんが飛ぶと、アプリ本体と DB が戻っても動きません。
スナップショットだけで足りるか
スナップショット はかなり便利です。
VPS 事業者側で用意されていることも多く、OS ごとまとめて戻せるので、昨日の状態へ全体を戻したい には相性がよいです。
ただし、スナップショットだけだと弱い場面があります。
個別復旧がしにくい
DB の一部だけ戻したい、特定ディレクトリだけ戻したい、というときに扱いづらいです。
世代や粒度が粗くなりやすい
日次 1 回だけだと、昼に壊れたときに朝までしか戻れないことがあります。
同じ基盤に寄りすぎると不安が残る
VPS 事業者側に丸ごと依存する形なので、保存先の分離や取り出しやすさも見た方が安全です。
つまり、スナップショットは有力ですが、万能なバックアップの代わりではない と見た方が実務向きです。
実務ではどう組み合わせると現実的か
かなりよくあるのは次の分け方です。
| 対象 | 向いている残し方 |
|---|---|
| DB | 定期ダンプ + 世代管理 |
| アップロードファイル | rsync やストレージ退避、日次コピー |
.env や秘密情報 |
暗号化保管、限定アクセスの保管先 |
| Nginx / cron / systemd / Firewall | Git 管理できる設定は管理、難しいものは定期退避 |
| サーバー全体の保険 | スナップショット |
この形にしておくと、
という切り分けがしやすくなります。
どこに置くべきか
最低限の答えは、同じ VPS の中だけに置かない です。
同じサーバーに
- 本番データ
- バックアップファイル
が両方あるだけだと、ディスク障害、侵害、誤削除でまとめて消えることがあります。
実務では、少なくとも
のどれかへ逃がす方が安全です。
小規模VPSならどこまでやれば十分か
全部盛りにしなくても、最初は次でかなり十分です。
1. DBの日次バックアップ
まずはここです。
ブログでも業務ツールでも、DB がないと戻しにくいことが多いです。
2. アップロードディレクトリの日次コピー
画像や添付があるなら、DB とセットで見ます。
3. .env と主要設定の保管
手元だけ、担当者の記憶だけ、にしない方が安全です。
4. 週次くらいのスナップショット
大きく壊れたときの保険としてかなり便利です。
5. 復旧メモ
これがないと、バックアップがあっても現場で止まります。
復旧するときは何から戻すべきか
実務でよくある順番はこうです。
- 新しい VPS か復旧先を用意する
- OS と基本ミドルウェアを整える
- Nginx / PHP / systemd / cron など設定を戻す
- アプリコードを配置する
.envや秘密情報を戻す- DB を復旧する
- ファイルを戻す
- 動作確認して公開を切り替える
ここで大事なのは、DB とファイルの時点が大きくずれないか です。
添付付きアプリや CMS では、DB だけ昨日、ファイルだけ今日、のようにずれると整合が崩れます。
小規模 Laravel アプリを VPS で動かしているなら、まず MySQL ダンプを別保管先へ日次退避し、`storage/app/public` やユーザー添付ディレクトリを別でコピーし、Nginx 設定・systemd 定義・cron を設定ファイルとして残しておく形が始めやすいです。障害時は新しい VPS を立てて、コード配置 → `.env` 投入 → DB 復元 → ファイル復元 → キャッシュクリア → 動作確認、の順で戻すと整理しやすいです。
よくある危ないパターン
DBだけで安心している
画像、添付、エクスポート結果、証明書関連が飛んでいることがあります。
スナップショットしかない
丸ごと戻すしかなく、部分復旧や取り出しがつらいことがあります。
同じVPSの中だけに置いている
これだと本番と一緒に失うリスクが残ります。
手順が担当者の頭の中だけ
実際の障害時は、ここがいちばん詰まりやすいです。
まとめ
VPS のバックアップで大事なのは、何世代残すか だけではなく、DB・ファイル・設定・サーバー構成をどう分けて残すか です。
実務では、DB ダンプ、ファイル退避、.env や主要設定の保管、スナップショットを役割分担させる形がかなり現実的です。
そして最後は、どこへ保存したか より 実際にその順で戻せるか を確認する方が価値になります。
VPS は自由度が高いぶん、バックアップも 丸ごと一発 ではなく、何を失うと困るか から設計した方が後でかなり楽です。