A manual WordPress backup needs both the website files and the correct database. Together they preserve the application, uploaded media, settings and content needed to reconstruct the site. Keep the backup outside the publicly served website and test that it can be restored.
IN THIS ARTICLE
01 Identify the components
Confirm the domain's document root and inspect the active configuration to identify the database and table prefix. Include WordPress files, plugins, themes, uploads, configuration and relevant hidden server files. Record external dependencies such as offloaded media, a CDN or an external search service, because a local backup may not contain their data.
02 Create a coordinated backup
- Choose a quiet period. For a store or membership site, arrange a controlled write pause or a supported consistent snapshot so files and database describe the same point in time.
- Export the identified database using your hosting backup tool, phpMyAdmin or an authorised WP-CLI database export.
- Archive or copy the complete website directory, including required hidden files. Avoid following unrelated account directories unintentionally.
- Store the SQL export and file archive in private storage with a clear date, site name and matching backup identifier.
- Download or copy the backup to an independent secure location and record its retention period.
03 Example: export the database to a private location with WP-CLI
If your service supports WP-CLI, first verify the WordPress installation and create or choose a writable backup directory outside every public website root with access restricted to the authorised account. Replace both paths below with those verified locations and choose a new, unused filename:
wp --path=/path/to/wordpress db export /private/backup-directory/site-before-change.sqlThe command reads the database connection from the selected WordPress configuration. Do not add the database password to the command line. By default it exports all tables in that database, which can include other installations sharing the same database; confirm that scope and your authority before proceeding.
Wait for successful completion and confirm the output file exists and is non-empty without publishing its contents. This is the database portion only. Capture the matching website files under the coordinated backup plan above, copy the pair to independent protected storage and test restoration.
Where should the SQL file be stored?
Use a private directory outside the web document root or a protected backup service. A guessable SQL or ZIP file placed beside your homepage can expose passwords hashes, personal data and configuration secrets. Do not put database credentials into shared command histories or paste the backup into a support conversation.
Does copying wp-content cover everything?
It preserves important custom files and uploads, but it does not include the database or necessarily all configuration. A recovery procedure may reinstall clean WordPress core separately, but that must be an explicit plan with the required versions and configuration recorded. A media-only copy cannot recover posts and settings stored in the database.
04 Verify before making risky changes
Check that archives open, the SQL export is non-empty and the expected directories exist. Restore the pair into an isolated test environment and test representative pages and login. For large sites, confirm there was enough temporary disk space and that the export completed without truncation. Keep the original backup unchanged while testing recovery.