The idea of an off-site backup is pretty simple. Your main NAS sits on-premise and is susceptible to a variety of external threats and physical damage, which can potentially lead to data loss. That’s exactly where an off-site backup comes into play. It creates an additional copy of your data away from the main NAS, allowing you to retrieve it in cases where your primary NAS is affected by something like a flood or a cyclone. This is critical, especially for businesses where customer data is extremely important.

While it’s important to set up an off-site backup whenever you get a new NAS in the first place, it’s even more important to test it initially and then do so regularly to ensure backup integrity and basic backup hygiene. I, for one, did only one of those two things and honestly regretted it later — and I’ll tell you exactly how it went.

I thought my off-site backup was 'done'

Surprise, surprise: it wasn’t

During my early days with the NAS, I had a lot on my mind to set up, including a bunch of apps, the settings I wanted, and the features I wanted to exclude. Off-site backup was one of those things because I knew I needed a safety net to keep my data safe and secure. Like everything else, I set it up, crossed it off my list, and moved on. I had configured it and completely forgotten about it for a good few weeks.

I genuinely believed it would now work on its own without any problems or requiring my intervention for a very long time. I wanted it to be a set-it-and-forget-it setup that didn’t bother me much. And all the green checkmarks showing the correct status only reinforced the idea that everything was working fine. In my head, all my photos, documents, and work files were stored somewhere safe and could be restored whenever I needed. Thankfully, I realised fairly quickly that this wasn’t the case.

A restore job that didn’t go well

That was a big moment of realisation

As I mentioned earlier, there were no signs that anything was failing or that my data was at risk. But out of curiosity, I decided to try a restore job while I was reorganising some of my data and moving it between two NAS devices. It wasn’t something I needed to do. I hadn’t seen any backups fail, and the logs were clean. I just wanted to test it once.

When I tried restoring a small set of files, I noticed something strange. Once the restore process completed, there were no obvious errors, but the results weren’t quite right. Some folders were missing, some had missing files, and others had file structures that weren’t what I expected. The permissions didn’t match either.

My first instinct was that I was at fault, that I hadn’t set things up properly or had selected the wrong snapshot. I ran another restore session, but the results were the same. I even cross-checked the original files, and everything there was exactly as it should have been. It became clear that this was simply a bad off-site backup job that I hadn’t tested before putting it into use.

I’m just glad it happened on a normal day

My data is thankfully still safe from disaster

Had this happened during a real emergency, the experience would have been very different. I would have been stressed and scrambling to restore missing files and fix broken folder structures. Instead, this restore test helped me discover the limits of my backup when I could afford to, and it gave me the time to make the necessary changes so that the restore job would work properly going forward.

Fixing the restore wasn’t about throwing more hardware at the problem and calling it a day. It was a much more deliberate backup process once I understood the reality. Earlier, the backup chain was fairly complex, so the first step was simplifying it so both the system and I could clearly understand what was going on. I cleaned up permissions and paths that I had previously taken for granted, and this time, things went much more smoothly.

More importantly, I tested the restore again before finally trusting it in production. This, I’ve now realised, is the single most important step.

What I realised

And how you should approach your backups

Even after fixing the restore workflow, some of the data was technically recoverable, but it required far more effort than I had imagined. The failed test also highlighted just how much I had been relying on defaults. After that point, I set up custom schedules, adjusted retention policies, and fixed the things that actually mattered. My backup system was now designed around recovery, which is the entire point of having backups in the first place.

In a solid backup strategy, off-site backup — whether on cloud storage or a second off-premise NAS — is a crucial component. It provides the kind of redundancy that can save large volumes of data in almost any kind of data-loss incident. For both professionals and home users, an off-site backup strategy is a relatively affordable and effective way to keep data safe. Even if you choose the cloud for off-site backups, it should be a core part of your overall backup system, simply to give you real peace of mind.