Webサイトや社内システム、業務用アプリケーションをVPSで運用していると、気になるのが「もしサーバーが止まったらどうするか」という問題です。
普段は問題なく動いていても、以下のようなトラブルはいつ発生するかわかりません。
主なリスク：
・自然災害
・通信障害
・システム障害
・設定ミスや人的ミス
・サイバー攻撃
・サーバーOSやアプリケーションの不具合
こうしたトラブルが発生したとき、1台のサーバーだけで運用していると、サービス停止やデータ復旧に時間がかかってしまう可能性があります。
そこで検討したいのが、DR対策です。
DRとは Disaster Recovery の略で、日本語では「災害復旧」や「障害復旧」と呼ばれます。
簡単に言えば、万が一のトラブルが起きたときでも、できるだけ早くサービスを復旧できるように備えておくことです。
本記事では、さくらのVPSで始めるDR対策について、わかりやすく紹介します。
DR(災害・障害復旧)対策の考え方
DR対策というと、少し難しく聞こえるかもしれません。
「専門的なクラウド構成が必要なのでは？」
「大企業向けの話では？」
「ロードバランサーや自動切り替えが必要なのでは？」
そう感じる方もいるかもしれません。
もちろん、大規模なサービスでは、複数拠点にまたがった高度な冗長化や、自動フェイルオーバーと呼ばれる仕組みが使われることもあります。
フェイルオーバーとは、稼働中のサーバーに障害が発生したとき、予備のサーバーへ自動的に切り替える仕組みのことです。
ただし、すべてのシステムで最初から高度な構成を作る必要はありません。
中小規模のWebサイトや社内システムであれば、まずは以下のような考え方から始めるだけでも、停止リスクへの備えになります。
・別リージョンに予備のVPSを用意する
・メインサーバーのデータを定期的にバックアップする
・障害時にバックアップサーバーへ復旧できる手順を決めておく
・DNSの切り替え方法を確認しておく
大切なのは、「絶対に止めない構成」をいきなり目指すのではなく、「止まっても早く戻せる構成」を段階的に作ることです。
なぜDR対策にさくらのVPSが最適なのか？
サーバーを1つの場所だけで運用している場合、その拠点で何らかのトラブルが起きると、システム全体に影響が出る可能性があります。
たとえば、東京リージョンでWebサイトを運用している場合、バックアップサーバーも同じ東京リージョンに置いていると、同一拠点の障害や広域トラブルの影響を同時に受ける可能性があります。
一方で、メインサーバーを東京、バックアップサーバーを大阪や石狩に置くような構成にしておけば、拠点を分けたリスク分散が可能になります。
イメージとしては、重要な書類を1つのオフィスだけに保管するのではなく、別の地域の拠点にもコピーを保管しておくようなものです。
普段使うのはメインのオフィス。
万が一、そのオフィスが使えなくなったときは、別拠点にあるコピーを使って業務を再開する。
サーバー運用でも同じ考え方ができます。
さくらのVPSでは、国内の複数リージョンからサーバーを選べるため、サービスの特性やリスク許容度に合わせて、段階的にインフラ配置を検討できます。
はじめてのDR対策は「2台構成」でOK
DR対策というと難しく見えますが、最初はシンプルで十分です。
・通常： メインVPSでサービス運用
・バックアップ： 別リージョンのVPSにデータを保存
・障害時： バックアップ環境に切り替えて復旧
ポイントはたった3つです。
・別リージョンにVPSを1台用意する
・データを定期的にバックアップする
・復旧できる状態にしておく
これだけでも、「単一サーバー運用」と比べると安心感は大きく変わります。
小さく始めて、段階的に強化する
いきなり高度な構成を作る必要はありません。
まずは、
・日次バックアップ
・別リージョンへの保存
この程度から始めるだけでも、十分な第一歩になります。
その上で、
・バックアップ頻度を上げる
・復旧手順を整備する
・自動化を検討する
といった形で、運用に合わせて強化していくのがおすすめです。
具体施策：リージョンを跨いだバックアップの構築方法
ここでは、実際に「どうやってバックアップを実現するのか」を見ていきます。
今回利用するのは rsnapshot というツールです。
rsnapshotとは？
rsnapshotは、Linuxで昔から使われているバックアップツールで、
内部的には「rsync」というファイル転送ツールを利用しています。
特徴は次の3つです。
・差分のみを転送するため高速
・過去の状態を世代管理できる
・ハードリンクを使ってディスク消費を抑える
・バックアップサーバー側からデータを取得する「pull型」
「スナップショット型バックアップ」とは？
rsnapshotの最大の特徴は、「スナップショット型」であることです。
これは例えば：
・昨日の状態
・1週間前の状態
・1ヶ月前の状態
をそのままディレクトリとして保持できる仕組みです。
しかも実体はコピーではなく「ハードリンク」になります。
例えると同じ本を何冊もコピーしているように見えるけど、
実際には「同じ本にしおりを挟んで管理している」イメージです。
またsnapshotは毎回フルバックアップしているように見えますが、
実際には変更があったファイルの差分のみを保持しているため容量を節約できます。
構成イメージ（リージョン跨ぎ）
東京リージョンがバックアップ対象サーバー、大阪または石狩リージョンにバックアップサーバーの配置を想定します。
[東京リージョン]
└ メインVPS（Web/DB）
↓ SSH + rsync
[大阪 or 石狩リージョン]
└ バックアップVPS（rsnapshot）
rsnapshotを導入する具体的な手順を説明します。
OSはUbuntu 24.04、ユーザー名はubuntu(バックアップサーバー、バックアップ対象サーバーのユーザー共に)を前提とします。
rsnapshotの基本構成
バックアップサーバ側で以下のコマンドを実行してrsnapshotをインストールします。
sudo apt install rsnapshotバックアップのフォルダを作成しておきます。
ここではユーザーのフォルダの直下にbackupという名称で作成します。
mkdir ~/backuprsnapshotの設定を行なっていきます。
設定ファイルは下記のパスになります。
/etc/rsnapshot.conf
編集はroot権限が必要なためsudoで行います。
(vim以外のエディタを利用される場合は適宜置き換えてください)
rsnapshotの実行自体はユーザー権限で行います。
sudo vim /etc/rsnapshot.conf内容は下記のように設定してください。
空白はスペースではエラーになるため、タブにしてください。
#cmd_sshの箇所のコメントアウトを外してください
cmd_ssh /usr/bin/ssh
#lockfileのパスをユーザー領域に変更してください
lockfile /home/ubuntu/.rsnapshot.pid
#バックアップを保存するディレクトリを指定します。必要に応じて変更ください。
snapshot_root /home/ubuntu/backup/
#retain daily 7: 日単位のバックアップを7日分残す
#retain weekly 4: 週単位のバックアップを4日分残す
#デフォルトの設定でretain alpha X, retain beta X, retain gamma X
#などの設定がある場合はdailyなどの設定と衝突するので削除してください。
retain daily 7
retain weekly 4
#バックアップの対象を指定します。
#target-server (サーバー名またはIP)、バックアップしたいフォルダは置き換えてください。
#管理者アクセス権限が必要なディレクトリを対象にする場合は
#その権限を持ったアカウントを指定する必要があります。
#前半が「バックアップ対象のサーバー情報とディレクトリ」、
#後半が「バックアップサーバー側での保存ディレクトリ」になります。
#backupで指定する対象ディレクトリは複数設定可能です。
backup ubuntu@target-server:/home/ubuntu backup_target_server/SSH鍵認証の設定
rsnapshotはSSH経由で接続するため、SSH公開鍵の設定が必要になります。
公開鍵はバックアップサーバー側からバックアップ対象サーバーにアクセスする際に必要になります。
バックアップサーバー側で公開鍵を生成します。
既に生成していある場合は実施不要です。
#このコマンドでは~/.ssh/id_ed25519.pubという公開鍵のファイルが生成されます。
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519バックアップ対象サーバーへ公開鍵を送ります。
(1) バックアップ対象サーバーが「パスワードログイン有効」になっている場合
下記のコマンドで実施できます。target-serverはバックアップ対象サーバーのものに置き換えてください。
ssh-copy-id ubuntu@target-server
(2)「パスワードログイン無効」になっている場合
バックアップサーバーの公開鍵を下記の方法でバックアップ対象サーバーに設定します。
さきほどのssh-keygenコマンドでの公開鍵は下記に生成されます。
~/.ssh/id_ed25519.pub
バックアップ対象サーバーの認証キーの一覧ファイルにさきほどのid_ed25519.pubの内容を追加します。
ディレクトリとファイルの権限も設定しておきます。
~/.ssh/authorized_keysアクセス権限を修正しておきます。
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys公開鍵の設定が正しくされたかどうかsshでのログインを試みます。
ログインが正しくできれば公開鍵の設定は完了です。
ssh接続の確認 (target-serverはご自身の環境に置き換えてください。)
ssh ubuntu@target-serverバックアップを実施
rsnapshot daily実際のバックアップ構造
/home/uezato/backup/
├ daily.0/
├ daily.1/
├ weekly.0/
※daily.0 が最新です動作確認
下記コマンドで設定ファイルのテストを行います。
rsnapshot configtestSyntax OKと表示されるとチェック完了です。
エラーが発生する場合は設定ファイルを見直してください。
・編集した行の空白が「スペース」の場合はエラーになりますので、「タブ」に置き換えてください。
・cmd_ssh /usr/bin/sshがコメントアウトされているままだとエラーになりますのでコメントアウトを外してください。
復旧手順
障害時はrsyncコマンドで実施します。
バックアップは通常のフォルダ、ファイルとして保存されているだけですので必要なものだけを指定して戻すことができます。
#target_serverはバックアップ対象サーバーのIPに置き換えてください
rsync -av ~/backup/daily.0/backup_target_server/home/ubuntu/ ubuntu@target_server:/home/ubuntu/更にバックアップの内容を上げていくのであれば下記のような対策をおすすめします。
・DBはダンプと併用（mysqldumpなど）
・転送ポート制限（FW）
・バックアップの監視（fail検知）
バックアップは「取得すること」よりも「復元できること」が重要です。
ぜひ実際に復元まで試してみてください。
DR対策としてリージョンを跨いだ具体的なバックアップ方法についてご紹介しました。
・さくらのVPSは国内3リージョンに対応
・別リージョンにバックアップ環境を持つことでDR対策が可能
・最初は「2台構成」で十分
・小さく始めて段階的に強化すればOK
まずは1台追加して、バックアップ環境を用意するところから始めてみませんか？
２週間の無料体験実施中！さくらのVPSをまずは『気軽に』試してみませんか？
さくらのVPSでは、通常のお申し込みを行うと、そのまま『2週間無料お試し』として利用できます。
まずは触ってみることで、自分に合った使い方やサーバー選びのポイントが自然と見えてきます。
・2週間以内の解約なら料金は不要
・そのまま使い続けたい場合は、解約せずに利用するだけで正式契約へ移行します
・すぐに本契約へ切り替えたい場合は手動で変更も可能です
ぜひ気軽にお試しください。
※お申し込みをされることで２週間の無料体験が自動で開始します。
無料期間内の解約であれば料金はかかりませんのでご安心ください！
for Windows Server