Skip to main content

QNAP → UNAS Nightly Sync via Hybrid Backup Sync (HBS3)

Audience: T2 / T3 Use when: A site has both a QNAP (file server) and a UniFi UNAS (backup target), and QNAP data needs to be protected. Also use when a client asks to "back up the QNAP" and the only backup platform on site is NinjaOne.

Why This Page Exists

NinjaOne cannot back up a QNAP. NinjaOne image backup requires the NinjaOne agent, which runs on Windows/macOS/Linux only. QTS will not take the agent, so a QNAP can never appear in NinjaOne as a protected device the way a workstation or server does.

When a site has a QNAP holding data and a UNAS acting as the NinjaOne backup target, the QNAP pushes its own data to the UNAS using Hybrid Backup Sync (HBS3) — QNAP's native tool — over SMB.

Options Considered (and why HBS3 direct wins)

Option How it works Verdict
A — HBS3 to a folder on a Windows PC QNAP syncs to a local folder on a PC that already has a NinjaOne image plan; the image plan carries it to NAS + cloud Works, but inflates the PC's image chain on both local and cloud legs, consumes PC disk permanently, and depends on that PC staying awake. Storage cost is hidden as chain growth.
B — NinjaOne file/folder backup pointed at a UNC path A Windows agent backs up the QNAP share as a network source Verify in-tenant before trusting. Some agent configurations silently skip network sources, producing a green job that protects nothing.
C — HBS3 direct to a UNAS SMB share QNAP writes straight to a dedicated share on the UNAS Preferred. One hop, no workstation dependency, data stored once at source size.

Option C is the DTC-preferred pattern.

Offsite gap: Option C leaves both copies in the same building. HBS3 supports multiple destinations in one job set — add a cloud destination (B2/S3) for a real offsite copy. This is new spend outside NinjaOne's included cloud storage and needs sign-off before you configure it. If offsite is declined, document that the QNAP has no offsite protection.

Prerequisites

  • UNAS adopted, merged, RAID pool Fully Operational (see UNAS 2 — Client Deployment SOP, page 3381)
  • UNAS File Services credentials generated and stored in IT Glue
  • QNAP reachable on the same subnet
  • Known QNAP data volume — check Storage & Snapshots → Shared Folder/LUN → Used Capacity before sizing anything

Procedure

Step 1 — Create a dedicated share on the UNAS

UniFi Drive → Shared Folders → New Shared Drive

Setting Value
Name QNAP_Backup (or client-appropriate name)
Storage Pool Storage Pool 1
Snapshot Enabled — daily, retain 14
SMB Trash Disabled
Enforce Storage Limit Set a ceiling based on QNAP data volume
Encrypt Drive Off

Snapshots are mandatory. A one-way sync mirrors deletions. Without snapshots, a bad delete on the QNAP propagates to the UNAS and the copy is gone. Snapshots are the only versioning layer in this design.

SMB Trash off — per NinjaOne Backup — NAS Setup & Best Practices (page 3002), a recycle bin on a backup share is a known cause of silent capacity exhaustion.

Do not reuse the share NinjaOne writes its image backups to. Keep backup-target, user-data, and QNAP-sync shares separate.

Step 2 — Create a non-admin user on the QNAP

Control Panel → Privilege → Users → Create

  • Username: <client>-user (e.g. odental-user)
  • Generated password, stored in IT Glue
  • User Groups: everyone only — not administrators
  • Shared Folder Permission: RW on in-scope shares only
  • Application Privilege: File Station only

Per the Client Credential Administration Standard, never use administrative credentials for share access.

Step 3 — Update and open HBS3

App Center → Hybrid Backup Sync → update if available → Open

Step 4 — Create the sync job

Sync → Create Sync Job → One-way Sync Job

Destination storage space: select Remote CIFS/SMB Server.

Do not select "Remote NAS (RTRR)." RTRR requires QNAP software on the far end. The UNAS does not run it and the job will fail.

Storage space settings:

Field Value
Name <Client> UNAS
IP address UNAS IP
Username UNAS File Services username
Password From IT Glue
Destination folder /QNAP_Backup

Click Test Connection — must return Success before continuing.

Credential note: HBS3 handles SMB scoping internally, so the .\ prefix required when mapping from Windows is not needed here. Enter the bare username.

Step 5 — Name the job and pair folders

  • Job Name: <Client> QNAP → UNAS Nightly Sync (never leave the One-way Sync 1 default)
  • Pair each in-scope source share to its own subfolder under /QNAP_Backup — e.g. FILE SHARE → /QNAP_Backup/FILE SHARE
  • Create destination subfolders using the new-folder icon in the folder picker

Exclude Surveillance Station folders (QVRProAppData, QVRProAutoSnap, QVRProDB, QVRProRecording, QVRProSpace_Vault1):

  • QVRProRecording is video and grows without bound — it will exhaust the destination
  • QVRProDB is a live database; a file-level copy may not restore cleanly
  • Surveillance Station has its own backup mechanism

Step 6 — Schedule

Select Scheduler → + under Schedules → Frequency Daily, Start Time 02:00.

"Inactive hours" is not the schedule. It is a blackout window that prevents syncing during the specified range. Leave it unchecked.

Confirm Configured: 1 before continuing. Offset the start time from the site's NinjaOne image backup window (DTC standard is 12:00 AM) so the two jobs do not contend for the same disk.

Step 7 — Rules

Methods tab — defaults are correct (Enable filters, Exclude symbolic links, Exclude system-generated temp files).

Policies tab → Advanced settings:

Setting Value Why
Remove additional files in destination folder Checked Makes it a true mirror. Without it, deleted source files persist forever and the destination grows unbounded.
Do not take a snapshot Unchecked Let HBS3 snapshot first for a consistent point-in-time copy rather than reading changing files off live disk.
File and folder name character conflict Skip with warning Default

Options tab:

  • Notification trigger: Job fails checked. Leave "Job finishes" and "Real-time sync resumes" unchecked.
  • Error handling defaults are fine (60s timeout, 5 retries, 180s intervals, restart after abnormal termination)

Notifications will not send until a delivery method is configured in the QNAP's Notification Center. Configure it after creating the job, or a failing sync stays silent indefinitely.

Step 8 — Create and verify

  1. Review Summary → Create
  2. Run Sync Now manually
  3. Browse \\<UNAS IP>\QNAP_Backup and confirm folder structure and size match the source
  4. Restore-test one file back to the QNAP
  5. Configure Notification Center delivery method
  6. Document in IT Glue: UNAS IP, share name, QNAP IP, job name, schedule, credential locations

Per NinjaOne Image Backup Plan Configuration Standard (page 1421): the ticket stays open until the restore test is complete and documented. A backup that has never been restore-tested is not a backup.

Known Gotchas

Symptom Cause Fix
Job fails immediately after selecting Remote NAS RTRR selected instead of CIFS/SMB Recreate the storage space using Remote CIFS/SMB Server
Job never runs on schedule "Inactive hours" configured instead of a Schedule entry Uncheck Inactive hours, add a Schedule via +
Destination grows far beyond source size "Remove additional files in destination folder" unchecked Enable it; deleted files were accumulating
Destination fills the UNAS pool QVRPro* folders included in source, or no storage limit set Exclude Surveillance folders; set Enforce Storage Limit
Failures never alerted Notification Center delivery method not configured Configure delivery method on the QNAP
SMB auth fails from a Windows machine (not HBS3) Missing .\ prefix Prefix username with .\; run net use * /delete to clear cached sessions

UniFi Drive Limitations (document as exceptions)

UniFi Drive does not support the per-share, per-user permission model that QTS and DSM provide:

  • Share access is tied to the default UI.com account; UniFi Identity requires a unique UI.com email per user, so a second user on the DTC email will fail
  • No per-share ACLs
  • Access is effectively Owner/All Admins

This is a documented deviation from the dtcbackup least-privilege standard in page 3002 and the Client Credential Administration Standard. The QNAP side can and must meet the standard (Step 2). Note the UNAS exception in client documentation rather than treating it as an oversight.

A possible workaround — provisioning a client-specific UI.com identity so a dedicated non-admin UniFi user can be created — has not been validated. Test before relying on it.

Back to top