How to back up my website before making changes (2026)
Quick Answer
Before you change your website, take a full backup of both the site files and the database, store the backup somewhere separate from the server, and test that you can restore it. The safest order is: identify what needs backing up, put the site into a low-change state if possible, create the backup, verify it, then make your changes. A backup is only trustworthy if you can see all expected files, confirm the database export completed, and ideally restore it to a test location.
Overview
A proper website backup protects you from broken updates, accidental deletions, failed plugin or theme changes, server problems, and hacking cleanup mistakes. For most websites, you need two things: the site files and the database. Files usually include themes, plugins, media, configuration files, and custom code. The database usually holds posts, pages, settings, user accounts, orders, forms, and other dynamic content. If you miss either part, a restore may be incomplete or unusable. The best approach is not just to click a backup button and hope. First work out how your site is built and where its data lives. Then reduce the chance of new content being added during the backup, especially on shops, membership sites, or busy blogs. Create the backup using your hosting panel, your CMS backup tool, or command-line tools if you manage the server yourself. Save copies off the server as well, because a server failure or compromise can affect local backups too. The final and most important stage is verification. Check that the backup files exist, are recent, and can be opened or restored. If possible, do a test restore to a staging site or local environment. That is how you know the backup is genuinely usable, not just present.
Who this is for
Website owners, administrators, freelancers, and small teams making updates to a CMS site, custom site, shop, or business website.
What you’ll need
- Admin access to your website or CMS
- Hosting control panel, SSH/SFTP, or backup plugin access
- Access to the website database if your site uses one
- A separate storage location such as cloud storage, local computer, or another server
- Enough storage space for at least one full backup
- A staging site or local test environment if you want to verify by restoring
Before you start
Check how your website is built: CMS or custom, single server or managed platform, and whether it uses a database. Confirm where uploads, configuration files, SSL keys, environment files, and cron jobs are stored. If the site is transactional, note that orders, form submissions, comments, or bookings may change while you are backing up; plan a maintenance window or quiet period if possible. Also check whether your host already creates automatic backups, but do not rely on that alone without confirming retention and restore options.
Step-by-step
- 1
Identify everything that must be backed up
List the parts of your site that would be needed to rebuild it exactly as it is now. For most sites this means website files and the database. Also check for items people often forget: uploaded media, custom theme files, plugin or extension folders, configuration files, environment files, redirects, scheduled tasks, and any assets stored outside the main web root. If your host uses a separate mail service or CDN, note that these may need separate exports or settings records.
Why: You cannot restore what you did not save. Many failed recoveries happen because someone backed up only files or only the database.
- 2
Reduce live changes during the backup
If practical, back up during a quiet period. For ecommerce or membership sites, consider temporary maintenance mode, pausing content editing, or at least telling your team not to make changes while the backup runs. If you cannot pause the site, note the backup time so you know what data may have changed afterwards.
Why: A backup taken while content is changing can leave the files and database out of sync, especially during updates, checkouts, or form submissions.
- 3
Create a full backup of site files
Use one reliable method: your hosting control panel backup tool, a CMS backup tool, or direct access with SFTP/SSH. Copy the full web root and any linked directories your application uses. Make sure hidden files are included where relevant, because important configuration files may not be visible by default. If your platform provides downloadable archive files, save them with a clear date and site name.
Why: Files contain the code, media, and configuration needed for the site to run and look correct after a restore.
- 4
Export the database
Create a complete database export using your hosting panel, database tool, CMS backup system, or command-line database dump tool. If your site uses more than one database, export each one. Save the export in a standard format your platform can restore from. Make sure the export completes without errors and is dated clearly.
Why: The database usually holds the content and settings that make the site current. Without it, the restored site may load but be missing pages, users, orders, or configuration.
- 5
Store the backup away from the live server
Download the backup to your computer and also copy it to a separate storage location such as secure cloud storage or another server. Keep the backup names clear so you can identify which site and date they belong to. If the backup contains personal data, store it securely and limit access to authorised people only.
Why: A backup kept only on the same server can be lost in the same outage, account issue, or security incident that affects the live site.
- 6
Verify that the backup is complete and usable
Check that the backup files are present, readable, and recent. Confirm the file backup contains expected folders such as uploads or media and that the database export is not empty or obviously incomplete. The best check is a test restore to a staging site or local environment, then loading key pages and confirming the admin area works. Record where the backup is stored and how it was made.
Why: Verification turns a backup from a guess into something you can trust. A corrupted or partial backup is often only discovered when it is too late.
- 7
Only then make your website changes
Once the backup is verified, go ahead with the update, edit, plugin change, code deployment, or server change. Keep the backup available until you are satisfied the site is stable. If the change is significant, consider taking another backup immediately before the final deployment step.
Why: Making changes after a verified backup gives you a known recovery point if something breaks.
Why this works
Website changes usually affect either the code and files, the database content, or both. A complete backup captures the state of all the parts needed to recreate the site. Storing it separately and testing restoration protects against both technical failure and false confidence.
Common mistakes to avoid
- Backing up only the files and forgetting the database
- Keeping the only backup on the same hosting account
- Assuming an automatic host backup definitely includes everything you need
- Not including hidden configuration files
- Taking a backup but never testing whether it can be restored
- Making changes on a busy live site while orders or edits are still coming in
Troubleshooting
The backup archive is missing uploads, images, or media
Check whether media is stored in a separate directory, object storage service, or CDN origin. Create an additional backup of that location and note any related configuration.
The database export fails or times out
Try a host-provided export tool, a command-line dump if you have server access, or split the export if your platform supports it. If errors continue, ask your host to confirm database access limits and error logs.
The restored site shows errors even though the backup exists
Check that the files and database are from the same point in time, that configuration values such as database credentials are correct, and that any environment-specific settings were updated for the test location.
You are not sure whether the backup is complete
Compare the backup contents against a simple checklist: web files, uploads, themes or templates, plugins or extensions, configuration files, database export, and any off-server assets or settings.
Compare your options
Hosting control panel backup
Best for: Most site owners who want a straightforward full-site backup
Pros: Usually simple, often includes files and database together, no extra setup
Cons: Quality and restore options vary by host, and backups may stay on the same infrastructure unless you download them
CMS backup plugin or built-in backup tool
Best for: CMS users who want scheduled backups and easier restores
Pros: Convenient, often supports off-site storage, can be managed from the admin area
Cons: May miss server-level items, can fail on large sites, and depends on the CMS still working
Manual backup with SFTP/SSH plus database export
Best for: Developers and administrators who need control and visibility
Pros: Clear understanding of what was backed up, flexible, good for custom sites
Cons: More technical, easier to make a mistake if you miss a component
| Option | Best for | Pros | Cons |
|---|---|---|---|
| Hosting control panel backup | Most site owners who want a straightforward full-site backup | Usually simple, often includes files and database together, no extra setup | Quality and restore options vary by host, and backups may stay on the same infrastructure unless you download them |
| CMS backup plugin or built-in backup tool | CMS users who want scheduled backups and easier restores | Convenient, often supports off-site storage, can be managed from the admin area | May miss server-level items, can fail on large sites, and depends on the CMS still working |
| Manual backup with SFTP/SSH plus database export | Developers and administrators who need control and visibility | Clear understanding of what was backed up, flexible, good for custom sites | More technical, easier to make a mistake if you miss a component |
Alternatives
- Use a staging site provided by your host and take a snapshot before changing anything
- Use version control for code changes alongside regular file and database backups
- Use managed hosting with tested backup and one-click restore features
Pro tips
- Name backups clearly with the site name and date so you can find the right restore point quickly
- Keep a short restore checklist with each backup location
- For important sites, keep more than one recent backup in separate places
- If you run a shop or booking site, note any orders or submissions received after the backup time
- Take a fresh backup immediately before major plugin, theme, PHP, or server changes
Safety notes
- Backups often contain personal data, passwords in configuration files, and business information, so restrict access and store them securely
- Do not share backup archives over insecure channels
- If you restore to a test environment, prevent search engines and the public from accessing that copy
Legal & regulatory notes
If your backup contains personal data, you may have data protection and security obligations depending on where you operate and where the backup is stored. Follow your organisation's retention, access control, and breach-response policies, and use your official legal or compliance guidance for the exact rules that apply.
What this guide does not cover: This guide explains the general process for backing up a website before changes. It does not give platform-specific click paths for every host, CMS, or server setup, and it does not cover full disaster recovery design for complex infrastructure.
Cost considerations
The main costs are storage space, premium backup tools if you use them, and staff time to test restores. Off-site storage and staging environments can add recurring costs, but they usually reduce the risk of a much more expensive outage or data loss incident.
Frequently asked questions
Do I need to back up both files and the database?+
Usually yes. Files hold the code, media, and configuration, while the database often holds the content and settings. Many sites will not restore properly without both.
Is my host's automatic backup enough?+
It may be helpful, but check what it includes, how often it runs, how long backups are kept, and how restores work. For important changes, it is sensible to make your own fresh backup as well.
How do I know the backup worked?+
Check that the backup files exist, look complete, and are recent. The strongest proof is a successful test restore to staging or a local environment.
Should I put my site into maintenance mode first?+
If the site is busy or transactional, that is often a good idea because it reduces the risk of changes happening mid-backup. For quieter sites, scheduling the backup during a low-traffic period may be enough.
What if I only changed a small thing like a plugin or a CSS file?+
You should still back up first. Small changes can still take a site down, conflict with other components, or affect the database.
Sources & references
Guidance on this page is traced to documented sources. Last checked 25 September 2026.
- WordPress.org Support · official
Supports the need to back up both WordPress files and the database, and explains backup methods and restore planning.
- cPanel · manufacturer
Supports use of hosting control panel backup tools and the distinction between full backups and partial backups.
The core backup process is stable, but exact menus, tools, and hosting features change regularly.