Backup cannot start: the backup folder is reachable from the webPRO

Why SiteVault refuses to back up

A backup holds your whole database and your wp-config.php. If the folder it’s saved in can be read over the web, anyone who guesses or finds a backup file name can download it. SiteVault tests this by writing a small test file into the folder and requesting it over http:// and https://. If the test file downloads, the backup is refused and the message names the folder and the rule to add.

Find your backup folder

Go to SiteVault Pro → Settings → General. Backup Location shows the full path. When the folder is open, the exact rule for your site appears right below it, and the refusal message shows it too. Copy it from there if you can.

• Most installs: wp-content/sitevault-backups/
• Older installs: wp-content/uploads/sitevault/backups/ (the folder the free SiteVault plugin also uses). If your site moved to the new folder and the old one still holds backups, block both.

nginx

Add this inside the server { ... } block for your site, above the other location blocks:

location ^~ /wp-content/sitevault-backups/ { deny all; }
location ^~ /wp-content/uploads/sitevault/ { deny all; }

The second line covers the older folder; it does no harm if that folder doesn’t exist. If WordPress lives in a subfolder (for example example.com/blog/), put that folder in front: location ^~ /blog/wp-content/sitevault-backups/ { deny all; }. The rule shown in SiteVault already includes it. Then test the config and reload:

sudo nginx -t && sudo systemctl reload nginx

Which server blocks need it

Add the rule to every server block that serves your site’s files. A block that only redirects (for example port 80 sending everything to https://) serves nothing and doesn’t need it. If the SiteVault message says “http:// redirects to https://”, the HTTPS block is the one to change.

SpinupWP

SpinupWP loads custom rules for a site from its server/ folder, inside the server block and before its own location blocks.

location ^~ /wp-content/sitevault-backups/ { deny all; }
location ^~ /wp-content/uploads/sitevault/ { deny all; }

sudo nginx -t && sudo service nginx reload

Apache and LiteSpeed

Both follow the .htaccess file SiteVault writes into the folder, so normally nothing is needed. If the folder still shows as open, the server is set to ignore .htaccess files (AllowOverride None). Add this to the site’s virtual host instead, with your real path, then restart the web server:

<Directory "/var/www/example.com/wp-content/sitevault-backups">
    Require all denied
</Directory>

Add a second block for wp-content/uploads/sitevault if the older folder still holds backups.

OpenLiteSpeed

Check that it worked

From your own computer, request a backup-style file name in the folder. The file doesn’t need to exist:

curl -I https://example.com/wp-content/sitevault-backups/test.zip

403 Forbidden means the folder is blocked. 404 Not Found means the request reached the folder, so the rule isn’t active yet: check that you edited the block that serves the site and that the reload succeeded. (Don’t test with web.config or .htaccess: many servers refuse those names everywhere, so a 403 there proves nothing about the folder.) Then click Backup Now; the backup starts once SiteVault’s own test is refused too. The admin notice clears on its next check.

When something in front of the server already blocks the folder

SiteVault requests the test file from your own server. If a proxy or firewall in front of the site (and not the web server itself) blocks the folder, the test can still see it as open. Only in that case, a developer can tell SiteVault to skip the test with a must-use plugin:

<?php
add_filter( 'rb_allow_public_backup_dir', '__return_true' );

Still refused after adding the rule? Email priority support

Email support@royalplugins.com with the details below. Priority email support is included with your SiteVault Pro license; typical response time is within 24 hours.