GUIDE ALL

Why WP Multitool Says Your Backups Are in a Public Folder

The warning means WP Multitool could not store backups above your website root, so it put them in wp-content/uploads, which is a public folder. Whether they can be downloaded depends on your server. Apache honours the protection files the plugin writes. nginx ignores them. Since 1.9.8 the plugin tests each such backup by requesting its address, and deletes it if the server serves it. To check your own site, open the backup's address in a private browser window (step 3). To fix it, ask your host for a folder above the site root (step 4).

What the Warning Means

When WP Multitool takes a backup - a database dump before a cleanup, or a copy of wp-config.php before an edit - it tries to put the file in a folder the web server does not publish. That is the first directory above WordPress that PHP can write to and that isn't itself a web root (it looks up to three levels up). If WordPress sits in a subfolder of the docroot, for example public_html/wp/, it skips public_html and goes higher. The folder is called wpmultitool-backups, with a subfolder for your site. A dump is a copy of your users table, password hashes included, and the web server has no business handing that to anyone who asks for it. To do that, PHP needs permission to create that folder in a directory above your site. On a VPS or a decent managed host it usually has that permission, and you never see this warning. On a lot of shared hosting it doesn't. The directory above your site belongs to root or to the hosting panel, and PHP can't write there. When that happens WP Multitool still takes the backup. Running a cleanup with no backup at all would be worse. It falls back to wp-content/uploads/wpmultitool-backups/ and it tells you, which is the warning that brought you here. That fallback is no longer a silent gamble. Since 1.9.8, every backup that lands inside the web root is tested. WP Multitool writes protection files into the folder (.htaccess for Apache 2.2 and 2.4, web.config for IIS, plus empty index.php and index.html files, re-created on every backup if they go missing). Then it requests the backup's own address, following redirects that stay on your own host. If the server answers with anything other than 401, 403 or 404, the file is served to the public, so WP Multitool deletes it and cancels the cleanup. If the check cannot run at all, for example because a firewall blocks the site from calling itself, it tells you in an admin notice instead of leaving a file it could not vouch for. Before 1.9.8 none of this happened: the fallback wrote the file and relied on .htaccess alone.

Step by Step

  1. Read the path in the warning

    The notice names the exact folder it's using. If it starts with your site's own directory and contains wp-content/uploads, the backups are inside the public part of your site. If it sits above that, there's nothing to fix and you shouldn't be seeing the warning at all.

  2. Find out whether your host runs nginx or Apache

    This decides how exposed you actually are. WP Multitool drops a .htaccess file that denies all access (written for both Apache 2.2 and 2.4) into the backup folder, plus a web.config for IIS. Apache honours .htaccess and blocks the download. nginx ignores both files entirely, so on nginx those guards do nothing. You can ask your host, or run curl -I https://yoursite.com and look at the Server header. Plenty of hosts run nginx in front of Apache, so if you get nginx there, ask support which one actually serves your files. On 1.9.8 or later you don't have to work this out to be safe: the plugin runs the download test itself after each backup. Knowing your server still helps you read the result if a backup is refused.

  3. Test it yourself, don't take my word for it

    Take a backup from WP Multitool > Database Optimizer, then find the file. Its name starts with backup- and ends in .sql, and it sits in the folder the warning names. Open the file's address in a private browser window, for example https://yoursite.com/wp-content/uploads/wpmultitool-backups/YOUR-SITE-FOLDER/THAT-FILENAME.sql.

    If your browser downloads it or shows SQL, the file is public. If you get a 403 or 404, the guard is working on your host.

    On 1.9.8 or later, if the file was public, the plugin already deleted it and the cleanup failed with an error or an admin notice, so a missing file is the sign to look for. On an older version, or for a file that is already there, this is the only answer that counts, because it shows what the web server actually does.

  4. Ask your host for a folder above the site root

    This is the fix that usually works, and it costs the host about a minute. Ask them to create a directory called wpmultitool-backups in the directory directly above your WordPress root (if WordPress lives in public_html/wp, above public_html), and to make it owned and writable by the user PHP runs as. On cPanel or DirectAdmin that's normally one level up from public_html. Once it exists, WP Multitool finds it on its own, moves anything already sitting in uploads, and the warning goes away. You don't have to change a setting. A folder that is itself a web root is never used, so don't point it at public_html.

  5. Delete what's already there once you've moved

    WP Multitool moves its own backups for you, and since 1.9.8 it also deletes its own old ones (see the FAQ on retention). If you've been taking them for a while, or you've used other plugins that write into uploads, look through wp-content/uploads for anything ending in .sql, .bak, .old or .zip and get rid of what you don't need. Those extensions aren't PHP, so the server hands them over as plain text. WP Multitool only manages its own backup folder, so anything another plugin left behind is yours to clean up.

  6. If the host says no

    Some shared hosts won't do it, and a few can't. In that case, on Apache the protection files keep the backups from being downloaded, and on nginx the plugin will delete a backup it finds public, so cleanups will fail there until a private folder exists. Moving to a host that gives PHP a private folder is a bigger job than a support ticket, so plan it on your own schedule.

  7. Or send it to me

    If you'd rather not deal with any of it, email support@wpmultitool.com with your host's name and the path from the warning. I'll tell you which of the above applies to your setup, and whether it's worth moving. I wrote the plugin, so I know what it's asking for and how to word the ticket so support understands it.

FAQ

Has my data already leaked?

Unlikely. Step 3 tells you whether a backup is reachable right now, which is the part you can check. Since 1.9.8, database dumps are named backup-, the type, the date, then 24 random characters, then .sql, and config backups carry a random 20-character part, so nobody finds one by guessing. Before 1.9.8 database dumps had only the date in the name, which is guessable, and the update renames them. What can find one is a crawler that picked the address up somewhere, a referrer header, or another plugin that indexes your uploads folder. Unlikely, and not impossible. Nothing on your site can show you whether someone has already downloaded a file, so if step 3 finds a public dump, treat the passwords and keys in it as exposed and change them.

Why doesn't the plugin just refuse to take the backup?

Because then cleanups would stop working on a large slice of shared hosting, and you'd be running database deletions with no way back. So it takes the backup, protects the folder and makes noise about where it had to put it. Since 1.9.8 it does refuse in one case: when the backup ends up inside the web root and the server actually serves it. Then the file is deleted and the cleanup is cancelled, because a deletion with no backup is safer than a public copy of your users table.

Isn't the .htaccess file enough?

On Apache, yes. On nginx it does nothing, because nginx never reads .htaccess files (or web.config). There's no way for a plugin to fix that from inside WordPress: the rule would have to go in the server config, which PHP can't write to. Since 1.9.8 the plugin tests instead of hoping: on nginx a backup in uploads is downloaded once, found public, and deleted. To get working backups there, the folder has to move above the web root.

Can I just turn the warning off?

You can hide it for 30 days. It comes back after that, because the condition that caused it is still true. It stops for good once the backups are somewhere private. The warning about a check that could not run is separate and has to be fixed at the source: let the server reach its own address, or move the folder above the web root.

How long are backups kept?

Since 1.9.8, backups older than 30 days are deleted, and the newest 5 are always kept whatever their age. It runs once a day from WP-cron and again after every new backup. The setting is called Backup retention, on the Database Optimizer screen: set the days to 0 to keep everything, and change how many of the newest are always kept. Config Manager backups follow the same setting, and backups you pinned there are never deleted.

I'm updating from an earlier version. What happens to my old backups?

On the first request after the update, WP Multitool moves backups out of a published folder when a safe one exists, writes the protection files, renames database dumps that only had a date in the name so they get a random part, and applies the retention rules. That last step means old backups beyond the newest 5 can be deleted right away, so download anything older you want to keep first.

Does this affect Lite as well as Pro?

Yes. Both editions write database backups the same way, and the fix is identical. Config backups are Pro only, since Config Manager is a Pro module, but the folder and the protection are shared.

Not sure what your host will say?

Send me the hosting name and the path from the warning, and I'll tell you which of the steps above applies to your setup and whether it's worth moving. I wrote the plugin, so I know what it's asking for.

Email me about it