BackupBinder

A backup has four parts.

The site is a directory on this machine. Files are always included. A database dump is included when an addon, such as the WordPress one, says the site has a database.

1. Capture Files from a local path or an SFTP server (copied here first).
2. Archive A versioned local repository. Unchanged data stored once.
3. Copy out Optional destinations (SFTP, disk, S3, B2, Google Drive). With none enabled, the run never leaves this computer.
4. Prove restore Test into an empty scratch directory, away from the live site.

The browser, the command line, or an agent.

They run the same backup. Every command prints JSON, so a script or an agent can read the result. The browser is there for you to set a site up and to read the last run.

• Browser

  serve on this machine. Set up a backup, then read the last run and whether a restore has been checked.

• Command line

  Setup, backup, check, and restore from the terminal. A failure comes back as JSON with a code and a message.

• Agent

  An agent talks to the same tools over stdio MCP. It names the exact site before it changes anything, and it asks you for a host, a user, or a key.

You can check that a restore works.

A restore into an empty folder is how you know the archive is good. These rules are on every run.

Archive

Lives on this machine

Restore

Empty scratch only

Remotes

Optional copies

• A restore goes into an empty folder. The live site, a folder inside it, a parent of it, and the repository are refused.
• Database passwords and destination secrets stay out of the site file and out of command output.
• A change needs the site's id and its exact root.
• A backup with no remote is finished. A remote is a copy of that archive.
• WordPress is one shipped addon. A directory that matches no addon is files only.