// BACKUP & RESTORE
WordPress backups that can actually be restored
Most WordPress backups are never tested. A backup nobody has restored is a guess dressed up as a safety net, and you find out which one you have on the worst possible day. Here is what to back up, how often, where copies belong, and how a restore really goes.
// WHAT GETS BACKED UP
What a complete WordPress backup actually includes
Two halves: the files and the database. WordPress builds every page live out of MySQL, so your content is not sitting in files waiting to be copied.
The database
Every post, page, product, order and setting lives in the MySQL database, not in a file you can see over FTP. Lose it and the site is gone, even with every file intact.
The files
WordPress core, your theme, every plugin, and the uploads folder of images and PDFs. Files are the easy half, and the half people mistake for a whole backup.
The configuration
wp-config.php holds the database credentials and security keys, .htaccess holds your permalink rules. Small files, but restoring without them means a blank page or a 404 on every URL.
A files-only backup is close to worthless here. Restore one and you get WordPress, a theme and your images, with no posts, pages, menus, settings or orders.
// FREQUENCY
How often to back up, tied to how often the site changes
Back up as often as you would hate to redo the work. A brochure site that changes quarterly and a store taking orders daily do not need the same schedule. The test is what the gap between two backups costs you.
// WHERE THEY LIVE
Where WordPress backups should be stored
Somewhere other than the server running the website. A backup on the same hosting account shares every risk the site has: if the server dies, the account is suspended, or an attacker gets write access, the site and the backup go together.
The rule is 3-2-1: three copies, on two kinds of storage, with at least one off-site. In practice that means the live site, an automated backup pushed to cloud storage such as Google Drive, Dropbox or Amazon S3, and whatever your host keeps.
The off-site copy is the one that matters. It survives your host having a very bad week, and an attacker who owns your hosting account cannot quietly delete it. Preventing the break-in itself is WordPress security, a separate job.
// PLUGINS VS HOST
Automated backup plugins versus your host's backups
Run both, and rely on the plugin. A dedicated plugin gives you control over schedule, retention and destination. UpdraftPlus, BlogVault and Jetpack VaultPress are all commonly used and all cover files plus database with off-site storage. Some security plugins bundle backups too. Check yours actually sends the database off the server.
- Host backups usually sit on the same infrastructure as your site, so a server failure or suspension takes both at once.
- Retention is often a rolling few days, and the host sets it, not you.
- Restores are frequently whole-account, so you cannot pull back one broken page without rolling everything else back.
- Few hosts guarantee a backup is clean or restorable, and a restore may be a support ticket, not a button.
// THE HALF EVERYONE SKIPS
The WordPress restore process, step by step
Restoring is the part that decides whether the backups were worth anything. Most plugins automate the middle of this list. None automate the checking, which is exactly where restores fail.
-
Back up the broken site first
Copy the current state before you overwrite anything. If the restore fails, you want a way back.
-
Restore into staging, not over live
Push it into staging or a local copy first, so a bad backup cannot make things worse.
-
Put the files back
Upload core, themes, plugins and uploads. After a compromise, take core and plugins fresh from source.
-
Import the database
Drop the existing tables and import the SQL file. This is what brings content, settings and orders back.
-
Reconnect wp-config.php and the URLs
Match the database credentials to the environment you are restoring into, and correct the site and home URLs.
-
Test what customers touch
Load pages, re-save permalinks, check images, submit the form, run a test order. Homepages lie.
-
Go live, then clear every cache
Flush the WordPress cache, the host cache and the CDN. Failed-restore reports are often a cached page.
Now do it once while nothing is wrong. A test restore into staging is the only way to find that the export has been silently truncated for six months. Twice a year, under an hour, and the guess becomes a safety net.
// RETENTION
How long to keep WordPress backups
Thirty days is the floor, ninety is better, and a monthly copy kept for a year costs almost nothing in cloud storage. Retention is where a lot of otherwise sensible setups quietly fail.
Malware on a WordPress site is rarely dramatic. Injected code often sits quiet for weeks, redirecting mobile visitors, adding hidden spam links or skimming form data, until Google flags the domain. By then the infection is older than your backups.
On a rolling seven-day window, every copy you hold is already infected and restoring just reinstalls the problem. Ninety days plus monthly archives gives you something from before the compromise. Past that, you need WordPress malware removal, not a restore.
// WHERE THIS FITS
Backups are one part of keeping a WordPress site alive
Backups are the recovery layer. They stop nothing getting in, so pair them with WordPress security hardening, and know what a cleanup involves on WordPress malware removal. For the whole ongoing burden, read what WordPress maintenance costs, or get website maintenance in Darwin from a local team, scoped and quoted as one number. Our own hand-coded websites have no plugin stack or database to back up.
// QUESTIONS
Straight answers on backups and restores
Not sure whether your current backups would actually bring the site back? Ask us and we'll tell you straight, no jargon, no pressure.
Get in touchWhat should a WordPress backup include?
Both files and database. Files cover core, your theme, plugins and the uploads folder. The database holds every post, page, setting, user, form entry and order. A files-only backup restores an empty shell, which is why having backups and being able to restore are different claims.
How often should I back up my WordPress site?
Match it to how often the site changes. A brochure site is fine monthly, an active blog weekly, a site storing form submissions daily. A store taking orders needs real-time or hourly database backups. Always take one before an update.
How do I restore a WordPress site from a backup?
Back up the broken site, restore into staging rather than over live, upload the files, import the database, fix the wp-config.php credentials and site URLs, test pages, forms and checkout, then clear every cache. Plugins automate the middle. None automate the testing.
How long should I keep WordPress backups?
Longer than you think. Thirty days is the floor, ninety is better, and keep a monthly copy for a year. Malware often sits undetected for weeks, so a seven-day window can mean every backup you hold is already infected.
What are the best WordPress backup plugins?
There is no single right answer, and anyone who gives you one is usually an affiliate. UpdraftPlus, BlogVault and Jetpack VaultPress are all widely used and all cover files plus database with off-site storage. What matters more is whether anyone has test-restored it.
Does Web Blend handle backups for a WordPress site you did not build?
Yes. Updates, backups, security patching and monitoring are real ongoing work on WordPress, and we do it on a monthly maintenance plan from $170 a month, on sites we did not build as well as our own. We scope what the site needs first and confirm the monthly number before anything starts, and backups get test-restored rather than just scheduled.
// READY WHEN YOU ARE
Find out if your backups would actually work
We'll check what is running, whether it covers the database, where the copies are stored and how far back they go. Then one clear number to fix what is missing.
Talk to us