Shell script hooks can now wait for the whole backup, not just the borg part — and plugins run in an order you choose.
Post-scripts can wait for prune and offsite sync (#402)
A shell hook's post-script ran the moment borg finished. That is only the client's half of the work: prune and offsite sync happen afterwards on the BBS server. A script that powers down the machine holding the repository therefore cut the prune off part-way through, or stopped it happening at all.
The shell hook config now chooses when its post-script runs:
- As soon as the backup finishes — the existing behaviour, and still the default. Nothing changes for configurations you already have.
- After prune and offsite sync finish — the client skips the script, and BBS waits for the repository to go quiet before sending the client a job to run it.
Backing up to storage that is woken for a window and shut down again is a normal enough arrangement that borgmatic has a hook point for exactly this. Thanks to @Flache8734 for the report and for the config excerpt showing how it should behave.
The client has to still be online when the work finishes, since that is where the script runs. And the hook has to be a saved plugin configuration rather than an inline one — an inline config can't be addressed later, and a deferred hook on one is now logged as skipped rather than silently never running.
Plugins run in the order you put them in
Plugin cards on a backup plan can be dragged, and the selected ones show the step number they run at. Useful when one plugin's output depends on another having gone first — a script that quiesces an application before the database dump, say.
The order was always respected internally; there was simply no way to influence it. Selected plugins now also sort to the front of the list in run order, so the sequence is visible before you change anything.
Also in this release
The status report from a client no longer loses work when the client disappears mid-request. Importing the file catalog and queueing the automatic prune both happen after BBS has already accepted the report, and on Apache installs that work ran on the client's own connection — so a client that powered itself off in a post-backup script could take the tail of it away. The prune then never got queued, and the job sat at "Importing file catalog..." indefinitely.
Also worth knowing, from earlier tonight
v2.79.2 added borg 1.4.5 for clients on older Linux — CentOS/RHEL 7, Amazon Linux 2, and anything else still on glibc 2.17. It sits alongside 1.4.4 and 1.4.3 under Settings → Updates → Borg, and nothing switches to it on its own: the version your clients receive stays where you left it until you select 1.4.5 and save. Clients that can run upstream's own binary still get upstream's — the bundled build is only used where no compatible official one exists.
That release also stopped a backup succeeding with an unexplained empty file browser: the file catalog import could decline to run in four different ways and log none of them, and now says which.
Notes
- The agent is updated in this release (2.80.0) — the deferred post-script arrives as a new task type, so clients need it before that option will work. Everything else works on older agents.
- Adds one database migration.
