実践的な VPS バックアップ戦略（3-2-1ルール）

ApexVPSチーム著 • 最終更新: 2026年7月 • 読了時間 7分

信頼性の高いVPSバックアップ戦略は、5分で復旧できるか、最悪の1週間になるかの分かれ目です。サーバーは故障し、ディスクは破損し、デプロイは失敗し、コマンドをひとつ間違えるだけでディレクトリを消去できます。Cloudflareラーニングセンターやほとんどのインフラチームが指すのは、同じシンプルな規律、3-2-1ルールです。このガイドでは、実サーバーへの適用方法、使用ツール、復旧が実際に機能するためのスケジュールとテスト方法を説明します。

3-2-1ルールとは

3-2-1 ルールは何十年も前からあるバックアップの原則で、サーバーの場所に関係なく有効です：

データの3つのコピー — ライブコピーに加え、少なくとも2つのバックアップ。
2 つの異なるメディアまたはストレージシステム — 単一の障害が両方のコピーを同時に失わせることがないようにします。
1 つのオフサイトコピー — 保護対象のマシンから物理的または論理的に分離された場所に保管します。

VPS では通常、稼働中のサーバー、ローカルバックアップリポジトリ、そして暗号化されたコピーをリモートストレージにプッシュすることを意味します。ポイントは、単一の共有障害点を持たない冗長性です。

VPS でバックアップすべきもの

ディスク全体をブロック単位でバックアップするのは非効率で遅いです。優れたバックアップ計画は、再作成が本当に難しい3つのものに焦点を当てます。

アプリケーションデータとファイル

アップロードされたファイル、ウェブサイトのルート、コンテナボリューム、ユーザー生成コンテンツなどです。一般的なパスには /var/www、/srv、/home、Docker ボリュームディレクトリがあります。ファイルサーバーや Wiki などのアプリをセルフホストしている場合、ここに取り返しのつかないコンテンツが存在します。これらのディレクトリの通常の構成については、VPS でのセルフホスティングのガイドを参照してください。

データベース

実行中のデータベースファイルをコピーしないでください。途中まで書き込まれた破損状態を取得する可能性があります。代わりに一貫性のあるダンプをエクスポートします。MySQL または MariaDB の場合:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

--single-transaction フラグは、InnoDB テーブルをロックせずに一貫性のあるスナップショットを提供します。PostgreSQL の場合は、代わりに pg_dump を使用します:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

システムおよびサービス設定

サーバーを自分仕様にするファイル: /etc (nginx、systemd ユニット、cron、SSH 設定)、パッケージリスト、TLS 証明書、ファイアウォールルール。障害後にこれらを記憶から再構築するのは、バックアップが回避すべき面倒な作業です。

バックアップツールの選択

3つのツールでほぼすべての VPS ケースをカバーできます。重複排除と暗号化をどの程度重視するかに基づいて選択してください。

restic — 暗号化・重複排除スナップショット

restic は、デフォルトで暗号化と重複排除を行う最新の単一バイナリバックアップツールです。リポジトリを一度初期化し、その後バックアップを実行します:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — 重複排除アーカイブ

BorgBackup は同様の重複排除と圧縮を提供しますが、ワークフローが少し異なります:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — シンプルなファイルミラーリング

別のホストにファイルを高速ミラーリングするだけであれば、SSH 経由の rsync が最適です:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

-aAX フラグはパーミッション、ACL、拡張属性を保持し、--delete はミラーをソースと同期させます。rsync だけでは履歴のバージョン管理ができないため、多くのチームが restic や borg と組み合わせています。

cron でスケジュールを自動化

実行を忘れるバックアップは存在しないバックアップと同じです。手順をスクリプトにまとめ、実行可能にし、cron でスケジュールします。crontab を編集するには:

crontab -e

次に、以下のような行を追加します:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

ログを出力し、失敗時にスクリプトが非ゼロで終了するようにして、プランに含まれる監視およびアラート機能に結び付けてください。静かなバックアップ失敗は、バックアップなしより悪いです。安全だと感じさせるからです。

実際のオフサイトコピーを保持する

3-2-1 の「1」は多くの人が省略する部分です。保護対象のサーバーと同じ場所にあるバックアップは、そのサーバーと一緒に消えます。暗号化されたコピーを独立した場所（オブジェクトストレージ、リモート SFTP ボックス、別のプロバイダー）にプッシュします。restic と borg はどちらもリモートリポジトリに直接書き込むことができ、例えば SFTP 経由で:

restic -r sftp:[email protected]:/backups/restic backup /var/www

restic と borg は VPS からデータが送信される前に暗号化するため、リモートホストは平文を見ることはありません。古いスナップショットをポリシーに基づいて剪定し、ストレージが無限に増えないようにします:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

リストアを毎回テストする

未テストのバックアップは噂にすぎません。定期的に使い捨ての場所へのリストアをスケジュールし、ファイルとデータベースが無傷で戻ってくることを確認します:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

復元が成功しデータが一致すれば、それが戦略です。一致しなければ、実際の障害時ではなく火曜日の午後にそれを知ることになります。

スナップショットは一つの層であり、戦略全体ではない

すべてのApexVPSプランには自動バックアップが含まれています。Starter Proでは日次スナップショット、Businessでは時間ごとのスナップショットが作成され、不具合のあるデプロイや誤削除の後の迅速なロールバックに本当に役立ちます。しかし、それが何であるかを正直に認識しましょう。それは当プラットフォーム上にある便利な第一の層にすぎません。3-2-1ルールが要求するオフサイトで独立検証済みのコピーの代わりにはなりません。プラットフォームのスナップショットは高速なローカル復元ポイントとして扱い、オフサイトとテスト済み復元の部分を満たすために独自のresticやborgジョブを実行してください。この多層的なアプローチこそが、希望的観測のセットアップと回復力のあるセットアップを分けるものです。Nextcloudのようなアプリケーションをセルフホストする場合でも、本番データベースを運用する場合でも同じです。

VPSバックアップ戦略のチェックリスト

すべてをまとめると、仮想サーバーの完全なバックアップ戦略は次のようになります。一度実行してスクリプト化し、cronに任せましょう。

重要なものを特定する — アプリケーションファイル、データベースダンプ、および/etcの下の設定。
ツールを選ぶ — 暗号化、重複排除、バージョン管理されたバックアップにはresticまたはBorgBackup、単純なミラーにはrsync。
データベースを一貫してダンプする — mysqldump --single-transactionまたはpg_dumpを使用し、稼働中のファイルの生コピーは決して使わない。
自動化する — cronでスクリプトをスケジュールし、ゼロ以外の終了コードでアラートを出す。
1つのコピーをオフサイトにプッシュする — 独立したストレージに暗号化して、適切な保持ポリシーで保存する。
復元を定期的にテストする — 一時的な場所に復元し、データが無傷であることを確認する。

これら6つのことを行えば、3-2-1ルールは理論ではなく、インフラが頼れる習慣になります。セットアップに費やす最初の1時間は、障害発生中に唯一のコピーが死んだディスクにあったことを発見するコストに比べれば取るに足りません。

これを実行するために完全に制御できるサーバーが必要ですか？ ApexVPSは、39のデータセンターにわたる完全なrootアクセス、NVMeストレージ、専用リソースを提供します。暗号通貨のみのチェックアウトで、カードもKYCも不要です。専用VPSプランを比較 →

よくある質問

プロバイダーのスナップショットはバックアップ戦略として数えられますか？

スナップショットは便利な層の一つですが、完全な戦略ではありません。当社の日次および時間ごとのスナップショットは、ほとんどの短期的なミスを防ぎますが、サーバーと同じプラットフォーム上にあります。完全な3-2-1バックアップ戦略には、まだ独立したオフサイトのコピーと、実際にテストした復元が必要です。

VPSのバックアップはどのくらいの頻度で行うべきですか？

失ってもよいデータ量に応じて頻度を合わせてください。静的ファイルや設定は日次で十分ですが、アクティブなデータベースは時間ごとのダンプが適切なことが多いです。cronでスケジュールを自動化し、バックアップが忘れられて実行されないことがないようにしてください。

VPSバックアップに最適なツールは何ですか？

resticとBorgBackupはどちらも優れています。重複排除、圧縮、暗号化を提供し、オフサイトのリポジトリをサポートします。rsyncは単純なファイルミラーに適しており、mysqldumpやpg_dumpはデータベースのエクスポートに適しています。多くのセットアップでは、データベースダンプとresticまたはborgの実行を組み合わせています。

バックアップが実際に機能しているかどうかを確認するには？

定期的に復元をテストしてください。一時ディレクトリに復元し、ファイルの内容とチェックサムを検証し、データベースダンプをスクラッチデータベースにインポートします。復元したことがないバックアップは、回復計画ではなく、希望的観測にすぎません。