Updated · 31 Aug 2026
Short answer.
A backup is useful only when it can restore one consistent state of the site. An ordinary WordPress project needs at least the database, user uploads, code, and configuration. Stores and member sites also need a clear point in time and an explicit tolerance for lost recent data.
Check first
Evidence before change.
- Where the database, uploads, custom code, and configuration live.
- Whether archives are encrypted and who can download or delete them.
- Whether a copy is stored outside the account or disk running production.
- How many versions remain and how a failed backup job is detected.
- The RPO: how much recent data may be lost.
- The RTO: how long restoration may take.
Safe sequence
Move in small verifiable steps.
- Define the contents. Files without the database—or a database without uploads—do not restore the whole site.
- Prove consistency. Mutable data needs a clear snapshot moment or a maintenance window.
- Restore separately. Deploy into an isolated environment, never over production.
- Test journeys. Open pages, log in, submit a test form, and run jobs without real external side effects.
- Document the procedure. Record the backup source, order, secrets outside the document, and the success criterion.
Common mistakes
What usually increases risk.
- Keeping the only copy beside production.
- Treating a green backup-job status as proof of archive integrity.
- Restoring an old database over production without preserving new data.
- Allowing real payments, mail, or webhooks during a restore test.
320px Site Audit
What can be checked automatically.
Site Audit can observe selected settings and backup signals, but it does not read private archives or launch restoration automatically. “A copy exists” must remain separate from “restoration was verified.”
When help is useful
A concrete next step.
In 320px support, a checkpoint and postflight are part of risky releases; an already failed project needs a separate recovery plan.
Continue
A related guide and the full collection.
01
Updating PHP for WordPress
A safe move to a supported PHP version: code inventory, stage, error logs, critical journeys, production switch, and rollback.
Tell us what the site needs.
A goal, the current difficulty, and an optional website address are enough. Do not send passwords, keys, or private exports.