Hybrid Backup Sync 3 (HBS 3) is the central backup app on QTS and QuTS hero — it combines backup, restore and sync in one interface and can address any S3-compatible object storage as a cloud target. That is exactly where intercolo i3 fits in: S3-compatible, strong read-after-write, reached via the server address de-fra.i3storage.com in region de-fra. This gives your QNAP a real offsite copy under 3-2-1 — no second NAS at another site, no tape drive and no hyperscaler egress surprises. At 99.999999% durability, with data that never leaves the Frankfurt facility: German operator, GDPR/DPA under Art. 28, no access under the US CLOUD Act.
In the QTS/QuTS hero App Center open Hybrid Backup Sync and go to Storage Space (Create Storage Space) → Create → Cloud Storage. This defines the cloud target you then use in backup or sync jobs.
Choose NOT the native Amazon S3 entry, but S3 Compatible. Only that type allows a custom server address — the prerequisite for pointing at intercolo i3 instead of AWS.
Server address: de-fra.i3storage.com · Region: de-fra. Keep SSL/TLS enabled (the certificate is valid). Addressing: path-style reaches the bucket as de-fra.i3storage.com/<bucket>, virtual-hosted as <bucket>.de-fra.i3storage.com — both work; when in doubt pick path-style.
Enter the Access Key + Secret Key from your intercolo API-key pair; access runs exclusively through these SigV4 keys, no password login. Select an existing bucket or pre-create one via aws-cli/rclone.
Under Backup → New Backup Job set local NAS folders as the source and the i3 target you just created as the destination. Define schedule and version management (retention) in the job — HBS 3 controls both app-side, not the storage.
Path-style: https://de-fra.i3storage.com/qnap-backup · Virtual-hosted: https://qnap-backup.de-fra.i3storage.com. Both work; for aws-cli/rclone, --endpoint-url https://de-fra.i3storage.com with region de-fra is enough.
The QuDedup Engine deduplicates client-side right on your QNAP: HBS 3 splits the source data into blocks, spots duplicates before transfer and uploads only unique, compressed blocks to object storage (.qdff format). That saves twice — first less occupied storage, because redundancies are never uploaded, and second less egress on restore, because retrieval is deduplicated and compressed too. Compute load and key control stay on the NAS; the storage holds compact blocks instead of raw files. Especially with many similar files or recurring full backups this lowers cost noticeably.
The right job type for the offsite copy: HBS 3 writes versioned restore points in QuDedup format, with retention rules and a schedule. That is exactly what belongs in the Frankfurt object storage as the 3rd copy under 3-2-1.
One-way or two-way sync mirrors the current file state without version history. Good for data exchange and distribution — but sync alone is not a backup: deletions or ransomware encryption would be mirrored along.
When a backup runs is set by HBS 3 — hourly, daily or as continuous backup. The storage merely accepts the objects; the cadence is purely an app matter on your QNAP.
How many versions are kept and for how long is controlled by HBS 3 version management (smart versioning / version rules) — NOT storage-side S3 versioning. Retention is exactly what you configure in the job.
To set expectations clearly: i3 Object Storage provides NO storage-side immutability (no Object Lock/WORM, no storage-side versioning). Protection here comes from two other layers. First, spatial separation under 3-2-1: local QNAP snapshots as a fast first line, plus this independent offsite copy in Frankfurt — together with HBS 3 retention that deliberately keeps older versions. Second, confidentiality through client-side encryption: enable encryption in the HBS 3 job and the QNAP encrypts the data with AES BEFORE upload. The storage then holds only unreadable ciphertext, transport is additionally secured by TLS and the key never leaves your NAS — no provider, us included, can read the backups. Store the password safely: no key, no restore.
The most expensive backup mistake is the untested restore. At US hyperscalers every retrieval test costs egress fees, so people test too rarely. Here 1 TB of egress is included per booked TB of storage — you pull individual files or whole folders back from Frankfurt regularly and validate your recovery chain without the next invoice exploding. Because QuDedup deduplicates retrieval too, real traffic is often far below the raw data size. Extra egress is billed transparently at +€3.99/TB — predictable, not surprising: you know what a test costs before you run it.
| Wasabi | Backblaze B2 | intercolo i3 | |
|---|---|---|---|
| Location / data residency | EU region selectable, US corporation | EU region selectable, US corporation | Frankfurt DC, 100% DE, GDPR/DPA |
| Server address | s3.eu-central-*.wasabisys.com | s3.eu-central-*.backblazeb2.com | de-fra.i3storage.com (de-fra) |
| Egress model | 'free' up to storage limit, then throttled | 1 TB free/day, then per GB | 1 TB incl./TB, then +€3.99/TB |
| Starting storage price | List price US$/TB | List price US$/TB | €2.49/TB |
| Storage immutability | Object Lock available | Object Lock available | No — offsite copy in 3-2-1 |
| Support / contact | Ticket, EN | Ticket, EN | Direct, German, DC team |
| Power | varies | varies | 100% green power |
For clean operations, separate tasks via dedicated buckets and dedicated API key pairs rather than bucket policies or ACLs. An SMB might create one bucket with its own SigV4 key per site or per retention class (operational backup vs. long-term); a compromised or replaced key can then be rotated in isolation without touching the other backups. In a homelab one bucket per NAS is often enough — what matters stays the same: the access/secret key belongs only on the NAS, and presigned URLs or a second key pair serve targeted, temporary access. That keeps the blast radius of a single key small and every backup chain cleanly attributable.
Kokemuksemme puhuu puolestaan: olemme onnistuneesti suorittaneet siirtoja, joissa on ollut useita petatavuja dataa ja yli 500 miljoonaa tiedostoa.