How to back up a WordPress website

A full WordPress backup has two parts: the database and the website files. The database contains content, users, comments, and settings; the files contain WordPress, themes, plugins, uploads, configuration, and other site assets. Saving only one part will not give you a complete restore.

Back up before WordPress, theme, or plugin updates, before installing major changes, and before moving the site. Set the frequency according to how often your content changes. A busy shop may need daily backups, while a rarely updated brochure site may need less frequent copies.

Open phpMyAdmin from your hosting control panel and select the database used by WordPress. If you are unsure which database it is, check the DB_NAME value in wp-config.php. Export all tables and save the resulting SQL, compressed SQL, or equivalent export file with a date in its name.

This manual method is reliable, but it is easy to select the wrong database or forget that the export does not include themes, plugins, or media files. WordPress recommends regular database backups and specifically warns that a database backup alone is not a full-site backup.

Connect to the server with SFTP rather than ordinary FTP where possible. Download the complete WordPress directory, including wp-content, wp-config.php, and hidden files such as .htaccess when present. The wp-content directory is especially important because it normally contains your uploads, plugins, and themes.

Keep the files from roughly the same time as the database export and place them in one dated backup folder. The drawback is time and storage: large media libraries can make manual downloads slow, and an interrupted transfer may leave you with an incomplete copy.

Keep at least three to five recent backup sets and store copies in different locations, such as your computer, separate cloud storage, and a host or server location. Do not keep the only copy on the same server as the live website; a server failure or compromised account could affect both.

• Check that the database export opens or has a sensible file size.
• Check that the downloaded archive contains wp-content and your configuration file.
• Record the backup date, WordPress version, and any special server settings.

A backup that has never been restored is an assumption, not a recovery plan.

For a manual restore, restore the website files first and then import the database. If the database name, username, password, or host changes, update the matching connection details in wp-config.php. Restore the matching database and files together rather than mixing dates unless you understand the consequences.

Test a restore on staging when possible. Common failures include insufficient disk space, server upload limits, incorrect file permissions, incomplete uploads, stale caches, and restoring only the database. If a restore stops halfway, the live site can be left in a broken state, so take a fresh backup before attempting a second repair.

For most site owners, the faster route is a backup plugin that can capture the database and files on a schedule, send copies to separate cloud storage, and provide a guided restore. Configure the schedule to match how often the site changes, enable encryption if available, and keep notifications turned on so a failed backup does not go unnoticed.

Backuply Pro fits this route with scheduled backups, cloud storage, encryption, logs, and one-click restores. Install it from the WordPress dashboard under Plugins, activate it, choose what to back up, connect your storage, and run an on-demand backup before relying on the schedule. Manual backups are still useful as an independent fallback.