USB backup speed often collapses after tens of gigabytes when a fast cache fills or sustained work exposes a slower storage, thermal, or transport limit.
The first 50GB is not a universal threshold. It is a clue that the transfer crossed from burst behavior into steady-state behavior, reached a different file set, filled an SSD cache, triggered SMR cleanup, heated an enclosure, or exposed USB retries. The correct diagnosis compares the same source data through controlled large-file and small-file tests while recording destination latency, temperature, link errors, and actual written bytes.
Confirm Whether the Slowdown Follows Bytes, Time, or File Count
Repeat a bounded backup while recording elapsed time, transferred bytes, file count, average file size, source read rate, destination write rate, and the exact point where throughput falls.
Fio distinguishes sequential and random workloads, which makes it suitable for proving whether the destination slows after a fixed byte volume or only when the backup reaches many small files.
If the collapse occurs near the same number of written gigabytes regardless of file mix, investigate cache and thermal limits. If it follows file count or directory depth, metadata and application overhead are more likely.
Check Whether an SSD Burst Cache Has Filled
Identify the destination media and record its model, free space, temperature, firmware, and sustained write behavior. Compare the first minute with the rate after the slowdown.
Crucial explains that SSD performance can fall when background garbage collection needs cleanup time, which is why a short fast burst does not represent the drive’s long-duration write rate.
Pause the workload long enough for the drive to cool and perform background cleanup, then resume with the same data. A temporary recovery supports cache or thermal pressure but does not identify which one without temperature and latency evidence.
Rule Out Drive-Managed SMR Cleanup
Check whether the USB destination contains a drive-managed SMR disk. Compare one large sequential stream with a backup that repeatedly updates or creates many small files.
Seagate states that SMR performs best with predictable writes, while fragmented or random updates can create additional internal movement and a lower steady-state rate.
Do not infer SMR solely from capacity or brand. Confirm the exact model, and avoid using a drive whose workload characteristics conflict with frequent incremental or metadata-heavy backups.
Check for USB Resets, Autosuspend, and Link Retries
Save the host log from before the backup begins through the slowdown. Look for device resets, UAS errors, command aborts, negotiated-speed changes, disconnects, and autosuspend transitions.
The Linux kernel documents USB runtime power management, helping separate a storage-media slowdown from a transport path that repeatedly suspends, resumes, or resets under sustained load.
A USB link can remain connected while retries reduce useful throughput. Test a direct rear port, known-good short cable, correct power adapter, and another host before changing filesystem or backup settings.
Determine Whether the Backup Changes Into a Small-File Workload
Inspect the backup log around the slowdown and compare average file size, file creation rate, metadata operations, ACL work, checksums, compression, and encryption before and after the threshold.
Red Hat describes small-file storage as a metadata-intensive workload, so a lower MB/s value can be normal when the backup shifts from large payload files to many create, close, stat, and directory updates.
Measure files per second as well as megabytes per second. A small-file phase can show low byte throughput while the storage stack remains busy and responsive.
Verify Free Space, Discard, and Write Amplification
Record destination free space, snapshot retention, recycle-bin use, thin allocation, and whether discard reaches an SSD through the USB bridge and filesystem.
The fstrim manual explains that unused blocks must be communicated to supported storage before they can be reused efficiently.
Do not enable discard through an enclosure that does not pass it safely. Restore deliberate free-space headroom first, then compare the same backup segment after supported cleanup.
Run One Controlled A/B Backup Before Replacing Hardware
Create one large-file test set and one equal-size small-file test set. Run each to the same destination after cooling, then repeat on another USB path or destination while capturing temperature and errors.
The ZimaSpace guide to staging a large initial backup provides the adjacent method for separating backup scheduling and network saturation from destination steady-state performance.
The diagnosis is complete when the slowdown follows one measurable condition—cache exhaustion, SMR cleanup, file mix, heat, USB retries, or low reusable space—and the corrected path sustains the expected steady-state rate.
Frequently Asked Questions
Does a slowdown after 50GB prove the drive has a 50GB cache?
No. The threshold can also reflect elapsed time, temperature, file mix, free-space pressure, or internal cleanup. Repeat with different data shapes before estimating cache size.
Why does pausing the backup temporarily restore speed?
The pause may allow an SSD to fold cached data, an SMR disk to reorganize writes, an enclosure to cool, or the USB transport to recover. Temperature and latency logs are needed to separate them.
Should I judge backup performance by the initial speed?
No. Capacity planning should use the stable rate after caches fill and the workload reaches its normal mix of data, metadata, verification, and retention work.
Support & Tips
More to Read

Can Plex Share a GPU With Another Docker Container?
Plex and another container can often access the same GPU, but you must test driver support, device mapping, video-engine load, memory, and recovery behavior.

How to Tell Whether a Plex Error Comes From the Client or Server
Reproduce the same item on another client, compare the session path, then collect server evidence only after scope tells you where the failure actually...

How to Configure Plex Cache and Transcode Temporary Storage
Protect persistent Plex state while placing transcode temp files on suitable local storage, then verify cleanup, free space, and restart behavior.

