Docs

Backups & volumes

What each profile copies, how a job becomes a backup, and how to be sure the file on your disk is the file the server made.

The five profiles

Profile	Key	Copies
Everything	full	The database and every file, including uploads.
Database only	database_only	The database only. No files at all.
Files only	files_only	Every file, including uploads. No database.
Files without media	files_no_media	The database and every file except uploads — the smallest copy that still carries your code and content.
Custom	custom	Choose the areas yourself. Anything you do not tick is left out.

Jobs and backups are different things

A job is a run in progress. A backup is what a finished job left behind. They are separate resources because they have separate lifetimes — cancelling a job is not deleting a backup, and deleting a backup does not touch any job.

The five stages

Every backup moves through the same pipeline. Each stage does a bounded amount of work, records exactly where to resume, and hands control back:

1Checking there is room — before anything is written.
2Exporting the database — table by table, with a recorded position.
3Scanning files — building the list of what goes in.
4Building the archive — writing volumes and their checksums.
5Finishing up — sealing the manifest and running the retention sweep.

Every stage must complete at least one unit of work per step. A stage that returns without advancing its resume position fails its job with a message naming the stage, rather than being re-queued forever.

Volume size and retention

Both live on the Settings tab.

Maximum volume size (MiB) — defaults to 1536. Anything below 10 is raised to it when saved. Very large single files are refused or truncated by a fair number of hosts and browsers, which is what splitting avoids.
Backups to keep — older backups beyond this many are deleted automatically at the end of each run. Set it to 0 to keep every backup and manage them yourself.
Extra exclusions — one glob pattern per line, relative to the WordPress root. These are added to the ones every profile already excludes.

Verify the checksum. Really.

Every volume's SHA-256 is shown on the Backups screen, computed when the archive was sealed. Check it after downloading — this matters more here than for most files.

A truncated zip is not a partial backup

A .zip keeps its index at the end. An archive whose download was cut short is not a backup missing its last few files — it is a file that will not open at all. The checksum is how you tell which case you are in, months before you need the answer.

# macOS / Linux
shasum -a 256 fiction-drafts-2026-08-29-full.zip

# Windows PowerShell
Get-FileHash .\fiction-drafts-2026-08-29-full.zip -Algorithm SHA256

Interrupted downloads resume

The download endpoint supports HTTP range requests, so a transfer that drops picks up where it stopped rather than restarting.

# resume in place
curl -C - -O "https://example.com/...&token=..."
wget -c "https://example.com/...&token=..."

The five-minute lifetime on a download link bounds when a download may start. A transfer already under way is never interrupted, so a multi-hour download of a large archive is fine.

What the manifest records

Alongside the archives, each backup carries a manifest of what went into it: the WordPress version, the PHP version, the list of active plugins, the table list, and byte counts. It is how a backup stays interpretable long after you have forgotten what the site looked like when you made it.