NAS
QNAP HBS 3 backup destination permissions
HBS 3 (Hybrid Backup Sync 3) is QNAP's backup tool. The wizard makes it easy to point a backup at a cloud bucket or remote NAS — and easy to misconfigure in ways that mean a compromised QNAP can also corrupt or delete the backup. The right destination configuration treats the backup like an immutable archive: separate credentials, separate retention, separate auth scope.
Best for: QNAP operators setting up HBS 3 backup destinations for the first time, or auditing existing destinations for the credential-isolation patterns that limit blast radius.
Why backup-destination credentials matter (the ransomware lesson)
- Ransomware events on QNAP NAS devices have historically included the backup destinations — attackers who land on the QNAP also enumerate any reachable backup target and encrypt/delete the backup there too.
- The protection is **credential separation**: HBS 3 connects to the destination with a dedicated account that has write-but-not-delete-old permissions, OR the destination itself enforces versioned/immutable writes via lifecycle rules.
- Goal: a compromised QNAP can add new backup data to the destination but cannot delete or modify existing backups, and an attacker can't pivot from the QNAP into the backup account.
Cloud destination — credential and bucket-policy setup
- Create a dedicated cloud account/keypair for HBS 3 — NOT the same root credentials you use for the cloud console. For S3-compatible: an IAM user with a programmatic-only access key. For Backblaze B2: a separate application key scoped to a specific bucket. For Google Drive: a service account in a project dedicated to backups.
- Restrict the keypair's permissions to write + list on the backup bucket. **Deny delete and overwrite** at the bucket-policy level. This is the credential-separation protection.
- Enable bucket-level versioning so even an authorized delete leaves recoverable previous versions. On S3: bucket Properties > Bucket Versioning > Enable. On B2: bucket settings > File Lock or lifecycle rule.
- Set lifecycle rules to age old versions out after a retention window (e.g., 90 days of versions). Without this, versioning grows unbounded.
- Encryption: HBS 3 supports client-side encryption with a passphrase + salt. Enable it; store the passphrase in a password manager that itself has an offsite copy. **Without the passphrase, the backup is unrecoverable.**
Remote NAS destination — SSH key and rsync mode
- Generate a dedicated SSH key on the QNAP for HBS 3 backup use: Control Panel > Network & File Services > SSH > generate (or via the OS terminal).
- On the remote NAS (destination), add only this SSH key to the destination's authorized_keys. Restrict the key's `command=` to the specific rsync receive path; the QNAP can write to the backup destination but cannot run arbitrary commands on the remote NAS.
- Use rsync with `--link-dest` to create snapshot-style incremental backups on the destination — each backup is a directory of hardlinks to unchanged files plus copies of changed files. Looks like a full backup, takes minimal space.
- Destination filesystem should support versioning OR have separate ZFS / btrfs snapshots that the QNAP SSH key cannot modify. If the destination is another QNAP, configure Snapshot Vault on the destination with retention longer than HBS 3 source retention.
Retention strategy
- HBS 3 supports two retention models: Smart Versioning (default — hourly/daily/weekly mix with automatic pruning) and Custom Versioning (specify exact retention per version tier).
- Smart Versioning typical: 24 hourly + 7 daily + 4 weekly + 12 monthly. Enough granularity to recover from accidental changes; capped storage growth.
- Set the retention policy at the HBS 3 job level AND at the destination level (bucket lifecycle for cloud, dataset retention for remote NAS). Two layers of retention = a misconfiguration on one side doesn't lose everything.
- Calculate destination capacity: daily change rate × retention days = approximate storage need. For most home QNAPs, 1-3× source data size is a reasonable destination capacity target.
Verification — the part that proves it works
- After the first HBS 3 job completes, restore a known file to a temp folder: HBS 3 > Restore > pick the job > pick a file > restore to alternate location. Open the file; confirm content.
- Test the encryption-passphrase recovery path: re-enter the passphrase from your password manager into HBS 3 on a NEW or RESET QNAP setup, point at the same destination, and confirm browse + restore works. The disaster moment is the wrong time to learn the passphrase storage is gone.
- Run monthly restore drills (calendar reminder). Pick a different file each month so you exercise different paths.
- Watch HBS 3 > Job Status for failed runs — automatic notifications via Control Panel > Notification Center should route to email or app push, so a quietly-broken backup chain doesn't go unnoticed.
Destination credentials are dedicated (not main cloud-console root).
Cloud console > IAM (S3) or Application Keys (B2) > New > assign minimum permissions (PutObject + ListBucket + GetObject) > deny DeleteObject > save key
Cloud console > IAM / Application Keys shows a dedicated keypair for HBS 3 with scoped permissions.
Stop before assuming 'it works' = 'it's safe' — incident reports show the difference matters.
Layer path
Step-by-step runbook
Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.
Generate dedicated destination credentials with scoped permissions
Check: Cloud console > new IAM user / application key with PutObject + ListBucket + GetObject; explicit Deny on DeleteObject. Or for remote NAS: dedicated SSH key with restricted command/path.
Expected result: Dedicated credential exists; main cloud-console root credentials are not used by HBS 3.
If not: Sharing credentials means one compromise = total exposure.
Enable destination versioning + lifecycle rules
Check: Bucket Properties > Versioning > Enable. Lifecycle > expire previous versions after retention window (e.g., 90 days).
Expected result: Versioning enabled; lifecycle rule set.
If not: Without versioning, even authorized deletes are irreversible.
Set up encryption passphrase storage
Check: Password manager entry for HBS 3 encryption passphrase + salt. Confirm password manager itself has an offsite copy (paper safe, second device).
Expected result: Passphrase storage exists with redundancy.
If not: Skipping this step means losing the passphrase loses the backup — and password managers can fail / be locked out.
Configure HBS 3 job with the scoped credential
Check: HBS 3 > Backup > Create > source folders (irreplaceable only) > destination using new credential > encryption enabled > Smart Versioning retention > schedule daily off-peak.
Expected result: Job appears in HBS 3 list.
If not: Don't include multimedia caches or downloads in the source.
Run the first backup manually and verify completion
Check: HBS 3 > Job Status > the job > Run Now. Wait for completion.
Expected result: Status Success; Bytes Transferred matches expected.
If not: If failure: check log; resolve destination/auth/source issue; re-run.
Test restore to prove restorability
Check: HBS 3 > Restore > the job > a small known file > Restore to alternate location. Open the file.
Expected result: Restored file opens; content matches.
If not: If restore fails, the backup chain is broken — fix before relying on it.
Schedule recurring restore drill + monitor failed runs
Check: Calendar reminder monthly for restore drill. Notification Center > route HBS 3 job failures to email/push.
Expected result: Recurring drill scheduled; failure alerts route to you.
If not: Without monitoring, broken backups go unnoticed until needed.
Decision tree
If: Cloud destination — S3-compatible (Backblaze B2 / S3 / Wasabi).
Then: Versioning + lifecycle + delete-denied credential is the strongest configuration.
Action: Bucket > Versioning ON > Lifecycle rule (e.g., expire previous versions after 90 days) > IAM keypair with PutObject but no DeleteObject permission.
If: Remote NAS destination (rsync to another QNAP or generic Linux host).
Then: Use rsync with `--link-dest` (hardlink-based incremental snapshots) and a destination-side filesystem that snapshots independently.
Action: SSH key restricted to specific rsync receive path on destination; destination has its own ZFS / btrfs / Snapshot Vault retention.
If: USB drive destination.
Then: Physical separation provides air-gap when unplugged.
Action: Encrypt the USB drive (HBS 3 client-side encryption); rotate two USB drives weekly with one always offsite (neighbor / work).
If: Already configured HBS 3 with main cloud credentials.
Then: Audit before continuing.
Action: Rotate credentials to a dedicated keypair; apply bucket policy; verify with attempted unauthorized action.
Safe stop: Stop before assuming 'it works' = 'it's safe' — incident reports show the difference matters.
If: Source data includes encrypted application data (databases, encrypted shares).
Then: HBS 3 captures the encrypted state; restoring without app-side keys = encrypted data.
Action: Stop databases or use app-native consistent-snapshot tools before HBS 3 backup of those datasets.
Evidence table
| Symptom | Evidence to collect | Likely layer | Next action |
|---|---|---|---|
| HBS 3 backup job uses same credentials as main cloud console root. | HBS 3 > job > destination credentials. | Credential scope too broad | Generate dedicated keypair; restrict scope; rotate. |
| Bucket lifecycle rule missing — versioning enabled but old versions never expire. | Cloud console > bucket > Management / Lifecycle. | Unbounded storage growth | Set lifecycle rule to expire previous versions after retention window (e.g., 90 days). |
| First restore attempt fails with permission error. | HBS 3 > Restore > error log. | Restore-direction credentials missing or scoped wrong | Credential needs read access in addition to write for restore; verify policy includes GetObject / ListBucket. |
| HBS 3 job log shows successful backup but file count keeps growing on destination over weeks. | Bucket size in cloud provider console. | COPY mode without lifecycle pruning | Confirm Smart Versioning or Custom Versioning policy is set at job level; add lifecycle rule at bucket level as second layer. |
Commands and settings paths
Generate dedicated cloud credentials with scoped permissions
Cloud console > IAM (S3) or Application Keys (B2) > New > assign minimum permissions (PutObject + ListBucket + GetObject) > deny DeleteObject > save key
Where: In the cloud provider's console (not on the QNAP).
Expected: New keypair has scoped permissions; main cloud console root credentials are unchanged and not used for HBS 3.
Failure means: Test the new key by attempting a delete (should be denied) and a put (should succeed).
Safe next step: Replace credentials in HBS 3 with the new keypair; revoke any older keys.
Enable bucket versioning
S3: Bucket > Properties > Bucket Versioning > Enable. B2: Bucket settings > Object Lock or default-retention.
Where: In the cloud provider's console.
Expected: Versioning shows Enabled in bucket properties.
Failure means: Without versioning, any delete is unrecoverable.
Safe next step: Add lifecycle rule to expire previous versions after retention window.
Configure HBS 3 backup job with encryption
HBS 3 > Backup > Create > source folders > destination credentials (the scoped keypair) > Encryption enabled > strong passphrase + salt > schedule > Save
Where: In HBS 3 (via QTS Main Menu).
Expected: Job appears in list with the schedule.
Failure means: Passphrase + salt must be stored before completing the wizard.
Safe next step: Stop before completing if passphrase storage isn't ready.
First-restore verification
HBS 3 > Restore > the job > pick a small file > Restore to alternate location > open and verify content
Where: In HBS 3.
Expected: Restored file opens with matching content; encryption passphrase unlocks successfully.
Failure means: If restore fails, the backup isn't real yet.
Safe next step: Practice this monthly via calendar reminder; the disaster moment is the wrong time to learn the passphrase storage rotted.
Hardware and platform boundary
Change only when
- A second backup destination (tier-2: e.g., a different cloud provider or remote NAS) is the right next investment only after monthly drills are clean on the first destination for at least three months.
Evidence that matters
- Credential isolation, destination versioning + lifecycle, encryption passphrase storage durability, and restore-drill cadence matter most.
Evidence that does not matter
- Faster QNAP hardware doesn't speed up cloud backup — upstream bandwidth is the bottleneck.
Avoid
- Avoid sharing credentials with QNAP admin or cloud-console root, skipping versioning, unencrypted destinations, or treating successful backups as restorable without proof.
Last reviewed
2026-05-18 · Reviewed by HomeTechOps. Reviewed against QNAP's HBS 3 Hybrid Backup Sync documentation, the QNAP security best-practices article (which explicitly addresses backup-credential separation post-ransomware-incidents), and NIST's conservative-backup framing for credential-isolation and recovery-key custody.
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.