Low-angle photo of an old oak card-catalogue cabinet in a dim archive room, one drawer pulled out with blank cards in place under warm lamp light, for backing up and restoring a WordPress site.

هذا المقال متوفر باللغة العربية — اقرأ بالعربية

Most site owners think about backups on the worst day of the year: the day the site is hacked, an update breaks the checkout, or the hosting account is suspended. A good WordPress backup and restore plan turns that day into a short, boring job instead of a crisis. This guide explains what a complete backup contains, how often to take one, where to keep it, and, just as important, how to restore it and prove that it works.

The advice here follows the official WordPress documentation and the WP-CLI command reference, with notes from real client work in Egypt, Saudi Arabia and the Gulf, where shared hosting, bilingual sites and busy WooCommerce stores are common.

Why a backup you never tested is only a hope

A backup has one job: to bring your site back. Many owners discover during an emergency that their “backup” was only the files, or only the database, or a zip that stopped updating six months ago. The WordPress documentation is direct about this. It recommends backing up the database regularly and always before an upgrade, and it suggests that even when backups are automated, you should take a manual backup once in a while to make sure the automatic process is actually working.

Things that can take a site down, in our experience, include:

  • A plugin or theme update that conflicts with another plugin.
  • Malware or an attacker who gains admin access.
  • A hosting problem, a disk failure, or an unpaid hosting invoice.
  • Human error: deleting the wrong page, product or user, or running a bulk edit by mistake.
  • A failed migration to a new host or a new domain.

Only some of these are under your control. A tested backup covers all of them.

What a complete WordPress backup includes

The official documentation splits a WordPress site into two parts, and you need both to restore a typical site: the files and the database. Backing up one does not back up the other.

The files

The files live in your WordPress directory on the server: WordPress core, themes, plugins, uploads, wp-config.php and .htaccess. The documentation points out that the wp-content folder holds your own content (themes, plugins and uploaded media), so it deserves the most attention, together with wp-config.php, which holds your database connection details. Core files can be replaced with a fresh download from wordpress.org, so they matter less.

The database

The database is stored in a separate system, usually MySQL or MariaDB, outside the WordPress folder. It contains your posts, pages, comments, settings, users and, on a WooCommerce store, your orders and customers. Downloading the WordPress folder does not copy it. To back it up you create an export (a dump), usually a .sql, .gz or .bz2 file.

Part What it holds How to copy it
wp-content Themes, plugins, media uploads Plugin, host panel, SFTP or rsync
wp-config.php Database details, keys, settings Download with SFTP, store privately
.htaccess Rewrite rules, redirects Download with SFTP
Database Content, users, orders, settings Export with phpMyAdmin, WP-CLI or a plugin

The documentation also suggests treating the files and the database as one “backup set” taken around the same time, and even keeping the database export inside the same zip as the files so the two always match.

How often should you back up?

The official guidance is simple: smaller sites with few posts can be backed up weekly, while busy sites with lots of activity should be backed up daily. We would add one practical rule for MENA businesses: let the frequency follow the value of the data, not the size of the site.

  • Brochure or company site that changes a few times a month: weekly is usually fine, plus a manual backup before every update.
  • Blog or news site publishing every day: daily database backups, weekly full backups.
  • WooCommerce store: daily at minimum. If you take many orders a day, ask your host or backup service about more frequent database backups, because every order placed after the last backup is lost if you restore an old copy.
  • Before any risky change (major update, new theme, migration, bulk import): always take a fresh manual backup, whatever your schedule says.

Where to keep your backups: the 3-2-1 rule

A backup that sits only on the same server as the site disappears with the site. The WordPress documentation recommends keeping at least three to five recent backups, stored in different places, for example one on the hosting server, one in cloud storage such as Google Drive or Dropbox, and one downloaded to your own computer.

This matches the well known 3-2-1 rule published by the US Cybersecurity and Infrastructure Security Agency (CISA):

  • 3 copies of important data: the original and two backups.
  • 2 different types of storage, so one problem cannot hit both.
  • 1 copy kept offsite, away from your main location.

For a WordPress site, a practical version looks like this: the host’s own daily backups, a plugin sending copies to a cloud storage account that is not linked to your hosting login, and a monthly copy downloaded to an encrypted drive in the office. If the hosting account is compromised or closed, you still have two copies the attacker or the host cannot reach.

One warning: a backup file contains wp-config.php and your full database, including user emails and, on a store, customer addresses and order history. Treat backup storage as sensitive. Use strong passwords and two-factor authentication on the cloud account, and never put backup zips in a public folder on the web server.

Four ways to back up a WordPress site

1. Your hosting control panel

Most hosts provide backup tools, and many run their own daily backups. They are convenient and often include one-click restore. Check three things with your host: how many days of backups they keep, whether the backups are stored on a different server, and whether restoring costs extra. Do not rely on host backups alone, since they share the same account and the same company as your site. The official database guide also notes that in cPanel, a “full backup” is meant for archiving and cannot be restored through cPanel. For the database, use the separate MySQL database download instead.

2. A backup plugin

Plugins are the easiest option for most owners because they schedule backups and send them offsite automatically. Popular choices in the WordPress.org plugin directory include UpdraftPlus (4,000,000+ active installations at the time of writing), All-in-One WP Migration and Backup (5,000,000+), and Duplicator (1,000,000+). Features differ between free and paid versions, especially for remote storage, scheduling and large sites, so read each plugin page and test before you rely on it. Whichever you choose:

  • Send backups to remote storage, not only to the server.
  • Set a retention count so old backups are rotated and storage does not fill up.
  • Turn on email reports so you notice when a backup fails.
  • Keep the plugin updated like any other plugin.

3. phpMyAdmin and SFTP (manual)

The manual method is useful when you have no plugin access or the dashboard is down. In phpMyAdmin, select the WordPress database, open the Export tab, choose the Quick method and SQL format, and save the file. The documentation notes that phpMyAdmin can struggle with large databases, which is where command line tools help. Then download wp-content, wp-config.php and .htaccess over SFTP. Prefer SFTP to plain FTP, since plain FTP sends your password unencrypted.

4. WP-CLI (for developers and VPS owners)

If you have SSH access, WP-CLI is the fastest and most reliable way. The wp db export command runs mysqldump using the credentials in wp-config.php, so you do not need to type the database password:

cd /var/www/example.com
wp db export backups/db-$(date +%F).sql
tar -czf backups/files-$(date +%F).tar.gz wp-content wp-config.php .htaccess

Keep the backups folder outside the public web root in a real setup, or move the files off the server straight away. With a cron job and a tool that copies the archives to remote storage, this becomes a dependable automated backup.

WordPress backup and restore: the restore steps

Restoring is where most plans fail, so it is worth learning before you need it. The official documentation gives a clear order: back up the database first and the files second, and when restoring, restore the files first and then import the database.

Restoring with a plugin

  1. Install WordPress (or use the existing install if the dashboard still works).
  2. Install the same backup plugin and connect it to the remote storage that holds your backups.
  3. Pick the backup set from a date before the problem started.
  4. Restore files and database together, then log in again.
  5. Go to Settings, then Permalinks, and click Save to refresh rewrite rules.

Restoring manually

  1. Upload the backed up wp-content, wp-config.php and .htaccess to the server, replacing the damaged files.
  2. Create an empty database if needed, then import the SQL file with phpMyAdmin (Import tab) or with wp db import.
  3. If the database name, user or password changed, update them in wp-config.php.
  4. Test the home page, a few inner pages, the login, forms and, on a store, the cart and checkout.
wp db import backups/db-2026-10-10.sql
wp search-replace 'https://old.example.com' 'https://example.com' --dry-run

The second command matters when you restore to a different domain or move from a staging copy. WordPress stores some data in serialized form, and wp search-replace handles serialized values safely. Run it with --dry-run first to see what will change, then run it again without that flag.

After a hack, restore carefully

If you are restoring because of malware, do not just roll back and walk away. The backup may already contain the infection, and the hole the attacker used is still open. Pick a backup from before the first sign of trouble, update WordPress, themes and plugins straight after restoring, remove anything you do not use, and change every password: WordPress admins, hosting, database, SFTP and email. Our guide to locking down the WordPress login page covers the next steps for keeping attackers out.

Test your backups with a restore drill

A restore drill is the only way to know your backup works. Once a quarter, or after changing your backup setup, restore a recent backup to a staging site or a local install and check it. It takes an hour and it can save a business.

  • Does the backup open and extract without errors?
  • Are recent posts, products and orders there?
  • Do images load, including those uploaded this month?
  • Do both language versions work, with the language switcher pointing to the right pages?
  • Can you log in, and do forms and checkout behave normally on staging (with payments in test mode)?
  • How long did the whole restore take? Write it down, because that is your real recovery time.

Add the drill to your monthly and quarterly site maintenance routine so it does not depend on memory.

Notes for MENA site owners

Bilingual sites with WPML or Polylang

Translation plugins keep their data in database tables and options, so a database backup covers the translation links between your Arabic and English pages. Problems come from partial restores: restoring only some tables, or restoring the database without the matching wp-content, can break translation links or leave media without its translated copy. Restore the full backup set together.

WooCommerce stores and the order gap

When you restore a store to yesterday’s backup, today’s orders vanish from the database even though the customers paid. Before restoring a live store, export recent orders (WooCommerce, then Orders, or a CSV from your payment gateway dashboard), and put the store in maintenance mode during the restore so no new orders are lost halfway.

Shared hosting limits

Many affordable hosts in the region limit disk space, PHP execution time or file count. Large backups can time out or fill the account. Exclude cache folders and old backup files from your backups, keep only the copies you need on the server, and send the rest offsite.

A backup checklist you can copy

Task How often Done by
Automatic database backup Daily (stores and busy sites) Plugin or host
Automatic full backup Weekly Plugin or host
Manual backup before updates Every update Site owner or developer
Offsite copy check Monthly Site owner
Restore drill on staging Quarterly Developer

If you would rather not manage this yourself, backups, updates and restore drills are part of our SiteCare plans for WordPress sites.

Frequently asked questions

Are my host’s backups enough?

They are a good first layer, but not enough on their own. They live with the same company and often the same account as your site. Keep at least one copy in storage the host does not control.

Does a database backup include my images?

No. Images and other media are files in wp-content/uploads. The database only stores information about them. You need a file backup for the actual images.

How many backups should I keep?

The WordPress documentation suggests at least three to five recent backups in different locations. For stores, keep a few daily copies and a few weekly ones so you can go back far enough if a problem is noticed late.

Can I use a backup to move my site to a new host?

Yes. Restore the files and database on the new host, update wp-config.php with the new database details, and if the domain changes, run a search and replace that handles serialized data, such as wp search-replace. The official migration guide explains the full process.

Final thoughts

A backup plan is not complicated: two parts (files and database), three copies in different places, a schedule that matches how valuable your data is, and a restore drill to prove it works. Set it up once, check it every month, and the next time something goes wrong, you will be looking at a short restore instead of a rebuild.

References