Client Profiles
A client profile describes a kind of machine — laptops, database servers, point-of-sale registers — and the settings a new client of that kind should start with. Instead of configuring each new client from scratch and remembering how you configured the last one, you describe the category once and pick it when you onboard.
Profiles live under Settings → Profiles.
Every BBS install has a Default profile. Existing clients were placed in it when profiles were introduced, and new clients land there unless you choose otherwise. It cannot be deleted.
A profile carries four groups of settings.
Identity — a name and a description. The name is what you'll pick from when adding a client, so make it the kind of machine rather than the department: Laptops rather than Sales.
What to back up — a Backup Plans, which supplies the directories, exclude patterns and advanced options a new plan starts with. Leave it as None if machines of this kind vary too much to have a sensible default.
When — a frequency and run hours. Run hours are comma-separated if you want several runs a day.
How long to keep it — the same six retention intervals a backup plan uses. 0 keeps nothing at that interval; -1 keeps every one.
How to handle failure — see below. This is the group that has no equivalent anywhere else.
Three settings govern what BBS does when a client stops responding partway through a backup:
| Setting | What it does |
|---|---|
| Max Retry Attempts | How many times a backup is re-queued after the client drops out before BBS gives up and reports a failure. |
| Give Up On Running Jobs After | How long a client must be silent and reporting no progress before BBS treats its running backup as dead. |
| Retry Backoff | How long to wait before the first retry. It doubles each attempt, capped at an hour. |
All three are blank by default, which means "follow the server-wide setting" under Settings → General. Fill one in only when this kind of machine genuinely differs.
That difference is the reason these live on the profile at all. A laptop that closes its lid mid-backup and reconnects twenty minutes later needs a much longer leash than a database server on a wired LAN, where thirty seconds of silence really does mean something broke. Before profiles, one number had to suit both: set it for the laptops and a genuinely stuck server sat unnoticed for an hour; set it for the servers and every laptop backup got killed and retried the moment someone walked to a meeting.
A blank field is not the same as zero. Blank follows the server; 0 is an actual value.
When adding a client — the Add Client page has a Profile dropdown, defaulting to Default.
Afterwards — open the client, click the pencil beside its name, and change Client Profile in the dialog. The client's current profile is shown as a badge in its header.
Moving a client between profiles takes effect immediately for failure handling — the new profile's patience applies to the next backup that runs. It does not rewrite backup plans the client already has.
This is the part worth understanding before you rely on profiles.
Editing a profile does not touch clients that already exist. A profile is a starting point, not a binding. If someone has tuned a plan for one awkward server — added a directory, loosened an exclude, extended retention because that machine matters more — that work is not undone because a colleague adjusted the profile it was created from.
The exception is failure handling, which is read live. Change Give Up On Running Jobs After on a profile and every client in it is treated with the new patience straight away. Those settings describe how BBS should react to a client misbehaving right now, so freezing a copy of them onto each plan at creation time would make them impossible to adjust across a fleet.
When you do want a profile change pushed down to everything in it, use Apply to Clients on the profile row. It is deliberately a separate, explicit action, and it is destructive.
Applying a profile replaces, on every client assigned to it:
- backup directories, exclude patterns and advanced options (only if the profile has a template)
- all six retention values
- the schedule's frequency and run hours
It leaves alone:
- which repository each plan writes to
- which plugins each plan runs
- every archive already taken
Those first two are per-client facts a profile has no opinion about, and overwriting them would break backups rather than reconfigure them.
Before it runs, BBS counts exactly what will change — how many clients, plans and schedules — and shows you those numbers. Anything tuned by hand on those clients is lost, and there is no undo. If you are unsure, the safest route is to check Backup Plans on one affected client first and note anything that looks deliberate.
Applying is recorded in the server log, so there is a record of who changed a fleet and when.
The Default profile cannot be deleted. Deleting any other moves its clients to Default; they keep the plans and schedules they already have, and their failure handling falls back to the server-wide settings.
A small business runs three kinds of machine, and each wants something different:
Registers are on all day and idle at night, on a wired network. Nightly at 22:00, keep 14 daily and 8 weekly, and be strict about failure — a register that goes quiet for five minutes has a real problem worth surfacing.
Laptops are open at unpredictable times and sleep without warning. Daily at 12:00 so they're likely awake, generous retries, and a long give-up window so a lid closed during a backup doesn't burn a retry.
Database servers use a template that pairs directories with the Database Backups, run at 01:00, keep more history, and are strict about failure.
Three profiles, created once. Onboarding a new register is then: add the client, choose Registers, done — with no chance of forgetting that registers keep 14 dailies.
- Backup Plans — what a plan contains and how templates fill one in
- Managing Clients — adding and editing clients
- Settings — the server-wide failure defaults a profile can override