Backup settings

Console → Backup settings. The backups themselves, schedules and downloads live on Backups: Backup strategy.

The Backup settings screen has three parts, and each one is changed in a different place. That is all this table says:

Backups & disk space

One switch, and it is not about whether backups run. It decides whether a table that did not change since the last backup keeps the file it already has instead of being written again. The backup is complete either way.

• S3-only servers write every table regardless: reusing a file means pointing at it on this machine's disk, and a server whose backups live only in a bucket has nothing here to point at. The card counts those servers.
• Use the default appears once you choose, and returns to the startup value.
• A red line saying the timer is on but no server can be refreshed is real: rebuilding from recorded changes writes files, so it needs a server with a Backup dir.

Per server

Backup dir, Backup S3, and Don't automatically include archived data in queries. Save or Enter.

Daemon default on that row means this server has no location of its own, so it falls back to the one DBTrail itself was started with. That one is shared by every server: a backup built there would fold this server's changes onto another server's snapshots and belong to neither. So reading the past works and making a backup refuses. Save a location on the server itself.

Warnings under a server:

• "The schedule cannot run as things stand." Usually a location cleared after the schedule was made. Every slot refuses until you save one.
• "Each scheduled run takes a full backup from your database." Backup S3 without Backup dir: nowhere local to rebuild, so every run reads the source in full. Add a Backup dir for the cheap path.

With a Backup S3, the server also shows about how many backups reach the bucket every 30 days, and Bucket rule to expire old backups: a days field, an S3 lifecycle rule for that server's backup prefix, and the command to apply it. DBTrail never deletes from S3 and never applies the rule; you do. The rule expires by age only, and the apply command replaces every rule on the bucket.

Set at startup

Read-only here. These are the values DBTrail was given when it started, and a running process cannot change how it was started: to change one, change the flag or variable named under the row and restart DBTrail.

Empty values read none, off, all tables or temp folder: not faults. A value the daemon refused shows a red line under its row.

Not on this screen: whether a scheduled update rewrites a changed table or writes its changes beside it (on by default since v0.84.0). It is set at startup only, with the flag --baseline-table-deltas=false or the variable BINTRAIL_BASELINE_TABLE_DELTAS=false to turn it off: how the Parquet copy works.

Good to know

• Backups says how each scheduled backup was made and, when it was a full copy, why. The reason is saved with the run, so it stays true after the cause is gone.
• After a long stop, a scheduled update can become a full backup (since v0.84.0). Before each slot the daemon measures how many changes an update would have to apply since the previous backup, against a cost model fitted on its last five measured updates and the duration of the last full backup. When the update is estimated to cost more, a full backup is taken and the run's reason on Backups reads Full backup instead of an update: an update from the recorded changes would take longer than a full backup: <N> events since the previous backup would take about <time> to apply at the measured rate, and the last full backup took <time>. When one of the three is unknown (no full backup on record, no measured update rate, or an index that did not answer the probe in time, warned once in the log), the age of the previous backup decides alone: older than two hours or six schedule intervals, whichever is longer, and the reason starts the previous backup is too old to update from and names what was missing. Both are said in the daemon log before the run starts. Backups also says which method the next slot will use, from the same measurement: Next run will take a full backup from your database (...). A server whose full backups cannot start keeps updating, however long it takes.
• A scheduled update with nothing new does not start (since v0.83.0). Each cycle first asks whether anything was indexed since the last update and whether the previous backup is still inside the window the index can update from. When nothing is new, the cycle is skipped: no run appears on Backups for it, and the daemon log says baseline refresh: nothing has been indexed since the last fold; skipping this cycle. A quiet server no longer republishes the same rows every interval.
• A full backup with a Backup dir is published as soon as it is on disk; the copy to S3 runs afterwards (since v0.84.0). The upload no longer holds the server's backup slot, so a scheduled update can run alongside it and reads the local copy, and the upload sends only the new snapshot, then any earlier local snapshot the bucket lacks. While the copy runs, Backups shows Backup saved on this machine: <N> table(s). Still copying it to the backup destination…, and the schedule counts the run as in flight until it finishes. An upload that fails after that is a failed run that keeps the local snapshot and names where it is. With a Backup S3 alone, nothing is published until the bucket has it, as before.
• A backup built from recorded changes checks free disk before each file it writes and refuses when the file plus 1 GiB does not fit.
• A read-only console (serve) shows the per-server list only: no backup loop, so no disk-space or startup card.
• A registry written by a newer DBTrail: values shown, saving refused, so nothing the newer version stored is dropped.