The correct time to discover that a backup is incomplete is before a
website fails. A dependable WordPress backup contains the files, the
database, and enough information to restore them to a working
environment.
Use this process whenever you plan to update critical plugins, edit
theme code, change hosting, alter DNS, install a security tool, or make
a large content change.
You may also hear this described as ‘save my WordPress site before an
update,’ ‘make a copy of my website before I change it,’ or ‘how do I
undo a WordPress change?’ Each question leads to the same rule: create
and verify a recovery point before the risky action begins.
What a complete
WordPress backup contains
WordPress is not a single file. A restorable backup normally
includes:
- The database, which contains posts, pages, settings, users, menus,
and much plugin data. - The
wp-contentdirectory, including uploads, themes,
plugins, and must-use plugins. - Configuration files such as
wp-config.phpand server
rules when applicable. - Any files stored outside the normal WordPress folders but required
by the site.
A database-only backup will not recover uploaded images or custom
theme files. A files-only backup will not recover most content and
settings.
Use more than one backup
layer
Hosting-provider backups are convenient and often the fastest way to
restore a whole account. A WordPress backup plugin can provide more
control over schedules and components. A manually downloaded copy gives
you a backup outside the hosting account.
For an important site, use at least two independent locations. A
backup stored only on the same server can disappear during an account
failure, compromise, or accidental deletion.
Back up immediately
before risky work
Scheduled backups are valuable, but timing matters. If the last
backup ran two days ago, restoring it could erase two days of form
entries, comments, purchases, or edits.
Create an on-demand backup immediately before the change. Label it
with the date and purpose, such as before-rank-math-update
or before-theme-header-edit. A descriptive label makes the
correct restore point easier to identify during an emergency.
Download and protect the
backup
Store an external copy on a trusted local drive or reputable
cloud-storage service. Do not put publicly accessible backup archives
inside the web root. Backup files can contain database credentials,
email addresses, private drafts, and other sensitive data.
Use encryption when the backup system provides it, protect the
storage account with multifactor authentication, and restrict access to
people who genuinely need restoration privileges.
Verify instead of assuming
A “backup complete” message confirms that a process finished; it does
not prove the website can be restored. At minimum, verify that the
backup set lists both database and file components, has a plausible file
size, and can be downloaded.
For higher-value sites, perform a test restoration to a staging
location periodically. Confirm that pages, images, logins, menus, forms,
and critical plugin settings survive the process.
Know the
difference between a backup and staging
A backup is a recovery copy. A staging site is a safe working copy
used to test changes. One does not replace the other.
Before a significant modification:
- Create and verify a backup.
- Copy the site to staging.
- Test the change on staging.
- Record the steps and expected result.
- Apply the approved change to production.
- Perform a focused post-change test.
Choose a retention schedule
Retention depends on how frequently the site changes. A brochure site
may be adequately protected by weekly backups plus an on-demand copy
before changes. A busy store or membership site may require frequent
database backups and daily full backups.
Keep several generations. If malware or corruption remains unnoticed
for a week, seven identical recent backups may all contain the problem.
Monthly or milestone copies add useful history.
Do not restore casually
Restoration can overwrite current information. Before restoring,
determine what changed after the selected backup was created. Preserve
recent orders, form submissions, comments, or content where
possible.
Confirm the exact target site and database. A restoration is
destructive even when it is necessary, so it deserves the same care as
any other high-impact change.
A short pre-change checklist
- Files and database included
- External copy downloaded
- Backup date and purpose labeled
- Administrator login confirmed
- Hosting access confirmed
- Current site screenshot captured
- Planned change documented
- Rollback steps understood
A backup is valuable only when it is complete, accessible, and
understood. Ten minutes spent verifying it can prevent hours of
uncertain recovery.
Define recovery objectives
Two simple questions improve a backup plan:
- How much recent data can the site afford to lose?
This determines backup frequency. - How long can the site remain unavailable? This
influences storage location, restoration method, and whether tested
standby infrastructure is necessary.
A site that changes once a month has different needs from a store
receiving orders every hour. Choose a schedule based on business
activity, not a generic daily-or-weekly recommendation.
Frequently asked questions
Does my hosting
plan already include backups?
It may, but confirm the schedule, retention period, included
components, restoration procedure, and whether backups remain available
after an account problem. Provider backups are one layer, not a reason
to skip an independent copy.
Can I keep a backup inside
WordPress?
A temporary archive may be created there, but it should not be the
only copy. Large archives consume storage and may be exposed if stored
in a publicly reachable location.
How often should I test
restoration?
Test after selecting a new backup system and periodically thereafter.
Test again after major hosting or architecture changes. Higher-value and
frequently changing sites justify more frequent exercises.
Related guides
- WordPress Site Recovery Checklist
- A
Practical WordPress Pre-Publish QA Checklist