Performance Settings

Settings, Performance is where you tune how hard your SHA works. The System tab controls how many backup streams, restore mounts, and background tasks run at once, how much of the host the Backup Data Engine - the EBA component that compresses and stores backup data - may use for compression, how many backups are admitted to start and run concurrently, when boot-evidence validation runs, and secondary copy concurrency. The Replication tab holds the safety timers that detect and recover stuck replication syncs.

You need settings read permission to open the page and settings write permission to save; users with read-only access see every control but saves are rejected. Almost everything applies within seconds of saving, without a restart - the exceptions are called out below. Tiles at the top show current effective limits, the active data engine profile with live memory-pressure state, and backup admission occupancy with the queue depth.

The Performance Profile presets size these concurrency limits in one click. Backup streams cap concurrent disk-export processes serving backups, restore mounts cap restore mount processes, background tasks cap disk-image operations such as coalesce and maintenance, and job starts size the worker pool that launches queued processes. When a limit is reached, new work queues and retries - nothing fails.

Turn on Customize limits to override values individually. Zero or negative values are ignored on save, and there is no upper guard - very large values can oversubscribe the host, so raise limits gradually. The three concurrency limits apply within about five seconds; maximum concurrent job starts is read once at start, so it takes effect the next time the appliance's process-management service restarts.

System load protection (on by default) defers new backup-stream starts while the host's one-minute load average is above the threshold. Running jobs are never paused, and restore mounts and background tasks are not load-gated. A threshold set well below typical host load will queue new backups indefinitely.

The Backup Data Engine profile - Memory Saver, Balanced (default), or Throughput - controls how much of the appliance's memory and CPU the engine may use for block compression during backup ingest. Capacity is sized automatically from the host's memory and CPU, with a matching memory guard per profile. Unlike every other control on this page, it applies immediately when clicked, with no restart; on failure the page reverts to the previous profile and shows the error.

Under memory pressure the engine protects itself: a watchdog halves compression capacity when memory runs low and drops to minimum under severe pressure, and the page shows "Temporarily throttled due to memory pressure". This is expected self-protection, and capacity recovers when pressure eases. Restore and verify decompression has its own, more generous limiter, so restores are not starved by backup compression.

Max concurrent backups (default 2, range 1-64) is the main appliance-wide backup concurrency lever: jobs over the limit queue and start automatically as slots free - lowering it queues excess backups, it never fails them. Per-repository startup limit (default 1, range 1-64) caps simultaneous backup startups per repository, and admission lease seconds (default 120, range 30-900) controls how quickly a crashed job's slot is reclaimed. Changes apply live; out-of-range values are rejected on save.

Leave the admission toggle on unless Sendense support advises otherwise. Disabling it removes the backup-start queueing gate, so scheduled jobs can all begin their startup work simultaneously - exactly the stampede this control exists to prevent.

These controls decide when boot-evidence validation runs and how much capacity it may use. A backup only runs evidence if its protection pattern requires it and it is due under the cadence set here. All boot-evidence settings apply live, and out-of-range values are rejected on save.

In Deferred dispatch mode a completed backup no longer implies its evidence has run - evidence catches up in background cycles, so expect results to lag by up to the dispatch interval plus queue depth.

Max concurrent secondary copies (default 3, range 1-64) caps how many secondary copy operations run at once; extra operations wait for a slot and the value applies live. The stale timeout (default 900 seconds, range 300-86400) treats a copy whose progress has not updated for that long as stalled and automatically recovers it - the stalled operation is removed and re-created fresh. Set it comfortably above your slowest normal copy interval so healthy long-running copies are not recycled.

The Replication tab covers six timers that detect and recover stuck replication syncs. Per-pattern, per-node, and global replication concurrency caps live with your replication patterns and DR settings, not here. Zero or negative values are ignored on save. The path probe timeout is picked up by each new sync; the remaining values are read when the appliance's replication engine starts, so plan for them to fully apply after that engine next restarts.