A complete WordPress backup covers the database, wp-content, wp-config.php and relevant web-server rules. Success is not merely an archive file; it must extract, import and pass functional tests in a clean environment.
wp db export backup.sql --add-drop-table
tar -czf wordpress-files.tar.gz public_html
sha256sum backup.sql wordpress-files.tar.gz
wp search-replace old.example new.example --dry-runThe database stores posts, users, settings, orders and plugin data; wp-content stores uploads, themes and plugins. wp-config.php contains database credentials, salts and custom constants. Web-server rules, cron jobs, custom PHP settings and external storage configuration should also be preserved when they are part of the deployment.
SQL export protects posts, users, WooCommerce orders, settings and plugin tables.
At minimum archive wp-content, wp-config.php and custom server files. Core can be downloaded again, but full files simplify recovery.
Extract the archive, import SQL and test frontend, admin, forms, cron, email and payment flows.
Creates an SQL export using the WordPress database configuration. For busy WooCommerce sites, plan a brief maintenance window or consistent snapshot.
wp db export ../backup-$(date +%F-%H%M).sql --add-drop-tableExclude cache, temporary files and old backup directories to reduce archive size.
tar --exclude=wp-content/cache --exclude=wp-content/upgrade --exclude="*.log" -czf ../wordpress-$(date +%F-%H%M).tar.gz .Confirm that SQL is non-empty, the tar archive is readable and hashes remain unchanged after transfer.
test -s ../backup.sql
tar -tzf ../wordpress.tar.gz >/dev/null
sha256sum ../backup.sql ../wordpress.tar.gzUse WP-CLI search-replace instead of raw SQL replacement to preserve serialized data.
wp search-replace "https://old.example" "https://new.example" --all-tables-with-prefix --precise --dry-runRecord free disk space, WordPress version, database size, PHP version and active plugins before backup.
Export the database via WP-CLI, mysqldump, cPanel phpMyAdmin or Plesk and verify that the SQL file is not empty.
Archive WordPress files; do not leave backup archives inside public_html and move them outside web access.
Generate SHA-256 hashes, transfer files to another server or object storage and compare hashes after transfer.
For restore, prepare an empty database and clean document root, extract files, import SQL and verify wp-config.php connectivity.
If the domain changed, run WP-CLI search-replace in dry-run mode first, then apply it and refresh caches, rewrite rules and permalinks.
Test frontend, wp-admin, media, login, forms, cron, email, payments and backups, then document the recovery.
wp-config.php credentials, DB_HOST or MySQL grants do not match the restored environment.
wp-content/uploads is missing, extracted to the wrong path or has incorrect ownership.
home/siteurl, plugin settings or serialized content still contain the old URL.
Interrupted transfer, full disk or a lost connection may have truncated the SQL dump.
No. wp-content stores files, while posts, users, orders and settings live in the database. Back up both.
Base frequency on change rate. Busy stores may need frequent database backups; static business sites may use daily or weekly backups. Define an RPO.
A plugin can be used, but backups should be off-site, protected, regularly restore-tested and complemented by a method that works when WordPress is unavailable.
Raw replacement can corrupt serialized values. Use WP-CLI search-replace or a serialization-aware tool.
File size and archive tests are not enough. The strongest proof is a successful restore and functional test in a clean environment.
Contact Eka Software and Information Systems for installation, server, script and technical support services.