初心者必見！webサーバーのバックアップ方法と管理術の基本

2025 10/30

2025/10/30

はじめに

本資料は、Webサーバーのバックアップについて、初心者から中小企業のWeb担当者やサーバー管理者向けに分かりやすくまとめたものです。Webサイトのデータ（記事、画像、顧客情報）や設定（ドメイン、SSL、メール設定）は、事故や操作ミス、ハードウェア故障で失われることがあります。本資料はそうしたリスクに備えるため、なぜバックアップが必要か、どのような種類があるか、具体的な保存先や復元方法まで、実務に役立つ情報を順を追って解説します。

章ごとに実践的な手順や注意点、レンタルサーバーの機能比較も掲載しています。例えば、静的なHTMLサイトとWordPressのようなCMSではバックアップ対象や手順が異なります。本書では具体例を示し、すぐに試せる方法を優先して紹介します。

読み方の提案：まず第3章で必要性を理解し、第4〜7章で準備を整えます。第8章で自動化し、第9章で復元手順を確認してください。本資料を使って、日々の運用で安心できる体制を作る一助になれば幸いです。

初心者向け！Webサーバーのバックアップ方法とプラクティス

はじめに

Webサーバーのバックアップは、サイトのデータ消失や障害に備える基本作業です。バックアップがないと、最悪サイトを一から作り直すことになります。ここでは初心者向けに分かりやすく手順と実践を説明します。

バックアップの基本

対象は大きく分けて「ファイル（HTML、画像、コード）」「データベース（例：MySQL）」です。両方を確実に保存します。例：WordPressならwp-contentとデータベースが重要です。

基本的な手順（手でできる方法）

ファイルをダウンロード：FTP/SFTPでサーバーの公開フォルダをローカルにコピーします。
データベースのエクスポート：phpMyAdminやmysqldumpでSQLファイルを作成します。
圧縮と保存：zipやtarでまとめ、日付を付けて保存します。

実践的なプラクティス

頻度：更新が多ければ毎日、少なければ週1回以上がおすすめです。
保存先：ローカル、外部クラウド、別サーバーの3か所に分けて保存します。
自動化：サーバー上でcronを使い、スクリプトで定期実行することで人為ミスを減らせます。
検証：定期的に復元テストを行い、バックアップが正常に使えるか確認します。

注意点

パーミッション（権限）や機密情報の扱いに注意してください。暗号化やアクセス制限をかけると安全です。
フルバックアップと差分（増分）を組み合わせると保存容量を抑えられます。

この章を読めば、まずは手動で確実にバックアップを取り、徐々に自動化や保存ポリシーを整える流れが分かります。

バックアップが必要な理由

なぜ備える必要があるのか

サーバーやサイトは予期せぬトラブルで簡単に動かなくなります。ハードウェア故障、ハッキング、ソフトウェア更新の失敗、人的ミス（誤削除や誤設定）などが原因です。バックアップがあれば被害を小さく抑えられます。

具体例で考える

ハードディスクが壊れてサイトが消えるケース
不正アクセスでファイルが改ざんされるケース
管理画面で誤って重要ファイルを削除してしまうケース
これらは実際に起こる問題で、復旧にかかる時間と費用は大きく異なります。

バックアップがもたらす効果

バックアップがあると短時間で復旧できます。例えば毎日バックアップを取れば、最悪でも前日の状態に戻せます。ダウンタイムが短ければ、顧客信頼や売上の損失を減らせます。

経済的な観点

バックアップは初期と運用のコストがかかりますが、復旧にかかる人件費や機会損失を比べると安価です。小さな投資で大きなリスクを防げます。

心構え

定期的なバックアップと保存先の分散（別サーバーやクラウド）は基本です。日常の運用に組み込み、万が一に備えましょう。

バックアップの種類

Webサイトを守るために知っておきたい代表的なバックアップの種類を、やさしく説明します。

フルバックアップ
説明: サイトの全データを丸ごと保存します。例: ファイル、データベース、設定を一度にコピーします。
長所: 復元が簡単で確実です。
短所: 容量と時間が大きくかかります。
使いどころ: 定期的に全体を保存したいとき（週1回など）。
増分バックアップ
説明: 前回のバックアップ以降に変わった部分だけを保存します。例: 昨日以降に追加したファイルのみ。
長所: 容量と時間を節約できます。
短所: 復元時に複数の世代を順に組み合わせる必要があります。
使いどころ: 頻繁に更新があるサイト向け。
差分バックアップ
説明: 最後のフルバックアップ以来の変更分を保存します。
長所: 復元は増分より簡単で、差分だけで戻せます。
短所: フルバックアップから時間が経つと差分が大きくなります。
使いどころ: フルと組み合わせて使うと効果的です。
保存場所に関する分類
外部バックアップ: 別サーバーやクラウド（例: S3、外部レンタルサーバー）に保存します。災害対策に有効です。
内部バックアップ: 同じサーバー内に保存します。復旧は早いですが、サーバー障害時に失うリスクがあります。
ローカルバックアップ: ユーザーのPCや外付けHDDに保存します。手元で管理でき安心感がありますが、自動化を検討してください。

用途や復元のしやすさ、保管コストを考えて組み合わせると安全性が高まります。

バックアップの方法

レンタルサーバーの自動機能

多くのレンタルサーバーはバックアップ機能を提供します。管理画面で保存期間や頻度を設定するだけで、運用の手間を減らせます。定期的に復元テストを行い、設定を確認してください。

WordPressなどのプラグイン利用

BackWPupやUpdraftPlusなどを使えば、データベースとファイルをまとめて保存できます。手順は、プラグインを有効化→スケジュール設定→リモート先（Dropbox、S3等）を指定→テスト実行、です。細かい除外設定で容量を節約できます。

手動バックアップ

ファイルはFTPクライアント（FileZilla等）でpublic_htmlやwp-contentをダウンロードします。データベースはphpMyAdminで「エクスポート」を選びSQLで保存します。日付を付けてクラウドに保管すると管理が楽です。

rsync（Linuxサーバー）の例

差分だけ転送するrsyncは効率的です。例: rsync -avz –delete /var/www/ backup@server:/backup/www/。SSH鍵で接続し、cronで定期実行（例：毎日2時）に設定します。

Windowsサーバーの場合

Windows Server BackupやCobian、Veeamなどを利用します。システムイメージとデータを別々に保存し、スケジュールを組んで自動化してください。

実務的な考え方

初回はフルバックアップを行い、以降は差分または増分で運用します。保管先は複数（オンサイト＋クラウド）にし、定期的に復元テストを行ってください。

バックアップの対象

Webファイル（HTML・画像・CSS・JavaScript）

Webサイトの見た目や動作を構成するファイルです。公開ディレクトリ（例：/public_html、/var/www/html）やアップロードフォルダを丸ごとバックアップしてください。画像やアップロードファイルは容量が大きくなりやすいので、差分バックアップや世代管理を検討します。

データベース（MySQL、PostgreSQLなど）

投稿やユーザー情報など動的データが入ります。ダンプ（例：mysqldump、pg_dump）でデータとスキーマを保存し、一貫性を保つためにトランザクション整合の方法を使います。頻度は更新量に合わせて決めます（例：ECサイトは頻繁、個人ブログは日次）。

設定ファイル（サーバー・アプリケーション設定）

nginx、Apache、PHP、.env、アプリ固有の設定ファイル（例：wp-config.php）やcron設定などを含めます。小さいが復元に必須です。アップデート前や設定変更後は必ずバックアップを取ります。

メールデータ（レンタルサーバー利用時）

レンタルサーバーではメールボックス（IMAP/POP）のデータやWebメール設定も消失すると困ります。エクスポート機能やサーバー提供のバックアップを利用し、必要なら定期的にローカルに保存します。

その他（ログ・ユーザーアップロード・APIキー）

アクセスログは障害時の解析で役立ちますが容量が増えます。ユーザーがアップロードしたファイルや生成バイナリ、外部サービスの設定やAPIキーは別途安全に保存し、機密情報は暗号化します。

運用上の注意点

どの対象でも、保存先の暗号化、アクセス制御、定期的な復元テストを行ってください。優先順位を付けてバックアップ頻度と保存期間を決めると管理が楽になります。

バックアップの保存先と管理

サーバー内（同一サーバー）

サーバー内に置くと手軽で復元が早いです。設定や自動化も簡単にできます。ただし、サーバー自体が故障したりハッキングを受けると一緒に失うリスクがあります。短期保存や差分バックアップの一時置き場として使うのが安全です。

外部ストレージ／クラウド（例：Dropbox、Google Drive、AWS S3）

安全性が高く、物理的に分離できます。クラウドなら自動転送やアクセス管理、バージョン管理が使えます。例として小規模ならDropboxやGoogle Drive、中〜大規模ならAWS S3やAzure Blobが適します。費用、転送速度、暗号化の有無を確認してください。

ローカルPCや外付けHDD

物理的に別場所で保管できるので、ネットワーク障害に強いです。管理が煩雑になりやすく、手動での更新ミスが起こりやすい点に注意してください。重要なデータは複数の場所に分散して保管しましょう。

保持期間と世代管理（世代管理の例）

最近のバックアップを短期間（例：7日分）残す
中期（例：30日分）は週次で残す
長期（例：1年）は月次・四半期で残す
古いバックアップは自動で削除する仕組みを入れて容量を管理します。クラウドのライフサイクル機能を使うと楽です。

管理のポイント

暗号化とアクセス制御を必ず設定する
バックアップの自動化とログ記録を行う
復元テストを定期的に実施する
ファイル名やフォルダに日付を付けるなど命名規則を決める
コストや転送時間を考慮して保存先を組み合わせる（例：短期はサーバー内、中長期はクラウド）

これらを組み合わせることで、万が一の障害に備えた堅牢なバックアップ運用ができます。

バックアップの自動化とスケジュール

はじめに

定期的なバックアップは手動だと忘れがちです。自動化すれば確実に取得でき、運用負担を減らせます。ここでは実践的な方法と注意点をやさしく説明します。

自動化の主な方法

cron：Unix系で最も一般的です。例えば深夜2時にバックアップを実行するには「0 2 * * * /usr/bin/rsync -a /var/www/ /backup/www/」のように設定します。cronは軽量で確実です。
プラグイン：WordPressなどCMSならBackUpプラグイン（例：UpdraftPlus）で簡単にスケジュール設定できます。FTPやクラウドへ自動保存できます。
レンタルサーバーの機能：多くは日次・週次で自動取得します。管理画面で有効化や保存期間の確認をします。

スケジュール設定のポイント

負荷の少ない時間帯（深夜や利用者が少ない時間）を選びます。
更新頻度に合わせて間隔を決めます（毎日、毎週、差分は数時間ごとなど）。
保存期間と世代管理を決めます（例：日次7世代、週次4世代、月次12世代）。

運用上の注意

通知とログ：失敗時にメールやSlackで通知を受け取る設定にします。
検証：定期的に復元テストを行いバックアップの正常性を確認します。
暗号化とアクセス制限：バックアップファイルを暗号化し、保存先のアクセス権を制限します。
容量管理：古いファイルを自動削除するローテーションを設定し、容量切れを防ぎます。

手動バックアップについて

更新頻度が低い場合は手動で十分ですが、忘れないようカレンダーや簡単なリマインダーを併用してください。

これらを組み合わせると、安全で負担の少ないバックアップ運用が実現します。

バックアップからの復元方法

Webサイトが動かなくなったとき、復元方法を知っていると安心です。ここでは代表的な復元手順をやさしく説明します。

管理画面からワンクリック復元

レンタルサーバーの管理画面に「バックアップ復元」機能がある場合、復元したい日時を選び、ボタンを押すだけで戻せます。例：ファイルのみ・データベースのみ・両方を選択可能。

プラグインや手動での復元（具体例）

WordPressならUpdraftPlusなどのプラグインでアップロードしてワンクリック復元できます。\n- 手動の場合はFTPでファイルをアップロードし、phpMyAdminでSQLファイルをインポートします。手順は次の通りです。
最新のバックアップファイルを用意する（例：zip, sql）。
FTPでpublic_htmlやwwwにファイルを上書きする。設定ファイル（wp-config.php等）は注意して扱う。
phpMyAdminで対象データベースを選び、インポート機能でSQLを読み込む。

復元が難しいときの対応

エラーが出る場合はログを確認し、該当ファイルやテーブル名をチェックします。バージョン違いでエラーが出ることもあります。自分で対応できない場合は、まずレンタルサーバーのサポートに連絡してください。多くの場合、サポートで復元を手伝ってくれます。

復元時の注意点チェックリスト

復元前に現在の状態を別名で保存する
復元日時とバックアップの中身を確認する
パーミッションや設定ファイルを再確認する
作業後にサイト全体を動作確認する

これらの手順で落ち着いて復元作業を進めてください。必要ならサポートに相談しましょう。

主要レンタルサーバーのバックアップ機能比較

概要

主要なレンタルサーバーは毎日バックアップを取り、Web・メール・データベースを対象に保存しています。保存期間はサービスによって14日〜30日と差があります。

各社の主な違い

Xserver
保存期間：おおむね14日
対象：Web/メール/DB
復元：管理画面やサポート経由で復元可能。自分で操作できる場合が多いです。
ConoHa WING
保存期間：おおむね14日
対象：Web/メール/DB
復元：管理画面からの復元やサポート依頼に対応します。
mixhost
保存期間：おおむね30日
対象：Web/メール/DB
復元：比較的長めの保存期間で安心感があります。
ロリポップ
保存頻度：1日1回のバックアップ
費用：復元は有料でプロバイダに依頼する形式が多い

選び方のポイント

保存期間：重要なデータは長めの保存期間が安心です。mixhostのように30日あると心強いです。
復元のしやすさ：管理画面でワンクリック復元できるか、サポート対応かを確認してください。
費用：復元に料金がかかると頻繁に使いにくくなります。ロリポップのように有料復元がある点は注意が必要です。

普段から自分でもエクスポート（ファイル・DBのダウンロード）を取っておくと、サービスに依存せず迅速に復旧できます。

バックアップ運用のポイント

定期的な復元テスト

バックアップは取得して終わりではありません。定期的に復元して動作を確認してください。例：月に1回、本番サイトの一部をテスト環境へ復元して表示やデータ整合性をチェックします。問題があれば手順を見直してください。

保存先を分散する

バックアップは複数の場所に保管します。具体例：外付けHDD、別のデータセンター、クラウドの3カ所に分けると安心です。物理的な災害や一時的な障害に備えられます。

クラウド保存時の暗号化とアクセス管理

クラウドに保存する場合は暗号化を検討してください。ログイン情報や鍵の管理も重要です。誰が復元できるか権限を絞り、不要な共有を避けてください。

バックアップログの確認

自動バックアップでもエラーは発生します。取得ログを定期確認し、失敗や時間のずれがないかチェックします。異常時は通知を受け取る設定にしましょう。

運用ルールとチェックリスト

運用担当者、頻度、保存期間、復元手順を文書化しておきます。具体的なチェックリスト例：
– 取得日時の確認
– 保存先の有無確認
– 復元テスト結果の記録

よくある注意点

古いバックアップの放置で容量を圧迫します。必要な期間だけ保管し、定期的に不要データを削除してください。手順を簡潔にし、誰でも実行できるようにしておくと復旧が速くなります。

まとめ

Webサーバーのバックアップで最も大切なのは「自動化」「多重化」「定期的なテスト」です。手動に頼らず自動で保存し、同じバックアップを複数の場所に残してください。
実践例：週に1回のフルバックアップ＋毎日の差分、さらに重要データはクラウドと外付けHDDに保存する。レンタルサーバーの自動機能やプラグインを活用すれば手間を減らせます。
安全対策：バックアップは暗号化し、アクセス権を限定してください。保存期間（保持ポリシー）を決めて古いデータは整理しましょう。
復旧準備：復元手順書を作り担当者を明確にします。定期的に復元テストを行い、問題点を洗い出して改善してください。
運用の習慣化：ログや通知で異常を早期検知し、バックアップの成功を監視します。小さな対策を継続すれば、障害発生時の影響を大きく減らせます。

まずは自動化から始め、少しずつ多重化やテストを増やして安全な運用を目指してください。