Website backups: plan for the restore, too

Back up the database and the files

A typical WordPress website has two essential parts: its database and its files. The database holds content, settings and other site data. Files include uploads, themes, plugins and configuration. Downloading a folder of files does not automatically include the database.

Keep the parts together as a recoverable set. WordPress’s backup documentation explains this distinction and why both parts matter. Also identify anything outside WordPress—such as a separate email service or an external booking platform—so you do not assume it is included in a website backup.

Choose a recovery window based on what changes

How much new information could your business afford to lose? A brochure website updated occasionally has different needs from a store recording orders throughout the day. Choose a backup frequency around that business requirement, and take a recoverable copy before significant changes.

Also agree on an acceptable recovery time. A nightly backup is not an immediate recovery plan if nobody knows how to access it or which person can approve the restore. Frequency, retention and recovery time are separate questions.

Keep enough history and a recovery path you control

A problem may not be discovered on the day it starts. Retention should allow you to reach a usable version from before the failure, accidental edit or other issue. Confirm which backup types exist and when older copies expire.

Check who owns the hosting and backup accounts. Where appropriate, keep a protected copy outside the system being backed up and verify how it can be retrieved. Avoid treating a copy stored beside the live site as your only recovery option. Protect backup access because a backup may contain customer information and configuration secrets.

• Confirm the actual files and database covered by the backup job.
• Check successful completion and investigate failed or incomplete jobs.
• Record access, retention and the steps for requesting or performing recovery.
• Confirm separately how any external systems retain their own data.

Test a restore away from the live website

Use an isolated environment to restore a representative backup. Check important pages, images, navigation, logins and integrations. Prevent test restores from sending real customer emails, processing payments or exposing private data.

For forms and transactions, understand which records are stored on the website and which are handled elsewhere. A restore can overwrite newer data. The recovery plan should explain how recent orders or inquiries will be reconciled rather than assuming a whole-site rollback is harmless.

Write down the recovery procedure

Keep a short, accessible record of the responsible person, account access process, available backups and restore steps. Store credentials through an appropriate password-management process rather than pasting them into a general project note.

Revisit the procedure when the hosting, website features or people responsible for support change. A plan that depends on a departed employee or an account nobody controls may fail exactly when the business needs it most.

Make the support scope explicit

Ask your hosting or maintenance provider what is included: backup frequency, retention, access, restore support and any limits or additional work. Do not assume a maintenance plan automatically provides every form of recovery or covers third-party systems.

I can help review the setup and identify the questions your recovery plan needs to answer. Specific backup and recovery commitments depend on the hosting and support scope we agree on. Explore WordPress hosting or ongoing website support.