WordPress & Web Development Basics
How to Backup a WordPress Website Manually Without a Plugin
A plain-English walkthrough for copying your files and database by hand — using nothing but your hosting control panel — so you're never one bad update away from losing everything.
Quick Answer
To back up WordPress manually, you copy two things: your files (through cPanel File Manager or FTP) and your database (through phpMyAdmin's export tool). Compress the files into a ZIP, export the database as a .sql file, then download both to a location outside your hosting account — your computer, an external drive, or a cloud folder. No plugin, no subscription, no third-party server involved.
Why manual backups are worth learning
Somewhere between your first WordPress install and your fiftieth plugin update, something is going to break. Maybe a theme update wipes out a custom function you added six months ago. Maybe a plugin conflict throws a fatal error and your homepage turns into a blank white page. Maybe your host has a hardware failure on the exact week their own backups happen to be corrupted too — it happens more often than hosting companies like to admit.
When that moment arrives, the only thing standing between "minor inconvenience" and "rebuild the site from scratch" is whether you have a recent, complete, working backup sitting somewhere safe. Not a backup you assume exists because you installed a plugin once and forgot about it. An actual file, on an actual drive, that you have personally verified opens and restores correctly.
Learning to do this manually isn't about rejecting backup plugins forever. It's about understanding what's actually happening under the hood, so that when a plugin fails silently — and they do fail silently, more often than the glowing App Store reviews suggest — you're not helpless. You know exactly where your files live, exactly how to export your database, and exactly how to put the pieces back together. That knowledge is worth far more than any single tool.
What a complete WordPress backup actually includes
A lot of beginners assume "backing up WordPress" means downloading a folder of images and calling it done. In reality, a WordPress site is built from two completely separate systems that have to be backed up together, or the backup is useless.
1. The files
This is everything living in your site's root directory, usually called public_html or www. It includes:
- WordPress core files — the engine that runs everything
- wp-content/themes — your active theme and any child theme you're running
- wp-content/plugins — every plugin you've installed
- wp-content/uploads — every image, PDF, and media file you've ever added, organized by year and month
- wp-config.php — the file that connects WordPress to its database
2. The database
This is the part beginners forget, and it's arguably more important than the files. Your database is a MySQL database that stores:
- Every post and page you've ever published, including drafts
- Every comment, and the metadata attached to it
- User accounts, roles, and passwords (hashed, not plain text)
- Your site settings, permalink structure, and widget configuration
- Plugin settings that don't live in files
Here's the part that trips people up: your media files live in the uploads folder, but the records of those files — which post they're attached to, their alt text, their captions — live in the database. Back up only the files, and you'll have a folder of orphaned images with no idea what they belonged to. Back up only the database, and you'll have posts referencing images that no longer exist. You need both, taken at roughly the same time, or the backup doesn't reconstruct a working site.
wp-content/uploads folder is not a backup. It's a partial backup at best. Without the database, you have pictures with no site to put them in.
Method 1: Backing up your files with cPanel File Manager
Most shared and managed WordPress hosts — Bluehost, Hostinger, SiteGround, Namecheap, and dozens of others — run cPanel or a cPanel-style dashboard. If you can log into your hosting account and see an icon labeled "File Manager," this method will work for you.
1Log in and open File Manager
From your hosting dashboard, open File Manager and navigate to public_html (or the subfolder your WordPress install lives in, if you run it from a subdirectory).
2Select everything and compress it
Click the top folder or select all files with Ctrl+A (or Cmd+A on Mac), then look for a Compress option in the toolbar. Choose ZIP Archive as the format. Depending on how many images and plugins you have, this can take anywhere from a few seconds to several minutes — don't close the tab while it's working.
3Download the ZIP file
Once compression finishes, a new .zip file will appear in the same directory. Right-click it and choose Download. Depending on your site's size, this could be anywhere from 50 MB for a small blog to several gigabytes for a media-heavy site — a slow connection may take a while, so let it finish completely before closing your browser.
wp-content/uploads separately from the rest of the files. Your media library is usually the biggest chunk, and splitting it out prevents one giant operation from failing halfway through.Method 2: Exporting your database with phpMyAdmin
Now for the part that actually contains your content. phpMyAdmin is a database management tool that comes bundled with nearly every cPanel hosting account, and it's how you'll export your WordPress database as a .sql file.
1Open phpMyAdmin
From your cPanel dashboard, find and click phpMyAdmin, usually under a "Databases" section. It opens in a new tab showing a list of databases on the left.
2Identify the correct database
If you only have one WordPress site on this hosting account, there's likely only one database to worry about. If you're unsure which one belongs to your site, open wp-config.php in File Manager and look for the line starting with define('DB_NAME', — that's your answer.
3Export the database
Click your database name in the left sidebar, then click the Export tab along the top. Leave the export method set to Quick and the format set to SQL — these defaults are correct for the vast majority of sites. Click Go, and a .sql file will download automatically.
Method 3: Backing up files over FTP/SFTP
If your host doesn't offer cPanel, or if File Manager's compression feature keeps failing on a large site, an FTP client is a reliable fallback. FileZilla is free, works on Windows, Mac, and Linux, and is the tool most developers reach for by default.
1Get your FTP credentials
Your host provides an FTP hostname, username, password, and port (usually 21 for FTP or 22 for the more secure SFTP) in your hosting dashboard, often under "FTP Accounts" or "Connection Info."
2Connect and navigate
Open FileZilla, enter your credentials in the Quickconnect bar, and once connected, navigate the right-hand panel to your public_html folder.
3Download the whole directory
Right-click the folder and choose Download. FileZilla will queue every file and folder inside it and transfer them to a local folder on your computer. This method downloads files individually rather than as one ZIP, so it's slower than the cPanel compress-and-download approach, but it's far less likely to time out on a huge site since it's not trying to compress everything in memory at once.
FTP handles files only — you'll still need to export your database separately through phpMyAdmin, exactly as described in Method 2. The two steps are always paired, regardless of which tool you use for the files.
Manual vs. plugin vs. host-level backups
None of these three approaches is universally "best" — they solve different problems. Here's how they actually compare once you look past the marketing.
The strongest setups, in practice, combine all three: host-level backups as a first line of defense, a plugin for routine automated peace of mind, and a manual backup as the one you trust before doing anything risky — a major theme switch, a PHP version upgrade, or a bulk plugin update.
How to restore a WordPress site from a manual backup
A backup you've never tested restoring isn't really a backup — it's a hope. Here's how the restore process works when you actually need it.
Restoring the files
1Upload the ZIP back to your server
In File Manager, upload your backup ZIP into public_html, then right-click it and choose Extract. This overwrites the current files with your backed-up versions.
2Confirm the file structure
Make sure wp-content, wp-config.php, and the core WordPress folders sit directly inside public_html, not nested inside an extra folder created by the extraction. This is the single most common restore mistake — a "site not found" error is almost always a folder-nesting issue.
Restoring the database
1Open phpMyAdmin and select your database
If you're restoring onto a fresh install, create a new empty database first, then select it.
2Import your .sql file
Click the Import tab, choose your backed-up .sql file, and click Go. phpMyAdmin will rebuild every table from that file.
3Check wp-config.php matches
Your wp-config.php file needs the correct database name, username, password, and host to match the database you just restored into. If you're restoring onto the same server under the same account, this usually needs no changes — but on a new host, you'll need to update these four values.
Where to store your backups (the 3-2-1 rule)
A backup sitting in the same hosting account as your live site protects you from almost nothing. If your host suspends the account, gets hacked, or has a server failure, your "backup" disappears along with everything else. Professionals follow what's known as the 3-2-1 rule:
- 3 copies of your data — the live site plus at least two backups
- 2 different storage types — for example, a local hard drive and a cloud service
- 1 copy stored off-site — physically or geographically separate from your primary location
In practice, for a solo blogger or small business, this usually looks like: one backup downloaded to your computer, and a second copy synced to Google Drive, Dropbox, or a similar cloud folder. Neither of those lives on your hosting server, so a hosting-side disaster can't touch either one.
How often you actually need to back up
There's no single right answer here — it depends entirely on how often your content changes and how painful it would be to lose a week of it.
- Static or rarely-updated sites: A full backup once a month is usually enough.
- Active blogs: A full backup weekly, with a quick database export after publishing anything you'd hate to rewrite.
- E-commerce or membership sites: Database backups daily at minimum, since orders, transactions, and user data change constantly. File backups whenever you install, update, or remove a plugin or theme.
A good rule of thumb: the backup should never be older than you're willing to lose. If losing three days of orders would be a genuine crisis, your database backup schedule needs to be daily, full stop.
Common mistakes that quietly ruin backups
Most backup failures aren't dramatic — they're small oversights that only reveal themselves at the worst possible moment.
- Backing up files but forgetting the database — the single most common mistake, and the one that makes a backup useless when you actually need it.
- Storing the only copy on the same server — defeats the entire purpose if the server itself is the thing that fails.
- Never testing a restore — a corrupted ZIP or a truncated .sql export looks identical to a good one until you try to use it.
- Backing up mid-update — if a plugin update is actively writing to the database while you export it, you can end up with an inconsistent snapshot. Back up before you start changes, not during them.
- Losing track of file size limits — some hosts cap File Manager downloads or phpMyAdmin exports at a certain size, silently truncating large sites. If your exported .sql file looks suspiciously small, check for a size-limit warning before trusting it.
Backing up large media libraries and multisite installs
The steps above work fine for a typical blog, but two situations deserve a slightly different approach: sites with years of accumulated images, and WordPress Multisite networks running several sub-sites from one install.
When your media library is the problem
If wp-content/uploads has grown into tens of thousands of files, compressing it as one ZIP in File Manager can time out or simply stall the browser tab. Rather than fighting that single giant operation, split it by year — most hosts organize uploads into folders like 2024, 2025, and 2026 — and compress and download each year separately. It's a few extra clicks, but each individual archive finishes in a reasonable time instead of one operation failing after twenty minutes of progress.
Backing up a Multisite network
A WordPress Multisite install still lives in one public_html folder and one database, so the file-backup steps don't change. The database, however, is where it gets more involved: instead of one set of content tables, Multisite creates a separate set of tables for every sub-site, all prefixed with a number (wp_2_posts, wp_3_posts, and so on). When you export through phpMyAdmin, use the Quick export with the SQL format as usual — it captures every sub-site's tables in the same file automatically. Just be aware the resulting .sql file will be noticeably larger than a single-site export, so budget extra time for both the export and the eventual restore.
Pre-update backup checklist
Keep this nearby for the next time you're about to touch a theme, a plugin, or a WordPress core update.
Before you click "update"
- Exported the database via phpMyAdmin in the last 24 hours
- Compressed and downloaded the full
public_htmlfolder, or at minimumwp-content - Confirmed both files landed somewhere off the hosting server (local drive or cloud folder)
- Noted your current theme, active plugins, and PHP version somewhere you can reference
- Checked that your last restore test actually worked, not just that a backup file exists
Frequently asked questions
Can I back up WordPress without installing a plugin?
Yes. Every WordPress site is really just two things — a folder of files and a MySQL database. You can copy the files through your host's File Manager or FTP, and export the database through phpMyAdmin. No plugin is required for either step.
What is the difference between backing up files and backing up the database?
Your files include WordPress core, themes, plugins, and uploaded media — the things that make your site look and function a certain way. Your database holds the actual content: posts, pages, comments, user accounts, and settings. You need both, because one without the other is an incomplete backup.
How often should I manually back up my WordPress site?
For a blog that publishes a few times a week, a weekly full backup plus a database-only backup after each new post is a safe rhythm. For an e-commerce or membership site with daily transactions, back up the database daily at minimum, and the files whenever you change a theme, plugin, or code.
Where should I store my WordPress backups?
Never only on the same server as your live site. Follow the 3-2-1 approach: keep at least three copies, on two different types of storage, with one copy stored somewhere physically separate — such as your local computer plus a cloud drive like Google Drive or Dropbox.
Will a manual backup work if my hosting account gets suspended?
Only if you already downloaded the backup to a location outside that hosting account before the suspension happened. A backup that only lives inside cPanel or on the same server becomes unreachable the moment your account access is cut off, so always move a copy off-site.
Is a manual backup as reliable as a backup plugin?
A manual backup can be just as reliable, and sometimes more transparent, because you see exactly what's being copied and where it's going. The trade-off is convenience: plugins automate the schedule, while a manual backup depends on you remembering to run it.
The bottom line
None of this requires special skills — just a willingness to click into cPanel once and see what's actually there. Once you've done a manual backup and a manual restore a single time, the fear of "what if something breaks" mostly disappears. You'll know exactly what your site is made of, exactly where the pieces live, and exactly how to put them back together if you ever need to. That confidence is worth more than any automated tool, because it's the one thing a plugin can never hand you on its own.