WordPress Backups: 4 Methods and When to Use Each

A WordPress site is not just a couple of files: on one side there are your files, on the other your database, and very often the mailboxes attached to your domain. If "I took a backup" doesn't mean all three, on a bad day you'll be left with half a site.

In this guide we walk through the four methods used for backing up WordPress — a hosting/cPanel backup, a backup plugin, a manual backup via FTP + phpMyAdmin and automated external backups — step by step, without hiding where each one gets stuck.

1. Before You Back Up: WordPress Has Three Parts

Whichever method you choose, a sound backup must cover the following:

• Files: wp-content — the themes, plugins and uploads (images, PDFs) inside it, plus wp-config.php and .htaccess.
• The MySQL database: Posts, pages, users, comments, WooCommerce orders, plugin settings — the site's "brain".
• Email: The mailboxes attached to your domain (IMAP). They are not part of a site backup; if you migrate host or the account closes, years of correspondence disappear.

Method 2: Hosting / cPanel Backup

This is the easiest starting point. In cPanel you can download a full backup from the Backup or Backup Wizard section:

1. Sign in to cPanel and open Files → Backup .
2. "Download a Full Account Backup" to create an archive containing files + database + email.
3. Once the archive is ready (it takes minutes on large sites), download it and store it somewhere separate — not just on your own computer.

Its limit: By default this backup sits on the same server as your site. If the server disk fails, your account is suspended or ransomware encrypts the files, you lose access to the backup too. For the details see our article on why a hosting backup isn't enough .

Method 3: A WordPress Backup Plugin

Installed from within the dashboard, with a familiar interface. The typical flow: install the plugin, connect a cloud account as the destination, set the schedule.

Its limit: The plugin runs inside WordPress's own PHP process. That means it hits three walls:

• Timeouts: On shared hosting max_execution_time is usually 30–120 seconds. On a site of several GB the process is killed before the backup finishes; the backup is left half-done, yet no error usually appears in the dashboard.
• Memory limit: memory_limit runs out and the process ends silently.
• wp-cron: WordPress's scheduler is not a real cron; if no visitor arrives, the scheduled backup is never triggered. On low-traffic sites "a backup every night" turns into "a backup now and then".

Method 4: Manual Backup with FTP + phpMyAdmin

For those who want full control. It takes two steps:

A. Download the files over FTP

1. Connect to your site with an FTP client such as FileZilla.
2. public_html (or the site's root folder) and download everything inside it.
3. Make sure hidden files are visible — if .htaccess is skipped, your redirects are lost.

B. Export the database with phpMyAdmin

1. Open phpMyAdmin from your hosting panel and select your site's database.
2. Switch to the "Export" tab at the top.
3. Choose Quick as the method and SQL as the format, then download. On large databases prefer the compressed (gzip) option.

Its limit: The method works, but it depends on a human. During a busy week nobody opens FTP. And data loss never happens on a day you planned for. On top of that, a phpMyAdmin export of a large database can hit a browser timeout.

Method 5: Automated External Backup (Recommended)

The three methods above share the same weakness: the backup either sits on the same server, or hits PHP limits, or waits for you to remember. An automated external backup closes all three at once.

With Yedekalma the flow is as follows:

1. You install a single PHP module on your site (a WordPress plugin is also available). The module runs independently of WordPress, so plugin conflicts and the wp-cron problem disappear.
2. The file, database and email (IMAP) backups are taken in chunks — so large sites don't hit timeouts and the job resumes where it left off.
3. The backup is written straight to your storage destination (Google Drive, S3, FTP, your own server). Your backups are never held on our servers.
4. Unchanged files are not sent again (incremental backup), so even an hourly backup stays light.
5. If a backup fails or a schedule is missed you get an alert — there is no silent failure.

6. Comparison: Which Method Suits You?

* Depends on wp-cron; on low-traffic sites the scheduled backup may never fire.

7. How Often Should You Back Up?

The right answer depends on the type of site. A simple rule: the gap between two backups is the amount of time you're willing to lose.

• A corporate brochure site: A weekly backup is usually enough.
• A blog or news site: Daily. Losing a day's content is recoverable.
• WooCommerce or a membership site: Hourly or more often. Every hour lost means orders lost — see e-commerce website backups.
• Before every update: Take a manual backup right before a plugin or theme update — see backing up and staging before an update.

8. Taking the Backup Isn't Enough: Test It

The most dangerous kind of backup is one you believe exists but is actually corrupt. A zero-byte SQL file also looks like a "backup" in the folder. Once a month, do this:

1. Open the backup archive and check that the wp-content and .sql file is a sensible size.
2. Restore the backup to a staging environment and see whether the site comes up.
3. If you don't know the restore steps: how to restore a WordPress site.

For the full picture: the danger of an untested backup and the 3-2-1 backup rule.

Frequently Asked Questions