WordPressサイトの復旧作業

最終更新: 2025-10-24 対象: エックスサーバーで利用停止(403エラー)になったWordPressサイトの復旧作業

目次

  1. 概要
  2. 作業の流れ

⚠️ 2週間以内の場合(緊急対応フロー)2週間以上経過(通常対応フロー)

  1. 初期対応(問い合わせ受付時)

⭐ まず顧客を落ち着かせる症状発見時期の確認

  1. 事前調査
  2. 必要情報の収集
  3. サーバー情報の確認
  4. バックアップ作業
  5. 仮設サイト構築
  6. サーバー初期化
  7. メール復旧
  8. WordPress再構築
  9. 監視
  10. 後片付けとセキュリティ対策
  11. 重要な注意事項・ハマりポイント
  12. よく使うコマンド集
  13. テンプレート集

概要

この作業の目的

エックスサーバーから「高負荷により利用停止」の通知を受けたサイトを、サーバー初期化後に復旧させる。

作業の難しさ

  • 画面には403エラーのみ表示
  • WordPressダッシュボードも開けない
  • ダウンロードしたPCもウイルス感染する可能性ある
  • 不正ファイルが残ったままアップロードすると再発する

目指すゴール

  1. サーバーを初期化しても過去メールを復旧させる
  2. メールの停止時間は可能な限り短くする
  3. バックアップデータが確実か仮設サイトで確認する
  4. 打ち合わせでは「もしも」「万が一」などネガティブな言葉は使わない

復旧作業の基本方針

クリーンインストールの原則

基本方針:

データベース + 画像データ = 保持
その他すべて(WordPress本体、テーマ、プラグイン) = クリーンインストール

この方針により:

  • WordPress本体、テーマ、プラグインは最新バージョンで再インストール
  • ウイルスや不正ファイルが紛れ込むリスクを最小化
  • セキュリティホールのある古いバージョンを排除

例外ケース: オリジナルテーマ

オリジナルテーマを使用している場合:

  • WEB制作会社が作ったオリジナルテーマはクリーンインストールできない
  • テーマファイルを1ファイルずつチェックする必要がある
  • もしウイルスが入り込んでいたら手作業での確認が必須
  • 作業時間が大幅に増加する可能性あり

対策:

  1. 不審なPHPコード(eval、base64_decode等)を検索
  2. エックスサーバーから指摘されたファイルと同種のファイルを検索
  3. 最終的には仮設サイトでテーマを動作確認

⚠️ 注意: 一般的なアンチウイルスソフトはWindows/Mac用であり、サーバーOS(Linux)上のPHPファイルに対しては効果が限定的です。ウイルススキャンは気休め程度と考え、手作業での確認とテストサイトでの動作確認が重要です。

作業の流れ

⚠️ 症状発見が2週間以内の場合(緊急対応フロー)

ステップ1. 初期対応・ヒアリング「大丈夫です。任せてください」
ステップ2. 症状発見時期の確認 → 2週間以内!
ステップ3. 【緊急】エックスサーバーの自動バックアップから即座にダウンロード
         ⚠️ 午前2時前に必ず実施すること
ステップ4. バックアップデータの確認
ステップ5. リストアで復旧
ステップ6. 動作確認
ステップ7. セキュリティ対策

このケースでは以下の通常フローは不要です。


症状発見が2週間以上経過している場合(通常対応フロー)

ステップ1. 初期対応・ヒアリング「大丈夫です。任せてください」
ステップ2. 症状発見時期の確認 → 2週間以上経過
ステップ3. 事前調査(Googleキャッシュ、Whois)
ステップ4. 必要情報の収集
ステップ5. サーバー情報の確認
ステップ6. データバックアップ(SSH/FTP経由)
ステップ7. 仮設サイト構築(別サーバーで復旧可能性確認)
ステップ8. サーバー初期化
ステップ9. メール復旧
ステップ10. WordPress再構築
ステップ11. 監視・最終調整
ステップ12. 後片付け・セキュリティ対策

初期対応(問い合わせ受付時)

⭐ 最重要:まず顧客を落ち着かせる

最初にすべきこと:

「大丈夫です。任せてください。」

依頼者は非常に不安な状態です。まず安心してもらうことが最優先です。

  • 落ち着いたトーンで話す
  • 復旧実績があることを伝える
  • これから何をするのか明確に説明する

症状発見時期の確認(最重要ヒアリング)

最初に必ず確認すること:

「いつこの症状に気がつきましたか?」

⚠️ 2週間以内の場合 → 緊急対応フロー

症状発見が2週間以内の場合:

  1. すぐにエックスサーバーの自動バックアップからダウンロード
  2. リストアで復旧できる可能性が高い
  3. このケースではサーバー初期化は不要

エックスサーバーの自動バックアップ仕様:

  • バックアップは毎日午前2時に更新される
  • 過去7日分(または14日分)が保存されている
  • 残業してでも午前2時前にダウンロードすること
  • 午前2時を過ぎると、正常な状態のバックアップが上書きされてしまう可能性がある

緊急バックアップダウンロード手順:

ステップ1: サーバー容量の事前確認(重要)

# SSHでサーバーにログイン後、ディスク使用量を確認
df -h
  • [ ] ディスク使用量を確認
  • [ ] 50%を超えている場合は不要ファイルを削除
  • バックアップディレクトリは大容量
  • 事前に十分な空き容量を確保する必要がある
  • 目安: ディスク使用量を50%以下にする

ステップ2: バックアップ申請

  1. [ ] サーバーパネル > バックアップ > 自動バックアップ
  2. [ ] 症状が出る前の日付のバックアップを申請
  3. [ ] Web、メール、データベース全てを申請

⚠️ 重要:

  • バックアップ申請後、エックスサーバーがbackupという名前のディレクトリを作成
  • 完了まで数時間かかる(サイズによる)
  • 処理状況はサーバーパネルで確認可能

ステップ3: バックアップディレクトリの確認と保護

バックアップが完成したら、SSHで即座に以下を実行:

# backupディレクトリが作成されていることを確認
ls -la | grep backup

# ⚠️ 重要: このディレクトリは翌日消える!
# すぐにディレクトリ名を変更して保護
mv backup backup_YYYYMMDD_保護
# 例: mv backup backup_20251024_保護

⚠️ 超重要: backupディレクトリは翌日には自動的に消えてしまうため、作成されたらすぐに名前を変更すること!

ステップ4: アーカイブ作成(必須)

# tarで圧縮してアーカイブを作成(圧縮オプション必須)
tar czf backup_YYYYMMDD.tar.gz backup_YYYYMMDD_保護/
# 例: tar czf backup_20251024.tar.gz backup_20251024_保護/

# アーカイブが作成されたことを確認
ls -lh backup_YYYYMMDD.tar.gz

⚠️ なぜアーカイブが必要か:

  • アーカイブせずにダウンロードするとエラーが出まくる
  • ファイル数が膨大なため、1つずつダウンロードすると失敗する
  • tarアーカイブにすることで1ファイルとしてダウンロード可能

ステップ5: ダウンロード

# FTPまたはSCPでアーカイブファイルをダウンロード
# ダウンロードが完了するまで他の作業はしない
  1. FTPクライアント(FileZillaなど)またはSCPでアーカイブをダウンロード
  2. ダウンロード完了まで待機(数十分〜数時間)
  3. ローカルでアーカイブを展開して内容確認
  4. データベース、Webファイル、メールデータが揃っていることを確認

⚠️ 重要: このケースでは以下のマニュアルの大部分がスキップされます。リストア作業のみで復旧できます。


2週間以上経過している場合 → 通常対応フロー

2週間以上経過している場合は、以下の通常フローで対応します。

電話/メール受付時に確認すること

こちらが知りたい情報

  • あなたはシステムエンジニアか
  • ウェブサイトのオーナーは誰か
  • 事象が発生したのはいつか(最重要)
  • バックアップはあるのか、感染はないのか
  • エックスサーバーとのやりとりはあるか
  • 依頼する意思はあるか
  • 独自メールは使っているか

相手が知りたい情報

  • この状態から復旧できるのか
  • 復旧まで時間はどれくらいかかるのか
  • 何が原因で感染したのか

依頼者の心理状態(理解しておくこと)

  • とても不安である
  • サーバーの初期化で記事が復活するのか心配
  • できるだけ早く復旧させて欲しい
  • 料金のことも心配
  • エックスサーバーサポートは不親切だと思ってしまう
  • 解説記事があったけど手順が難しい
  • 個人事業主に任せて大丈夫なのか
  • データを消えてしまうのが怖い

事前調査

チェックポイント1: 発生事象の確認

  • エックスサーバーカスタマーサポートからのメールを確認
  • 対象ドメインが403エラーであることを確認
  • Whoisでドメインが有効期限内であることを確認
# Whoisで確認
whois example.com

チェックポイント2: Googleキャッシュで情報収集

  • WordPressのバージョン
  • 使用しているテーマ名とバージョン
  • プラグイン名(わかる範囲で)

エックスサーバーメールから情報抽出

# 検出された不正ファイルからドメインを抽出
cat メール.txt | awk -F"/" '{print $4}' | sort | uniq

必要情報の収集

チェックポイント3: 作業に必要な情報

1. エックスサーバーサーバーパネルのログイン情報

URL: https://www.xserver.ne.jp/login_server.php
サーバーID: hogehoge
サーバーパネルパスワード: piyopiyo

2. 復旧対象ホームページのアドレス

例) https://mydomain.com/

3. 使用しているメールアドレスの一覧

例) info@mydomain.com
    support@mydomain.com
    sales@mydomain.com

4. エックスサーバーサポートからのメール

件名:
本文:(問い合わせ番号を含む)
お客様のサーバーアカウントにおいて、
サーバーに対する負荷が著しく高い状況を確認いたしました。

5. Googleドライブ共有用のGmailアドレス

6. 有料テーマを使っている場合は最新版のテーマファイルを受け取る

サーバー情報の確認

エックスサーバーのサーバーパネルで確認

  • [ ] cronがないかチェック(あったら設定を控える)
  • [ ] ドメイン一覧
  • [ ] メール一覧(復旧時に流し込むのでカンマ区切りテキストファイルに保存)
  • [ ] HTTPSサイトの一覧
  • [ ] 各ドメインのPHPバージョン(重要!)
  • [ ] MySQLのバージョン

⚠️ 重要: PHPバージョンの記録 ドメインを作るとデフォルトはPHP7.2。PHP5.4.16で開発したサイトをリストアすると文法エラーが出る。この確認を怠ると2日潰すことがある。

バックアップ作業

ネットワーク接続

FTP接続

サーバー: sv####.xserver.jp
ユーザー名: サーバーID
パスワード: サーバーパネルパスワード

SSH接続

ホスト名: サーバーID.xsrv.jp
ポート: 10022
ユーザー名: サーバーID
認証方式: 公開鍵認証

SSH接続用configファイル例:

Host xserver-example
  HostName sv####.xserver.jp
  Port 10022
  User サーバーID
  IdentityFile ~/.ssh/your_key_id_rsa
# 接続
ssh xserver-example

データバックアップ手順

方法1: サーバーパネルからダウンロード(推奨)

  • エックスサーバーのサーバーパネルでバックアップ機能を使う
  • tar.gz形式で圧縮される
  • サイズが大きいとダウンロードに失敗することがある(その場合は問い合わせ)

方法2: SSH経由でバックアップ

# バックアップディレクトリ作成
mkdir ~/mybackups

# パーミッション付きのファイルリストを作成
ls -laR ドメイン名 > ~/mybackups/file_list.txt

# ディレクトリごとにtarで固める
tar czf ~/mybackups/domain_name.tar.gz ドメイン名/

# ファイル数を数える(確認用)
find ドメイン名 -type f | wc -l

# すべてのバックアップをまとめる
cd ~/mybackups
tar cvf all_backups.tar *.tar.gz

ダウンロード後の確認

# tarが壊れていないかチェック
tar tvf mybackups.tar | wc -l

# 複数ファイルを一括チェック
for i in `ls *.tar`; do echo ${i}; tar tvf ${i} | wc -l; done

データベースのバックアップ

wp-config.phpからDB情報を抽出

# wp-config.phpを探す
find . -name "wp-config.php"

# DB情報を抽出
grep "DB_NAME\|DB_USER\|DB_PASSWORD\|DB_HOST" wp-config.php

MySQLからエクスポート

# SSHでサーバーにログイン後
mysqldump -h MySQLホスト名 -u DBユーザー名 -p DB名 > backup_db.sql

# 例
mysqldump -h mysql####.xserver.jp -u example_wp1 -p example_wp1 > example_wp1.sql

Googleドライブ共有

共有フォルダの構成

顧客名様用共有フォルダ/
├── thema_plugins/
│   ├── 受け取った有料テーマ(最新版)
│   └── ダッシュボードからインストールできないプラグイン
└── backups/
    ├── Web/
    │   └── WordPressとメールのデータ
    └── DB/
        └── エクスポートしたDBデータ
  • [ ] フォルダに一箇所にまとめてダウンロード
  • [ ] GoogleドライブとSSDの両方に保管
  • [ ] お客さんと共有するが読み取り専用に変更してから共有

仮設サイト構築

仮設サイトの目的

顧客のサーバーとは別のサーバーに仮設サイトを構築し、以下を確認する:

  • バックアップデータからサイトが復旧できることを確認
  • 顧客に復旧可能であることを見せて安心してもらう
  • 本番作業前にプラグインやテーマの動作確認

仮設サイト構築先の選択

オプション1: エックスサーバーの初期ドメイン(推奨)

メリット:

  • 顧客、エンドユーザーが参照できて安心してもらえる
  • 終わったらドメインの初期化で削除できる
  • 複数ドメインの場合はサブドメインを使って構築可能

構築手順:

  1. 顧客サーバーの初期ドメイン(xxx.xsrv.jp)を使用
  2. または、初期ドメインのサブドメインを作成
  3. BASIC認証を設定して一般公開を防ぐ

オプション2: 別のエックスサーバーアカウント

メリット:

  • 顧客のサーバーに影響を与えない
  • 独立した環境で作業可能

仮設サイト構築手順

1. WordPress簡易インストール

  • [ ] エックスサーバーの簡易インストール機能でWordPressをインストール
  • [ ] 記録しておいたPHPバージョンに設定
  • [ ] 記録しておいたMySQLバージョンに設定

2. データベースのインポート

# SSH接続してデータベースをインポート
mysql -h MySQLホスト名 -u DBユーザー名 -p DB名 < backup_db.sql

3. Webデータのアップロード

# FTPまたはSCP経由でWebデータをアップロード
# wp-content/uploads/(画像データ)
# wp-content/themes/(テーマ)
# wp-content/plugins/(プラグイン)

# ファイル数の確認
find wordpress -type f | wc -l

4. wp-config.phpの編集

// 仮設サイトのデータベース情報に置き換える
define('DB_NAME', '仮設サイトのDB名');
define('DB_USER', '仮設サイトのDBユーザー名');
define('DB_PASSWORD', '仮設サイトのDBパスワード');
define('DB_HOST', '仮設サイトのMySQLホスト名');

5. URLの置換(Search-Replace-DB)

# wordpress配下にSearch-Replace-DB-masterを配置
cd wordpress
wget https://github.com/interconnectit/Search-Replace-DB/archive/master.zip
unzip master.zip
rm master.zip

ブラウザでアクセス:

http://仮設サイトのURL/Search-Replace-DB-master/

置換対象:

https://example.com -> http://仮設サイトのURL
http://example.com -> http://仮設サイトのURL

⚠️ 重要: 置換が完了したらSearch-Replace-DB-masterディレクトリは削除する

6. 仮設サイトのセキュリティ設定(重要)

目的: 仮設サイトから顧客や関係者にメールが飛ばないようにする、かつ顧客が誤ってログインできないようにする。

実施内容:

  1. 管理者パスワードを変更
  2. 作業者の自分のアカウントを追加
  3. 全ユーザーのメールアドレスとパスワードを変更
  4. 管理者メールアドレスも変更

これにより得られる効果:

効果説明
メール通知の防止仮設サイトのWordPressがサイトオーナーにメール通知することがない
誤ログインの防止「ログインしないでください」と言うまでもなく、顧客は物理的にログインできない
混乱の防止仮設サイトが何なのかわからずにログインしてしまうことがない
作業の継続性送られてきたログイン情報が間違っていても、自分はWordPressにログインできる

SQL実行手順:

# SSH接続後、MySQLに接続
mysql -h MySQLホスト名 -u DBユーザー名 -p DB名

-- 1. 全ユーザー情報の確認
SELECT user_login, user_pass, user_email FROM wp_users;

-- 2. 管理者のメールアドレスとパスワードを変更
UPDATE wp_users SET user_email = "work@example.com" WHERE user_login = "admin";
UPDATE wp_users SET user_pass = md5('dummy-password') WHERE user_login = "admin";

-- 3. その他全ユーザーのメールアドレスとパスワードも変更
-- 例: ユーザーが複数いる場合
UPDATE wp_users SET user_email = CONCAT(user_login, '@example-dummy.com');
UPDATE wp_users SET user_pass = md5('dummy-password');

-- 4. 管理者メールアドレスも変更
SELECT option_value FROM wp_options WHERE option_name = "admin_email";
UPDATE wp_options SET option_value = "work@example.com" WHERE option_name = "admin_email";

-- 5. 作業者用アカウントを追加(ダッシュボードから実施)
-- ユーザー名: workuser
-- メール: work@example.com
-- 権限: 管理者

⚠️ セキュリティプラグインでテーブル名が変更されている場合:

-- wp-config.phpで$table_prefixを確認
-- 例: $table_prefix = 'wp3df2f0';

-- テーブル名を変更して実行
SELECT user_login, user_pass, user_email FROM wp3df2f0users;
UPDATE wp3df2f0users SET user_email = "work@example.com" WHERE user_login = "admin";
UPDATE wp3df2f0users SET user_pass = md5('dummy-password') WHERE user_login = "admin";

7. BASIC認証の設定(推奨)

仮設サイトへのアクセスを制限するため、BASIC認証を設定する。

エックスサーバーのサーバーパネルで設定:

  1. サーバーパネル > アクセス制限 > BASIC認証設定
  2. 対象ディレクトリを選択
  3. ユーザー名とパスワードを設定

⚠️ 注意: BASIC認証を使用するとバックアッププラグインが動かない場合がある

仮設サイトでの確認作業

  • [ ] トップページが表示されることを確認
  • [ ] ダッシュボードにログインできることを確認
  • [ ] テーマが正しく表示されることを確認
  • [ ] プラグインが正しく動作することを確認
  • [ ] トップページのスクリーンショットを撮る
  • [ ] 管理者メールアドレスを記録
  • [ ] ユーザー名とメールアドレスの一覧を作成
  • [ ] お客さんに復旧可能であることを伝える(安心してもらう)
  • 仮設サイトのURLとBASIC認証情報を送付
  • スクリーンショットを送付
  • 「このように復旧できます」と明確に伝える

サーバー初期化

初期化前の準備

  • [ ] 全データのバックアップが完了していることを確認
  • [ ] 仮設サイトで復旧可能性を確認済みであることを確認
  • [ ] お客さんに初期化のタイミングを通知

初期化手順

  1. [ ] SSLを解除する(ドメインごと)
  2. [ ] ドメインを削除する(すべてのドメイン)
  3. [ ] 初期ドメインを初期化する
  4. [ ] 他のファイル、ディレクトリもすべて消す

– ⚠️ .sshディレクトリだけは残す(SSH接続に必要)

エックスサーバーへの報告(2020年以降は不要)

注意: 現在のエックスサーバーでは初期化完了報告は不要になった

以前は以下のような報告メールを送っていた:

件名: 問い合わせ番号:xsv000000000 Webサーバー領域初期化完了
宛先: support@xserver.ne.jp
CC: 依頼主

本文:
エックスサーバー 様(cc XXXX様)

問い合わせ番号:xsv000000000 Webサーバー領域初期化完了
しましたのでご報告します。

ホスト名: XXXX.xserver.jp
サーバーID: XXXX

私はXXXX様の代理でこの対応をしております。

----------------------------------
有限会社CNTサービス http://www.cntsv.jp
飯田正勝(Iida Masakatsu)
iida.masa@cntsv.jp
tel:047-401-8731 fax:047-401-8732

初期化後の確認

  • [ ] 対象ドメインにアクセスして403エラーが解除されたことを確認

メール復旧

ドメイン再設定

  • [ ] ドメインを再設定
  • [ ] SSL設定(反映にはしばらく時間がかかる)

メールアドレスの一括設定

メール一覧をカンマ区切りテキストファイルから一括で流し込む

メールアドレス一覧例:

info@example.com,TempPass123
support@example.com,TempPass456
sales@example.com,TempPass789

過去メールの復旧

  • [ ] バックアップしたメールデータを上書きする
  • [ ] 新パスワードを設定してWebメールで確認

Webメールのアドレス:

https://www.xserver.ne.jp/login_mail.php

パスワード生成サービス:

http://www.luft.co.jp/cgi/randam.php

メール復旧確認用リスト作成

メールアドレス           初期パスワード
info@example.com        TempPass123
support@example.com     TempPass456
sales@example.com       TempPass789

WordPress再構築

メンテナンス画面の表示

ドメインの反映を待つ間に、メンテナンス画面を表示する

index.html:

<!DOCTYPE html>
<html>
  <head>
    <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'>
    <title>システムメンテナンスのお知らせ</title>
  </head>
  <body>
    <div style='width: 640px; margin: 50px auto;'>
      <div style='border: 1px solid #ccc; padding: 30px; margin-top: 30px;'>
        <h2 style="color: #F00">システムメンテナンスのお知らせ</h2>
        <p>
          いつもご利用いただき、ありがとうございます。<br />
          このたびサービス向上のため、システムメンテナンスを実施いたします。<br />
          下記時間帯でサービスがご利用いただけません。<br />
          お客さまには大変ご迷惑をおかけいたしますが、何卒ご了承いただけますようよろしくお願い申し上げます。
        </p>
        <p>
          メンテナンス期間:現在~2025年XX月XX日(X)XX:00<br />
          ※作業の状況により長引く場合がありますので、予めご了承ください
        </p>
      </div>
    </div>
  </body>
</html>

待っている間にやること

  • [ ] 画像データフォルダのクリーニング
  • [ ] エックスサーバーが指摘したファイルを探して削除
  • [ ] 同じ種類のファイルがないか検索して削除

画像データクリーニングスクリプト:

#!/usr/bin/bash
date
find /path/to/CleanedImages/files -type f -exec file {} \; \
| grep -v "JPEG image data" \
| grep -v "PNG image data" \
| grep -v "GIF image data" \
| grep -v "PC bitmap" \
| grep -v "Apple QuickTime movie"
date
#!/usr/bin/bash
date
find /path/to/CleanedImages/files -type f -name "._*" -exec file {} \; | grep -v AppleDouble
date

WordPress簡易インストール

エックスサーバーの簡易インストール機能を使う

  • [ ] WordPress最新版をインストール
  • [ ] 記録しておいたPHPバージョンに設定
  • [ ] 記録しておいたMySQLバージョンに設定

データベースの切り替え

  • ワードプレスのテーマをインストール(有料テーマがあれば先に)
  • 仮設サイトと比較しながらプラグインをインストール
  • Classic Editorは共通的に入れておく
  • クリーニングした画像データフォルダをアップロード

wp-config.phpの編集:

// 新しく作成したデータベース情報に置き換える
define('DB_NAME', 'example_wp_new');
define('DB_USER', 'example_wp_new');
define('DB_PASSWORD', 'new_password');
define('DB_HOST', 'mysql####.xserver.jp');
  • [ ] バックアップしたデータベースをインポート
mysql -h mysql####.xserver.jp -u example_wp_new -p example_wp_new < backup_db.sql

サーバー負荷を抑えて作業

# 実行優先度を下げる
nice -n 19 コマンド

ログイン情報の変更

データベースを切り替えるとログインできなくなるので、管理者情報を変更する

基本的な手順:

mysql -h mysql####.xserver.jp -u DBユーザー名 -p DB名

-- ユーザー情報確認
SELECT user_login, user_pass, user_email FROM wp_users;

-- パスワード変更
UPDATE wp_users SET user_pass = md5('TempPass123') WHERE user_login = "admin";

⚠️ セキュリティプラグインでテーブル名が変更されている場合:

-- wp-config.phpで$table_prefixを確認
-- 例: $table_prefix = 'wp3df2f0';

-- テーブル名を変更して実行
SELECT user_login, user_pass, user_email FROM wp3df2f0users;
UPDATE wp3df2f0users SET user_pass = md5('TempPass123') WHERE user_login = "admin";

作業用ユーザーの作成と顧客対応の工夫

作業用アカウントの作成

  • [ ] ダッシュボードにログインしたら作業用ユーザーを作成
  • ユーザー名: workuser(任意の名前)
  • メールアドレス: 自分の業務用メール
  • 権限: 管理者
  • パスワード: 強固なパスワード
  • [ ] 以降、作業用ユーザーで作業を行う
  • [ ] 元の管理者アカウントは触らない

顧客が誤ってアクセスしないための対策(オプション)

本番環境でも仮設サイトと同様の対策を取る場合:

メリット:

  • 作業中に顧客が誤ってログインして混乱することを防ぐ
  • 顧客から提供されたログイン情報が間違っていても作業を継続できる
  • 作業完了まで顧客はログインできないため、設定途中の状態を見られない

実施方法:

-- 全ユーザーのパスワードを一時的に変更
UPDATE wp_users SET user_pass = md5('dummy-password');

-- 管理者メールアドレスを一時的に自分のメアドに変更
UPDATE wp_options SET option_value = "work@example.com" WHERE option_name = "admin_email";

⚠️ 重要:

  • この対策を実施した場合、必ず後片付けで元に戻すこと
  • 顧客には「作業中は一時的にログインできません」と事前に伝えること
  • 作業完了時に新しいパスワードを設定して顧客に伝える

プラグインの設定調整

  • [ ] 仮設サイトと比較しながらプラグインの設定を調整
  • [ ] パーマリンク設定を変更(グローバルメニューのリンク切れ対策)

監視

負荷監視

# SSH接続してtopコマンドで監視
top
  • [ ] topコマンドで負荷が高くならないか監視する

もし負荷が高くなったら:

  • そのドメインを削除する
  • 原因を特定してから再度構築

後片付けとセキュリティ対策

セキュリティ設定(重要)

php.ini設定

  • エックスサーバー > サーバーパネル > php.ini設定
  • allow_url_fopenOFF
  • allow_url_includeOFF

⚠️ この変更のためにXアクセラレータをVer.2からVer.1に変更する必要がある場合あり

後片付けチェックリスト(重要)

セキュリティ関連(必須)

  • SSH接続をOFFにする(重要)
  • FTPユーザーのパスワード変更をお願いする(重要)
  • 各メールの初期パスワード変更をお願いする

WordPress管理者情報の復元(必須)

  • 管理者のメールアドレスを元に戻す(重要)
  -- 元のメールアドレスに戻す
  UPDATE wp_options SET option_value = "customer@example.com" WHERE option_name = "admin_email";
  • 顧客が使用するWordPress管理者パスワードを設定(重要)
  -- 新しい強固なパスワードを設定
  UPDATE wp_users SET user_pass = md5('New-Strong-Password') WHERE user_login = "admin";

– パスワード生成: http://www.luft.co.jp/cgi/randam.php – 顧客に新しいパスワードを安全な方法で伝える

  • 全ユーザーのログイン情報を顧客に確認
  • 作業中に一時的にパスワードを変更していた場合は元に戻す、または新しいパスワードを設定して顧客に伝える
  • ユーザー名とメールアドレスの一覧を顧客に送付

作業用アカウントの削除確認

  • 作業用ユーザー(workuser等)の削除について顧客に依頼
  • すぐに削除してもらうか、しばらく残しておいてもらうかは顧客と相談
  • 緊急時のサポート用として残しておくことを提案することも可

提案レベルの後片付け

セキュリティ強化の提案

  • エックスサーバーの自動バックアップをONにしてもらう
  • 月額料金がかかるが、次回の障害時に復旧が容易になる
  • 過去7日分のバックアップが保存される
  • ドメインロック設定をする
  • 不正なドメイン移管を防ぐ
  • WordPress自動更新の有効化
  • WordPress本体の自動更新
  • プラグインの自動更新
  • テーマの自動更新(オリジナルテーマの場合は注意)

定期的なメンテナンスの提案

  • 定期的なバックアップの実施(backWPupプラグイン等)
  • 定期的なWordPress/プラグイン/テーマの更新
  • 不要なプラグインやテーマの削除
  • 定期的なセキュリティスキャン

backWPupの設定

  • backWPupの設定はエラーが起きると管理者にメールが飛ぶ
  • 実行にも時間がかかる
  • ジョブを一本で処理をさせるとタイムアウトエラーで終わることがある
  • 何度も実行していたらエックスサーバーに処理を無効にされたことがある

再発防止対策

  • エックスサーバーサポートがオススメする対策を実施
  • 古いWordPressやプラグインが原因だった場合は説明

重要な注意事項・ハマりポイント

1. PHPバージョンの違い

症状:

  • リストア後に文法エラーが発生
  • ダッシュボードが真っ白

原因:

  • 初期化前のPHPバージョンを確認せずにリストア
  • ドメインを作るとデフォルトはPHP7.2
  • PHP5.4.16で開発したサイトをリストアすると文法エラー

対策:

  • 初期化前に必ずPHPバージョンを記録する
  • リストア時に同じバージョンに設定する

実績: この確認を怠って2日潰したことがある

2. セキュリティプラグインによるテーブル名変更

症状:

  • MySQLを切り替えた後、ダッシュボードでWordPressインストーラーが起動
  • ログインできない

原因:

  • All In One WP Securityなどのプラグインがテーブル接頭辞を変更している
  • wp_users ではなく wp3df2f0users などのランダムな接頭辞になっている

確認方法:

# バックアップデータから確認
find . -name wp-config.php -exec grep table_prefix {} \;

対策:

// wp-config.phpを確認
$table_prefix = 'wp3df2f0'; // デフォルトの'wp_'ではない

// データベース操作時もテーブル名を変更
SELECT user_login FROM wp3df2f0users;

3. WordPress初期インストールのタイミング

発見:

  • ワードプレスを初期インストールした時に、テーマファイルもインストールしてからMySQLを切り替える
  • これをするとMySQLを切り替えた瞬間に障害前のWordPressの画面が表示される
  • 初期インストールしたMySQLのデータは捨てるので、テーマはインストールしてOK
  • ただし、プラグインのインストールは待った方がいい

4. その他のハマりポイント

.htaccessファイル

  • .htaccessファイルの存在に気がつかないとハマる
  • データベースのインポートまで失敗することがある

BASIC認証

  • BASIC認証を使用するとバックアッププラグインが動かない
  • 仮設サイトにエックスサーバーのデフォルトドメインを使うのは有効

パーマリンク設定

  • グローバルメニューがリンク切れを起こす
  • パーマリンク設定を変更して解決
  • なぜリストアしても同じ設定にならないのか不明

絶対パスでの画像指定

  • 絶対パスで画像ファイルを指定している部分がある
  • 仮設サイトではアイコン等が表示されない
  • 本番環境に持っていくことで解決

配布終了しているプラグイン

  • ダウンロードの仕方がわからないプラグインがある
  • 有料版のテーマ、プラグインの多さ

有料テーマのライセンス

  • Bethemeはライセンスが1ウェブサイトのみ

よく使うコマンド集

SSH接続

# 基本接続
ssh -p 10022 サーバーID@サーバーID.xsrv.jp

# configを使った接続
ssh xserver-example

ファイル操作

# ディレクトリ内のファイル数を数える
find . -type f | wc -l

# wp-config.phpを探す
find . -name "wp-config.php"

# 特定の文字列を含むファイルを検索
find . -type f -exec grep -l "文字列" {} \;

# パーミッション付きリスト作成
ls -laR > file_list.txt

バックアップ

# tar圧縮
tar czf backup.tar.gz ディレクトリ名/

# tar内容確認
tar tvf backup.tar | wc -l

# 複数tarの一括確認
for i in `ls *.tar`; do echo ${i}; tar tvf ${i} | wc -l; done

MySQL操作

# MySQL接続
mysql -h MySQLホスト名 -u ユーザー名 -p DB名

# ダンプ作成
mysqldump -h MySQLホスト名 -u ユーザー名 -p DB名 > backup.sql

# ダンプからインポート
mysql -h MySQLホスト名 -u ユーザー名 -p DB名 < backup.sql

よく使うSQL

-- ユーザー情報確認
SELECT user_login, user_pass, user_email FROM wp_users;

-- パスワード変更
UPDATE wp_users SET user_pass = md5('新しいパスワード') WHERE user_login = "ユーザー名";

-- メールアドレス変更
UPDATE wp_users SET user_email = "新しいメアド" WHERE user_login = "ユーザー名";

-- 管理者メールアドレス確認
SELECT option_value FROM wp_options WHERE option_name = "admin_email";

-- 管理者メールアドレス変更
UPDATE wp_options SET option_value = "新しいメアド" WHERE option_name = "admin_email";

-- サイトURLとホームURL確認
SELECT * FROM wp_options WHERE option_name = "siteurl";
SELECT * FROM wp_options WHERE option_name = "home";

テンプレート集

メンテナンス画面HTML

<!DOCTYPE html>
<html>
  <head>
    <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'>
    <title>システムメンテナンスのお知らせ</title>
  </head>
  <body>
    <div style='width: 640px; margin: 50px auto;'>
      <div style='border: 1px solid #ccc; padding: 30px; margin-top: 30px;'>
        <h2 style="color: #F00">システムメンテナンスのお知らせ</h2>
        <p>
          いつもご利用いただき、ありがとうございます。<br />
          このたびサービス向上のため、システムメンテナンスを実施いたします。<br />
          下記時間帯でサービスがご利用いただけません。<br />
          お客さまには大変ご迷惑をおかけいたしますが、何卒ご了承いただけますようよろしくお願い申し上げます。
        </p>
        <p>
          メンテナンス期間:現在~2025年XX月XX日(X)XX:00<br />
          ※作業の状況により長引く場合がありますので、予めご了承ください
        </p>
      </div>
    </div>
  </body>
</html>

SSH config

Host xserver-example
  HostName sv####.xserver.jp
  Port 10022
  User サーバーID
  IdentityFile ~/.ssh/your_key_id_rsa

見積もり例

<作業の流れ>
 ステップ1. 依頼者様からヒアリング
 ステップ2. 依頼者様から作業に必要な情報の受領
 ステップ3. サーバーの全バックアップ
 ステップ4. バックアップデータのチェック(トップ画面スクショ送付)
 ステップ5. サーバー初期化、「メンテナンス中です」画面表示
 ステップ6. メールの復旧、WordPressサイトを再構築
 ステップ7. データバックアッププラグイン設定、再発防止対策

<作業時間の目安>
 5~10営業日

<おすすめポイント>
・引き受けた仕事は最後まで責任を持って対応します
・全て最新バージョンになります(WordPressのみ)
・再発防止対策実施
・過去メールを復旧します

参考情報

パスワード生成サービス

http://www.luft.co.jp/cgi/randam.php

Search-Replace-DB

https://github.com/interconnectit/Search-Replace-DB

作成者: 有限会社CNTサービス 最終更新: 2025-10-24

\ 最新情報をチェック /