Offsite cloud backup
Synology Hyper Backup to Backblaze B2: S3 Setup and Recovery Plan
Backblaze B2 is a practical offsite destination for Synology Hyper Backup because Backblaze exposes an S3-compatible API that Hyper Backup can use as an S3 Storage target. The important part is not copying endpoint values into a wizard; it is designing the bucket, application key, retention, encryption and restore process so the cloud copy remains useful after the NAS or credentials are lost.
Quick answer
Create a restricted B2 destination, then treat restoration as part of setup
Create a private B2 bucket, create an application key with only the permissions the backup requires, record the S3 endpoint, then configure Hyper Backup with Custom Server URL and Signature Version v4. After the first successful backup, use Backup Explorer to restore test files and document where the B2 credentials and Hyper Backup encryption secrets are stored.
Live Amazon products
Current hardware for this workflow
This Sprint 9E catalogue is intentionally small: it surfaces current and previous Synology systems relevant to photo, backup and remote-access ownership decisions, while compatible third-party NAS drives can be read from Cloudzat Storage Price Intelligence in read-only mode. Hardware cards support the workflow; they do not replace the application and recovery guidance on each page.
Owner decision
B2 is the offsite copy, not the only recovery path
Cloud backup protects against local disaster, but large restores are constrained by Internet speed and egress workflow. Keep a local recovery copy when downtime matters, and use B2 for geographic separation. The most resilient design values both recovery speed and offsite survival.
Interactive owner tool
Backblaze B2 Backup Planner
Use this as a planning aid. It identifies missing reliability layers and the simplest likely direction, but it does not replace current Synology, Immich, Backblaze, Google or Tailscale documentation for the exact service and software version.
Owner reliability checklist
Four checks before trusting the new workflow
Protect the original data
A photo or backup application is not the final safety layer. Know where originals live and keep an independent copy outside the primary NAS.
Design remote access by user role
Family photo access, private administrator access and public sharing do not need the same exposure or credentials.
Document recovery secrets
Encryption keys, cloud credentials, tailnet access and DSM accounts should remain recoverable even when the original NAS is unavailable.
Test before deleting the old copy
Migration and backup jobs are complete only after representative files restore, metadata looks correct and the next administrator can follow the procedure.
Start with a dedicated private bucket
Backblaze lets you create private or public B2 buckets. A NAS backup repository should normally be private because there is no reason for anonymous users to read backup objects.
Use a recognizable bucket name that is not shared with unrelated experiments. Isolation makes lifecycle, permissions and troubleshooting easier, and it reduces the chance that another application key receives broader access than necessary.
Create a purpose-built application key
Backblaze exposes a keyID and applicationKey for programmatic access. Create a credential specifically for Hyper Backup rather than reusing a broad account-level key across many services.
Store the secret securely when it is created because Backblaze only displays the applicationKey at creation time. Recovery documentation should identify how a trusted administrator can obtain or rotate the credential without searching old browser sessions.
Record the correct regional S3 endpoint
Backblaze’s integration guide instructs users to select Custom Server URL in Hyper Backup and enter the B2 S3 endpoint shown for the bucket. The endpoint matters because it directs the S3-compatible client to the correct B2 region.
Copy it from the B2 console rather than using a generic value from an old tutorial. Cloud endpoints and regions are infrastructure details worth verifying at setup time.
Use Signature Version v4 and the B2 credentials
Backblaze specifies Signature Version v4 for the Hyper Backup S3 configuration. The keyID maps to the access-key field and the applicationKey maps to the secret-key field.
If the key is restricted to one bucket, make sure its permissions and list-bucket behavior allow Hyper Backup to complete the setup. A connection failure is often credential scope or endpoint configuration rather than a Synology storage problem.
Choose the source with recovery in mind
Hyper Backup can protect selected folders, packages and other supported data. Do not send every terabyte to B2 simply because the destination is available. Classify what must survive a local disaster and what can be recreated.
Irreplaceable photos, documents, configurations and business datasets usually deserve priority. Replaceable media libraries may be better protected locally if cloud storage and restore bandwidth would add large costs for data that can be re-ripped or downloaded.
Estimate the first upload from upstream bandwidth
A multi-terabyte NAS can take days or weeks to upload over a residential connection. The relevant speed is sustained upstream throughput after overhead and other household traffic, not the maximum download rate in your ISP plan.
Run the initial job during a period when the NAS and network can remain stable. If the dataset is enormous, evaluate whether a different first-copy strategy is needed before committing to a cloud design that can never finish its baseline.
Encrypt when the offsite provider should not see plaintext
Hyper Backup supports client-side encryption. When enabled, data is encrypted before it leaves the NAS, which can reduce trust placed in the storage provider.
The tradeoff is credential responsibility. Keep the encryption password/key in a secure independent location. Losing the NAS and the only copy of the decryption secret at the same time makes the offsite repository useless.
Retention affects both protection and storage growth
Versioning protects against deletions and corruption discovered later, but every retained change consumes storage. Use Smart Recycle or a custom policy based on how quickly data changes and how far back users realistically need to recover.
Photo archives may change slowly after import, while working documents can accumulate frequent versions. Separate tasks can keep retention logic aligned with the data rather than applying one compromise schedule to everything.
Cloud does not remove ransomware planning
If compromised credentials can delete the B2 repository, offsite location alone is not sufficient protection. Restrict application keys, protect the Backblaze account with strong authentication and avoid using one administrative credential everywhere.
Version retention helps with changed data, but account security and deletion controls are equally important. Backup resilience is strongest when the production NAS cannot casually destroy every historical copy.
Restore testing should include the cloud path
A successful upload proves only that data can leave the NAS. Use Hyper Backup Explorer or the appropriate restore workflow to retrieve representative folders and open the restored files.
Test from the perspective of a damaged or unavailable source NAS. Record the B2 endpoint, bucket, credentials, Hyper Backup secret and expected repository name so recovery does not depend on the machine that was just lost.
Large disaster restores may need a local companion copy
Cloud restores are constrained by your downstream connection and the size of the dataset. A local external drive or second NAS can restore everyday data much faster, while B2 remains the copy that survives fire, theft or another building-level event.
This is why 3-2-1 designs remain useful even when cloud storage is inexpensive. The offsite copy and the fast local copy solve different operational problems.
Monitor cost and capacity as the NAS grows
A B2 backup that starts at 2TB may quietly become 10TB as photo and video collections expand. Track source growth, retention overhead and the amount of data that truly needs offsite protection.
Review the task at least annually. Storage prices, dataset value, bandwidth and alternate providers can change. A backup destination should remain an active design choice rather than a forgotten monthly bill. Before changing providers or deleting a task, export or record the configuration and confirm that the repository can still be relinked. Long-lived cloud backups often outlast the laptop, browser profile or administrator who originally created the bucket, so operational continuity matters as much as today’s upload speed. Keep provider billing contacts and account-recovery methods current as part of the backup review.
Questions people ask
Hyper Backup and Backblaze B2 questions
Does Synology Hyper Backup support Backblaze B2?
Yes. Backblaze documents Hyper Backup integration through the B2 S3-compatible API using the S3 Storage destination.
Which S3 signature version should I use?
Backblaze’s current integration guide specifies Signature Version v4.
What is the B2 access key in Hyper Backup?
Use the Backblaze keyID as the access key and the applicationKey as the secret key.
Should the B2 bucket be private?
A backup bucket should normally be private unless you have an unusual requirement for public object access.
Can I encrypt Hyper Backup data before B2?
Hyper Backup supports client-side encryption. Preserve the decryption secret somewhere independent from the NAS.
How long will the first upload take?
It depends on dataset size and sustained upstream bandwidth. Multi-terabyte initial uploads can take many days on residential Internet.
Should I back up my entire media library to B2?
Only if the recovery value justifies storage and restore cost. Replaceable media may be less important than irreplaceable photos and documents.
Is B2 enough for 3-2-1 backup?
It can provide the offsite copy, but the complete strategy still requires multiple copies and preferably different media or systems.
How do I know the B2 backup can restore?
Restore sample files and folders through the Hyper Backup recovery workflow and document the credentials and endpoint needed for a future rebuild.
Do I need a local backup too?
A local copy is valuable when fast restore matters. B2 protects against site-level loss; local storage can reduce recovery time after smaller incidents.
Official references and methodology
Verify the exact service, data path and recovery plan
This guide follows Backblaze’s current Synology Hyper Backup integration steps and Synology Hyper Backup capabilities. It treats B2 as an S3-compatible offsite repository and explicitly separates credential scope, encryption, first-upload bandwidth and restore testing from the mechanics of creating the task.
- Backblaze Hyper Backup integration guide
- Hyper Backup DSM 7.4 specifications
- Hyper Backup backup-task documentation
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, NAS models, DSM behavior, application versions and service documentation can change. Verify the exact Synology model and the current Synology, Immich, Backblaze, Google or Tailscale documentation before changing a production photo, backup or remote-access workflow.