For a very long time, I thought that I had nailed my backup setup. My NAS was doing everything — or at least I thought it was. Every night, I would see the green checkmark indicating that the backup had been completed successfully, and I’d go to bed worry-free. That irony hit me hard after a reckless spree.

My backup setup had all the logical pieces in place, including device copies, periodic syncs, and offsite backup for extra redundancy. It felt bulletproof, so I overlooked misconfigurations and occasional errors out of sheer laziness, making my NAS setup increasingly unreliable. When I finally noticed the gap, a couple of months had already gone by since the last usable backup.

This is about what all went wrong in my setup, and what I wish I had paid more attention to a bit earlier.

The ‘everything’s alright’ illusion

Frequent checks are the key

I think a lot of first-time NAS users make this mistake — I got too focused on coverage rather than nuance, wanting to back up every single file on my devices, from photos to project folders. I set up a lot of backup and sync tasks with Hyper Backup and Synology Drive on my NAS for nightly backups. It was set to smart versioning, and I assumed I was sorted for good.

In doing so, and trusting the automated processes that the NAS smartly handles, I didn’t bother double-checking whether my shared folders were mapped correctly or how the external drives were mounting following reboots. These gaps I left early on became the ghosts of the past that began bothering me later in my NAS’s life.

But things were far from alright underneath

The first red flag came after a small power outage that made the NAS restart without warning. The reboot happened alright, but I noticed that the backup task didn’t run that night. I shrugged it off, thinking it was maybe just delayed, nothing else. What I failed to notice was that the external drive I had connected failed to remount ever since that outage. The backup destination path was no longer valid, and the backups failed for a good week or two.

Sometime later, I also made the mistake of running multiple backup tasks with overlapping schedules. One was uploading to the cloud storage after midnight, while another was writing to an external drive at the same time. Both were trying to compress and move a lot of data at once, putting a severe load on the CPU and I/O. This resulted in a bunch of incomplete versions and even corrupted archives, even though the NAS showed both tasks as completed. Thankfully, it wasn’t too late when I noticed — it would’ve been a big tragedy if I ever needed to restore those files and learned about these corrupted backups in that moment.

Another thing that comes to my mind is the problem I had with versioning. My data retention policy was set to keep smart versions, as I mentioned earlier, assuming it meant as many as needed. How it worked in reality was a far cry from that. The system only kept a few recent versions and routinely deleted older copies, and the schedule didn’t meet my needs. I found out when I was trying to restore an older copy of a folder and realized that the version was gone.

The fixes that made things reliable

Every single one of those issues was avoidable

Once I figured out what had gone wrong, I stopped treating backups as a checkbox and started treating them as a system that needs constant maintenance, like a car.

The first step was simple: I separated everything. Each destination, including local, external, and cloud, got its own independent job with clear schedules that didn’t overlap. That instantly eliminated the problem with resource conflict.

Then I took on the permissions mess. Instead of relying on the admin account for everything, I created a dedicated backup user with read access to every shared folder. This way, no matter who creates a file, the backup process can still read it, also making it easier to audit which account changed what.

Next came power and mounting. I configured the external drive to auto-mount with the same path every time and added a short delay to the backup task after startup. That ensured it never ran before the drive was ready. Connecting the NAS to a small UPS for power backup has also helped reduce the chances of such failures.

Versioning took a bit more thought since I wanted to create custom versioning with a simpler rotation — monthly stays for a year, weekly for a month, and daily for a week. This is more practical for me and works in my case, but you can choose to go with whatever works best for you.

With that, I’ve also started periodically testing restores every few weeks to ensure everything is running smoothly. It could just be a random folder that I try restoring to a temporary location.

Things I wish I’d noticed sooner

The writing was always on the wall

Looking back, the signs were always there. Those warning signs in Hyper Backup that I never opened, and the missing external drive in File Station that I ignored thinking it would mount on the next reboot, were things I should have checked, even if they turned out to be nothing. Neither the NAS nor the software had failed; it was a failure of attention — assuming that automation meant reliability without checks.

If you use a NAS at home, it’s easy to assume that you’re protected just because you’ve set up redundancy and a backup system with solid schedules. But if you’re new to NAS, you should expect to run into a bunch of issues as I did and find your quick ways around them. Simple.