誰も元に戻してくれない　サーバー障害から事業を守るために必要な備え

レンタルサーバーに大きな障害が発生しても、サーバー会社がホームページやメール、失われたデータをすべて元に戻してくれるとは限りません。

補償や損害賠償について話し合うことはできます。しかし、補償が決まるまで業務を止めて待つわけにはいきません。

自分の事業を守るために、現実的にできることは次の3つです。

障害で停止したサーバーと、外部バックアップから正常なサーバーへデータを移す様子を示すイラスト

信頼できるサーバーを選ぶ
サーバーとは別の場所に、復元可能なバックアップを持つ
業務を止められない場合は、メールの別保存とサイトの待機環境を用意する

スマイルサーバーで発生した深刻な事態

NTTスマートコネクトが提供するレンタルサーバー「スマイルサーバー」では、2026年7月24日、一部のサーバー設備で第三者による不正アクセスが確認されました。

被害拡大を防ぐため、対象サーバー上のすべてのサービスが停止されました。

2026年8月19日時点の公式発表では、次の状態が続いていました。

ホームページやメールなどのサービスを利用できない
サーバー内のデータを利用者へ渡すことができない
利用者自身でホームページやメール環境を再構築する必要がある
復旧環境の提供開始は、2026年9月中旬頃を目標としている。ただし、調査結果により時期が前後する可能性がある
顧客情報が外部に漏えいした事実は確認されていないが、調査は継続中

データを渡せない理由は、不正アクセスの影響を受けている可能性があり、そのまま利用すると二次被害につながるおそれがあるためです。

サービスを停止した判断自体は、被害拡大を防ぐために必要だったと考えられます。

しかし、対象利用者から見れば、約4週間にわたって元のサーバーを利用できず、データも取り出せない状態でした。NTTスマートコネクト公式発表

誰かが元に戻してくれるとは限らない

レンタルサーバーを利用していると、サーバー会社がホームページやメール、データを常に保護してくれているように感じます。

ところが、実際の責任範囲は契約やサービス仕様によって異なります。

スマイルサーバーの利用規約では、サーバー内のデータが滅失、毀損、漏えいした場合でも、同社に故意または重大な過失がある場合を除き、原則として責任を負わない内容になっています。

サービスをまったく利用できなかった場合の賠償も、利用できなかった時間と料金を基準に上限が定められています。逸失利益などの間接損害は、賠償対象外とされています。スマイルサーバサービス利用規約

仮にホームページの再構築に数十万円かかっても、同じ金額が補償されるとは限りません。

メールが使えなかったことで商談を失っても、それを損害として証明し、サーバー会社へ請求するのは簡単ではありません。

なお、今回の不正アクセスについては、2026年8月19日時点で原因や影響範囲が調査中です。顧客情報が外部に漏えいした事実は確認されていませんが、調査完了前であり、スマイルサーバ側の過失を断定することはできません。

補償されてもデータは戻らない

金銭的な補償を受けられたとしても、次のものが自動的に元へ戻るわけではありません。

長年更新してきたホームページの記事
WordPressの設定やカスタマイズ
お問い合わせフォームから受信した内容
サーバー上だけに保存されていたメール
顧客から預かった画像やPDF
会員情報や予約情報
制作途中のファイル
障害直前に更新されたデータ

消失したデータが唯一のものであれば、金銭では取り戻せません。

サーバー会社と責任について話し合っている間も、ホームページの再構築、メールの再設定、顧客への説明が必要です。

結局、復旧作業をするのは自分か、自分が依頼した制作会社・システム会社になります。

「バックアップ機能がある」だけでは不十分

サーバー会社がバックアップ機能を提供していても、それだけで安心とはいえません。

確認すべきなのは次の点です。

何日分保存されるのか
どのデータが対象なのか
メールも保存されるのか
復元は自分で行うのか、サーバー会社が行うのか
復元に費用がかかるのか
障害発生時にもバックアップへアクセスできるのか
本番サーバーとは別の設備に保存されているのか
不正アクセスを受けた場合でも安全に取り出せるのか

今回のようにサーバー設備全体が調査対象になれば、同じ環境にあるバックアップも、すぐには利用できない可能性があります。

必要なのは、サーバー会社が用意したバックアップとは別に、自分で管理するバックアップを持つことです。

バックアップはサーバーの外に置く

WordPressサイトであれば、少なくとも次のデータをサーバー外へ保存します。

WordPressのデータベース
テーマ
プラグイン
アップロード画像
PDFなどの掲載ファイル
wp-config.phpなどの設定情報
DNSやメールアカウントの設定記録

保存先には次のような選択肢があります。

別会社のクラウドストレージ
別会社のサーバー
社内のNAS
外付けSSD
制作会社が管理するバックアップ環境

重要なのは、稼働中のサーバーと同時に失われない場所へ保存することです。

同じサーバー内の別フォルダにコピーしただけでは、サーバー全体が停止した場合に取り出せません。

バックアップは「ある」ではなく「戻せる」が基準

バックアップを保存していても、実際に復元できなければ意味がありません。

よくあるのが次のような状態です。

バックアップファイルが壊れている
データベースしか保存されていない
画像ファイルが含まれていない
保存処理が数か月前に止まっている
復元方法を誰も知らない
管理画面のパスワードが分からない
契約担当者が退職している
復元先のサーバーを用意できない

バックアップは定期的に復元テストを行う必要があります。

テスト環境や別のサーバーへ復元し、次の内容を確認します。

ホームページが表示される
WordPressの管理画面へログインできる
画像やPDFが表示される
お問い合わせフォームが動作する
必要なデータが復元されている

IMAPはメールサーバーが止まると利用できない

IMAPは、サーバー上にあるメールを複数の端末から確認するための仕組みです。

メールソフトが過去のメールをパソコン内に保存していれば、サーバー停止中でも一部を読める場合があります。

しかし、次のメールは確認できない可能性があります。

パソコン内に保存されていない過去のメール
ダウンロードされていない添付ファイル
サーバー停止後に届いた新着メール
別の端末だけで確認していたメール

サーバーが停止してから過去のメールを取り出そうとしても、サーバーへ接続できなければ何もできません。

過去メールを別のメールサービスにも保存する

対策の一つが、普段から別のメールサービスへメールを転送しておくことです。

会社のメールアドレスに届いたメールを、別事業者のメールサービスにも転送します。

これにより、契約しているメールサーバーが停止しても、転送済みの過去メールを別のサービスから確認できます。

設定時には次の点を確認します。

元のメールサーバーとは別の事業者を使う
転送先に十分な保存容量を確保する
顧客情報や機密情報を保存してよいサービスか確認する
迷惑メール判定や転送失敗の有無を確認する
転送先にも二要素認証を設定する
実際にメールが届いているか定期的に確認する

同じサーバー内に別のメールアドレスを作って転送しても、サーバー全体が停止すれば一緒に使えなくなります。

転送だけでは新着メールを守れない

別サービスへの転送は、過去メールを確認する対策にはなります。

ただし、元のメールサーバーが停止してメールを受信できない場合は、転送処理そのものが動きません。

つまり、サーバー停止後に送られた新着メールまで、必ず転送先へ届くわけではありません。

メールを継続して受信するには、緊急時にメールの配送先を示すDNSのMXレコードを、別のメールサービスへ切り替えられるように準備しておく必要があります。

これは単純な転送設定より難しくなります。

メールを止められない企業では、事前にサーバー会社や制作会社と切り替え方法を確認しておくべきです。

サイトは別サーバーに待機環境を用意する

ホームページも、バックアップを保存するだけでなく、別のサーバーに同じサイトを用意しておく方法があります。

料金はかかりますが、次の構成にします。

通常運用する本番サーバー
本番サイトのデータを定期的に同期する別会社の待機サーバー
障害発生時に切り替えられるDNSの管理環境

本番サーバーが停止した場合は、ドメインの接続先を示すDNSを待機サーバーへ切り替えます。

元のサーバーが復旧するまで、別のサーバーでホームページを表示できます。

「自動転送」というよりは、別サーバーへの「同期・複製」と考えた方が正確です。

待機サーバーは事前の動作確認が必要

別のサーバーを契約してWordPressをコピーするだけでは不十分です。

事前に次の内容を確認します。

別サーバーでも正常に表示できるか
WordPress、テーマ、プラグイン、画像、データベースが同期されるか
PHPやデータベースのバージョンに問題がないか
SSL証明書を利用できるか
お問い合わせフォームからメールを送信できるか
DNSを切り替える権限と手順が整理されているか
元のサーバーへ戻す手順が決まっているか

更新頻度の低い会社案内サイトであれば、1日1回程度の同期でも実用になる場合があります。

一方、次のようなサイトでは単純な定期コピーだけでは不十分です。

ECサイト
予約サイト
会員サイト
掲示板や投稿機能のあるサイト
頻繁にお問い合わせ情報を保存するサイト

障害直前の注文や予約が待機サーバーへ同期されていなければ、切り替え時にデータが失われます。

更新頻度の高いサイトでは、短い間隔での同期やデータベースの複製など、より専門的な構成が必要です。

DNSの切り替えも事前準備が必要

障害が起きてからDNSの管理情報を探していると、復旧が遅れます。

次の内容を整理しておきます。

DNSを管理している会社
管理画面へログインできる担当者
二要素認証の復旧方法
変更するDNSレコード
待機サーバーのIPアドレス
メール用MXレコードの切り替え先
切り替え前後の確認手順

DNSを変更しても、すべての利用者へ即時に反映されるとは限りません。

DNSには、情報をどの程度の時間保存するかを示すTTLがあります。TTLが長いと、接続先を変更しても古いサーバーへアクセスする状態がしばらく続きます。

障害対策として待機サーバーを運用する場合は、平常時からTTLと切り替え手順を確認しておく必要があります。

バックアップと待機環境は目的が違う

バックアップ、メール転送、待機サーバーには、それぞれ別の役割があります。

対策	主な目的
バックアップ	消失・改ざんしたデータを過去の状態へ戻す
メールの別保存	転送済みの過去メールを別環境から確認する
予備メール環境	元のメールサーバー停止中も新着メールを受信する
待機サーバー	本番サーバー停止中もサイトを表示する
DNS切り替え	利用者の接続先を待機環境へ変更する

バックアップがあっても、復元作業が終わるまでサイトは表示できません。

待機サーバーがあっても、改ざんされたデータまで同期してしまえば、正常な状態へ戻せないことがあります。

そのため、重要なサイトでは次の両方が必要です。

すぐに切り替えられる待機環境
過去の正常な状態へ戻せる複数世代のバックアップ

信頼できるサーバーをどう選ぶか

有名企業や大企業が運営しているから、絶対に障害が起きないとはいえません。

見るべきなのは会社名だけではなく、サービスの内容です。

障害情報を迅速に公開しているか
過去の障害原因と再発防止策を説明しているか
バックアップの保存場所と世代数が明確か
復元方法と費用が明記されているか
サポート窓口へ連絡できるか
セキュリティ更新を継続しているか
二要素認証やアクセス制限を利用できるか
サービス停止時の代替環境があるか
利用規約の免責範囲を確認できるか
事業用途に必要な可用性が確保されているか

月額料金の安さだけで選ぶと、障害時の復旧作業や営業損失の方が高くなる場合があります。

ただし、高額なサーバーなら安全ということでもありません。

保存するデータの重要度と、停止した場合の影響に合わせて選ぶ必要があります。

制作会社に任せている場合も確認する

ホームページの管理を制作会社へ任せている場合も、何をどこまで任せているのか確認します。

バックアップを取っているのは誰か
どこへ保存しているのか
何世代保存しているのか
復元作業は保守料金に含まれるのか
別サーバーへの緊急移転に対応できるか
メールの転送や予備環境を用意できるか
ドメインとDNSの管理権限を誰が持っているか
サーバー契約者は誰か
復旧に必要なIDとパスワードを誰が管理しているか

「制作会社に任せているから大丈夫」ではなく、障害発生時に誰が何をするのかを決めておく必要があります。

事故が起きる前に確認する

最低限、次の対策は行えます。

サーバー外へ毎日バックアップする
複数世代のバックアップを残す
定期的に復元テストを行う
重要メールを別のメールサービスにも保存する
緊急時のメール受信方法を確認する
ドメイン、DNS、サーバーの管理情報を整理する
サイトを止められない場合は待機サーバーを用意する
DNSとメールの切り替え手順を決める
緊急時に依頼する担当者を決める
保守契約の復旧範囲を確認する

すべてのサイトに高度な冗長化が必要なわけではありません。

まずは、現在のサーバーが今日使えなくなった場合に、どのデータが残り、誰がどのように復旧するのかを確認することです。

誰かが守ってくれることを前提にしない

サーバー会社には、安全なサービスを提供する責任があります。

大きな事故が発生した場合には、原因を調査し、利用者へ説明し、必要な補償を行うべきです。

しかし、事故が起きたあとにサーバー会社の責任を追及しても、業務に必要なデータがすぐに戻るとは限りません。

誰もホームページを再構築してくれない。

誰もメールを再設定してくれない。

誰も失われたデータを元に戻してくれない。

だからこそ、何も起きていないときに準備しておく必要があります。

バックアップは、壊れたデータを元に戻すためのものです。

待機環境は、障害中も業務を続けるためのものです。

この2つを分けて考えることが、サーバー障害から事業を守る最初の一歩になります。