Synology to Wasabi Backup: AU$630/Yr vs Backblaze [2026] | #hacking | #cybersecurity | #infosec | #comptia | #pentest | #ransomware

Synology’s Hyper Backup app has shipped a native Wasabi target for years, but the deal the two companies struck in February 2026 changed the calculus for Australian NAS owners. Synology and Wasabi now market the pairing as a joint “integrated cloud backup” answer to ransomware, and the pricing behind it (Wasabi’s pay-as-you-go tier moved to US$7.99 per TB per month on July 1, 2026) makes offsite backup for a home lab or small office cheaper than most people expect. This tutorial walks through the entire setup on a current DSM 7.x Synology NAS, from creating a Wasabi bucket to scheduling immutable, versioned backups that survive a ransomware attack on the NAS itself.

If you already run Backblaze B2 or a Synology C2 subscription, you’ll find the steps below transferable, but Wasabi’s zero-egress-fee model is worth the switch for anyone who expects to actually restore data one day rather than just store it. We’ll cover prerequisites, bucket and access key setup, Hyper Backup configuration, retention and ransomware-resilience settings, cost modelling in AUD, and a full troubleshooting section for when the sync task fails, stalls, or throws an access-denied error.

What You Need Before You Start

This build assumes a real Synology NAS running a current DSM release, an active internet connection with enough upload headroom to push your data offsite, and a card that can be billed in USD (Wasabi bills in USD, so factor exchange rate movement into your AUD budgeting). Here’s the exact software and account list:

• A Synology NAS running DSM 7.x (DS925+, DS1825+, DS224+ and similar current models all qualify; anything on DSM 6.2 or later can install Hyper Backup, but DSM 7.x is recommended for the current AES-256 encryption options)
• Hyper Backup version 4.2.1-4228 or later, installed via Package Center (this is the release Synology shipped on March 25, 2026, and it’s the version this guide’s menu paths match)
• A free Wasabi account created at wasabi.com, upgraded to a paid pay-as-you-go plan before you start a production backup (the 30-day free trial caps storage and isn’t meant for real workloads)
• Admin access to your Synology NAS’s DSM control panel
• An estimate of how much data you’re backing up, in TB, so you can pick the closest Wasabi region and forecast monthly cost
• About 60–90 minutes for first-time setup, plus however long the initial full backup takes to upload (this depends entirely on your upload speed — a 2TB initial backup on a 50Mbps NBN upload link can take three to four days running in the background)

You do not need a static IP, a VPN, or port forwarding for any of this. Hyper Backup pushes data out to Wasabi over standard HTTPS; nothing needs to be exposed on your router.

Step 1: Understand Why Wasabi (and Not Just Any S3 Bucket)

Before touching DSM, it’s worth understanding what makes Wasabi different from a plain AWS S3 bucket or Backblaze B2, because the pricing model changes how you should configure retention later. Wasabi’s headline feature is that it charges no egress fees and no API request fees — you pay a flat per-TB monthly rate and nothing else, regardless of how often you restore data or how many API calls Hyper Backup makes during a sync. That matters specifically for backup workloads, where the expensive moment isn’t the nightly incremental upload, it’s the day you need to pull an entire dataset back down after a drive failure or a ransomware event.

Compare that to Backblaze B2, which is cheaper per TB stored but bills for egress once you cross its free download allowance, and to Synology’s own C2 Storage, which bundles Hyper Backup integration natively but at a higher effective TB rate. A cost comparison published by an Australian NAS review site in mid-2026 put a 5TB backup with one full restore per year at roughly AU$630 annually on Wasabi, versus around AU$735 on Backblaze B2 (including egress) and AU$708 on Synology C2. The gap isn’t dramatic, but it compounds as your dataset grows past 10TB, and it’s the restore-cost predictability that most home-lab and SMB users actually care about after living through a scare.

There’s also a structural reason this pairing works well specifically for Synology hardware. Hyper Backup already handles block-level deduplication, versioning, and client-side encryption before anything leaves the NAS, so Wasabi doesn’t need to offer any of those features itself — it just needs to be a durable, S3-compatible bucket that stores whatever ciphertext Hyper Backup sends it. That division of labour is why the February 2026 partnership announcement focused on pricing and support integration rather than new technical features: the technical groundwork already existed on both sides, Synology through Hyper Backup and Wasabi through its S3-compatible API, and the deal mostly formalised a relationship that motivated users had already been building manually for a couple of years.

Step 2: Create Your Wasabi Account and Choose a Region

Sign up at wasabi.com and select a plan. For Australian users, region choice is the single setting most guides get wrong. Wasabi doesn’t currently operate a data centre inside Australia, so the practical choice is the nearest APAC point of presence, typically Singapore (ap-southeast-1). Latency from Sydney or Melbourne to Singapore is low enough that it doesn’t meaningfully slow a scheduled overnight backup, and it avoids the much higher latency of routing to a US region.

Once your account is active:

1. Log in to console.wasabisys.com
2. Click Buckets in the left sidebar, then Create Bucket
3. Give it a globally unique name (bucket names are shared across all Wasabi customers, so something like yourdomain-nas-backup-2026 avoids collisions)
4. Select your region — for most Australian users, the Singapore or a general APAC endpoint will give the best latency
5. Leave versioning and object lock settings at default for now; we’ll revisit object lock in the ransomware-resilience step later

Note the exact endpoint hostname shown for your bucket’s region (for example s3.ap-southeast-1.wasabisys.com). You’ll need this exact string in Hyper Backup’s configuration screen in Step 5, and a typo here is one of the most common causes of a failed connection.

Step 3: Generate an Access Key Pair

Hyper Backup authenticates to Wasabi using an S3-style access key and secret key, not your Wasabi account password. Generating a dedicated key pair, scoped to just the backup bucket, is both more secure and easier to rotate later if it’s ever compromised.

1. In the Wasabi console, go to Access Keys
2. Click Create New Access Key
3. Choose Create a Root Access Key for a first attempt (you can later create sub-user policies scoped to a single bucket for tighter security)
4. Copy both the access key ID and the secret access key immediately — Wasabi shows the secret key only once

Store both values in a password manager rather than a plain text file on the NAS you’re about to back up — if that NAS is ever compromised, you don’t want your cloud credentials sitting on the same disk.

Step 4: Install Hyper Backup on Your Synology NAS

If Hyper Backup isn’t already installed:

1. Log in to DSM
2. Open Package Center
3. Search for “Hyper Backup”
4. Click Install, then Open once it finishes

Check your installed version against the current release. Synology’s release notes list 4.2.1-4228, dated March 25, 2026, as the current DSM 7.x build at the time of writing. If Package Center shows an older version, run DSM’s update check before proceeding, since the S3-compatible storage target and some retention options were tightened in recent point releases.

Step 5: Configure Wasabi as an S3 Storage Backup Destination

This is the step most tutorials rush, and it’s where most failed first attempts happen. Inside Hyper Backup:

1. Click the + button in the bottom-left corner and choose Data backup task
2. On the destination screen, select S3 Storage (not “File server” and not any specific named provider tile)
3. Under server, choose Custom Server URL rather than a preset AWS region
4. Enter your bucket’s exact Wasabi endpoint, for example s3.ap-southeast-1.wasabisys.com
5. Set Signature Version 4 (v4) — Wasabi requires v4 signing, and leaving this on v2 is the single most common cause of an authentication failure
6. Paste in your access key and secret key from Step 3
7. Select your bucket name from the dropdown, or type it manually if it doesn’t auto-populate
8. Click Next

Hyper Backup will run a connection test at this point. If it fails, jump ahead to the troubleshooting section below before re-entering credentials repeatedly, since most failures here are endpoint or signature-version mismatches rather than bad keys.

# Example Wasabi S3 target values for Hyper Backup
Server: Custom Server URL
Server URL: s3.ap-southeast-1.wasabisys.com
Signature Version: v4
Bucket: yourdomain-nas-backup-2026
Directory: /hyperbackup/ds925plus
Access Key ID: your-access-key
Secret Access Key: your-secret-key

Step 6: Choose What to Back Up

After the destination connects, Hyper Backup shows a source selection screen split into shared folders, packages, and system configuration. For most households and small offices, the sensible starting scope is:

• Every shared folder holding irreplaceable data — photos, documents, financial records
• Application data for anything you’d hate to reconfigure from scratch (Synology Photos, Synology Drive, Synology Note Station if you use it)
• DSM system configuration, so a full NAS replacement can restore settings, not just files

Skip anything reproducible from source, like a media library ripped from your own physical discs, unless replacing it would genuinely cost you more time than the storage costs to keep a copy. Every extra TB selected here is an extra US$7.99 a month at current Wasabi pricing, so scope selection is really a cost decision disguised as a technical one.

Step 7: Set Encryption Before the First Upload

On the backup settings screen, enable client-side encryption and set an encryption key. This matters more with cloud backup than with a local backup, because you’re trusting a third party to store your data — client-side AES-256 encryption means Wasabi (or anyone who breaches Wasabi) sees only ciphertext, never your actual files.

Write the encryption key down somewhere other than the NAS itself. Hyper Backup cannot recover an encrypted backup without it, and there’s no “forgot password” flow — lose the key and the entire backup set is permanently unreadable, which defeats the point of having it.

Step 8: Configure Retention and Smart Recycle

Retention policy is the setting that determines whether this backup actually protects you from ransomware, or just quietly re-uploads an encrypted mess every night. Hyper Backup offers two models:

• Smart Recycle — automatically thins out older versions (keeping more recent daily versions, fewer weekly, fewer still monthly) while capping total storage growth
• Custom rotation rule — manually define how many versions to keep at each interval

For ransomware resilience specifically, the setting that matters is keeping enough historical versions that at least one predates any possible infection. If your NAS gets hit by ransomware today and you don’t notice for two weeks, a retention window shorter than two weeks means every retained version is already encrypted garbage. A common practical setting is 7 daily, 4 weekly, and 6 monthly versions, giving roughly six months of recoverable history at a storage cost increase that’s usually under 30% over keeping just the latest copy, thanks to Hyper Backup’s block-level deduplication between versions.

Different data types warrant different retention depth, and lumping everything into one policy usually means either overpaying to protect low-value files or underprotecting the files that actually matter. The table below is a starting point rather than a rule — adjust it to your own risk tolerance and how much Wasabi storage cost you’re comfortable carrying.

Step 9: Schedule the Backup Task

On the scheduling screen, set a recurring window that doesn’t compete with your NAS’s other jobs (media transcoding, Time Machine backups from Macs on the network, or Surveillance Station recording). A nightly window between 1am and 5am is typical for a home setup. For the first run only, expect the initial full backup to take substantially longer than any incremental run afterward — this is uploading your entire selected dataset for the first time, and it’s the one part of this process bandwidth, not configuration, controls.

Enable bandwidth throttling if the NAS also serves live traffic during the day, so a large scheduled backup doesn’t saturate your upload link during work hours.

Step 10: Run and Verify the First Backup

Click Apply, then manually trigger the task once rather than waiting for the schedule, so you can watch the first run and catch any issue early. In Hyper Backup’s task list, click the task and watch the log panel.

[2026-09-14 01:03:12] Task started
[2026-09-14 01:03:14] Connecting to s3.ap-southeast-1.wasabisys.com
[2026-09-14 01:03:16] Connection established
[2026-09-14 01:03:19] Scanning source: /volume1/Documents
[2026-09-14 01:03:22] Scanning source: /volume1/Photos
[2026-09-14 01:04:01] Uploading: 1.2 GB / 890 GB (0.1%)
[2026-09-14 04:41:55] Uploading: 890 GB / 890 GB (100%)
[2026-09-14 04:42:08] Verifying backup integrity
[2026-09-14 04:44:31] Task completed successfully

Once the first pass finishes, log in to the Wasabi console and confirm the bucket shows the expected data volume. A mismatch between what Hyper Backup reports as uploaded and what Wasabi shows as stored almost always means an interrupted task that needs to be re-run, not a billing error.

Step 11: Test a Restore Before You Need One

A backup nobody has ever restored from is a hope, not a plan. In Hyper Backup, open the task, click Restore, and pull back a handful of test files rather than the whole dataset. Confirm the files open correctly and the encryption key you saved actually decrypts them. This is also the moment to time how long a partial restore takes, so you have a realistic recovery-time estimate if you ever need the real thing under pressure.

Because Wasabi charges no egress fee, this test costs you nothing beyond the time it takes — there’s no reason to skip it to save money, which is one advantage this setup has over egress-billed alternatives.

Step 12: Harden Against Ransomware With Isolated Retention

The scenario that actually justifies offsite cloud backup, as opposed to a second local drive, is ransomware that encrypts both your NAS and any locally attached backup drive in the same attack. To close that gap, add a layer that even a compromised NAS admin account can’t undo:

1. Use a separate, dedicated Wasabi sub-account or scoped policy for backup, not your root credentials, so a compromised NAS can’t delete cloud copies
2. Enable versioning on the bucket at creation time (this can’t always be added retroactively without recreating the bucket)
3. Consider a second, smaller backup task with a longer retention interval pointed at a separate bucket, so even if one credential set is compromised, a second copy with different access keys survives
4. Store the Wasabi access key and encryption key in a password manager that isn’t itself backed up to the same NAS

This mirrors the logic behind a proper 3-2-1 backup strategy: the NAS is one copy, a local backup is the second, and this Wasabi bucket, isolated behind its own credentials, is the third — offsite and out of reach of anything that compromises the NAS itself.

Cost Breakdown: Wasabi vs Backblaze B2 vs Synology C2

The three realistic options for a Synology NAS owner wanting cloud backup in 2026 are Wasabi, Backblaze B2, and Synology’s own C2 Storage. Each uses a different pricing model, which matters more than the headline per-TB rate once you model in a real restore event.

These figures come from published list pricing and a third-party Australian comparison, converted at approximate exchange rates — actual cost depends on your AUD/USD conversion on the day you’re billed, and on how much data you actually store versus this 5TB example. If you’re deciding between providers rather than committing to Wasabi specifically, the earlier site guide on benchmarking cloud backup services covers a broader provider comparison methodology, and the best cloud backup services roundup compares consumer-focused providers side by side.

How This Fits a Broader Backup Strategy

A Wasabi-backed Hyper Backup task shouldn’t be your only line of defence. It plays the “offsite, isolated” role in a layered setup that also includes a local backup for fast day-to-day restores. If you’re also weighing Backblaze as a target for other machines on your network, the site’s Backblaze cloud backup setup guide covers that path, and if immutability is a hard requirement for compliance reasons rather than just a nice-to-have, the Backblaze B2 Object Lock guide walks through true write-once retention that not even an account owner can delete before the lock expires. For automating transfers between multiple cloud targets rather than relying on a single vendor’s native client, the rclone automation guide is a useful next step once this Wasabi setup is stable.

Migrating an Existing Backup From Backblaze B2 or Another Provider

If you’re not starting from scratch and already have a Hyper Backup task pointed at Backblaze B2 or another S3-compatible provider, don’t simply delete the old task and create a new one against Wasabi — that leaves you with zero valid offsite copies during the transition window, which is exactly the moment you don’t want to be exposed. Instead, run both destinations in parallel for at least one full retention cycle.

1. Leave the existing backup task running against your current provider, untouched
2. Create the new Wasabi task following Steps 2 through 9 above, using a different backup directory name so the two tasks don’t collide
3. Let the new Wasabi task complete a full initial backup and at least one successful incremental run
4. Perform a test restore from the Wasabi copy specifically, not just the old provider, to confirm the new chain works end to end
5. Only once the Wasabi backup has a few weeks of version history do you retire the old task, and even then, consider keeping the old provider’s data in place for another month or two rather than deleting it immediately

If you’d rather move the actual stored data between providers instead of re-uploading everything from the NAS a second time, a tool like rclone can sync object storage buckets directly, cloud-to-cloud, without routing the transfer back through your home internet connection at all. The site’s rclone automation guide covers that workflow if a full re-upload from the NAS isn’t practical on your connection.

Common Pitfalls When Backing Up a Synology NAS to Wasabi

Most failed setups trace back to one of these mistakes:

1. Using the wrong signature version. Wasabi requires Signature Version 4. Leaving Hyper Backup on the default or on v2 produces authentication errors that look like a bad password.
2. Choosing a region far from Australia. Picking a US-East endpoint instead of an APAC one adds noticeable latency and slows every backup window.
3. Forgetting the encryption key isn’t recoverable. Losing it means losing the entire backup set permanently — there is no reset option.
4. Backing up everything, including reproducible media libraries. This inflates storage cost for data that didn’t need protecting in the first place.
5. Setting retention too short for realistic ransomware dwell time. Many ransomware infections sit undetected for one to three weeks; a retention window shorter than that means every kept version could already be compromised.
6. Using root Wasabi credentials for the backup task. If the NAS is compromised, an attacker with root keys can delete the cloud copies too.
7. Never testing a restore. A backup task showing “success” every night tells you uploads work, not that a restore will.
8. Ignoring bandwidth throttling. An unthrottled initial backup can saturate a home connection for days and make every other household activity crawl.

Troubleshooting Guide

Even a correctly configured backup task occasionally throws errors. Here’s what the most common ones mean and how to fix them.

1. “Failed to connect to server” during setup. Double-check the endpoint hostname for typos, and confirm you selected the correct region — an endpoint for the wrong Wasabi region will refuse the connection entirely.
2. “Access denied” or “Signature does not match” errors. This is almost always the signature version. Go back into the task settings and confirm Signature Version 4 is selected, not v2 or auto.
3. Backup task stuck at 0% for a long time. Hyper Backup is often still scanning and deduplicating source files before it starts the upload, especially on a large first run — check DSM’s resource monitor to confirm the process is actually using CPU and disk I/O, not genuinely frozen.
4. Task fails partway through a large upload. Check for a DSM update or router/ISP connection drop during the window; Hyper Backup resumes from where it left off on the next scheduled run, so a partial failure isn’t a lost backup, just a delayed one.
5. Restore test shows corrupted or unreadable files. Confirm you’re using the exact encryption key from setup — a slightly wrong key (extra space, wrong case) will fail decryption silently on some file types and visibly on others.
6. Wasabi bucket shows less data than Hyper Backup reports uploaded. Check for an interrupted task in the Hyper Backup log; re-run the task manually to reconcile.
7. Backup runs painfully slowly every night. Check your bandwidth throttling setting — a limit set for testing and never removed will bottleneck every incremental run indefinitely.
8. Monthly Wasabi bill is higher than expected. Wasabi enforces a minimum storage duration policy on deleted objects; frequently deleting and re-adding large files (rather than letting versioning and Smart Recycle manage it) can trigger charges for storage you thought you’d freed.
9. DSM shows Hyper Backup as “not responding.” Restart the Hyper Backup package from Package Center; this usually resolves after a DSM update that the package hasn’t fully re-initialised against yet.

Advanced Tip: Scoping Access Keys to a Single Bucket

The root access key generated in Step 3 works, but it can read, write, and delete every bucket in your Wasabi account. Once your backup task is running reliably, replace it with a scoped policy attached to a dedicated sub-user, so a leaked credential — or a compromised NAS with that key stored on it — can’t touch anything beyond the one backup bucket. In the Wasabi console, create a policy similar to this before generating the sub-user’s access key:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::yourdomain-nas-backup-2026",
        "arn:aws:s3:::yourdomain-nas-backup-2026/*"
      ]
    }
  ]
}

Attach this policy to a new sub-user, generate that sub-user’s access key pair, and swap it into Hyper Backup’s destination settings in place of the root key. Test the connection again after swapping — a policy that’s too narrow will show as a connection or permission failure rather than a clear error message, so re-verify the first backup task runs cleanly before relying on it.

Advanced Tip: Verifying Bucket Contents From the Command Line

Because Wasabi is S3-compatible, you can inspect what’s actually stored in your bucket using the standard AWS CLI, pointed at Wasabi’s endpoint instead of Amazon’s. This is useful for a periodic sanity check that doesn’t rely on trusting Hyper Backup’s own reporting, and it works from any machine with the AWS CLI installed, not just the NAS itself.

# Configure a named profile for Wasabi (one-time setup)
aws configure --profile wasabi-backup

# List objects in the backup bucket
aws s3 ls s3://yourdomain-nas-backup-2026 \
  --endpoint-url https://s3.ap-southeast-1.wasabisys.com \
  --profile wasabi-backup \
  --recursive --human-readable --summarize

# Example output:
# 2026-09-13 01:44:31    1.2 GiB hyperbackup/ds925plus/version_142
# 2026-09-14 04:44:31    1.3 GiB hyperbackup/ds925plus/version_143
# Total Objects: 214
# Total Size: 890.4 GiB

If the object count or total size hasn’t grown since your last scheduled backup, that’s a sign the task is either failing silently or not running on schedule — check the Hyper Backup log on the NAS next.

Advanced Tip: Splitting Backup Scope Across Multiple Wasabi Buckets

Once the basic setup is running reliably, consider splitting your backup scope across two Wasabi buckets with separate access keys — one holding irreplaceable personal data with long retention, and a second holding lower-priority application data with a shorter, cheaper retention window. This isn’t necessary for most home setups, but for a small business NAS holding both client records and internal working files, it lets you apply stricter access control and longer legal-hold retention to the data that actually needs it, without paying the same retention cost across everything.

Advanced Tip: Monitoring Backup Health Without Logging Into DSM Daily

Hyper Backup can send task status notifications through DSM’s notification centre to email or a mobile push notification. Set this up so a failed task alerts you immediately rather than being discovered a month later when you actually need to restore something. For a household or small office, a monthly calendar reminder to manually check the Wasabi console and confirm the stored data volume is growing as expected catches the kind of silent failure that notifications sometimes miss.

Advanced Tip: Scripting a Backup Health Check

DSM’s built-in notifications cover task failures, but they won’t tell you if a task has quietly stopped running altogether — for example if the scheduler was disabled during a DSM update. A simple scheduled script run from DSM’s Task Scheduler, checking the Wasabi bucket’s most recent object timestamp against the current date, catches that failure mode too. This example uses the AWS CLI configured against Wasabi’s endpoint (as set up in the earlier command-line verification tip) and sends an alert through a webhook if the newest object is older than expected.

#!/bin/bash
# health-check.sh — run daily via DSM Task Scheduler
BUCKET="yourdomain-nas-backup-2026"
ENDPOINT="https://s3.ap-southeast-1.wasabisys.com"
PROFILE="wasabi-backup"
MAX_AGE_HOURS=36

LATEST=$(aws s3api list-objects-v2 \
  --bucket "$BUCKET" --endpoint-url "$ENDPOINT" --profile "$PROFILE" \
  --query 'sort_by(Contents,&LastModified)[-1].LastModified' --output text)

LATEST_EPOCH=$(date -d "$LATEST" +%s)
NOW_EPOCH=$(date +%s)
AGE_HOURS=$(( (NOW_EPOCH - LATEST_EPOCH) / 3600 ))

if [ "$AGE_HOURS" -gt "$MAX_AGE_HOURS" ]; then
  curl -s -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"Wasabi backup stale: newest object is ${AGE_HOURS}h old\"}" \
    "https://your-webhook-url"
fi

Set this to run once a day, an hour or two after the scheduled Hyper Backup window closes. A stale-backup alert firing repeatedly is a far better failure mode to discover than finding out the backup silently stopped months ago, on the day you actually need to restore from it.

The Complete Working Setup, Summarised

By the end of this tutorial, you should have: a Wasabi account with a bucket in an APAC region, a dedicated non-root access key pair, Hyper Backup 4.2.1-4228 or later configured with S3 Storage pointed at that bucket using Signature Version 4, client-side AES-256 encryption enabled with the key stored safely off the NAS, a retention policy that spans at least several weeks of history, a scheduled nightly task with bandwidth throttling during business hours, and — critically — a tested restore that confirms the whole chain actually works. That’s a genuinely resilient offsite backup, not just an upload job that runs and hopes.

Frequently Asked Questions

Do I need a Synology NAS specifically, or does this work with QNAP too?
This tutorial is written for Synology’s Hyper Backup app specifically. QNAP’s Hybrid Backup Sync app supports S3-compatible targets including Wasabi through a similar but not identical configuration screen — the core concepts (custom endpoint, Signature Version 4, access keys) carry over, but menu paths differ.

Is Wasabi actually cheaper than Backblaze B2 for a Synology NAS?
It depends on how often you restore. Wasabi’s per-TB storage rate is slightly higher than Backblaze B2’s, but Wasabi charges no egress fees, while B2 bills for downloads beyond a free allowance. For backup workloads where restores are rare but can be large, Wasabi’s model tends to work out cheaper once you factor in even one full restore per year.

What happens if I lose my Wasabi encryption key?
The backup becomes permanently unreadable. Hyper Backup’s client-side encryption has no recovery mechanism or password reset — store the key in a password manager separate from the NAS itself.

Does this protect against ransomware that encrypts the NAS?
Yes, provided you use a dedicated, non-root Wasabi access key for the backup task and keep enough historical versions that at least one predates the infection. If an attacker gains access to the same root credentials used for backup, they could potentially delete cloud copies too, which is why a scoped, separate key matters.

How long does the first backup take?
It depends entirely on your upload bandwidth and dataset size. A few hundred gigabytes on a fast NBN plan can finish overnight; multiple terabytes on a slower upload link can take several days running continuously in the background.

Can I use this setup for a small business, not just a home NAS?
Yes — the same Hyper Backup and Wasabi configuration scales to business use, though for compliance-sensitive data you should also review retention requirements specific to your industry and consider splitting buckets by data sensitivity, as covered in the advanced tips above.

Is Wasabi Cloud NAS the same product as this tutorial covers?
No. Wasabi Cloud NAS is a separate gateway product priced at US$9.99/TB/month from September 15, 2026, designed to present Wasabi storage as a network share. This tutorial uses plain Wasabi Hot Cloud Storage as an S3-compatible backup target through Hyper Backup, which is a different, and for most home or SMB backup use cases more cost-effective, approach.

Do I still need a local backup if I have this cloud setup?
Yes. Cloud backup to Wasabi should be one leg of a 3-2-1 strategy, not your only copy — a local backup gives you a much faster restore for routine file recovery, while the cloud copy is your protection against a disaster that takes out the NAS and anything physically connected to it.