Why Does Immich Increase Fan Noise During Family Photo Backup?
Immich often becomes louder during family photo backup because accepting files can trigger additional CPU, machine-learning, video, database, and storage work after the network transfer itself. Fan noise is therefore a symptom of heat production, not a diagnosis of which Immich component is responsible.
A phone may finish uploading thousands of photos while the server continues generating thumbnails, extracting metadata, analyzing faces, building search representations, and processing videos. Before changing fan curves or buying new hardware, line up the noisy period with the active job queues and host resource graphs.
Match the Fan Ramp to the Job That Starts at the Same Time
Record fan speed or temperature together with CPU use, GPU activity if present, disk latency, and Immich job counts. Begin with a quiet baseline, start one representative family backup, and mark when uploads end. If the fan remains high while a specific queue continues to fall, that downstream job is a stronger explanation than the mobile transfer itself.
A recent community report after importing thousands of images and videos described sustained high CPU and pointed back to inspecting Immich job queues rather than assuming the server was stuck. Use such reports as workload evidence, not as a thermal specification: media mix, enabled jobs, CPU generation, accelerator, and cooling can make two libraries behave very differently.
If temperatures rise but CPU, GPU, and disk work stay near idle, this branch stops explaining the noise. Inspect chassis airflow, dust, fan-control behavior, a neighboring container, filesystem scrub, or backup software. The related ZimaSpace analysis of AI NAS power, cooling, and indexing load helps frame why sustained local processing can change an otherwise quiet storage appliance.
Separate Machine Learning and Video Work From Ordinary Uploading
Run a small controlled batch and watch whether machine learning, thumbnail generation, or video-related work dominates after the files arrive. Image analysis can keep CPU or an accelerator busy; video processing can add longer bursts; thumbnail generation and metadata extraction can combine CPU work with many filesystem operations.
An Immich background-processing discussion illustrates an important queue behavior: downstream jobs can be created while upstream work is still completing, so one queue can rise even though the system is making progress. A growing count is not automatically a loop; compare arrival and completion rates and look for repeated failures on the same assets. Pause or reduce only the confirmed heavy class during diagnosis. If fan noise drops immediately and the household interface becomes responsive, resume at lower concurrency and measure how much longer the queue takes to drain. If noise is unchanged, restore the previous setting and follow the next resource rather than stacking unrelated tweaks.
Check Storage and Cooling When CPU Percentage Does Not Explain the Noise
Hard drives can stay active during originals writes, generated-file creation, database checkpoints, or another NAS backup that overlaps the Immich import. Disk activity can also warm a compact enclosure even when CPU percentage looks moderate. Record drive temperatures and I/O wait alongside processor temperature instead of treating โlow CPUโ as proof that cooling should be quiet.
Confirm that intake and exhaust are unobstructed, fans and heatsinks are clean, and the server can sustain the workload without thermal throttling. Independent NAS load-and-noise measurements show the expected mechanism: a compact system can become measurably louder under sustained load than at idle.
The exact dBA values are hardware-specific; use your own temperature and fan curve as the acceptance boundary.
Do not solve a processing bottleneck by insulating or restricting airflow to make the box quieter. If the server must live near people, schedule heavy initial imports for an acceptable time, lower measured concurrency, relocate the machine, or improve cooling. The change should reduce heat or exposure without converting noise into hidden thermal stress.
Validate Noise Against a Complete Backup Cycle
Repeat the same sample after one targeted change and measure upload completion, queue drain time, temperatures, fan behavior, search responsiveness, and failed jobs. Include enough time after the last upload for background work to settle; judging only the transfer window can miss the stage that actually heats the server.
A passing result has a predictable noisy window, stable safe temperatures for the hardware, advancing jobs, no thermal throttling or unexpected restarts, and a return toward baseline after the workload drains. Record that envelope so later fan noise can be compared with a known normal family-backup cycle. If noise persists long after queues are empty, one job repeatedly regenerates the same work, or the host remains hot with Immich idle, treat it as a separate cooling or competing-service problem. Escalate with temperatures, fan RPM if available, resource graphs, queue counts, versions, and the timestamp where workload ended but the symptom did not.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
