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

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

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

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

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

• 信頼できるサーバーを選ぶ

• サーバーとは別の場所に、復元可能なバックアップを持つ

• 業務を止められない場合は、メールの別保存とサイトの待機環境を用意する

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

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

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

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

• ホームページやメールなどのサービスを利用できない

• サーバー内のデータを利用者へ渡すことができない

• 利用者自身でホームページやメール環境を再構築する必要がある

• 復旧環境の提供開始は、2026年9月中旬頃を目標としている。ただし、調査結果により時期が前後する可能性がある

• 顧客情報が外部に漏えいした事実は確認されていないが、調査は継続中

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

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

しかし、対象利用者から見れば、約4週間にわたって元のサーバーを利用できず、データも取り出せない状態でした。

2026年10月20日追記：9月8日から、停止時点の7月24日のデータと設定を復元した環境の申込みが始まりました。希望する対象契約者への提供で、申込期限は11月25日です。停止後の更新データは自動統合されず、安全性確認で一部ファイルが除外される場合もあります。利用者側でデータの確認・移行・動作確認が必要です。公式の復旧環境申込案内を確認してください。本文の8月19日時点の記述は、当時の経過として残しています。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つを分けて考えることが、サーバー障害から事業を守る最初の一歩になります。

関連リンク

復旧対象のサーバー・データベースと接続先の管理を理解するには、サーバー、データベース、ドメインを参照してください。

関連する用語・実践記事

• 二要素認証

転載元

この記事は「業務改善推進プロジェクト」に掲載したコラムの転載です。

誰も元に戻してくれない　サーバー障害から事業を守るために必要な備え｜業務改善推進プロジェクト

関連記事

あわせて読みたい記事はこちらです。