サーバーパネル内は頻繁には触らないので見逃していましたが、バックアップに関する機能がいくつか確認できます。
ただ少し分かりくにかったのでメモ的にまとめつつ、2026年7月に発生したスマイルサーバーの不正アクセス被害にも絡めて記載したいと思います。
ただしこの種の作業を専門的に対応している訳ではないので正確性は保証できない点にご留意ください。
前提
- XServerのスタンダードプラン利用
- WordPress運用中
- メール運用中
- バックアップ用のプラグインは使用せず、サーバーに付属するバックアップ機能を用いる
実際に契約している運用中のサーバーで試しましたが、記事に趣旨的にバックアップ用のプラグインは使わない前提です。
結論的私見
長くなるので先に「自動バックアップ」機能に関する結論的な私見を記載します。
- 全プランに付属している機能で常に稼働しており、追加費用なしで利用できる
- メールの復元や取得も可能
- 復元対象は過去14日間であり、全体やドメイン単位などで対象を限定することができ、管理画面内のプルダウンから選んでボタンを押すだけで復元可能
- 過去14日間の制限がが許容できるなら、プラグイン対応よりも良い選択肢となる可能性が高い
- バックアップの取得と手動復旧作業を併用すると、多くの状況に対応できる可能性が高まる
他方、XServerでは以下のように他にも選択肢が存在するので、目的次第では「自動バックアップ」機能はあまり使わないかもしれません。
- WordPressのみを対象とするなら、不正アクセス等によるファイル改竄にも簡易に対応できる可能性がある「WordPressリカバリー」機能を使う方が良い
- ステージング機能(カスタマイズやアップデート時に有用)や死活監視アラート(サーバーダウンの検知)等の運輸の安全性が重要なら、「XServer for WordPress
」プランに移行する方がよい - ファイル改善検知等の高度なセキュリティ機能が必要なら「XServerビジネス
」プランに移行する方がよい
ただし、収容サーバ単位で不正アクセスに被害に遭った場合は以下のようになると思われます。
- ローカルに保存したバックアップファイルによる復元が唯一の手段(「自動バックアップ」の「取得」や手動バックアップで作成)
長期的にみれば、侵害がないことを確認された場合はサーバーが丸ごと復旧する可能性もあります。
しかし可能性は不明であり、可能であっても3ヶ月以上かかると思われ、手元のバックアップデータで新しい環境に復元するしかないと思われます。
WordPressリカバリー
上記ページ内で説明されていますが、以下のように状況に合わせて復旧の種類を選ぶ形です。
- 正しく表示されなくなったWordPressの復旧
- 不正アクセスを受けたWordPressの復旧
- ログインできなくなったWordPressの復旧
- ログインパスワードのリセット
- WordPress本体のリセット
ただし、「サイトを完全に復旧することを保障するものではない」とのことで注意が必要です。
公式ヘルプでは各復旧に種類が具体的にどういう処理をしているのかという説明が見当たらないようで、復旧後に問題が発生した場合は対処が困難になるのかもしれません。
また、ヘルプ等に記載がないものの管理画面内の文言から、以下がリカバリー対象となる条件の模様です。
- 管理画面から「簡単インストール」でインストールしたWordPressのみが対象
Web改ざん検知
- 1サイトのみが対象
- 1日1回、診断開始URLからリンクをたどり、30ページ分のWebページを診断
対象はwebページのみで30ページまでであり大味な印象です。
しかしながら「Web改ざん検知」がなければ検知数は確実に0ですし、あった方がよいことは確かです。
さくらインターネットでは有料オプションとして「Web改ざん検知サービス」が提供されていますが、最低価格プランの対応ページ数は30ページなので、業界的にはこのページ数で最低限の効果はあるということかもしれません。
なお、プランを上げることで100ページ、300ページ、1000ページとページ数は増えていきます。
Xserverのバックアップ
概ね以下の各ページの内容とリンク先で「自動バックアップ」の実行と復元に関する詳細が確認できます。
大まかには以下の対象2種と手法2種の組み合わせで計4種類となります。
| 対象 | 手法 |
|---|---|
| サーバー領域 ファイルマネージャーやFTP等でアクセスできる範囲 |
自動バックアップ(取得・復元) |
| 手動(取得) | |
| MySQLデータベース | 自動バックアップ(取得・復元) |
| 手動(取得) |
サーバー領域のバックアップ機能には、サーバーパネルの左メニュー内にある「サーバー」をクリックして下層項目を表示させる必要があります。
自動と手動でメニュー項目が分かれています。
MySQLデータベースの場合は、同じく左メニュー内にある「データベース」をクリックする必要があります。
自動と手動でメニュー項目が分かれておらず、移動後の画面内にあるタブで自動と手動の機能を切り替えることができます。
自動バックアップ
「自動バックアップ」は以下のような機能の模様です。
- 全プランに付属している機能
- 自動で毎日バックアップされている
- 過去14日分が保存されており、その範囲内であればプルダウンで日付を選んで復元できる
- 自動でバックアップされたデータを手動で取得しダウンロードできるが、24時間で削除され、そのバックアップデータを用いて自動で復元する機能はない
公式ヘルプでは下記のように「申し込み」という言葉が使われていますが、実際にはサーバー側にフォーム等から対応を依頼する形ではありません。
ユーザー側の操作のみで完結します。
待ち時間は対象のファイル数やデータ量によるので、数分かそれ以上待つことになると思います。
サーバーパネル上の「バックアップ」より、ご希望のバックアップ対象データをご指定の上、お申し込みください。
詳細な手順はマニュアルをご参照ください。
サーバー領域の取得と復元の対象
選択肢としては以下のまず2種類があります。
- すべてを取得(or復元)
- 対象を指定して取得(or復元)
具体的には以下のファイル群が対象となります。
| Web領域 | 対象ドメインの「public_html」ディレクトリのデータ |
|---|---|
| Web用設定ファイル | 対象ドメインの「public_html」「mail」ディレクトリ以外のデータ |
| メール領域 | 対象ドメインの「mail」ディレクトリのデータ |
なおメールに関しては、Quoted-Printableでエンコードされたファイルとなり、1メールが1ファイルに該当する形で保存されます。
エンコードの結果本文は読める状態でないため、本文を読みたい場合は何らかのシステムやサービスで複合する必要があります。
ただし外部のサービスを利用すると情報漏洩の危険性があるため、できるだけローカルで何とかすることをお勧めします。
Quoted-Printableに関しては以下などを参照ください。
すべてを取得
サーバーで設定したすべてのドメイン内の「Web領域」「Web用設定ファイル」「メール領域」のファイルが取得と復元の対象となります。
画像等の重いデータの存在を考えると、状況次第では膨大なデータ量になる可能性があります。
対象を指定
ドメインの指定と、そのドメイン配下の「Web領域」「Web用設定ファイル」「メール領域」のそれぞれを任意で選択可能です。
データ量や復元時実務も考えると範囲は限定的な方が良いので、前項の「全て」よりも対象を指定した方が良いように思います。
MySQLデータベースの取得と復元の対象
- データベース単位で取得と復元が可能
すべてのデータベースを一括でという機能はないため、データベース単位で取得と復元を行います。
取得実行後データの保存の期間と状態
少しややこしいですが以下のようになります。
- 「自動バックアップ」で保存されているデータは14日間保存され、15日前のデータは削除される
- 「自動バックアップ」で取得したデータは、サーバー内に新たに保存され24時間経つと削除される
- 保存場所は１箇所しかないので、24時間以内に複数回取得を実行すると、実行のたびに上書きされる
つまり「自動バックアップ」と「取得」は別の仕組みであり、「自動バックアップ」のデータはユーザーが触れるサーバー領域には存在しておらず、FTP等を用いても直接アクセルはできません。
取得したバックアップは、「自動バックアップ」で保存しているデータをユーザーが触れる場所にコピーしているイメージであり、24時間で削除という制限は取得を実行したデータのみに適用されます。
取得実行後のデータの保存箇所
- サーバー領域: /home/サーバーID/userbackup/
- MySQLデータベース: /home/サーバーID/backup/
「ダウンロードする」などのボタンが存在しないため、ファイルマネージャーかFTP等でサーバー内にアクセスして取得する必要があります。
クライアントなどの普段はサーバーにアクセスしない方からすると実行困難な可能性が高いです。
しかしどちらにせよ、取得したデータで復元するにはサーバーにアクセスする必要があり、取得が困難な時点で対象外とも考えられます。
復元機能の対象となるバックアップデータ
- 「自動バックアップ」のページのプルダウンで選択可能な過去14日分
- 「自動バックアップ」で取得したデータは、「自動バックアップ」の復元機能では使用できない
「自動バックアップ」の復元で指定できるのは、管理画面内のプルダウンで選べる過去14日分のいずれかのみです。
仮に1ヶ月や1年前のデータを手元のPCやストレージに保存していた場合、そのデータは手動作業でしか利用できません。
この点後述する手動バックアップとも共通する点であり、復元機能を持つプラグインとの明確な差になります。
「自動バックアップ」の対象外
公式ヘルプの引用を見る
また、以下の領域に存在するデータは対象外として、本機能ではバックアップを取得いたしません。あらかじめご了承ください。
- /home/（サーバーID）/（ドメイン名）/public_html/wp-content/cache ディレクトリ配下
- /home/（サーバーID）/（ドメイン名）/public_html/wp-content/plugins/（プラグイン名）/cache ディレクトリ配下
- /home/（サーバーID）/（ドメイン名）/public_html/wp-content/debug.log
- /home/（サーバーID）/（ドメイン名）/public_html/（任意のディレクトリ）/wp-content/cache ディレクトリ配下
- /home/（サーバーID）/（ドメイン名）/public_html/（任意のディレクトリ）/wp-content/plugins/（プラグイン名）/cache ディレクトリ配下
- /home/（サーバーID）/（ドメイン名）/public_html/（任意のディレクトリ）/wp-content/debug.log
- /home/（サーバーID）/Maildir ディレクトリ配下
- /home/（サーバーID）/Maildir.（数値） ディレクトリ配下
- /home/サーバーID/ドメイン/xserver_php/session/
契約サーバーアカウント内に存在するファイル数が非常に多い状況などにより、バックアップの処理に大きな負荷がかかったり、処理があまりにも長時間に及ぶような場合など特殊な事由によって、ごくまれに一部のアカウントに関してバックアップの対象外とする場合があります。
万が一対象外とする場合は、該当のお客様個別にお知らせいたします。
公式ヘルプを見ると以下の理解になると思いますが、おそらく大きな問題はないのではと思います。
- キャッシュ系のデータはバックアップされない
- Maildirとsesscionなどの特殊なディレクトリもバックアップされない
手動バックアップ
手動バックアップは以下のような機能の模様です。
- 全プランに付属している機能
- 実行時点でのバックアップデータを取得でき、ボタンでダウンロード可能
ファイルマネージャーやFTP等を用いる必要がないため、手動でダウンロードする作業を簡易に実行できる便利な仕組みという印象です。
サーバー領域
- ドメイン単位ではなく、任意のディレクトリを対象にして取得できる
「自動バックアップ」よりも細かく対象を選んでバックアップ可能です。
例えばWordPressを使用している場合は、uploadsディレクトリ内の特定の月日のディレクトリを圧縮状態でダウンロードできます。
プラグインによるバックアップとの比較検討
ここまでを踏まえてプラグインと比較すると、大まかには以下のように考えられます。
- プラグイン利用によるリスクが許容できるなら、任意のタイミングで作成したバックアップから簡易に復元できる点でプラグインによるバックアップの方が有効
- 復元用バックアップが最大で14日前という制限が許容でき、空きサーバ容量に余裕があるなら、プラグインのリスクがなく安定して動作するXServer付属の「自動バックアップ」の方が有効
- メールやWP以外のファイルまで含めるなら、XServer付属の「自動バックアップ」が必要
プラグインの対象はWordPressのみですが、XServerの自動(手動)バッアップの対象はサーバー内のほぼ全域に及ぶため、この点は前提として大きな違いとなります。
過去14日間という制限は、復元が必要になった際の状況次第となります。
例えばユーザーがの作業ミスやシステム障害時であれば「過去14日間以内のどこかの時点に戻せれば良い」という状況は十分のあり得ますので、この場合は過去14日間の制限は問題になり得ません。
それぞれで想定されるリスクを見る
- 共通のリスク
-
- 提供が停止される可能性がある
- 有料である、あるいは今後有料になる可能性がある
- 脆弱性がありセキュリティに穴を開ける可能性がある
プラグイン利用時にしか当てはまらないように思えますが、XServerが「自動バックアップ」のサービスを停止する可能性も0ではないので、一応共通したリスクだと考えられます。
- プラグイン利用によるリスク
-
- ユーザー側でアップデートに対応する必要があり、アップデート時に問題が発生する可能性がある(PHPエラー等で真っ白の画面になるなど)
- 復元に失敗する可能性がある(バックアップ作成時と先のPHP等のバージョンが異なる場合など)
- バックアップデータ量が多いと、無料プランでは復元できなかったり、対応不可の可能性がある
復元時の動作しない実例として、All-in-One WP Migrationでは以下の問題が起こりました。
- バックアップデータと復元先のPHPのバージョンが異なり、エラーがでて復元できない
上記は公式のヘルプでも触れられているので仕様ではありますが、「保存しておいたデータで復元できる」という利点が成り立たないということになります。
ただし成功した事例もあり、必ずエラーになるというわけではないようです。
- XServerの「自動バックアップ」のリスク
-
- 最大で14日前のデータしか指定できない
- 取得したバックアップデータでは復元機能が使えず、手動で作業を行う必要がある
- サーバーに十分な空き容量が必要
- ファイルとデータベースでバックアップが分かれているので、片方だけ行うと問題が起こる可能性がある
サーバーの空き容量に関しては、復元時に「すべてを復元」を選らんだ場合、おそらく使用データと同量程度の空き容量が必要になるのではと思います。
つまり半分以上の容量を使用している場合は復元に失敗する可能性があります。
この場合は「対象を指定して復元」を用いて分割して復元を実行することで対応可能だと思われます。ファイルとデータベースでバックアップが分かれている点に関しては、以下の状況が発生すると何かしら問題が発生するかもしれません。
- ファイルは復元したが、データベースは以前のまま
- データベースは復元したが、ファイルは以前のまま
プラグインによるバックアップを実行する場合も、バックアップ作成時の設定次第で同種の状況になり得ます。
しかし同様に設定でデータベースを含めて全てをまとめた状態でバックアップファイルを作成できるため、バックアップの作成も復元も簡易に対応できる点が異なります。
スマイルサーバーの不正アクセス被害実例に基づく検討
2026年7月にスマイルサーバーが不正アクセスの被害に遭い、その影響を受けたクライアントの対応を行いました。
このセクションではスマイルサーバーの不正アクセス被害時の対応経験に基づき記載します。
不正アクセスによるサーバーの状態
不正アクセスによって以下の状況が発生しました。
- 収容サーバー内の1サイトが被害にあったのではなく、収容サーバー自体が被害にあった(2サーバー分)
- 被害拡大を防ぐため、収容サーバー自体の機能が停止された
- 調査等の諸々の完了までサーバーの停止が続く
上記のサーバー機能の停止は以下の問題を引き起こします。
- サーバー管理画面に入れないため、各種設定等が確認できずない
- FTP等でサーバーにアクセスできず、ファイルの取得ができない
(=サーバー内にしかバックアップデータを保存していない場合は取り出せず、アップロードしていた画像も取り出せない) - MySQL等のデータベースにアクセスできず、データが取得できない
- メールアカウントにアクセスできず、メールの送受信ができない
- サイトはドメインが存在しないのと同じ状態になる(404等のステータスコードも返されない(はず))
加えて、調査が完了しない時点では以下の問題も発生します。
- ローカルに保存していたバックアップが汚染されている可能性があり、安全を確認する必要がある
復旧対応
ここまでの状況から以下のようになり、スマイルサーバーから提案された代替サーバーへの移行も困難な状況になります。
- サーバー内にバックアップを保存している場合は、全く役に立たない
- ローカルに保存したバックアップが使用可能とは限らない(調査が完了しないので不正アクセスの開始期間が分からず日付による判定ができない)
- サーバー機能が停止しているので、サーバー移転もできない
幸い私のクライアントは、2025年5月にスマイルサーバーのシステム更新があった際にサイトのリニューアルを行なっていたので、その時点での侵害はないと考えて当時作ったバックアップを用いて復旧が行えました。
もしもリニューアルを行なっていなかった場合は、作業の都合で取得した部分的なバックアップしかなかったので仮サイトしか作れなかったかもしれません。
さらに言えば、何もバックアップがない場合は新規作成するしかありません。
XServerに置き換えた検討
サーバー内部の仕様などが関係すると思いますので根拠は薄いですが、スマイルサーバー同様に収容サーバー自体が被害を受けた状況を想定すると以下のように考えられます。
- 「Web改ざん検知」で検知できた可能性はかなり低い
- 「自動バックアップ」「WordPressリカバリー」の機能が使える可能性はかなり低い
- バックアップ(サーバー領域+MySQLデータベース)を取得しローカルに保存していた場合は、復旧に用いれる可能性があるが、安全性の調査や復旧を手作業で行う必要がある
つまり有効な対策としては、復旧を主目的とした素材確保として以下になると思います。
- 定期的に「自動バックアップ(or手動)」で取得を実行し、ローカルへバックアップを保存しておく
- バックアップは「サーバー領域」と「MySQLデータベース」の2種類が必要
プラグインを用いる場合
- 可能なら復元機能がある複数のプラグインでバックアップを定期的に取得する
失ったサーバーと復旧先のサーバーの条件が同じでない可能性を考えると、復元機能を持つプラグインは複数使った方が安全性が高いように思います。
利便性の点では「All-in-One WP Migration」が便利だと思います。
安全性の点では「BackWPup – WordPress バックアップ & 復元プラグイン」の方が良いかもしれません。
「BackWPup」の圧縮バックアップデータを解凍すると確認できますが、画像含めて構成ファイルがそのまま入っているようなので、もしもプラグインによる復元時にエラーが出た場合でも復旧素材として使いやすいように思われるためです。
クライアント観点
「クライアント自身でバックアップの保存を実行可能か否か」という点では、XServerもプラグインもプルダウンやボタン操作が可能なので一応「クライアント自身で対応可能」と言えます。
しかし現実的には、XServerの方は該当画面へのアクセス経路やUIの複雑さを考えるとハードルが高いため、クライアント自身での対応は難しいと思われます。
そのためプラグインでの対応の方が良いと思われます。
自動で外部ストレージに保存する機能を持つプラグインもありますし、そういった仕組みを利用することも検討できます。
ただしオンラインストレージは容量制限がある上、適切に管理されていない可能性もあり、「設定すれば何もしなくて良い」とはならないかもしれません。
「クライアント自身でバックアップを用いて復元可能か否か」という点では、実行は可能ですが成功するかどうかはやってみないとわからないという結論になると思います。
この点はWordPressのコアやプラグインのアップデートと同様です。
結び
システム障害等への対応であれば、XServerの「自動バックアップ」は有効な方法に思えます。
実行後が正常であるかが少し怖いですが、「WordPresリカバリー」の機能を使うとより簡単に対応できる可能性もあります。
他方、不正アクセスへの対応であれば状況は変わりますので、諸々確認の上アクションを決める必要があります。
補足
不正アクセス時にサイト復旧以外で必要となる作業例
当記事ではほぼ触れていませんが、サーバー停止時に最も問題なのはメールの送受信ができない点です。
「サイトに問題が生じており閲覧できません。復旧までお待ちください。」などを顧客に伝えることができないためです。
SNS等で告知可能な場合はある程度のケアが可能ですが、部分的な対応となる点は否めません。
加えて代替環境が用意されて場合には、一時的な費用減免の確認や、申込時に必要な記述や選択内容の確認も必要となります。
申し込み時の申請内容に不備があると問題になりえます。
ここまでを踏まえると、バックアップを用いた復旧作業も重要なのですが、以下のような関連作業も重要なので、関わる場合は対応範囲が広くなる点を念頭に置いておいたほうがよいかなと思います。
- 代替環境に関する契約の確認(特定期間の比喩が免除されるなど)
- 代替環境への移行手順(被害サーバーの契約内容や設定次第で選ぶべき項目が変わる可能性がある)
- メールアカウントの再設定と、パスワード変更による先方メーラの設定サポート
スマイルサーバーのバックアップ機能
スマイルサーバーにも上記のように有料のバックアップオプションがありますが、見てわかる通り素人の方が利用できるものではありません。
XServerの「自動バックアップ」のページと見比べると一目瞭然です。
加えて、やはり不正アクセスによるサーバー停止時には役に立たない機能となります。
0人がこの記事を評価
役に立ったよという方は上の「記事を評価する」ボタンをクリックしてもらえると嬉しいです。
連投防止のためにCookie使用。SNSへの投稿など他サービスとの連動は一切ありません。
