Where backups go
A backup is written to a folder on your server first, then sent to Dropbox. Once Dropbox has confirmed it holds an identical copy, the copy on your server is deleted. The folder on your server is a waiting room, not an archive.
In Dropbox
Freshet Backup only sees its own folder in your Dropbox: the app folder under Apps. Inside it, each site gets a folder named after its host, so several sites can share one Dropbox account without mixing:
Apps/<app folder>/www.example.com/www.example.com-20261025-031500.sql.gz
The file name is the host and the time the backup started, in UTC.
The newest 7 backups are kept. After each run, older backups of this site in that folder are removed. Only files the plugin made are counted and removed; anything else you put in the folder is never touched. To keep more or fewer, set FRESHET_BACKUP_KEEP_REMOTE. To use another folder, set FRESHET_BACKUP_DROPBOX_PATH (/ puts the files in the app folder itself). Both are on wp-config constants.
The check that a backup arrived complete
A backup only counts once Dropbox confirms it arrived complete. When the upload finishes, Dropbox reports a fingerprint of the file it stored (its content hash). The plugin computes the same fingerprint from the file on your server and compares the two.
- They match: the backup is in Dropbox and verified. The copy on your server is deleted.
- They do not match, or the upload fails: the backup does not count. The copy on your server is kept, and the next run sends it again along with its own. Last run and a notice on every wp-admin page say what went wrong.
Large backups go up in 8 MB pieces, so the plugin never holds a whole backup in memory.
On your server
Settings → Freshet Backup shows the local folder's full path under Local folder. The plugin picks it in this order:
FRESHET_BACKUP_DIR, when you set it inwp-config.php.- A folder next to the website's folder, never inside it:
<parent of the web root>/freshet-backups/<host>/. Used only when the server allows writing there and that parent folder does not itself look like a website. - A folder inside
wp-content, with a random name:wp-content/freshet-backup-<random>/.
Wherever it ends up, the plugin writes three files into it that tell web servers to serve nothing from it: .htaccess, web.config and an empty index.php.
At most 3 backups are kept here. With Dropbox working, the folder is normally empty: each backup is deleted as soon as Dropbox has verified it. Copies only pile up when Dropbox cannot be reached; then the oldest are removed so no more than 3 remain. Set FRESHET_BACKUP_KEEP_LOCAL to change the number.
Without a Dropbox connection, backups made with FRESHET_BACKUP_ENABLED stay in this folder only, and the same limit of 3 applies.
Choosing the folder yourself
Set an absolute path in wp-config.php, above /* That's all, stop editing! */:
define( 'FRESHET_BACKUP_DIR', '/home/example/backups/www.example.com' );
A folder outside the web root is best: nothing a URL can reach. The web server must be able to write to it; if it cannot, no backup is written and Last run says which folder and why.
The download check
A backup in a folder anyone can download is a public copy of your database. So whenever the local folder sits somewhere a URL could reach it, inside the web root or inside wp-content, the plugin checks before every backup that it really cannot be downloaded.
It saves a small test file in the folder, requests it from your own site over HTTP, and deletes it again. Then:
- The file did not come back (the server answered 401, 403, 404 or 410, or showed some other page instead): the folder is private. The backup is written.
- The file came back: the folder can be downloaded from the web. No backup is written.
- The check could not finish (the site could not reach itself, or answered with an error): no backup is written either.
The check fails closed: when the plugin cannot confirm the folder is private, it makes no backup, rather than one that might be public. Last run and a notice on every wp-admin page say which case it was, and the folder.
A folder outside the web root, which nothing maps to a URL, needs no check and gets none.
When the check fails
The usual cause is a server that ignores .htaccess, which is common on nginx. Two fixes:
- set
FRESHET_BACKUP_DIRto a folder outside the web root, or - block that folder in the server configuration.
If the check could not finish because the site cannot load its own pages (a firewall, or a host that blocks requests to itself), the first fix is the one that works.
Until one of them is in place, no backup is made on purpose. Press Run backup now after the change to confirm it.
Next: Schedule and missed backups.