Storage destinations

A storage destination is the bucket a backup job's output is written to. Each policy picks one destination at creation; every archive under that policy lands there.

Two kinds, as the Destinations page puts it: "Managed buckets are Norcube-owned; customer-owned destinations (R2, B2, Wasabi, MinIO, AWS S3 outside our account) live on infrastructure you control."

Manage them in Backup → Destinations — the list shows each destination's type, bucket, region, ownership, and verification status, with search and filters (Managed / BYO / Unverified only).

Managed destinations

Norcube provisions managed storage for your organization on demand — you never see or configure the bucket. Archives are encrypted at rest and organized under per-datasource, per-job prefixes; access is restricted to the Backup control plane, which is what makes 15-minute download links possible. Storage is billed per GB retained per month.

Managed destinations can't be edited or deleted — they have no credentials to rotate and nothing to configure.

BYO destinations

Point Backup at a bucket you own when you want the archives on your own infrastructure — in-house audit requirements, downstream pipelines (lifecycle transitions, replication, triggers), or just consolidated cloud billing.

Create

Destinations → New destination. The header sets expectations: "Register an S3-compatible bucket. We verify the credentials with a tiny write/read/delete probe before saving."

• Destination name — a label only you'll see (customer-r2-prod).
• Provider — picks sensible defaults and shows provider-specific help:
  • AWS S3 — a real AWS region required (eu-central-1, …); no endpoint URL, the SDK resolves it.
  • Cloudflare R2 — endpoint https://{ACCOUNT_ID}.r2.cloudflarestorage.com (replace with your account ID); region stays auto.
  • Backblaze B2 — regional endpoint (e.g. https://s3.us-west-002.backblazeb2.com); use the S3-compatible application key, not the master key.
  • Wasabi — the regional endpoint matching the bucket's location.
  • Generic S3-compatible (MinIO, …) — self-hosted MinIO or any other S3-compatible service.
• Bucket and Region.
• Endpoint URL — shown for everything except AWS S3; pre-filled per provider.
• Force path-style addressing — "Required for MinIO and a few self-hosted S3-compatible services. R2, B2, and Wasabi use virtual-hosted-style (leave unchecked)." Defaults on for MinIO.
• Encryption at rest — sse-s3 uses the bucket's default encryption (recommended for BYO providers — R2, B2, Wasabi, and MinIO all encrypt at rest by default); sse-kms only applies to AWS S3 buckets with a customer-managed KMS key.
• Access key ID / Secret access key — credentials with write access to the bucket.

Click Verify & save destination. As the form's info box explains: "On submit we run a tiny write/read/delete probe against your bucket. If anything fails we won't save the destination — you'll see the underlying error inline and can correct the credentials or endpoint. Credentials are KMS-wrapped at rest once verify succeeds."

The probe writes a small test object, reads it back, then deletes it (delete failure is tolerated — write+read access is what matters). A failed probe leaves no partial state: no destination row, no stored credentials, no audit entry.

Credential handling

Stored credentials are envelope-encrypted exactly like database credentials (details) and are write-only — no screen or API ever returns them. Rotating keys is done via the API (PATCH /storage-destinations/{id}), which requires the access key and secret together and re-runs the verification probe before saving — a successful rotation updates the destination's Verified timestamp (audited as storage_destination.reverified).

Delete

Use the row's delete action. The dialog spells out the semantics:

• The destination is retired and its stored credentials are wiped.
• "Existing backup archives in the bucket are not touched — they're the customer's data on the customer's storage." Past job records keep their pointer for historical reference.
• The request is refused while any backup policy still uses this destination — point those policies elsewhere or delete them first.
• It's also refused while any backup still lives in the destination. Deleting it wipes the credentials those archives need to be downloaded or restored, so you must delete those backups (or let retention expire them) first — this prevents silently orphaning archives you can still reach.

Behaviour and edge cases

• A policy's destination is chosen at creation. To move future backups elsewhere, create a new policy on the new destination and swap attachments; archives already written stay put.
• Automatic retention cleanup applies to managed storage. On BYO buckets, Backup writes archives but doesn't reliably remove old ones — pair the policy's retention window with a lifecycle rule on your own bucket (expire objects under the backup prefix after N days) so aged archives don't accumulate.
• Bucket lifecycle rules are yours anyway. You can layer transitions (Glacier, deep archive) on a BYO bucket — just don't expire objects earlier than the retention window you still want restorable.
• Verification status is visible. The Verified column shows when credentials last passed the probe; the Unverified only filter surfaces destinations that need attention.

Related

• Create a backup policy — where a destination gets used.
• Encryption and security — how destination credentials and archives are protected.