Website backup: files, databases, and a tested restore

A website backup is a recoverable copy of the files, content, and configuration your site needs to work. For a self-hosted site, that may include a database as well as uploaded images and code. On a hosted website builder, recovery depends on the platform’s backup and export features.

The useful question is whether you can restore the site you need, from a known date, within an acceptable time. A downloaded archive or a successful backup notification is only part of that evidence. This guide explains what to capture, how to protect it, and how to test a restore without overwriting your live website.

Start with the type of website you run

Identify who controls the hosting, database, domain, and backups. A self-hosted WordPress installation, a WordPress.com plan, and a hosted builder such as Webflow have different recovery procedures. Do not assume that instructions for one apply to the others.

For a self-hosted site, ask the host or administrator what the backup contains and how to restore it to a separate location. For a hosted builder, check its current restore scope, export limits, plan requirements, and account-access requirements. For the broader storage concepts, see our cloud backup guide.

What belongs in a website backup?

Create an inventory before selecting a backup tool. Include the parts needed to serve pages and the services that support important visitor actions, such as placing an order or submitting a form.

Site files and uploaded media

For self-hosted WordPress, preserve the required themes, plugins, uploads, custom code, and configuration. The official WordPress file-backup guide explains what the site files cover. Include configuration files that your file-transfer tool may hide, and record the software versions needed to rebuild the environment.

If images or documents live in a separate storage service, inventory that location too. A copy of the web server’s directory cannot capture files stored elsewhere unless the backup process explicitly includes them.

The database

The WordPress database-backup guide distinguishes database content, such as posts, pages, comments, and settings, from themes, plugins, and uploaded files. A database export usually needs to be imported into a compatible database system during recovery. Downloading the site directory alone does not do that.

Check custom plugin tables and separate application databases. Record which database belongs to the site, rather than relying on a name that may be unclear to the person restoring it later.

Configuration and external dependencies

Keep a recovery record for DNS, redirects, scheduled jobs, certificates, runtime settings, and external integrations. Store secrets through your approved credential-management process and document how an authorized person can retrieve them. The recovery record should identify the responsible account owners without becoming a plain-text list of passwords.

Decide separately how to recover data held outside the website, such as payment records, mailing lists, or externally stored form submissions. Restoring the website does not necessarily roll those services back to the same point.

Keep files and the database consistent

Treat the database and files as a coordinated backup set with a shared identifier and capture time. The WordPress backup documentation recommends keeping them together as a set. Matching dates are useful, but they do not by themselves prove consistency on a busy site.

For example, a database may contain a reference to a newly uploaded image that an earlier file copy missed. A shop may receive new orders while a backup is running. Ask how the selected tool coordinates those changes, and what activity must pause during capture.

For administrators using MySQL, a single-transaction dump provides a consistent snapshot for transactional tables such as InnoDB, with documented limits for other table types and concurrent schema changes. It does not coordinate a separate copy of uploaded files. Use a procedure appropriate to the application, rather than assuming one database option solves the entire backup.

For a small site, an agreed window that pauses all relevant writes may be practical. Putting up a maintenance page is insufficient if background jobs, administrators, or integrations can still change data. Busy services need a backup method designed for their workload.

Choose between manual and automatic backups

For a self-hosted site, compare the host’s backup service, a WordPress backup plugin, and an administrator-managed process. Use the same questions for each: what is included, where are copies stored, how are failures reported, and can you restore without the original site working?

A manual backup can provide a useful checkpoint before a change. Automatic backups can cover routine work on a defined schedule, but still need monitoring and a tested restore process. Confirm that the schedule is actually configured; “automatic” does not tell you its frequency or retained history.

Before relying on a tool, create one backup set, verify its contents, and run the test below. Choose by demonstrated recovery coverage and ongoing effort, rather than the number of features listed.

Choose a schedule and retention period you can explain

Set the schedule from the amount of recent work the site can afford to lose. A portfolio edited occasionally has different needs from a shop receiving orders all day. Take an additional recoverable copy before substantial changes, while continuing the regular schedule.

As a simple example, a restore point captured at midnight will not contain a page written at 10 a.m. If the site fails at 6 p.m. and that is the newest usable point, the missing interval is 18 hours. That example assumes the backup completed successfully; failed jobs can leave an older restore point.

Define how long to keep versions, who can delete them, and when to review the policy. Keep enough history to investigate problems discovered late, within the organization’s retention requirements. If the tool uses incremental backups, confirm which earlier backup and change files are needed for a restore before removing any part of the set.

Send failure alerts to an owner and a backup contact. Check the last successful capture, included components, destination, and available storage. An automation that keeps running with the wrong exclusions can produce consistently incomplete backups.

Protect the backup separately from the website

A backup stored only on the same server can be lost with that server. Keep a separate copy whose access and recovery do not depend entirely on the live site. Our 3-2-1 backup guide explains how multiple copies and locations can reduce shared failure risks.

CISA’s ransomware guidance recommends offline, encrypted backups and regular recovery testing. A second online copy is not automatically isolated from an attacker who can access both locations.

Limit backup access, protect administrator accounts, and check that authorized recovery staff can obtain the required decryption keys if the website account is unavailable. Test that access path before an incident.

Do not leave database dumps or backup archives in a publicly accessible website directory or storage bucket. OWASP documents how forgotten backup files can expose source code, credentials, and other sensitive information. An obscure filename does not make a publicly downloadable archive private.

Understand hosted-builder backup and export limits

A platform restore point and an export serve different purposes. Check both before treating a downloaded file as a complete website backup.

Webflow, for example, provides automatic and manual restore points. Its backup documentation lists effects on settings and data, including scheduled CMS items and locales. Review those effects before a restore and check the resulting publication queue afterward.

Webflow’s code export documentation states that CMS and Ecommerce content, localized content, and several hosted features are excluded. A code ZIP is therefore not a complete working copy of a dynamic site. Export relevant collection data separately and document what still depends on the platform.

For any hosted builder, establish how you would recover after an accidental edit and after losing account access. Those are different situations. Record who can request help and which data you hold independently.

Test a restore in a separate environment

Use a test environment with its own database and access controls. Keep it separate from production, block public access, and disable outbound email, live payments, webhooks, and scheduled integrations until they can be tested safely. A restored site can otherwise act on real customers or external systems.

Follow the host’s or backup tool’s recovery procedure. If the test site uses a different domain, stored URLs may need adjustment. The official WordPress migration guidance warns that indiscriminate database replacements can damage serialized data. Use a method designed for WordPress and inspect its proposed changes before applying them.

Check more than the homepage. Verify representative pages, uploaded images, downloads, administrator access, navigation, search, and important forms. Test payments only in an appropriate test mode. Measure the time needed to retrieve the backup, rebuild the environment, and validate the result.

A small WordPress restore exercise

This exercise is for a non-production WordPress site using test content. It is a procedure you can run with your chosen backup tool, not a reported test result.

1. Create a test page with the text “Backup check A.” Upload a new test image and place it on that page. Record the page URL and image filename.
2. Capture a coordinated backup of the database and files. Record its identifier, capture time, completion status, and storage location.
3. On the source test site, change the text to “Backup check B” and upload a second test image after the backup has completed.
4. Restore the recorded backup into a separate, empty test environment using the tool’s documented process. Apply any required test-domain changes there.
5. Open the restored page. It should show “Backup check A” and the first image. The later text and second upload should be absent from the restored backup state.
6. Check that the image is served by the restored environment, not silently loaded from the source site. Confirm administrator access and test the site’s important functions.
7. Record the elapsed time, missing components, errors, and corrective actions. Repeat the test after fixing a problem.

This exercise checks a small content-and-file example. It does not validate every plugin, integration, or recovery scenario. Expand it to cover the functions your site depends on. Our recoverability testing guide covers broader recovery validation.

Prepare the production recovery decision

Before a real restore, identify the recovery point and the newer data it would replace. A rollback can remove orders, edits, or submissions created after that point. Decide how to preserve or reconcile those records before changing production.

If compromise caused the incident, restoring an old copy does not resolve the cause on its own. Use the incident-response process to assess the backup, secure access, and address the weakness before returning the service to use.

Keep a short runbook with the backup location, access route, restore steps, validation checks, and the person authorized to approve the return to service. Update it after a change of host, backup tool, or important integration.

Website backup checklist

• The backup scope includes the required files, database, and external data.
• The capture method keeps related components consistent.
• The schedule and retained history match the site’s recovery needs.
• A separate protected copy and recovery credentials are available.
• Failures reach someone who can investigate them.
• A restore has been tested away from production, with the result recorded.
• The owner understands what a production rollback could replace.

A useful website backup plan leaves the next person with a known recovery point, accessible copies, and a restore procedure they have evidence to trust.