How to back up a WordPress site

A recoverable WordPress backup is the rollback point before plugin upgrades, theme deployments, host moves, or incident response. A partial copy that saves only files or only the database cannot reliably recreate the site when posts, uploads, plugins, and configuration need to return to the same moment.

WordPress stores dynamic content in MySQL or MariaDB and keeps application state in the directory tree that contains wp-config.php, wp-content, hidden files, and any custom drop-ins. WP-CLI can export the active database without pasting credentials into the shell, while a compressed archive preserves the matching file tree from the same snapshot window.

Examples assume shell access on the host, a working wp command, and enough free space outside the public document root to hold both artifacts at once. WP-CLI relies on the host mysqldump client for wp db export, so install the current MySQL or MariaDB client package first when that binary is missing. On busy sites, a short maintenance window keeps comments, orders, or edits from landing between the database dump and the file archive.

1. Open a terminal session in the live WordPress document root.

   $ cd /var/www/html

   Run the remaining wp commands from the directory that contains the active wp-config.php file.

   Related: How to install WP-CLI on Ubuntu or Debian
   Related: How to install WP-CLI on CentOS, Fedora, or Red Hat

2. Create a timestamped backup directory outside the web root and keep the shell session open so later steps can reuse the same BACKUP_DIR variable.

   $ BACKUP_DIR=~/backups/wordpress/manual-$(date +%F-%H%M%S)
   $ mkdir -p "$BACKUP_DIR"
   $ printf '%s\n' "$BACKUP_DIR"
   /home/user/backups/wordpress/manual-2026-03-29-120500

   Do not store backup archives under the public document root. A web-accessible backup directory turns a recovery asset into a data leak.

3. Enable maintenance mode before the final snapshot when the site is still receiving writes.

   $ wp maintenance-mode activate
   Enabling Maintenance mode...
   Success: Activated Maintenance mode.
   $ wp maintenance-mode status
   Maintenance mode is active.

   Keep maintenance mode active until both backup artifacts are complete. On a read-only staging copy or a site already in a controlled maintenance window, this step can be skipped.

4. Export the live database into the backup directory.

   $ wp db export "$BACKUP_DIR/site.sql"
   Success: Exported to '/home/user/backups/wordpress/manual-2026-03-29-120500/site.sql'.

   The command reads the active database settings from wp-config.php instead of exposing credentials in shell history.

   If the command fails with an error such as env: 'mysqldump': No such file or directory, install the current host MySQL or MariaDB client package first so WP-CLI can call mysqldump.

5. Create a compressed archive of the current document root while excluding the temporary maintenance marker file.

   $ tar -czf "$BACKUP_DIR/site-files.tar.gz" --exclude='.maintenance' -C /var/www/html .

   Archiving from the document root captures wp-config.php, hidden files, plugins, themes, uploads, and custom server-side files in one bundle.

   If uploads or generated assets live on a mounted path outside the document root, back up that separate storage location in the same maintenance window.

6. Check the archive for recovery-critical paths before copying it elsewhere.

   $ tar -tzf "$BACKUP_DIR/site-files.tar.gz" | grep -E '^\./wp-config\.php$|^\./wp-content/(plugins|themes|uploads)/' | sed -n '1,8p'
   ./wp-config.php
   ./wp-content/plugins/
   ./wp-content/plugins/google-site-kit/
   ./wp-content/themes/

   Adjust the pattern for the directories that matter on that site. The goal is to prove that the archive contains the live configuration file and the relevant wp-content trees before the backup leaves the host.

7. Record checksums for the SQL dump and file archive.

   $ shasum -a 256 "$BACKUP_DIR/site.sql" "$BACKUP_DIR/site-files.tar.gz"
   6d0d25ed1a2c0c9d46f22cc904e72cbe145fb26d22d74468c6014eef6672979a  /home/user/backups/wordpress/manual-2026-03-29-120500/site.sql
   d2513ba1e1f8511f74b1c767366b2faa44d96a43ba150876b46c291cc3ef8eea  /home/user/backups/wordpress/manual-2026-03-29-120500/site-files.tar.gz

   Checksums make it obvious when a later transfer, sync, or object-storage upload produced a truncated file.

8. Disable maintenance mode after both backup artifacts are complete.

   $ wp maintenance-mode deactivate
   Disabling Maintenance mode...
   Success: Deactivated Maintenance mode.
   $ wp maintenance-mode status
   Maintenance mode is not active.

   If either artifact failed or produced an empty file, fix the failure and re-run the snapshot before reopening the live site.

9. Confirm that both backup artifacts exist, then copy the backup directory to off-host storage.

   $ find "$BACKUP_DIR" -maxdepth 1 -type f -print
   /home/user/backups/wordpress/manual-2026-03-29-120500/site-files.tar.gz
   /home/user/backups/wordpress/manual-2026-03-29-120500/site.sql

   Keep several recent copies and store at least one of them off-host. A backup that lives only on the same server does not help after storage failure, ransomware, or full-host loss.

   Related: How to restore a WordPress site