05-Jun-2026 — configurable backup worker pool and rename task to backups ref #282

build 668 — commit bdc2fc7

What's New

The all-environments backup now has a configurable worker pool, so its memory use can be tuned from the admin UI rather than being fixed in code. Manual backups across many environments no longer start all at once, which was the cause of the earlier out-of-memory failures. The task has also been renamed to "Backups" for a shorter, clearer label.

Related issue: #282 - feat(backup): scheduled all-environments backup task (off by default, platform-admin only)

At a glance

• Manual all-environment backups run one environment at a time instead of firing every request together.
• A new Backup worker pool panel lets you tune concurrency, timeout and retries.
• Defaults stay memory-conservative, so existing behaviour is unchanged until you raise the limits.

Where to find it

Open Admin > System Settings > Scheduled Tasks and choose the Backups tab (/admin/system-settings?tab=scheduled-tasks&task-sub-tab=backups). The worker pool controls sit alongside Run now, the enable switch, the schedule and the run history, matching the embedded-configuration pattern already used by the Brevo task.

How it behaves

The Backup worker pool panel exposes these settings, stored with the scheduled task:

• Mongo backups
• how many environments are dumped at once. Default 1. This is the memory-sensitive control, since each concurrent environment runs its own mongodump process.
• S3 object backups
• how many objects are copied in parallel within a backup. Default 8. These are server-side S3-to-S3 copies, so raising this costs API throughput rather than server memory.
• Timeout per environment
• default 45 minutes.
• Retries and Retry delay
• default 1 retry after 60 seconds, so a single transient failure does not lose that environment's backup until the next run.
• Upload Mongo dumps to S3 and Include S3 objects
• included by default.

Manual backups started from the Backup and Restore page now run the selected environments serially and collect any per-environment failures, instead of launching a burst of concurrent requests and stopping at the first error.

Why it is restricted

The all-environments backup still only runs where platform-admin is enabled, and the scheduled task remains off by default. The worker pool changes do not alter that. A normal group site shows the task for visibility but does not run it.

How to try it out

1. Go to /admin/system-settings?tab=scheduled-tasks&task-sub-tab=backups.
2. Confirm the Backups tab shows the Backup worker pool panel with the defaults above.
3. Adjust a setting (for example raise S3 object backups) and Save backup settings.
4. Use Run now and watch the run history to confirm environments are processed one at a time.

Technical changes

• New scheduled-task settings shape persisted under the existing scheduledTasks config document, keyed by task id, with defaults registered so a fresh task shows them before the first save.
• Scheduled backup job replaces its hard-coded loop with a bounded worker pool that reads these settings; default concurrency of 1 preserves the current serial behaviour.
• S3 object backup accepts a bounded concurrency, defaulting to 1, threaded through the backup service into the S3 copy path.
• Manual multi-environment backup on the Backup and Restore page serialises starts and aggregates per-environment failures.
• Default settings: Mongo concurrency 1, S3 object concurrency 8, timeout 45 minutes, retries 1, retry delay 60 seconds.
• Rename: the slug all-environments-backup becomes backups consistently across the ScheduledTaskSubTab enum value, the task id and name constants, the settings interface, the Angular component and its selector, both source filenames (backups-task-settings.ts, backups-job.ts), the backend scheduleBackups function and the cron:backups log namespace. The sub-tab label is now "Backups"; the descriptive card heading remains "All-environments backup".