Freshet Backup

FAQ

What is in a backup?

Every table that starts with your site’s table prefix, as a compressed SQL file (.sql.gz). Set FRESHET_BACKUP_ALL_TABLES to true to include every table in the database. Files and uploads are not included.

The database is read through WordPress itself, a few rows at a time, so it works on hosts that allow no shell commands and does not need much memory.

How do I restore a backup?

Download the file from Dropbox and import it into the database: with your host’s database tool (phpMyAdmin accepts .sql.gz files), or from a shell with gzip -dc backup.sql.gz | mysql database_name.

Where is the Dropbox connection stored?

In wp-config.php, not in the database. A copy of the database on a development machine, a staging site or in a migration tool then carries no access to your Dropbox. The lines only apply on this site’s own addresses, so a copy of wp-config.php elsewhere does nothing either.

Before changing wp-config.php, the plugin checks the new version for errors, writes it beside the old one and swaps it in whole, then reads it back. If the read-back differs, the previous contents are put back. No copy of wp-config.php is kept anywhere. If it cannot write the file, the screen shows the lines to paste yourself.

Disconnect removes the site’s access at Dropbox and takes the lines out again.

Which settings are there?

The screen sets how often backups run. Everything else is an optional constant in wp-config.php: FRESHET_BACKUP_INTERVAL (seconds, or hourly / twicedaily / daily / weekly; overrides the screen), FRESHET_BACKUP_ALL_TABLES, FRESHET_BACKUP_DIR, FRESHET_BACKUP_KEEP_LOCAL (default 3), FRESHET_BACKUP_KEEP_REMOTE (default 7) and FRESHET_BACKUP_DROPBOX_PATH (default: a folder named after the site’s host). The database holds only the schedule chosen on the screen and the result of the last run.

Where are the copies kept on my server?

Each backup is written to a folder on your server first. Settings → Freshet Backup shows its path. By default it is a folder with a random name inside wp-content, protected by .htaccess and web.config files, and before every backup the plugin checks that nobody can download from it. To choose the folder yourself, set FRESHET_BACKUP_DIR in wp-config.php; it may be anywhere the web server can write, including outside the website.

Version 1.1.0 could put this folder next to the website’s folder. From 1.1.1 on, backups still waiting there are moved into the new folder by the next backup and sent from there. If one cannot be moved, the Last run row says so and where it is.

Once Dropbox confirms it has a backup, the copy on the server is deleted. A backup that could not be sent waits in the folder and goes with the next one, and without Dropbox the backups stay there. The folder holds at most 3, oldest removed first; FRESHET_BACKUP_KEEP_LOCAL changes the number.

In Dropbox, 7 are kept, oldest removed first; FRESHET_BACKUP_KEEP_REMOTE changes the number. Other files in the folder are never touched.

Can I use my own Dropbox app?

Yes. Define FRESHET_BACKUP_ENABLED, FRESHET_BACKUP_DROPBOX_APP_KEY, FRESHET_BACKUP_DROPBOX_APP_SECRET and FRESHET_BACKUP_DROPBOX_REFRESH_TOKEN in wp-config.php. They take precedence over a connection made on the screen. Give the app access to its own folder only, with the files.metadata.read and files.content.write permissions.

It says the backup folder can be downloaded from the web

Your server ignores the .htaccess file in the backup folder, which is common on nginx. Set FRESHET_BACKUP_DIR to a folder outside the web root, or block that folder in the server configuration. Until then no backup is written there, on purpose.

Does it run without visitors?

Mostly, and it tells you when it does not. WordPress runs scheduled tasks (WP-Cron) only when someone visits the site, and a page cache answers most visits before WordPress loads. So on a quiet or heavily cached site a backup can be late.

Two things cover that. A backup that is a whole interval overdue is made the next time an administrator opens wp-admin, after the page has loaded. And if nothing has worked for twice the interval, a notice appears on every wp-admin page.

For a schedule that does not depend on visitors, give the site a real cron job. In wp-config.php:

define( 'DISABLE_WP_CRON', true );

and in the server’s crontab:

*/15 * * * * cd /path/to/wordpress && wp cron event run --due-now --quiet --url=https://www.example.com

Keep the --url: the Dropbox connection only applies on the site’s own addresses, and a command without it names none. Without WP-CLI, curl -fsS -o /dev/null https://www.example.com/wp-cron.php?doing_wp_cron in the crontab does the same job.

Do not set DISABLE_WP_CRON without adding the crontab line: then nothing runs the schedule at all. To check, look at the end of the Last run row under Settings → Freshet Backup. “Started on schedule” means the schedule is running; “Started by the catch-up” means it is not, and only wp-admin visits are keeping backups going.

How do I know a backup actually happened?

Look at Last run under Settings → Freshet Backup. It shows when the last backup ran and, if it failed, why. If backups stop happening, a notice appears on every wp-admin page.