My NAS backups were destroying Plex performance until I moved them to 3 AM

Published Oct 2, 2026, 10:00 AM EDT Korbin is a Linux system administrator who spends most of his time in a terminal figuring out how things actually work. Over the last decade he's written hundreds of articles about Linux configuration, troubleshooting weird problems, and using open-source tools in the real world. He also works a lot with Windows systems and networking, especially in mixed environments where things don't always behave the way the documentation says they should. Writing things down is how he makes sense of it all and hopefully saves someone else a few hours. I've tweaked my backup configuration countless times over the years, but the overall strategy has always been the same: a nightly transfer of important files to a second hard drive and an offsite VPS. That satisfies the 3-2-1 backup rule perfectly, and has protected my files through numerous device failures. The part that I never gave much thought to was the timing. As long as an automated backup job was kicking off every night, I felt that everything was implemented correctly and working smoothly. And it was, for the most part, but my NAS stays busy with a lot of other tasks, and when any of them coincided with an ongoing backup, everything ran worse. My backups were bogging down everything Too many processes competing for the same uplink I started getting messages from friends saying that Plex was buffering or that the catalog would load slowly. That sort of complaint usually ends up being because of their own Internet, plus there's been a handful of Plex hiccups that I've sorted out. There was one week that was different, though, where I received numerous messages from different people. My first clue about the source of the problem was that the messages would all come in around the same time on different nights. All of the messages lined up with my backup window, but it took me a while to realize that it was the cause. The complaints were always on and off, because usually my server simply doesn't have much to back up, so it keeps the line clear for other data. My backups are incremental, so only new and changed files get copied over. Even without much to transfer, having rsync scan millions of files on my storage pool to check for changes isn't exactly ideal during something as intensive as transcoding and streaming. Everything was technically working as expected. It's just that I had three demanding jobs running during the hours that people were actively using the server. Once I compared the timestamps of the reports with my cron schedule, the culprit was pretty obvious. It's honestly a little embarrassing that it took me a while to notice, but hindsight is 20/20. A better schedule fixed the performance issues Nobody's awake at 3 AM to notice a slow disk The fix was a simple crontab edit: I configured my backup and scrub for times when nobody would need the NAS. I pushed the local sync to 3 AM, and moved the off-site sync to an hour after. That way, the two tasks won't fight each other. I also changed my monthly scrub to an early Saturday morning when nobody should be touching the server, at least not for anything beyond some light file access. Here's what the crontab looks like now: 0 3 * * * /mnt/scripts/local-sync.sh 0 4 * * * /mnt/scripts/offsite-sync.sh 0 1 * * 6 zpool scrub tank It's such an easy fix, but the difference showed up immediately. I still haven't received any new text messages about Plex not loading when the server gets its usual evening traffic surge. The backups run faster, too, since they're running when the server is quiet, and nobody else is using my home's connection. The only thing I need to do is review logs every morning to make sure my backups and snapshots are still good. At least I don't need to fruitlessly troubleshoot Plex anymore. An automated backup has its own caveats Here's how I make it work There are two things to keep in mind with automated daily/nightly backups. Backing up once every 24 hours means that there's a whole day's worth of changes to sync. For files that undergo lots of important incremental changes, that may not be often enough. The other caveat is that automated backups don't give you a chance to sign off on what changes get synced. My rsync scripts will attempt to run no matter what, even if there's a problem that I haven't caught yet. My website's codebase receives a lot of small updates, especially now that I have AI writing a large portion of it. I've needed to restore sections from backup a few times when things went awry in production. But for situations like that, version control systems like Git work far better. It's exactly what they're meant for, too. Restoring from a full backup, even a snapshot, doesn't have all the changelog data, either. If you have a codebase to maintain, once-a-day backups aren't the most ideal way to keep it safe. As for confirming backup integrity, that's what my morning reviews are for. Automated backups can be problematic because even unintended changes are synced. If some files were erroneously deleted before the sync, they're now deleted from the backup destination as well. During my review of the log files, I can see what changes rsync made, and if anything is off, I can restore lost files from the most recent snapshot. Backup timing is worth thinking about Backups are more of a background activity than anything else. You don't really need to monitor them (although reviewing them after completion is recommended), and they can be automated to run at any time. Once I realized the impact an active backup has on other concurrent tasks, I shifted them to off-peak hours, which was a simple fix for a problem that had confused me for months.