# Backup cannot start: the backup folder is reachable from the web
> SiteVault Pro refuses a backup when its backup folder can be downloaded. Add one nginx, Apache or LiteSpeed rule to block it, including SpinupWP steps.
- Canonical:
- HTML version:
---
SiteVault Pro checks that nobody can download your backups by URL before every backup. When the check finds the backup folder open, the backup doesn’t start. The fix is one rule in your web server’s config. This page shows the rule for nginx (including SpinupWP), Apache, LiteSpeed and OpenLiteSpeed, and how to check it worked.
### Most sites that see this run nginx
SiteVault puts `.htaccess`, `web.config` and `index.php` deny files in the backup folder. Apache, LiteSpeed and IIS follow them. nginx ignores them, so on nginx the folder needs a server rule. That includes SpinupWP, CloudPanel, RunCloud, GridPane and most VPS setups.
## 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.
Encryption doesn’t replace the rule
With “Encrypt all backups” on, archives are still written unencrypted first and encrypted when the backup finishes, and the working files made during a backup are never encrypted. Block the folder even when encryption is on.
## 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
```
Why `^~` and not `~*`
nginx uses the first regex `location` that matches. Many hosts ship a static-file rule like `location ~* \.(zip|gz|sql)$` earlier in the config, and a regex deny rule placed after it never runs. When a `^~` prefix rule is the longest prefix that matches the request, nginx uses it and skips the regex rules, wherever they sit in the block.
### 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.
#### Create the rule file
SSH in as a sudo user and create `/etc/nginx/sites-available/{DOMAIN}/server/sitevault.conf`, replacing `{DOMAIN}` with your site’s domain:
```
location ^~ /wp-content/sitevault-backups/ { deny all; }
location ^~ /wp-content/uploads/sitevault/ { deny all; }
```
#### Test and reload nginx
```
sudo nginx -t && sudo service nginx reload
```
#### Check it, then start a backup
Run the check in [Check that it worked](#check), then click **Backup Now**. SiteVault tests the folder again before it starts.
## 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:
```
Require all denied
```
Add a second block for `wp-content/uploads/sitevault` if the older folder still holds backups.
## OpenLiteSpeed
#### Open the WebAdmin console
Go to **Virtual Hosts → (your site) → Context** (the console usually runs on port 7080).
#### Add a Static context
Click **Add** → **Static**. Set **URI** to `/wp-content/sitevault-backups/` and **Accessible** to **No**. Save. Repeat for `/wp-content/uploads/sitevault/` if the older folder still holds backups.
#### Graceful restart
**Actions → Graceful Restart**.
## 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:
```