WordPress の再インストールと障害復旧：安全なバックアップ・コア修復・移行手順

Table of Contents

「再インストール」を消去と考えず、安全にサービスを復旧する

WordPress のコア、サイトコンテンツ、実行時設定は別々の資産です。通常、コアを置き換えるためにデータベース、wp-config.php、wp-content を削除する必要はなく、バックアップ復元を新規インストール画面から始めるべきでもありません。本手順は 2026 年 9 月 1 日に最終確認しました。原因を削除で覆い隠すのではなく、ロールバック可能で検証できる復旧を目的とします。

侵害が疑われる場合、コアの再インストールだけではバックドアがなくなったと証明できません。ホストを隔離し、ログとディスク証拠を保全し、サイト由来の PHP、WP-CLI、plugin、MU plugin の実行を止め、incident response の手順で credential、key、salt をローテーションします。侵害を除外できた後、または信頼できる環境で証拠保全を終えた後に限り、以下のサイトコマンドを実行してください。

1. 事象を分類し、メンテナンス時間を定義する

状況	典型的な証拠	正しい開始点
コアファイル破損または checksum failure	Version が判明し、database と content は無傷	staging で同じ version・locale の検証済みコアに置換
更新の中断	`.maintenance` の残留、version の混在、database upgrade の未完了	現状 snapshot を保存し、単一の明示的 version を展開してから DB upgrade を評価
clean host での再構築・移行	旧 host の廃止、または runtime が非対応	隔離した新 host で content と DB を復元し、test 後に traffic を切替
データ誤削除・状態の巻き戻し	正常だった時点の既知 recovery point がある	同一時点の DB と file backup をまず staging に復元
侵害の疑い	不明な admin、見覚えのない PHP、異常な scheduled task や外向き通信	隔離・証拠保全・secret rotation を行い、既知の信頼できる source から再構築

Change owner、maintenance window、許容データ損失、health check、rollback owner、stop condition を決めます。Backup が読めること、staging DB が production と分離されていること、target version が互換であることを証明できなければ停止します。Production を最初の演習場所にしてはいけません。

2. 読み取り専用の inventory と証拠を作る

Host、PHP、DB server、web server、WordPress version と locale、site URL、table prefix、active theme、plugin、MU plugin、drop-in、scheduled task、object cache、media storage、reverse proxy、DNS、TLS、定期 backup を記録します。wp-admin、wp-includes、root file、wp-content の hash を保存します。Log と inventory には private path や IP が含まれ得るため、アクセス制限した evidence storage に保管します。

以下の WP-CLI check は侵害の疑いがなく、WP-CLI 自体も信頼できる installation から実行する場合に限ります。--skip-plugins --skip-themes は MU plugin を skip しません。MU plugin が信頼できない場合、WP-CLI を実行しないでください。

set -eu

SITE_ROOT=/srv/www/example
EVIDENCE_DIR=/srv/backups/example/20260901T124200Z-evidence

test -d "$SITE_ROOT/wp-admin"
test -d "$SITE_ROOT/wp-includes"
test -d "$SITE_ROOT/wp-content"
test ! -e "$EVIDENCE_DIR"
install -d -m 0700 "$EVIDENCE_DIR"

wp --path="$SITE_ROOT" core version --skip-plugins --skip-themes
wp --path="$SITE_ROOT" core verify-checksums --include-root --skip-plugins --skip-themes
wp --path="$SITE_ROOT" plugin list --format=json --skip-plugins --skip-themes > "$EVIDENCE_DIR/plugins.json"
wp --path="$SITE_ROOT" theme list --format=json --skip-plugins --skip-themes > "$EVIDENCE_DIR/themes.json"
find "$SITE_ROOT" -xdev -type f -print0 | sort -z | xargs -0 sha256sum > "$EVIDENCE_DIR/site-files.sha256"

Checksum failure は official release と異なる file があることだけを示し、それだけでは正当な custom、破損、侵害を区別できません。--insecure で TLS を回避しないでください。WP-CLI の official documentation は、download が man-in-the-middle attack にさらされると警告しています。

3. 完全で保護され、テスト可能なバックアップを作る

公式 WordPress backup guide は database と file の両方を要求します。少なくとも database、wp-content/uploads、theme、plugin、MU plugin、drop-in、wp-config.php、.htaccess または同等の server rule、robots file、custom PHP config、scheduled task、web/PHP/cache config、TLS・DNS inventory、外部 object storage の version を保存します。DB と config には personal data と secret が含まれるため、暗号化し、access を制限し、retention を定め、production と別の failure domain に置きます。

次の例は専用 directory を新規作成し、password を command に含めず wp-config.php から DB 接続を読みます。Sample path は先に承認済み absolute path へ変更してください。Destination が存在すれば停止し、production file は削除しません。

set -eu

SITE_ROOT=/srv/www/example
BACKUP_ROOT=/srv/backups/example/20260901T124200Z

test -d "$SITE_ROOT/wp-content"
test ! -e "$BACKUP_ROOT"
install -d -m 0700 "$BACKUP_ROOT/files"

wp --path="$SITE_ROOT" db export "$BACKUP_ROOT/database.sql" --single-transaction --skip-plugins --skip-themes

for item in wp-config.php wp-content .htaccess .user.ini robots.txt; do
  if test -e "$SITE_ROOT/$item"; then
    cp -a -- "$SITE_ROOT/$item" "$BACKUP_ROOT/files/"
  fi
done

find "$BACKUP_ROOT" -type f ! -name SHA256SUMS -exec sha256sum {} + > "$BACKUP_ROOT/SHA256SUMS"
chmod 0600 "$BACKUP_ROOT/database.sql" "$BACKUP_ROOT/SHA256SUMS"

Host 管理者用の制限された経路で、Apache、Nginx などの ingress config、PHP-FPM、systemd、cron、cache config、certificate reference を別途 copy します。Private key を blog repository や ticket に置いてはいけません。Snapshot は restore test ではありません。Checksum を検証し、隔離 DB への完全な restore を行います。

4. まず clean staging で完全復元する

Staging は別 hostname、別 DB、least-privilege DB user を使います。外向き mail、payment、webhook、search indexing、production queue を遮断します。Production の wp-config.php を直接 copy せず、staging 専用 config を作り、credential は管理された secret storage から注入します。

Test import が production を指さないよう、続行前に DB 名を比較します。以下の copy と import は明示した staging path のみを対象にします。2 つの test gate が通ったことを確認してから実行してください。

set -eu

PROD_ROOT=/srv/www/example
STAGE_ROOT=/srv/www/example-staging
BACKUP_ROOT=/srv/backups/example/20260901T124200Z

test "$STAGE_ROOT" != "$PROD_ROOT"
test -f "$STAGE_ROOT/wp-config.php"
test "$(wp --path="$STAGE_ROOT" config get DB_NAME --skip-plugins --skip-themes)" != "$(wp --path="$PROD_ROOT" config get DB_NAME --skip-plugins --skip-themes)"

cp -a -- "$BACKUP_ROOT/files/wp-content/." "$STAGE_ROOT/wp-content/"
wp --path="$STAGE_ROOT" db import "$BACKUP_ROOT/database.sql" --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" db check --skip-plugins --skip-themes

Restore 後も staging を private に保ちます。URL を変更する前に post、user、media、menu、widget、table count、prefix を確認します。DB への write 前には新しい staging snapshot を作ります。

5. 最小の修復 branch を選ぶ

Branch	保持するもの	使用時期	してはいけないこと
A：core file 置換	DB、`wp-config.php`、`wp-content` 全体、server rule	Core が破損し version が判明	DB table や content directory を削除しない
B：failed update 修復	A の全てと update 前 snapshot	Version が混在、または maintenance mode が残留	無条件に `latest` へ進めない
C：clean host 再構築	Trusted backup から選択的に復元	Host migration、runtime 交換、security rebuild	不明な system binary や secret を copy しない
D：backup 復元	同じ recovery point の DB と file	Data damage または bad release	異なる時点の DB と uploads を組み合わせない

原因と選んだ branch が一致しなければ停止し、再分類します。複数 branch の同時実行は change surface を広げ、rollback evidence を壊します。

6. Branch A：検証済みの同一 version で core を置換する

WP-CLI `core download` は明示的な version と locale を取得できます。latest、nightly、--insecure を使わないでください。Site 外で clean core を作り、`core verify-checksums` で検証します。Version は compatibility review と WordPress official release archive に基づいて決めます。

set -eu

SITE_ROOT=/srv/www/example-staging
CORE_STAGE=/srv/releases/wordpress-core-X.Y.Z-zh_CN
QUARANTINE=/srv/quarantine/example-core-20260901T124200Z
TARGET_VERSION=X.Y.Z
TARGET_LOCALE=zh_CN

test -d "$SITE_ROOT/wp-content"
test -f "$SITE_ROOT/wp-config.php"
test ! -e "$CORE_STAGE"
test ! -e "$QUARANTINE"
install -d -m 0750 "$CORE_STAGE"
install -d -m 0700 "$QUARANTINE"

wp core download --path="$CORE_STAGE" --version="$TARGET_VERSION" --locale="$TARGET_LOCALE" --skip-content
wp core verify-checksums --path="$CORE_STAGE" --version="$TARGET_VERSION" --locale="$TARGET_LOCALE"

mv -- "$SITE_ROOT/wp-admin" "$QUARANTINE/wp-admin"
mv -- "$SITE_ROOT/wp-includes" "$QUARANTINE/wp-includes"
cp -a -- "$CORE_STAGE/wp-admin" "$SITE_ROOT/wp-admin"
cp -a -- "$CORE_STAGE/wp-includes" "$SITE_ROOT/wp-includes"
find "$CORE_STAGE" -maxdepth 1 -type f -print0 |
while IFS= read -r -d '' core_file; do
  core_name=${core_file##*/}
  if test -f "$SITE_ROOT/$core_name"; then
    cp -a -- "$SITE_ROOT/$core_name" "$QUARANTINE/$core_name"
  fi
  cp -a -- "$core_file" "$SITE_ROOT/$core_name"
done

wp --path="$SITE_ROOT" core verify-checksums --include-root --version="$TARGET_VERSION" --locale="$TARGET_LOCALE" --skip-plugins --skip-themes

この allowlist は wp-admin、wp-includes、official package の root file だけを移動・置換し、wp-content、wp-config.php、DB は削除しません。--include-root が extra root file を報告したら個別に確認し、特定した file を quarantine へ移します。Wildcard で一括削除してはいけません。Staging test 後、同じ review 済み手順で production に deploy します。

7. Branch B：中断した更新を修復する

実際の file version、意図した version、.maintenance、PHP error、update log を先に記録します。明示的な 1 つの完全な core version を展開し、再検証します。`wp core update-db` は code が一貫し、DB backup が検証済みで、official upgrade path が要求するときだけ実行します。これは通常の health check ではなく DB write です。

set -eu

SITE_ROOT=/srv/www/example-staging

wp --path="$SITE_ROOT" core verify-checksums --include-root --skip-plugins --skip-themes
wp --path="$SITE_ROOT" maintenance-mode activate --skip-plugins --skip-themes
wp --path="$SITE_ROOT" core update-db --skip-plugins --skip-themes
wp --path="$SITE_ROOT" maintenance-mode deactivate --skip-plugins --skip-themes

WP-CLI が起動しない場合、無限に再試行しません。Root の .maintenance だけを正確に quarantine へ移して test し、任意の dotfile は削除しません。Error が出たら maintenance mode を維持し、log を保存して rollback します。公式 upgrade guide は upgrade 前の backup を要求し、wp-config.php、wp-content、custom server rule を明示的に保持します。

8. Branch C：clean host で再構築する

新 host に、現在 support されサイトと互換な PHP、DB、web server、extension を導入します。Time sync、log、backup、monitoring、HTTPS を有効化します。専用 system account、site directory、least-privilege DB user を作り、DB root account を再利用せず、command、chat、repository に password を貼りません。

明示的な core version と locale を download・verify します。新しい wp-config.php と salt を作成し、review 済み uploads、theme、plugin、MU plugin、drop-in のみを選択的に復元します。Import 前に target DB が空で production ではないと証明します。公式 migration guide は hostname や path の変更が DB 内 URL に影響すると説明しています。通常の SQL 文字列置換ではなく serialization-aware tool を使います。

Security rebuild では、review 済み data と media だけを移し、不明な PHP、cache、古い secret、system config は移しません。Launch 前に旧 host credential を失効させ、queue、cron、webhook、object cache が旧 endpoint を参照していないことを確認します。

9. Branch D：既知の正常なバックアップから復元する

Recovery point objective を満たす DB と file の組を選び、version、checksum、encryption key、restore instruction を検証します。DB、uploads、order などの外部 system は一貫した時点である必要があります。まず staging に復元します。新しい table を作るため空 site を install したり、import の「準備」として production table を全削除したりしません。

Production cutover 前に maintenance window に入り、現在の障害状態を snapshot として保全します。その後、host 承認済み方法で target DB を import し、検証済み file release へ atomic switch します。Production import は destructive recovery gate です。Authorized reviewer が target DB、backup time、current snapshot、rollback command を確認する必要があります。旧 release や backup をすぐ削除しません。

10. URL 変更は serialization-aware に行う

WordPress option や plugin data には PHP serialized value があり得ます。通常の sed や SQL REPLACE は encoded length を壊します。WP-CLI `search-replace` は serialized data を扱えます。Table prefix に限定し、--dry-run から始めます。Post GUID は表示 URL ではないため通常 guid を skip します。Multisite、domain mapping、custom table は別計画が必要です。

set -eu

STAGE_ROOT=/srv/www/example-staging
OLD_URL=https://www.example.com
NEW_URL=https://staging.example.net

wp --path="$STAGE_ROOT" search-replace "$OLD_URL" "$NEW_URL" --all-tables-with-prefix --skip-columns=guid --dry-run --skip-plugins --skip-themes

Dry-run の table と change count を review し、新しい DB snapshot を取得してから、--dry-run を外して一度実行します。DB が他の application と共有されないと証明できない限り --all-tables は使いません。その後 home、siteurl、重要 plugin setting を読み、hard-coded HTTP content を確認します。

11. Plugin、theme、MU plugin、drop-in を隔離する

まず staging で障害を再現します。通常 plugin は公式 `wp plugin deactivate` で無効化できます。これは DB を書くため snapshot 後にのみ実行します。記録した batch 単位で戻して trigger を特定し、「全て update して様子を見る」ことで evidence を変えません。

set -eu

STAGE_ROOT=/srv/www/example-staging

wp --path="$STAGE_ROOT" plugin deactivate --all --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" plugin list --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" theme list --skip-plugins --skip-themes

MU plugin は自動 load され、advanced-cache.php、object-cache.php、db.php などの drop-in は通常 plugin と異なります。Hash を記録し、疑わしい 1 file だけを staging quarantine へ移します。Production の wp-content 全体を rename・delete しません。Theme switch は rendering と widget を変えるため、installed・reviewed・compatible な theme を staging で診断にだけ使います。

公式 hardening guide と file-permissions guide に従い、専用 owner/group を使い、web service が application 上必要な場所だけを書けるようにします。再帰的な chmod 777 は禁止です。PHP process に deployment key や code tree 全体への write access を与えません。find ... -ls で実際の owner、group、mode を audit し、hosting model に合わせて個別修正します。

12. Permalink、HTTPS、cache、server rule

元の .htaccess、Nginx/Caddy route、reverse-proxy header、PHP-FPM、cache config、security header を先に復元・比較します。WordPress の permalink documentation は Apache .htaccess の書込みが permission に依存すると説明しています。Nginx、Caddy、managed proxy には server layer の同等 routing が必要で、dashboard 設定の保存を繰り返しても修復できません。

set -eu

STAGE_ROOT=/srv/www/example-staging

wp --path="$STAGE_ROOT" option get home --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" option get siteurl --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" rewrite flush --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" rewrite list --skip-plugins --skip-themes

URL と server rule が正しいと確認してから rewrite を flush します。Home、post、pagination、feed、REST API、media、admin route を test します。Nginx/Caddy で WP-CLI が server config を編集すると期待して --hard を使わないでください。WordPress HTTPS guide に従い、certificate chain、reverse proxy の HTTPS detection、home/siteurl、secure cookie、mixed content、HTTP から HTTPS への redirect を検査します。Object/page/CDN cache purge の範囲を記録し、古い failure を再注入しないようにします。

13. 検証、リリース、ロールバック

Layer	Launch gate	Rollback trigger
File	Core checksum 合格、説明できない extra なし、permission が host model と一致	Checksum 変化、不明 PHP、異常 owner
DB	`db check` 合格、table count・user・content・business record の標本が一致	SQL error、serialization corruption、recovery point 不一致
Application	Login、publish、media、search、form、cron、REST、mail sandbox が合格	PHP fatal、queue 重複、write failure、制御不能な outbound action
Web/TLS	Critical route、redirect、certificate、cache header、proxy origin が正常	Redirect loop、mixed content、5xx、private staging の露出
Observability	Error rate、latency、disk、DB connection、queue の baseline がある	Metric が threshold 超過を継続、または新しい log error

set -eu

STAGE_ROOT=/srv/www/example-staging
STAGE_URL=https://staging.example.net

wp --path="$STAGE_ROOT" core verify-checksums --include-root --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" db check --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" cron event list --skip-plugins --skip-themes
curl --fail --silent --show-error --head "$STAGE_URL/"
curl --fail --silent --show-error --head "$STAGE_URL/wp-json/"

Low traffic または atomic release switch で launch し、旧 release、DB snapshot、config、DNS fallback を保持します。合意した observation window で baseline と比較します。Stop condition 発生時は「もう一つだけ修正」を続けず、旧 release と同一時点 DB、server rule を戻し、新 cache を purge して recovery health を検証します。原因、command、version、hash、approval、data difference、follow-up repair を記録します。

14. 現在の公式リファレンス

15. 2011 年原文の正確なアーカイブ

以下は source_export の可視本文全体です。原文の文字、link、空白、句読点は変更せず、不活性な外側 code fence だけを追加しました。元の export と Git history は変更していません。

警告：アーカイブの手順は最初に全 DB table と config を削除します。現在の運用手順ではありません。上の maintenance runbook を使用してください。


Table of Contents

Toggle

- [wordpress重装](https://blog.lazying.art/en/html/computer_internet/wordpress/390/wordpress%e9%87%8d%e8%a3%85.html/#wordpress%E9%87%8D%E8%A3%85)

# wordpress重装

1、进入phpmyadmin，导出数据库。事先若能用wordPress Database Backup备份数据库也可以。备份的时候，不要忘了/wp-content/uploads文件夹下的东东啊。
 2、删除WordPress已安装数据库里所有table表。
 3、用免费ftp工具或在线文件管理进入WordPress安装目录，删除config.php和.htaccess这两个记录文件或安装痕迹。
 4、重新设置config.php。[可选]（WordPress一般会自动创建这个配置文件）
 5、浏览器输入你WordPress网址，重装WordPress。填写数据库信息、管理员信息。
 6、记住admin密码，进入重装后的WordPress后台，修改admin密码。[可选]
 7、再次进入phpmyadmin，恢复或导入数据库。