Point it at a folder or a server.

A folder on this machine

--path is a directory here. Pass the site's --id and --root on later calls, once setup has given them to you.

./bin/backupbinder setup --path /path/to/site

Each response has phase and next. Read next, send only what it asks for, and stop when phase is ready. If next.options is set, pick one option. Do not send every field from every option.

You can decline a step:

• --no-database stores files only.
• --remote none keeps the archive on this machine.
• --no-schedule leaves the schedule off.
• --no-backup finishes setup without taking a backup now.

If that directory is already a site, setup returns the existing site. It does not create a second one.

A server

A server is a host, a user, and a remote path, passed together. Do not also pass --path.

./bin/backupbinder setup --host files.example --user backup --remote-path /var/www/site --name Example

The next backup copies that server into var/copies/ with rsync over SSH, then archives the copy. SSH uses the keys already on this machine. Saving a new server replaces the previous one. localhost in the server's database config means the database on that server.

In the browser

Run serve, open the UI, and choose Set up a backup. Each page is one decision, with every field for that decision. Back returns to the previous page with the values you saved. Retention and speed limits stay on the site page after setup.

What the run stores

Files are always in the backup. Cache directories, node_modules, and similar junk are left out.

A database dump is included when the site's addon defines one, or when you set a database yourself. The WordPress addon ships with the program. It looks for a WordPress tree, then tries wp db export and, if that fails, mysqldump. On a server, that dump runs on the server and is copied back.

If no addon matches, or you pass --adapter files, the backup is files only. A files-only site has no database password. set_adapter reads the directory again and saves the matching addon on a site you already have. The schedule, the server, and destinations stay.

The dump password is read from the config file the addon names. For WordPress that file is wp-config.php. If you save a password into var/secrets/, it is read from there instead. It is not written into the site file, and commands do not print it.

You can add a site type, or replace one, by putting a JSON file in addons/ next to the program. The same id replaces the shipped addon. A new id adds a type. The file names the marker files, what to leave out, how to read versions, and which dump commands to run.

Each successful run writes var/manifests/<site>/<run>.json and a row in var/registry.sqlite. The manifest names the site, the files, the database when one was captured, versions when they can be read, the size, the time, where the snapshot was written, the restore commands, and restore confidence. Confidence stays never until a scratch restore has passed.

The site file

The browser and the commands write var/sites/<id>.json. You can edit that file. The next time the program opens, a newer file replaces the registry row. The same refresh happens when serve or mcp handles a request.

Passwords, access keys, and secret keys are rejected in that file. They stay in var/secrets/.