自動バックアップとスナップショットはどう違いますか
どちらもサーバーディスク全体をコピーしておく方法ですが、作成するタイミングと支払い方式が違います。
- 自動バックアップ:サーバー作成時にオンにする追加オプションです。サーバーディスク全体のコピーが決まった周期で自動的に作成され、料金はサーバー料金の 5.6% として請求書に加算されます。復元は、最初の支払いが確認された後にサポートページからご依頼いただければ対応します。
- スナップショット: 別途注文する商品です。大きな更新の直前のように自分で決めたタイミングのディスク全体を保存し、ストレージ 1 GB あたり月 $0.009 で計算します。注文時に 20GB から 2,000GB まで 10GB 単位で容量を選びます。
毎日変わるウェブサイトやデータベースは自動バックアップが自動で守り、OS のアップグレードのように元に戻しにくい作業の前にはスナップショットを1つ残しておけば、2つの機能が互いのすき間を埋めます。商品の説明は、自動バックアップとスナップショットのページにあります。
自動バックアップを有効にする
- アカウントで新しいサーバーを押し、リージョン、サイズ、イメージを選びます。
- 追加オプションの自動バックアップをオンにします。
- 右側の概要に、サーバーとバックアップを合わせた月額料金がすぐに表示されます。
- サーバー作成を押して選択した請求期間の料金を支払い、期間が終わる前に更新の請求書を支払うと、サーバーは継続して稼働します。
自動バックアップは、サーバー作成時に選ぶオプションです。すでに使っているサーバーのデータを守るには、スナップショットを注文するか、下のサーバー内バックアップを併用してください。API でサーバーを作成するときは、リクエストに "backups": true を入れれば同じオプションが有効になります。
自動バックアップからの復元を依頼する
復元はサポートスタッフが対応し、ご希望の時点を正確に選んで戻します。最初の支払いが確認された後、サポートページから次のようにご依頼ください。
- トピックはサーバーを選びます。
- サーバー名の欄に、復元するサーバーの名前を書きます。
- 内容に、戻したい日付と時刻(UTC)、同じサーバーに戻すかどうかを書きます。
復元するとサーバーディスクがバックアップ時点の内容に置き換わるため、それ以降に作成したファイルは消えます。残したい最近のファイルがあれば、依頼の前にお使いの PC にダウンロードしておいてください。回答はサポートセンターページに表示されます。
スナップショットを注文する
- スナップショットのページで注文を押します。
- 保存容量を選びます。サーバーディスクと同じか少し大きい容量なら、ディスク全体を余裕をもって収められます。
- 名前の欄に対象のサーバー名を書いておけば、どのサーバーのスナップショットかすぐにわかります。英字、数字、ピリオド、ハイフンを使えます。
- 注文すると選択した請求期間の料金を支払い、準備が終わるとアカウントの商品一覧に表示されます。
データベースのように書き込みが続くサーバーは、スナップショット作成時に一時的にサービスを止めるか、サーバーを停止しておくと最もきれいなイメージが得られます。スナップショットへの巻き戻しや新しいサーバーの作成も、最初の支払いが確認された後、サポートページでサーバー名とスナップショット名を書いてご依頼いただければ対応します。
サーバー内で自分でバックアップする
自動バックアップとスナップショットがサーバー全体を守るのに対し、サーバー内のバックアップは、ファイルとデータベースを別の場所にもう1部置く方法です。コピーを3部、2種類のストレージに、そのうち1部は別の場所に置く3-2-1の原則に従えば、最も安心です。
ステップ1. ファイルとデータベースをまとめる
mkdir -p /root/backup
tar czf /root/backup/www-$(date +%F).tar.gz /var/www
mysqldump --single-transaction --all-databases | gzip > /root/backup/db-$(date +%F).sql.gzPostgreSQL なら sudo -u postgres pg_dumpall | gzip > /root/backup/pg-$(date +%F).sql.gz、Docker のボリュームなら docker run --rm -v ボリューム名:/data -v /root/backup:/out alpine tar czf /out/ボリューム名.tar.gz -C /data . でまとめます。
ステップ2. 毎日自動で実行する
crontab -e でスケジュールジョブを開き、下の3行を入れれば、毎日午前3時(サーバー時刻)にバックアップファイルを作成し、7日を過ぎたファイルは整理されます。crontab の中では、% の前にバックスラッシュを付けます。
0 3 * * * tar czf /root/backup/www-$(date +\%F).tar.gz /var/www
5 3 * * * mysqldump --single-transaction --all-databases | gzip > /root/backup/db-$(date +\%F).sql.gz
30 3 * * * find /root/backup -name '*.gz' -mtime +7 -deleteステップ3. 別の場所にもう1部送る
バックアップファイルが同じサーバーにしかないと、サーバーと一緒に失われるおそれがあります。別のリージョンのサーバーに rsync で送るか、rclone でオブジェクトストレージにアップロードすれば、別の場所にもう1部できます。
rsync -az /root/backup/ backup@BACKUP_SERVER_IP:/backups/web-1/状況に応じてどの方法を選べばよいですか
3つの方法は互いの代わりになるというより、組み合わせて使うときに最も心強くなります。自分のサーバーの用途に合わせて、次のように組み合わせてみてください。
- 個人ブログ、小規模なウェブサイト: サーバー作成時に自動バックアップをオンにしておき、テーマやプラグインを大きく変える前に WordPress のエクスポートファイルを1つ取得しておけば十分です。
- ネットショップ、会員サービス: 自動バックアップに加えてデータベースのダンプを毎日作成し、別のリージョンにもう1部送ります。注文履歴や会員情報を、時間単位で取り戻せます。
- 開発、テストサーバー: 大きな実験の前にスナップショットを1つ残し、実験が終わったらスナップショットを削除して保存料金を節約します。
- 同じ構成のサーバーを複数台使うとき: 基準となるサーバーのスナップショットを長く保管しておけば、新しいサーバーを同じ状態にすばやく揃えられます。
どの組み合わせでも大切なのは、コピーがサーバーの外にも1部あるか、そしてそのコピーから実際に戻してみたことがあるかです。この2つさえ押さえておけば、突然のミスや障害にも落ち着いてサービスを復旧できます。
料金もあわせて考えてみてください。自動バックアップはサーバー料金の 5.6% で決まる毎月同じ金額で、スナップショットは保存した容量分だけかかります。サーバー内のバックアップは追加料金なしでディスク容量だけを使いますが、別の場所に送るコピーには受け取る側のストレージが必要です。必ず守るべきデータのサイズと、戻す必要がある頻度を基準に選べば、コストと安全性を両立できます。
復元の練習とよい習慣
バックアップは、元に戻せてこそ価値があります。月に1回ほど小さなサーバーを1台作ってバックアップファイルを展開し、サイトが開くかを確認しておけば、実際の場面で手順に迷いません。確認が終わったテスト用サーバーは、すぐに削除してください。
- 大きな作業の直前には、スナップショットかバックアップファイルを1つ残します。
- バックアップファイルの名前に日付とサーバー名を入れて、どの時点のものかすぐにわかるようにします。
- データベースのパスワードや API キーのような秘密情報を含むバックアップは、安全な場所にだけ保管します。
- サーバーを再インストールする前には、再インストールガイドのデータを移すステップを先に行います。
ディスク容量が足りずバックアップを長く保管しにくい場合は、サーバーに NVMe ブロックディスクを追加して、バックアップ専用の領域として使う方法もあります。Docker を使っているなら、Docker のインストールガイドのボリューム管理もあわせてご覧ください。
