Been setting up a QNAP NAS as the local layer of a 3-2-1 backup strategy for a small business, and wanted to share what’s worked well so far — and get feedback from others who’ve done the same.
What’s working:
Using Hybrid Backup Sync (HBS) to replicate NAS snapshots to an offsite/cloud target, so the NAS isn’t the only copy
Scheduling snapshots frequently enough to keep RPO tight, without overloading storage with redundant versions
Enabling immutable snapshots where possible, specifically to reduce the risk of ransomware reaching the backup layer if the main network gets compromised
Where I’m less sure:
Best snapshot retention schedule for balancing storage costs vs. recovery flexibility (anyone have a solid rule of thumb here?)
Whether QuDedup is worth enabling for mixed file types, or if it’s better suited to specific workloads
How others are handling restore testing on a QNAP setup without disrupting production — is anyone doing scheduled test restores, or is it more ad hoc?
Curious how others here have configured their QNAP boxes for this kind of layered backup approach, especially anyone supporting client environments rather than personal/home use (we do managed backup and DR work for businesses in the UAE at
The best and probably only protection against this is redundant offline backups that are physically disconnected from the (inter-)net. Anything accessible online can and will be hijacked.
I’m assuming you are using QuTS Hero 6 since you are talking about immutable snapshots. Those certainly are great at protecting against ransomeware, but this alone aren’t really enough. I assume immutable snapshots can be vaulted to another NAS but are they immutable on that NAS as well and does that NAS need to be running Hero 6? That I don’t know. I haven’t made the leap to Hero 6 yet.
So IMO, here’s is what you need:
1.) Full backup of your NAS to a secondary NAS on your LAN
2.) Full backup of your NAS to a cloud provider
3.) Second cloud based backup of your most critical data (I say this as a full backup of many TB can get expensive for multiple copies. Many times the most critical data is much smaller.
4.) Snapshots taken regularly on your NAS (you decide what is immutable and what isn’t). Snapshots aren’t all that stellar as a “backup” mechanism. What they are really good for is accidental file deletion or corruption.
5.) Vaulted snapshots to a second NAS.
6.) Most valuable data stored on an external drive - ask as @UdoA suggested - a drive that is completely removed from the NAS. So really a couple of external drives that are rotated.
What is really unfortunate is that QNAP has yet to provide the ability for the NAS to have a full bare metal backup. Some QNAP related data is rather difficult to backup/extract and if you have to do a restore, you may lose some settings.
You will need to set separate backups for your virtual machines. Yes, backing up the VM files themselves is useful, but it’s easiest to get your VMs up and running if you set up a backup for the VM files from within Virtualization Station.
For Containers, make sure all your container data is mapped to storage locations outside of the “default” QNAP locations. That data is exceptionally hard to backup as QNAP essentially mounts encrypted copies of the data at run time. Saving your data to another location on the NAS will just make your life so much easier. Make sure to save copies of all your YAML code as well. The “details” of the containers again are rather difficult to backup. Container Station does not have a backup option like Virtualization Station. The “details” of each container are stored in QNAP’s database/directories and are nearly impossible to actually backup. I just looked and there’s not even a manual “export” function available.
Other apps like NotesStation store all their data in QNAP databases that are not easily backed up. If you use these, you should regularly export you data from within those apps.
Hi, here are some suggestions for your reference. If you’d like to discuss this further, please send me a private message.
In Snapshot Manager, the Retention Policy gives you three modes — keep for a maximum time, keep a maximum number, or Smart Versioning — and the last one is what answers your “cost vs. recovery options” question directly. Instead of a flat window, Smart Versioning keeps a grandfather-father-son spread: a number of most-recent (general) snapshots plus separate hourly / daily / weekly / monthly buckets, so you get dense recent coverage and a sparse long tail without an unbounded count. The built-in defaults (24 general, 24 hourly, 7 daily, 4 weekly, 12 monthly) are a sensible starting point — raise the weekly/monthly counts for longer recovery reach, lower them if the pool is tight.
QuDedup on mixed data — it comes down to redundancy, not file “type” as such. In gerenral:
Dedupes well: VM/disk images, ISOs, many near-identical documents, repeated full backups.
Dedupes poorly: already-compressed or unique media — photos, video, MP3, ZIP/RAR, encrypted files.
Note: deduplicated backups are packaged (.qdff) and are read back via HBS
or the QuDedup Extract Tool, and restores from deduplicated data can run slower than the original backup did. https://www.qnap.com/en/how-to/faq/con_show.php?cid=1014
Restore an HBS backup to an alternate destination. Point a test restore at a different NAS. Doing this on a schedule is the practical way to prove the copies actually restore, not just that the job runs.
On the offline point others raised: Airgap+ isolates the backup destination by controlling its switch/router port, so the target is only reachable during the backup window.
