How to Optimize Photo Thumbnail Jobs Around Backup Windows
Thumbnail generation reads originals, writes many small derivatives, updates database rows, and may compete for CPU with video encoding or machine learning. Running it during a NAS backup can stretch both jobs and increase latency for interactive photo browsing.
The goal is not to make thumbnails permanently slow. Measure which resource collides with the backup, reduce only the relevant concurrency, and give each heavy job a defined window with a recovery rule if it overruns. Keep normal worker settings documented so temporary throttling does not become an unnoticed permanent limit.
Measure the Collision Before Changing Workers
Run a normal backup without a thumbnail backlog and record duration, storage latency, network throughput, and CPU use. On another day, process a representative thumbnail batch without backup traffic and capture the same metrics.
The constrained resource determines the fix. High disk latency suggests staggering read and write workloads; a saturated CPU suggests fewer image workers; a busy database volume may require separating database storage from derivative storage.
Immich exposes job queues and worker controls described in its jobs and workers documentation. Record the current values before editing them so a failed experiment has a clean rollback.
Define a Quiet Window and an Overrun Rule
Place backups in the window with the strongest recovery requirement, then reserve a following or preceding window for thumbnail work. Avoid starting both at the same minute, because queue startup can create a burst of file opens and database activity.
Define what happens if a backup runs long. A safe rule is to leave thumbnail workers reduced or paused until the backup reports completion, then restore their normal concurrency rather than allowing two schedules to overlap blindly.
Keep a catch-up window after large imports. Without one, a low overnight worker limit can leave users waiting days for thumbnails even though daytime resources are available.
Tune Concurrency for the Bottleneck
Change one worker class or concurrency value at a time and process the same size batch. Compare queue drain rate with backup duration and interactive latency instead of judging success by CPU utilization alone.
If originals and backups share HDDs, fewer concurrent image reads often help more than a higher CPU limit. If originals are on fast storage but the database is busy, move or protect the database workload before increasing workers.
Keep network mounts reliable during both operations. The Immich network storage guide explains why a mounted-but-stalled path can look like an application job problem.
Validate One Full Cycle and Restore Normal Service
Observe a complete backup followed by a thumbnail window. Record start and finish times, maximum storage latency, queue depth, failed jobs, and whether users can open recent photos during the cycle.
After the backlog drains, return concurrency to the documented normal value if the reduced setting was only for catch-up protection. Permanent throttling should be intentional and based on measured service goals.
The change passes when backup duration remains predictable, thumbnail queues clear within the planned catch-up period, and no failed jobs or missing assets appear. Roll back the last concurrency change if error rate or database latency rises.
Recommended products
Support & Tips
More to Read
Can You Replace a Noisy Mini PC Fan Without Changing Thermal Control?
Yes—if the replacement matches the electrical interface, airflow, and feedback signals; connector fit alone does not preserve thermal control.
Can a Home Server Resume Services in Dependency Order After UPS Recovery?
Yes—use explicit boot dependencies and readiness checks; restart policies alone do not guarantee services become usable in the right order.
Can You Use Wake-on-LAN After a Complete Power Loss?
Sometimes—WOL needs standby power and firmware/NIC state to recover after AC returns; it cannot wake a machine while power is absent.
