06. B2 Cloud Storage deep dive

Be fluent enough to be honest. Every feature below has a “how it actually behaves” note, because the POC will find it if you do not.

What you will be able to do after this section

• Explain B2’s architecture from shard to region in 90 seconds.
• Configure buckets, keys, Object Lock, lifecycle, replication, and encryption from memory.
• Name every documented S3 compatibility gap before the customer finds it.

1. Architecture: from file to vault

Backblaze Vault. 20 storage pods, one per cabinet. Drives in the same slot position across the 20 pods form a tome. Each file is written to one tome.

Erasure coding. Each file is split into 20 shards: 17 data + 3 parity using Reed-Solomon. Any 17 shards rebuild the file. The vault survives a pod failure, a full cabinet power loss, or a cabinet network outage. Writes still succeed with one pod down (leaving two parity shards). Reads succeed with three pods down.

Designed durability: 99.999999999 percent (11 nines) annually, per Backblaze docs “Resiliency, Durability, and Availability” (updated Aug 2023, checked 2026-10-14).

Overhead math for the whiteboard: 20/17 = 1.176. Backblaze stores about 1.18 raw bytes per logical byte inside a vault, versus 3.0 for triple replication. That efficiency is a big part of how a $6.95 price works.

How it actually behaves: durability is per region. A region is one or more data centers (US West uses Sacramento and Phoenix). If the requirement is “survive loss of a region”, the answer is Cloud Replication to a second account in another region, priced as a second copy.

2. Regions and data centers

Source: docs “Where are the Backblaze Cloud Storage Data Centers” (updated Feb 2025, checked 2026-10-14). Storage price is the same in every region.

How it actually behaves:

• Region is chosen at account creation and cannot be changed.
• One account = one region. Multi-region = multiple accounts, usually tied together under a Group.
• S3 endpoints look like https://s3.<region-code>.backblazeb2.com, for example s3.us-west-004.backblazeb2.com. The exact code appears on the bucket details page. Never guess it in a demo.

3. Pricing mechanics (checked 2026-10-14, backblaze.com/cloud-storage/pricing)

• Storage: $6.95/TB/30 days, billed per byte-hour. First 10 GB free.
• Egress: free up to 3x average monthly stored (byte-hour average), then $0.01/GB.
• Partner egress: unlimited free to Fastly, Cloudflare, bunny.net, CacheFly, CoreWeave, Equinix Metal, Vultr, phoenixNAP.
• Transactions: Class A, B, C free for pay-as-you-go. Class D (outbound Event Notifications) first 2,500/day free, then $0.004 per 10,000.
• No minimum object size, no minimum storage duration, no upload fee, no delete fee.
• Terms: monthly PAYG (card or invoice) or annual capacity commitments of 1 to 5 years, billed in full at contract start, rate locked.
• Add-ons: implementation support, premium support, Universal Data Migration (with qualifying commitment).

Discrepancy to know: the transaction pricing page (checked 2026-10-14) still says storage is “$0.005/GB/month”, which is the old $5/TB rate. The pricing page and docs say $6.95. Quote $6.95 and flag the stale page internally.

4. Buckets, files, versions

• Buckets are private or public (allPublic). No per-object ACLs.
• B2 keeps file versions by default. Uploading the same name creates a new version. “Deleting” through S3 with versioning creates a hide marker (delete marker).
• The web console Lifecycle Settings offers presets such as “Keep all versions” and “Keep only the last version”. Veeam guides require Keep all versions, because Veeam manages retention itself.

5. Lifecycle rules

From docs (checked 2026-10-14):

• Up to 100 lifecycle rules per bucket.
• Native API rule properties: fileNamePrefix (required, "" means all files), daysFromUploadingToHiding, daysFromHidingToDeleting, daysFromStartingToCancelingUnfinishedLargeFiles. Values must be positive integers or null.
• Example:

[{"fileNamePrefix":"backup/","daysFromUploadingToHiding":7,"daysFromHidingToDeleting":30,"daysFromStartingToCancelingUnfinishedLargeFiles":3}]

• S3-compatible lifecycle configuration is also exposed (the MCP server lists “configure bucket lifecycle rules” in its S3 tools).

How it actually behaves: there is no “transition to Glacier” because there is one class. Lifecycle is about hiding and deleting versions and cleaning up unfinished multipart uploads. A rule with prefix "" can delete everything. In a demo, always scope by prefix.

6. Object Lock (immutability)

From docs “Object Lock” (checked 2026-10-14):

• Enable at bucket creation, on an existing bucket, or with b2_update_bucket. Once enabled, it cannot be disabled on that bucket.
• Retention between 1 and 3,000 days.
• Governance mode: keys with the right capability can shorten or remove retention.
• Compliance mode: nobody can remove retention; it can only be extended.
• Legal hold: independent of retention, no expiry, removed explicitly.
• Default bucket retention applies to new uploads; must be enabled at bucket creation; does not change existing files.
• Not allowed on restricted buckets (shared buckets, snapshots) or a bucket that is a replication source.
• No extra cost. Normal storage charges apply to locked data.
• Capabilities: readBucketRetentions, writeBucketRetentions, writeFileRetentions, bypassGovernance, writeFileLegalHolds and related. [verify exact capability names in app-key table before a demo]
• Was formerly called “File Lock”; some API names still say file lock.
• Functionally matches AWS S3 Object Lock per Backblaze.

How it actually behaves: most customers never touch the API. Veeam, Rubrik, Commvault, MSP360, Synology Hyper Backup ask “how many days immutable” and set it per object. The SE job is to make sure the bucket has Object Lock enabled before the backup software connects.

Landmine: compliance mode means you pay to store it until it expires, even if you leave. Set realistic retention. Say this out loud; it builds trust.

7. Application keys

• Master key: all capabilities, all buckets, shown once, regenerating invalidates the old one. Needed for Partner API and account-level admin.
• Standard keys: scoped to one bucket, multiple buckets (Multi-Bucket Application Key), a file prefix, a capability set, and an expiry. Survive master key rotation.
• Limit: 100 million app keys per account (contact sales for more).
• Use a standard key for the S3 API, integrations, and anything customer-facing.

How it actually behaves: least privilege is the security story. One key per app, per tenant, per backup server. Read-only keys for media distribution.

8. Server-side encryption

• SSE-B2: Backblaze-managed keys, AES-256, unique key per file, wrapped by a global key. Default for new uploads since Sep 14 2026 (blog Aug 27 2026). Before that, encryption was opt-in per bucket and only applied to files uploaded after enabling.
• SSE-C: customer supplies an AES-256 key on each request; Backblaze does not store it. Lose the key, lose the data.
• No extra charge to encrypt. Nominal Class C calls to read or change bucket encryption settings.
• Works through both Native and S3-compatible APIs.

9. Cloud Replication

• Copies objects from a source bucket to one or more destination buckets, same region or across regions.
• Configured in the web console or Native API; not configurable through the S3 API, but replicates files written by either API.
• New uploads replicate as they arrive; existing files (“backfill”) process daily at midnight UTC; non-fatal failures retry the next day.
• Cross-region requires a second account in that region.
• Replicated data cannot be replicated again (no chains).
• Metadata changes after initial replication are not replicated. Hidden files may not be hidden at the destination.
• First-time use needs a verified email and payment history. Over 50 TB: contact Sales.
• No service fee or egress charge for replication per Backblaze marketing; you pay storage for both copies.

10. Event Notifications

• Webhook HTTP POSTs on uploads, updates, deletions, filtered by bucket, event type, optional prefix; optional signing secret (HMAC).
• Managed via console or b2_set_bucket_notification_rules / b2_get_bucket_notification_rules.
• Request access from Support to enable (docs checked 2026-10-14).
• Billed as Class D: 2,500/day free, then $0.004 per 10,000.
• Patterns: trigger transcoding, audit logs, metadata DB updates, Cloudflare Worker, forward to AWS SNS then Lambda (Backblaze guide exists).

11. Live Read

Read and edit large media files while they are still uploading, through B2 and connected tools (Telestream Vantage guide exists). Sell it to live sports and broadcast where time-to-air matters. [verify availability terms: may require enablement]

12. S3-compatible API: the honest list

Supported: core object and bucket ops, multipart, presigned URLs (GET and PUT), SSE-B2/SSE-C, Object Lock, versioning, CORS, IPv6. Signature V4 only (Rubrik guide notes V2 fails until Rubrik support switches it).

Not supported (docs checked 2026-10-14): object ACLs, IAM roles, object tagging (Get returns empty, Put with x-amz-tagging is rejected), website configuration, browser POST uploads to presigned URLs. Bucket ACL is limited to private and public-read.

Naming rules differ slightly from AWS. Check bucket and file naming page before migrating.

13. Native B2 API, Partner API, Groups

• Native API: b2_* calls; required for some features (replication setup, event notification rules, some NAS sync per Object Lock FAQ).
• Partner API: create and manage accounts programmatically, usage reporting, billing workflows. Used by MSPs, Powered by Backblaze, and B2 Neo.
• Groups / Organizations: central admin and billing across member accounts. Group admins currently cannot manage event notification rules in member accounts.

14. Access and tooling

Web console (and an Enterprise Web Console), b2 CLI, AWS CLI, rclone, Cyberduck, SDKs, MCP server. Bucket access logs and CORS are listed security features.

Ask these, then listen

1. Which S3 features does your code use beyond Put/Get/List?
2. Do you need region-loss survival or just device and site loss?
3. Who can delete data today, and should anyone be able to?

Three moves, in this order

1. Map their API usage against section 12.
2. Pick the region by residency and GPU/user location.
3. Design keys and Object Lock before the first byte lands.