# How to Back Up a Website Before Any Changes

> To back up a website, save two things: all files, meaning core, themes, plugins and uploads, and an export of the database. Do it before every change, keep three to five copies in different places, and restore one copy to a test environment at least once to prove the backup actually works.

- URL: https://kleinerauftrag.de/en/delivery/how-to-back-up-a-website/
- Language: en
- Updated: 2026-10-19
- Publisher: Kleiner Auftrag (OnlineBuilders LLC, https://onlinebuilders.biz)

The photo above shows a burnt-out server. Every backup stored on that machine went with it. That's the dramatic version. The quiet versions hurt just as much: a backup plugin that has been saving files but not the database for six months, or an export that stopped at 80 percent and never complained.

Before anyone changes your site, whether that's you or a developer you've hired, you need a state you can return to. Here's how to make one and how to check it's real.

## What a complete backup contains

Sites built on a content management system store their content in two separate places. The WordPress documentation on [backups](https://developer.wordpress.org/advanced-administration/security/backup/) spells it out. Posts, pages, comments and settings live in the database. The core software, themes, plugins, uploaded images and configuration files such as `wp-config.php` and `.htaccess` live in the file system.

Download the files over SFTP and you have no content. Export only the database and you have no images. To restore, you need both.

Joomla, Drupal or a custom-built shop follow the same principle. The exception is a purely static site without a database, where ideally every file already lives in a Git repository.

**Back up and restore: the order matters**

1. **Backup: database first** Export as a `.sql` file so it matches the state of the files.
2. **Backup: then the files** Every folder, including uploads and config files.
3. **Store** Both together in one dated folder, in several places.
4. **Restore: files first** Copy them to the test environment.
5. **Restore: then the database** Import it, and update `wp-config.php` if credentials changed.

That order comes straight from the WordPress documentation: database first when backing up, files first when restoring.

## Three ways to take a backup

**Through your host.** Hosts often run automatic backups and let you restore from their control panel. Convenient. Still, check how far back they go, whether you can restore on your own and whether you can download a copy. A backup stored only with the same provider doesn't help when the provider is the problem.

**With a plugin.** WordPress has backup plugins that bundle files and database into an archive and send it to cloud storage. The catch: they run inside the very site they're protecting. When something goes wrong you often find out at restore time. That's why the WordPress documentation advises taking a manual backup now and then, even with automation, to confirm the automation still works.

**By hand.** With SFTP access and database access, for example through phpMyAdmin, you can download both yourself. With SSH access, two commands do the job:

```bash
# Export the database (credentials are in wp-config.php)
mysqldump -u DB_USER -p DB_NAME > backup-2026-10-19.sql

# Pack all site files into one archive
tar -czf backup-2026-10-19-files.tar.gz /path/to/website
```

Download both files over SFTP and check they aren't suspiciously small. A `.sql` file of a few kilobytes for a site with hundreds of posts is a warning sign.

## Shopify and other hosted platforms

On hosted shop platforms you have no access to the server or database. Shopify's [help page on exporting products](https://help.shopify.com/en/manual/products/import-export/export-products) lists creating a backup among the uses of the product CSV export. Customers and orders can be exported as CSV too, and you can download your theme from the admin.

That isn't a complete copy. Some settings and relationships don't appear in any export file. Before a theme change, duplicating the live theme and editing the copy is often enough, since Shopify lets you keep several themes with only one published. For anything more, third-party backup apps exist and are worth comparing case by case.

## What no website backup includes

Even a complete backup of files and database misses parts of a working website. These live elsewhere and tend to get lost in a migration or a total failure:

- **Email mailboxes** hosted with the same provider. They aren't part of the site files and need their own backup.
- **DNS records** for your domain, such as mail settings, Google verification or entries for outside services. A screenshot of the DNS panel is a decent record.
- **Scheduled tasks** on the server, known as cron jobs, that might trigger an integration overnight.
- **Settings in outside services** such as your payment provider, newsletter tool or form spam protection, tied to the site through API keys.
- **Server settings** like the PHP version or redirects set in the host's control panel.

You don't have to back all of that up for a small job. You should know it exists, though, especially if the developer is working on email delivery, your domain or an integration. Half a page of notes covering these points is gold on a bad day.

## Where to keep backups

The WordPress documentation recommends keeping at least three to five recent backups in different places, such as with your host, in cloud storage and on your own computer. Several copies matter because faults don't always show up straight away. If a change on Monday breaks a form and someone notices on Thursday, a single backup from Wednesday leaves you with no clean state.

Mind data protection. A backup holds the same customer data as your site. An unencrypted archive in a publicly shared cloud folder is a data leak waiting to happen.

**Before a developer touches your site**

- [ ] Database export and files from today exist
- [ ] Backup stored somewhere besides your host
- [ ] File sizes look plausible (no database of a few KB)
- [ ] Restore tested at least once on a test environment
- [ ] Developer knows where the backup is and how to restore it
- [ ] Separate user account created for the developer

## The test that turns a file into a backup

You only know a backup works once you've restored it. Ideally to a staging environment, which some hosts offer, or locally on a computer. If the site runs there with all its content and images, the backup is good. If it doesn't, you've found out on a quiet afternoon rather than on the day the live site goes blank.

You don't need to repeat that test before every change. Once per backup method is enough, and again after anything fundamental changes, like moving hosts. If you work with a developer, a restore test makes a neat small job of its own. It rarely takes long and pays off when it counts. Our guide on [how to brief a developer](https://kleinerauftrag.de/en/scoping/how-to-brief-a-developer/) shows how to describe it.

Have the backup ready before any job starts, together with a [separate login for the developer](https://kleinerauftrag.de/en/delivery/share-passwords-with-developer/). When you set acceptance criteria, it's reasonable to include one saying a backup is taken before going live. You'll find wording in our [acceptance criteria examples](https://kleinerauftrag.de/en/scoping/acceptance-criteria-examples/).

If you'd rather not organise backups, updates and monitoring yourself, you can hand that to a provider of [hosting and operations](https://onlinebuilders.biz/solutions/hosting). Everyone else: take a manual backup with database and files today, store it in two places, and book an hour next week to restore it to a test environment.

## Step by step

1. **Export the database** Export the database as a .sql file using phpMyAdmin, your host's control panel or mysqldump. Back up the database first.
2. **Save the files** Download all site files via SFTP or as an archive from your host, including configuration files such as wp-config.php and .htaccess.
3. **Keep both together** Store the database export and the files together in one folder with the date in its name.
4. **Store copies in several places** Keep three to five copies in different locations, for example at your host, in cloud storage and on your own computer.
5. **Test a restore** Restore the backup to a test environment: files first, then the database. Only when the site runs there is the backup proven.

## FAQ

### Is my host's automatic backup enough?

As a baseline, often yes. As your only backup, no. Check how far back it goes, whether you can restore it yourself and whether restores cost extra. Before a change, keep an extra copy that doesn't live with the same provider.

### How often should I back up my website?

The WordPress documentation suggests weekly for small sites with few posts, daily for high-traffic sites with many posts, and always before an upgrade. A shop taking orders every day needs daily backups at minimum.

### How many backups should I keep?

At least three to five recent ones, spread across different places, according to the WordPress documentation. That leaves you a clean copy even if a problem only shows up a few days after it started.

### Does GDPR apply to backups?

Yes. A backup holds the same customer data as the live site. Store it encrypted or at least access-controlled, and treat any cloud service that holds it as a processor of that data.

Photo: John from USA, CC BY 2.0 (https://commons.wikimedia.org/wiki/File:Backup_Backup_Backup_-_And_Test_Restores.jpg)