DB-유

Hyper Backup to Amazon S3 or Backblaze B2

· synology, backup, s3

RAID is not a backup. I say that to everyone who tells me their NAS is "safe" because it has two disks. RAID does nothing against a fire, a theft, ransomware on a client PC that rewrites every file on the share, or an rm -rf in the wrong folder. The off-site copy is the one that saves you, and Hyper Backup on DSM 6.x pushes an encrypted, versioned copy of selected folders to object storage with no extra hardware.

I use Amazon S3 and Backblaze B2. S3 has the most storage classes; B2 costs a fraction per gigabyte, so it's what I recommend for home and small office units. The Hyper Backup workflow is the same apart from credentials. Do the sums on your uplink first: a 2 TB initial backup over 20 Mbit/s takes about ten days.

Bucket and a restricted key

For S3, create a bucket in the region closest to you and an IAM user with a policy such as:

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

Never use root account credentials for this; a restricted key is the whole point. Save the access key ID and secret. Do not enable bucket versioning; Hyper Backup manages versions itself and S3 versioning would only double the storage.

For B2, create a private bucket, then under App Keys create a key with access to that bucket only, with read and write capabilities. Note the keyID and applicationKey; the applicationKey is shown once.

Creating the task

Hyper Backup → the plus button → Data backup task. Choose the destination:

  • Amazon S3 storage or S3 Storage for S3, entering the access key, secret, and picking the bucket from the list.
  • Backblaze B2 for B2, entering keyID and applicationKey and the bucket name.

Set a directory name inside the bucket; Hyper Backup creates a .hbk folder there and stores data in its own deduplicated block format. The contents are not browsable as plain files; you restore through Hyper Backup or Hyper Backup Explorer.

What to back up

Tick the shared folders that hold irreplaceable data: documents, photos, the homes folder, database dumps. Skip anything you can regenerate such as downloaded media, and skip the docker folder unless you have stopped the containers first, because open database files back up inconsistently.

On the next screen you can include package settings, which is worth ticking for things like Surveillance Station or Web Station configuration.

Schedule, encryption, integrity check

Task name:                  offsite-b2
Backup schedule:            daily at 02:00
Integrity check schedule:   weekly, Sunday 04:00, check all data
Client-side encryption:     enabled, strong passphrase
Compression:                enabled
Transfer encryption:        enabled

Client-side encryption means the provider never sees plaintext, and it means that losing the passphrase or the exported key file makes the backup permanently unreadable. Hyper Backup forces you to download the .pem key when you enable it. Store the key and the passphrase somewhere that is not the NAS.

Rotation

Enable backup rotation and pick Smart Recycle. It keeps hourly versions for 24 hours, daily for a month and weekly beyond that, up to the version count you set; I use 60 versions. Without rotation the task keeps every version forever and the bucket grows without bound.

First run

Start the task manually with Back up now. The first run uploads everything. On the Hyper Backup main window the task shows progress and throughput; with B2 I typically see the connection saturated. Later runs are incremental at the block level, so a few changed documents means a few megabytes of upload.

You can throttle from Control Panel → Network → Traffic Control if backups compete with users during the day, or just let the schedule keep it at night. I prefer the schedule; fiddling with throttles is something I forget about.

Restore something. Seriously.

A backup that has never been restored is a hope, not a backup. After the first run:

  1. In Hyper Backup, choose Restore → Data, select the task and a version, and restore a single folder to an alternative location on the NAS. Compare with the original.
  2. Run Integrity Check once manually and confirm it reports no errors.
  3. Check the bucket in the provider console: the .hbk directory should exist and the stored size should be close to the compressed source size.
  4. On another machine, install Hyper Backup Explorer for Windows, Mac or Linux, and open the .hbk directly from a synced copy or after downloading it. With the key file and passphrase you can browse and extract files without a Synology at all, which is the scenario you are preparing for.

Failures I've seen

  • "Failed to access the backup destination" on B2 shortly after creating the task: the application key was created for a different bucket, or the bucket is public. Recreate the key with the bucket restriction and try again.
  • The S3 task fails with AccessDenied on the first run but the connection test passed. The IAM policy is missing s3:ListBucket on the bucket ARN itself (without /*). Both resource lines in the policy above are needed.
  • The task runs for hours at zero throughput. Hyper Backup is building its file index on a share with millions of small files, or the integrity check is running at the same time. Check Resource Monitor for img_backup CPU usage; if it is busy, it is working. Splitting very large shares into separate tasks helps.
  • "Backup task is suspended because the destination has been modified by another task" appears when two Synology units are pointed at the same bucket directory. Each task needs its own directory name in the bucket.

Once it's run cleanly for a week, set Control Panel → Notification to email you on failure and leave it alone. My routine is a glance at the version list and the invoice monthly, and one small test restore a quarter.