WordPress Reinstallation and Recovery: Safe Backups, Core Repair, and Migration

Table of Contents

Restore service safely; do not treat “reinstallation” as erasure

WordPress core, site content, and runtime configuration are separate assets. Replacing core normally does not require deleting the database, wp-config.php, or wp-content; restoring a backup should not begin by running the fresh-install wizard. This runbook was last checked on September 1, 2026. Its aim is a reversible, verifiable recovery—not deletion that hides the cause.

If compromise is suspected, reinstalling core does not prove that a backdoor is gone. Isolate the host, preserve logs and disk evidence, stop executing PHP, WP-CLI, plugins, and MU plugins from the site, and follow an incident-response process to rotate credentials, keys, and salts. Run the site commands below only after compromise has been ruled out or evidence collection has finished in a trusted environment.

1. Classify the incident and define the maintenance window

Situation	Typical evidence	Correct starting point
Damaged core files or checksum failure	Version is known; database and content are intact	Replace core in staging with verified files for the same version and locale
Interrupted update	Leftover `.maintenance`, mixed versions, or unfinished database upgrade	Preserve a state snapshot, deploy one explicit version, then assess the database upgrade
Clean-host rebuild or migration	Old host is retiring or its runtime is unsupported	Restore content and database on an isolated new host, test, then switch traffic
Accidental data loss or state rollback	A known recovery point predates the bad state	Restore database and file backups from the same point in staging first
Suspected compromise	Unknown admins, unfamiliar PHP, abnormal scheduled tasks or outbound traffic	Isolate, preserve evidence, rotate secrets, and rebuild from known-trusted sources

Name the change owner, maintenance window, acceptable data-loss window, health checks, rollback owner, and stop conditions. Stop if you cannot prove that the backup is readable, the staging database is isolated from production, or the target version is compatible. Production must not be the first rehearsal.

2. Build a read-only inventory and evidence set

Record the host, PHP, database server, web server, WordPress version and locale, site URLs, table prefix, active theme, plugins, MU plugins, drop-ins, scheduled tasks, object cache, media storage, reverse proxy, DNS, TLS, and scheduled backups. Save hashes for wp-admin, wp-includes, root files, and wp-content. Logs and inventories may contain private paths and IP addresses, so keep them in restricted evidence storage.

The WP-CLI checks below apply only when compromise is not suspected and WP-CLI itself comes from a trusted installation. --skip-plugins --skip-themes does not skip MU plugins; do not run WP-CLI when an MU plugin is untrusted.

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"

A checksum failure says only that a file differs from the official release; by itself, it does not distinguish a legitimate customization, corruption, or compromise. Do not bypass TLS with --insecure: the official WP-CLI documentation warns that doing so exposes the download to a man-in-the-middle attack.

3. Create a complete, protected, testable backup

The official WordPress backup guide requires both database and file backups. Preserve at least the database, wp-content/uploads, themes, plugins, MU plugins, drop-ins, wp-config.php, .htaccess or equivalent server rules, robots file, custom PHP configuration, scheduled tasks, web/PHP/cache configuration, TLS and DNS inventory, and versions of externally stored objects. The database and configuration contain personal data and secrets; encrypt them, restrict access, define retention, and keep them outside the production failure domain.

This example creates a dedicated directory and reads database access from wp-config.php without putting a password in the command. Replace the sample paths with approved absolute paths first. It stops if the destination exists and does not delete production files.

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"

Through a restricted host-administration channel, separately copy Apache, Nginx, or other ingress configuration, PHP-FPM, systemd, cron, cache configuration, and certificate references. Never put private keys in the blog repository or a ticket. A snapshot is not a restore test: verify its checksums and complete a restore into an isolated database.

4. Perform a complete restore in clean staging first

Staging needs a separate hostname, separate database, and least-privilege database user. Block outgoing mail, payments, webhooks, search indexing, and production queues. Do not copy the production wp-config.php directly; create a staging-specific configuration and inject credentials from controlled secret storage.

Compare database names before continuing so a test import cannot target production. The copy and import below point only to an explicit staging path; run them only after both test gates pass.

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

Keep staging private after the restore. Check posts, users, media, menus, widgets, table counts, and prefixes before changing URLs. Take another staging snapshot before any database write.

5. Choose the smallest repair branch

Branch	What it preserves	When to use it	What not to do
A: replace core files	Database, `wp-config.php`, all of `wp-content`, server rules	Core is damaged and the version is known	Do not delete database tables or the content directory
B: repair a failed update	Everything in A plus the pre-update snapshot	Versions are mixed or maintenance mode remains	Do not blindly continue to `latest`
C: rebuild on a clean host	Restore selected items from a trusted backup	Host migration, runtime replacement, or security rebuild	Do not copy unknown system binaries or secrets
D: restore from backup	Database and files from the same recovery point	Data damage or a bad release	Do not combine a database and uploads from different times

Stop and classify again if the cause and chosen branch do not agree. Combining branches expands the change surface and can destroy rollback evidence.

6. Branch A: replace core with a verified matching version

WP-CLI `core download` can fetch an explicit version and locale. Do not use latest, nightly, or --insecure. Build clean core outside the site and verify it with `core verify-checksums`. The version must come from compatibility review and the official WordPress 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

This allowlist moves and replaces only wp-admin, wp-includes, and official package files at the root; it does not delete wp-content, wp-config.php, or the database. Assess each extra root file reported by --include-root and move an identified file to quarantine; never bulk-delete it with a wildcard. After staging passes, deploy production through the same reviewed procedure.

7. Branch B: repair an interrupted update

First record the actual file version, intended version, .maintenance, PHP errors, and update logs. Deploy one explicit, complete core version and verify it again. Run `wp core update-db` only when code is consistent, the database backup is verified, and the official upgrade path requires it. It is a database write, not an ordinary health check.

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

If WP-CLI cannot start, do not retry indefinitely. Move only the root .maintenance file to quarantine and test; do not delete arbitrary dotfiles. On any error, keep maintenance mode active, save logs, and roll back. The official upgrade guide requires backup before upgrading and explicitly preserves wp-config.php, wp-content, and custom server rules.

8. Branch C: rebuild on a clean host

Install currently supported, site-compatible PHP, database, web server, and extensions on the new host. Enable time synchronization, logs, backups, monitoring, and HTTPS. Create a dedicated system account, site directory, and least-privilege database user. Do not reuse a database root account or paste passwords into commands, chat, or the repository.

Download and verify an explicit core version and locale. Create a new wp-config.php, generate new salts, and selectively restore reviewed uploads, themes, plugins, MU plugins, and drop-ins. Before import, prove that the target database is empty and not production. The official migration guide notes that hostname or path changes affect URLs stored in the database; use a serialization-aware tool rather than plain SQL text replacement.

For a security rebuild, migrate only reviewed data and media—not unknown PHP, caches, old secrets, or system configuration. Before launch, revoke old-host credentials and ensure that queues, cron jobs, webhooks, and object caches no longer point to old endpoints.

9. Branch D: restore a known-good backup

Select a database and file set that meets the recovery-point objective, then verify versions, checksums, encryption keys, and restoration instructions. The database, uploads, and external systems such as orders must represent a consistent point in time. Restore into staging first. Do not install an empty site to generate new tables, and do not delete every production table to “prepare” for import.

Before production cutover, enter the maintenance window and preserve a snapshot of the current failed state. Then import the target database and atomically switch to the verified file release using the host's approved method. Production import is a destructive recovery gate: an authorized reviewer must confirm the target database, backup time, current snapshot, and rollback command. Do not immediately remove the old release or backups.

10. URL changes must be serialization-aware

WordPress options and plugin data may contain PHP-serialized values. Plain sed or SQL REPLACE can corrupt encoded lengths. WP-CLI `search-replace` handles serialized data; constrain it to the table prefix and begin with --dry-run. Usually skip guid, because a post GUID is not a display URL. Multisite, domain mapping, and custom tables need a separate plan.

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

Review the dry-run table list and counts, take a new database snapshot, then run once without --dry-run. Do not use --all-tables unless the database is proven not to be shared. Afterwards, read home, siteurl, and critical plugin settings and check for hard-coded HTTP content.

11. Isolate plugins, themes, MU plugins, and drop-ins

Reproduce the failure in staging first. Regular plugins can be disabled with official `wp plugin deactivate`. It writes to the database, so run it only after a snapshot. Restore plugins in recorded batches to identify the trigger; do not alter evidence by “updating everything and seeing what happens.”

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 plugins load automatically, while drop-ins such as advanced-cache.php, object-cache.php, and db.php are not ordinary plugins. Record hashes, then move one suspect file to staging quarantine; do not rename or delete the entire production wp-content. A theme switch changes rendering and widgets, so diagnose only in staging with an installed, reviewed, compatible theme.

Follow the official hardening guide and file-permissions guide: use a dedicated owner/group and let the web service write only where the application requires it. Never apply recursive chmod 777, and do not give the PHP process deployment keys or write access to the whole code tree. Audit actual owners, groups, and modes with find ... -ls, then make individual changes appropriate to the hosting model.

12. Permalinks, HTTPS, caches, and server rules

Restore and compare the original .htaccess, Nginx/Caddy routes, reverse-proxy headers, PHP-FPM, cache configuration, and security headers first. The WordPress permalink documentation explains that Apache .htaccess writes depend on permissions. Nginx, Caddy, or a managed proxy needs equivalent server-layer routing; repeatedly saving the dashboard setting cannot repair that configuration.

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

Flush rewrites only after URL and server rules are correct. Test the home page, posts, pagination, feeds, REST API, media, and admin routes. On Nginx/Caddy, do not use --hard expecting WP-CLI to edit server configuration. Follow the WordPress HTTPS guide to check the certificate chain, reverse-proxy HTTPS detection, home/siteurl, secure cookies, mixed content, and HTTP-to-HTTPS redirects. Record the scope when purging object, page, or CDN caches so an old failure is not reintroduced.

13. Validate, launch, and roll back

Layer	Launch gate	Rollback trigger
Files	Core checksums pass; no unexplained extras; permissions match the host model	Checksum changes, unknown PHP, or abnormal owner
Database	`db check` passes; sampled table count, users, content, and business records agree	SQL errors, serialization corruption, or inconsistent recovery point
Application	Login, publishing, media, search, forms, cron, REST, and mail sandbox pass	PHP fatal, duplicate queues, write failure, or uncontrolled outbound action
Web/TLS	Critical routes, redirects, certificates, cache headers, and proxy origin are correct	Redirect loop, mixed content, 5xx, or exposed private staging
Observability	Error rate, latency, disk, database connections, and queues have baselines	Metrics stay over thresholds or logs show new errors

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/"

Launch with low traffic or an atomic release switch, retaining the old release, database snapshot, configuration, and DNS fallback. Compare baselines through the agreed observation window. When a stop condition fires, do not continue changing one item at a time: restore the old release and matching database, restore server rules, purge the new cache, and verify recovery health. Record the cause, commands, versions, hashes, approvals, data differences, and follow-up repair.

14. Current official references

15. Exact archive of the 2011 source

The complete visible source_export body follows. No source text, links, whitespace, or punctuation were changed; only the inert outer code fence was added. The original export and Git history remain unchanged.

Warning: the archived sequence deletes all database tables and configuration first. It is not a current operating guide. Use the maintained runbook above.


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，恢复或导入数据库。