How to back up WordPress: files, database, storage, and restoration testing

WordPress backups are made by copying the website’s two components, the files on the server and the database stored in a separate system, at the same time and storing them somewhere separate from the website. A complete answer to how to back up WordPress includes one further step: testing that the copy can actually be restored. A backup file that cannot be opened is no different from having no backup at all.

This guide covers what a backup should include, how often it should be taken, hosting panel, plugin, and manual backup methods, the steps for exporting a database with phpMyAdmin, storage arrangements, and restoration testing. Every step is supported by WordPress.org’s backup and database documentation.

Why back up a WordPress website?

A backup is the only reliable way to return a website to its state on a particular date when it is lost or broken. WordPress’s backup documentationstates that the database contains every post, every comment, and every link, that everything written may be lost if it is deleted or corrupted, and that the causes are not always controllable.

Loss often comes from an unexpected source: a plugin update leaving the database operation unfinished, an accidentally deleted page, a compromised administrator account, a server failure, or suspension of a hosting account after missed payments. In each of these situations, a proper backup reduces rebuilding work that could take days to a matter of hours.

A backup does not replace security precautions; it does not prevent an attack or an error, but only makes recovery afterward possible. Updates, strong login protection, and permission management reduce risk, while the backup is the final safeguard that comes into play on the day those precautions are not enough.

What should a backup include: files and the database

A complete WordPress backup includes both files and the database; the website cannot be fully restored with one without the other. The official documentation explicitly corrects a common misconception: downloading the WordPress folder does not back up the database, because the database is usually stored outside that folder in MySQL or MariaDB. The components that must be included in a backup are as follows:

  • Database: posts, pages, comments, users, settings, order records, and form submissions
  • wp-content folder: uploaded images and files, themes, plugins
  • wp-config.php: database connection details and security keys
  • .htaccess and additional files in the root directory: redirect rules, verification files, static pages

According to the documentation, WordPress core files are not the critical component because clean copies can be downloaded again from the official website. The priorities are wp-content, wp-config.php, and the database; nevertheless, taking a full website backup saves time during recovery.

How often should WordPress be backed up?

Backup frequency depends on how often the website changes, and an additional backup is taken before every update. The official documentation gives weekly backups for small websites with little content and daily backups for busy, frequently updated websites as general recommendations. The following table makes this advice more concrete by website type:

Website typeGeneral frequencyWhen to take an additional backup
Corporate promotional website that rarely changesWeeklyBefore every update and design change
Blog or news website with regularly published postsDailyBefore bulk content imports
Website taking orders, memberships, or appointmentsAt least daily; more frequent backups can be considered for the databaseBefore campaign periods and plugin updates

The question to ask when deciding the frequency is this: if everything added since the last backup were lost, how difficult would it be to make up for that loss? Losing orders and form inquiries costs far more than rewriting a blog post.

WordPress backup methods

WordPress can be backed up in three ways: through the hosting company’s backup tool, through a scheduled backup plugin, or by downloading files through SFTP and manually exporting the database. The official documentation states that most hosting companies provide a backup tool, that automatic backup plugins are available in the plugin search section of the WordPress administration screens, and that files can be copied to a computer through SFTP clients.

The hosting tool is convenient, but the backup usually remains in the same account; if access to the account is lost, the backup may also become inaccessible. Plugins automate scheduling and can send backups to cloud storage, but may strain server resources on large websites and are themselves software that must be kept updated.

Manual backup takes effort but shows how the process works. The official documentation also explains that SFTP clients’ synchronization feature can maintain an up-to-date mirror copy of server files on a computer. The documentation recommends supplementing automatic backups with an occasional manual backup as a way of making sure the process works.

Page contents

Trustworthy web agency: handshaking client and team, trust shield illustration

Database backup with phpMyAdmin step by step

A manual database backup is made by exporting it as an SQL file through phpMyAdmin in the hosting panel. A simplified version of the steps in WordPress’s database backup documentation is as follows:

  1. Open phpMyAdmin from the hosting panel and select the database used by WordPress from the left side.
  2. Go to the Export tab in the top menu.
  3. If the Custom method is selected, check that all tables are selected.
  4. Choose SQL as the format; compression can be enabled for large databases.
  5. Select “Add DROP TABLE” so that existing tables can be overwritten during restoration, and “IF NOT EXISTS” to avoid errors.
  6. Use the Go button to download the file to the computer, and store it with the date added to its filename.

Confirm which database belongs to the website using the database name line in wp-config.php. Backing up the wrong database is a common mistake when there are multiple websites in the same hosting account.

Let’s review your existing backup setup together

A free preliminary assessment clarifies where backups are stored, how often they are taken, whether they include both files and the database, and when they were last restored and tested. Missing links and the order for correcting them are noted clearly.

Where should backups be stored? The 3-2-1 principle

Backups should be stored in at least one location independent of the server running the website. WordPress’s backup documentation recommends keeping at least 3 to 5 current backups in different places, for example one on the hosting server, one in cloud storage, and one on a computer; this leaves a version to return to even if one copy becomes corrupted or is lost.

The 3-2-1 principle frequently mentioned in data protection turns the same idea into an easy-to-remember rule. There are three copies of the data in total, with the live website counted as one of them; the copies are distributed across two different storage media; and one copy must remain outside the hosting account and server. This principle is a general approach that works in practice, rather than a standard or legal obligation.

The documentation also reminds readers that most hosting companies back up the entire server, but requesting a copy from that backup can take time. This is why having a backup the website owner can access directly matters when fast recovery is needed. When making a hosting selection , ask how many days back the backups extend and whether the website owner can access them directly through the panel.

The order for backing up and restoring

For a consistent backup, the database is backed up first, followed by the files; during restoration, the sequence is reversed. The official documentation recommends taking the file and database backups close together in time and treating them as a single “backup set”, placing the database dump in the same folder or compressed archive. This prevents confusion over which file backup matches which database, even years later.

Including the website name, date, and content type in filenames (for example, firma_2026-10-01_veritabani.sql) and keeping a short backup log makes the work easier. The log records each backup’s date, scope, storage location, and the last date it was restored and tested; during a crisis, this record identifies which copy to return to within seconds.

During restoration, files are put back in place first, and then the database is imported. In phpMyAdmin, this is done through the Import tab with SQL selected as the format, and the existing database returns to its state at the time of the backup. If the website is being moved to another server or a different database user, the connection details in wp-config.php are also updated with the new values; these steps are also fundamental to the WordPress website migration process.

How do you perform a restoration test?

A restoration test means unpacking the backup into a separate copy without touching the live website and verifying that the website starts up completely from that copy. WordPress’s development copy documentationrecommends using a separate installation to test updates and changes without interrupting the live version; the same environment is suitable for backup testing. The following points are checked during the test:

  • Do the homepage, internal pages, and blog posts open completely?
  • Are the images and downloadable files in place?
  • Can you log in to the administration panel, and are users and roles correct?
  • Do functions such as the contact form, cart, or membership work?
  • Are the latest orders or form records visible in a way consistent with the backup date?

The time taken by the test should also be recorded. Knowing how many hours it will take to bring the website back during a real crisis clarifies both internal expectations and the information to give customers. The test is repeated several times a year, and especially whenever the backup method changes.

Transparent pricing: calculator and budget planning illustration

What should you look for when choosing a backup plugin?

A backup plugin is chosen according to where it sends the backup, how restoration is performed, and whether it provides notifications when an error occurs; interface convenience is secondary. The following criteria guide the evaluation:

  • Can the backup be sent to a destination outside the server, such as cloud storage or a remote server?
  • Can scheduling be set for hours when website traffic is low?
  • Can unnecessary files, such as cache folders, be excluded from the backup?
  • Is an alert sent by email or another channel when a backup fails?
  • Can the archive be encrypted, and are old backups automatically deleted after the specified number is exceeded?
  • Is the backup stored in a standard format, such as an SQL dump and compressed file archive, that can be opened manually even if the plugin breaks?

On large websites, incremental backup, which adds only changed files instead of copying all files every time, reduces both time and storage space; WordPress’s backup resources also include a section devoted to encrypted incremental backups. The plugin itself should also be updated regularly and installed from a reliable source; an abandoned backup plugin can become a tool that fails on the very day it is needed. After setup, always check that the first backup actually reaches its destination and that the archive can be opened.

Backup security and personal data

A backup file is as sensitive as the website itself; it contains user accounts, customer information, form inquiries, and connection details from wp-config.php. For this reason, backups are not left in a publicly accessible web folder, sharing links are not kept public, and the accounts where they are stored are protected with two-step authentication.

WordPress’s hardening documentation provides three ways to make sure a backup has not been modified afterward: encrypting the archive, recording each backup file’s hash value in a separate location, and keeping copies on media that cannot be overwritten. Deleting old backups containing personal data after a specified period is also as important to data security as storing them.

The same applies under KVKK (Turkey’s Personal Data Protection Law): the law lists ensuring the preservation of personal data and preventing unlawful access to it among the data controller’s obligations (Law No. 6698, Article 12). A backup has two aspects in this respect: it is both a means of protecting data and a copy of data that must itself be protected.

Common WordPress backup mistakes

Most backup problems emerge on the day the backup is needed. The most common mistakes seen in practice and the correct approaches are as follows.

Backing up only the database or only the files: the content returns but images are lost, or the reverse happens. Both parts of the backup set are taken together every time.

Keeping all copies on the same server: a server failure or account suspension makes the backups inaccessible along with the website.

Not backing up before an update: the official documentation calls for regular database backups and a backup before every upgrade; the plugin documentation also notes that a current backup should exist before updating. If an error occurs after an update, its source is investigated through WordPress troubleshooting steps, while the backup remains the last resort.

Never testing the backup: an incomplete archive or corrupted SQL file is noticed only when someone tries to open it. Regular restoration testing and backup monitoring can be planned as permanent tasks in the WordPress maintenance and updates routine.

Let’s build a backup plan for your website

A WordPress backup setup is established according to how quickly the website changes, its order or form traffic, and its hosting capabilities. Frequency, storage locations, and the testing schedule can be determined together; a WhatsApp message or a short phone conversation is enough for a free preliminary assessment.

Related guides

Frequently asked questions

The website’s files, especially wp-content and wp-config.php, and its database are backed up close together in time and stored in a location separate from the website. Backups can be taken through a hosting tool, a scheduled plugin, or manually through SFTP and phpMyAdmin; the ability to restore the backup is also tested separately.

WordPress’s official documentation recommends weekly backups for small websites and daily backups for frequently updated websites. An additional backup should also be taken before every update.

It does not; the database is usually located outside the WordPress folder, in MySQL or MariaDB. The database must be exported separately and stored together with the file backup.

WordPress’s backup documentation recommends keeping at least 3 to 5 current backups in different locations. For example, one can be stored on the server, one in cloud storage, and one on a computer.

It is not sufficient on its own; the backup remains in the same account, and requesting a copy can take time. The website owner should also have a copy stored outside the server that they can access directly.

First the files are put back in place, then the database is restored by selecting the SQL file through phpMyAdmin’s Import tab. If server or database details have changed, wp-config.php is also updated.

The backup is unpacked into a separate test copy without touching the live website, and pages, images, login, forms, and recent records are checked. This test should be repeated especially whenever the backup method changes.

Onur Ertem - Onur Freelance Corporate Web Design

Onur Ertem

Strengthen your business online! 🚀 Are you ready to grow your brand with corporate web design and digital marketing solutions? Contact us now and stand out in the digital world with our professional support!

Phone-alt Whatsapp

Call us

Call us for detailed information.

Let us call you!

Share your number and let us call you!

Our other services

Service areas

Contact information