How to Back Up a Website: Files, Databases, Restore Tests, and Backup Schedules

Overview

If you need a clear answer to how to back up a website, start with one rule: a backup only matters if you can restore it. Many site owners discover too late that they saved the wrong folders, skipped the database, or relied on a host snapshot they never tested. The goal is not to collect copies. The goal is to preserve a working version of the site.

For most websites, a complete backup includes four parts:

• Website files: application files, themes, plugins, uploads, media, configuration files, and custom code.
• Database: posts, pages, settings, user accounts, orders, form entries, and other dynamic content.
• Environment details: PHP version, server settings, cron jobs, DNS notes, SSL-related setup, and any special dependencies.
• Restore instructions: where the backup is stored, how to access it, and the steps to rebuild the site quickly.

This matters because different sites fail in different ways. A plugin conflict might damage the database. A mistaken file edit might break the theme. A server issue might require a full rebuild on a new host. If you only back up one layer, recovery can still be slow or incomplete.

Use this simple rule of thumb:

• If your site changes often, back up often.
• If your site earns money, collect leads, or serves internal users, use automated backups.
• If you are about to make changes, take an on-demand backup first.
• If you have never tested a restore, treat your backups as unverified until you do.

It also helps to separate backup types:

• Full backup: files plus database.
• Database-only backup: useful for content-heavy sites where data changes constantly.
• File-only backup: useful before code edits, theme changes, or design work.
• Snapshot or image: a host-level copy of the environment, often helpful but not a complete substitute for an accessible application-level backup.

If you run WordPress, this process pairs well with a staging workflow. Before major updates, create a backup and test changes on staging first. If you need a separate guide for that process, see How to Create a Staging Site for WordPress and Test Changes Safely.

Checklist by scenario

This section gives you a reusable website backup checklist by situation. You do not need the same routine for every site event.

1. Before updating plugins, themes, CMS core, or custom code

Use this checklist before routine maintenance:

• Confirm the site is currently working on the front end and in the admin area.
• Take a full backup of files and database.
• Label the backup with the date, time, environment, and reason, such as pre-plugin-update.
• Store the backup in a location separate from the live server.
• Note current versions of plugins, themes, CMS core, and PHP.
• If possible, test the updates on staging first.
• After updating, verify key user flows: homepage, navigation, forms, login, checkout, search, and page templates.

This is the most common use case because routine changes break more sites than dramatic disasters. If you are troubleshooting forms after an update, a related guide is How to Fix a Website Contact Form That Is Not Sending Emails.

2. Before changing hosts or moving servers

Migrations deserve a stricter process because you may need the backup as both insurance and source material for the move.

• Create a full backup of files and database.
• Export the database in a standard format your new environment can import.
• Copy hidden files such as .htaccess where relevant.
• Save configuration files, environment variables, and redirect rules.
• Document DNS records, email routing, subdomains, and SSL setup.
• Verify media uploads and large asset directories are included.
• Store one copy locally and one in remote storage.
• Test the backup before changing DNS.

If the purpose of the backup is a host move, also review How to Migrate a WordPress Site to a New Host Without Downtime and How to Choose Web Hosting for a Small Website: Shared, VPS, Cloud, and Managed Options.

3. Before redesigns, theme changes, or structural changes

Design work often changes templates, menus, widget areas, and media references. Back up more than just the theme directory.

• Take a full backup.
• Export menus, widget settings, and customizer settings if your platform supports it.
• Save a crawl or list of important URLs.
• Record current robots and sitemap behavior.
• Capture screenshots of key pages for comparison after launch.
• Test a restore plan before making the structural change.

After relaunches, related issues often involve crawl control and HTTPS cleanup. Useful follow-up guides include robots.txt Guide for Beginners: What to Allow, Block, and Test, XML Sitemap Guide: How to Create, Submit, and Troubleshoot Site Maps, and How to Fix Mixed Content Errors After Enabling HTTPS.

4. For routine operations and scheduled protection

This is where a website backup schedule matters most. Choose a schedule based on content change frequency and business impact.

A practical starting point:

• Low-change brochure site: weekly full backups and before any manual changes.
• Content site or blog: daily database backups, weekly full backups.
• Membership, store, or lead-heavy site: frequent automated database backups and daily or more frequent full backups, depending on activity.
• Development-heavy site: backups before deployments plus a regular automated schedule.

Retention matters too. Keep more than one restore point. A backup taken after malware, data corruption, or a silent configuration problem may not help. It is usually safer to keep a short set of recent backups and a smaller archive of older known-good versions.

5. During an incident or suspected compromise

When a site is already failing, act carefully. You may need to preserve evidence and avoid overwriting a useful older copy.

• Do not rely only on the current damaged state.
• Create a copy of the current files and database for investigation.
• Locate the last known-good backup.
• Check what changed between the current version and the known-good version.
• Restore to a clean staging or isolated environment first if possible.
• Change credentials after recovery if compromise is suspected.
• Verify core functions before reopening full access.

If the site is broken in a more limited way, such as routing or rewrite issues, a targeted fix may be enough. For WordPress paths and permalinks, see How to Fix the WordPress 404 Error: Permalinks, .htaccess, and Server Checks.

What to double-check

This section is where backups become dependable. Before you assume the job is done, verify these points.

Files and folders included

Check that the backup actually includes:

• Application core files where relevant
• Themes and plugins or extensions
• Uploads and media libraries
• Custom code and configuration files
• Hidden files such as .htaccess when applicable
• Generated files that are hard to recreate

Be careful with platforms that store critical settings outside the main web root or in environment variables. The site may restore visually but still fail because credentials or paths are missing.

Database completeness

If you need to backup files and database, the database is often the more important half. Double-check:

• All expected tables are present
• The export completed without interruption
• The file size is plausible for the site
• Character encoding is preserved
• You can import the backup into a test environment

For dynamic sites, a stale database can be as damaging as no database at all. That is why schedule and timing matter.

Storage location and access

A backup stored only on the same server is vulnerable to the same outage, deletion, or account issue. Verify:

• You have at least one off-server copy
• Access credentials to the storage location are documented and current
• File naming is clear enough to identify the right restore point quickly
• Permissions are limited to the right people

Restore test

The most overlooked step in any restore website backup plan is the test restore. At minimum:

• Restore the backup to a staging site or local environment
• Confirm the homepage loads
• Check admin login
• Open several content types and templates
• Verify forms, search, checkout, or other mission-critical workflows
• Review media links, redirects, and static assets

If the site uses a different domain in staging, watch for hard-coded URLs and HTTPS issues. After restore, also validate crawl-related files and structure. If you changed site sections, you may need to review directory strategy as outlined in Subdomain vs Subdirectory for SEO and Site Structure: When to Use Each.

Recovery time expectations

Backups are part of operations, not just storage. Ask:

• How long would it take to restore this site?
• Who has permission to start the restore?
• Are DNS, SSL, and application credentials available if rebuilding on a new server?
• Is there a written checklist someone else could follow?

A backup process is stronger when it works even if the usual admin is unavailable.

Common mistakes

Most backup failures are procedural. The tools may be fine, but the process is weak. These are the mistakes worth avoiding.

• Backing up only files: common on CMS sites where the real content lives in the database.
• Backing up only the database: risky when themes, plugins, uploads, and custom code matter.
• Keeping backups only on the same server: convenient but fragile.
• Not labeling backups clearly: in a crisis, vague filenames slow down recovery.
• Depending entirely on host-level snapshots: they can help, but you still want an accessible application-level copy.
• Never testing a restore: this is the classic failure point.
• Using a schedule that does not match site activity: a weekly backup may be fine for a static site and inadequate for an active store.
• Ignoring hidden config files and environment settings: the restored site may not connect to the database or send email correctly.
• Overwriting old backups too quickly: you may need an older clean version if a problem went unnoticed for days.
• Skipping a manual backup before a change because automation exists: scheduled backups do not always align with the exact moment you need a rollback point.

Another subtle mistake is treating performance tooling or caching as a backup strategy. They solve different problems. If you are optimizing the site after recovery, use a separate performance checklist such as How to Speed Up a WordPress Site: Performance Checklist You Can Reuse.

When to revisit

Your backup policy should not be written once and forgotten. Revisit it whenever the site, stack, or business impact changes. The right backup setup for a simple brochure site can become inadequate once the site starts collecting leads, publishing daily content, or processing transactions.

Review your process at these moments:

• Before seasonal planning cycles or high-traffic periods
• Before redesigns, migrations, or major plugin rollouts
• When workflows or tools change
• When the hosting environment changes
• When your site adds new forms, e-commerce, memberships, or integrations
• After any incident, even a small one
• At regular maintenance intervals, such as quarterly

For a practical recurring routine, use this short action list:

1. Confirm what data your site cannot afford to lose.
2. Set a full backup schedule and, if needed, a more frequent database schedule.
3. Store copies off-server and verify access.
4. Document restore steps in plain language.
5. Test one restore on staging.
6. Update the checklist whenever the site architecture or workflow changes.

If you want one takeaway from this guide, make it this: a website backup is a recovery process, not a checkbox. Build a simple system, test it, and revisit it before important changes. That gives you something far more useful than a pile of backup files. It gives you a controlled way back to a working site.