Troubleshooting guide: how to back up a WordPress site

Troubleshooting guide: how to back up a WordPress site

Backing up a WordPress site is routine, but when backups fail it becomes urgent to diagnose the cause rather than merely retrying the same process. This guide focuses on troubleshooting common backup failures and verifying that backups are complete and restorable so that you can recover quickly after corruption, accidental deletion or a failed update.

Start with quick checks that reveal the simplest causes of backup failure. Confirm there is enough disk space on the server or in your chosen cloud storage. Inspect plugin notifications and the WordPress site health screen for errors. Review server error logs and any backup plugin logs for timeouts, permission denied messages or failed database exports. Verify scheduled tasks are running if you rely on automated backups and make sure your hosting provider has not paused cron jobs or imposed execution limits.

Verifying a backup is as important as creating it. Open the archive produced by your backup tool and ensure it contains a database dump plus the wp-content directory with active themes and uploads. Check file sizes and timestamps for recent changes. For database dumps, search for table CREATE statements and confirm the dump ends normally, which indicates completion. If a backup archive is corrupted, try creating a new export and compare checksums to spot intermittent storage issues.

Common causes of incomplete or corrupt backups include plugin conflicts, insufficient PHP memory, file permission problems and unreliable FTP or SFTP transfers. To address these: temporarily disable non-essential plugins and retest the backup; increase PHP memory_limit and max_execution_time in php.ini or via your host panel; set correct file permissions such as 755 for folders and 644 for files on Linux servers; and use SFTP rather than plain FTP to avoid interrupted transfers. If database exports repeatedly fail, check for corrupt tables and repair them using wp‑admin tools, phpMyAdmin or WP‑CLI.

Manual backup can both restore confidence and serve as a workaround while debugging automated tools. Export the database using phpMyAdmin, WP‑CLI or the hosting control panel and save the SQL file locally. Copy the wp-content folder and the root files such as wp-config.php and .htaccess via SFTP or the file manager. If your site is large, consider backing up uploads and plugins separately to narrow down the part that triggers failures. The essential items to include in a manual backup are listed here.

• Database dump containing all WordPress tables.
• The wp-content directory including uploads, themes and plugins.
• wp-config.php and any customised root files such as .htaccess.
• Any mu-plugins or custom cron scripts stored outside wp-content.

Restoring a backup is the best proof it is valid, so perform a test restore to a staging environment before you need a recovery. Import the SQL file into a fresh database and upload the files to a staging site, then update wp-config.php with the new database details and check the site loads correctly. Verify logins, media files and permalinks, and regenerate thumbnails if needed. If the restore fails, the error output will guide you to missing files, database errors or mismatched URLs that need addressing.

To reduce future troubleshooting, adopt defensive practices: keep two independent backup methods such as a plugin plus manual exports, store copies off-site with versioned retention, and set up notifications for backup failures. Test restores monthly and keep a short checklist for emergency recovery operations. For other troubleshooting and practical how-to articles in this series visit the Build & Automate How-To Guide label to build a consistent routine for site maintenance and backups. For more builds and experiments, visit my main RC projects page.